Authoring workflow: prove the small model contract through the shipped guide

[noeltock]

Problem

A canonical plan from an expert-authored fixture proves compiler feasibility. It does not prove that a caller can produce that plan through the shipped instructions, or that the resulting block delivers the requested editing experience. The latest two fresh authoring attempts reached no canonical plan despite passing candidate CI.

The next step is a controlled test of a complete proposal contract. Retain author() → canonical plan → preview/confirmation/write → plugin/proof. Do not introduce a second translator or move native-tree selection into core on the strength of these two failures.

Current state and evidence

Reviewed on 7 September 2026:

• Authoring: let Block Runner own source binding and bookkeeping #62 / PR Authoring: let Block Runner own source binding and bookkeeping #66, Authoring: adapt source styles to native WordPress markup in core #63 / PR Authoring: adapt source styles to native WordPress markup in core #67 and Authoring: return actionable source-located decisions for unresolved mappings #64 / PR Report actionable authoring diagnostics without exposing internal bookkeeping #68 are merged. Main is 410ac4dbf7cde97f1894f108cb3f95a09a60caa6.
• PR Prove proposal authoring through the shipped guide and source-bound runtime #69 is draft at 9680c5cc66bf17a3f803cf2eff4ddd75d41bdbf5. Its five exact-head CI jobs passed: Node 20/22/24 verification, packed-package boundary and WordPress proof. That does not establish model-generated artifact acceptance.
• The candidate already includes proposal-first instructions, an installed-package runnable example, self-contained utility/hero-handoff.html with CSS/SVG, complete fixed-proposal hero compilation, and the restored production-gated authoring runtime worker/scorer. Reconcile Prove proposal authoring through the shipped guide and source-bound runtime #69; do not recreate these pieces from an older checkout.
• The complete hero test currently declares only the heading editable. Authoring guide: define the complete proposal workflow #70 extends it to the actual requested fields before further usability work.
• Historical five-fixture saved-plan WordPress successes are useful feasibility evidence from a different candidate. They are not fresh model outputs or release certification. Manual acceptance remains separate.

Fresh trials on the same frozen candidate

Each row is one fresh execution with at most three distinct submissions, diagnostic-guided corrections, no expected plan exposure and no caller repair. These are two models on one fixture, not a reliability benchmark.

Runtime	Submission 1	Submission 2	Submission 3	Outcome
gpt-5.6-luna, low	Figure bound to Group	Numeric image dimension rejected against source string	Group contains direct Buttons; first blocker reports CSS grid ownership for flex	No canonical plan
gpt-5.6-sol, low	Node label rejected	Figure bound to Column	Authored grid bound to Columns	No canonical plan

The Sol report also contains an intermediate caption Custom HTML warning from convert(). Figure-bound Image derives its caption; no final generated package existed, so that warning does not establish final caption loss. The supported Columns/grid rejection must stay intact.

The guide's advanced complete-plan schema permits node label, and later page-content guidance recommends Columns. The proposal route has different requirements. Instruction contamination is plausible; these findings do not prove it is the only cause. The three-submission cap is an experimental bound, not a known natural completion limit.

Work sequence

Order	Work	Boundary
1	#70: complete the proposal-only instructions and deterministic editing-field proof	Keep runtime/compiler behaviour unchanged.
2	This issue: one newly authorised instruction-only usability trial	Same compiler, source, prompt semantics, harness, model effort, submission limit and thresholds.
3	If successful, prove the exact generated artifact in WordPress	Preserve that artifact; #54/#55 retain the wider acceptance and release scopes.
4	#71: narrow dimension equivalence; #72: actionable proposal/stage diagnostics	Keep these runtime changes out of the controlled baseline; integrate separately after its result is recorded, with checks for the affected behaviour.

The model continues to choose native structure, source bindings and editing intent. Core transports facts and implements the chosen primitives. Automatic wrapper synthesis or another semantic layer requires new evidence and a separate scope; it is not the default next fix.

Controlled experiment

First finish #70 and its packed example/full-field checks. Freeze a candidate whose executable compiler matches 9680c5c; instruction files and their normal package/hash metadata may change. Record executable file hashes separately from instruction hashes so a new tarball does not conceal a runtime change. If unrelated implementation has landed, preserve an isolated baseline instead of silently testing a different compiler.

Use one fresh gpt-5.6-luna low execution to compare with the original low-cost attempt. An issue assignment does not authorise the paid run: record explicit model scope before starting. Maximum three distinct proposals within that execution; no unchanged resubmission. Stop at the first unexplained failure, the third rejection, or canonical-plan success. Do not upgrade the model, extend the limit, repair the compiler or rerun during this comparison.

The supplied input remains benchmarks/authoring/sources/utility/hero-handoff.html, hero.css and assets/aurora-dashboard.svg. The source and supported options are public and self-contained. Use supplied CSS mode and explicit foundation: "component", the existing source/asset root, and the same target identity. Do not infer Tailwind utilities or fetch replacement assets.

The caller receives only source, the updated shipped instructions and supported options. It must expose editable eyebrow, heading, body, both CTA texts, product image and alt text; preserve both links, caption, content/assets, mobile copy-before-image ordering, layout and hover/focus behaviour. Do not supply the golden proposal, repaired plans, repository tests, compiler implementation or previous attempts. The worked documentation example must be a different design.

Use the existing public collectSourceEvidence() / packed author() boundary: analysis returns source evidence and options; each submitted proposal goes unchanged into author(html, { sourcePath, assetRoot, author: { name, title, styles: { mode: "css", css, foundation: "component" } }, proposal }). Save the raw proposal and report before any next submission. Only report.ok && report.package?.canonicalPlan counts as proposal success. Do not hand-assemble coverage, hashes, mandatory warning strings or native adapter CSS.

Reuse these entry points

• skills/block-runner/SKILL.md, skills/block-runner/references/GUIDE.md and scripts/smoke-packed-cli.mjs: installed instruction example and package boundary.
• test/author.proposal.test.ts, test/author.native-style-adapters.test.ts, test/author.diagnostics.test.ts: already cover proposal binding, source retention, native adaptation, deterministic output and tamper rejection. Authoring guide: define the complete proposal workflow #70 adds the complete editable-field case.
• scripts/authoring-runner.ts, scripts/authoring-runtime-worker.cjs, scripts/authoring-runtime-style-contract.ts, scripts/authoring/score.ts: production materialisation and existing runtime/scoring contract from Prove proposal authoring through the shipped guide and source-bound runtime #69. Preserve the production author gate.
• scripts/build-pattern-overrides-fixture.ts, scripts/proof-playwright.mjs, test/proof-real-wordpress.test.ts, proof/wp-env.json: generated package, real WordPress 7.1, editing/save/reopen and pattern proof. Preserve viewport thresholds and approved upstream exceptions.

Pin the supported Node version from the candidate package.json; reuse its installed dependencies and packed artifact. No new orchestration layer or full benchmark matrix is needed. Run required integration checks once after implementation stabilises; do not repeat them for reporting-only edits.

Acceptance criteria and retained evidence

• Authoring guide: define the complete proposal workflow #70 establishes a runnable packed proposal example and expert-authored feasibility for all requested editable fields without omission decisions.
• Before the model starts, record revision, packed artifact, executable/instruction/source/harness/scorer/environment hashes, actual model/effort, task prompt and the authorised limit.
• Preserve raw model output, raw distinct proposals, diagnostics, command history, timestamps and caller interventions. Verify frozen inputs remained unchanged; report infrastructure failure separately from a proposal rejection.
• A failed controlled attempt stops with a specific diagnosis and explicit next decision. It remains a valid recorded experiment, but does not close the overall usability requirement or authorise another attempt.
• If successful, use that exact canonical plan for the existing preview/confirmation/write and generated plugin path. Required write confirmation remains attached to the final canonical identity; never count a repaired plan as model success.
• Verify the exact model-generated artifact in WordPress: native editing for every requested field, save/reopen, content/links/assets/caption, responsive layout, hover/focus and applicable pattern overrides. Package generation alone is not completion.
• Report model usability, deterministic compiler checks, runtime proof and manual acceptance separately. One success proves this attempt, not model reliability or release readiness.

A further collection-editing or pattern-override usability case needs separately authorised scope after the hero succeeds; no automatic expansion to the remaining corpus. #54 owns wider supplied-design acceptance and #55 release guidance/publication readiness. Keep this issue and #69 incomplete until the missing usability/runtime evidence is established. No npm publication is authorised by this issue.