ai-delivery-workflow 0.3.0 → 0.5.0

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-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/references/artifact-contract.md

@@ -15,29 +15,29 @@ Record artifact ID, type, version, iteration ID, status, producer skill, input a
 
 Use UTF-8 CSV, fixed headers, stable IDs, controlled enums, parser-safe quoting, and no merged cells, colors, formulas, or delimiter-packed relationship fields.
 
-## Prototype Handoff Set
+## Prototype Handoff
 
 For visual or interactive terminals, require:
 
-- a versioned prototype set with one member manifest per independently versioned review bundle;
-- a valid human tool-selection receipt per member, with one actually available authoring tool selected before source authoring;
-- stable page, canvas, prototype-file, and file-terminal catalogs with normalized relationships;
-- an executable low-fidelity prototype with a passing human `UX-LF` receipt;
-- a checksummed visual system, design tokens, selected UI framework, component-state matrix, and passing human `UX-VS` receipt;
+- one exact immutable Prototype revision with checksummed source, review bundle, Review Shell, Visual Standard, review evidence, and normalized catalogs;
+- a valid human tool-selection receipt for the Prototype, with one actually available authoring tool selected before source authoring;
+- stable terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs with normalized relationships;
+- a production-compatible runnable Prototype with passing human `UX-VS` and `UX-UI` receipts;
+- a checksummed design-reference selection, runnable HTML Visual Reference and manifest, visual system, design tokens, selected UI framework/component system/icon library, pinned component registry/configuration, selected components, checksummed local adaptations, component-state matrix, license/upstream attribution, complete scoped design-input checksum list, an unexpired human `UX-VS` receipt, and a passing `ai-delivery visual-standard validate` report;
 - a runnable formal UI with a passing human `UX-UI` receipt;
 - checksummed review sessions, comments, complete adjustment log, experience/requirement change sets, and impact assessment;
 - an aligned `product-prototype-reconciliation.yaml` and a `ui-handoff.yaml` whose development readiness is `ready-for-development`;
-- each member manifest with immutable source revision, SHA-256 review bundle, and checksums for linked traceability and state catalogs;
-- normalized feature/acceptance/terminal/flow/page/canvas/file/screen/state-to-prototype-element traceability;
-- one source confirmation per set member against product and initial architecture inputs;
-- one architecture validation receipt per set member before architecture reconciliation exits;
-- one test validation receipt per relevant set member before test design exits.
+- the Prototype revision with immutable source revision, SHA-256 source and review-bundle tree checksums, and checksums for every linked catalog;
+- normalized feature/acceptance/terminal/flow/Page/Review Scene/state-to-prototype-element traceability;
+- one source confirmation for the Prototype revision against product and initial architecture inputs;
+- one architecture validation receipt for the Prototype revision before architecture reconciliation exits;
+- one test validation receipt for the Prototype revision before test design exits.
 
-Validate main page IDs against `^P[0-9]{2,}$` and child IDs against `^P[0-9]{2,}-[0-9]{2,}$`; require child `parent_page_id` to match its main-page prefix. Verify derived display labels, uniqueness, no ID reuse, and `retired` preservation. Reject third-level page IDs. Require each canvas to contain exactly one main-page family. Require file splits when terminal, authoring tool, permission, freeze/review lifecycle, or independent delivery boundaries differ.
+Validate main Page IDs against `^P[0-9]{2,}$` and child IDs against `^P[0-9]{2,}-[0-9]{2,}$`; require child `parent_page_id` to match its main-page prefix. Verify derived display labels, uniqueness, no ID reuse, and `retired` preservation. Reject third-level Page IDs. Verify that every Review Scene belongs to one Page, every trigger targets an explicit scene, and every prototype or production route resolves through normalized foreign keys.
 
 Require tool selections `valid/selected`, all applicable staged Gate decisions approved by a human, and impact assessments `valid/ready-for-finalization`. Require each Gate's latest session `approved`, every comment terminal, every adjustment revision-linked, every semantic impact reconciled with product and rebaselined before final freeze, and the approved formal UI revision to match the final manifest. Only a genuinely non-visual terminal may mark these visual Gates `not-applicable`, with product-terminal evidence and rationale.
 
-Require the same set identity/checksum and complete relevant member identities, revisions, bundle/management/review/impact checksums, and receipt checksums in all downstream references. Require source confirmations `valid/confirmed-for-handoff` and architecture/test receipts `valid/accepted`. Reject ambiguous set cardinality, mutable URL-only evidence, missing members or receipts, checksum mismatches, silent downstream edits, and confirmed prototypes with blocking issues.
+Require the same Prototype revision/checksum, source revision/checksum, review-bundle checksum, UI Mapping checksum, normalized catalog checksums, review/impact checksums, and receipt checksums in all downstream references. Require source confirmation `valid/confirmed-for-handoff` and architecture/test receipts `valid/accepted`. Resolve affected Page, Review Scene, UI component, frontend source, and acceptance identities from explicit UI Mapping rows. Reject ambiguous or conflicting references, mutable URL-only evidence, missing receipts, checksum mismatches, silent downstream edits, and confirmed Prototypes with blocking issues. Never infer any relationship from a file name or row order.
 
 ## Status Rules
 

package/skills/ai-delivery-verify-candidate/SKILL.md

@@ -9,7 +9,11 @@ Validate the assembled system independently. Never modify product code, migratio
 
 ## Artifact Location
 
-Write iteration-scope outputs to `.workflow/iterations/<version-id>/11-candidate-verification/` and release-scope outputs to `.workflow/releases/<release-id>/R05-release-verification/`. Candidate binaries and images remain immutable in their artifact stores and are referenced by digest.
+Write iteration-scope outputs to `.workflow/iterations/<version-id>/05-candidate-assurance/` and release-scope outputs to `.workflow/releases/<release-id>/R05-release-verification/`. Candidate binaries and images remain immutable in their artifact stores and are referenced by digest.
+
+## Development Node
+
+Iteration scope runs inside `05-candidate-assurance` against the bound candidate recorded when the node attempt starts. Pass that exact `candidate_id` when registering assurance artifacts; never retarget an active attempt. If any repair changes code, migration, configuration, IaC, dependency, build, or digest, return to `04-implementation`, select a new immutable candidate, and begin a new Candidate Assurance attempt. Release scope remains in `R05-release-verification`.
 
 ## Task State
 
@@ -25,14 +29,17 @@ Require `scope: iteration` or `scope: release`. For iteration scope, verify one
 
 Read `.workflow/config/workspace.yaml` first. Resolve and verify every `repo_id`, `code_commit`, optional `code_tag`, `source_path`, and SHA-256 against the configured nested code repository; stop when a candidate references the workflow repository or another code repository.
 
-Read the candidate manifest, approved baselines, exact ready UI handoff, aligned product reconciliation, experience/requirement change sets, task-to-experience-change traceability, exact prototype set and relevant member manifests/review bundles, tool-selection and page/canvas/file catalogs, interaction/component-state contracts, review/impact records, prototype source confirmations, architecture and test receipts, overall test strategy, public iteration test contract, prior defects, actual change inventory, applicable standards, test environment evidence, and candidate commit and artifact digests. Require source confirmations `valid/confirmed-for-handoff` and architecture/test receipts `valid/accepted`. Stop if the environment or candidate is mutable, any relevant member receipt is missing or non-passing, any planned `ready-for-development` change lacks implementation evidence, or any handoff/set/member identity, management/review/impact checksum, or review-bundle checksum is mismatched.
+Read `candidate-manifest.yaml` first and require it to pin the exact ready UI handoff, aligned `product-prototype-reconciliation.yaml`, Prototype revision, source revision, source tree, review bundle, UI Mapping, and task traceability identities/checksums for UI-bearing scope. Then read the approved baselines, experience/requirement change sets, task-to-experience-change traceability, normalized terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs, interaction/component-state contracts, review/impact records, prototype source confirmation, architecture and test receipts, overall test strategy, public iteration test contract, prior defects, actual change inventory, applicable standards, test environment evidence, and candidate commit and artifact digests. Require source confirmation `valid/confirmed-for-handoff` and architecture/test receipts `valid/accepted`. Stop if the environment or candidate is mutable, a candidate binding field, required receipt, or catalog reference is missing or non-passing, any planned `ready-for-development` change lacks implementation evidence, or any Prototype revision, UI Mapping, handoff, reconciliation, traceability, review/impact, source, or review-bundle identity/checksum conflicts. Never infer a relationship from a file name or catalog order.
+
+For UI-bearing scope, also require the candidate manifest to pin the exact frozen Mock Scenario Pack. Create `ui-acceptance-request.yaml`, run `ai-delivery ui-acceptance plan`, execute its exact Scene/viewport matrix in the pinned Playwright environment, write `ui-acceptance-results.yaml` plus checksummed evidence, and run `ai-delivery ui-acceptance verify` before deciding. Use approved Visual Standard breakpoints or the `390x844`, `768x1024`, and `1440x900` defaults with default maximum diff ratio `0.001`. Produce exact-viewport PNGs and a transparent RGBA changed-pixel mask, plus deterministic JSON protocol envelopes matching every request selector and response in the plan's frozen contract expectation. This work remains inside `05-candidate-assurance`. A Product Backend Mock can drive deterministic rendering but never satisfies real backend or end-to-end acceptance; bind the exact candidate, non-Mock environment, immutable deployment digest, contract result, and end-to-end result in separate real product backend evidence when the plan requires it.
 
 ## Plan Independent Verification
 
 1. Analyze changed and adjacent risks without relying only on developer-authored tests.
-2. Derive additional edge, negative, cross-component, end-to-end, exploratory, regression, security, performance, accessibility, compatibility, migration, recovery, and page/canvas/file/element-level prototype-conformance work as applicable.
-3. Create only test roles justified by risk. Keep every role independent from implementation.
-4. Invoke `$ai-delivery-execute-test` for each test work package.
+2. Resolve affected Pages, Review Scenes, UI components, frontend sources, and acceptance criteria through the pinned UI Mapping, then derive additional edge, negative, cross-component, end-to-end, exploratory, regression, security, performance, accessibility, compatibility, migration, recovery, and mapped prototype-conformance work as applicable.
+3. For each affected UI Scene, execute deterministic rendering and interaction at every approved breakpoint. Compare against the exact Prototype with the approved pixel ratio and retain reviewable prototype/candidate/diff images. Block on WCAG 2.2 AA, keyboard, focus, touch-target, text-overflow, responsive, recovery, protocol, or Mock authority failures.
+4. Create only test roles justified by risk. Keep every role independent from implementation.
+5. Invoke `$ai-delivery-execute-test` for each test work package.
 
 ## Decide
 
@@ -42,7 +49,7 @@ Produce:
 
 - independent test cases and automation;
 - execution logs and evidence;
-- requirement, feature, experience-change, page, canvas, prototype-file/element, risk, and test coverage matrices;
+- requirement, feature, experience-change, Page, Review Scene, prototype-element, UI Mapping, UI component, frontend-source, acceptance, risk, and test coverage matrices;
 - defect CSV with severity and reproduction evidence;
 - specialty test results as applicable;
 - untested scope and residual risks;

package/skills/ai-delivery-verify-candidate/assets/verification-template/ui-acceptance-request.yaml

@@ -0,0 +1,19 @@
+schema_version: 1
+artifact_type: ui-acceptance-request
+iteration_id: ITER-0001
+candidate_id: CANDIDATE-0001
+node_attempt: 1
+experience_ref: .workflow/experience
+prototype_revision_ref: prototype/revisions/PROTOTYPE-REVISION-0001/prototype-revision.yaml
+mock_scenario_pack_ref: mock-scenario-packs/MOCK-SCENARIO-PACK-0001.yaml
+test_strategy:
+  ref: .workflow/iterations/ITER-0001/03-delivery-readiness/test-strategy.yaml
+  algorithm: sha256
+  checksum: REPLACE_WITH_SHA256
+runner:
+  engine: playwright
+  package_version: REPLACE_WITH_EXACT_VERSION
+  browser: chromium
+  browser_version: REPLACE_WITH_EXACT_VERSION
+  environment_image: REPLACE_WITH_PINNED_IMAGE
+  environment_digest: sha256:REPLACE_WITH_64_HEX_DIGEST

package/skills/ai-delivery-verify-candidate/assets/verification-template/ui-acceptance-results.yaml

@@ -0,0 +1,53 @@
+schema_version: 1
+artifact_type: ui-acceptance-results
+iteration_id: ITER-0001
+status: pending
+decision: blocked
+plan_checksum: REPLACE_WITH_SHA256
+candidate:
+  candidate_id: CANDIDATE-0001
+  manifest_checksum: REPLACE_WITH_SHA256
+  node_attempt: 1
+prototype_revision:
+  artifact_id: PROTOTYPE-REVISION-0001
+  checksum: REPLACE_WITH_SHA256
+  source_revision: REPLACE_WITH_IMMUTABLE_SOURCE_REVISION
+  review_bundle_checksum: REPLACE_WITH_SHA256
+  ui_mapping_checksum: REPLACE_WITH_SHA256
+mock_scenario_pack:
+  artifact_id: MOCK-SCENARIO-PACK-0001
+  checksum: REPLACE_WITH_SHA256
+runner:
+  engine: playwright
+  package_version: REPLACE_WITH_EXACT_VERSION
+  browser: chromium
+  browser_version: REPLACE_WITH_EXACT_VERSION
+  environment_image: REPLACE_WITH_PINNED_IMAGE
+  environment_digest: sha256:REPLACE_WITH_64_HEX_DIGEST
+mock_boundary:
+  product_backend_mock_used_for_rendering: false
+  product_backend_mock_accepted_as_real_backend_evidence: false
+real_product_backend_acceptance:
+  status: pending
+  source: real-product-backend
+  candidate:
+    candidate_id: CANDIDATE-0001
+    manifest_checksum: REPLACE_WITH_SHA256
+    node_attempt: 1
+  environment:
+    environment_id: REPLACE_WITH_NON_MOCK_ENVIRONMENT_ID
+    deployment_ref: REPLACE_WITH_IMMUTABLE_DEPLOYMENT_REF
+    deployment_digest: sha256:REPLACE_WITH_64_HEX_DIGEST
+    product_backend_mock_enabled: false
+  evidence:
+    ref: .workflow/iterations/ITER-0001/05-candidate-assurance/real-product-backend.json
+    algorithm: sha256
+    checksum: REPLACE_WITH_SHA256
+candidate_assurance:
+  node: 05-candidate-assurance
+  node_attempt: 1
+  candidate_id: CANDIDATE-0001
+# One result is required for every plan execution. Every evidence object uses ref/algorithm/checksum.
+# Visual evidence uses exact-viewport PNGs; diff.png is an RGBA mask (alpha 0 unchanged, alpha >0 changed).
+# Protocol request/response evidence is JSON exactly matching the frozen expectation emitted by plan.
+executions: []

package/skills/ai-delivery-verify-candidate/references/candidate-verification-contract.md

@@ -2,7 +2,7 @@
 
 ## Scope
 
-Require `iteration` or `release`. Iteration scope verifies one planned-version candidate for `12-version-closeout`. Release scope verifies the exact `R04-release-candidate`, selected version closure, release material index, environment/configuration snapshot, migrations, rollback compatibility, and target tag before R06.
+Require `iteration` or `release`. Iteration scope writes under `05-candidate-assurance`, verifies the exact candidate bound to that node attempt, and produces evidence for `06-version-closeout`. Every registered iteration assurance artifact carries the bound `candidate_id`; candidate-changing repair requires a new candidate and node attempt. Release scope verifies the exact `R04-release-candidate`, selected version closure, release material index, environment/configuration snapshot, migrations, rollback compatibility, and target tag before R06.
 
 ## Test Work Packages
 
@@ -16,7 +16,15 @@ Create test types only when justified by changed or adjacent risk.
 
 Return `pass` only when mandatory gates pass, blocking defects are absent, required coverage is evidenced, and untested scope is acceptable under approved policy. Return `fail` for candidate defects and `blocked` for unavailable prerequisites.
 
-For UI-bearing scope, require one exact ready UI handoff, aligned product reconciliation, experience-change set, prototype-set identity/checksum, and a complete relevant member set across manifests, tool-selection and page/canvas/file catalogs, review/impact records, source confirmations, architecture receipts, test receipts, iteration plan, work packages, and candidate traceability. Verify every planned `experience_change_id` has the declared implementation action and independent behavior, visual-regression, responsive, and accessibility evidence as applicable. Verify matching management/review/impact checksums and applicable page/canvas/file/element identities and states through every delivered terminal. Route requirement conflicts to product, prototype defects to experience, feasibility conflicts to architecture, testability gaps to test design, and implementation differences to development.
+For UI-bearing scope, require `candidate-manifest.yaml` to pin one exact ready UI handoff, aligned product reconciliation, Prototype revision/checksum, source revision/checksum, review-bundle checksum, UI Mapping checksum, and both task traceability checksums. Verify these bindings against the experience-change set, normalized catalogs, review/impact records, source confirmation, architecture receipt, test receipt, iteration plan, work packages, and candidate traceability before deriving tests. Resolve every affected Page, Review Scene, UI component, frontend source, and acceptance criterion from the pinned UI Mapping. Verify every planned `experience_change_id` has the declared implementation action and independent behavior, visual-regression, responsive, and accessibility evidence as applicable. Verify matching references and checksums through every delivered terminal; reject missing or conflicting candidate fields or references and never infer relationships from file names or row order. Route requirement conflicts to product, prototype defects to experience, feasibility conflicts to architecture, testability gaps to test design, and implementation differences to development.
+
+## UI Acceptance
+
+UI Acceptance is mandatory inside iteration `05-candidate-assurance`; it is not another formal node. The candidate manifest pins the frozen Mock Scenario Pack in addition to the Prototype and UI Mapping. Run `ai-delivery ui-acceptance plan <workspace> --request <request>` before browser execution, then `ai-delivery ui-acceptance verify <workspace> --request <request> --results <results>` before a passing decision. Both commands are read-only.
+
+The plan must bind the active node attempt, exact immutable candidate manifest checksum, approved unexpired Visual Standard whose checksum is identical to the frozen Prototype revision, frozen Prototype revision, current approved Page receipts, candidate traceability, complete UI Mapping, frozen Scenario Pack, approved test strategy, and exact Playwright/browser/image versions. Revalidate the Scenario Pack candidate checksum, human confirmation, Prototype binding, mapping, protocol contracts, and checksummed Microcks admin export artifacts instead of trusting its status field. It expands every affected Review Scene across the approved Visual Standard breakpoints; absent an approved override, use `390x844`, `768x1024`, and `1440x900`, with `max_diff_pixel_ratio: 0.001`.
+
+The results must cover the plan exactly and bind checksummed prototype/candidate/diff PNG screenshots, deterministic fixture and Scenario identity, interactions, WCAG 2.2 AA with no violations, keyboard, focus, touch-target, text-overflow, responsive, recovery, and protocol request/response evidence. Prototype and candidate PNG dimensions equal the exact viewport; the diff is a non-interlaced 8-bit RGBA mask where transparent pixels are unchanged and non-transparent pixels are changed. Decode the PNGs, compare prototype and candidate pixels, require the mask to identify the same pixels, and recompute changed-pixel counts and ratio independently. Protocol evidence is deterministic JSON equal to the request and response expectation derived from both the frozen approved contract and its checksummed Microcks admin export artifact, including path/query/header dispatcher values and a named request body when the contract uses them. External Dependency Mock use requires explicit approval in the test strategy. Product Backend Mock may render a Scene but is always marked ineligible as real backend or end-to-end evidence; require a separate checksummed `real-product-backend` result whenever it was used. That result and its JSON evidence bind the exact candidate, a named non-Mock environment, immutable deployment digest, `product_backend_mock_enabled: false`, and passing contract plus end-to-end checks. Any candidate manifest checksum change invalidates the plan, returns work to `04-implementation`, selects a new immutable candidate, and starts a new Candidate Assurance attempt.
 
 ## Independence
 

package/skills/ai-delivery-verify-production/SKILL.md

@@ -9,7 +9,7 @@ Keep deployment execution separate from release success.
 
 ## Artifact Location
 
-Write production verification reports, signal snapshots, rollback decisions, and release decisions to `.workflow/releases/<release-id>/R09-production-verification/`. External observability data may remain in controlled systems only when immutable references and timestamps are recorded in `.workflow/`.
+Write production verification reports, signal snapshots, rollback decisions, and release decisions to `.workflow/releases/<release-id>/R09-production-verification/`. A `released` decision must also write the immutable machine-readable `production-verification.json` sidecar. External observability data may remain in controlled systems only when immutable references and timestamps are recorded in `.workflow/`.
 
 ## Task State
 
@@ -19,7 +19,7 @@ Write production verification reports, signal snapshots, rollback decisions, and
 
 ## Preflight
 
-Read the approved release package, deployment record, previous stable release, verification thresholds, rollback authorization, observability state, and target environment. Confirm that the deployed identities match the manifest.
+Read the approved release package, candidate receipt, deployment record, previous stable release, verification thresholds, rollback authorization, observability state, and target environment. Confirm that the deployed identities match the manifest: the R00 `expected_main` base, one source version-ready Tag/commit, exact candidate commit and incremental merge commit when one exists, immutable release Tag, image digest, configuration, and migrations.
 
 ## Verify
 
@@ -36,15 +36,18 @@ Read the approved release package, deployment record, previous stable release, v
 - When old-image compatibility is unproven or data recovery is irreversible, stop and request the approved manual recovery decision.
 - For ambiguous business-signal degradation with healthy technical signals, pause for human judgment.
 
-After successful release verification, invoke `$ai-delivery-manage-git` to fast-forward code-repository `main` to the exact deployed, tagged commit. Record the release decision only in the workflow repository. For same-version redeploy, allow code `main` to remain at the same commit. After rollback, keep code `main` unchanged and retain the failed release, version, and Tags. Do not update `production_version_id` or `production_release_id` in R09; hand the verified identities to R10, which records them through the formal `release-archived` transition.
+For a `released` decision, write `production-verification.json` before any protected Git action. It must use `schema_version: 1`, `operation: production-verification-decision`, exact `release_id`, `decision: released`, and full immutable `expected_main_commit`, `verified_release_commit`, and `deployed_commit` fields; the last two must name the deployed candidate. Then invoke `$ai-delivery-manage-git`'s controlled `scripts/release-git.mjs promote` operation with `--release-id`, `--release-branch`, the R00 `--expected-main`, exact `--verified-release-commit`, `--production-verification <R09-production-verification/production-verification.json>`, `--receipt <path>`, and `--apply`. Accept success only when its JSON receipt proves the protected code-repository `main` fast-forwarded from that exact base to that exact commit and records the evidence checksum. For same-version redeploy, it may record an explicit unchanged result only when `main` already names the verified candidate. Omitting `--apply` is planning only. Record the release decision only in the workflow repository.
+
+Do not synchronize `release-fix/*` into `line/<product-id>` before the production decision. On `released`, hand every deployed release-fix identity, the expected line head, the R09 JSON decision, and an R10 schema-2 product-line `candidate-inventory.json` to R10. It must bind `product_id`, `line_branch`, the active candidate, and every candidate's own `release_id`, immutable commit, and current status; the root has no release ID. R10 runs `scripts/release-git.mjs sync-release-fix --source-ref --source-commit --verified-release-commit --line-branch --expected-line --production-verification <R09 JSON> --candidate-inventory <predecessor R10 JSON> --successor-candidate-inventory <new R10 JSON> --receipt <path> --apply`; it writes an `applied` merge receipt or unchanged `idempotent` receipt, derives `stale_candidate_ids` plus `candidate_status_updates` across that product line, and emits the new immutable successor inventory. The input inventory remains immutable, and a replay can use only byte-identical successor content. After rollback, blocked, or human-decision outcomes, keep code `main` and `line` unchanged and retain the failed release, version, and Tags. Do not update `production_version_id` or `production_release_id` in R09; hand the verified identities to R10, which records them through the formal `release-archived` transition.
 
 ## Outputs
 
-- production verification report and evidence;
+- production verification report and evidence, including `production-verification.json` for every `released` decision;
 - release decision and observation window;
 - rollback deployment record and rollback verification when applicable;
 - residual risks, incident or defect routes, and final production version;
 - release archive handoff or rework status.
+- main-promotion receipt when released, plus the candidate inventory and release-fix synchronization handoff when applicable;
 - final production version, release ID, and immutable release evidence for `R10-release-archive`.
 
 Read [production-verification-contract.md](references/production-verification-contract.md) and use `assets/production-verification-template/`.

package/skills/ai-delivery-verify-production/assets/production-verification-template/production-verification.json

@@ -0,0 +1,9 @@
+{
+  "schema_version": 1,
+  "operation": "production-verification-decision",
+  "release_id": "REL-0001",
+  "decision": "released",
+  "expected_main_commit": "<full-git-sha>",
+  "verified_release_commit": "<full-git-sha>",
+  "deployed_commit": "<same-full-git-sha>"
+}

package/skills/ai-delivery-verify-production/assets/production-verification-template/production-verification.md

@@ -1,7 +1,15 @@
 # Production Verification
 
+`production-verification.json` in this directory is the mandatory machine-readable decision sidecar for a `released` outcome. Fill it with full immutable Git object IDs before invoking `release-git.mjs promote`; this report remains the human-readable evidence.
+
 ## Release And Deployment Identity
 
+- R00 `expected_main`:
+- source `version-ready` Tag and commit:
+- release-candidate merge commit:
+- immutable release Tag:
+- candidate receipt:
+
 ## Mandatory Checks
 
 ## Observation Window And Signals
@@ -10,6 +18,18 @@
 
 ## Decision
 
+- decision:
+- machine-readable decision: `production-verification.json`
+- `main` promotion receipt:
+
 ## Rollback And Rollback Verification
 
+## Release-Fix Line Synchronization Handoff
+
+- release-fix branch/commit:
+- `line/<product-id>`:
+- R10 predecessor candidate inventory: schema-2 product-line `candidate-inventory.json`
+- R10 successor candidate inventory: distinct immutable JSON path supplied through `--successor-candidate-inventory`
+- required R10 receipt:
+
 ## Residual Risk And Routes

package/skills/ai-delivery-verify-production/references/production-verification-contract.md

@@ -2,13 +2,29 @@
 
 ## Required Evidence
 
-Record deployment and release IDs, actual artifact digests, health and readiness, critical journey smoke results, data integrity, authorization, logs, errors, latency, resources, queues, alerts, dashboards, business sanity signals, observation window, and final decision.
+Record deployment and release IDs, candidate receipt, immutable release Tag, R00 production-base commit, actual candidate/deployed commit, actual artifact digests, health and readiness, critical journey smoke results, data integrity, authorization, logs, errors, latency, resources, queues, alerts, dashboards, business sanity signals, observation window, and final decision.
+
+For every `released` decision, write `R09-production-verification/production-verification.json` before invoking a protected Git operation. Its exact machine-readable shape is:
+
+```json
+{
+  "schema_version": 1,
+  "operation": "production-verification-decision",
+  "release_id": "REL-0001",
+  "decision": "released",
+  "expected_main_commit": "<full-git-sha>",
+  "verified_release_commit": "<full-git-sha>",
+  "deployed_commit": "<same-full-git-sha>"
+}
+```
+
+`release_id` must equal the Git operation's release ID; both candidate fields must be full object IDs and must be equal. `promote` additionally requires the JSON `expected_main_commit` to equal R00. The Git receipt records the evidence path and SHA-256 so a later archive can prove the decision it consumed.
 
 ## Decisions
 
-- `released`: mandatory thresholds pass; fast-forward `main` to the exact deployed tagged commit, or keep the identical commit for same-version redeploy, then hand off R10 archive.
+- `released`: mandatory thresholds pass; write the JSON decision above, then invoke `release-git.mjs promote --release-id <id> --release-branch <branch> --expected-main <r00-sha> --verified-release-commit <candidate-sha> --production-verification <R09-production-verification/production-verification.json> --receipt <path> --apply` to fast-forward `main` only from the recorded R00 `expected_main` to the exact deployed, tagged candidate commit. Save the promotion receipt with old/new heads and its production-verification evidence binding. For same-version redeploy, retain an explicit unchanged receipt only if `main` already equals that exact candidate, then hand off R10 archive.
 - `rolled-back`: an authorized technical threshold fails; redeploy the previous stable image digest and verify it.
 - `blocked`: rollback compatibility, recovery authority, or evidence is insufficient.
 - `human-decision`: business signals are ambiguous while technical signals remain healthy.
 
-Never create a rollback branch, move a release Tag, reset `main`, or rebuild the previous image.
+For each successful deployed `release-fix/*`, R10 must freeze a `candidate-inventory.json` with `schema_version: 2`, `scope: "product-line"`, `product_id`, `line_branch`, `active_candidate_id`, `active_candidate_commit`, and a unique `candidates` list of `{ candidate_id, release_id, candidate_commit, status }` objects. The root must not define `release_id`; each candidate preserves the release that created it. The input inventory's line branch must equal the operation's `--line-branch`, while the active and verified candidate records must carry the operation release ID. Before archive, call `release-git.mjs sync-release-fix --release-id <id> --source-ref <branch> --source-commit <sha> --verified-release-commit <candidate-sha> --line-branch <line> --expected-line <line-sha> --production-verification <R09 JSON> --candidate-inventory <predecessor-R10 JSON> --successor-candidate-inventory <new-R10 JSON> --receipt <path> --apply`. The successor path must differ from the predecessor and receipt; it is an immutable product-line inventory emitted by the controlled operation, never a rewrite of the input. Its receipt records predecessor/successor evidence bindings, release/source identities, verified release commit, line heads, merge strategy, derived `stale_candidate_ids`, derived `candidate_status_updates` including each candidate's release ID, and `applied` or idempotent `idempotent` status. Callers must not supply a stale-candidate list. Selectable candidates across the product line that omit the successful fix become `stale`; candidates already `stale` or `released` are not rewritten. When the previous active candidate becomes stale, the successor advances the active pointer to the verified candidate. Replays require byte-identical existing successor content. Never create a rollback branch, move a release Tag, reset `main`, rewrite `line`, or rebuild the previous image.

package/skills/ai-delivery-design-experience/assets/experience-template/low-fidelity-confirmation.yaml

@@ -1,32 +0,0 @@
-artifact_id: LOW-FIDELITY-CONFIRMATION-0001
-artifact_type: low-fidelity-interaction-confirmation
-version: 1
-iteration_id: ITER-0001
-status: pending
-producer_skill: ai-delivery-design-experience
-prototype_artifact_id: PROTOTYPE-0001
-prototype_fidelity: low-fidelity-interactive
-interaction_runtime: executable
-source_revision: LF-REVISION-0001
-review_entrypoint: prototype/low-fidelity/index.html
-interaction_contract_ref: interaction-contract.csv
-interaction_contract_checksum: REPLACE_WITH_SHA256
-experience_change_set_ref: experience-change-set.csv
-experience_change_set_checksum: REPLACE_WITH_SHA256
-checks:
-  executable_entrypoint: pending
-  layout_coverage: pending
-  interaction_coverage: pending
-  state_changes: pending
-  validation_and_errors: pending
-  responsive_behavior: pending
-  no_dead_controls: pending
-human_approval:
-  required: true
-  approver: null
-  decided_at: null
-  decision: pending
-  approved_source_revision: null
-decision: pending
-blocking_issues: []
-evidence: []