This file is auto-generated from decisions.jsonl. Edit records there, then run /playbook-render.
| ID | Title | Status | Date |
|---|---|---|---|
| DEC-001 | Accept explicit equivalent benchmark trees | accepted | 2026-09-02 |
| DEC-002 | Use one canonical cross-harness skill bundle | accepted | 2026-09-02 |
| DEC-003 | Generate one registered block per input design | accepted | 2026-09-03 |
| DEC-004 | Make registered-block authoring the 0.9 preview | accepted | 2026-09-03 |
| DEC-006 | Keep live model benchmarks explicitly scoped | accepted | 2026-09-04 |
| DEC-007 | Keep native WordPress editor behavior with evidence-bound testing exceptions | accepted | 2026-09-04 |
| DEC-005 | Retain a narrow WordPress editor exception for 0.9 testing | superseded | 2026-09-04 |
Status: accepted Date: 2026-09-02
A single exact expected tree produced false negatives when authored HTML visibly justified an extra stat-card or download-card group. Ignoring group wrappers globally would hide genuine missing-card regressions in pricing, feature, and bento layouts.
A benchmark spec may list a small number of explicit acceptedTrees. Each entry is a complete reviewed tree, is available to every producer and engine, and is scored with the same structure and attribute assertions as the canonical tree. Producer-specific branches and global wrapper forgiveness are prohibited.
Source-driven equivalent structures can score correctly without weakening strict container requirements elsewhere. Review pages must display every accepted tree, suite hashes must include them, and fixture authors must justify each alternative as contract-permitted ambiguity rather than use it to rescue one model output.
Status: accepted Date: 2026-09-02
The shipped skill source lived under a parent directory that did not match its frontmatter name, while the installer defaulted only to Claude Code despite the guide being harness-neutral. Current clients converge on .agents/skills, but Claude Code still documents .claude/skills, and unknown harnesses may use arbitrary roots.
Keep one specification-valid source at skills/block-runner with detailed material under references. The skill installer recursively copies that bundle to project-scoped .agents/skills and .claude/skills by default, supports explicit target, scope, and directory overrides, and never detects models or calls an LLM. Installed runtime commands pin the invoking package version while the explicit update command stays on @latest; managed hashes permit safe updates while local or unmanaged changes require --force.
One npm artifact can serve current cross-agent clients, Claude Code, arbitrary skill roots, and stdout-only harnesses without vendor-specific source forks. The two default installed copies may duplicate bytes, but installation is explicit and deterministic; symlink projection, plugins, lockfiles, and marketplace packaging remain deferred until they solve a demonstrated distribution need.
Status: accepted Date: 2026-09-03
Block Runner currently converts authored HTML into block markup for content placed on a site. A new code-authoring mode could easily drift into batch design-system synthesis, cross-input deduplication, or preservation of transport-layer dependencies such as Tailwind. The intended outcome is narrower: turn one supplied design into one reusable, registered WordPress block that belongs in the destination editor.
Each authoring run takes one exported HTML design plus its assets and produces one named, registered WordPress block source package. Multiple designs remain independent inputs and outputs. Generated blocks use native Block Editor primitives, map styling to WordPress supports and destination tokens where possible, emit scoped CSS where necessary, and require no Tailwind runtime. Pattern overrides are a first-class output requirement. General Block Bindings remain a later extension, but the generated content model must not prevent them.
The first release can optimise for faithful one-to-one block generation and real editor behaviour instead of premature component discovery. Repeated runs may duplicate styles or structure, which is acceptable in this phase. Direct Figma or InDesign ingestion, cross-block deduplication, invented dynamic PHP behaviour, and broad data-binding generation remain out of scope. Acceptance must prove the generated block can build, register, insert, edit, save, reopen, render, and participate in pattern overrides on the target WordPress version.
Status: accepted Date: 2026-09-03
The registered-block authoring work is a material expansion of Block Runner and needs a real testing period before a 1.0 promise. The public website also needs a coherent description of the product after the recent intent-path, skill, benchmark, styling, context, and packaging work; its current rules-only framing is no longer accurate.
Ship the one-design-to-registered-block capability as the defining 0.9 preview on the path to 1.0. Maintain a separate future-state product brief that describes Block Runner assuming the 0.9 requirements are complete, so website design and messaging can be developed against the intended product rather than the current partial implementation.
The 0.9 acceptance gate must cover both implementation quality and a testing-ready product narrative. Forward-looking documentation must label itself as an assumed completed 0.9 state and must not be confused with the current npm release. The rules walker remains an offline path and benchmark control, not the headline definition of Block Runner.
Status: accepted Date: 2026-09-04
Registered-block integration needs regression and WordPress runtime proof, but a new live model benchmark matrix has a separate token and time cost. Preparing benchmark infrastructure must not silently authorize repeated provider runs.
Use deterministic tests, reviewed fixed inputs, and retained runtime evidence first. Run live model benchmarks only within the project owner's current model, effort, and scope authorization; prefer the smallest focused run that can answer an unresolved question. Do not start a provider matrix or tuner loop merely to complete implementation.
Regression and release receipts must state what actually ran. An unrun registered-block model benchmark remains pending and produces no score; historical page-content scores are not evidence for registered-block generation. The current per-model operating restrictions are maintained in the local handover.
Status: accepted Date: 2026-09-04
WordPress 7.1 native Heading and Paragraph editing controls reproduce the same Axe findings without a Block Runner wrapper. The project owner delegated release decisions and prioritized native WordPress compatibility over replacing its editor controls.
Extend the 0.9-testing-only exception to the exact independently reproduced native Paragraph finding alongside the existing Heading findings. Require matching standalone native-control lifecycle evidence, observed WordPress version and immutable evidence hashes. Preserve raw failures and reject unrelated rules, elements, frontend failures or missing review. Keep the original release and mutation gates.
No custom replacement editor is introduced to hide upstream failures. Report the accepted upstream exception explicitly; recheck after WordPress upgrades and before 1.0. This does not waive missing tests, artifact review or unrelated accessibility failures.
Status: superseded Date: 2026-09-04
Axe reports aria-allowed-attr and aria-allowed-role on the WordPress 7.1 native Heading editing surface. A retained control run reproduced both findings with core/heading and no generated Block Runner wrapper, while native insert, edit, save and reopen passed.
Accept these verified upstream native Heading editor findings as an explicit exception for the 0.9 testing release only, as approved by the project owner. Keep the raw accessibility_editor gate failed and retain both control and generated-block evidence. Do not disable the Axe rules or call the full proof profile passed.
Release reporting must identify the accepted upstream exception and archive its evidence. Other elements or findings, frontend accessibility, missing manual review, visual proof and all other release gates remain outside the exception. Recheck on WordPress upgrades and before 1.0; do not carry the exception forward automatically.