Theme Assistant Token and Child Theme Exports

Export boundary

Token and child theme exports should contain accepted design work, not unresolved drafts, temporary fixes, failed experiments, or unrelated CSS history. The export is a developer handoff artifact and should carry review context.

Package review

Confirm token scope, CSS history, theme JSON impact, preview pages, changed files, caveats, and staging checks before delivery. The export tutorial should be paired with Design Tokens and Style System and Theme Publishing and Rollback.

Rollback context

Include the previous token set, child theme backup, CSS history label, and accountable owner so deployment issues can be reversed without guessing which visual change caused them.

Quick reference

• Use this page when planning, reviewing, presenting, publishing, or rolling back Theme Assistant visual work.
• Do not treat generated CSS, external references, or polished previews as production-ready until responsive, accessibility, cache, and rollback checks pass.

Scope limits

• This page does not replace development review for PHP templates, checkout logic, plugin behavior, or structural theme changes.
• Use it for scoped visual review, presentation, and rollback discipline before production CSS changes.

Owner and cadence

• Primary owner: designer or developer, with site-owner approval for production visual impact.
• Review cadence: before publishing, after theme updates, and after cache or WooCommerce template changes.
• Escalate when visual work affects revenue-critical pages, accessibility, mobile navigation, or theme behavior outside the intended scope.

Access and data boundary

• Use public URLs, safe screenshots, component selectors, breakpoints, and design notes that can be reviewed without exposing private admin or customer context.
• Keep checkout payment details, account data, private staging URLs, and client-only design files out of prompts, fetched references, and presentation notes.

Production checklist

• Assign a named owner and define the production impact before rollout.
• Capture validation, support, and rollback notes in the same place operators already review SophMate work.
• Capture the affected URL, target selector, intended visual outcome, reviewer, and rollback note for every meaningful visual change.
• Review mobile, desktop, keyboard focus, reduced motion, contrast, checkout, cart, account, and navigation behavior before publishing.

Acceptance checks

• The guidance can be repeated by a second operator.
• The work has a clear escalation path when it affects customers, money, content, settings, privacy, or workflow execution.
• The proposed CSS or presentation output can be traced to a specific page, component, and design goal.
• The reviewer can reject, revise, or roll back the change without guessing which selectors were affected.

Failure modes to test

• Test mobile overflow, contrast failure, keyboard focus loss, reduced-motion behavior, broad selector impact, cache differences, and checkout/account regressions.
• Confirm the CSS or presentation workflow can be rejected, revised, or rolled back from a named history item.

Evidence to capture

• Capture target URL, selector or component family, desktop/tablet/mobile review, accessibility notes, CSS history label, and approval status.
• Record screenshots or presentation notes only after removing provider keys, customer data, private URLs, and unrelated admin details.

Decision record

• Record the visual decision, target URL, component or selector family, reviewer, accessibility result, responsive result, CSS history label, and rollback owner.
• Include whether checkout, cart, account, logged-out, cache, reduced-motion, and mobile states were reviewed before production publishing.

Stop or rollback path

Pause publishing until visual scope, accessibility, affected templates, and rollback history are clear.

Monitoring window

• Monitor affected pages after cache clears, theme updates, mobile traffic, and checkout/account review.
• Review visual feedback, accessibility findings, and CSS history before expanding the design pattern.

Expansion criteria

• Reuse the design pattern only after affected breakpoints, templates, accessibility states, and rollback history pass review.
• The designer and site owner agree which pages or component families are in scope.

Common mistakes

• Publishing broad CSS from a single preview without checking logged-out, mobile, checkout, account, and cache states.
• Using external design references as production assets instead of review context.

Common questions

What is the main decision this page supports?

The page helps the team decide whether ownership, evidence, access, failure handling, monitoring, and rollback are clear enough for production use.

Who should own this decision?

The designer should own visual intent, while the site owner or developer approves production impact.

What should stop the rollout?

Stop when visual work affects checkout, account, mobile, accessibility, cache, or broad selectors without a rollback note.

Related operations

• Return to SophMate Documentation.
• Use Diagnostics and Support for support evidence.
• Use Responsive and Accessibility Review before visual publishing.
• Use Client Presentation Workflow when an agency needs client approval.
• Use Multi-Page Consistency Checker before broad component updates.