ai-delivery-workflow 0.2.2

package/skills/ai-delivery-design-experience/assets/experience-template/visual-system-confirmation.yaml

@@ -0,0 +1,31 @@
+artifact_id: VISUAL-SYSTEM-CONFIRMATION-0001
+artifact_type: visual-system-confirmation
+version: 1
+iteration_id: ITER-0001
+status: pending
+producer_skill: ai-delivery-design-experience
+visual_direction_ref: visual-direction.yaml
+visual_direction_checksum: REPLACE_WITH_SHA256
+design_tokens_ref: design-tokens.json
+design_tokens_checksum: REPLACE_WITH_SHA256
+ui_framework_selection_ref: ui-framework-selection.yaml
+ui_framework_selection_checksum: REPLACE_WITH_SHA256
+component_state_matrix_ref: component-state-matrix.csv
+component_state_matrix_checksum: REPLACE_WITH_SHA256
+checks:
+  product_fit: pending
+  typography: pending
+  semantic_color: pending
+  layout_and_spacing: pending
+  component_states: pending
+  responsive_rules: pending
+  accessibility: pending
+  framework_compatibility: pending
+human_approval:
+  required: true
+  approver: null
+  decided_at: null
+  decision: pending
+decision: pending
+blocking_issues: []
+evidence: []

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

@@ -0,0 +1,82 @@
+# Experience Contract
+
+## Required Coverage
+
+Map every in-scope `feature_id + terminal_id` pair to at least one flow and screen or explicitly justify why no visual surface exists.
+
+`feature-screen-coverage.csv`:
+
+`feature_id,terminal_id,flow_id,screen_id,state_id,coverage_status,notes`
+
+`screen-states.csv`:
+
+`state_id,screen_id,state_type,trigger,user_message,available_actions,recovery,accessibility_notes`
+
+Use state types `default`, `loading`, `empty`, `success`, `partial`, `error`, `permission`, `disabled`, and `recovery` as applicable.
+
+## 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.
+
+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.
+
+## 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.
+
+`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.
+
+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
+
+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.
+
+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.
+
+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.
+
+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.
+
+Each prototype manifest contains:
+
+- 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.
+
+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.
+
+`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`
+
+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:
+
+- tool-selection validity;
+- page/canvas/file management validity;
+- mandatory staged human-review closure for `UX-LF`, `UX-VS`, and `UX-UI`;
+- review-impact propagation;
+- product behavior and acceptance alignment;
+- terminal coverage;
+- product-manual terminology;
+- initial architecture constraints;
+- state and interaction coverage;
+- 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.
+
+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.

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

@@ -0,0 +1,68 @@
+# Prototype Management Contract
+
+## 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`:
+
+`candidate_id,prototype_artifact_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.
+
+## Stable Page Identity
+
+Use separate fields for identity and display:
+
+- Main page: `page_id: P01`, `page_name: 页面名称A`, `display_label: P01-页面名称A`.
+- Child page: `page_id: P01-01`, `parent_page_id: P01`, `page_name: 页面名称1`, `display_label: P01-01-页面名称1`.
+
+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.
+
+## Canvas And File Boundaries
+
+Use:
+
+- `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.
+
+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`.
+
+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.
+
+## 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.
+
+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.
+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.
+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.
+
+## 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.
+
+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`.
+
+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.
+
+## 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.

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

@@ -0,0 +1,56 @@
+---
+name: ai-delivery-design-tests
+description: Validate confirmed prototype testability and define the overall release test strategy and public test contract for the next agile iteration slice. Use before TDD implementation, when a prototype or architecture test seam changes, when acceptance criteria are unclear, after replanning, or when independent verification finds a gap in test design.
+---
+
+# Design Tests
+
+Create a durable release strategy once and detailed test inputs just in time for the next slice.
+
+## 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.
+
+## Task State
+
+1. Invoke `$ai-delivery-checkpoint-task` before preflight to recover or initialize the task snapshot.
+2. Checkpoint after every meaningful artifact, gate, validation, merge, deployment action, or other external milestone, and before compaction or interruption.
+3. Before returning, finish the snapshot as `completed`, `blocked`, `failed`, or `interrupted`, with actual outputs, evidence, blockers, and one idempotent next action. A Hook event alone never proves completion.
+
+## 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.
+
+## 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.
+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.
+
+## Outputs
+
+- overall `test-strategy.md`;
+- current `iteration-test-contract.md`;
+- 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;
+- `prototype-test-scope.csv`;
+- test traceability CSV files including `experience_change_id` coverage;
+- gaps returned to product, experience, architecture, or planning.
+
+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.

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

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Design Tests"
+  short_description: "Validate prototype testability and design test contracts"
+  default_prompt: "Use $ai-delivery-design-tests to validate prototype testability and design tests for the current iteration."

package/skills/ai-delivery-design-tests/assets/test-design-template/iteration-test-contract.md

@@ -0,0 +1,19 @@
+# Iteration Test Contract
+
+## Selected Slice And Sources
+
+## Confirmed Public Seams
+
+## Acceptance Examples
+
+## Contract And Data Obligations
+
+## Quality Targets
+
+## Test Data And Environment
+
+## Developer Automation
+
+## Entry And Exit Criteria
+
+## Traceability And Gaps

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

@@ -0,0 +1 @@
+prototype_artifact_id,prototype_version,terminal_id,slice_id,scope_status,rationale,evidence_ref

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

@@ -0,0 +1,73 @@
+artifact_id: PROTOTYPE-TEST-VALIDATION-0001
+artifact_type: prototype-test-validation
+version: 1
+iteration_id: ITER-0001
+status: draft
+producer_skill: ai-delivery-design-tests
+input_artifacts:
+  ui_handoff: UI-HANDOFF-0001@1
+  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_confirmation: PROTOTYPE-CONFIRMATION-0001@1
+  architecture_validation: PROTOTYPE-ARCH-VALIDATION-0001@1
+  prototype_tool_selection: PROTOTYPE-TOOL-SELECTION-0001@1
+  prototype_review_decision: PROTOTYPE-REVIEW-DECISION-0001@1
+  prototype_impact_assessment: PROTOTYPE-IMPACT-ASSESSMENT-0001@1
+standards: []
+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
+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_confirmation_ref: PROTOTYPE-CONFIRMATION-0001@1
+prototype_confirmation_checksum: REPLACE_WITH_SHA256
+source_revision: REVISION-0001
+review_bundle_algorithm: sha256
+review_bundle_checksum: REPLACE_WITH_SHA256
+tool_selection_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
+prototype_review_decision_checksum: REPLACE_WITH_SHA256
+prototype_review_sessions_checksum: REPLACE_WITH_SHA256
+prototype_review_comments_checksum: REPLACE_WITH_SHA256
+prototype_adjustment_log_checksum: REPLACE_WITH_SHA256
+prototype_impact_assessment_checksum: REPLACE_WITH_SHA256
+traceability_checksum: REPLACE_WITH_SHA256
+state_catalog_checksum: REPLACE_WITH_SHA256
+feature_screen_coverage_checksum: REPLACE_WITH_SHA256
+architecture_validation_ref: PROTOTYPE-ARCH-VALIDATION-0001
+architecture_validation_version: 1
+architecture_validation_checksum: REPLACE_WITH_SHA256
+architecture_baseline_ref: ARCH-FINAL-0001@1
+architecture_baseline_checksum: REPLACE_WITH_SHA256
+test_contract_id: TEST-CONTRACT-0001
+test_contract_version: 1
+test_contract_checksum: REPLACE_WITH_SHA256
+decision: changes-required
+affected_experience_change_ids: []
+affected_page_ids: []
+affected_canvas_ids: []
+affected_prototype_file_ids: []
+affected_prototype_element_ids: []
+observable_seams: []
+untestable_elements: []
+ambiguity_findings: []
+accessibility_coverage: []
+blocking_issues: []
+return_node: experience-design
+evidence: []

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

@@ -0,0 +1,31 @@
+# Test Design Contract
+
+## 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.
+
+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.
+
+## Quality Gates
+
+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.
+
+## 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.
+- 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.
+
+## Prototype Test Validation
+
+`prototype-test-scope.csv`:
+
+`prototype_artifact_id,prototype_version,terminal_id,slice_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.
+
+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.

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

@@ -0,0 +1,66 @@
+---
+name: ai-delivery-develop-iteration
+description: Orchestrate implementation of one planned vertical slice from an exact confirmed prototype and public test contract by deriving dynamic technical work packages, assigning capability-based AI roles, enforcing TDD and independent review, and assembling a candidate. Use when an iteration slice, prototype receipts, and public test contract are ready for implementation or when verified defects return to development.
+---
+
+# Develop Iteration
+
+Derive technical tasks just in time. Do not predefine frontend, backend, database, or other roles unless the selected slice and architecture require them.
+
+## 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.
+
+## Task State
+
+1. Invoke `$ai-delivery-checkpoint-task` before preflight to recover or initialize the task snapshot.
+2. Checkpoint after every meaningful artifact, gate, validation, merge, deployment action, or other external milestone, and before compaction or interruption.
+3. Before returning, finish the snapshot as `completed`, `blocked`, `failed`, or `interrupted`, with actual outputs, evidence, blockers, and one idempotent next action. A Hook event alone never proves completion.
+
+## 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.
+
+## Derive Work Packages
+
+Resolve the only code repository from `.workflow/config/workspace.yaml`. Put source, retained tests, package manifests, and all work branches there; put work-package definitions, task shards, review decisions, and evidence in the workflow repository. Every handoff reference to code must include the configured `repo_id`, exact `code_commit`, optional `code_tag`, `source_path`, and SHA-256.
+
+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.
+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.
+8. Use `$ai-delivery-manage-git` to create an isolated worktree and `work/<iteration-id>/<task-id>-<slug>` branch for every package.
+
+## 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.
+
+## TDD Policy
+
+Require TDD for business behavior, defect fixes, and contracts. Allow documented exceptions for generated code, pure configuration, simple visual-only changes, or disposable probes. Record the reason and review the exception.
+
+## Outputs
+
+- technical work package and dependency CSV files;
+- `task-prototype-traceability.csv` for UI-bearing packages;
+- `task-experience-change-traceability.csv` for UI-bearing packages, with explicit create/update/remove/migrate/no-code action;
+- dynamic role profiles;
+- source, migration, configuration, and documentation changes;
+- retained tests and Red/Green evidence;
+- independent review results and resolutions;
+- slice traceability and known limitations;
+- buildable candidate commit and candidate manifest.
+
+Read [development-contract.md](references/development-contract.md).
+
+## Handoff
+
+Hand the candidate to `$ai-delivery-verify-candidate` only after all package reviews, CI gates, and developer checks pass and the delivery platform supplies a reproducible test environment.

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

@@ -0,0 +1,4 @@
+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/task-experience-change-traceability.csv

@@ -0,0 +1 @@
+task_id,experience_change_id,change_type,implementation_action

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

@@ -0,0 +1 @@
+task_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id

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

@@ -0,0 +1,39 @@
+# Development Contract
+
+## Technical Work Packages
+
+`technical-work-packages.csv`:
+
+`task_id,iteration_id,slice_id,sequence,title,objective,capability_role,work_package_ref,stack_ref,test_seam_ref,status`
+
+`task-dependencies.csv`:
+
+`predecessor_task_id,successor_task_id,dependency_type`
+
+`task-acceptance.csv`:
+
+`task_id,acceptance_id`
+
+`task-prototype-traceability.csv`:
+
+`task_id,prototype_artifact_id,prototype_version,source_revision,prototype_file_id,canvas_id,page_id,prototype_element_id`
+
+`task-experience-change-traceability.csv`:
+
+`task_id,experience_change_id,change_type,implementation_action`
+
+Use only `create`, `update`, `remove`, `migrate`, and `no-code` for `implementation_action`. Every UI-bearing task must map to at least one `ready-for-development` experience change. Do not derive action type from screenshots, visual diffs, filenames, or chat history.
+
+Store detailed commands, expected outputs, risks, evidence, and rollback impact in one Markdown record per task.
+
+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.
+
+## 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.
+
+## Dynamic Role Rules
+
+Name the role from required capability, not organization chart. Combine roles when boundaries and risk permit. Keep implementation separate from change review, independent testing, and high-risk security validation.

package/skills/ai-delivery-evolve-workflow/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: ai-delivery-evolve-workflow
+description: Record explicit workflow feedback and objective delivery signals, evaluate them at safe points, govern project-local extensions through risk-classified proposals and trials, and inspect, approve, disable, roll back, or export extension evidence. Use when a user suggests improving the installed workflow, repeated failures or Gate rejections indicate a process problem, an evolution review is due, an extension needs approval or recovery, or another delivery Skill reaches a task or version safe point.
+---
+
+# Evolve The Project Workflow
+
+Use the project Evolution CLI for every feedback, proposal, extension, trial, and decision state change. Never edit `.workflow/evolution/index.yaml` or registered extension state directly.
+
+## Capture Feedback
+
+1. Treat explicit improvement language such as “以后应当”“这里不合理” or “建议” as feedback without asking again.
+2. Record a concise structured summary and return the generated feedback ID to the user.
+3. Use `source_kind: user` for explicit user intent, `objective` for repeatable failures, and `ai-observation` for a single AI hypothesis.
+4. Never persist full conversations, secrets, sensitive values, or chain-of-thought.
+
+Run:
+
+```text
+node .workflow/tools/evolution/evolve.mjs feedback record ...
+```
+
+## Evaluate Only At Safe Points
+
+Invoke `evaluate --safe-point task` after a task finishes, `--safe-point version` during version closeout, or `--safe-point review` on explicit request. Do not change extension behavior during an active task.
+
+- A user suggestion or strong Gate/version failure may become a proposal immediately.
+- Other objective signals require three distinct events or two distinct tasks.
+- A single `ai-observation` cannot authorize a proposal.
+
+## Govern Extensions
+
+1. Create a proposal spec with hypothesis, baseline, metrics, scope, rollback conditions, and feedback IDs.
+2. Generate extension files only in `.workflow/delivery/runtime/evolution/staging/`.
+3. Call `register`; let the CLI copy and checksum the version into `.workflow/extensions/`.
+4. Start or enable an extension only with `--safe-point task|version|review` after the active-task marker has been cleared. A terminal extension cannot be revived; changed content requires a new version.
+5. Let low-risk extensions enter trial automatically. For medium/high risk, Node scripts, or blocking behavior, first record an `extension-approval` feedback receipt with `--explicit-user`, `--confirmation-subject <id>@<version>`, and `--confirmation-checksum <sha256>`, then pass its ID to `approve --confirmation-feedback-id`.
+6. Record trial observations only at safe points. Low-risk trials become active after three applicable executions or one completed iteration when metrics do not worsen. Medium/high risk must pass trial before a second explicit `enable --state active` transition.
+7. Disable or roll back on regression, Hook failure, conflict, or checksum damage. Preserve all evidence.
+
+User-authored files are not trusted merely because they exist in `.workflow/extensions/`; register and enable them through the same process.
+
+## Respect Precedence
+
+Apply constraints in this order:
+
+```text
+core safety and Gates > approved standards > human-approved extensions > automatic trial extensions
+```
+
+An extension never edits package-managed Skills, formal-state tools, Hook tools, standards, or Gate definitions. Disable the lower-precedence extension on conflict.
+
+## Export Safely
+
+Use `export` only to create a local, redacted promotion bundle. Never send it to another repository, project, or service without explicit user confirmation.
+
+Read [evolution-contract.md](references/evolution-contract.md) before creating a proposal, manifest, executable Hook, or approval decision.

package/skills/ai-delivery-evolve-workflow/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "自进化工作流"
+  short_description: "持续记录反馈、评估信号并安全演进项目级交付工作流扩展能力"
+  default_prompt: "使用 $ai-delivery-evolve-workflow 记录当前意见并在安全点评估可验证的项目级扩展。"

package/skills/ai-delivery-evolve-workflow/references/evolution-contract.md

@@ -0,0 +1,42 @@
+# Evolution Contract
+
+## Storage
+
+- `.workflow/evolution/` contains Git-tracked feedback, proposals, experiments, decisions, and local promotion bundles.
+- `.workflow/extensions/<extension-id>/versions/<version>/` contains immutable registered versions.
+- `.workflow/delivery/runtime/evolution/` contains ignored event queues, staging files, and idempotency data.
+- `.workflow/tools/evolution/evolve.mjs` is the only state mutation entrypoint.
+
+## Lifecycle
+
+Use `observed`, `proposed`, `trial`, `active`, `rejected`, `disabled`, `rolled-back`, `superseded`, and `expired`. Enforce `proposed -> trial -> active`; terminal versions cannot be revived. Do not expire by elapsed time or iteration count. Use `expired` only for explicit closure or objectively vanished applicability. Bind approvals to extension ID, version, SHA-256, an explicit-user confirmation feedback receipt, source event, and time.
+
+## Risk
+
+- `low`: advisory, checklist, display, or non-blocking declarative checks. Automatic trial is allowed; output is limited to `pass` or `warn`.
+- `medium`: routing, template, work-package, artifact-generation, or validation behavior. Human approval is required.
+- `high`: block, Node script, Git, deployment, security, permission, environment, or external-system capability. Human approval is required.
+
+The CLI derives risk from the manifest and may only raise the requested risk.
+
+## Manifest
+
+Use schema version 1 with `extension_id`, `version`, non-empty `capabilities`, and non-empty `hooks`. Each Hook declares `event`, `decision`, optional `message`, optional `evidence_refs`, and optional project-local `.mjs` `entrypoint`. A blocking decision is valid only on a `before` event, so a stopped transition cannot leave already-written formal state behind.
+
+Supported events are `before`, `after`, and `failed` for task, node, gate, artifact, version, and release, plus `feedback-recorded`, `evaluation-due`, and `extension-state-changed`.
+
+Hook output is JSON:
+
+```json
+{
+  "decision": "pass | warn | block",
+  "messages": [],
+  "evidence_refs": []
+}
+```
+
+Node 18 remains supported. Import checks, a ten-second maximum timeout, a project-local working directory, and a minimal environment reduce risk but are not a security sandbox. Hook messages and evidence references are type-checked, bounded, and redacted before returning or entering Git-tracked audit records.
+
+## Trial
+
+Every proposal declares a hypothesis, baseline, metrics, scope, and rollback conditions. Trial and activation commands require a named safe point and are rejected while `.workflow/delivery/runtime/active-task.json` exists. The default observation window is three applicable executions or one completed iteration, whichever occurs first. A low-risk trial with no regression becomes active automatically. Medium/high trials wait for explicit activation after evaluation. Any `worsened`, `failure`, Hook failure, or checksum damage rolls back or disables the affected extension.