ai-delivery-workflow 0.2.2 → 0.4.0

package/skills/ai-delivery-close-version/SKILL.md

@@ -9,9 +9,9 @@ Finish one planned version and stop before release. Never start a release from t
 
 ## Preflight
 
-1. Recover or initialize the `12-version-closeout` task through `$ai-delivery-checkpoint-task`.
-2. Run `node .workflow/tools/state/state.mjs verify`.
-3. Require a passing immutable candidate, closed version tasks, complete requirement/test/material traceability, and no unresolved blocking defect.
+1. Recover or initialize the `06-version-closeout` task through `$ai-delivery-checkpoint-task`.
+2. Run `node .workflow/tools/state/state.mjs verify --history`.
+3. Require a passing immutable candidate, a completed Candidate Assurance receipt for that same candidate, closed version tasks, complete requirement/test/material traceability, and no unresolved blocking defect.
 4. Read the preceding version lineage and Git policy. Require the candidate to descend from the current `line/<product-id>` head, except for the first version.
 
 ## Close The Version
@@ -19,12 +19,13 @@ Finish one planned version and stop before release. Never start a release from t
 1. Read `.workflow/config/workspace.yaml`; verify the candidate in the configured code repository and populate `repo_id`, `code_commit`, `source_path`, and SHA-256.
 2. Freeze the candidate commit and create code `version-ready/<version-id>/rN`. Never move or replace an existing Tag; increment `rN` only for a newly verified replacement candidate.
 3. Fast-forward code `line/<product-id>` to the tagged commit. Never advance code `main` here.
-4. Copy the closeout assets into `.workflow/iterations/<version-id>/12-version-closeout/`, populate the code Tag identity, and compute the final manifest SHA-256.
-5. Register the version materials with the formal state CLI, set the closeout artifact to `release-ready`, and complete `12-version-closeout` with that registered artifact as evidence.
+4. Copy the closeout assets into `.workflow/iterations/<version-id>/06-version-closeout/`, populate the code Tag identity, and compute the final manifest SHA-256.
+5. Register the immutable closeout semantic revision directly as `release-ready` with the formal state CLI, and complete `06-version-closeout` with that registered artifact as evidence. Do not register a draft and mutate its status in place.
 6. Commit all version workflow materials and create immutable workflow `workflow-ready/<version-id>/rN` at that exact workflow commit. Record the workflow commit, workflow Tag, and manifest checksum in the lineage index without rewriting the tagged manifest.
-7. Verify both Tags and the manifest checksum. Inspect the current workflow revision, then run `state.mjs transition --expected-revision <revision> --event version-closed --iteration-id <version-id> --artifact-id <closeout-artifact-id>` to update the audited cumulative development identity. Never edit `latest_line_version_id` directly.
-8. Run formal state `verify`, archive tasks with `task-state.mjs archive-version --version-status release-ready --candidate-id <candidate-id> --evidence <closeout-artifact-id>`, checkpoint the Git and archive evidence, and finish the task.
-9. Invoke `$ai-delivery-evolve-workflow evaluate --safe-point version --iteration-id <version-id>`. Record trial results and decisions, but never use an Evolution result as release intent.
+7. Verify both Tags and the manifest checksum. Inspect the current development scope revision, then run `state.mjs transition --expected-scope-revision <revision> --event version-closed --iteration-id <version-id> --artifact-id <closeout-artifact-id>` to update the audited cumulative development identity. Never edit `latest_line_version_id` directly.
+8. Run `state.mjs snapshot create --id <version-id> --reason version-boundary`, then `state.mjs verify --history --since-anchor`. The first trusted anchor performs a full-history audit before creation; later anchors validate the suffix from the previous anchor.
+9. Archive tasks with `task-state.mjs archive-version --version-status release-ready --candidate-id <candidate-id> --evidence <closeout-artifact-id>`. The command must first obtain `snapshot references` from the formal-state CLI and fail before writing if the anchor, scope, or candidate is missing. Verify that the version manifest references checksummed task summaries, complete attempt values, scope, candidate, Gate decisions, and the version-boundary anchor; then checkpoint the Git, anchor, and archive evidence and finish the task.
+10. Invoke `$ai-delivery-evolve-workflow evaluate --safe-point version --iteration-id <version-id>`. Record trial results and decisions, but never use an Evolution result as release intent.
 
 ## Stop Boundary
 

package/skills/ai-delivery-close-version/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Close Planned Version"
-  short_description: "Freeze a verified version as release-ready"
+interface:
+  display_name: "Close Planned Version"
+  short_description: "Freeze a verified version as release-ready"
   default_prompt: "Use $ai-delivery-close-version to bind code Tag, workflow Tag, and manifest checksum without publishing."

package/skills/ai-delivery-close-version/assets/version-lineage.yaml

@@ -8,5 +8,5 @@ candidate_commit: "<git-sha>"
 version_ready_tag: "version-ready/VER-0001/r1"
 workflow_commit: "<workflow-git-sha>"
 workflow_ready_tag: "workflow-ready/VER-0001/r1"
-artifact_manifest: ".workflow/iterations/VER-0001/12-version-closeout/version-manifest.yaml"
+artifact_manifest: ".workflow/iterations/VER-0001/06-version-closeout/version-manifest.yaml"
 artifact_sha256: "<sha256>"

package/skills/ai-delivery-close-version/references/version-closeout-contract.md

@@ -11,9 +11,9 @@
 
 `version-manifest.yaml` binds the version to its candidate, verification, task archive, product/architecture/prototype/test baselines, and material index. `version-lineage.yaml` records exactly one predecessor and the cumulative ordered ancestry. `line-advance-record.yaml` records the old/new line heads, immutable tag, actor, and checks.
 
-All outputs live under `.workflow/iterations/<version-id>/12-version-closeout/`, use stable IDs, and are registered through the formal state CLI. A version is `release-ready` only when every checksum resolves and the line fast-forward is proven.
+All outputs live under `.workflow/iterations/<version-id>/06-version-closeout/`, use stable IDs, and are registered through the formal state CLI. A version is `release-ready` only when every checksum resolves and the line fast-forward is proven.
 
-After the `release-ready` closeout artifact is registered, `12-version-closeout` is completed, and both immutable Tags are verified, run the formal `version-closed` transition with that artifact ID. This audited event is the only writer of `workflow-state.yaml.latest_line_version_id`. Then archive version tasks to `.workflow/control/archives/versions/<version-id>/` and verify that active task/checkpoint shards were removed. The task archive is a separate checkpoint operation and does not replace this formal transition.
+After Candidate Assurance has completed for the same immutable candidate, the `release-ready` closeout revision is registered, `06-version-closeout` is completed, and both immutable Tags are verified, run the formal `version-closed` transition with that artifact ID. This audited event is the only writer of `workflow-state.yaml.latest_line_version_id`. Then create the version-boundary history anchor and archive version tasks to `.workflow/control/archives/versions/<version-id>/`. Verify that the manifest references checksummed task summaries, attempt receipts, scope, candidate, Gate decisions, and that anchor, and that active task/checkpoint shards were removed. The task archive is a separate checkpoint operation and does not replace this formal transition.
 
 ## Failure rules
 

package/skills/ai-delivery-define-product/SKILL.md

@@ -9,7 +9,11 @@ Turn an initial idea into two human-approved baselines without inventing unresol
 
 ## Artifact Location
 
-Write every workflow document produced by this skill under project `.workflow/`. Place version-scoped node outputs in `.workflow/iterations/<iteration-id>/<node-id>/` and approved reusable product baselines in `.workflow/product/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+Write every workflow document produced by this skill under project `.workflow/`. Place version-scoped node outputs in `.workflow/iterations/<iteration-id>/01-product-shaping/` and approved reusable product baselines in `.workflow/product/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+
+## Development Node
+
+This Skill owns `01-product-shaping`. Discovery, product definition, and prototype reconciliation are task phases inside that node; they do not create separate formal nodes. The node retains human `GATE-A` for discovery and `GATE-B` for the product baseline. On a later version, reuse an unaffected approved product baseline only when change-impact analysis proves its scope is unaffected and its registered artifact identity and checksum still match. Record that baseline as completion evidence instead of replaying interviews or Gate decisions; any affected input requires a new revision and the applicable Gate.
 
 ## Task State
 
@@ -20,7 +24,7 @@ Write every workflow document produced by this skill under project `.workflow/`.
 
 ## Preflight
 
-Read the project state, artifact registry, applicable standards, and existing product baseline. For a change, identify the affected terms, terminals, features, stories, and acceptance criteria before editing. In prototype-reconciliation mode also read the complete adjustment log, requirement change set, formal UI confirmations, prototype set, and bidirectional product coverage.
+Read the project state, artifact registry, applicable standards, and existing product baseline. For a change, identify the affected terms, terminals, features, stories, and acceptance criteria before editing. In prototype-reconciliation mode also read the complete adjustment log, requirement change set, formal UI confirmation, exact Prototype revision and checksum, normalized Page and Review Scene catalogs, UI Mapping, and bidirectional product coverage.
 
 ## Run Discovery
 
@@ -62,14 +66,14 @@ Use the schemas and controlled values in [product-contract.md](references/produc
 
 ## Reconcile Confirmed Prototypes
 
-Run this mode only after every visual or interactive prototype member is candidate-approved and its adjustments are terminal.
+Run this mode only after the candidate Prototype revision is approved for every visual or interactive Page and Review Scene and all of its adjustments are terminal.
 
 1. Review every row in `requirement-change-set.csv`; classify it as approved, rejected, or requiring clarification. Do not approve a requirement merely because the prototype implements it.
 2. Verify both directions of `prototype-product-coverage.csv`: every prototype behavior must resolve to an approved feature/story/acceptance criterion, and every visual product behavior must resolve to a prototype element or justified `not-applicable` row.
 3. Apply approved added, modified, retired, or superseded requirements to a new product baseline version. Preserve stable IDs for modifications and retire IDs instead of reusing them.
 4. Re-run Gate B for every changed product artifact and record exact approval evidence. When nothing changes, retain the existing baseline and record an `aligned` no-change decision.
 5. Write `product-prototype-reconciliation.yaml` with the input/output product baseline checksums, prototype/formal-UI checksums, terminal and terminology checks, requirement-change closure, stale artifacts, and required prototype revalidation.
-6. Return rejected prototype behavior to experience for removal. Return an updated baseline to experience, mark affected prototype members stale, and require their staged re-approval. Repeat until the receipt is `status: valid`, `decision: aligned`, and every requirement change is terminal.
+6. Return rejected prototype behavior to experience for removal. Return an updated baseline to experience, mark the affected Page and Review Scene revisions stale, and require their staged re-approval in a new Prototype revision. Repeat until the receipt is `status: valid`, `decision: aligned`, and every requirement change is terminal.
 
 ## Handoff
 

package/skills/ai-delivery-define-product/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Define Product"
-  short_description: "Discover requirements and produce an approved product baseline"
-  default_prompt: "Use $ai-delivery-define-product to discover and define the product baseline."
+interface:
+  display_name: "Define Product"
+  short_description: "Discover requirements and produce an approved product baseline"
+  default_prompt: "Use $ai-delivery-define-product to discover and define the product baseline."

package/skills/ai-delivery-define-product/references/product-contract.md

@@ -40,11 +40,11 @@ Use change types `added`, `modified`, `retired`, and `superseded`. Use statuses
 
 `prototype-product-coverage.csv`:
 
-`feature_id,story_id,acceptance_id,terminal_id,prototype_artifact_id,page_id,prototype_element_id,coverage_status,rationale`
+`feature_id,story_id,acceptance_id,terminal_id,prototype_revision_id,page_id,review_scene_id,prototype_element_id,coverage_status,rationale`
 
 Use `covered`, `not-applicable`, and `missing`. Every `not-applicable` row requires a rationale. Product reconciliation fails on `missing`, an unapproved prototype behavior, an uncovered visual requirement, or a non-terminal requirement change.
 
-`product-prototype-reconciliation.yaml` records exact input/output product baseline identities and checksums, the complete candidate prototype set and formal-UI confirmations, coverage/change-set checksums, terminal/terminology/state checks, stale artifacts, required revalidation, and decision `aligned`, `product-update-required`, or `prototype-correction-required`. Only `aligned` may use `status: valid`.
+`product-prototype-reconciliation.yaml` records exact input/output product baseline identities and checksums, the candidate Prototype revision/checksum and formal-UI confirmation, UI Mapping and coverage/change-set checksums, terminal/terminology/state checks, stale Page and Review Scene identities, required revalidation, and decision `aligned`, `product-update-required`, or `prototype-correction-required`. Only `aligned` may use `status: valid`.
 
 ## Product Manual
 

package/skills/ai-delivery-deploy-production/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Deploy Production"
-  short_description: "Deploy one approved immutable iteration version to production"
+interface:
+  display_name: "Deploy Production"
+  short_description: "Deploy one approved immutable iteration version to production"
   default_prompt: "Use $ai-delivery-deploy-production to deploy the approved immutable package and record facts in the workflow repository."

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

@@ -9,7 +9,11 @@ Use one skill with `initial` and `reconcile` modes so coupled architecture views
 
 ## Artifact Location
 
-Write every workflow document produced by this skill under project `.workflow/`. Place version-scoped node outputs in `.workflow/iterations/<iteration-id>/<node-id>/` and approved reusable architecture baselines in `.workflow/architecture/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+Write every workflow document produced by this skill under project `.workflow/`. Place version-scoped node outputs in `.workflow/iterations/<iteration-id>/02-solution-design/` and approved reusable architecture baselines in `.workflow/architecture/`. Do not relocate source code, automated test source, repository configuration, or non-document build artifacts.
+
+## Development Node
+
+This Skill shares `02-solution-design` with `$ai-delivery-design-experience`. Initial architecture, prototype impact handling, and final reconciliation are task phases inside that node rather than separate formal nodes. Reuse an unaffected approved architecture baseline only by exact registered artifact identity and checksum after change-impact analysis; affected decisions require a new baseline revision and the applicable approval.
 
 ## Task State
 
@@ -34,9 +38,9 @@ Major decisions include platforms, paid services, security or privacy boundaries
 
 ## Reconcile Mode
 
-1. Read the experience baseline, `ui-handoff.yaml`, all staged Gate receipts (`UX-LF`, `UX-VS`, and `UX-UI`), aligned `product-prototype-reconciliation.yaml` receipt, experience/requirement change sets, interaction contract, design tokens, framework selection, component-state matrix, page-component map, frozen prototype set, every member manifest, management catalogs, review/impact records, traceability, and each source confirmation. Verify exact identities/checksums and require the handoff to be complete and free of stale references.
-2. Verify that the selected UI framework/version is compatible with the architecture stack and dependency policy, and that every page family, component mapping, interaction, state, permission, query, upload, real-time behavior, failure mode, responsive rule, and accessibility requirement is technically supported. Use stable change/page/canvas/file/element/component IDs in findings.
-3. Write one `prototype-architecture-validation.yaml` per set member with the UI handoff identity/checksum, all consumed artifact versions/checksums, exact architecture baseline version/checksum, implementability decision, affected changes/contracts/components, issues, and return node. An accepted receipt uses `status: valid`; a `changes-required` receipt uses `status: invalid`. Accept the handoff only when all member receipts pass, then advance accepted experience changes from `formal-ui-confirmed` to `architecture-accepted` and `ready-for-development` through the state CLI.
+1. Read the experience baseline, `ui-handoff.yaml`, both staged Gate receipts (`UX-VS` and `UX-UI`), aligned `product-prototype-reconciliation.yaml` receipt, experience/requirement change sets, interaction contract, design tokens, framework selection, component-state matrix, page-component map, 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/impact records, traceability, and source confirmation. Verify every exact identity/checksum and require the handoff to be complete and free of stale references. Reject a missing or conflicting reference; never infer a relationship from a file name or catalog order.
+2. Resolve every affected Page, Review Scene, UI component, frontend source, and acceptance ID through the pinned UI Mapping. Verify that the selected UI framework/version is compatible with the architecture stack and dependency policy, and that every mapped interaction, state, permission, query, upload, real-time behavior, failure mode, responsive rule, and accessibility requirement is technically supported. Use stable change, terminal, Page, Review Scene, prototype-element, UI Mapping, component, frontend-source, and acceptance IDs in findings.
+3. Write one `prototype-architecture-validation.yaml` for the Prototype revision with the UI handoff identity/checksum, Prototype revision and UI Mapping checksums, all consumed artifact versions/checksums, exact architecture baseline version/checksum, implementability decision, affected changes/Pages/Review Scenes/mappings/components/acceptance criteria, issues, and return node. An accepted receipt uses `status: valid`; a `changes-required` receipt uses `status: invalid`. Accept the handoff only when the receipt passes, then advance accepted experience changes from `formal-ui-confirmed` to `architecture-accepted` and `ready-for-development` through the state CLI.
 4. Return product or experience defects to their producer. Do not silently weaken approved behavior or edit the frozen prototype.
 5. Finalize APIs, data access, events, component boundaries, test seams, deployment requirements, and implementation constraints.
 6. Reopen human approval only when reconciliation creates or changes a major decision.
@@ -64,4 +68,4 @@ Read [architecture-contract.md](references/architecture-contract.md) and use `as
 
 ## Handoff
 
-Initial mode feeds experience design and delivery-platform preparation. Reconcile mode accepts only an exact confirmed prototype version and produces the final baseline plus its prototype validation receipt for planning, test design, platform work, and implementation.
+Initial mode feeds experience design and delivery-platform preparation. Reconcile mode accepts only an exact confirmed Prototype revision and UI Mapping and produces the final baseline plus its prototype validation receipt for planning, test design, platform work, and implementation.

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

@@ -6,8 +6,7 @@ status: draft
 producer_skill: ai-delivery-design-architecture
 input_artifacts:
   ui_handoff: UI-HANDOFF-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
   prototype_tool_selection: PROTOTYPE-TOOL-SELECTION-0001@1
   prototype_review_decision: PROTOTYPE-REVIEW-DECISION-0001@1
@@ -15,23 +14,23 @@ input_artifacts:
 standards: []
 ui_handoff_ref: UI-HANDOFF-0001@1
 ui_handoff_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
@@ -45,11 +44,12 @@ architecture_baseline_version: 1
 architecture_baseline_checksum: REPLACE_WITH_SHA256
 decision: changes-required
 affected_page_ids: []
-affected_canvas_ids: []
-affected_prototype_file_ids: []
+affected_review_scene_ids: []
+affected_ui_mapping_ids: []
 affected_prototype_element_ids: []
 affected_experience_change_ids: []
 affected_ui_component_ids: []
+affected_acceptance_ids: []
 component_impacts: []
 contract_impacts: []
 quality_budget_conflicts: []

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

@@ -21,7 +21,7 @@ Produce a versioned architecture-gate artifact that lists major decision IDs and
 
 Add experience coverage validation, exact UI handoff acceptance, selected framework/dependency compatibility, interaction-driven queries, design-token/component constraints, final APIs/events/schemas, final component impact map, final public test seams, and implementation commands.
 
-Produce one `prototype-architecture-validation.yaml` per prototype-set member. Pin the `ui-handoff.yaml` version/checksum, prototype-set and member identities, source confirmation, staged Gate receipts, aligned product reconciliation, framework selection, design tokens, interaction/component contracts, change sets, management/review/impact checksums, linked coverage, and final architecture baseline. Record decision (`accepted` or `changes-required`), affected experience change/page/canvas/file/element/component IDs, dependency/component/contract impacts, quality-budget conflicts, unresolved issues, evidence, and return node. Use `status: valid` only with `accepted`; reject any identity mismatch or handoff not ready for development. Do not modify experience artifacts.
+Produce one `prototype-architecture-validation.yaml` for the exact Prototype revision. Pin the `ui-handoff.yaml` version/checksum, Prototype revision/checksum, source and review-bundle checksums, UI Mapping checksum, normalized catalog checksums, source confirmation, staged Gate receipts, aligned product reconciliation, framework selection, design tokens, interaction/component contracts, change sets, review/impact checksums, linked coverage, and final architecture baseline. Resolve affected Page, Review Scene, prototype-element, UI Mapping, UI component, frontend-source, and acceptance IDs only from the normalized catalogs. Record decision (`accepted` or `changes-required`), affected identities, dependency/component/contract impacts, quality-budget conflicts, unresolved issues, evidence, and return node. Use `status: valid` only with `accepted`; reject any missing or conflicting identity or a handoff not ready for development. Never infer a relationship from a file name or catalog order. Do not modify experience artifacts.
 
 ## Architecture Decision Test
 

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

@@ -1,6 +1,6 @@
 ---
 name: ai-delivery-design-experience
-description: Select prototype and UI tools, produce executable low-fidelity interactions, define a confirmed visual system, transform them into formal framework-based UI, record every adjustment and requirement impact, reconcile the final prototype with product requirements, and create a development-ready handoff. Use after initial architecture or whenever product, interaction, visual, framework, page, or component behavior changes.
+description: Select prototype and UI tools, define a confirmed visual system, produce a production-compatible runnable prototype, record every adjustment and requirement impact, reconcile the final prototype with product requirements, and create a development-ready handoff. Use after initial architecture or whenever product, interaction, visual, framework, page, or component behavior changes.
 ---
 
 # Design Experience
@@ -9,7 +9,11 @@ Design complete user experiences for the terminals selected by product and imple
 
 ## Artifact Location
 
-Write every workflow document, prototype management artifact, and review record produced by this skill under project `.workflow/`. Place version-scoped node outputs in `.workflow/iterations/<iteration-id>/<node-id>/` and approved reusable experience baselines in `.workflow/experience/`.
+Write every workflow document, prototype management artifact, and review record produced by this skill under project `.workflow/`. Place version-scoped node outputs in `.workflow/iterations/<iteration-id>/02-solution-design/` and approved reusable experience baselines in `.workflow/experience/`.
+
+## Development Node
+
+This Skill shares `02-solution-design` with `$ai-delivery-design-architecture`. Visual-system design, production-compatible prototype design, product reconciliation, and architecture reconciliation remain task phases inside the same formal node. Human `UX-VS` and `UX-UI` decisions remain mandatory for every visual or interactive Prototype revision. Reuse an unaffected approved experience baseline only by exact registered artifact identity and checksum; any affected Page or Review Scene requires a new revision and the applicable staged Gates.
 
 ## Task State
 
@@ -21,51 +25,53 @@ Write every workflow document, prototype management artifact, and review record
 
 Read the approved product baseline, terminal and feature catalogs, initial architecture baseline, major-decision approval receipt or explicit not-required assessment, applicable design standards, and existing experience baseline. Verify all input versions and checksums. Return missing terminal scope or feature behavior to product definition; refuse to prototype from unapproved major architecture decisions.
 
+When `prototype.yaml` has `status: migration-pending-ux-ui` or a `prototype-migration.yaml` exists, apply the Legacy Prototype Migration section of [experience-contract.md](references/experience-contract.md). Treat copied member sources as migration inputs, complete the normalized catalogs and current Review Shell, then freeze and validate a new revision before requesting `UX-UI`; no legacy approval is reusable.
+
 ## Workflow
 
 1. Map each feature-terminal pair to user tasks and journeys.
-2. Reserve one stable prototype member ID per independent source/review lifecycle. Inspect actual tool and skill availability, recommend evidence-backed authoring tools and optional design assistants, and obtain the user's selection in a valid `prototype-tool-selection.yaml`. Do not start prototype authoring before this human tool-selection Gate passes.
-3. Define information architecture, navigation, task flows, and the stable page catalog. Use `P01` for a main page and `P01-01` for its child; keep identity separate from the display label and never renumber or reuse retired IDs.
-4. Plan prototype files and canvases explicitly. Keep one main-page family per canvas, split files at terminal/tool/freeze/review boundaries, and record normalized page-canvas-file-terminal relationships.
-5. Build a runnable low-fidelity interaction prototype using the architecture-selected frontend runtime or another selected executable authoring tool. Use neutral styling and mock, in-memory, or local persisted data. Every visible control must work; cover navigation, validation, loading, empty, success, error, permission, disabled, recovery, and responsive behavior in `interaction-contract.csv`.
-6. Run mandatory Gate `UX-LF`. The user must operate the prototype and approve the exact low-fidelity source revision in `low-fidelity-confirmation.yaml`. Record every comment and every resulting adjustment; re-review until no open adjustment remains. Interactive prototypes cannot use `contract-only`.
-7. Record every adjustment immediately in `prototype-adjustment-log.csv`, including its classification, before/after revision, reason, requirement/change references, and product, architecture, and test impacts. Never overwrite a prior revision. Create or update `experience-change-set.csv`, `experience-change-domains.csv`, and `requirement-change-set.csv` using stable IDs.
-8. After `UX-LF` passes, define `visual-direction.yaml`. Inspect compatible UI frameworks, skills, and MCP capabilities; record evidence in `ui-framework-candidates.csv`, recommend two or three viable options when available, and obtain the user's exact framework/version choice in `ui-framework-selection.yaml`. Architecture limits the runtime; experience selects the compatible UI system.
-9. Define machine-readable `design-tokens.json`, typography, semantic colors, spacing, size, border, radius, shadow, opacity, z-index, breakpoints, motion, icons, responsive rules, accessibility, and `component-state-matrix.csv`. Run mandatory Gate `UX-VS` and pin all visual-system checksums in `visual-system-confirmation.yaml`.
-10. Transform the confirmed low-fidelity prototype into a production-compatible formal UI baseline using the selected framework while preserving confirmed interactions. Keep mock data and do not bind production services. Map stable pages/elements to framework components and source entrypoints in `page-component-map.csv`.
-11. Run mandatory Gate `UX-UI`. The user must operate and approve the formal UI source revision. Record and re-review every adjustment until `formal-ui-confirmation.yaml` reaches candidate approval with no open comments. The candidate is not frozen yet.
-12. After all prototype members are candidate-approved, aggregate the full adjustment and requirement-change sets and invoke `$ai-delivery-define-product` in prototype-reconciliation mode. Produce complete bidirectional `prototype-product-coverage.csv`. Product owns `product-prototype-reconciliation.yaml`; never silently rewrite product requirements to match the prototype.
-13. When reconciliation finds a product change, create and approve a new product baseline, mark affected artifacts stale, revise only affected prototype members, rerun their required Gate, and repeat reconciliation. Reject or remove unapproved prototype behavior. Proceed only with `decision: aligned` and every requirement change terminal.
-14. Derive added, modified, retired, superseded, and unchanged experience rows by comparing stable IDs and checksums with the prior frozen experience baseline. Use phase states `proposed`, `interaction-confirmed`, `visual-confirmed`, `formal-ui-confirmed`, `architecture-accepted`, `ready-for-development`, `included-in-work-package`, `implemented`, and `verified`; use `changes-requested`, `stale`, `blocked`, `retired`, and `superseded` when applicable.
-15. Freeze every prototype source revision, Gate receipt, product-reconciliation receipt, review bundle, management catalog, design system, change set, coverage file, and manifest checksum; then freeze the ordered member list and `experience-baseline.yaml`.
-16. Run contract completeness checks and write one source confirmation per member plus `ui-handoff.yaml`. Set `development_readiness: ready-for-development` only when `UX-LF`, `UX-VS`, `UX-UI`, and product reconciliation all pass and no blocking or stale requirement/experience change remains.
-
-Tool selection, low-fidelity interaction approval, visual-system/framework approval, formal-UI approval, and final product reconciliation are required decisions for every visual or interactive prototype. Only genuinely non-visual terminals may use justified `not-applicable` results.
+2. Reserve the project's one logical Prototype and its stable identity in `prototype.yaml`. Inspect actual tool and skill availability, recommend evidence-backed authoring tools and optional design assistants, and obtain the user's selection in a valid `prototype-tool-selection.yaml`. Do not start prototype authoring before this human tool-selection Gate passes.
+3. Define information architecture, navigation, task flows, stable Pages, and stable Review Scenes. Use `P01` for a main Page and `P01-01` for its child; use independent `RS0001` identities for directly reviewable conditions. Keep identity separate from display labels, never renumber or reuse retired IDs, and never create a production Page merely to expose a condition.
+4. Group every terminal in the same Prototype through `prototype-terminals.csv`. Declare an independent source entrypoint and build command only where terminal runtimes require it. Normalize Pages, Review Scenes, trigger conditions, prototype routes, production routes, and UI Mapping in their authoritative catalogs; do not duplicate registrations in source or manifests. Register every active Page and Review Scene plus each shared source dependency in `prototype-review-units.csv`, with checksummed source references; record each affected Page as one normalized `prototype-review-unit-pages.csv` association row. Register reusable Component Registration, Data Contract, Component Candidate, component binding, implementation mapping, and Source Inspection Snapshot facts in their own required v2 catalogs. Every required field, identity, terminal/Page/Scene relationship, source reference, and checksum must be complete before freezing; a Page-level Source Inspection Snapshot may omit only `review_scene_id`. Create `frontend-change-scope.yaml` for the production code repository, listing its code root, non-empty frontend roots and UI extensions, and explicit Page ownership for every shared component and route registry. Shared components may own a file or directory. Each route registry must own one file and bind the SHA-256 of its exact approved candidate content so an additional route in an already mapped registry cannot inherit another Page approval. A production UI source is actionable only when it is covered by an active UI Mapping row or one of those explicit ownership entries.
+5. When the user has not supplied a visual direction, read installed `ref/ui/README.md` before any `DESIGN.md`. Evaluate exactly two or three relevant references against the approved product, audience, terminal, brand, and architecture inputs; record one primary reference, at most one supporting reference with its narrow application scope, rationale, upstream version, paths, and SHA-256 values in `design-reference-selection.yaml`. Do not copy a reference product's trademark, proprietary asset, or brand identity. A missing index, `LICENSE`, `UPSTREAM.yaml`, selected reference, or checksum match fails closed.
+6. Define `visual-direction.yaml`. Inspect compatible UI frameworks, skills, and MCP capabilities; record evidence in `ui-framework-candidates.csv`, recommend two or three viable options when available, and obtain the user's exact framework, component-system, icon-library, and version choices in `ui-framework-selection.yaml`. Pin the component registry and version, component configuration file and checksum, selected components, and every checksummed local adaptation. For architecture-compatible React Web with no user override, select shadcn and Lucide. For incompatible runtimes, obey architecture constraints and require an explicit human selection instead of silently substituting a default.
+7. Define machine-readable `design-tokens.json`, typography, semantic colors, spacing, size, border, radius, shadow, opacity, z-index, breakpoints, motion, icons, responsive rules, accessibility, and `component-state-matrix.csv`. Generate a runnable `visual-reference.html` plus `visual-reference-manifest.yaml` that applies the selected references and lets the user operate token modes, component states, responsive behavior, and accessibility states. Before requesting `UX-VS`, start or reuse `ai-delivery manager serve <workspace>`, route the user to P11, and ensure it exposes only the exact checksummed Visual Reference. After the human decision, pin the approved Visual Reference, reference documents, component system, icon library, and every design-input checksum in `visual-system-confirmation.yaml`; each checksum entry declares `scope: project` for `ref/ui` or `scope: experience` for generated inputs. Before completing `UX-VS`, run `ai-delivery visual-standard validate <workspace> --experience <relative-directory>` and retain its successful report as Gate evidence. Missing inputs or licenses, checksum drift, or an approval that is expired blocks the flow and requires a new Visual Reference revision and approval.
+8. Build the one production-compatible runnable Prototype in the isolated `prototype/source` tree using the selected framework and architecture runtime. Keep mock data and do not bind production services. When a Review Scene needs an outside protocol, run `ai-delivery mock setup <workspace>` and `ai-delivery mock start <workspace>`, register every mock with explicit External Dependency Mock (`external-dependency`) or Product Backend Mock (`product-backend`) kind, owner, approved contract reference, replacement condition, protocol, operation/channel, and stable scenario identity, then review `ai-delivery mock sync <workspace> --dry-run`. Only after that dry-run validates every named scenario and dispatcher input may `ai-delivery mock sync <workspace>` run. Keep Product Backend Mock entries for unfinished product-owned public contracts in their separate catalog and never misclassify them as external. Export each actual OpenAPI/AsyncAPI definition changed through the managed Microcks UI into `mock-admin-exports/`, then bind its kind, Mock ID, protocol, relative path, and SHA-256 in `mock-admin-export.yaml`; freeze must protocol-validate every mapped scenario against those exported bytes. Production traffic recording, production credentials, and unsanitized personal data are prohibited, and every explicit import requires passed sanitization evidence. Map every active Review Scene exactly once in `mock-scenario-mappings.csv`. Run `ai-delivery mock freeze <workspace> --experience <relative-directory> --scenario-pack mock-scenario-pack-request.yaml --dry-run`, ask the user to approve that exact candidate checksum, then run the same command without `--dry-run` and formally register the immutable Mock Scenario Pack checksum as `artifact_type: mock-scenario-pack`. Only that registered Pack is authoritative for the Prototype revision and later UI Acceptance. A Product Backend Mock may drive a UI scene, but the real backend is not proven and end-to-end acceptance is not satisfied by that mock. Prototype routes reference only the registered Pack's `mock_id` and `scenario_id`, then trigger the contract-defined dispatcher deterministically; do not duplicate response logic inside the Prototype. Maintain one current Review Shell that consumes the server-supplied `review_path` query parameter and renders the matching registered prototype route. Expose every Page and Review Scene through that direct route, and keep production routes limited to real business Pages. Every visible control must work; cover navigation, validation, loading, empty, success, error, permission, disabled, recovery, responsive behavior, and accessibility in `interaction-contract.csv`. Bind prototype routes, production routes, frontend sources, and acceptance IDs once in `ui-mapping.csv`.
+9. Record every adjustment immediately in `prototype-adjustment-log.csv`, including its classification, before/after revision, reason, requirement/change references, and product, architecture, and test impacts. Never overwrite a prior revision. Create or update `experience-change-set.csv`, `experience-change-domains.csv`, and `requirement-change-set.csv` using stable IDs.
+10. Run mandatory Gate `UX-UI`. Validate the exact Prototype revision, start or reuse `ai-delivery manager serve <workspace>`, and give the returned loopback URL plus P12/P13 affected Page and Review Scene IDs to the user. The Review Shell derives each Page as `approved`, `pending-review`, `changes-requested`, or `stale` from checksummed Page review receipts; it shows the changed evidence domains, all owning Review Scenes, and the Page/Scene/revision checksums. The user must operate that exact revision and write `approved` or reason-required `changes-requested` decisions only through the Workflow Manager controlled API. Never let browser code edit YAML, formal state, or receipts directly. Across revisions, consider decisions only from the checksum-validated `previous_revision` ancestor chain, nearest ancestor first; never inherit from a descendant or unrelated revision. Carry forward a Page approval only when that prior decision is approved and the complete Page checksum is identical; a later changes-requested decision on the selected ancestor takes precedence. Label the final pending Page action `Approve Page and complete UX-UI`, and atomically write its Page receipt with the formal `UX-UI` Gate decision. After approval, reject further Page decisions until a new immutable Prototype revision has a new pending `UX-UI` Gate. Record and re-review every adjustment until `formal-ui-confirmation.yaml` reaches candidate approval with no open comments. A content or catalog change requires a new exact revision; the Workflow Manager must reject target revision drift before accepting a decision.
+11. After every affected Page and Review Scene is candidate-approved, aggregate the full adjustment and requirement-change sets and invoke `$ai-delivery-define-product` in prototype-reconciliation mode. Produce complete bidirectional `prototype-product-coverage.csv`. Product owns `product-prototype-reconciliation.yaml`; never silently rewrite product requirements to match the Prototype.
+12. When reconciliation finds a product change, create and approve a new product baseline, mark affected artifacts stale, revise the same Prototype source, rerun the required Gate, and repeat reconciliation. Reject or remove unapproved prototype behavior. Proceed only with `decision: aligned` and every requirement change terminal.
+13. Derive added, modified, retired, superseded, and unchanged experience rows by comparing stable IDs and checksums with the prior frozen experience baseline. Use phase states `proposed`, `interaction-confirmed`, `visual-confirmed`, `formal-ui-confirmed`, `architecture-accepted`, `ready-for-development`, `included-in-work-package`, `implemented`, and `verified`; use `changes-requested`, `stale`, `blocked`, `retired`, and `superseded` when applicable.
+14. Freeze one immutable `prototype-revision.yaml` for the iteration. Its checksummed review bundle contains the Review Shell, terminal/Page/Review Scene/trigger/route/UI Mapping/Review Unit/Review Unit Page, Component Registration, Data Contract, Component Candidate, component binding, implementation mapping, and Source Inspection Snapshot catalogs, Visual Standard evidence, review evidence, and `frontend-change-scope.yaml`; bind the scope with its own SHA-256 in the revision. Pin the exact source revision and run `ai-delivery prototype-revision validate <workspace> --experience <relative-directory> --revision <relative-yaml>` before registration; never copy or fork the logical Prototype for a new iteration.
+15. Run contract completeness checks and write one source confirmation plus `ui-handoff.yaml` for the exact Prototype revision. Set `development_readiness: ready-for-development` only when `UX-VS`, `UX-UI`, product reconciliation, and revision validation all pass and no blocking or stale requirement/experience change remains.
+
+Tool selection, visual-system/framework approval, formal-UI approval, and final product reconciliation are required decisions for every visual or interactive prototype. Only genuinely non-visual terminals may use justified `not-applicable` results.
 
 ## Outputs
 
 - user journeys and task flows;
 - information architecture and page inventory;
-- tool candidate catalog and human tool-selection receipt per prototype-set member;
-- stable page, canvas, file, and file-terminal catalogs;
-- wireframes and high-fidelity screens;
-- executable low-fidelity prototype, interaction contract, and `UX-LF` confirmation;
-- visual direction, UI framework candidates/selection, design tokens, component-state matrix, and `UX-VS` confirmation;
-- production-compatible formal UI baseline, page-component map, and `UX-UI` confirmation;
+- one project Prototype descriptor, tool candidate catalog, and human tool-selection receipt;
+- normalized terminal, Page, Review Scene, trigger-condition, route, UI Mapping, Component Registration, Data Contract, Component Candidate, binding, implementation mapping, and Source Inspection Snapshot catalogs;
+- revision-bound frontend roots plus shared component and route registry Page ownership;
+- design reference selection, runnable HTML Visual Reference, visual direction, UI framework/component/icon selection, design tokens, component-state matrix, and `UX-VS` confirmation;
+- production-compatible runnable prototype, interaction contract, page-component map, and `UX-UI` confirmation;
 - responsive, accessibility, content, and interaction rules;
 - state catalog;
-- mandatory staged-review decision, `UX-LF`/`UX-VS`/`UX-UI` receipts, review sessions, comments, adjustment log, and impact assessment;
+- mandatory staged-review decision, `UX-VS`/`UX-UI` receipts, review sessions, comments, adjustment log, and impact assessment;
 - experience change/domain sets and requirement change set;
 - product-prototype coverage and final reconciliation receipt;
 - versioned experience baseline and `ui-handoff.yaml` with explicit development readiness;
-- reviewable prototype source/export, one `prototype-manifest.yaml` per independently versioned bundle, and `prototype-set.yaml`;
+- one current isolated Prototype source, one current Review Shell, and one immutable checksummed `prototype-revision.yaml` per approved iteration;
 - `prototype-traceability.csv`;
-- one prototype source-confirmation YAML per prototype-set member;
+- one source-confirmation YAML bound to the exact Prototype revision;
 - `feature-screen-coverage.csv` mapping feature ID, terminal ID, flow ID, screen ID, and state ID;
 - versioned experience baseline and unresolved technical questions.
 
-Read [experience-contract.md](references/experience-contract.md) for handoff identity and [prototype-management-contract.md](references/prototype-management-contract.md) for tool, page, canvas, file, and review rules. Use `assets/experience-template/` for all controlled templates.
+Read [experience-contract.md](references/experience-contract.md) for handoff identity and [prototype-management-contract.md](references/prototype-management-contract.md) for tool, terminal, Page, Review Scene, route, UI Mapping, and review rules. Use `assets/experience-template/` for all controlled templates; files explicitly labeled legacy are compatibility inputs, not current-flow outputs.
 
 ## Handoff
 
-Send the experience baseline, `ui-handoff.yaml`, all four Gate receipts, change sets, interaction/visual/component contracts, frozen prototype set identity, every member manifest/checksum, source revision, review-bundle checksum, management checksums, traceability checksum, and source-confirmation checksum to `$ai-delivery-design-architecture` in reconcile mode. Architecture writes one separate validation receipt per set member and advances accepted experience changes to `ready-for-development`. Preserve the same frozen set for planning and test design; downstream nodes must never edit experience artifacts.
+Send the experience baseline, `ui-handoff.yaml`, tool-selection receipt, both experience Gate receipts, product-reconciliation receipt, change sets, interaction/visual/component contracts, exact Prototype revision identity/checksum, source revision, review-bundle checksum, catalog checksums, traceability checksum, and source-confirmation checksum to `$ai-delivery-design-architecture` in reconcile mode. Preserve the same frozen revision for planning and test design; downstream nodes must never edit experience artifacts.
+
+Legacy `prototype-set.yaml` and member manifests are read-only compatibility inputs. A compatibility reader may normalize them in memory when inspecting historical iterations, and the explicit CLI migration may copy their validated bytes into the current isolated source tree. This Skill never creates, updates, or deletes a prototype set, member bundle, member-scoped manifest, closed iteration, archive, legacy Gate, or legacy event.

package/skills/ai-delivery-design-experience/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Design Managed Prototypes"
-  short_description: "Select tools and manage reviewable prototypes"
-  default_prompt: "Use $ai-delivery-design-experience to select a prototype tool, manage pages and canvases, and close review before handoff."
+interface:
+  display_name: "Design Managed Prototypes"
+  short_description: "Select tools and manage reviewable prototypes"
+  default_prompt: "Use $ai-delivery-design-experience to select a prototype tool, manage pages and canvases, and close review before handoff."

package/skills/ai-delivery-design-experience/assets/experience-template/LEGACY-COMPATIBILITY.md

@@ -0,0 +1,16 @@
+# Legacy Prototype Compatibility Inputs
+
+The current flow does not create or update the following files. They remain in
+the package only so historical iterations can be inspected, verified, rebuilt,
+or explicitly migrated until downstream consumers complete their migration:
+
+- `prototype-set.yaml`
+- `prototype-manifest.yaml`
+- `page-catalog.csv`
+- `canvas-catalog.csv`
+- `canvas-pages.csv`
+- `prototype-files.csv`
+- `prototype-file-terminals.csv`
+
+Treat these files as read-only. Normalize their identities in memory and never
+use them as the output model for a new iteration.

package/skills/ai-delivery-design-experience/assets/experience-template/design-reference-selection.yaml

@@ -0,0 +1,32 @@
+artifact_id: DESIGN-REFERENCE-SELECTION-0001
+artifact_type: design-reference-selection
+version: 1
+iteration_id: ITER-0001
+status: draft
+producer_skill: ai-delivery-design-experience
+catalog_ref: ref/ui/README.md
+catalog_checksum: REPLACE_WITH_SHA256
+license_ref: ref/ui/LICENSE
+license_checksum: REPLACE_WITH_SHA256
+upstream_ref: ref/ui/UPSTREAM.yaml
+upstream_checksum: REPLACE_WITH_SHA256
+upstream_version: REPLACE_WITH_40_CHARACTER_SOURCE_COMMIT
+selection_context:
+  product_baseline_ref: PRODUCT-BASELINE-0001@1
+  architecture_baseline_ref: ARCH-INITIAL-0001@1
+  terminal_ids: []
+  audience: []
+  usage_context: []
+  brand_constraints: []
+evaluation_count:
+  minimum: 2
+  maximum: 3
+evaluated_references: []
+primary_reference: null
+max_supporting_references: 1
+supporting_reference: null
+rationale: null
+selected_by: null
+selected_at: null
+decision: pending
+blocking_issues: []

package/skills/ai-delivery-design-experience/assets/experience-template/experience-baseline.yaml

@@ -7,8 +7,8 @@ status: draft
 producer_skill: ai-delivery-design-experience
 product_baseline_ref: PRODUCT-BASELINE-0001@1
 architecture_initial_ref: ARCH-INITIAL-0001@1
-prototype_set_ref: PROTOTYPE-SET-0001@1
-low_fidelity_gate_status: pending
+prototype_revision_ref: PROTOTYPE-REVISION-0001@1
+prototype_revision_checksum: REPLACE_WITH_SHA256
 visual_system_gate_status: pending
 formal_ui_gate_status: pending
 product_reconciliation_status: pending

package/skills/ai-delivery-design-experience/assets/experience-template/formal-ui-confirmation.yaml

@@ -4,16 +4,29 @@ version: 1
 iteration_id: ITER-0001
 status: pending
 producer_skill: ai-delivery-design-experience
-prototype_artifact_id: PROTOTYPE-0001
-low_fidelity_confirmation_ref: LOW-FIDELITY-CONFIRMATION-0001@1
+gate_id: UX-UI
+prototype_id: PROTOTYPE
+prototype_revision_ref: PROTOTYPE-REVISION-0001@1
+prototype_revision_checksum: REPLACE_WITH_SHA256
+page_catalog_checksum: REPLACE_WITH_SHA256
+review_scene_catalog_checksum: REPLACE_WITH_SHA256
+review_unit_catalog_checksum: REPLACE_WITH_SHA256
+review_unit_page_catalog_checksum: REPLACE_WITH_SHA256
+visual_standard_checksum: REPLACE_WITH_SHA256
 visual_system_confirmation_ref: VISUAL-SYSTEM-CONFIRMATION-0001@1
-formal_ui_source_revision: UI-REVISION-0001
+candidate_source_revision: REPLACE_WITH_IMMUTABLE_SOURCE_REVISION
 formal_ui_review_entrypoint: prototype/formal-ui/index.html
 page_component_map_ref: page-component-map.csv
 page_component_map_checksum: REPLACE_WITH_SHA256
 interaction_contract_checksum: REPLACE_WITH_SHA256
 experience_change_set_checksum: REPLACE_WITH_SHA256
 candidate_status: candidate-approved-pending
+allowed_page_review_statuses:
+  - approved
+  - pending-review
+  - changes-requested
+  - stale
+page_review_receipts: []
 checks:
   confirmed_interactions_preserved: pending
   framework_components_applied: pending

package/skills/ai-delivery-design-experience/assets/experience-template/frontend-change-scope.yaml

@@ -0,0 +1,30 @@
+schema_version: 1
+artifact_type: frontend-change-scope
+code_root: code
+frontend_roots:
+  - src
+ui_file_extensions:
+  - .css
+  - .html
+  - .js
+  - .jsx
+  - .json
+  - .less
+  - .mdx
+  - .sass
+  - .scss
+  - .ts
+  - .tsx
+  - .vue
+  - .svelte
+shared_components:
+  - source_ref: src/components
+    source_kind: directory
+    page_ids:
+      - P01
+route_registries:
+  - source_ref: src/router.tsx
+    source_kind: file
+    page_ids:
+      - P01
+    approved_checksum: REPLACE_WITH_SHA256

package/skills/ai-delivery-design-experience/assets/experience-template/interaction-contract.csv

@@ -1 +1 @@
-interaction_id,prototype_artifact_id,page_id,prototype_element_id,trigger,precondition,state_before,state_after,observable_feedback,error_behavior,keyboard_behavior,acceptance_id,status
+interaction_id,prototype_id,page_id,review_scene_id,prototype_element_id,trigger,precondition,state_before,state_after,observable_feedback,error_behavior,keyboard_behavior,acceptance_id,status

package/skills/ai-delivery-design-experience/assets/experience-template/mock-admin-export.yaml

@@ -0,0 +1,8 @@
+schema_version: 1
+source: microcks-managed-ui
+exported_at: null
+artifacts: []
+security:
+  production_traffic_recording: false
+  production_credentials: false
+  unsanitized_personal_data: false

package/skills/ai-delivery-design-experience/assets/experience-template/mock-scenario-mappings.csv

@@ -0,0 +1 @@
+review_scene_id,mock_id,mock_kind,scenario_id,data_source,data_classification,sanitization_status,sanitization_evidence_ref

package/skills/ai-delivery-design-experience/assets/experience-template/mock-scenario-pack-request.yaml

@@ -0,0 +1,24 @@
+schema_version: 1
+artifact_id: MOCK-SCENARIO-PACK-0001
+artifact_type: mock-scenario-pack-request
+version: 1
+iteration_id: ITER-0001
+prototype_revision:
+  ref: prototype/revisions/PROTOTYPE-REVISION-0001/prototype-revision.yaml
+  algorithm: sha256
+  checksum: REPLACE_WITH_SHA256
+scenario_mapping:
+  ref: mock-scenario-mappings.csv
+  algorithm: sha256
+  checksum: REPLACE_WITH_SHA256
+admin_export:
+  ref: mock-admin-export.yaml
+  algorithm: sha256
+  checksum: REPLACE_WITH_SHA256
+human_confirmation:
+  required: true
+  decision: pending
+  actor: null
+  decided_at: null
+  candidate_checksum: null
+output_ref: mock-scenario-packs/MOCK-SCENARIO-PACK-0001.yaml