ai-delivery-workflow 0.2.2 → 0.4.0

package/skills/ai-delivery-orchestrate/references/formal-state-contract.md

@@ -2,7 +2,7 @@
 
 ## Authority
 
-Portable active task and checkpoint authority is sharded by task under `.workflow/control/tasks/` and `.workflow/control/checkpoints/`. Closed versions move to `.workflow/control/archives/versions/<version-id>/`; normal recovery scans only active collections and explicit audit reads the archive. Local `.workflow/delivery/runtime/` contains only non-portable execution state and optional detailed archive copies.
+Portable active task and checkpoint authority is sharded by task under `.workflow/control/tasks/` and `.workflow/control/checkpoints/`. Closed versions move to `.workflow/control/archives/versions/<version-id>/`; normal recovery scans only active collections and explicit audit reads the archive. The version manifest references checksummed archived task summaries and attempt receipts plus the anchored scope manifest, candidate, Gate decisions, and history anchor. Local `.workflow/delivery/runtime/` contains only non-portable execution state and optional detailed archive copies.
 
 Use `.workflow/tools/state/state.mjs` as the only writer for:
 
@@ -12,8 +12,12 @@ Use `.workflow/tools/state/state.mjs` as the only writer for:
 
 Use `.agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs` as the only writer for runtime task snapshots, checkpoints, recovery state, and version archives. Hooks may append their own redacted lifecycle records but may not infer task, artifact, Gate, node, candidate, release, or deployment completion.
 
+Use the packaged top-level `ai-delivery migrate` command as the only writer for `.workflow/control/migrations/` and compatibility task/layout transformations, `ai-delivery repair` as the only writer for `.workflow/control/repairs/transactions/`, and `ai-delivery compact` as the only writer for `.workflow/control/archives/history/artifact-registry/`. Migration copies legacy-root workflow material into `.workflow/`, adds explicit attempts to flat task shards, and records automatic or checksum-bound human semantic grouping while preserving every source byte, task lifecycle, scope, formal view, and legacy event byte. Archive invalidation is a separate checksum-chained forward transaction that references the original archive, a human actor, reason, RCA evidence, and recovery evidence; the archive itself remains immutable. A migration rollback is legal only while the post-migration schema 2 event and repair fingerprints and every migrated target checksum remain unchanged. Compaction is always a later explicit operation and never part of migration.
+
 Do not edit controlled files directly, including after a command error. Inspect, repair the cause, and rerun with the newly observed revision.
 
+`inspect`, `verify`, Bootstrap diagnostics, Bootstrap artifact generation, and Workflow Manager formal-state reads hold the same formal-state lock as mutations for the full multi-file read. They fail closed when another reader, a mutation, or an incomplete transaction owns the state, and they never recover or take over a stale lock. Only a later mutation or `rebuild` may perform journal recovery.
+
 ## Commands
 
 Run from the project root:
@@ -21,44 +25,85 @@ Run from the project root:
 ```text
 node .workflow/tools/state/state.mjs inspect
 node .workflow/tools/state/state.mjs verify
+node .workflow/tools/state/state.mjs verify --history
+node .workflow/tools/state/state.mjs verify --history --since-anchor
+node .workflow/tools/state/state.mjs snapshot create --id <anchor-id> --reason version-boundary
+node .workflow/tools/state/state.mjs snapshot create --reason configured-interval
+node .workflow/tools/state/state.mjs snapshot references --iteration-id <iteration-id> --candidate-id <candidate-id>
 node .workflow/tools/state/state.mjs rebuild
-node .workflow/tools/state/state.mjs artifact register --expected-revision <revision> --id <artifact-id> --artifact-type <type> --path <.workflow/path> --node <node-id> --status <status> --version <version> --producer-skill <skill>
-node .workflow/tools/state/state.mjs artifact register --expected-revision <revision> --id <new-id> --path <.workflow/path> --node <node-id> --status <status> --supersedes <old-id>
+node .workflow/tools/state/state.mjs artifact register --expected-revision <revision> --id <artifact-id> --artifact-type <type> --path <.workflow/path> --node <node-id> --status submitted --version <version> --producer-skill <skill>
+node .workflow/tools/state/state.mjs artifact register --expected-revision <revision> --id <new-id> --path <.workflow/path> --node <node-id> --status <semantic-status> --supersedes <old-id>
 node .workflow/tools/state/state.mjs artifact status --expected-revision <revision> --id <artifact-id> --status <status> --evidence <reference>
-node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event node-started --iteration-id <iteration-id> --node <node-id>
-node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event release-started --iteration-id <release-id>
-node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event node-completed --iteration-id <iteration-id> --node <node-id> --evidence <artifact-id>
-node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event version-closed --iteration-id <version-id> --artifact-id <closeout-artifact-id>
-node .workflow/tools/state/state.mjs transition --expected-revision <revision> --event release-archived --iteration-id <release-id> --artifact-id <archive-artifact-id> --production-version-id <version-id>
-node .workflow/tools/state/state.mjs gate request --expected-revision <revision> --gate-id <gate-id> --iteration-id <iteration-id> --node <node-id> --evidence <artifact-id>
-node .workflow/tools/state/state.mjs gate decide --expected-revision <revision> --gate-id <gate-id> --decision <decision> --actor <actor-id> --rationale <text> --evidence <artifact-id>
+node .workflow/tools/state/state.mjs artifact compact
+node .workflow/tools/state/state.mjs artifact compact --apply
+node .workflow/tools/state/state.mjs artifact prune
+node .workflow/tools/state/state.mjs artifact prune --apply
+node .workflow/tools/state/state.mjs scope freeze --expected-scope-revision <revision> --iteration-id <iteration-id> --manifest-id <manifest-id> --slice <slice-id> --requirement <requirement-id> --acceptance <acceptance-id> --required-task <node-id>:<task-id> --required-artifact <node-id>:<artifact-id> --approved-by <actor-id> --reason <text>
+node .workflow/tools/state/state.mjs scope amend --expected-scope-revision <revision> --iteration-id <iteration-id> --manifest-id <new-manifest-id> --supersedes <current-manifest-id> --slice <slice-id> --requirement <requirement-id> --acceptance <acceptance-id> --required-task <node-id>:<task-id> --required-artifact <node-id>:<artifact-id> --approved-by <actor-id> --reason <text>
+node .workflow/tools/state/state.mjs scope warn --expected-scope-revision <revision> --iteration-id <iteration-id> --metric <metric> --observed <number> --reason <text>
+node .workflow/tools/state/state.mjs transition --expected-scope-revision <revision> --event node-started --iteration-id <iteration-id> --node <node-id>
+node .workflow/tools/state/state.mjs transition --expected-scope-revision <revision> --event release-started --iteration-id <release-id>
+node .workflow/tools/state/state.mjs transition --expected-scope-revision <revision> --event node-completed --iteration-id <iteration-id> --node <node-id> --evidence <artifact-id>
+node .workflow/tools/state/state.mjs transition --expected-scope-revision <revision> --event version-closed --iteration-id <version-id> --artifact-id <closeout-artifact-id>
+node .workflow/tools/state/state.mjs transition --expected-scope-revision <revision> --event release-archived --iteration-id <release-id> --artifact-id <archive-artifact-id> --production-version-id <version-id>
+node .workflow/tools/state/state.mjs gate request --expected-scope-revision <revision> --gate-id <gate-id> --iteration-id <iteration-id> --node <node-id> --evidence <artifact-id>
+node .workflow/tools/state/state.mjs gate decide --expected-scope-revision <revision> --gate-id <gate-id> --decision <decision> --actor <actor-id> --rationale <text> --evidence <artifact-id>
 ```
 
 Repeat `--evidence` for multiple evidence IDs. Use `iteration-started` only for development and `release-started` only after explicit user release intent. Other events are `node-started`, `node-completed`, `node-blocked`, `node-unblocked`, `candidate-selected`, `release-selected`, `version-closed`, and `release-archived`.
 
-`workflow-state.yaml` schema 2 owns independent `development_state` and `release_state` objects. Each has its own scope ID, revision, node collections, Gate collections, node attempts, and selected identities. The top-level revision remains the serialized audit-stream revision. A release may advance while later cumulative development is active; neither scope resets the other.
+`workflow-state.yaml` schema 2 owns independent `development_state` and `release_state` objects. Each has its own scope ID, revision, node collections, Gate collections, node attempts, and selected identities. Use the owning scope revision for workflow optimistic concurrency. The top-level revision remains the serialized audit-stream revision and is accepted by `--expected-revision` only for compatibility. A release may advance while later cumulative development is active; neither scope resets the other.
+
+`version-closed` requires completed `06-version-closeout` and a registered `release-ready` artifact from that completed node; it is the only writer of `latest_line_version_id`. `release-archived` requires completed `R10-release-archive`, a registered `released` artifact from that node, and `--production-version-id`; it is the only writer of `production_version_id` and `production_release_id`. These identities live in the audited `workflow-state.yaml`; descriptive or legacy compatibility fields in `project.yaml` are not authoritative.
+
+## Seven-Node Producer And Legacy Read Compatibility
+
+The installed `development-seven-node` producer graph is `00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`. Product Shaping owns `GATE-A` and `GATE-B`; Solution Design owns `UX-VS` and `UX-UI`. `development-legacy-13` is read-only compatibility: `inspect`, `verify`, `rebuild`, and explicit migration operations may consume historical records and `inspect.node_contracts` reports both models. Every new legacy task, artifact registration, transition, candidate selection, version closeout, Gate request, and Gate decision is rejected before mutation. Producer Skills request only `development-seven-node` IDs.
+
+`UX-LF` is a retired Gate contract. New `gate request` and `gate decide` writes fail before mutation, while historical decisions and event shards remain readable and verifiable. Package upgrade previews pending `UX-LF` requests in open scopes and applies `contract retire` as a forward `gate-contract-retired` transaction executed only by `system:package-upgrade`. The transaction removes pending requests without adding a Gate decision and appends checksummed `contract_retirement_receipts`; closed iterations, archives, prior decisions, and prior event bytes are never rewritten.
+
+Independent release work continues to use `R00-release-request` through `R10-release-archive`. Older production nodes `12-release-preparation` through `16-version-archive` are accepted only when registering or reading historical artifacts; transition and Gate commands reject them as read-only. Use artifact statuses `release-ready` for a closed unpublished version and `included-in-release` when a specific release has consumed that immutable version manifest.
+
+## Artifact Lifecycle And Retention
 
-`version-closed` requires completed `12-version-closeout` and a registered `release-ready` artifact from that node; it is the only writer of `latest_line_version_id`. `release-archived` requires completed `R10-release-archive`, a registered `released` artifact from that node, and `--production-version-id`; it is the only writer of `production_version_id` and `production_release_id`. These identities live in the audited `workflow-state.yaml`; descriptive or legacy compatibility fields in `project.yaml` are not authoritative.
+`draft` and `review-draft` are mutable working-file statuses and must not be registered. Bootstrap observations, planning inputs, prototypes, and other working drafts remain discoverable through their owning checksummed pointers or manifests until a semantic decision is made. Register only immutable semantic revisions such as `submitted`, `rejected`, `approved`, `frozen`, or `failed`. A later decision or content change creates a new file and artifact ID with `--supersedes`; it never changes a formal revision in place. Supersession is derived from the successor's relation while every predecessor field remains unchanged. `artifact status` is compatibility-only: it may migrate a draft already registered by an older workflow exactly once, with evidence, but refuses every formal revision.
 
-New development work uses nodes `00-bootstrap` through `12-version-closeout`; independent release work uses `R00-release-request` through `R10-release-archive`. Legacy nodes `12-release-preparation` through `16-version-archive` are accepted only when registering or reading historical artifacts; transition and Gate commands reject them as read-only. Use artifact statuses `release-ready` for a closed unpublished version and `included-in-release` when a specific release has consumed that immutable version manifest.
+`artifact prune` uses the latest trusted history anchor as its retention boundary. The default command is a byte-for-byte zero-write dry-run that lists eligible `artifact-registry` shards. Only `--apply` removes shards at or before the anchored artifact revision. Apply writes one checksummed receipt under `.workflow/control/retention/artifact-registry/<anchor-id>.yaml`, retains the JSONL boundary and every post-anchor shard, and rolls staged shards back if the receipt cannot be committed. After pruning, `verify --history` reports `retained-history` and verifies the trusted anchor plus retained suffix; it must not claim that deleted pre-anchor shards were re-audited. `rebuild` starts from the latest trusted snapshots and replays only the retained suffix.
+
+`artifact compact` is separate from retention pruning. The packaged `ai-delivery compact <project> --dry-run` route is byte-for-byte zero-write and reports the latest trusted anchor, legacy full-snapshot revision coverage, a path-and-bytes history-root digest, loose bytes, archive bytes, and expected net freed bytes. Apply packages only anchored legacy `after_value` shards into `.workflow/control/archives/history/artifact-registry/<anchor-id>.json.gz`; its checksummed manifest binds the archive, exact source entries, coverage, anchor, and registry checksum. The CLI validates the written bundle, every original entry, and a full replay before moving loose shards. Any validation failure retains all loose history. After success, `verify --history` reports `compacted-history`, validates and replays the archive, then verifies the anchored suffix. New delta records continue from the anchor's record checksum when the loose directory is empty.
+
+## Frozen Scope And Derived Node State
+
+Delivery Readiness freezes the approved Slice, requirement, acceptance, required-task, and required-artifact sets with `scope freeze`. The first freeze sets `scope_contract_version: 1`; every manifest revision is append-only, SHA-256 checksummed, and explicitly approved. After freeze, `scope amend` is the only scope-change path: it must name the current manifest through `--supersedes`, carry a new manifest ID, and record `--approved-by` plus `--reason`. Historical scopes without `scope_contract_version` remain readable and use the legacy closeout rules until an explicit freeze enables the new contract.
+
+`scope warn` records an exceeded Slice budget for `logical-tasks`, `active-hours`, `wall-clock-hours`, or `blocking-repair-rounds`. Its result is always `action: warn-only` and `reslice_performed: false`; it neither changes the frozen manifest nor automatically replans, reslices, or changes acceptance. A human may separately approve a `scope amend` when a real scope change is intended.
+
+`inspect.derived_node_states` projects each node as `pending`, `active`, `waiting`, `blocked`, `ready-to-complete`, or `completed` from the current manifest, stable task facts, latest append-only blocking findings, mandatory Gate decisions, registered artifacts and checksums, selected immutable candidate, and any completion receipt. Do not write a node state merely because an agent reports progress. For governed planning-through-closeout nodes, `node-completed` is accepted only from `ready-to-complete` and writes an immutable completion receipt that binds the manifest revision/checksum, task and artifact facts, Gate decisions, candidate, blocking-defect set, evidence, and receipt checksum. `verify` rejects tampered manifests or receipts and completed governed nodes without a receipt for the current manifest.
+
+In the seven-node model, `04-implementation` must select an immutable candidate and retain that candidate itself as completion evidence. Starting `05-candidate-assurance` binds the selected candidate to that node attempt; every artifact registered for that node requires `--candidate-id <bound-candidate-id>`, and completion rejects evidence bound to another attempt or candidate. Later `candidate-selected` events do not retarget the active attempt, and its completion receipt retains the bound candidate ID. Starting `06-version-closeout` binds the current candidate and requires a current-scope Candidate Assurance completion receipt for that same candidate.
 
 ## Mutation Order
 
-1. Recover and activate the runtime task.
+1. Run `task-state.mjs inspect` without mutation, recover the recommended task when needed, and activate it with its structured phase before checkpoint or finish. `init` creates queued work only; activation is the only path that starts an attempt and checks dependencies. Queued work cannot skip activation, and phase status is derived rather than accepted through `--phase-status`. Recovery prefers active work, then retryable failed work, then dependency-ready queued work. Preserve the task ID across review, triage, repair, and test rounds; a failed unchanged task starts another attempt only through `--new-attempt`. Finding records are append-only; resolve an existing open finding only in repair/test/verification with evidence and an approved `change_set_id`. Do not complete a task while its latest task-level conclusion contains an open blocking finding. Create a new task only for a material logical-contract change and link it with `--derived-from` or `--supersedes`; a duplicate contract under another ID is invalid.
 2. Write and validate the artifact in `.workflow/`.
 3. Inspect formal state and capture both revisions.
 4. Register the artifact or change its status.
 5. Request and decide every required Gate with explicit actor, rationale, and registered evidence.
-6. Transition the node only after graph prerequisites are satisfied by current-scope completion or successful registered baseline evidence, completion evidence has an allowed success status, mandatory Gates for the current node attempt pass, and no Gate remains pending.
-7. Run `verify`.
-8. Checkpoint or finish the runtime task with the resulting IDs and revisions.
+6. After Delivery Readiness, freeze the approved manifest with `scope freeze`; use only `scope amend` for a human-approved scope change and `scope warn` for a non-mutating budget warning. Read `inspect.derived_node_states` before transition.
+7. Transition the node only after graph prerequisites are satisfied by current-scope completion or successful registered baseline evidence, completion evidence has an allowed success status, mandatory Gates for the current node attempt pass, and no Gate remains pending. Governed nodes must be `ready-to-complete`; the command writes their completion receipt.
+8. Run routine `verify`. At ordinary task safe points, run `snapshot create --reason configured-interval`; it is a no-op until `project.yaml.formal_state_snapshot_interval` events have accumulated. At version closeout, create a version-boundary anchor. Use `verify --history --since-anchor` for the post-anchor chain. Use `verify --history` for full loose history, `compacted-history` when a verified bundle replaces the legacy prefix, and `retained-history` when only a retention receipt remains.
+9. Checkpoint or finish the runtime task with the resulting IDs and revisions.
 
-Every mutation uses optimistic concurrency through `--expected-revision`. A revision conflict means another writer won; inspect and reconcile before choosing a new command.
+Artifact mutations use `--expected-revision`; workflow mutations use `--expected-scope-revision`. Independent development and release commands that were prepared from the same inspection may wait for the current formal transaction and then both commit, because each compares only its owning aggregate. Two writers of the same aggregate fail closed on its revision conflict. Never combine the two revision options. A conflict means another writer won that aggregate; inspect and reconcile before choosing a new command.
 
 ## Integrity
 
-The CLI uses one shared formal-state lock, atomic replacement, SHA-256 artifact checksums, and append-style JSONL audit events. The shared lock serializes both revision streams so concurrent workflow and registry commands cannot overwrite each other's audit append. `verify` checks schemas, revisions, both scope identities, node-state exclusivity, artifact identity and path uniqueness, `.workflow/` path containment, artifact checksums, audit revision continuity, and the last audit checksum for each formal stream.
+The CLI uses one shared formal-state lock, recoverable transactional replacement, SHA-256 artifact checksums, checksummed authoritative event shards, and append-style JSONL audit events. The shared commit section prevents concurrent streams from overwriting each other's audit append; mutation writers wait up to 30 seconds for an identifiable active writer and then re-read and compare their own aggregate. Artifact and workflow mutations use the same schema 2 delta contract: every record carries a transaction ID, idempotency key, before/after stream revisions, only the affected aggregate operations, the previous record checksum, the resulting view checksum, and its own record checksum. A transition or Gate that consumes registered evidence appends a separate relation to the registry's top-level `handoffs` collection without changing any artifact revision, and commits the workflow and artifact deltas under one transaction ID; either both streams commit or both roll back. The artifact delta carries only the new handoff relation rather than the complete relation history. Scope start commits its `project.yaml` compatibility identity in the same journal as the workflow shard, workflow view, and JSONL index. All targets are durably staged before a prepared journal is written. A caught failure rolls the whole semantic action back; after process interruption, read commands fail closed and the next locked mutation or `rebuild` rolls back a prepared journal or validates and cleans a committed journal. Existing full-snapshot shards remain read-only and may be replayed as the base for later deltas.
+
+Trusted formal-state snapshots live under `.workflow/control/snapshots/formal-state/<anchor-id>/`. Each anchor keeps exact workflow and registry views plus their checksums, stream revisions, record-chain heads, and the JSONL byte/event boundary; `latest.yaml` points to the current trusted anchor. The first anchor requires a successful full-history audit. Later anchors validate only the suffix from the previous trusted anchor before advancing the pointer. Routine `verify` validates the anchor and current invariants, then reads only the JSONL suffix and never decompresses history archives. `verify --history --since-anchor` also reads and replays only post-anchor shards. Before compaction or retention pruning, `verify --history` traverses every loose shard. A compact archive preserves and replays the original legacy prefix and reports `compacted-history`; a prune receipt has no original bytes and therefore reports `retained-history` while verifying only the trusted anchor plus suffix.
+
+`snapshot references` is the single trusted projection used by `archive-version`. It validates the latest pointer, anchor, exact snapshots, target scope manifest, and selected immutable candidate under the formal read lock, then returns relative JSON Pointer references and checksums for scope, candidate, every Gate decision, and the history anchor. An optional requested candidate ID is only a consistency assertion and must equal the candidate selected in the anchored workflow state. Missing or mismatched formal evidence fails before task archive files are written; task-state code must not reimplement anchor validation or emit nullable formal references.
 
 Formal approval is never inferred. A Gate decision requires an explicit actor, rationale, and registered evidence. A Hook event, chat message, file timestamp, UI state, or successful command alone is not approval.
 
-Version completion never implies release intent. Registering a `release-ready` artifact or completing `12-version-closeout` must not create an R-node transition. `R00-release-request` requires successful evidence registered on R00 with `artifact_type: release-request`. Mandatory Gate IDs are `GATE-A`, `GATE-B`, `UX-LF`, `UX-VS`, `UX-UI`, and `PRODUCTION-APPROVAL`. Only a genuinely non-visual experience scope may use `not-required` for a UX Gate; the decision must retain its experience evidence and add successful `02-product-definition` evidence whose artifact type contains `terminal` (the canonical type is `product-terminal-scope`). Gate A, Gate B, and production approval require `approved`.
+Version completion never implies release intent. Registering a `release-ready` artifact or completing `06-version-closeout` or compatibility `12-version-closeout` must not create an R-node transition. `R00-release-request` requires successful evidence registered on R00 with `artifact_type: release-request`. Mandatory active Gate IDs are `GATE-A`, `GATE-B`, `UX-VS`, `UX-UI`, and `PRODUCTION-APPROVAL`. Only a genuinely non-visual experience scope may use `not-required` for an active UX Gate; the decision must retain its experience evidence and add successful product-terminal evidence from `01-product-shaping` or compatibility `02-product-definition` whose artifact type contains `terminal` (the canonical type is `product-terminal-scope`). Gate A, Gate B, and production approval require `approved`.

package/skills/ai-delivery-orchestrate/references/workflow-model.md

@@ -4,15 +4,17 @@
 
 Install all delivery Skills under `.agents/skills/`, keep Hook configuration in `.codex/config.toml`, and write durable workflow documents under `.workflow/`. Formal state is mutated only by `.workflow/tools/state/state.mjs`; runtime tasks are mutated only by `task-state.mjs`.
 
-Formal state schema 2 separates `development_state` from `release_state`. The two scopes own independent IDs, revisions, nodes, Gates, and selections while sharing only the serialized audit revision and cumulative/production identities. Start them with `iteration-started` and `release-started` respectively. Release activity never prevents the next cumulative development version from starting.
+Formal state schema 2 separates `development_state` from `release_state`. The two scopes own independent IDs, revisions, nodes, Gates, and selections while sharing only the serialized audit revision and cumulative/production identities. Workflow mutations compare the owning scope revision, so development and release actions prepared from the same inspection can commit independently; same-scope stale writers fail closed. Start the scopes with `iteration-started` and `release-started` respectively. Release activity never prevents the next cumulative development version from starting.
 
 ## Development State Machine
 
-`00-bootstrap -> 01-product-discovery -> 02-product-definition -> 03-architecture-initial -> 04-experience-design(UX-LF -> UX-VS -> UX-UI) -> 02-product-definition(prototype-reconciliation) -> 05-architecture-reconcile -> 07-iteration-planning -> 08-test-design -> 09-development -> 10-change-review -> 11-candidate-verification -> 12-version-closeout -> release-ready`
+`00-bootstrap -> 01-product-shaping(GATE-A -> GATE-B) -> 02-solution-design(UX-VS -> UX-UI) -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout -> release-ready`
 
-Start `06-platform-preparation` after initial architecture and join it before candidate verification. Closeout creates an immutable version-ready Tag, advances `line/<product-id>`, archives closed version tasks, and stops. It never changes `main` or starts a release.
+This is the installed `development-seven-node` producer route. New producer tasks, artifacts, and requested formal transitions use these node IDs. `development-legacy-13` is read-only compatibility: inspect, verify, rebuild, and explicit migration may consume historical records, while new task, artifact, transition, candidate, closeout, and Gate writes are rejected. Release nodes `R00-release-request` through `R10-release-archive` remain writable.
 
-The state CLI enforces graph prerequisites. A later iteration may satisfy an unaffected prerequisite with a registered successful baseline artifact instead of replaying the node. Reopening a completed node requires an explicit reason and creates a new node attempt, so prior Gate decisions cannot silently approve revised output.
+Within `03-delivery-readiness`, platform preparation may start after the initial architecture baseline and must join planning and test design before scope freeze. Within `05-candidate-assurance`, change review and candidate verification bind to the same immutable candidate. Closeout creates an immutable version-ready Tag, advances `line/<product-id>`, archives closed version tasks, and stops. It never changes `main` or starts a release.
+
+The state CLI enforces graph prerequisites. A later iteration may satisfy an unaffected prerequisite with a registered successful approved baseline artifact whose identity and checksum still match instead of replaying the node. Reopening a completed node requires an explicit reason and creates a new node attempt, so prior Gate decisions cannot silently approve revised output.
 
 ## Independent Release State Machine
 
@@ -22,7 +24,7 @@ Only explicit user release intent may create R00. The user selects a cumulative
 
 ## Gates And Transition Rules
 
-Retain discovery Gate A, product Gate B, major architecture decisions, prototype tool selection, mandatory human `UX-LF`/`UX-VS`/`UX-UI`, standard governance, and exact-package production approval. Product reconciliation after all prototype candidates must be `valid/aligned`; intermediate handoffs use downstream contract validation.
+Retain discovery Gate A, product Gate B, major architecture decisions, prototype tool selection, mandatory human `UX-VS`/`UX-UI`, standard governance, and exact-package production approval. Product reconciliation after all prototype candidates must be `valid/aligned`; intermediate handoffs use downstream contract validation.
 
 Advance only from immutable referenced inputs. Mark dependents stale after upstream change. Preserve failed candidates, releases, Tags, and deployment records. Treat image rollback as deployment state, never Git state. On restart reconcile workspace, Git, artifacts, and external systems; never automatically replay production actions.
 

package/skills/ai-delivery-orchestrate-release/SKILL.md

@@ -26,8 +26,8 @@ Coordinate `R00` through `R10`. Never infer release intent from completed versio
 7. `R07-production-approval`: request mandatory Gate `PRODUCTION-APPROVAL`, bound to the exact package checksum and target environment. It cannot be waived with `not-required`.
 8. `R08-production-deployment`: invoke `$ai-delivery-deploy-production` only after approval.
 9. `R09-production-verification`: invoke `$ai-delivery-verify-production` and decide `released` or rollback/recovery.
-10. `R10-release-archive`: register the final archive artifact as `released`, complete R10 with that artifact as evidence, tag the released commit, then run `state.mjs transition --expected-revision <revision> --event release-archived --iteration-id <release-id> --artifact-id <archive-artifact-id> --production-version-id <version-id>`. Verify the formal state before compacting release task context. Never edit production identity fields directly.
+10. `R10-release-archive`: register the final archive artifact as `released`, complete R10 with that artifact as evidence, tag the released commit, then run `state.mjs transition --expected-scope-revision <release-scope-revision> --event release-archived --iteration-id <release-id> --artifact-id <archive-artifact-id> --production-version-id <version-id>`. Run `verify --history` before compacting release task context. Never edit production identity fields directly.
 
-Run formal `verify` at every handoff. Preserve failed releases and evidence. Stop instead of replaying a production action after recovery.
+Run routine formal `verify` at every handoff and reserve `verify --history` for R10 or an explicit history audit. Preserve failed releases and evidence. Stop instead of replaying a production action after recovery.
 
 Read [release-workflow-contract.md](references/release-workflow-contract.md) and use the request and selection assets.

package/skills/ai-delivery-orchestrate-release/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Orchestrate Release"
-  short_description: "Publish selected cumulative versions on demand"
-  default_prompt: "Use $ai-delivery-orchestrate-release to start or resume an explicit production release."
+interface:
+  display_name: "Orchestrate Release"
+  short_description: "Publish selected cumulative versions on demand"
+  default_prompt: "Use $ai-delivery-orchestrate-release to start or resume an explicit production release."

package/skills/ai-delivery-orchestrate-release/references/release-workflow-contract.md

@@ -1,6 +1,6 @@
 # Independent Release Workflow Contract
 
-The development state machine ends at `12-version-closeout`. Only an explicit user request creates `R00-release-request`.
+The development state machine ends at `06-version-closeout`. Only an explicit user request creates `R00-release-request`.
 
 Each release owns `.workflow/releases/<release-id>/R00-release-request/` through `R10-release-archive/`. Every node consumes registered immutable inputs and registers versioned outputs. Release IDs are unique even when the target commit and image digest were previously deployed.
 

package/skills/ai-delivery-plan-iteration/SKILL.md

@@ -9,7 +9,11 @@ Plan business capability increments. Do not pre-split work into fixed frontend,
 
 ## Artifact Location
 
-Write every workflow document produced by this skill under project `.workflow/`, defaulting version-scoped planning outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+Write every workflow document produced by this skill under project `.workflow/`, defaulting version-scoped planning outputs to `.workflow/iterations/<iteration-id>/03-delivery-readiness/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+
+## Development Node
+
+This Skill owns the planning task phases inside `03-delivery-readiness` and converges with platform preparation and test design. Delivery Readiness completes only after their exact evidence is current and `scope freeze` has bound the approved Slice, requirement, acceptance, logical-task, and formal-artifact sets. Reusing an unaffected approved planning input never bypasses a new scope freeze for the current version.
 
 ## Task State
 
@@ -19,7 +23,7 @@ Write every workflow document produced by this skill under project `.workflow/`,
 
 ## Preflight
 
-Read approved product, final architecture, and experience baselines; exact `ui-handoff.yaml`; aligned `product-prototype-reconciliation.yaml`; experience/requirement change sets; interaction, visual, component, and page-component contracts; the confirmed prototype set and accepted architecture receipts; current backlog; production state; applicable standards; and unresolved risks. Require `development_readiness: ready-for-development` and reject stale changes, missing receipts, non-passing decisions, or identity/checksum mismatches. Distinguish product priority from technical execution order.
+Read approved product, final architecture, and experience baselines; exact `ui-handoff.yaml`; aligned `product-prototype-reconciliation.yaml`; experience/requirement change sets; interaction, visual, component, and page-component contracts; the exact confirmed Prototype revision and checksum; its source and review-bundle checksums; the normalized terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs; and the accepted architecture receipt; current backlog; production state; applicable standards; and unresolved risks. Require `development_readiness: ready-for-development` and reject stale changes, missing or conflicting references, non-passing decisions, or identity/checksum mismatches. Never infer a relationship from a file name or catalog order. Distinguish product priority from technical execution order.
 
 ## Workflow
 
@@ -30,10 +34,12 @@ Read approved product, final architecture, and experience baselines; exact `ui-h
 5. Define MVP or planned-version scope, cumulative version order, allowed concurrency, and risk probes. Do not assume any completed version will be published immediately.
 6. Prefer high-value, high-risk, and early-feedback slices while respecting prerequisites.
 7. Define entry criteria, completion criteria, and measurable iteration outcomes.
-8. Attach the exact prototype-set identity/checksum, relevant member identity/revision/checksum, management/review/impact checksums, and stable page/canvas/file/element IDs to every UI-bearing slice in `slice-prototype-traceability.csv`.
+8. Resolve each affected Page, Review Scene, UI component, frontend source, and acceptance criterion from the pinned UI Mapping. Attach the exact Prototype revision, source revision, terminal, Page, Review Scene, prototype-element, UI Mapping, UI component, and acceptance identities to every UI-bearing Slice in `slice-prototype-traceability.csv`; pin the Prototype revision and UI Mapping checksums in the scope manifest.
 9. Map every actionable `added`, `modified`, `retired`, or `superseded` row to a selected slice in `slice-experience-change-traceability.csv`. Preserve its phase status and implementation/test impact; do not schedule `proposed`, `blocked`, or `stale` changes.
 10. Record deviations when technical sequence delays a higher business priority; request human approval only if release scope or an approved product decision changes.
-11. Replan after verified feedback rather than preserving stale dates or task lists.
+11. At Delivery Readiness, prepare the scope manifest and invoke formal-state `scope freeze` with the approved Slice, requirement, acceptance, required-task, and required-artifact IDs. This enables `scope_contract_version: 1`; downstream readiness is read from `inspect.derived_node_states`, and governed node completion produces a completion receipt.
+12. Keep the frozen scope unchanged during execution. Use `scope warn` only to record a budget overrun as `warn-only` with `reslice_performed: false`; do not automatically reslice or change acceptance. Replan or change scope only after explicit human approval through `scope amend`, preserving the superseded revision.
+13. Replan after verified feedback rather than preserving stale dates or task lists.
 
 ## Outputs
 
@@ -47,6 +53,7 @@ Read approved product, final architecture, and experience baselines; exact `ui-h
 - `slice-prototype-traceability.csv` for UI-bearing work;
 - `slice-experience-change-traceability.csv` showing which added/modified/retired experience changes enter each slice;
 - replanning rules and current plan baseline.
+- a draft `scope-manifest.yaml` whose approved contents are frozen through `scope freeze`; later `scope amend` revisions are append-only and budget `scope warn` records never mutate it.
 
 Do not output component-level technical tasks. The development orchestrator derives those just in time from a selected slice and the latest architecture.
 

package/skills/ai-delivery-plan-iteration/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Plan Iteration"
-  short_description: "Prioritize and sequence vertical slices for an agile iteration"
-  default_prompt: "Use $ai-delivery-plan-iteration to plan the next agile delivery iteration."
+interface:
+  display_name: "Plan Iteration"
+  short_description: "Prioritize and sequence vertical slices for an agile iteration"
+  default_prompt: "Use $ai-delivery-plan-iteration to plan the next agile delivery iteration."

package/skills/ai-delivery-plan-iteration/assets/planning-template/scope-manifest.yaml

@@ -0,0 +1,17 @@
+scope_contract_version: 1
+manifest_id: null
+iteration_id: null
+revision: null
+status: draft
+supersedes: null
+prototype_revision_ref: null
+prototype_revision_checksum: null
+ui_mapping_checksum: null
+slices: []
+requirements: []
+acceptance: []
+required_tasks: []
+required_artifacts: []
+approved_by: null
+approval_reason: null
+manifest_checksum: null

package/skills/ai-delivery-plan-iteration/assets/planning-template/slice-prototype-traceability.csv

@@ -1 +1 @@
-slice_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id
+slice_id,prototype_revision_id,source_revision,terminal_id,page_id,review_scene_id,prototype_element_id,ui_mapping_id,ui_component_id,acceptance_id

package/skills/ai-delivery-plan-iteration/references/planning-contract.md

@@ -24,17 +24,23 @@ Use dependency types `blocks`, `enables`, and `validates`.
 
 `slice-prototype-traceability.csv`:
 
-`slice_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id`
+`slice_id,prototype_revision_id,source_revision,terminal_id,page_id,review_scene_id,prototype_element_id,ui_mapping_id,ui_component_id,acceptance_id`
 
 `slice-experience-change-traceability.csv`:
 
 `slice_id,experience_change_id,change_type,phase_status,implementation_impact,test_impact`
 
+## Frozen Scope
+
+Use `scope-manifest.yaml` to prepare the Delivery Readiness decision. It lists the approved Slices, requirements, acceptance IDs, required logical tasks, and required formal artifacts. After approval, call formal-state `scope freeze`; this enables `scope_contract_version: 1` and stores an append-only revision plus checksum in `workflow-state.yaml`. The planning file is an input draft, not an authority to edit formal state directly.
+
+After freeze, `scope amend` is the only scope-change operation and requires explicit human approval plus `--supersedes` for the current revision. `scope warn` only records an exceeded budget as `action: warn-only` and `reslice_performed: false`; it does not replan, reslice, or change acceptance. Read node readiness from `inspect.derived_node_states`. A governed node completes only from `ready-to-complete`, and the formal-state CLI writes a completion receipt bound to the current manifest, task facts, Gate decisions, artifacts, candidate, blocking defects, and evidence. Historical scopes without `scope_contract_version` remain on the legacy completion contract.
+
 ## Rules
 
 - Preserve business priority from product sources.
 - Use technical constraints to choose sequence, not to silently redefine priority.
 - Prefer thin end-to-end behavior over horizontal frontend/backend layers.
-- Pin the ready UI handoff, aligned product reconciliation, experience-change set, confirmed prototype-set ID/version/checksum and every relevant member `prototype_artifact_id`, version, `source_revision`, `review_bundle_checksum`, tool-selection checksum, page/canvas/file catalog checksums, review/adjustment checksums, and impact-assessment checksum in the iteration plan. Map UI-bearing slices to individual experience-change and page/canvas/file/element rows without delimiter-packed CSV fields. Schedule only `ready-for-development` changes.
+- Pin the ready UI handoff, aligned product reconciliation, experience-change set, exact Prototype revision/checksum, source and review-bundle checksums, UI Mapping checksum, normalized catalog checksums, review/adjustment checksums, impact-assessment checksum, and accepted architecture receipt in the iteration plan. Resolve UI-bearing Slices to individual experience-change, terminal, Page, Review Scene, prototype-element, UI Mapping, UI component, and acceptance rows without delimiter-packed CSV fields. Reject missing or conflicting references and never infer relationships from file names or row order. Schedule only `ready-for-development` changes.
 - Describe affected component scope only at planning time; defer technical tasks and roles to development.
 - Replan from verified evidence and record scope-impact decisions.

package/skills/ai-delivery-prepare-platform/SKILL.md

@@ -9,7 +9,11 @@ Run as a parallel stream after initial architecture and join application develop
 
 ## Artifact Location
 
-Write every platform plan, configuration inventory, environment ledger, readiness report, and workflow document under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Infrastructure source and executable configuration remain in architecture-defined repository locations and are referenced by path, version, and checksum.
+Write every platform plan, configuration inventory, environment ledger, readiness report, and workflow document under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/03-delivery-readiness/`. Infrastructure source and executable configuration remain in architecture-defined repository locations and are referenced by path, version, and checksum.
+
+## Development Node
+
+This Skill contributes a parallel task stream inside `03-delivery-readiness`; it does not create a separate platform formal node. Its exact environment and platform readiness evidence joins planning and test-design evidence before scope freeze. An unaffected approved platform baseline may be reused only by registered identity and checksum when architecture and selected Slice impacts leave it valid.
 
 ## Task State
 

package/skills/ai-delivery-prepare-platform/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Prepare Delivery Platform"
-  short_description: "Prepare CI/CD, environments, infrastructure, and observability"
-  default_prompt: "Use $ai-delivery-prepare-platform to prepare delivery and operations capabilities."
+interface:
+  display_name: "Prepare Delivery Platform"
+  short_description: "Prepare CI/CD, environments, infrastructure, and observability"
+  default_prompt: "Use $ai-delivery-prepare-platform to prepare delivery and operations capabilities."

package/skills/ai-delivery-prepare-release/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Prepare Release"
-  short_description: "Freeze an immutable version and complete delivery inventory"
-  default_prompt: "Use $ai-delivery-prepare-release to prepare the current iteration for production release."
+interface:
+  display_name: "Prepare Release"
+  short_description: "Freeze an immutable version and complete delivery inventory"
+  default_prompt: "Use $ai-delivery-prepare-release to prepare the current iteration for production release."

package/skills/ai-delivery-review-change/SKILL.md

@@ -9,7 +9,11 @@ Review independently from the implementation context. Do not edit product code o
 
 ## Artifact Location
 
-Write every review report, findings table, decision, and evidence reference produced by this skill under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Do not write review documents beside application source.
+Write every review report, findings table, decision, and evidence reference produced by this skill under project `.workflow/`. Work-package reviews stay in `.workflow/iterations/<iteration-id>/04-implementation/`; candidate-wide reviews stay in `.workflow/iterations/<iteration-id>/05-candidate-assurance/`. Do not write review documents beside application source.
+
+## Development Node
+
+Use `04-implementation` for pre-merge package review phases. Use `05-candidate-assurance` for the candidate-wide independent change review bound to that node attempt's immutable candidate. Review rounds remain phases and finding records under the stable logical task; they never create another formal development node.
 
 ## Task State
 
@@ -19,7 +23,13 @@ Write every review report, findings table, decision, and evidence reference prod
 
 ## Preflight
 
-Read the work package, diff, approved source artifacts, standards versions, architecture constraints, TDD evidence, test results, allowed modification scope, exact UI handoff/product-reconciliation checksums, task-to-experience-change actions, and page/canvas/file/element mappings for UI-bearing work. Re-run relevant checks when evidence is absent or stale.
+Read the work package, diff, approved source artifacts, standards versions, architecture constraints, TDD evidence, test results, allowed modification scope, exact UI handoff and `product-prototype-reconciliation.yaml` checksums, Prototype revision and UI Mapping checksums, task-to-experience-change actions, and terminal/Page/Review Scene/prototype-element/UI component/frontend-source/acceptance mappings for UI-bearing work. Reject missing or conflicting references and never infer relationships from file names or row order. Re-run relevant checks when evidence is absent or stale.
+
+## Two-Phase Review Protocol
+
+1. **Feedback collection:** enter the review phase to pin the complete diff or immutable candidate plus its source contracts as `review_subject_baseline`, then collect the full review batch across every axis. Append structured findings to the current review phase and record `review_axes` plus the `collection_decision`. Make no code changes during feedback collection, and do not ask the executor to repair one finding while other axes remain unreviewed.
+2. **Approved change set:** group every current open finding into a coherent proposed change set. Before any repair, record an approval actor, rationale, exact finding IDs, allowed files, expected evidence, and stable `change_set_id`; the task CLI rejects any subject drift, promotes the pinned subject to the repair baseline, and computes the canonical collection checksum. The independent reviewer never applies the set. The work-package executor applies only the approved change set in a repair phase, records evidence against each finding, and does not broaden scope.
+3. Run one concentrated rereview after every approved change-set item has evidence. Recheck affected and adjacent behavior, then resolve findings in the review phase with the same `change_set_id` and the exact Git files changed since approval. A newly discovered issue starts a new feedback collection and cannot be smuggled into the already approved set.
 
 ## Review Axes
 
@@ -29,12 +39,12 @@ Read the work package, diff, approved source artifacts, standards versions, arch
 4. **Correctness:** inspect error paths, state transitions, concurrency, compatibility, resource handling, and rollback impact.
 5. **Tests:** verify behavior through confirmed seams, independent expected values, useful failure sensitivity, and adequate regression coverage.
 6. **Scope:** flag unrelated files, hidden generated changes, dependency drift, and ownership violations.
-7. **Experience conformance:** for UI-bearing changes, verify each `ready-for-development` experience change was implemented with its declared create/update/remove/migrate/no-code action, exact member revision, interaction/component-state obligations, and stable page/canvas/file/element mappings; reject stale, untracked, or visually inferred work.
+7. **Experience conformance:** for UI-bearing changes, run `ai-delivery frontend-guard verify-diff <workspace> --base <review-subject-base> --head <review-subject-head>` and require its independent Git diff, revision-bound frontend scope, current Page approval, and UI Mapping checks to pass. Then verify each `ready-for-development` experience change was implemented with its declared create/update/remove/migrate/no-code action, exact Prototype revision, interaction/component-state obligations, and stable UI Mapping relationships across Page, Review Scene, component, frontend source, and acceptance identities; reject stale, untracked, or visually inferred work. Never accept Hook logs or a local `check-file` result as substitute evidence.
 
 ## Output
 
 Report findings first, ordered by severity, with tight file and line references. For each finding include evidence, violated source ID, impact, and required correction. Then report open questions, check results, residual risk, and one decision: `pass`, `fail`, or `blocked`.
 
-Do not use `pass` when required checks did not run. Do not repair findings yourself; return them to the work-package executor.
+Do not use `pass` when required checks did not run. Do not repair findings yourself; return the approved change set to the work-package executor and wait for concentrated rereview evidence.
 
 Read [review-contract.md](references/review-contract.md).

package/skills/ai-delivery-review-change/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Review Change"
-  short_description: "Independently review a code change against standards and specs"
-  default_prompt: "Use $ai-delivery-review-change to independently review the current code change."
+interface:
+  display_name: "Review Change"
+  short_description: "Independently review a code change against standards and specs"
+  default_prompt: "Use $ai-delivery-review-change to independently review the current code change."

package/skills/ai-delivery-review-change/references/review-contract.md

@@ -11,6 +11,12 @@
 
 Record finding ID, severity, title, file and line, evidence, violated artifact or standard ID, impact, and required correction.
 
+## Two-Phase Session
+
+Entering the review phase pins one `review_subject_baseline`; feedback collection records the complete append-only finding batch against that subject before repair begins. There must be no code change during feedback collection, and approval fails if the current Git state no longer matches the pinned subject. Close the collection by supplying the reviewed axes, exact finding IDs, and decision; the task CLI persists the canonical collection.
+
+An approved change set is persisted through task `--change-set-json` with a stable `change_set_id`, approval actor, rationale, every current open finding ID, repository-relative allowed files, expected evidence, `review_axes`, and `collection_decision`. The task CLI captures the code `repair_baseline`, persists the canonical `feedback_collection`, and computes the SHA-256 `collection_checksum`. The executor applies that set in a repair phase; the reviewer does not edit the code. During concentrated rereview, a resolved finding declares the exact Git `changed_files` since approval, and the CLI rejects an invented change-set ID, a finding outside the approved set, missing expected evidence, undeclared actual changes, or a file outside the approval. New findings require a new feedback collection and approved change set.
+
 ## Decision
 
 Return `pass` only when no blocking findings remain and required checks ran. Return `fail` for confirmed blocking findings and `blocked` when evidence or execution prerequisites are missing.

package/skills/ai-delivery-triage-failure/SKILL.md

@@ -9,7 +9,11 @@ Classify ownership without fixing the defect.
 
 ## Artifact Location
 
-Write every triage report, defect route, evidence index, and workflow document produced by this skill under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Raw external evidence may remain in controlled systems only when immutable references and checksums are recorded in `.workflow/`.
+Write every triage report, defect route, evidence index, and workflow document produced by this skill under project `.workflow/`. Implementation-origin reports stay in `.workflow/iterations/<iteration-id>/04-implementation/`; candidate-origin reports stay in `.workflow/iterations/<iteration-id>/05-candidate-assurance/`. Raw external evidence may remain in controlled systems only when immutable references and checksums are recorded in `.workflow/`.
+
+## Development Node
+
+Triage is a phase of the stable logical task in the node where the failure was observed, not its own formal node. Use `04-implementation` for package, developer-test, and repair failures. Use `05-candidate-assurance` for failures against the bound candidate, then route the correction to the earliest owning producer. A correction that changes candidate bytes returns through `04-implementation`, creates a new immutable candidate, and requires a new Candidate Assurance attempt.
 
 ## Task State
 

package/skills/ai-delivery-triage-failure/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Triage Test Failure"
-  short_description: "Classify test failures and route them to the owning stage"
-  default_prompt: "Use $ai-delivery-triage-failure to classify and route the observed failure."
+interface:
+  display_name: "Triage Test Failure"
+  short_description: "Classify test failures and route them to the owning stage"
+  default_prompt: "Use $ai-delivery-triage-failure to classify and route the observed failure."

package/skills/ai-delivery-validate-artifacts/SKILL.md

@@ -26,9 +26,12 @@ Require every workflow document to resolve under project `.workflow/` unless it
 5. Verify required artifact sets for the target handoff.
 6. Verify baseline immutability, version increments, stale flags, and downstream impact declarations.
 7. Verify status transitions and human gates.
-8. Verify traceability from product goals through features, terminals, stories, acceptance criteria, pages, canvases, prototype files/elements, slices, tasks, tests, release items, and deployment evidence as applicable.
-9. For UI-bearing scope, validate the human tool-selection Gate, executable low-fidelity runtime, mandatory `UX-LF`, `UX-VS`, and `UX-UI` human decisions, stable page numbering, one-main-page-family-per-canvas rule, explicit file/terminal relations, adjustment history, impact propagation, and aligned `product-prototype-reconciliation.yaml`.
-10. Verify complete prototype-set membership and that UI handoff, experience confirmation, architecture validation, test validation, planning, development, and verification all reference the same product reconciliation, experience-change checksum, set checksum, and relevant member IDs, versions, source revisions, review-bundle checksums, management/review catalog checksums, impact-assessment checksums, and receipt checksums. Require downstream work to consume only `ready-for-development` changes.
+8. Verify traceability from product goals through features, terminals, stories, acceptance criteria, Pages, Review Scenes, prototype elements, UI Mapping rows, UI components, frontend sources, Slices, tasks, tests, release items, and deployment evidence as applicable.
+9. For UI-bearing scope, validate the human tool-selection Gate, mandatory `UX-VS` and `UX-UI` human decisions, production-compatible runnable Prototype, stable Page and Review Scene identities, normalized terminal/trigger/route relations, Review Units, adjustment history, impact propagation, and aligned `product-prototype-reconciliation.yaml`. Validate that Workflow Manager evidence names the same checksummed target used by the Gate, uses its loopback origin and allowlisted review action, and contains no target revision drift; before `UX-VS`, its only content target is the Visual Reference, and afterward it is one exact Prototype revision.
+10. Validate every Prototype Page review receipt as an immutable checksummed YAML record under `.workflow/delivery/reviews/prototype-pages/<revision-id>/`. Reject an invalid or extra field, file-path/identity mismatch, actor, timestamp, receipt checksum, Prototype revision checksum, Page checksum, Scene checksum, or evidence checksum. Derive status from the current revision or its checksum-validated `previous_revision` ancestor chain, nearest ancestor first; reject inheritance from descendants or unrelated revisions. Carry forward only when the selected prior decision is approved and the complete Page checksum is identical; preserve a later changes-requested decision on that ancestor, and derive stale after any evidence change. Require the final Page receipt and approved `UX-UI` Gate decision to reference each other through the same actor, iteration, Prototype revision, and receipt checksum, and reject any later receipt unless a new pending `UX-UI` request exists.
+11. Verify that UI handoff, experience confirmation, architecture validation, test validation, planning, development, and verification all pin the same exact Prototype revision/checksum, source revision/checksum, review-bundle checksum, UI Mapping checksum, normalized catalog checksums, product reconciliation, experience-change checksum, review/impact checksums, and receipt checksums. Resolve every affected Page, Review Scene, UI component, frontend source, and acceptance criterion through explicit normalized foreign keys. Reject missing or conflicting references. Never infer relationships from file names or row order. Require downstream work to consume only `ready-for-development` changes.
+12. For every UI-bearing code handoff, validate the revision-bound `frontend-change-scope.yaml` checksum and its code root, non-empty frontend roots and extensions, shared component ownership, and file-only route registry ownership with the exact approved candidate-file SHA-256. Cross-check every active UI Mapping and ownership source against those roots and extensions; a declared source that would be skipped invalidates the scope. Run `ai-delivery frontend-guard verify-diff` with the handoff's fixed base and candidate head; require the independent Git diff to have current approved Page receipts and exact UI Mapping or scope coverage, and read changed route registries from the fixed candidate Git object rather than the mutable worktree. Reject Hook-only evidence, unmapped new or removed UI files, unapproved route-registry content, pending/changes-requested/stale Pages, and scope or revision drift.
+13. Before Candidate Assurance can pass a UI-bearing candidate, require successful `ui-acceptance plan` and `ui-acceptance verify` reports bound to the active attempt and immutable candidate checksum. Check exact Page/Scene/viewport coverage, pinned Playwright environment, visual diff counts and evidence, interaction and WCAG 2.2 AA checks, keyboard/focus/touch-target/text-overflow/responsive/recovery results, protocol evidence, Scenario Pack authority, and separate real backend evidence whenever Product Backend Mock rendered a Scene. Candidate checksum drift requires a new `04-implementation` candidate and Candidate Assurance attempt.
 
 ## Output
 

package/skills/ai-delivery-validate-artifacts/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Validate Delivery Artifacts"
-  short_description: "Validate artifact contracts, IDs, references, and baselines"
-  default_prompt: "Use $ai-delivery-validate-artifacts to validate the current delivery artifacts."
+interface:
+  display_name: "Validate Delivery Artifacts"
+  short_description: "Validate artifact contracts, IDs, references, and baselines"
+  default_prompt: "Use $ai-delivery-validate-artifacts to validate the current delivery artifacts."