0.9 acceptance: prepare two complete workflows before owner testing

[noeltock]

Problem

Repeatedly asking the release owner to run a full manual checklist after each implementation change makes the closeout expensive. Existing fixture evidence also does not establish that a normal agent-assisted session can carry an unfamiliar authored design through to a usable installed block.

Solution

After cleanup is integrated, run two bounded end-to-end acceptance journeys and prepare one candidate for owner review. Use a straightforward authored design and a more demanding responsive design with local assets, selected from available, appropriately licensed inputs. Record setup and plan corrections instead of hiding them.

Acceptance criteria

• Pin the candidate revision and use its packed CLI and shipped skill in a clean consumer project.
• Carry each supplied design through source inspection, native plan, readable preview, authorised confirmation, source generation, build, ZIP installation and ordinary editing on the supported WordPress target.
• Retain input, plan, source package, ZIP, commands, environment, diagnostics and editor/frontend screenshots. Record every manual plan correction and blocked step.
• Verify save/reopen, responsive presentation, asset delivery and fixed/editable behaviour. Exercise two pattern instances, canonical updates and individual resets where overrides are promised.
• Exercise one supported existing-plugin integration and one subsequent generated-source change, including preservation of user-edited content and refusal of incompatible regeneration.
• Run relevant automated gates on the integrated candidate. Raw failures, approved upstream exceptions and human-only checks remain distinguishable.
• Produce a prepared build and a short owner acceptance script focused on fidelity, editing feel and any unresolved judgement. Include working access/setup instructions so the owner does not reconstruct the environment.
• Fixes after acceptance preparation trigger checks for the affected behaviour plus required integration gates. Explain any reason the full human session must be repeated; do not require it by default.

Evidence and scope

Reviewed against 2b26c9d37352f7fb7d1229ee717eaeb1185ff2df on remote main. Recheck current code before implementation; this issue does not claim new tests have passed.

This is two bounded workflow checks, not a scored benchmark or a new corpus. Reuse existing proof tooling. No new orchestration platform, paid model benchmark, production-site changes or release publication. Any model-assisted preparation must follow the existing harness/model authorisation limits.

The owner's 0.9 review remains required. External tester feedback follows 0.9 and informs 1.0; this issue does not require broad compatibility certification before the testing release.

Existing workflow and proof entry points

Reuse skills/block-runner/references/GUIDE.md and the existing CLI sequence: author analysis → canonical plan → author preview/write → plugin preview/write → generated plugin build/ZIP → proof. Authoring source and an installable plugin ZIP are different artifacts; do not stop after the first write.

The source checkout reviewed here was at e642d174, while remote main was already 2b26c9d37352f7fb7d1229ee717eaeb1185ff2df. Build an isolated current candidate or obtain a fresh packed artifact; do not assume local dist or the private September 4 handover describes current code.

The implementation now uses template 0.9-static-v9, with useInnerBlocksProps in the emitted edit/save roots. Older v8 fixture receipts do not certify those bytes.

Reuse:

• scripts/build-pattern-overrides-fixture.ts and test/proof-real-wordpress.test.ts for actual generated ZIP/runtime setup.
• scripts/proof-playwright.mjs, src/proof/runner.ts and src/proof/profiles.ts for existing lifecycle and capability-derived checks.
• test/registered-block.workflow.test.ts, test/authoring.runtime.test.ts, test/authoring.regeneration.test.ts and test/plugin.profile.test.ts for already-implemented workflow, saved-content and package checks.
• proof/reviews/0.9-testing/ and release/0.9-testing/accessibility-exception.md for the narrow native Heading/Paragraph exception. Raw findings must remain visible; it is not a generic accessibility waiver.

What still needs fresh evidence

The representative automated WordPress fixture has already exercised real editing and pattern behaviour. The missing evidence is two ordinary supplied-design journeys using the shipped workflow, including the correction effort required to get a useful plan. Do not simply rerun the golden fixture twice and call that real-design acceptance.

Select accessible authored HTML/assets first. Do not scrape frontend WordPress markup, claim native Figma ingestion, or invent that two suitable real-project inputs are already available. If a needed input or test destination is missing, specify that exact dependency; the owner's future acceptance session should not be used to perform agent setup work.

Regeneration already classifies new-package, unchanged, style-only, content-defaults and saved-markup-or-structure. New defaults do not migrate saved instances; structural replacement is refused without a new identity or tested migration. Exercise those existing semantics rather than building migration machinery.

Handoff contents

One candidate index should link the packed package, both inputs/plans, both prepared outputs, runtime evidence, setup/access instructions and a short known-limitations list. Include a proposed time budget for the human session and the specific decisions only a human should make. Keep an affected-behaviour checklist for any later fix. Do not promise zero human retesting if the candidate's editing or appearance changes.

Execution update — 6 September 2026

The host storage and Docker blockers are resolved. Existing containers, images and volumes were preserved. Fresh native Heading and Paragraph controls passed on WordPress 7.1, with edit/save/reopen, Axe and visual artifacts retained.

Acceptance exposed a linked-stylesheet defect: compiled CSS supplied in configuration was also prepared as an image asset. A focused two-file local patch fixes exact local-file matching while retaining dependency evidence and preserving unmatched/symlink rejection. It is not committed or merged. Base revision: 51886e94824360a72162e5efd6013926dd9496b3; patch SHA-256: a377c61e28980d4c2d3caba36b9a7a59603be1d2a80458a7185f8e268e9b3160.

The patched candidate passed 613 tests with four skips (58 files passed, one skipped), build, pack checks, clean packed-consumer installation and shipped-skill installation. The stock verify command was interrupted before completion; the passing bounded-worker suite and individual gate results are recorded separately. Patched package SHA-256: e2a49604c091658da69af5cca2a3c757b557b5a4cc34f379811460ba74983c85. Earlier main CI does not certify this uncommitted patch.

Both repository-authored supplied fixtures now have generated, built, ZIP-checked standalone plugins. Original analysis failures and explicit plan/source corrections are retained. The local SVG matches the source bytes in the production ZIP; the responsive ZIP contains scoped one/two/four-column behavior and reduced-motion CSS. Existing-plugin source integration, unrelated user-file preservation and refusal of incompatible generated-save-markup regeneration passed.

The asset ZIP installs, activates and renders the SVG, text and CTA, with frontend Axe passing. Targeted native-attribute edits to heading, button text/URL and image alt/caption survived save/reload. Original generic field-targeting and empty-stylesheet mismatches remain retained separately. The editor image-caption Axe finding remains open; it is not covered by the Heading/Paragraph exception.

Responsive runtime exposed a topology conflict: native Columns picked up WordPress flex layout, defeating the authored grid. A separately recorded semantic-plan correction uses native Groups while preserving source IDs/hash, fields, styles and coverage. Corrected ZIP SHA-256: 523708647ca962a13fb4da9e4e0e955648b5ef6842076443c7555e5092427fd5. Fresh editor insertion/save/reopen and frontend checks passed: actual grid display, one/two/four columns at 500/640/800/1024/1200px, full-span header, no overflow, reduced motion and readable screenshots. The original failed version is preserved; this is not a saved-content migration. The wrapper has no wide/full alignment control, and the tested theme content width is about 645px.

The shared pattern runtime receipt test passed (one passed, six skipped), retaining raw editor Axe and blocked manual-review gates. Both working review pages and a 20–30 minute owner script are prepared locally. Source-patch integration, the open caption accessibility finding, the final release-matrix receipt and owner acceptance remain outstanding.

This is supplied-fixture evidence, not an unfamiliar real-project claim. No complete final release-matrix receipt, owner fidelity/editing/accessibility acceptance or publication is claimed. A short 20–30 minute owner session is prepared; #54, #55 and #56 remain open until their outstanding gates are accounted for.