Merge remote-tracking branch 'origin/suggest/inline-wiring' into fix/73411-f12-stacked-format-toggle

# Conflicts:
#	packages/editor/CHANGELOG.md

Author: adamsilverstein

.agents/skills/design-system-code-review/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: design-system-code-review
+description: Use when reviewing a Gutenberg change to a WordPress Design System package or its public contract, including `@wordpress/components`, `@wordpress/ui`, or `@wordpress/theme`; do not use to implement the change or review a consumer-only application.
+---
+
+# Review a WordPress Design System contribution
+
+## Establish the review boundary
+
+1. Define the changed public surface and observable behaviour.
+2. Scan the complete diff once, then classify it as:
+   - **Internal:** no public contract or observable behaviour changes.
+   - **Public:** adds, removes, renames, or changes supported behaviour.
+3. Read [Working with WordPress Design System packages](../../../docs/contributors/design/design-system-packages.md)
+   and the applicable package source guidance.
+4. Apply the public guide's evidence precedence: the diff is the proposed
+   post-change state, target source is its baseline, and MCP is supplementary
+   current-design context.
+
+## Review proportionally
+
+For an internal change, verify contract preservation and focused coverage, then
+skip the public-only work below. For a public change:
+
+- assess Gutenberg and external package consumers separately;
+- verify compatibility and migration rather than treating repository migration
+  as sufficient;
+- before drafting findings for a removal, replacement, or rename, compare the
+  old and new accepted values, semantics, states, interaction, and styling in
+  a compact contract table; complete the comparison even after finding one
+  valid defect;
+
+For either classification, use the public guide's
+[package completion gate](../../../docs/contributors/design/design-system-packages.md#change-a-package-safely)
+and inspect only the surfaces applicable to the change.
+
+Use browser evidence when source or class assertions cannot establish visual,
+focus, motion, or layout parity.
+
+## Finding evidence gate
+
+Before reporting a finding, identify the exact changed line, affected public
+contract or behaviour, target-source or consumer evidence, and concrete impact.
+Treat incomplete diff context as a verification gap unless the complete patch
+proves the defect. Apply the same evidence and precision standard even when
+another valid defect already exists.
+
+## Output contract
+
+Recheck every finding against the complete diff and source. Separate defects,
+verification gaps, and optional follow-ups. Report material findings with
+proportional severity and the smallest coherent direction; report no findings
+when the evidence exposes none.

.agents/skills/design-system-contribution/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: design-system-contribution
+description: Use when planning or implementing a safe `@wordpress/components`, `@wordpress/ui`, or `@wordpress/theme` change in a local Gutenberg checkout; do not use for consumer-only application changes or infer commit, push, or pull-request authority.
+---
+
+# Contribute to the WordPress Design System
+
+## Classify the change
+
+1. State the requested outcome and relevant package or consumers.
+2. Classify the change as internal or public:
+   - **Internal:** preserves the public contract and observable behaviour.
+   - **Public:** adds or changes supported behaviour.
+3. For a public change, state the missing behaviour and audit existing public
+   composition and similar components or tokens.
+4. If supported behaviour already meets the public need, recommend it and stop
+   unless the request establishes a distinct contract.
+
+Read the cross-package guide and the package-specific source guidance that
+matches the change:
+
+- [`docs/contributors/design/design-system-packages.md`](../../../docs/contributors/design/design-system-packages.md)
+- [`packages/components/CONTRIBUTING.md`](../../../packages/components/CONTRIBUTING.md)
+- [`packages/ui/CONTRIBUTING.md`](../../../packages/ui/CONTRIBUTING.md)
+- [`packages/theme/README.md`](../../../packages/theme/README.md)
+- [`packages/theme/tokens/README.md`](../../../packages/theme/tokens/README.md)
+
+Use an available WordPress Design System MCP server to learn current direction
+when useful, but verify implementation and compatibility against this checkout.
+
+## Scale work to the contract
+
+- For an internal change, preserve the public contract and run focused checks.
+- For a public change, define the contract and assess external consumers,
+  compatibility, migration, documentation, and generated output.
+- For a replacement or rename, compare observable old and new values, states,
+  and interaction—not only types or class names.
+
+Follow current package precedents only where they apply. Do not add optional
+stories, public documentation, release notes, or compatibility machinery for
+an unchanged public capability. Still follow the repository's required package
+changelog policy for production code changes.
+
+## Finish
+
+Use the public guide's
+[package completion gate](../../../docs/contributors/design/design-system-packages.md#change-a-package-safely)
+with the applicable package source guidance. Mark each relevant contract
+surface complete, not applicable, or blocked.
+
+Run focused tests and required lint, type, generation, or build checks. Verify
+interaction or CSS behaviour where source-level tests cannot establish it.
+
+Stop for product or design-system agreement when a public component, token, or
+API lacks accepted behaviour. Include consumer evidence, alternatives,
+compatibility impact, and the proposed contract.

.agents/skills/design-system-ui-composition/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: design-system-ui-composition
+description: Use when building or changing a Gutenberg feature, plugin interface, or standalone application UI with public `@wordpress/components`, `@wordpress/ui`, or `@wordpress/theme` APIs, including when the code does not yet use the Design System; do not use to change package source or depend on package-private implementation details.
+---
+
+# Compose a WordPress Design System interface
+
+## Classify before searching
+
+1. State the user-visible behaviour, minimum runtime and package versions,
+   rendering owner, runtime document, and whether each Design System dependency
+   is bundled or externalized.
+2. Inspect the changed surface and its nearest same-surface precedent once.
+3. Choose the narrowest path:
+   - **Lightweight:** keep an existing supported component when behaviour,
+     styling, and document setup do not change.
+   - **Standard:** select or compose a public component or token.
+   - **Deep:** handle custom UI, a package migration, or another rendering
+     document such as an iframe, popup, or portal.
+
+Do not reopen component selection on the lightweight path. Verify the existing
+contract, make the narrow change, and stop.
+
+## Select for the behaviour
+
+When selection is material, write the required interaction contract before
+choosing a component. Follow the maintained recommendation sources and
+target-version checks in
+[Working with WordPress Design System packages](../../../docs/contributors/design/design-system-packages.md#choose-a-recommended-component),
+then verify the selected public API in the deployed runtime or installed
+version, as applicable.
+
+Choose the smallest public composition that owns exactly the required
+behaviour. Do not turn a trigger into a menu, dialog, or state owner merely
+because a nearby precedent does. Stop searching when one recommended option
+satisfies the behaviour and setup.
+
+## Apply conditional setup
+
+- For custom UI, first establish why public composition is insufficient.
+- For a migration, preserve observable interaction, styling, accessibility,
+  and compatibility.
+- For a separate document, read the
+  [cross-package document setup guidance](../../../docs/contributors/design/design-system-packages.md#setup-depends-on-the-document)
+  before editing. Make a short per-document ledger for the packages actually
+  used: static styles, runtime-injected styles, root theming, and overlays.
+  Mark each applicable requirement verified or blocked; do not add setup for a
+  package that does not render there.
+
+For a planning task with no concrete host file or state owner, keep the plan
+actionable under explicit assumptions. When the request names a target, inspect
+that exact target; do not silently plan against another package or active
+equivalent. Treat missing context as a verification gap; block only when it
+prevents a safe behaviour or API decision.
+
+Use the linked public documentation for API and setup facts. Do not copy its
+component mappings, token inventory, or implementation recipes into this
+skill.
+
+## Finish
+
+Exercise the changed interaction and run focused checks. Before declaring
+completion, recheck the behaviour contract and every rendering document.
+Report unresolved setup or parity evidence as blocked rather than silently
+omitting it.
+
+If no public API meets the need, document the unmet behaviour and affected
+consumers. Route package work to `design-system-contribution` in a local
+Gutenberg checkout; otherwise request an upstream Design System change.

.agents/skills/design-system-ui-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: design-system-ui-review
+description: Use when reviewing a Gutenberg, plugin, or application UI/UX change for correct public WordPress Design System usage and user-facing behaviour, including a component, control, visual styling, token, interaction, layout, overlay, or other user-facing interface; do not use to implement a change or review Design System package source.
+---
+
+# Review a WordPress Design System interface
+
+## Start shallow
+
+1. Define the changed user-facing behaviour, affected users, runtime document,
+   target versions, and dependency deployment boundary.
+2. Scan the complete diff once for semantics and accessibility, interaction
+   and focus, styling and tokens, integration, tests, and compatibility.
+   Account for every changed file before deep research; finding one defect
+   does not end this pass.
+3. Choose the narrowest review path:
+   - **Lightweight:** copy-only or supported-prop changes with no interaction,
+     styling, or setup change.
+   - **Standard:** component, custom UI, styling, or interaction changes.
+   - **Deep:** migrations, public-contract risk, or separate documents and
+     overlays.
+
+On the lightweight path, verify the target runtime API, every changed consumer,
+and required changelog coverage. State what the change improves and what
+behaviour and semantics remain unchanged, then stop. Do not reopen component selection
+without evidence that the existing component is unsuitable.
+
+## Deepen only material questions
+
+Use the recommendation sources in
+[Working with WordPress Design System packages](../../../docs/contributors/design/design-system-packages.md#choose-a-recommended-component)
+only when component, package, prop, token, or setup selection is material.
+Apply that guide's evidence precedence: treat the supplied diff as the proposed
+post-change state, verify availability against the target version, and use MCP
+as current-direction context rather than target-version proof.
+
+For standard and deep reviews, investigate only the dimensions made material
+by the first pass. Judge custom UI by demonstrated user, accessibility,
+consistency, or maintenance impact—not by the mere existence of a public
+alternative. For separate documents, verify the applicable package setup in
+the document that renders the interface.
+
+When custom UI has a material defect, explicitly decide whether the smallest
+coherent fix is to repair it or replace it with a verified public component.
+Do not leave the implementation direction implicit.
+
+## Finding evidence gate
+
+Before reporting a finding, establish:
+
+1. the incorrect user-observable behaviour or public contract;
+2. the exact changed line that causes it;
+3. target-version source or runtime evidence for the expected behaviour; and
+4. why the change is required now rather than an optional enhancement.
+
+If any part is missing, resolve it, report a verification gap, or omit the
+finding. Treat missing context in a diff excerpt as a gap unless the complete
+diff proves an omission. Missing tests alone are not a defect without a
+demonstrated regression or repository requirement.
+
+## Output contract
+
+Recheck every finding against the complete diff and source. Classify each
+concern as a defect, verification gap, or optional follow-up. Report material
+findings with user impact, target evidence, and the smallest coherent
+direction, plus focused verification of the affected behaviour. Report no
+findings when the evidence exposes none. Do not prescribe package internals in
+a consumer review. Route package-source reviews to
+`design-system-code-review`, then stop.

.github/workflows/bundle-size.yml

@@ -74,4 +74,4 @@ jobs:
                   repo-token: '${{ secrets.GITHUB_TOKEN }}'
                   pattern: '{build/scripts/**/*.min.js,build/styles/**/*.css,build/modules/**/*.min.js}'
                   clean-script: 'distclean'
-                  build-script: 'build -- --skip-types'
+                  build-script: 'build'

.github/workflows/end2end-test.yml

@@ -38,7 +38,7 @@ jobs:
               uses: ./.github/setup-node
 
             - name: Npm build
-              run: npm run build -- --skip-types
+              run: npm run build
 
             # Wider than the `build*` directories, because the build also emits
             # generated files next to sources: the block parsers, the icon

.github/workflows/reusable-workflow-lint.yml

@@ -51,15 +51,15 @@ jobs:
                   persist-credentials: false
 
             - name: Install the latest version of uv
-              uses: astral-sh/setup-uv@c771a70e6277c0a99b617c7a806ffedaca235ff9 # v9.0.0
+              uses: astral-sh/setup-uv@ae62891fec2bb8e7d6c99fc78c9fec3a63790f8d # v10.0.0
 
             - name: Run zizmor
               run: uvx zizmor@1.24.1 --persona=regular --format=sarif --strict-collection . > results.sarif
               env:
                   GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
             - name: Upload SARIF file
-              uses: github/codeql-action/upload-sarif@d1ba80a13dd99fba24a470575428917156a28b43 # v4.37.5
+              uses: github/codeql-action/upload-sarif@5595ccaf912efad79be6eef63a5619ff05969be3 # v4.37.6
               with:
                   sarif_file: results.sarif
                   category: zizmor

.github/workflows/static-checks.yml

@@ -115,6 +115,14 @@ jobs:
                   npm run lint:css:update-suppressions
 
             - name: Type checking
+              run: npm run typecheck
+
+            - name: Check type declaration files
+              # Runs against the declarations the type check just emitted;
+              # the bundle build below skips types and with them this check.
+              run: npm run check:type-declarations
+
+            - name: Build packages
               run: npm run build
 
             - name: Validate package contents

.github/workflows/unit-test.yml

@@ -209,7 +209,7 @@ jobs:
               uses: ./.github/setup-node
 
             - name: Run build scripts
-              run: npm run build -- --skip-types
+              run: npm run build
 
             - name: Upload built JavaScript assets
               uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1

AGENTS.md

@@ -11,13 +11,15 @@ npm run wp-env-test start       # Only start if not already running.
 
 # Development
 npm start     # Development with watch
-npm run build # Production build
-npm run build -- --skip-types # Faster build; skips type generation
+npm run build # Production build; emits types with --noCheck, does NOT type check
 ```
 
+`npm run build` never fails on type errors. After changing TypeScript or checked JS, run `npm run typecheck`.
+
 ### Key Directories
 
 -   `/packages/` - JavaScript packages (each has README.md and CHANGELOG.md)
+-   `/routes/` - Route entry points for the admin single-page apps, one directory per route; each declares the page(s) it belongs to (the extensible site editor, the dashboard, the media editor, and others)
 -   `/lib/` - PHP code
 -   `/lib/compat/wordpress-X.Y/` - Version-specific features (new PHP features usually go here)
 -   `/phpunit/` - PHP tests
@@ -41,6 +43,7 @@ Read only what your task needs, when it needs it:
 ```bash
 npm run format            # Fix JS formatting
 npm run lint:js          # Check JS linting
+npm run typecheck        # Type check sources, plus TypeScript tests and stories
 vendor/bin/phpcbf        # Fix PHP standards
 vendor/bin/phpcs         # Check PHP standards
 
@@ -51,6 +54,7 @@ vendor/bin/phpcbf <path_to_php_file.php>
 ## Architectural decisions
 
 -   **Package layering**: Three editor layers — `block-editor` (generic, WP-agnostic) → `editor` (WordPress post-type-aware) → `edit-post`/`edit-site` (full screens). Lower layers MUST NOT depend on higher ones.
+-   **Site editor parity**: the site editor exists twice — `packages/edit-site` (v1) and the extensible site editor (v2: the `routes/*` entry points declaring the `site-editor-v2` page, booted by `packages/boot`, behind the `gutenberg-extensible-site-editor` experiment). Any feature or enhancement added to the site editor MUST be added to the extensible site editor in the same change, so the two do not drift. If a feature deliberately does not belong in v2, say so explicitly instead of silently skipping it.
 -   **Block data model**: Blocks are in-memory tree structures during editing, serialized as HTML with comment delimiters (`<!-- wp:name -->`). Work with the block tree via APIs, not the serialized HTML.
 -   **Data layer**: Uses `@wordpress/data` (Redux-like stores). Edit entities through `core-data` actions (`editEntityRecord` / `saveEditedEntityRecord`), not direct state manipulation.
 -   **Styles system**: Three-layer merge — WordPress defaults < `theme.json` < user preferences. Use Block Supports API and CSS custom properties (`--wp--preset--*`), not hardcoded values.
@@ -69,6 +73,7 @@ For full architecture details, see `docs/explanations/architecture/`.
 -   Never invoke WordPress's forked or local CLIs through `npx` (e.g. `npx prettier`, `npx wp-scripts`). WordPress ships its own `wp-prettier` fork, and `wp-scripts` is the bin name of `@wordpress/scripts`. A bare `npx wp-scripts` can resolve to an unrelated third-party package on the public registry, not the local tool. Use the npm scripts instead (`npm run format`, `npm run lint:js`, `npm run lint:css` and so on), which run the binaries from local `node_modules`.
 -   PHP function and class names are renamed at build time (`gutenberg_*` prefix, `*_Gutenberg` suffix) to avoid conflicts with WordPress Core — the built names, not the source names, are what runs (and what tests must call). See `docs/contributors/code/build-system-function-prefixing.md`.
 -   Production code changes in a package require an entry in that package's `CHANGELOG.md`. See `docs/contributors/code/managing-packages.md`.
+-   Packages with TypeScript dev files split their configs: `tsconfig.build.json` (src only, emits `build-types`) and the default `tsconfig.json` (dev project: tests and stories, `noEmit`, jest types). Packages without dev files keep a single `tsconfig.json` build project, and a few packages deviate (a dev-only project with handwritten declarations, or specialized build projects); see the TypeScript section in `packages/README.md`. Reference a split package by `../<pkg>/tsconfig.build.json` and an unsplit one by `../<pkg>`. `npm run build` never type checks (it emits declarations with `--noCheck`); use `npm run typecheck`, and never add jest types to a build project.
 -   A rejected `apiFetch` is not always an `Error`: a REST error arrives as a plain object (`{ code, message, data }`), `parse: false` rejects with the `Response` (which carries `status`, not `message`), an aborted request rethrows an `AbortError`, and a handler set via `setFetchHandler` can reject anything. Do not interpolate the rejection into a string (`` `${ error }` `` gives `[object Object]`) or branch on `instanceof Error`. Normalise it to a message before showing the user anything, and supply your own copy when there is none — `ensureError` in `packages/core-data/src/private-actions.js` is the reference implementation, though it is local to that file rather than exported.
 
 ## PR instructions