Standards of Practice for 2026 Premium WordPress Themes

Executive summary

The strongest 2026 pattern for a premium WordPress theme is a block-theme-first architecture that treats the Site Editor, theme.json, patterns, template parts, and global styles as the primary product surface; keeps PHP customizations small and well-scoped; and exposes machine-readable, permissioned management surfaces for AI and automation through WordPress-native APIs rather than ad hoc filesystem or AJAX entry points. That direction is now materially reinforced by WordPress 6.9, which made the Abilities API available in core for 6.9+ and continued the performance advantages of block themes, while WooCommerce’s own store-editing documentation increasingly assumes block themes for full template-level commerce editing.

For your audit, the central strategic conclusion is straightforward: keep the current Go theme as a benchmark and migration reference, but do not center your 2026 premium platform on it. Your Intent Packet already frames the right problem statement: Go is the thicker “premium baseline” in fallback coverage and commerce polish, while wp-theme-homoplasticus-base is the Gutenberg-native shell that should evolve into the reusable AI Foundry platform. That packet also already identifies the highest-value missing pieces: wider block-template coverage, style variations, richer pattern inventory, an allowlisted asset manifest, and governed AI mutation flows. In other words, the packet is directionally correct; what it needs is a standards-based execution model and a disciplined prioritization sequence.

As of April 2026, the practical compatibility target should be WordPress 6.9.x, specifically the latest maintained 6.9 release line, not a vague “6.x+” target. WordPress 6.9 was released on December 2, 2025, and the release archive identifies the most recent 6.9 branch release as the actively maintained line; WordPress 6.9.4 was issued on March 11, 2026 as a follow-up security release after 6.9.2 and 6.9.3. For a premium theme stack—and especially one exposing AI-assisted management surfaces—being on the latest maintained branch is not optional.

The best editor experience in 2026 comes from a theme that does four things exceptionally well. First, it keeps design tokens and most editorial styling in theme.json so Global Styles and the Style Book remain first-class and low-friction. Second, it ships broad template and template-part coverage so editors rarely hit dead ends in the Site Editor. Third, it provides pattern-driven workflows for common content types across blog, service, and commerce contexts. Fourth, it exposes governed AI surfaces with schema-validated inputs and outputs, strict permissions, approvals, audit trails, rollback, and privacy-by-default behavior.

My bottom-line judgment is that your end-state should be an AI Foundry block theme plus Foundry Bridge/Abilities layer plus MCP transport, where Go is retained only as a parity checklist and design reference. That is the architecture most aligned with modern WordPress core, WooCommerce’s current block direction, and your packet’s proposal/approval/audit goals.

Assumptions and audit baseline

I am making a few explicit assumptions because your current production stack is only partially specified. I assume you are comparing three things: a current premium Go-based site experience, a thinner Gutenberg-native block theme (wp-theme-homoplasticus-base) that you want to turn into AI Foundry, and a companion services layer consisting of a bridge plugin and an MCP server for governed AI operations. That assumption comes directly from your Intent Packet, which identifies the theme, bridge, and MCP layers as distinct responsibilities.

I also assume your current “Go” reference is effectively a classic PHP theme, because your packet describes it in classic-template terms such as 404.php, archive.php, search.php, single.php, a search form, richer fallbacks, Woo compatibility, and a broader legacy theme surface. By contrast, the packet describes wp-theme-homoplasticus-base as a block-theme shell built around theme.json, HTML templates, template parts, patterns, and locally hosted assets. That is the key architectural split for this audit.

Finally, I assume your AI/automation goal is not autonomous publishing, but AI-assisted site management with human approval. Your packet repeatedly emphasizes proposal-aware mutation, approval, audit, validation, rollback, and path-restricted asset access. That matters because the right standards for MCP/AI enablement are not just “more APIs”; they are capability discovery, least privilege, schema contracts, provenance, and human-in-the-loop governance. WordPress 6.9’s Abilities API is the first core-native feature that maps unusually well to that model.

Target state in one diagram

The architecture below reflects the most standards-aligned end state for your stack: editor-first WordPress, machine-readable capabilities in core, governed execution in the bridge layer, and MCP only as the external transport and orchestration layer. That matches both your packet and WordPress 6.9’s evolving direction.

flowchart LR
    A[Human editor or operator] --> B[WordPress Site Editor]
    C[AI client] --> D[MCP adapter]
    D --> E[Bridge plugin]
    B --> E
    E --> F[WordPress Abilities API]
    E --> G[REST API]
    E --> H[Proposal and audit store]
    E --> I[Allowlisted theme assets]
    E --> J[Templates parts patterns theme.json]
    J --> K[Front end render]
    E --> L[WooCommerce blocks and templates]

Standards of practice for a premium 2026 theme

Core compatibility and editor model

A premium 2026 theme should target the latest maintained WordPress line and treat WordPress 6.9+ as the minimum serious target if AI capability registration is a requirement, because the Abilities API only exists in core on 6.9 and above. If the platform must still satisfy some 6.8 installs, then Abilities support should be designed as progressive enhancement with a fallback discovery layer, not as duplicated permanent architecture.

The critical architectural choice is block theme over classic theme for premium Gutenberg experience. Only block themes unlock the full Site Editor model for templates, template parts, styles, and template-level editing. Classic themes still matter for backward compatibility and can now benefit from 6.9’s on-demand block style loading, but they remain second-class for full-site editing and editor-native system design. WordPress itself documents that the Site Editor is available only with block themes, and the 6.9 performance work still showed stronger gains for block themes than classic themes.

That does not mean classic themes are obsolete. It means their best role in 2026 is transition layer, legacy compatibility surface, or reference implementation, not premium platform core. If you kept Go as the parent experience, you could improve it with theme.json, editor styles, block patterns, and Style Book support, especially since 6.8 brought the Style Book to classic themes that include editor styles or theme.json. But those are transitional improvements; they do not deliver the same level of template-native editor control or AI-governable structure as a real block theme.

Theme system design

The controlling principle should be: use theme.json for system rules, CSS for exceptions, and JavaScript only where interaction genuinely requires it. WordPress’s theme handbooks repeatedly position theme.json as foundational, and specifically recommend using the styles property wherever possible so that the Site Editor and Global Styles remain coherent and specificity conflicts stay limited. settings.custom is especially useful for stable token contracts because it generates CSS custom properties you can reuse both in theme.json and in conventional CSS.

A premium block theme should ship a full template topology, not just a handsome front page. Your own packet identifies the right missing coverage: 404, archive, search, single, blog/home, and broader template-part taxonomy. That aligns with the Site Editor’s strength: a premium block theme is valuable precisely because editors can work on these states without dropping back to PHP templates or the Customizer. Template parts should be registered via theme.json so they appear with clean labels and areas inside the editor UX.

Patterns should be treated as productized editorial accelerators, not demo filler. WordPress recommends theme-bundled patterns in /patterns, and block-type or semantic patterns are especially powerful for contextual insertion—such as header/footer replacements or query-loop starter layouts. For your use case, pattern families should map directly to real workflows: hero, longform editorial lead, proof/testimonial, FAQ, timeline, CTA, product merchandising, trust bar, author strip, and footers.

Style variations belong in /styles and should replace many historic “child-theme-for-colorway” habits. WordPress explicitly distinguishes style variations from child themes: variations are ideal for alternative visual systems built on the same theme contract, while child themes remain the right tool when code, templates, or functional overrides are needed. In your context, that means “storefront,” “service,” “journal,” and “science/editorial” should be style variations and pattern packs first, not separate theme forks.

Performance, accessibility, security, and maintenance

For premium themes in 2026, performance should be governed by explicit budgets, not good intentions. web.dev defines performance budgets as limits on metrics or resource sizes, and a useful baseline remains keeping critical-path resources lean, with user-centric metrics as the real outcome measure. For WordPress specifically, WordPress 6.9’s frontend guide underscores that block themes often avoid separate render-blocking CSS entirely when most styling is expressed through Global Styles, and core testing in 6.9 showed larger LCP improvements on block themes than on classic themes.

For operating targets, I recommend using the current Core Web Vitals thresholds as non-negotiable service levels: LCP at or below 2.5s, INP at or below 200ms, and CLS at or below 0.1, all at the 75th percentile for mobile and desktop cohorts; and TTFB at or below 0.8s as a supporting server-side target. WordPress 6.8 and 6.9 both added features that can help—such as speculative loading, query caching work, inline/minified block-theme styles, and better critical-path behavior—but the theme must still do its own part: never lazy-load the LCP image, use fetchpriority="high" for true LCP candidates where applicable, self-host fonts where practical, and limit third-party scripts aggressively.

Accessibility standards should be pegged to WCAG 2.2 AA now, with WCAG 3.0 used only as directional guidance, not as a release conformance target. WCAG 2.2 is a W3C Recommendation, while WCAG 3.0 is still a Working Draft and is explicitly not ready to be treated as a stable compliance target. For themes, the most operationally relevant newer 2.2 criteria are focus visibility/obscuration, target size, dragging alternatives, redundant entry, and accessible authentication. WordPress theme review guidance also reinforces basics that are still commonly broken in premium themes: skip links, visible focus, proper controls, labels, contrasts, landmark structure, and link distinguishability.

Security and maintenance should follow a simple rule set: stay on the latest maintained core version, do not expose uncontrolled file mutation, escape late, validate and sanitize input, use nonces for state-changing requests, and tie all privileged operations to capability checks. WordPress’s own documentation emphasizes escaping output, nonce usage, and the need to update to the latest version, while the theme review rules require privacy-sensitive behaviors like opt-in-only tracking. For your stack, the biggest additional rule is that AI must never bypass the same permission and validation boundaries a human admin would need to cross.

Commerce, multilingual, SEO, extensibility, and MCP enablement

WooCommerce’s current documentation makes block themes the natural premium path for deep store editing. WooCommerce explicitly notes that full site-editing customization of store templates requires a block theme, and its current store-editing guidance centers on templates, patterns, cart/checkout blocks, product collection blocks, and product-specific templates. The conversion pattern to follow is therefore: block-theme store templates, patternized merchandising sections, locked dynamic commerce blocks where necessary, and minimal template overrides. As WooCommerce itself reiterates, hooks are usually more robust than copying templates when you can choose.

For modern Woo stores, you should prefer Cart and Checkout blocks over legacy shortcode flows, use empty-state design intentionally, and reuse Product Collection instead of older single-purpose merchandising blocks where possible. WooCommerce’s current docs describe Checkout as a simplified conversion-optimized checkout flow and document modern cart/checkout block structures, while the Cart block now uses Product Collection for cross-sells in current releases.

Multilingual readiness begins with proper WordPress internationalization—stable text domains, wrapped strings, loaded translations, JS i18n where needed—but premium multilingual operation also requires URL architecture and search signaling discipline. Google’s guidance is still clear: if you ship localized versions, every language variant should reference itself and its siblings with hreflang, and each locale/version should have a coherent canonical strategy. That makes theme responsibilities practical rather than abstract: locale-aware navigation labels, language-switcher placement, translated template-part strings, and clean per-locale navigation/pattern defaults.

SEO should remain content-first, structure-aware, and schema-supported, not plugin-magic-first. Google’s current Search Central guidance emphasizes crawlable content, descriptive titles, snippet quality, logical URLs, canonicalization, and helpful people-first content. For WordPress themes, that means semantic headings, accessible link text, strong on-page document structure, and optional structured data that accurately matches visible content. At minimum, blogs should consider Article and Breadcrumb support, while Woo product pages should support Google’s product markup expectations.

For extensibility and child-theme/plugin interoperability, the standard is to keep the theme opinionated but not territorial. Patterns, style variations, template parts, theme.json tokens, and block hooks should do most of the work. The Block Hooks API is especially important because it lets plugins insert blocks into block themes while still preserving user control in the Site Editor. Child themes should remain viable for code-level customizations, but pure visual choice should prefer style variations and patterns.

For MCP/AI enablement, the mature standard in 2026 is: discoverable abilities, JSON-schema contracts, standard authentication, human approval for high-risk actions, and comprehensive audit/provenance. WordPress 6.9’s Abilities API is unusually well suited to this because it standardizes machine-readable capability registration with inputs, outputs, permissions, categories, hooks, and optional REST exposure. Combined with WordPress REST API and application passwords, it gives you a stable WordPress-native contract that an MCP adapter can translate into AI-consumable tools without inventing a separate capability registry from scratch.

That leads to the right AI workflow pattern for your packet: read freely where safe, propose before write, validate before apply, log every operation, preserve human attribution, and store diffs/rollback bundles as first-class records. GitHub Actions artifact attestations can add software build provenance, while WordPress revisions, proposals, and audit logs can provide editorial and operational provenance. Privacy-wise, the minimum standard is opt-in telemetry, least-privilege credentials, redaction of sensitive fields from AI prompts, and explicit consent before sending content to external models or services.

Gap analysis checklist

The table below is designed as a practical audit sheet for your current Go-centered stack. I have marked the likely risk posture based on your packet, but the table is meant to be rerun against the actual production implementation.

Prioritized remediation roadmap

The roadmap below assumes you want to keep business continuity while moving from a Go-centered premium stack to an AI Foundry premium block-theme platform.

gantt
    title Suggested modernization sequence
    dateFormat  YYYY-MM-DD
    section Foundation
    Core and patch alignment           :a1, 2026-04-25, 7d
    Theme inventory and parity map     :a2, 2026-04-25, 10d
    section Theme system
    Expand template hierarchy          :b1, after a2, 21d
    Add style variations and patterns  :b2, after a2, 21d
    section Commerce and quality
    Woo block template hardening       :c1, after b1, 21d
    Performance and accessibility CI   :c2, after b1, 14d
    section AI governance
    Abilities and asset manifest       :d1, after b2, 21d
    Proposal audit rollback workflow   :d2, after d1, 14d
    section Packaging
    Release process and provenance     :e1, after c2, 10d

Recommended effort scale

For planning purposes: S = hours to a couple of days; M = about one to three weeks; L = three to six weeks of coordinated theme/plugin/QA work. Those are implementation estimates, not elapsed calendar guarantees.

Reference implementation

A theme.json baseline for editor-first premium themes

This example shows the shape of a mature premium block theme: design tokens in settings, editor-governed styles in styles, explicit template-part registration, and pattern/style-variation friendly structure. It uses version: 3, which is the current theme.json generation for WordPress 6.6+ and the latest Gutenberg line.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "useRootPaddingAwareAlignments": true,
    "layout": {
      "contentSize": "720px",
      "wideSize": "1280px"
    },
    "color": {
      "defaultPalette": false,
      "defaultGradients": false,
      "palette": [
        { "slug": "bg", "name": "Background", "color": "#F7F7F5" },
        { "slug": "fg", "name": "Foreground", "color": "#171717" },
        { "slug": "accent", "name": "Accent", "color": "#275EFE" },
        { "slug": "muted", "name": "Muted", "color": "#6B7280" },
        { "slug": "success", "name": "Success", "color": "#0E9F6E" }
      ]
    },
    "typography": {
      "fluid": true,
      "defaultFontSizes": false,
      "fontFamilies": [
        {
          "slug": "inter",
          "name": "Inter",
          "fontFamily": "\"Inter\", system-ui, sans-serif"
        },
        {
          "slug": "display",
          "name": "Playfair Display",
          "fontFamily": "\"Playfair Display\", serif"
        }
      ],
      "fontSizes": [
        { "slug": "xs", "size": "0.875rem", "name": "XS" },
        { "slug": "sm", "size": "1rem", "name": "SM" },
        { "slug": "md", "size": "1.125rem", "name": "MD" },
        { "slug": "lg", "size": "clamp(1.5rem, 2vw, 2rem)", "name": "LG" },
        { "slug": "xl", "size": "clamp(2rem, 4vw, 3.25rem)", "name": "XL" }
      ]
    },
    "spacing": {
      "spacingScale": {
        "operator": "*",
        "increment": 1.5,
        "steps": 7,
        "mediumStep": 1.25,
        "unit": "rem"
      }
    },
    "custom": {
      "radius": {
        "sm": "0.5rem",
        "md": "0.875rem",
        "lg": "1.25rem"
      },
      "shadow": {
        "sm": "0 1px 2px rgba(0,0,0,.06)",
        "md": "0 8px 24px rgba(0,0,0,.10)"
      },
      "motion": {
        "duration": {
          "fast": "120ms",
          "base": "180ms",
          "slow": "280ms"
        },
        "easing": {
          "standard": "cubic-bezier(.2,.8,.2,1)"
        }
      }
    },
    "blocks": {
      "core/button": {
        "border": { "radius": true },
        "typography": { "fontSize": true }
      },
      "core/navigation": {
        "spacing": { "blockGap": true }
      },
      "woocommerce/product-image": {
        "border": { "radius": true }
      }
    }
  },
  "styles": {
    "spacing": {
      "padding": {
        "left": "var:preset|spacing|30",
        "right": "var:preset|spacing|30"
      }
    },
    "color": {
      "background": "var:preset|color|bg",
      "text": "var:preset|color|fg"
    },
    "elements": {
      "link": {
        ":hover": {
          "typography": { "textDecoration": "underline" }
        }
      },
      "button": {
        "border": {
          "radius": "var(--wp--custom--radius--md)"
        }
      }
    },
    "blocks": {
      "core/button": {
        "border": {
          "radius": "var(--wp--custom--radius--md)"
        }
      },
      "core/navigation": {
        "typography": {
          "fontWeight": "600"
        }
      }
    }
  },
  "templateParts": [
    { "name": "header", "title": "Header", "area": "header" },
    { "name": "footer", "title": "Footer", "area": "footer" },
    { "name": "commerce-header", "title": "Commerce Header", "area": "header" },
    { "name": "article-meta", "title": "Article Meta", "area": "uncategorized" },
    { "name": "trust-bar", "title": "Trust Bar", "area": "uncategorized" }
  ]
}

Pattern and block registration

For premium editorial DX, prefer the /patterns directory for most theme-bundled patterns, and use manual registration for cases where you need dynamic logic, semantic categories, or block-type targeting. Semantic patterns for header/footer replacements and contextual patterns for block transforms make the inserter substantially more effective.

<?php
/**
 * functions.php
 */

add_action( 'init', function () {
    register_block_pattern_category(
        'ai-foundry-proof',
        array(
            'label' => __( 'Proof', 'ai-foundry' ),
        )
    );

    register_block_pattern(
        'ai-foundry/author-strip',
        array(
            'title'       => __( 'Author Strip', 'ai-foundry' ),
            'categories'  => array( 'ai-foundry-proof' ),
            'blockTypes'  => array( 'core/post-content' ),
            'description' => __( 'Compact author metadata and trust signals for article templates.', 'ai-foundry' ),
            'content'     => '
                <!-- wp:group {"layout":{"type":"flex","justifyContent":"space-between","flexWrap":"wrap"}} -->
                <div class="wp-block-group">
                    <!-- wp:post-author-name /-->
                    <!-- wp:post-date /-->
                    <!-- wp:paragraph {"fontSize":"xs"} -->
                    <p>Reviewed and published under editorial workflow.</p>
                    <!-- /wp:paragraph -->
                </div>
                <!-- /wp:group -->
            ',
        )
    );
} );

AI capability registration and governance hooks

If your minimum supported version is 6.9+, expose AI-manageable operations as Abilities. If you must support older versions, keep the same schemas and wrap them in a compatibility layer, but do not invent a second long-term contract. The example below shows the right pattern: permission callback, JSON-schema boundaries, allowlisted file scope, pre/post execution hooks, and no direct raw write surface.

<?php
/**
 * Bridge plugin: register an allowlisted theme asset update ability.
 */

add_action( 'wp_abilities_api_categories_init', function () {
    wp_register_ability_category(
        'theme-governance',
        array(
            'label'       => __( 'Theme Governance', 'ai-foundry' ),
            'description' => __( 'Governed theme editing abilities with audit and approval.', 'ai-foundry' ),
        )
    );
} );

add_action( 'wp_abilities_api_init', function () {
    wp_register_ability(
        'ai-foundry/propose-theme-asset-update',
        array(
            'label'        => __( 'Propose Theme Asset Update', 'ai-foundry' ),
            'description'  => __( 'Creates a proposal to update an allowlisted theme asset.', 'ai-foundry' ),
            'category'     => 'theme-governance',
            'input_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'path' => array(
                        'type'        => 'string',
                        'pattern'     => '^(theme\\.json|templates\\/.+\\.html|parts\\/.+\\.html|patterns\\/.+\\.php|assets\\/src\\/.+\\.css)$',
                        'description' => 'Allowlisted relative theme path.',
                    ),
                    'proposed_content' => array(
                        'type'        => 'string',
                        'minLength'   => 1,
                        'description' => 'Full proposed file content.',
                    ),
                    'summary' => array(
                        'type'        => 'string',
                        'minLength'   => 8,
                        'maxLength'   => 500,
                        'description' => 'Human-readable explanation of the change.',
                    ),
                    'requires_approval' => array(
                        'type'    => 'boolean',
                        'default' => true,
                    ),
                ),
                'required' => array( 'path', 'proposed_content', 'summary' ),
            ),
            'output_schema' => array(
                'type'       => 'object',
                'properties' => array(
                    'proposal_id' => array( 'type' => 'integer' ),
                    'status'      => array( 'type' => 'string', 'enum' => array( 'pending_approval', 'rejected', 'applied' ) ),
                    'diff'        => array( 'type' => 'string' ),
                ),
                'required' => array( 'proposal_id', 'status', 'diff' ),
            ),
            'permission_callback' => function () {
                return current_user_can( 'edit_theme_options' );
            },
            'execute_callback' => function ( $input ) {
                $path = $input['path'];

                if ( ! ai_foundry_is_allowlisted_theme_path( $path ) ) {
                    return new WP_Error(
                        'forbidden_path',
                        __( 'Requested path is not writable by policy.', 'ai-foundry' ),
                    );
                }

                $current = ai_foundry_get_theme_asset_contents( $path );
                $diff    = ai_foundry_generate_diff( $current, $input['proposed_content'] );

                $proposal_id = ai_foundry_store_proposal( array(
                    'path'              => $path,
                    'summary'           => sanitize_text_field( $input['summary'] ),
                    'proposed_content'  => $input['proposed_content'],
                    'diff'              => $diff,
                    'actor'             => get_current_user_id(),
                    'requires_approval' => (bool) ( $input['requires_approval'] ?? true ),
                ) );

                return array(
                    'proposal_id' => (int) $proposal_id,
                    'status'      => 'pending_approval',
                    'diff'        => $diff,
                );
            },
            'meta' => array(
                'show_in_rest' => true,
            ),
        )
    );
} );

add_action( 'wp_before_execute_ability', function ( $ability, $input ) {
    ai_foundry_audit_event( 'ability.before', array(
        'ability' => method_exists( $ability, 'get_name' ) ? $ability->get_name() : 'unknown',
        'input'   => ai_foundry_redact_sensitive_fields( $input ),
    ) );
}, 10, 2 );

add_action( 'wp_after_execute_ability', function ( $ability, $result ) {
    ai_foundry_audit_event( 'ability.after', array(
        'ability' => method_exists( $ability, 'get_name' ) ? $ability->get_name() : 'unknown',
        'result'  => ai_foundry_redact_sensitive_fields( $result ),
    ) );
}, 10, 2 );

Human-in-the-loop prompt and data-flow contract

For AI-human collaboration, do not send the whole theme or database to a model. Send task-scoped context packs. This is the minimum safe contract I would use:

SYSTEM CONTRACT
- You may read only the supplied theme manifest, template map, pattern inventory, and relevant content objects.
- For write operations, you must produce:
  1) impact summary
  2) affected files/objects
  3) structured diff plan
  4) validation checklist
  5) rollback note
- Never propose edits outside allowlisted paths.
- Treat checkout, payments, authentication, personal data, and legal pages as approval-required.
- Prefer existing patterns, tokens, and style variations over bespoke CSS.
- If the request would change multiple surfaces, separate content changes from design-system changes.

HUMAN APPROVAL GATE
- Require explicit approval when:
  - editing theme.json
  - editing checkout/cart templates
  - changing navigation, redirects, canonicals, hreflang, robots, or structured data
  - touching any CSS or template affecting >1 template
  - introducing third-party scripts or outbound calls

PROVENANCE RECORD
- actor
- model
- prompt hash
- context pack hash
- proposal id
- approved by
- validation results
- applied commit / artifact / rollback bundle id

Recommended tooling and official sources

The toolchain below is the most defensible baseline for your stated goals because it stays close to WordPress core conventions, gives you measurable release quality, and supports provenance and AI governance without over-customizing the stack.

Opinionated product recommendations

If you want a short practical shortlist rather than an exhaustive marketplace survey, I would standardize on the following combination: WordPress 6.9.x latest patch, a block-theme-first AI Foundry parent theme, WooCommerce block templates, @wordpress/scripts, @wordpress/env, WPCS, Plugin Check, Playwright, axe-core, Lighthouse CI, and GitHub Actions artifacts/attestations. That is enough to deliver a premium editor experience, strong QA, and governed AI collaboration without introducing unnecessary platform sprawl.

Open questions and limitations

Because the production site details were intentionally unspecified, this report does not claim exact pass/fail status for your live Go stack. It instead provides a standards-based audit framework anchored to your Intent Packet and current official WordPress, WooCommerce, W3C, and Google docs. The highest-confidence unknowns are: the exact Go theme version in production, your currently active WordPress/WooCommerce versions, whether Cart/Checkout are already block-based, how much logic currently lives in the Customizer or child-theme overrides, and which external AI providers you intend to authorize for content or theme operations. Those answers would change prioritization details, but not the main conclusion: your platform should converge on a premium block theme with governed Abilities-driven AI management, using Go only as a parity benchmark, not as the long-term center of gravity.