ai-delivery-workflow 0.2.2 → 0.4.0

package/skills/ai-delivery-design-experience/references/experience-contract.md

@@ -16,58 +16,57 @@ Use state types `default`, `loading`, `empty`, `success`, `partial`, `error`, `p
 
 ## Design Baseline
 
-Include task flows, information architecture, page inventory, an executable low-fidelity prototype, interaction contract, visual direction, framework selection, machine-readable design tokens, component states, a production-compatible formal UI baseline, responsive behavior, accessibility rules, content rules, change sets, final product reconciliation, and unresolved technical questions.
+Include task flows, information architecture, page inventory, interaction contract, design-reference selection, runnable HTML Visual Reference, visual direction, framework/component/icon selection, machine-readable design tokens, component states, a production-compatible runnable prototype, responsive behavior, accessibility rules, content rules, change sets, final product reconciliation, and unresolved technical questions.
 
 Do not select new product terminals or change feature behavior. Route those changes to product definition.
 
-Apply [prototype-management-contract.md](prototype-management-contract.md) to every visual or interactive prototype member. A member cannot enter authoring without a valid human tool-selection receipt and cannot freeze without valid `UX-LF`, `UX-VS`, `UX-UI`, product-reconciliation, adjustment-closure, and impact-assessment evidence.
+Apply [prototype-management-contract.md](prototype-management-contract.md) to the project's one logical Prototype. It cannot enter authoring without a valid human tool-selection receipt and no revision can freeze without valid `UX-VS`, `UX-UI`, product-reconciliation, adjustment-closure, and impact-assessment evidence.
 
 ## Staged Gates And Handoff
 
-`UX-LF` accepts only an executable low-fidelity interaction revision with no dead controls and complete interaction/state evidence. `UX-VS` accepts exact visual-direction, design-token, framework-selection, and component-state checksums. `UX-UI` accepts a runnable formal UI revision that preserves confirmed interactions and applies the selected system. Product reconciliation runs after all members are candidate-approved and before freeze.
+`UX-VS` accepts exact design-reference selection, Visual Reference HTML/manifest, visual-direction, design-token, framework/component/icon-selection, component registry/configuration, selected components, checksummed local adaptations, component-state, license, upstream-attribution, and complete design-input checksums. Before Gate completion, `ai-delivery visual-standard validate <workspace> --experience <relative-directory>` must pass. Missing or drifted inputs, incomplete checksum coverage, and expired approvals fail closed. `UX-UI` accepts a production-compatible runnable Prototype revision with complete interaction/state evidence, no dead controls, and the selected visual system applied. Product reconciliation runs after all affected Pages and Review Scenes are candidate-approved and before freeze.
 
-`ui-handoff.yaml` is the single downstream readiness interface. It pins the experience baseline, prototype set, all Gate receipts, interaction contract, tokens, framework selection, component states, page-component map, experience/requirement changes, and product coverage. It remains `development_readiness: blocked` until every Gate passes, product decision is `aligned`, all requirement changes are terminal, and no referenced artifact is stale.
+`ui-handoff.yaml` is the single downstream readiness interface. It pins the experience baseline, exact Prototype revision, all Gate receipts, interaction contract, tokens, framework selection, component states, UI Mapping, experience/requirement changes, and product coverage. It remains `development_readiness: blocked` until every Gate and `prototype-revision validate` pass, product decision is `aligned`, all requirement changes are terminal, and no referenced artifact is stale.
 
 Use `experience-change-set.csv` for `added`, `modified`, `retired`, `superseded`, and `unchanged` stable identities. Normalize multiple domains through `experience-change-domains.csv`; allowed domains are `requirement`, `layout`, `navigation`, `interaction`, `state`, `content`, `visual`, `component`, `responsive`, and `accessibility`. Do not infer deltas by visually comparing prototype files.
 
-## Prototype Manifest
+## Prototype Revision
 
-Produce one `prototype-manifest.yaml` per independently versioned review bundle. A bundle may cover one or more terminals only when a single source revision, export, confirmation, and downstream validation lifecycle applies to all of them. Create separate manifests when terminals use different design sources, revision lifecycles, or review bundles.
+Maintain exactly one `prototype.yaml` descriptor, one current source tree, and one current Review Shell for the project. Multiple terminals remain inside this logical Prototype and are grouped by `terminal_id`; `prototype-terminals.csv` may declare compatible independent source entrypoints and build commands without creating separate Prototype identities.
 
-Create `prototype-set.yaml` as the complete ordered handoff set. Record its artifact ID, version, iteration, status, producer, product baseline, initial architecture baseline, architecture-gate inputs with versions/checksums, and one member row per manifest with the member artifact ID, version, covered terminal IDs, manifest path, and manifest SHA-256. Freeze and register the set checksum after all member manifests are frozen.
+Freeze every approved iteration as one immutable `prototype-revision.yaml`. It pins the stable Prototype ID, iteration ID, exact source revision/tree checksum, checksummed review bundle, Review Shell entrypoint, approved Visual Standard, review evidence, and all normalized catalogs. The review bundle contains the revision's terminal, Page, Review Scene, trigger-condition, route, and UI Mapping snapshots. Run `ai-delivery prototype-revision validate` before registration and retain the report.
 
-Architecture must produce one accepted receipt per set member before reconciliation passes. Test design validates members relevant to its selected slices: every set member must appear in `prototype-test-scope.csv` as `included` or `out-of-scope`; every included member requires an accepted test receipt, and every exclusion requires slice/terminal evidence and rationale.
+When Review Scenes depend on protocol simulations, keep External Dependency Mock and Product Backend Mock catalogs isolated. Every entry records an explicit kind, owner, approved contract, replacement condition, operation/channel, and named deterministic scenario. Export every managed UI OpenAPI/AsyncAPI definition into `mock-admin-exports/`; `mock-admin-export.yaml` binds each actual file by kind, mock identity, protocol, relative path, and SHA-256. Freeze requires exactly one export per used Mock identity and protocol-validates every mapped scenario against its exported content. Prohibit production traffic, credentials, and unsanitized personal data, and require passed sanitization evidence for explicit imports. `mock-scenario-mappings.csv` maps every active Review Scene exactly once. `ai-delivery mock freeze --dry-run` produces the candidate checksum for human confirmation; the immutable Mock Scenario Pack becomes authoritative only after its exact file checksum is formally registered. Product Backend Mock evidence never proves the real backend or end-to-end behavior.
 
-Name member files with their stable prototype ID, for example `prototype-manifest-PROTOTYPE-WEB-0001.yaml` and `prototype-confirmation-PROTOTYPE-WEB-0001.yaml`. Do not reuse an unsuffixed filename for multiple members.
+`prototype-pages.csv` owns stable Page identity. `prototype-review-scenes.csv` owns stable directly reviewable conditions. `prototype-trigger-conditions.csv` owns how each scene is activated. `prototype-routes.csv` owns route paths and their `prototype` or `production` kind. `ui-mapping.csv` binds each Page and Review Scene to its direct prototype route, real production Page route, frontend source, and acceptance ID. A production route never targets a Review Scene; conditional review access must not fabricate a production route.
 
-Each prototype manifest contains:
+Each iteration and every approval, source confirmation, architecture receipt, test receipt, plan, development task, and candidate check pin one exact Prototype revision identity and checksum. Later source work creates a new revision of the same Prototype; it never creates a Prototype copy or member bundle.
 
-- artifact ID, version, status, producer, and iteration ID;
-- exact product and initial architecture input references;
-- exact tool-selection reference/checksum;
-- prototype type, fidelity, source path or URL, immutable source revision, and review entrypoint;
-- stable review bundle path and SHA-256;
-- covered terminal, flow, screen, and state IDs;
-- page, canvas, canvas-page, prototype-file, and file-terminal catalog references with SHA-256 checksums;
-- staged human Gate receipts, review sessions, review comments, adjustment log, and impact assessment references with SHA-256 checksums;
-- traceability, state-catalog, and feature-screen-coverage references with SHA-256 checksums;
-- applicable standard IDs and versions.
+Legacy `prototype-set.yaml` and member manifests are accepted only as read-only historical inputs. Compatibility readers may normalize their identities for inspection, verification, rebuild, or explicit migration. Current producers never generate or mutate set/member artifacts.
 
-A remote design URL without an immutable revision and stable review export is not sufficient. Record the review entrypoint as a relative path inside the checksummed review bundle so it cannot drift independently. For a non-visual terminal, use `prototype_type: not-applicable` and record a product-terminal rationale.
+## Legacy Prototype Migration
+
+`upgrade` installs migration capability and reports `prototype_migration.required_follow_up`; it never applies the Prototype migration. `migrate --dry-run` is the authoritative zero-write plan, and `migrate` applies it only when `can_apply: true`.
+
+For the open iteration, validate set/member identity, manifest/source/catalog SHA-256, contained paths, and stable terminal, Page, route, and file identities. A valid zero-member input is `not-required`. A single member migrates automatically only when every identity, checksum, catalog, and target is unambiguous. Multiple members merge equal stable identities and block on differing definitions until one checksum-bound `human:<identity>` decision selects the canonical member. The one migration decision file always contains both `decisions` and `prototype_decisions` lists.
+
+Apply creates only `.workflow/experience/<iteration-id>/prototype.yaml`, `prototype-migration.yaml`, copied `prototype/source/<member-id>/...` bytes, and a current Review Shell. Preserve legacy set/member/source bytes, closed and archived iterations, Gate files, approvals, and events. The new descriptor uses `prototype_id: PROTOTYPE`, `status: migration-pending-ux-ui`, and `current_revision_ref: null`.
+
+Migration approval is never inherited. Complete the current normalized catalogs and Review Shell, freeze a new immutable revision, pass `prototype-revision validate`, then request a new `UX-UI`. The migration Review Shell is only a navigation aid; Workflow Manager may accept decisions only for the new complete frozen revision, and P17 keeps the migration lineage available for audit.
 
 `prototype-traceability.csv`:
 
-`prototype_element_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,feature_id,acceptance_id,terminal_id,flow_id,screen_id,state_id,interaction,coverage_status`
+`prototype_element_id,prototype_revision_id,source_revision,terminal_id,page_id,review_scene_id,feature_id,acceptance_id,flow_id,state_id,interaction,coverage_status`
 
 Every in-scope feature-terminal behavior and applicable state must resolve to at least one prototype element. Do not encode multiple IDs in one CSV cell; use multiple rows.
 
 ## Prototype Source Confirmation
 
-Write one immutable `prototype-confirmation.yaml` per set member. Pin the prototype-set reference/checksum, prototype manifest reference/checksum, artifact identity, source revision, review-bundle checksum, tool-selection checksum, management and review catalog checksums, impact-assessment checksum, and linked coverage checksums. Record separate results for:
+Write one immutable `prototype-confirmation.yaml` for the exact Prototype revision. Pin its identity/checksum, source revision/tree checksum, review-bundle checksum, tool-selection checksum, normalized catalog checksums, review/impact checksums, and linked coverage checksums. Record separate results for:
 
 - tool-selection validity;
-- page/canvas/file management validity;
-- mandatory staged human-review closure for `UX-LF`, `UX-VS`, and `UX-UI`;
+- terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalog validity;
+- mandatory staged human-review closure for `UX-VS` and `UX-UI`;
 - review-impact propagation;
 - product behavior and acceptance alignment;
 - terminal coverage;
@@ -77,6 +76,6 @@ Write one immutable `prototype-confirmation.yaml` per set member. Pin the protot
 - responsive and accessibility review;
 - unresolved issues and required return node.
 
-For every confirmation check, use statuses `pending`, `pass`, `fail`, and `not-applicable`; record evidence, and require a non-empty product-terminal rationale for `not-applicable`. Use decisions `confirmed-for-handoff` and `changes-required`. A confirmation can pass only when its set and manifest statuses are `frozen`, registered checksums match, tool selection is valid, `UX-LF`, `UX-VS`, and `UX-UI` are human-approved for visual or interactive members, product reconciliation is `valid/aligned`, the impact assessment is `valid/ready-for-finalization`, every required check is `pass` or justified `not-applicable`, and blocking issues are empty. Require `human_approval.required: true`, the latest review session for each applicable Gate `approved`, all comments terminal, all adjustments linked, and the approved formal UI source revision equal to the final manifest revision. Set confirmation `status: valid` with `confirmed_at` when confirmed; use `status: invalid` for `changes-required`. A genuinely non-visual terminal may mark visual Gates `not-applicable`; it must not use that exception for any member with user-operable interaction.
+For every confirmation check, use statuses `pending`, `pass`, `fail`, and `not-applicable`; record evidence, and require a non-empty product-terminal rationale for `not-applicable`. Use decisions `confirmed-for-handoff` and `changes-required`. A confirmation can pass only when the revision is `frozen`, registered checksums and revision validation match, tool selection is valid, `UX-VS` and `UX-UI` are human-approved for every visual or interactive terminal, product reconciliation is `valid/aligned`, the impact assessment is `valid/ready-for-finalization`, every required check is `pass` or justified `not-applicable`, and blocking issues are empty. Require `human_approval.required: true`, the latest review session for each applicable Gate `approved`, all comments terminal, all adjustments linked, and the approved formal UI source revision equal to the frozen revision's source revision. Set confirmation `status: valid` with `confirmed_at` when confirmed; use `status: invalid` for `changes-required`. A genuinely non-visual terminal may mark visual Gates `not-applicable`; it must not use that exception for any terminal with user-operable interaction.
 
-Downstream consumers must create separate receipts per prototype-set member and pin the source-confirmation version and checksum; they must not modify the frozen set, manifest, linked catalogs, or source confirmation. A rejected receipt creates a new affected prototype version and a new set version, then marks dependent experience, architecture, planning, and test artifacts stale as applicable.
+Downstream consumers pin the source-confirmation version/checksum and exact Prototype revision; they must not modify the frozen revision, linked catalogs, or source confirmation. A rejected receipt returns to the same current Prototype source, produces a new revision, and marks dependent experience, architecture, planning, and test artifacts stale as applicable.

package/skills/ai-delivery-design-experience/references/prototype-management-contract.md

@@ -2,15 +2,15 @@
 
 ## Tool Selection Gate
 
-Reserve a stable `prototype_artifact_id` for each prototype-set member before authoring. Inspect the current product scope, terminals, fidelity, collaboration, offline, version-control, interaction, review, and delivery constraints. Record every considered option in one member-scoped `prototype-tool-candidates-<prototype_artifact_id>.csv`:
+Reserve the project's stable `prototype_id` before authoring. Inspect the current product scope, terminals, fidelity, collaboration, offline, version-control, interaction, review, and delivery constraints. Record every considered option in one project-scoped `prototype-tool-candidates.csv`:
 
-`candidate_id,prototype_artifact_id,tool_name,tool_kind,availability,availability_evidence,fit_level,fit_rationale,recommendation_rank`
+`candidate_id,prototype_id,tool_name,tool_kind,availability,availability_evidence,fit_level,fit_rationale,recommendation_rank`
 
 Use `authoring-tool` and `design-assistant` for `tool_kind`; use `available`, `unavailable`, and `unknown` for availability; use `high`, `medium`, and `low` for fit. Figma, Pencil, and local HTML are authoring tools when available. A skill such as `ui-ux-pro-max-skill` is a design assistant, not a source-file or review-bundle manager.
 
 Verify availability instead of assuming installation or access. For a project skill, inspect the project-scoped `.agents/skills/` installation. If the selected skill is unavailable, install it only under the current project's `.agents/skills/` after explicit user selection; never install it globally.
 
-Recommend options with evidence, then ask the user to select one authoring tool and any optional design assistants for that member. Record the choice in `prototype-tool-selection-<prototype_artifact_id>.yaml`. The selection gate passes only with `status: valid`, `decision: selected`, a human `selected_by` and `selected_at`, an `available` selected authoring candidate, and a matching candidate-catalog checksum. Do not create prototype source, pages, canvases, or files before this gate passes. A tool change creates a new selection version and marks affected prototype artifacts stale.
+Recommend options with evidence, then ask the user to select one authoring tool and any optional design assistants for the Prototype. Record the choice in `prototype-tool-selection.yaml`. The selection gate passes only with `status: valid`, `decision: selected`, a human `selected_by` and `selected_at`, an `available` selected authoring candidate, and a matching candidate-catalog checksum. Do not create prototype source, pages, canvases, or files before this gate passes. A tool change creates a new selection version and marks the affected Prototype revision stale.
 
 ## Stable Page Identity
 
@@ -21,48 +21,69 @@ Use separate fields for identity and display:
 
 Main page IDs match `^P[0-9]{2,}$`; child page IDs match `^P[0-9]{2,}-[0-9]{2,}$`. Do not create third-level IDs. Allocate a page ID only for an independent route or independently reviewable business page. Model dialogs, loading, empty, error, permission, disabled, success, partial, and recovery variants as elements or states unless they are independently routed pages.
 
-Store all pages in member-scoped `page-catalog-<prototype_artifact_id>.csv`. Derive `display_label` from `page_id + "-" + page_name`; never parse identity from the label. Rename by changing `page_name` and `display_label` only. Never renumber or reuse an ID. Mark removed pages `retired`; allocate new IDs after the greatest allocated sibling number.
+Store all Pages in `prototype-pages.csv`. Derive `display_label` from `page_id + "-" + page_name`; never parse identity from the label. Rename by changing `page_name` and `display_label` only. Never renumber or reuse an ID. Mark removed Pages `retired`; allocate new IDs after the greatest allocated sibling number.
 
-## Canvas And File Boundaries
+Store every directly reviewable condition in `prototype-review-scenes.csv` with an independent `RS0001` identity, owning Page, terminal, scene type, and trigger-condition reference. Store trigger definitions once in `prototype-trigger-conditions.csv`. A Review Scene receives a direct prototype route but not an independent production route.
 
-Use:
+## Terminal, Route, And Mapping Boundaries
 
-- `canvas-catalog-<prototype_artifact_id>.csv` for stable canvas identity and its owning main-page family;
-- `canvas-pages-<prototype_artifact_id>.csv` for normalized canvas-to-page membership;
-- `prototype-files-<prototype_artifact_id>.csv` for source files, authoring tool, revision, lifecycle, and review scope;
-- `prototype-file-terminals-<prototype_artifact_id>.csv` for normalized file-to-terminal membership.
+Keep all terminals in the same logical Prototype. `prototype-terminals.csv` declares each `terminal_id`, source entrypoint, build command, review base path, production base path, compatibility group, and lifecycle. Compatible independent entrypoints are allowed; separate Prototype identities are not.
 
-One canvas contains exactly one main-page family: one main page and any `Pxx-*` children. Never put different main pages on the same canvas. A large family may use multiple canvases while retaining the same `main_page_id`.
+`prototype-routes.csv` is the only route registry. A `prototype` route may target a Page or Review Scene. A `production` route targets a Page only. `ui-mapping.csv` is the only bidirectional association among Page/Review Scene, prototype route, production Page route, frontend source, and acceptance ID. Do not repeat paths or mappings in Page, Review Scene, or revision manifests.
 
-Split prototype files when terminals, selected authoring tools, permissions, freeze/review lifecycles, or independent delivery boundaries differ. A file may contain multiple canvases only when those boundaries are shared. Use stable IDs and explicit catalog rows; never infer page, canvas, file, or terminal relationships from names or design-tool hierarchy. Retire IDs instead of deleting or reusing them.
+The frozen Review Shell entrypoint must consume Workflow Manager's `review_path` query parameter and render the matching active path from `prototype-routes.csv`. Treat an absent, unknown, retired, or cross-terminal path as an explicit not-found state. Relative CSS, JavaScript, font, and media references must remain runnable from the frozen entrypoint; Manager embeds only that checksummed content in a sandbox and never interprets product behavior.
+
+Legacy canvas/file catalogs are read-only compatibility inputs. When inspecting them, One canvas contains exactly one main-page family and stable identities remain immutable. Current authoring records source structure in the Prototype repository and normalized terminal/route catalogs instead of creating member-scoped canvas or file registries.
+
+## Production Frontend Scope
+
+Store one `frontend-change-scope.yaml` inside the frozen review bundle and bind its SHA-256 from `prototype-revision.yaml`. It declares the configured code root, non-empty frontend roots and UI file extensions, and production ownership entries for shared components and route registries. Shared-component entries use `source_ref`, `source_kind: file|directory`, and a non-empty normalized `page_ids` list. Every route-registry entry must name one file and add `approved_checksum`, the SHA-256 of the exact candidate file content approved with the Prototype revision. Every active UI Mapping and ownership source must fall inside a declared frontend root, and every file source must use an allowed UI extension; reject the entire scope rather than silently skipping a declared source. Keep direct Page and Review Scene files in `ui-mapping.csv`; use scope ownership only for production files that genuinely affect more than one mapped unit or own route registration. The local pre-write check validates Page ownership; the independent fixed-ref diff reads each changed route registry from the candidate Git object and rejects content that does not match its frozen checksum.
+
+Before any production frontend write, run `ai-delivery frontend-guard check-file` for the exact path. The guard validates the unexpired Visual Standard, frozen revision and scope checksum, active UI Mapping, and current Page receipts. A new file, removed file, copy, style, responsive rule, accessibility correction, defect fix, shared component, or route change follows the same rule. Missing coverage, pending review, changes requested, stale evidence, or checksum drift fails closed. The Hook invokes the same project runtime, but its result is not formal verification.
+
+At independent review and CI, run `ai-delivery frontend-guard verify-diff` from a fixed base Git ref to the candidate head. It reads the nested code repository diff directly and revalidates the exact revision, receipts, and ownership; Hook logs or prior local success are never accepted as proof. A scope entry affects only its declared Page IDs, so one approved Page cannot authorize a different pending Page.
+
+## Page Review State
+
+Register every active Page and Review Scene in `prototype-review-units.csv`. A Review Unit has a stable identity, kind (`page`, `review-scene`, or `shared-component`), checksummed Prototype source reference, and lifecycle status. Store each Unit-to-Page association as one normalized row in `prototype-review-unit-pages.csv`; never encode multiple Page IDs in one field. Each active Page and Review Scene requires its own active Review Unit; a shared component has one association row for every affected Page. The Page checksum covers its Page row, Review Scenes, trigger conditions, prototype and production routes, UI Mapping rows, Page source units, shared-component units and their Page associations, and the approved Visual Standard.
+
+The only Page Review Status values are `approved`, `pending-review`, `changes-requested`, and `stale`. Derive them from immutable Page review receipts, never from a mutable UI field or a global review decision. Each receipt binds a human actor, exact Prototype revision identity and checksum, Page checksum, Scene checksums, evidence-domain checksums, decision time, rationale, and optional comment. The browser writes decisions only through Workflow Manager's allowlisted Page-review action; it must not edit YAML, workflow state, or review receipts directly.
+
+For a new Prototype revision, inspect Page decisions only along its checksum-validated `previous_revision` ancestor chain, nearest ancestor first. Never inherit from a descendant or unrelated revision. Carry the selected prior decision forward only when it is `approved` and the complete Page checksum is identical. Preserve an unchanged latest `changes-requested` decision on that ancestor; if any bound evidence changes, derive `stale` and report the changed evidence domains. Any content or catalog drift invalidates the active review session before a decision is written.
+
+When the user approves the final pending Page, label the action `Approve Page and complete UX-UI`. Write that Page receipt and the `UX-UI` Gate decision in one atomic formal-state transaction, binding both to the same human actor, iteration, Prototype revision, and receipt checksum. A failure must leave both the receipt and Gate decision unwritten.
+
+After `UX-UI` is approved and no new `UX-UI` request is pending, close the controlled Page-decision API for that iteration. Any later requested UI change starts from a new immutable Prototype revision and a new formal Gate request; never append a receipt that would diverge from an already approved Gate.
 
 ## Mandatory Staged Human Review
 
-Every visual or interactive member requires human review at `UX-LF`, `UX-VS`, and `UX-UI`. Record `human_review_required: true` in `prototype-review-decision-<prototype_artifact_id>.yaml`; `contract-only` is permitted only for a genuinely non-visual `not-applicable` member.
+Every visual or interactive Prototype revision requires human review at `UX-VS` and `UX-UI`. Record `human_review_required: true` in `prototype-review-decision.yaml`; `contract-only` is permitted only when every covered terminal is genuinely non-visual and `not-applicable`.
 
 For each staged Gate:
 
-1. Record every round in `prototype-review-sessions-<prototype_artifact_id>.csv`, pinning the Gate, reviewed source revision, and evidence.
-2. Record every comment in `prototype-review-comments-<prototype_artifact_id>.csv` with page, canvas, file, element, classification, severity, responsible node, and evidence.
+1. Record every round in `prototype-review-sessions.csv`, pinning the Gate, reviewed source revision, affected Page and Review Scene identities, and evidence.
+2. Record every comment in `prototype-review-comments.csv` with Page, Review Scene, element, classification, severity, responsible node, and evidence.
 3. Use classifications `design-correction`, `requirement-change`, `architecture-impact`, and `clarification`; every concrete adjustment additionally uses one or more normalized domains from `experience-change-domains.csv`.
 4. Use terminal comment statuses `resolved`, `rejected-with-rationale`, and `superseded`; open work uses `open`.
-5. Record every prototype revision caused by a comment in `prototype-adjustment-log-<prototype_artifact_id>.csv`, including classification, reason, linked requirement/experience changes, upstream/downstream impacts, and evidence. Never overwrite an earlier revision or omit an adjustment because it appears visual-only.
+5. Record every source revision caused by a comment in `prototype-adjustment-log.csv`, including classification, reason, linked requirement/experience changes, upstream/downstream impacts, and evidence. Never overwrite an earlier revision or omit an adjustment because it appears visual-only.
 6. Require another review round after adjustments. Exit the Gate only when the latest session decision is `approved`, every comment is terminal, and the Gate receipt pins the approved revision and checksums.
 
-Set source confirmation `human_approval.required: true` and pin the final approver, decision time, approved formal UI revision, and exact set/member/Gate checksums. The approved revision must equal the manifest's final source revision.
+Set source confirmation `human_approval.required: true` and pin the final approver, decision time, approved formal UI source revision, and exact Prototype revision/Gate checksums. The approved source revision must equal the frozen Prototype revision's source revision.
 
 ## Impact Propagation
 
-Write `prototype-impact-assessment-<prototype_artifact_id>.yaml` after comments are classified and update it after every round. A `design-correction` updates experience artifacts only. A `clarification` updates only the artifacts named by its assessment without changing behavior. A `requirement-change` returns to product definition and creates a new product baseline before final prototype freeze. An `architecture-impact` returns to architecture and creates or validates the required architecture baseline before final prototype freeze.
+Write `prototype-impact-assessment.yaml` after comments are classified and update it after every round. A `design-correction` updates experience artifacts only. A `clarification` updates only the artifacts named by its assessment without changing behavior. A `requirement-change` returns to product definition and creates a new product baseline before final prototype freeze. An `architecture-impact` returns to architecture and creates or validates the required architecture baseline before final prototype freeze.
 
 Keep revised prototypes in `review-draft` while upstream change obligations remain open. Mark dependent artifacts stale, rerun affected nodes, and then revise the prototype from the new immutable inputs. The impact assessment passes with `status: valid` and `decision: ready-for-finalization` only when all required rebaselines resolve, stale impacts are declared, and blocking issues are empty.
 
 ## Final Product Reconciliation
 
-After every visual or interactive member reaches `candidate-approved`, aggregate all adjustments. Link every semantic adjustment to `requirement-change-set.csv`; use statuses `identified`, `product-triage`, `awaiting-product-confirmation`, `approved`, `rejected`, `product-baseline-updated`, `impact-propagated`, `prototype-rebased`, and `closed`.
+After every affected Page and Review Scene reaches `candidate-approved`, aggregate all adjustments. Link every semantic adjustment to `requirement-change-set.csv`; use statuses `identified`, `product-triage`, `awaiting-product-confirmation`, `approved`, `rejected`, `product-baseline-updated`, `impact-propagated`, `prototype-rebased`, and `closed`.
 
-Invoke product definition once for the complete candidate set. Product compares the approved baseline and prototype bidirectionally through `prototype-product-coverage.csv` and owns `product-prototype-reconciliation.yaml`. A rejected requirement change requires removal or correction of the prototype behavior. A changed product baseline makes affected members stale and requires their staged re-approval. Repeat until decision `aligned`; do not freeze by merely editing product documentation to match the prototype.
+Invoke product definition once for the complete candidate revision. Product compares the approved baseline and Prototype bidirectionally through `prototype-product-coverage.csv` and owns `product-prototype-reconciliation.yaml`. A rejected requirement change requires removal or correction of the Prototype behavior. A changed product baseline makes affected Pages and Review Scenes stale and requires their staged re-approval. Repeat until decision `aligned`; do not freeze by merely editing product documentation to match the Prototype.
 
 ## Final Freeze
 
-The final manifest pins SHA-256 checksums for tool selection, page/canvas/file catalogs, every staged Gate, visual system, interaction/component contracts, review session/comment/adjustment catalogs, change sets, final product reconciliation, and impact assessment. Source confirmation and UI handoff may pass only when all staged reviews are approved and closed, reconciliation is aligned, change sets are terminal, page/canvas/file rules pass, and impact assessment is ready.
+The final `prototype-revision.yaml` pins SHA-256 checksums for the source revision, Review Shell bundle, terminal/Page/Review Scene/trigger/route/UI Mapping catalogs, every staged Gate, visual system, review evidence, change sets, final product reconciliation, and impact assessment. Run `ai-delivery prototype-revision validate` before registration. Source confirmation and UI handoff may pass only when all staged reviews are approved and closed, reconciliation is aligned, change sets are terminal, normalized catalog rules pass, and impact assessment is ready.
+
+If a Review Scene uses a Mock System, the same Prototype revision must bind one formally registered immutable Mock Scenario Pack. The Pack maps every active Review Scene to exactly one contract-validated scenario, distinguishes External Dependency Mock from Product Backend Mock, binds approved contracts and replacement conditions, and records data classification and sanitization evidence. Managed UI runtime changes are never authoritative before each actual OpenAPI/AsyncAPI export file is SHA-256-bound and protocol/scenario-validated, followed by human confirmation of the candidate checksum, freeze, and formal registration. Mock success is not real backend or end-to-end acceptance evidence.

package/skills/ai-delivery-design-tests/SKILL.md

@@ -9,7 +9,11 @@ Create a durable release strategy once and detailed test inputs just in time for
 
 ## Artifact Location
 
-Write every workflow document produced by this skill under project `.workflow/`, defaulting version-scoped test design outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Automated test source remains in the repository test structure defined by the architecture and work package.
+Write every workflow document produced by this skill under project `.workflow/`, defaulting version-scoped test design outputs to `.workflow/iterations/<iteration-id>/03-delivery-readiness/`. Automated test source remains in the repository test structure defined by the architecture and work package.
+
+## Development Node
+
+This Skill owns test-design task phases inside `03-delivery-readiness`; it does not create a separate formal test-design node. Its public seams, acceptance examples, quality Gates, data plan, and environment plan join planning and platform evidence before scope freeze. Reuse an unaffected approved release test strategy by exact identity and checksum, but create or confirm the current Slice's public test contract before Delivery Readiness completes.
 
 ## Task State
 
@@ -19,21 +23,21 @@ Write every workflow document produced by this skill under project `.workflow/`,
 
 ## Preflight
 
-Read the selected vertical slice, product acceptance criteria, exact `ui-handoff.yaml`, `product-prototype-reconciliation.yaml`, experience and requirement change sets, interaction contract, component-state matrix, page-component map, design tokens, frozen prototype set and checksum, every member manifest, tool-selection and page/canvas/file catalogs, review and impact records, source confirmation, architecture validation receipt, final architecture, confirmed public test seams, quality budgets, prior defects, applicable standards, and existing test strategy. Require `UX-LF`, `UX-VS`, and `UX-UI` to be human-approved, product reconciliation to be `aligned`, UI handoff development readiness to be `ready-for-development`, source confirmations to be `valid/confirmed-for-handoff`, and architecture receipts to be `valid/accepted`. Reject missing member receipts, nonterminal change rows, or mismatched IDs, versions, revisions, management/review checksums, or review-bundle checksums.
+Read the selected vertical slice, product acceptance criteria, exact `ui-handoff.yaml`, `product-prototype-reconciliation.yaml`, experience and requirement change sets, interaction contract, component-state matrix, page-component map, design tokens, the exact immutable Prototype revision and checksum, its source and review-bundle checksums, the normalized terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs, review and impact records, source confirmation, architecture validation receipt, final architecture, confirmed public test seams, quality budgets, prior defects, applicable standards, and existing test strategy. Require `UX-VS` and `UX-UI` to be human-approved, product reconciliation to be `aligned`, UI handoff development readiness to be `ready-for-development`, source confirmation to be `valid/confirmed-for-handoff`, and the architecture receipt to be `valid/accepted`. Reject a missing receipt, nonterminal change row, missing or conflicting catalog reference, or mismatched identity, revision, or checksum. Never infer a relationship from a file name or catalog order.
 
 ## Workflow
 
 1. Establish or update the overall release test strategy and risk model.
 2. Confirm observable public interfaces and test seams. Never prescribe tests against private implementation details.
 3. Derive behavior examples from independent requirements and acceptance sources. Use the prototype to locate interactions and states, but never treat appearance alone as a product requirement.
-4. Map every prototype-set member to `included` or `out-of-scope` in `prototype-test-scope.csv` using selected slice and terminal evidence.
-5. Verify that every in-scope page, prototype interaction, component state, and `ready-for-development` experience change is observable and testable through a confirmed public seam. Write one `prototype-test-validation.yaml` per included member with the UI handoff and product-reconciliation checksums, `affected_experience_change_ids`, stable page/canvas/file/element IDs, and all management/review checksums. An accepted receipt uses `status: valid`; a `changes-required` receipt uses `status: invalid`. Accept the handoff only when every included member passes and every exclusion is justified; return untestable or ambiguous behavior to experience or architecture.
+4. Resolve every affected terminal, Page, Review Scene, UI component, frontend source, and acceptance ID from the pinned UI Mapping. Map each affected Page and Review Scene to `included` or `out-of-scope` in `prototype-test-scope.csv` using selected Slice and terminal evidence.
+5. Verify that every included Page, Review Scene, prototype interaction, component state, acceptance criterion, and `ready-for-development` experience change is observable and testable through a confirmed public seam. Write one `prototype-test-validation.yaml` for the Prototype revision with the UI handoff, product-reconciliation, Prototype revision, UI Mapping, and normalized catalog checksums; `affected_experience_change_ids`; and the affected stable identities. An accepted receipt uses `status: valid`; a `changes-required` receipt uses `status: invalid`. Accept the handoff only when the receipt passes and every exclusion is justified; return untestable or ambiguous behavior to experience or architecture.
 6. Define the current iteration's functional, contract, data, security, performance, compatibility, accessibility, responsive, and visual-regression obligations. Trace behavior, visual-regression, responsive, and accessibility cases to each affected `experience_change_id`.
 7. Define test data, environment, automation, entry, exit, severity, and quality-gate rules.
 8. Separate developer-visible obligations from independent verification:
    - publish acceptance examples, seams, contract expectations, and quality targets to development;
    - leave adversarial, exploratory, cross-component, regression, and additional edge cases for candidate verification.
-9. Trace every obligation to stable requirement, feature, page, canvas, prototype file, prototype element, risk, and architecture IDs.
+9. Trace every obligation to stable requirement, feature, Page, Review Scene, prototype-element, UI Mapping, UI component, frontend-source, acceptance, risk, and architecture IDs.
 
 ## Outputs
 
@@ -42,15 +46,17 @@ Read the selected vertical slice, product acceptance criteria, exact `ui-handoff
 - public behavior examples and contract fixtures;
 - `test-data-plan.md` and `test-environment-plan.md`;
 - `quality-gates.yaml`;
-- one prototype test-validation YAML per relevant prototype-set member;
+- one prototype test-validation YAML for the pinned Prototype revision;
 - `prototype-test-scope.csv`;
 - test traceability CSV files including `experience_change_id` coverage;
 - gaps returned to product, experience, architecture, or planning.
 
+For UI-bearing scope, the public test contract requires Candidate Assurance to run `ai-delivery ui-acceptance plan` and `verify`, cover every affected Review Scene at the approved Visual Standard breakpoints, retain prototype/candidate/diff evidence, and block on visual ratio, WCAG 2.2 AA, keyboard, focus, touch-target, text-overflow, responsive, recovery, protocol, or Mock authority failures. State whether External Dependency Mock is allowed and require separate real backend evidence whenever Product Backend Mock drives rendering.
+
 Do not implement product code or claim independent release acceptance.
 
 Read [test-design-contract.md](references/test-design-contract.md) and use `assets/test-design-template/` for new files.
 
 ## Handoff
 
-Development receives the exact ready UI handoff, aligned product reconciliation, actionable experience changes, prototype-set identity/checksum, and relevant member identities/checksums with the public contract, validates that all are actionable, and returns missing seams or ambiguous expectations here. Independent verification later derives additional cases from the approved sources and candidate behavior.
+Development receives the exact ready UI handoff, aligned product reconciliation, actionable experience changes, Prototype revision/checksum, UI Mapping checksum, normalized catalog checksums, and affected stable identities with the public contract, validates that all are actionable, and returns missing seams or ambiguous expectations here. Independent verification later derives additional cases from the approved sources and candidate behavior.

package/skills/ai-delivery-design-tests/assets/test-design-template/prototype-test-scope.csv

@@ -1 +1 @@
-prototype_artifact_id,prototype_version,terminal_id,slice_id,scope_status,rationale,evidence_ref
+prototype_revision_id,terminal_id,slice_id,page_id,review_scene_id,scope_status,rationale,evidence_ref

package/skills/ai-delivery-design-tests/assets/test-design-template/prototype-test-validation.yaml

@@ -9,8 +9,7 @@ input_artifacts:
   product_prototype_reconciliation: PRODUCT-PROTOTYPE-RECONCILIATION-0001@1
   experience_change_set: EXPERIENCE-CHANGE-SET-0001@1
   interaction_contract: INTERACTION-CONTRACT-0001@1
-  prototype_set: PROTOTYPE-SET-0001@1
-  prototype_manifest: PROTOTYPE-0001@1
+  prototype_revision: PROTOTYPE-REVISION-0001@1
   prototype_confirmation: PROTOTYPE-CONFIRMATION-0001@1
   architecture_validation: PROTOTYPE-ARCH-VALIDATION-0001@1
   prototype_tool_selection: PROTOTYPE-TOOL-SELECTION-0001@1
@@ -25,23 +24,23 @@ experience_change_set_ref: EXPERIENCE-CHANGE-SET-0001@1
 experience_change_set_checksum: REPLACE_WITH_SHA256
 interaction_contract_ref: INTERACTION-CONTRACT-0001@1
 interaction_contract_checksum: REPLACE_WITH_SHA256
-prototype_set_ref: PROTOTYPE-SET-0001@1
-prototype_set_checksum: REPLACE_WITH_SHA256
-prototype_artifact_id: PROTOTYPE-0001
-prototype_version: 1
-prototype_manifest_ref: prototype-manifest-PROTOTYPE-0001.yaml
-prototype_manifest_checksum: REPLACE_WITH_SHA256
+prototype_revision_ref: PROTOTYPE-REVISION-0001@1
+prototype_revision_checksum: REPLACE_WITH_SHA256
+prototype_id: PROTOTYPE
+prototype_revision_version: 1
 prototype_confirmation_ref: PROTOTYPE-CONFIRMATION-0001@1
 prototype_confirmation_checksum: REPLACE_WITH_SHA256
-source_revision: REVISION-0001
-review_bundle_algorithm: sha256
+source_revision: REPLACE_WITH_IMMUTABLE_SOURCE_REVISION
+source_checksum: REPLACE_WITH_SHA256
+review_bundle_algorithm: sha256-tree-v1
 review_bundle_checksum: REPLACE_WITH_SHA256
 tool_selection_checksum: REPLACE_WITH_SHA256
+terminal_catalog_checksum: REPLACE_WITH_SHA256
 page_catalog_checksum: REPLACE_WITH_SHA256
-canvas_catalog_checksum: REPLACE_WITH_SHA256
-canvas_pages_checksum: REPLACE_WITH_SHA256
-prototype_files_checksum: REPLACE_WITH_SHA256
-prototype_file_terminals_checksum: REPLACE_WITH_SHA256
+review_scene_catalog_checksum: REPLACE_WITH_SHA256
+trigger_condition_catalog_checksum: REPLACE_WITH_SHA256
+route_catalog_checksum: REPLACE_WITH_SHA256
+ui_mapping_checksum: REPLACE_WITH_SHA256
 prototype_review_decision_checksum: REPLACE_WITH_SHA256
 prototype_review_sessions_checksum: REPLACE_WITH_SHA256
 prototype_review_comments_checksum: REPLACE_WITH_SHA256
@@ -61,9 +60,11 @@ test_contract_checksum: REPLACE_WITH_SHA256
 decision: changes-required
 affected_experience_change_ids: []
 affected_page_ids: []
-affected_canvas_ids: []
-affected_prototype_file_ids: []
+affected_review_scene_ids: []
+affected_ui_mapping_ids: []
 affected_prototype_element_ids: []
+affected_ui_component_ids: []
+affected_acceptance_ids: []
 observable_seams: []
 untestable_elements: []
 ambiguity_findings: []

package/skills/ai-delivery-design-tests/references/test-design-contract.md

@@ -2,7 +2,7 @@
 
 ## Public Iteration Contract
 
-Include selected slice IDs, exact `ui-handoff.yaml` identity/checksum, aligned `product-prototype-reconciliation.yaml` identity/checksum, applicable experience-change IDs and statuses, exact prototype-set identity/checksum, relevant member identities/review-bundle checksums, tool-selection and page/canvas/file catalog checksums, review/adjustment/impact checksums, interaction and component-state contract checksums, confirmed public seams, acceptance examples, API/data contracts, required developer automation, test data needs, quality targets, entry criteria, exit criteria, and traceability.
+Include selected Slice IDs, exact `ui-handoff.yaml` identity/checksum, aligned `product-prototype-reconciliation.yaml` identity/checksum, applicable experience-change IDs and statuses, exact Prototype revision/checksum, source and review-bundle checksums, UI Mapping and normalized catalog checksums, review/adjustment/impact checksums, interaction and component-state contract checksums, confirmed public seams, acceptance examples, API/data contracts, required developer automation, test data needs, quality targets, entry criteria, exit criteria, and traceability.
 
 Do not publish the full independent verification case set before implementation. Candidate verification must derive additional adversarial, exploratory, edge, cross-component, and regression cases independently.
 
@@ -10,13 +10,15 @@ Do not publish the full independent verification case set before implementation.
 
 For every gate record ID, scope, command or measurement, threshold, blocking behavior, evidence path, and owner stage. Do not use coverage percentage alone as proof of behavior.
 
+For every UI-bearing iteration, the approved test strategy explicitly controls External Dependency Mock use during Candidate Assurance and requires separate real product backend evidence when Product Backend Mock drives deterministic UI rendering. The iteration contract requires `ui-acceptance plan` and `verify` against the immutable candidate, complete affected Page/Review Scene coverage at approved Visual Standard breakpoints, a pinned Playwright environment, reviewable screenshot diffs, and blocking WCAG 2.2 AA, keyboard, focus, touch-target, text-overflow, responsive, recovery, and protocol results.
+
 ## Test Design Rules
 
 - Verify observable behavior through public interfaces.
 - Use expected results from approved specifications, worked examples, or independent sources.
 - Mock only external system boundaries when needed.
 - Trace every obligation to requirement, feature, acceptance, architecture, or risk IDs.
-- Trace prototype-derived interactions and states to `page_id`, `canvas_id`, `prototype_file_id`, and `prototype_element_id` without treating unapproved visual invention as a requirement.
+- Resolve and trace prototype-derived interactions and states to `terminal_id`, `page_id`, `review_scene_id`, `prototype_element_id`, `ui_mapping_id`, `ui_component_id`, `frontend_source_ref`, and `acceptance_id` through the pinned UI Mapping without treating unapproved visual invention as a requirement.
 - Trace behavior, visual-regression, responsive, and accessibility obligations to each affected `experience_change_id`; test only changes in `ready-for-development` state.
 - Define controlled data setup and cleanup.
 
@@ -24,8 +26,8 @@ For every gate record ID, scope, command or measurement, threshold, blocking beh
 
 `prototype-test-scope.csv`:
 
-`prototype_artifact_id,prototype_version,terminal_id,slice_id,scope_status,rationale,evidence_ref`
+`prototype_revision_id,terminal_id,slice_id,page_id,review_scene_id,scope_status,rationale,evidence_ref`
 
-Use `included` and `out-of-scope`. Create normalized rows when a member covers multiple terminal/slice pairs. Every prototype-set member must have at least one scope row; every exclusion requires a rationale and evidence.
+Use `included` and `out-of-scope`. Create normalized rows for affected terminal, Slice, Page, and Review Scene combinations. Every affected Page and Review Scene resolved from the UI Mapping must have a scope row; every exclusion requires a rationale and evidence.
 
-Produce one `prototype-test-validation.yaml` per included prototype-set member. Pin the UI handoff, aligned product reconciliation, experience change set, interaction contract, prototype-set version/checksum, member manifest version/checksum, source-confirmation version/checksum, architecture-validation version/checksum, final architecture baseline version/checksum, source revision, review-bundle checksum, tool-selection checksum, page/canvas/file catalog checksums, review decision/session/comment/adjustment checksums, impact-assessment checksum, linked coverage checksums, and test-contract ID/version/checksum. Require `UX-LF`, `UX-VS`, and `UX-UI` approval, `ready-for-development`, upstream confirmation `valid/confirmed-for-handoff`, and architecture receipt `valid/accepted`. Record decision (`accepted` or `changes-required`), `affected_experience_change_ids`, affected page/canvas/file/element IDs, observable seams, untestable elements, ambiguity findings, accessibility coverage, evidence, and return node. Use receipt `status: valid` only with `accepted`, otherwise `status: invalid`. Reject missing member scope rows/receipts or mismatched identities and route corrections to the owning node.
+Produce one `prototype-test-validation.yaml` for the exact Prototype revision. Pin the UI handoff, aligned product reconciliation, experience change set, interaction contract, Prototype revision/checksum, source-confirmation version/checksum, architecture-validation version/checksum, final architecture baseline version/checksum, source revision, source and review-bundle checksums, UI Mapping checksum, normalized catalog checksums, review decision/session/comment/adjustment checksums, impact-assessment checksum, linked coverage checksums, and test-contract ID/version/checksum. Require `UX-VS` and `UX-UI` approval, `ready-for-development`, upstream confirmation `valid/confirmed-for-handoff`, and architecture receipt `valid/accepted`. Record decision (`accepted` or `changes-required`), `affected_experience_change_ids`, affected Page/Review Scene/prototype-element/UI Mapping/UI component/frontend-source/acceptance IDs, observable seams, untestable elements, ambiguity findings, accessibility coverage, evidence, and return node. Use receipt `status: valid` only with `accepted`, otherwise `status: invalid`. Reject missing scope rows or receipts, or missing/conflicting identities, and route corrections to the owning node. Never infer a relationship from a file name or catalog order.

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

@@ -9,7 +9,11 @@ Derive technical tasks just in time. Do not predefine frontend, backend, databas
 
 ## Artifact Location
 
-Write every planning, traceability, review, evidence, and candidate document produced by this skill under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/<node-id>/`. Application source, automated test source, and non-document build artifacts remain in their architecture-defined repository or artifact locations.
+Write every planning, traceability, review, evidence, and candidate document produced by this skill under project `.workflow/`, defaulting version-scoped outputs to `.workflow/iterations/<iteration-id>/04-implementation/`. Application source, automated test source, and non-document build artifacts remain in their architecture-defined repository or artifact locations.
+
+## Development Node
+
+This Skill owns `04-implementation`. Package planning, implementation, review, triage, repair, developer tests, and merge are phases of stable logical tasks inside this node, not separate formal nodes. The node completes only after all required tasks succeed and `candidate-selected` records one immutable candidate whose exact identity is retained as completion evidence.
 
 ## Task State
 
@@ -19,7 +23,9 @@ Write every planning, traceability, review, evidence, and candidate document pro
 
 ## Preflight
 
-Read the selected vertical slice, exact ready `ui-handoff.yaml`, aligned `product-prototype-reconciliation.yaml`, experience/requirement change sets, interaction contract, component-state matrix, page-component map, exact prototype set and relevant member manifests/review bundles, tool-selection and page/canvas/file catalogs, review/impact records, prototype confirmations and downstream receipts, public test contract, final architecture, experience baseline, applicable standards, repository state, active defects, and platform constraints. Require `development_readiness: ready-for-development`, source confirmations `valid/confirmed-for-handoff`, architecture receipts `valid/accepted`, and test receipts `valid/accepted`. Validate stable references, complete relevant member receipts, matching set/member IDs/revisions, management/review/impact checksums, review-bundle checksums, and confirmed public test seams. Reject `proposed`, `blocked`, `stale`, or otherwise non-actionable experience changes.
+Read the selected vertical Slice, exact ready `ui-handoff.yaml`, aligned `product-prototype-reconciliation.yaml`, experience/requirement change sets, interaction contract, component-state matrix, page-component map, exact Prototype revision and checksum, source and review-bundle checksums, revision-bound `frontend-change-scope.yaml`, normalized terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs, review/impact records, prototype confirmation and downstream receipts, public test contract, final architecture, experience baseline, applicable standards, repository state, active defects, and platform constraints. Require `development_readiness: ready-for-development`, source confirmation `valid/confirmed-for-handoff`, architecture receipt `valid/accepted`, and test receipt `valid/accepted`. Validate stable references, matching Prototype revision, frontend scope, and UI Mapping checksums, review/impact checksums, and confirmed public test seams. Reject missing or conflicting references and `proposed`, `blocked`, `stale`, or otherwise non-actionable experience changes. Never infer a relationship from a file name or catalog order.
+
+For UI-bearing scope, pin the exact frozen Mock Scenario Pack identity and checksum in `candidate-manifest.yaml` together with the Prototype revision and UI Mapping. Never mutate or retarget any of those bindings after the candidate becomes immutable.
 
 ## Derive Work Packages
 
@@ -28,7 +34,7 @@ Resolve the only code repository from `.workflow/config/workspace.yaml`. Put sou
 1. Analyze impacted components, contracts, data, configuration, infrastructure, security, and documentation.
 2. Produce the smallest dependency graph of technical work packages that can deliver the vertical slice.
 3. Define a capability-based role per package. Combine related capabilities when safe; create specialized roles only when the work requires them.
-4. Declare objective, inputs, relevant `experience_change_id` values, page/canvas/file/element IDs, exact prototype-set and member identities, allowed and forbidden modification scope, dependencies, stack and commands, TDD seam, outputs, completion evidence, risks, and rollback considerations.
+4. Resolve the affected Page, Review Scene, UI component, frontend source, and acceptance IDs through the pinned UI Mapping and frontend scope. Declare objective, inputs, relevant `experience_change_id` values, exact Prototype revision, frontend scope, and UI Mapping identities, terminal/Page/Review Scene/prototype-element/component/frontend-source/acceptance IDs, allowed and forbidden modification scope, dependencies, stack and commands, TDD seam, outputs, completion evidence, risks, and rollback considerations.
 5. Map every UI-bearing package to `task-experience-change-traceability.csv`. Derive `implementation_action` from the structured change contract using only `create|update|remove|migrate|no-code`; never infer whether work is new or modified from a visual diff or filename.
 6. Prevent parallel packages from owning overlapping write scopes. Serialize or revise boundaries when they overlap.
 7. Assign a stable execution sequence, write the complete technical work package and dependency CSV files, then register every package as a `queued` `$ai-delivery-checkpoint-task` snapshot. Do not execute the first package until the complete derived group is recoverable.
@@ -36,12 +42,13 @@ Resolve the only code repository from `.workflow/config/workspace.yaml`. Put sou
 
 ## Execute And Converge
 
-1. Invoke `$ai-delivery-execute-work-package` for each ready package.
-2. Invoke `$ai-delivery-review-change` from an independent validation context before merge.
-3. Return failed reviews to the package executor; never let the reviewer patch the code.
-4. Merge passing work packages into the iteration branch through `$ai-delivery-manage-git` and required CI gates.
-5. Run slice-level build, public contract tests, and developer regression checks.
-6. Produce a new immutable candidate identity whenever code, migration, configuration, IaC, or dependencies change.
+1. Invoke `$ai-delivery-execute-work-package` for each ready package. For every production UI path, require `ai-delivery frontend-guard check-file <workspace> --path <path>` immediately before its first write; missing current Prototype approval or UI Mapping coverage stops the package.
+2. Invoke `$ai-delivery-review-change` from an independent validation context before merge. Complete its feedback collection across all axes with no implementation mutation.
+3. Group the collected findings into an approved change set with a stable `change_set_id`. Return that whole set to the package executor; never let the reviewer patch the code or trigger finding-by-finding repair.
+4. Apply only the approved set in a repair phase, attach evidence to every finding, then run one concentrated rereview. A new finding begins another feedback collection and approved change set.
+5. Before merge, run `ai-delivery frontend-guard verify-diff <workspace> --base <fixed-base> --head <candidate-head>` for every UI-bearing diff. This independent Git diff check is required even when the local Hook ran successfully; then merge passing work packages through `$ai-delivery-manage-git` and the remaining CI gates.
+6. Run slice-level build, public contract tests, and developer regression checks.
+7. Produce a new immutable candidate identity whenever code, migration, configuration, IaC, or dependencies change.
 
 ## TDD Policy
 
@@ -57,9 +64,9 @@ Require TDD for business behavior, defect fixes, and contracts. Allow documented
 - retained tests and Red/Green evidence;
 - independent review results and resolutions;
 - slice traceability and known limitations;
-- buildable candidate commit and candidate manifest.
+- buildable candidate commit and `candidate-manifest.yaml`, with exact Prototype revision, UI Mapping, handoff, reconciliation, and task-traceability checksums for every UI-bearing candidate.
 
-Read [development-contract.md](references/development-contract.md).
+Read [development-contract.md](references/development-contract.md) and use `assets/development-template/` for traceability and candidate files.
 
 ## Handoff
 

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

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Develop Iteration"
-  short_description: "Orchestrate dynamic technical work packages with TDD"
+interface:
+  display_name: "Develop Iteration"
+  short_description: "Orchestrate dynamic technical work packages with TDD"
   default_prompt: "Use $ai-delivery-develop-iteration to implement the current vertical slice in the configured code repository."

package/skills/ai-delivery-develop-iteration/assets/development-template/candidate-manifest.yaml

@@ -0,0 +1,36 @@
+artifact_id: CANDIDATE-MANIFEST-0001
+artifact_type: iteration-candidate-manifest
+version: 1
+iteration_id: ITER-0001
+candidate_id: CANDIDATE-0001
+status: draft
+producer_skill: ai-delivery-develop-iteration
+repo_id: code
+code_commit: REPLACE_WITH_COMMIT_SHA
+code_tag: null
+source_path: .
+source_checksum: REPLACE_WITH_SHA256
+build_id: REPLACE_WITH_BUILD_ID
+artifact_digests: []
+configuration_baseline_ref: null
+migration_set_ref: null
+iac_ref: null
+source_task_ids: []
+standards_baseline_ref: STANDARDS-BASELINE-0001@1
+ui_handoff_ref: UI-HANDOFF-0001@1
+ui_handoff_checksum: REPLACE_WITH_SHA256
+product_prototype_reconciliation_ref: PRODUCT-PROTOTYPE-RECONCILIATION-0001@1
+product_prototype_reconciliation_checksum: REPLACE_WITH_SHA256
+prototype_revision_ref: PROTOTYPE-REVISION-0001@1
+prototype_revision_checksum: REPLACE_WITH_SHA256
+prototype_source_revision: REPLACE_WITH_IMMUTABLE_SOURCE_REVISION
+prototype_source_checksum: REPLACE_WITH_SHA256
+prototype_review_bundle_checksum: REPLACE_WITH_SHA256
+ui_mapping_checksum: REPLACE_WITH_SHA256
+mock_scenario_pack_ref: MOCK-SCENARIO-PACK-0001@1
+mock_scenario_pack_checksum: REPLACE_WITH_SHA256
+task_prototype_traceability_ref: task-prototype-traceability.csv
+task_prototype_traceability_checksum: REPLACE_WITH_SHA256
+task_experience_change_traceability_ref: task-experience-change-traceability.csv
+task_experience_change_traceability_checksum: REPLACE_WITH_SHA256
+created_at: null

package/skills/ai-delivery-develop-iteration/assets/development-template/task-prototype-traceability.csv

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

package/skills/ai-delivery-develop-iteration/references/development-contract.md

@@ -16,7 +16,7 @@
 
 `task-prototype-traceability.csv`:
 
-`task_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id`
+`task_id,prototype_revision_id,source_revision,terminal_id,page_id,review_scene_id,prototype_element_id,ui_mapping_id,ui_component_id,frontend_source_ref,acceptance_id`
 
 `task-experience-change-traceability.csv`:
 
@@ -28,11 +28,13 @@ Store detailed commands, expected outputs, risks, evidence, and rollback impact
 
 Before executing any package in the derived group, initialize one `queued` runtime snapshot per CSV row. Copy `sequence` directly and translate every `blocks` or `enables` predecessor edge into `depends_on`. Recovery must be able to identify all not-started packages without relying on chat history.
 
-For UI-bearing packages, record the exact UI handoff and aligned product-reconciliation checksums, experience change set checksum, prototype-set ID/version/checksum, every relevant member `prototype_artifact_id`, version, `source_revision`, `review_bundle_checksum`, tool-selection checksum, page/canvas/file catalog checksums, review/adjustment checksums, impact-assessment checksum, and normalized task-to-change plus task-to-page/canvas/file/element rows. Refuse implementation when development readiness is not `ready-for-development`, the set is incomplete, a mapped change is non-actionable, or any identity differs across experience confirmation, architecture validation, test validation, or iteration planning.
+For UI-bearing packages, record the exact UI handoff and aligned product-reconciliation checksums, experience change set checksum, Prototype revision/checksum, `source_revision`, source and review-bundle checksums, UI Mapping checksum, normalized catalog checksums, review/adjustment checksums, impact-assessment checksum, and normalized task-to-change plus task-to-terminal/Page/Review Scene/prototype-element/UI Mapping/UI component/frontend-source/acceptance rows. Refuse implementation when development readiness is not `ready-for-development`, a mapped change is non-actionable, a reference is missing or conflicting, or any identity differs across experience confirmation, architecture validation, test validation, iteration planning, or the current UI Mapping. Never infer relationships from file names or row order.
 
 ## Candidate Identity
 
-Record candidate ID, iteration ID, commit SHA, build ID, artifact digests, configuration baseline, migration set, IaC reference, source task IDs, standards baseline, and timestamp.
+Record candidate ID, iteration ID, repository ID, commit SHA, optional tag, source path/checksum, build ID, artifact digests, configuration baseline, migration set, IaC reference, source task IDs, standards baseline, and timestamp in `candidate-manifest.yaml`.
+
+For every UI-bearing candidate, also pin the exact UI handoff and aligned product-reconciliation identities/checksums; Prototype revision identity/checksum; prototype source revision/checksum; review-bundle and UI Mapping checksums; and task-to-prototype plus task-to-experience-change traceability identities/checksums. Candidate Assurance must reject a missing field or any conflict between the candidate manifest and its referenced immutable artifacts. It must not reconstruct the binding from file names, catalog order, Git history, or chat context.
 
 ## Dynamic Role Rules