ai-delivery-workflow 0.5.0 → 0.6.0

package/skills/ai-delivery-orchestrate/assets/communication-template/confirmation-summary.yaml

@@ -0,0 +1,42 @@
+schema_version: 1
+summary_id: CONFIRMATION-SUMMARY-0001
+version: 1
+status: draft
+node: 01-product-shaping
+iteration_id: ITERATION-0001
+task_id: TASK-0001
+owner: team-or-role
+source_revision: REPLACE_WITH_CODE_OR_WORKFLOW_COMMIT
+updated_at: REPLACE_WITH_ISO_TIMESTAMP
+frontier_round: 1
+shared_understanding: false
+shared_understanding_actor: null
+shared_understanding_confirmed_at: null
+grouping_rationale: null
+records:
+  - confirmation_id: CONF-0001
+    question_id: Q-0001
+    parent_decision_id: null
+    frontier_round: 1
+    category: business_decision
+    status: proposed
+    question: "What decision must the user make?"
+    recommendation: "Recommended option and why."
+    options:
+      - id: OPTION-A
+        label: "Option A"
+        rationale: "Tradeoff and evidence."
+    decision: null
+    rationale: null
+    actor: null
+    confirmed_at: null
+    depends_on: []
+    evidence_refs: []
+    authority_refs: []
+    impact_refs: []
+    owner: product-owner
+    next_action: "Ask Q-0001 and wait for the user's answer."
+    next_action_owner: user
+    supersedes: null
+    superseded_by: null
+open_questions: []

package/skills/ai-delivery-orchestrate/assets/project-template/.workflow/iterations/ITER-0001/02-solution-design/product-impact-assessment.yaml

@@ -0,0 +1,42 @@
+artifact_id: PRODUCT-IMPACT-ASSESSMENT-0001
+artifact_type: product-impact-assessment
+version: 1
+iteration_id: ITER-0001
+status: draft
+producer_skill: ai-delivery-design-architecture
+source_node: 02-solution-design
+input_artifacts: []
+product_baseline:
+  id: PRODUCT-BASELINE-0001
+  version: 1
+  checksum: REPLACE_WITH_SHA256
+decision: clarification-required
+trigger:
+  kind: prototype-adjustment
+  summary: REPLACE_WITH_OBSERVED_CHANGE
+affected_product_assets:
+  terminals: []
+  features: []
+  stories: []
+  acceptance_criteria: []
+  non_functional_requirements: []
+  business_terms: []
+affected_design_assets:
+  experience_changes: []
+  prototype_pages: []
+  review_scenes: []
+  architecture_decisions: []
+  quality_budgets: []
+confirmation:
+  questions: []
+  summary_ref: .workflow/communication/confirmation-summary.yaml
+return:
+  required: true
+  node: 01-product-shaping
+  mode: prototype-reconciliation
+  reason: REPLACE_WITH_REASON
+rebaselines_required: []
+stale_artifacts: []
+product_reconciliation_ref: null
+evidence: []
+blocking_issues: []

package/skills/ai-delivery-orchestrate/assets/project-template/.workflow/tools/hooks/hook-event.mjs

@@ -144,15 +144,9 @@ function enforceFrontendGuard(projectRoot, input) {
 }
 
 try {
-  const currentProjectFile = findUp(process.cwd(), path.join(".workflow", "delivery", "project.yaml"));
-  const legacyProjectFile = currentProjectFile
-    ? null
-    : findUp(process.cwd(), path.join("delivery", "project.yaml"));
-  const projectFile = currentProjectFile || legacyProjectFile;
+  const projectFile = findUp(process.cwd(), path.join(".workflow", "delivery", "project.yaml"));
   if (!projectFile) process.exit(0);
-  const projectRoot = currentProjectFile
-    ? path.dirname(path.dirname(path.dirname(projectFile)))
-    : path.dirname(path.dirname(projectFile));
+  const projectRoot = path.dirname(path.dirname(path.dirname(projectFile)));
   const markerFile = path.join(projectRoot, ".workflow", "delivery", "runtime", "active-task.json");
   const marker = fs.existsSync(markerFile) ? JSON.parse(fs.readFileSync(markerFile, "utf8")) : null;
   const raw = await readStdin();

package/skills/ai-delivery-orchestrate/assets/project-template/AGENTS.md

@@ -36,12 +36,11 @@
 4. 任务、checkpoint、恢复状态、活动任务标记和版本归档只能由 `.agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs` 修改。
 5. 正式流程、物料和 Gate 状态只能由 `node .workflow/tools/state/state.mjs ...` 修改。禁止直接编辑 `.workflow/delivery/workflow-state.yaml`、`.workflow/delivery/artifact-registry.yaml` 和 `.workflow/delivery/state-events.jsonl`。
 5.1 研发 scope 使用 `iteration-started`，发布 scope 仅在用户明确发布后使用 `release-started`；两者可并行且不得互相重置。节点必须满足流程图前置条件、成功证据和当前尝试的强制 Gate。
-5.1.1 当前研发生产路线是 `development-seven-node`：`00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`。生产 Skill 只能为新任务、物料和正式 transition 使用这些研发节点 ID。`development-legacy-13` 仅提供只读兼容：`inspect`、`verify`、`rebuild` 和显式迁移可以读取历史状态；新任务、物料登记、transition、candidate、版本收尾和 Gate 写入全部拒绝。发布节点 `R00-release-request` 至 `R10-release-archive` 继续允许写入。
-5.1.2 Bootstrap 报告旧 schema、任务分组歧义或错误归档时，先运行发行包 `migrate --dry-run` 审阅 schema、分组、冲突、已验证 anchor 和文件变化。旧根布局会复制到 `.workflow/`，平铺 task 增加显式 attempts；分组歧义只能用绑定 dry-run source checksum、`human:` actor 和 rationale 的 `--decisions` 文件解除。结构迁移保持源字节、task lifecycle、scope、正式视图和旧事件字节不变；错误归档只通过带人工 actor、原因、RCA 与恢复 evidence 的独立 `repair --invalidate-archive` 前向事务失效，原归档不得改写。迁移后出现 schema 2 事务或迁移目标字节漂移即关闭回滚窗口。compact 与迁移分离：可信 anchor 建立后先运行 `ai-delivery compact <project> --dry-run` 审阅 coverage、root digest 和字节计划，只有人工明确要求才应用。
-5.1.3 Prototype 迁移的 dry-run 必须报告旧 set 中声明、有效和无效成员数量，并据此区分零成员、单成员和多成员；同一份 decisions 文件必须同时包含 `decisions` 与 `prototype_decisions`。完整性或 checksum 冲突只能修复源证据，人工决定不得覆盖；旧 member/set、关闭或归档记录、Gate 和事件保持原字节。迁移后的唯一 descriptor 状态为 `migration-pending-ux-ui`，必须先建立并校验完整的新 Prototype revision，再执行全新的 `UX-UI`；原型查看与审核统一由工作流管理器承担。
-5.2 Delivery Readiness 使用 `scope freeze` 冻结带 checksum 的 Slice、需求、验收、任务和物料集合并启用 `scope_contract_version: 1`。冻结后只有带明确人工批准和 `--supersedes` 的 `scope amend` 可以改变范围；预算超限仅用 `scope warn` 登记 `warn-only` 与 `reslice_performed: false`，不得自动重新切片或改变验收。历史 scope 未启用该字段时保持旧契约兼容。
+5.1.1 当前研发生产路线是 `development-seven-node`：`00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`。生产 Skill 只能为新任务、物料和正式 transition 使用这些研发节点 ID。发布节点 `R00-release-request` 至 `R10-release-archive` 继续允许写入。
+5.1.2 当前项目只接受 schema 2 formal state、canonical task shape、当前 `.workflow/` 布局和 v2 Prototype Revision。doctor、state inspect、prototype validation 或 checksum 检查失败时停止并报告精确冲突；修复必须通过受控当前接口完成。
+5.2 Delivery Readiness 使用 `scope freeze` 冻结带 checksum 的 Slice、需求、验收、任务和物料集合并启用 `scope_contract_version: 1`。冻结后只有带明确人工批准和 `--supersedes` 的 `scope amend` 可以改变范围；预算超限仅用 `scope warn` 登记 `warn-only` 与 `reslice_performed: false`，不得自动重新切片或改变验收。
 5.3 从 `inspect.derived_node_states` 读取 `pending | active | waiting | blocked | ready-to-complete | completed`，不得根据聊天或单一任务状态直接写正式节点状态。投影必须综合 task、最新 blocking finding、Gate、artifact、candidate、当前 scope manifest 和 completion receipt；受新契约治理的节点仅能从 `ready-to-complete` 完成，并写入绑定这些事实的 completion receipt。
-5.4 `draft/review-draft` 是 registry 外的可变 working file。提交、拒绝、批准、冻结、失败等语义决定使用新 artifact ID 登记为不可变 revision；后续决定通过 `--supersedes` 创建新 revision，不得用 `artifact status` 原地改写。`artifact status` 只兼容迁移升级前已登记的 draft。`artifact compact` 默认零写入；apply 必须先把 anchor 覆盖的 legacy shard 原字节写入 checksummed gzip bundle，并从包内完整 replay 到锚定 registry checksum，验证失败不得移除 loose history；成功后的模式是 `compacted-history`。`artifact prune` 同样默认零写入，只有显式 `--apply` 才能删除 artifact shard 并写 retention receipt；其模式是 `retained-history`，不得声称重审已删除字节。
+5.4 `draft/review-draft` 是 registry 外的可变 working file。提交、拒绝、批准、冻结、失败等语义决定使用新 artifact ID 登记为不可变 revision；后续决定通过 `--supersedes` 创建新 revision，不得原地改写。`artifact prune` 默认零写入，只有显式 `--apply` 才能删除 anchor 覆盖的 artifact shard 并写 retention receipt；其模式是 `retained-history`，不得声称重审已删除字节。
 6. 状态脚本失败时必须停止并修复输入、revision 冲突或脚本问题，不得手工修改受控文件绕过失败。
 7. 每次状态变更前运行 `inspect` 获取当前 revision；每次节点交接、版本收尾、生产审批、部署和发布归档前运行 `verify`。
 8. 读取 `.workflow/standards/index.yaml`，只加载适用于当前任务且状态为 `approved` 的规范。

package/skills/ai-delivery-orchestrate/references/codebase-document-contract.md

@@ -0,0 +1,91 @@
+# Codebase Documentation Contract
+
+This contract defines the project-owned documentation that lives in the independent code repository. It is a writing and validation contract, not a second workflow state store.
+
+## Files
+
+```text
+code/
+├─ AGENTS.md
+├─ CODEBASE_GUIDE.md
+└─ docs/
+   └─ CODEBASE_INDEX.md
+```
+
+- `CODEBASE_GUIDE.md` is the human-readable handbook for repository maintainers and contributors.
+- `AGENTS.md` is a short agent entrypoint. It contains only high-priority rules and conditional pointers into the handbook and index.
+- `docs/CODEBASE_INDEX.md` is the human-readable navigation map for directories, modules, entrypoints, tests, dependencies, risks, and maintenance ownership.
+
+The first release uses Markdown as the source of truth. A YAML or database projection is out of scope until a real consumer and synchronization contract exist.
+
+## Authority
+
+The project workflow repository remains authoritative for approved architecture, standards, formal state, task scope, Gates, and release identity. Code-repository documentation explains how to apply those decisions while working in source. When the handbook conflicts with an approved workflow artifact, stop relying on the conflicting section, report the conflict, and update the handbook through the owning workflow node.
+
+The environment is authoritative for facts it already expresses precisely, such as package scripts, compiler options, CI jobs, and directory names. The handbook should capture rationale, conventions, risks, and entrypoints that the environment cannot express reliably; it should link to rather than duplicate long configuration files.
+
+## Audience and language
+
+Write for a repository maintainer first. Use plain Simplified Chinese for explanatory prose and preserve technical identifiers, paths, commands, schemas, and protocol values exactly. A maintainer should be able to answer these questions without reading source code first:
+
+1. What is this project and where does execution start?
+2. How do I install, run, test, debug, review, and release it?
+3. Which layers and modules may depend on each other?
+4. Which paths are high risk, generated, externally maintained, or not directly editable?
+5. Which tests and evidence are required after a change?
+6. Who maintains this document and when must it be updated?
+
+## Guide sections
+
+`CODEBASE_GUIDE.md` must contain, or explicitly link to, these sections:
+
+1. project overview and ownership;
+2. quick start and verified commands;
+3. repository map and runtime entrypoints;
+4. layering and dependency direction;
+5. naming, testing, error, logging, configuration, security, and migration conventions;
+6. change workflow and verification expectations;
+7. risks, generated files, protected paths, and rollback notes;
+8. documentation ownership, freshness, approval references, and update triggers.
+
+## Index fields
+
+Every index row describes a directory or a key file relative to the code-repository root. Use these columns when applicable:
+
+| Field | Meaning |
+| --- | --- |
+| `path` | Relative path; never an absolute path or a path containing `..`. |
+| `purpose` | Why the directory or file exists. |
+| `entrypoints` | Main executable, route, public API, or command entrypoints. |
+| `tests` | Relevant native test paths or commands. |
+| `dependencies` | Important allowed dependencies or consumers. |
+| `risk` | `low`, `medium`, or `high`, with a short reason for `high`. |
+| `generated` | Whether a command regenerates the content. |
+| `owner` | Team or role responsible for keeping the entry accurate. |
+| `source_commit` | Code commit the entry was checked against. |
+| `last_reviewed` | ISO date of the latest human or validator review. |
+| `status` | `observed`, `approved`, or `stale`. |
+| `references` | Architecture, standards, task, test, or operational references. |
+
+Directory-level rows are the default. Use file-level rows for entrypoints, cross-layer adapters, persistence/authentication/deployment configuration, generated boundaries, and high-risk modules. The index is not required to enumerate every ordinary source file.
+
+## Freshness and safety
+
+- `observed` means discovered by Bootstrap or a tool and not yet approved by a maintainer.
+- `approved` means reviewed against the current code and the relevant approved architecture/standards.
+- `stale` means the recorded `source_commit` or referenced path may no longer describe the code.
+- A missing, stale, conflicting, or path-invalid entry must be reported before code modification relies on it.
+- Never put credentials, private keys, production data, or large source excerpts in these files.
+- `init` and `upgrade` must preserve existing code-repository documentation. Any creation or revision must be explicit, reviewable, and attributable to the owning workflow task.
+
+## Writing quality
+
+Prefer short paragraphs, tables, links, and concrete examples. Put the answer before the background. Keep one rule in one authoritative location. Link to formal workflow artifacts instead of copying their full contents. Every procedural section should end with a checkable command, file, review, or evidence criterion.
+
+## Completion checklist
+
+- A maintainer can find the runtime entrypoint, test entrypoint, and high-risk paths within one screen of navigation.
+- Every high-risk index row names its tests, owner, and update trigger.
+- Commands are verified from repository configuration or a recorded validation run.
+- All paths resolve inside the code repository and all status/commit metadata is current.
+- Conflicts with workflow architecture or standards are explicitly linked and not silently resolved in prose.

package/skills/ai-delivery-orchestrate/references/communication-confirmation-contract.md

@@ -0,0 +1,52 @@
+# Communication Confirmation Contract
+
+This contract records structured user decisions without storing a conversation transcript. It is a traceability index, not a second product, architecture, standards, task, or formal-state authority.
+
+## Placement and authority
+
+Store a mutable draft and its later immutable revisions under the current workflow repository's version-scoped node directory:
+
+```text
+.workflow/iterations/<iteration-id>/<node-id>/confirmation-summary.yaml
+```
+
+The summary may point to product, architecture, standards, task, Gate, or release artifacts, but those owning artifacts remain authoritative. A `confirmed` record is incomplete until its `authority_refs` points to the owning artifact or explicitly records the handoff that will create it.
+
+Do not store full chat transcripts, credentials, production data, or model reasoning. Preserve only the question, recommendation, decision, rationale, evidence references, impact, and next action needed to resume safely.
+
+## Knowledge categories
+
+Allowed `category` values are:
+
+- `observed_fact`: source, configuration, Git, test, or runtime fact found by the Agent;
+- `business_fact`, `business_decision`, `domain_term`, `business_constraint`;
+- `architecture_decision`;
+- `standard_decision`;
+- `risk`, `assumption`, `open_question`;
+- `execution_fact`, `execution_decision`.
+
+Facts require `evidence_refs`. User decisions require `actor`, `decision`, and `confirmed_at`; an Agent recommendation is never approval. `domain_term` records must point to the Product Manual Business Glossary or a superseding product artifact. `architecture_decision` records must point to an architecture baseline, decision record, or architecture Gate.
+
+## Confirmation statuses
+
+`proposed` is waiting for a decision. `confirmed` and `rejected` close a decision. `deferred` remains unresolved and must retain a responsible owner and next action. `superseded` is historical and must point to the replacement through `supersedes` or `superseded_by`.
+
+## Decision tree and frontier
+
+Each record has a stable `confirmation_id`, a `question_id`, a `frontier_round`, and optional `depends_on` decision IDs. The current frontier consists only of `proposed` records whose dependencies are closed by `confirmed`, `rejected`, or a valid superseding record. A dependency cycle, unknown dependency, or proposed record with unresolved dependencies is invalid rather than silently skipped.
+
+The default interaction policy is one user decision per round. Multiple questions may be presented together only when they are independent, low-risk, and the summary explicitly records the grouping rationale.
+
+## Shared understanding
+
+Set `shared_understanding: true` only after the current frontier is empty and the user has confirmed the summary. `deferred` and `open_question` records may remain, but each must identify an owner and an idempotent `next_action`. A node must not perform an action that depends on an unresolved decision.
+
+## Wait and mutation boundary
+
+When `next_action_owner` is `user` or `external`, the task remains a zero-mutation wait state. Recovery reports the exact recorded question or wait condition; it does not activate tasks, mutate formal state, register artifacts, or change Git. After the required input arrives, the controlled task CLI transfers ownership to `agent` with a new idempotent next action.
+
+## Superseding and provenance
+
+Never edit a confirmed record in place. A correction creates a new record with `supersedes`, retains the previous checksum/reference, and routes affected artifacts stale or back to their owning node. Every summary revision should retain `summary_id`, `version`, `source_revision`, `owner`, and `updated_at`.
+
+See `assets/communication-template/confirmation-examples.yaml` for a maintainer-readable two-round example: a confirmed product decision opens an architecture frontier, and shared understanding is recorded only after both decisions have authority references.

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

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

package/skills/ai-delivery-orchestrate/references/product-impact-assessment-contract.md

@@ -0,0 +1,87 @@
+# Product Impact Assessment Contract
+
+`product-impact-assessment.yaml` is the shared design-stage receipt for any finding that may change an approved product baseline. It is an impact record, not a product decision. Product intent, scope, terminology, priority, risk acceptance, and terminal selection remain owned by `01-product-shaping`.
+
+## When to create one
+
+Create one before continuing `02-solution-design` when design discovers any of the following:
+
+- a Prototype adjustment changes user-visible behavior, acceptance, or a terminal;
+- a new logical terminal, Page, Review Scene, or channel is needed;
+- a quality, security, privacy, compliance, availability, performance, or cost requirement changes product tradeoffs;
+- an architecture constraint changes a goal, business rule, scope, priority, risk acceptance, or terminology;
+- a user confirmation is needed to choose between materially different product outcomes.
+
+Use `no-impact` only when the evidence proves that approved product behavior, scope, terminals, terminology, acceptance, and non-functional requirements are unchanged.
+
+## Controlled values
+
+`decision` is one of:
+
+- `no-impact`: design may continue after recording evidence;
+- `architecture-only`: only implementation structure changes and approved product behavior is unchanged;
+- `product-update-required`: product must create and approve a successor baseline;
+- `clarification-required`: a user decision is needed before classification can close.
+
+`status` is `draft`, `awaiting-product`, `resolved`, `invalid`, or `superseded`. A resolved `no-impact` or `architecture-only` assessment has `status: resolved`; `product-update-required` and `clarification-required` remain `awaiting-product` until a valid product reconciliation receipt is linked.
+
+## Required fields
+
+```yaml
+artifact_id: PRODUCT-IMPACT-ASSESSMENT-0001
+artifact_type: product-impact-assessment
+version: 1
+iteration_id: ITER-0001
+status: draft
+producer_skill: ai-delivery-design-architecture
+source_node: 02-solution-design
+input_artifacts: []
+product_baseline:
+  id: PRODUCT-BASELINE-0001
+  version: 1
+  checksum: SHA256
+decision: clarification-required
+trigger:
+  kind: prototype-adjustment
+  summary: "Describe the observed change"
+affected_product_assets:
+  terminals: []
+  features: []
+  stories: []
+  acceptance_criteria: []
+  non_functional_requirements: []
+  business_terms: []
+affected_design_assets:
+  experience_changes: []
+  prototype_pages: []
+  review_scenes: []
+  architecture_decisions: []
+  quality_budgets: []
+confirmation:
+  questions: []
+  summary_ref: .workflow/communication/confirmation-summary.yaml
+return:
+  required: true
+  node: 01-product-shaping
+  mode: prototype-reconciliation
+  reason: "Explain why product ownership is required"
+rebaselines_required: []
+stale_artifacts: []
+product_reconciliation_ref: null
+evidence: []
+blocking_issues: []
+```
+
+Every listed asset uses a stable ID. Every input and evidence item pins a version and checksum when one exists. `return.node` is `01-product-shaping` for `product-update-required` and `clarification-required`; it is the owning design phase for a closed `no-impact` or `architecture-only` result.
+
+## Closure and propagation
+
+1. The producing design skill writes the assessment and checkpoints it before asking a user question or changing downstream artifacts.
+2. `product-update-required` or `clarification-required` blocks the current design handoff. Product owns the question and writes `product-prototype-reconciliation.yaml` plus a new approved product baseline when needed.
+3. A successor product baseline supersedes the input baseline. Affected architecture, experience, planning, test, and delivery artifacts become `stale` until revalidated against the successor checksum.
+4. `architecture-only` may continue only when the assessment explicitly proves no product asset changed and any major architecture decision has its own approval.
+5. `no-impact` and `architecture-only` do not authorize editing a frozen Prototype or approved product baseline.
+
+## Compatibility
+
+The existing `prototype-impact-assessment.yaml` remains a Prototype-local evidence record. Its `assessments`, review checksums, and adjustment log are consumed as `input_artifacts` or `affected_design_assets`; it must be wrapped by this contract before a cross-node return or final handoff. The old `decision: changes-required` maps to `product-update-required` only when an affected product asset is listed; otherwise it maps to `architecture-only` or `clarification-required` after review.

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

@@ -10,7 +10,7 @@ Formal state schema 2 separates `development_state` from `release_state`. The tw
 
 `00-bootstrap -> 01-product-shaping(GATE-A -> GATE-B) -> 02-solution-design(UX-VS -> UX-UI) -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout -> release-ready`
 
-This is the installed `development-seven-node` producer route. New producer tasks, artifacts, and requested formal transitions use these node IDs. `development-legacy-13` is read-only compatibility: inspect, verify, rebuild, and explicit migration may consume historical records, while new task, artifact, transition, candidate, closeout, and Gate writes are rejected. Release nodes `R00-release-request` through `R10-release-archive` remain writable.
+This is the installed `development-seven-node` producer route. New producer tasks, artifacts, and requested formal transitions use these node IDs. Release nodes `R00-release-request` through `R10-release-archive` remain writable.
 
 Within `03-delivery-readiness`, platform preparation may start after the initial architecture baseline and must join planning and test design before scope freeze. Within `05-candidate-assurance`, change review and candidate verification bind to the same immutable candidate. Closeout creates an immutable version-ready Tag, advances `line/<product-id>`, archives closed version tasks, and stops. It never changes `main` or starts a release.
 
@@ -27,5 +27,3 @@ Only explicit user release intent may create R00. The user selects a cumulative
 Retain discovery Gate A, product Gate B, major architecture decisions, prototype tool selection, mandatory human `UX-VS`/`UX-UI`, standard governance, and exact-package production approval. Product reconciliation after all prototype candidates must be `valid/aligned`; intermediate handoffs use downstream contract validation.
 
 Advance only from immutable referenced inputs. Mark dependents stale after upstream change. Preserve failed candidates, releases, Tags, and deployment records. Treat image rollback as deployment state, never Git state. On restart reconcile workspace, Git, artifacts, and external systems; never automatically replay production actions.
-
-Legacy nodes `12-release-preparation` through `16-version-archive` remain readable only for historical audit compatibility and are not used for new work.

package/skills/ai-delivery-orchestrate/scripts/confirmation-state.mjs

@@ -0,0 +1,30 @@
+#!/usr/bin/env node
+import { readConfirmationSummary } from "../../../lib/communication-confirmation.mjs";
+
+const [command, file] = process.argv.slice(2);
+if (!command || !file || !["validate", "frontier"].includes(command)) {
+  console.error("Usage: confirmation-state.mjs <validate|frontier> <confirmation-summary.yaml>");
+  process.exit(2);
+}
+try {
+  const result = readConfirmationSummary(file);
+  const payload = {
+    summary_checksum: result.checksum,
+    valid: result.validation.valid,
+    errors: result.validation.errors,
+    warnings: result.validation.warnings,
+    frontier: result.validation.frontier,
+    blocked_proposals: result.validation.blocked_proposals,
+  };
+  process.stdout.write(`${JSON.stringify(command === "frontier" ? {
+    summary_checksum: payload.summary_checksum,
+    valid: payload.valid,
+    errors: payload.errors,
+    frontier: payload.frontier,
+    blocked_proposals: payload.blocked_proposals,
+  } : payload, null, 2)}\n`);
+  process.exit(result.validation.valid ? 0 : 1);
+} catch (error) {
+  console.error(error.message);
+  process.exit(1);
+}

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

@@ -18,7 +18,7 @@ Coordinate `R00` through `R10`. Never infer release intent from completed versio
 ## Route Release Nodes
 
 1. `R01-version-selection`: invoke `$ai-delivery-assemble-release` to calculate and freeze the version selection, including the R00 `main` snapshot and exactly one target `version-ready` Tag.
-2. `R02-release-eligibility`: require continuous lineage, immutable tags, eligible artifacts, and the unchanged R00 main snapshot. For incremental release the snapshot must precede the target Tag; for same-version redeploy the target Tag must already be reachable from the snapshot. Also require every adjacent code and workflow ancestry edge, available images, compatible migrations/configuration, and no stale candidate.
+2. `R02-release-eligibility`: require continuous lineage, immutable tags, eligible artifacts, and the unchanged R00 main snapshot. For incremental release the snapshot must precede the target Tag; for same-version redeploy the target Tag must already be reachable from the snapshot. Also require every adjacent code and workflow ancestry edge, available images, compatible migrations/configuration, a resolved or superseded product impact assessment, and no stale candidate.
 3. `R03-material-aggregation`: aggregate checksummed requirements, architecture, prototypes, code, images, configuration, migrations, tests, risks, operations, and rollback materials.
 4. `R04-release-candidate`: invoke `$ai-delivery-manage-git`'s `scripts/release-git.mjs create-candidate` with `--release-id`, `--release-branch`, `--expected-main`, one `--source-tag`, its exact `--source-commit`, `--receipt`, and `--apply`. It creates `release/<release-id>-<slug>` from that snapshot. It merges the Tag with `--no-ff` for incremental release; for same-version redeploy when the Tag is already in the snapshot, it freezes that snapshot as the no-new-merge candidate. A moved `main` invalidates this release ID's candidate instead of changing its base.
 5. `R05-release-verification`: invoke `$ai-delivery-verify-candidate` with `scope: release`, bound to the exact candidate merge commit. Any release-fix creates a new candidate and repeats affected verification.
@@ -31,3 +31,5 @@ Coordinate `R00` through `R10`. Never infer release intent from completed versio
 Run routine formal `verify` at every handoff and reserve `verify --history` for R10 or an explicit history audit. Preserve failed releases and evidence. Stop instead of replaying a production action after recovery.
 
 Read [release-workflow-contract.md](references/release-workflow-contract.md) and use the request and selection assets.
+
+Validate the confirmation summary and require an explicit release decision linked to the release artifact. Proposed, deferred, or superseded records cannot authorize release; ambiguity returns to its owning node and leaves the release waiting.

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

@@ -23,7 +23,7 @@ This Skill owns the planning task phases inside `03-delivery-readiness` and conv
 
 ## Preflight
 
-Read approved product, final architecture, and experience baselines; exact `ui-handoff.yaml`; aligned `product-prototype-reconciliation.yaml`; experience/requirement change sets; interaction, visual, component, and page-component contracts; the exact confirmed Prototype revision and checksum; its source and review-bundle checksums; the normalized terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs; and the accepted architecture receipt; current backlog; production state; applicable standards; and unresolved risks. Require `development_readiness: ready-for-development` and reject stale changes, missing or conflicting references, non-passing decisions, or identity/checksum mismatches. Never infer a relationship from a file name or catalog order. Distinguish product priority from technical execution order.
+Read approved product, final architecture, and experience baselines; exact `ui-handoff.yaml`; aligned `product-prototype-reconciliation.yaml`; experience/requirement change sets; interaction, visual, component, and page-component contracts; the exact confirmed Prototype revision and checksum; its source and review-bundle checksums; the normalized terminal, Page, Review Scene, trigger-condition, route, and UI Mapping catalogs; and the accepted architecture receipt; current backlog; production state; applicable standards; unresolved risks; and the code repository handbook/index entries for affected paths. Require `development_readiness: ready-for-development` and reject stale changes, missing or conflicting references, non-passing decisions, or identity/checksum mismatches. Never infer a relationship from a file name or catalog order. Distinguish product priority from technical execution order.
 
 ## Workflow
 
@@ -54,9 +54,14 @@ Read approved product, final architecture, and experience baselines; exact `ui-h
 - `slice-experience-change-traceability.csv` showing which added/modified/retired experience changes enter each slice;
 - replanning rules and current plan baseline.
 - a draft `scope-manifest.yaml` whose approved contents are frozen through `scope freeze`; later `scope amend` revisions are append-only and budget `scope warn` records never mutate it.
+- handbook/index readiness receipt recording the consulted `source_commit`, path/command/test validation, maintainer owner, and whether affected documentation needs an approved update.
 
 Do not output component-level technical tasks. The development orchestrator derives those just in time from a selected slice and the latest architecture.
 
+## Confirmation Boundary
+
+Read the current confirmation summary before proposing scope. Agent-verifiable facts require evidence; only product-owner scope choices and risk acceptance become user questions. Append each answer, recompute the frontier, and keep unresolved business decisions out of `scope freeze`.
+
 Read [planning-contract.md](references/planning-contract.md) and use `assets/planning-template/` for a new iteration.
 
 ## Handoff

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

@@ -23,7 +23,7 @@ This Skill contributes a parallel task stream inside `03-delivery-readiness`; it
 
 ## Preflight
 
-Read initial and final architecture as available, deployment topology, stack manifest, quality targets, security standards, current environment baselines, and iteration scope. Treat cloud, paid-service, privacy, and hard-to-reverse infrastructure changes as major architecture decisions.
+Read initial and final architecture as available, deployment topology, stack manifest, quality targets, security standards, current environment baselines, iteration scope, and the current confirmation summary. Treat cloud, paid-service, privacy, and hard-to-reverse infrastructure changes as major architecture decisions. Agent-investigated platform facts require evidence; user choices about cost, risk, privacy, or irreversible infrastructure require a frontier confirmation and the architecture/approval artifact that owns the decision.
 
 ## Workflow
 

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

@@ -46,3 +46,5 @@ Read [release-contract.md](references/release-contract.md) and use `assets/relea
 ## Handoff
 
 Return exactly one immutable prepared release package to `$ai-delivery-orchestrate-release`. Human production approval occurs independently at `R07-production-approval`.
+
+Read the closeout confirmation summary and require an explicit, current release intent. Version completion or candidate pass never authorizes publication or external side effects.

package/skills/ai-delivery-prepare-release/assets/release-template/release-manifest.yaml

@@ -11,8 +11,6 @@ release_branch: ""
 release_candidate_commit: ""
 release_candidate_tag: ""
 candidate_receipt_ref: ""
-commit_sha: "" # Alias of release_candidate_commit for existing consumers.
-tag: "" # Alias of release_candidate_tag for existing consumers.
 package_hash: ""
 artifact_digests: []
 configuration_baseline: ""

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

@@ -23,7 +23,7 @@ Use `04-implementation` for pre-merge package review phases. Use `05-candidate-a
 
 ## Preflight
 
-Read the work package, diff, approved source artifacts, standards versions, architecture constraints, TDD evidence, test results, allowed modification scope, exact UI handoff and `product-prototype-reconciliation.yaml` checksums, Prototype revision and UI Mapping checksums, task-to-experience-change actions, and terminal/Page/Review Scene/prototype-element/UI component/frontend-source/acceptance mappings for UI-bearing work. Reject missing or conflicting references and never infer relationships from file names or row order. Re-run relevant checks when evidence is absent or stale.
+Read the work package, diff, approved source artifacts, standards versions, architecture constraints, TDD evidence, test results, allowed modification scope, codebase handbook/index read receipt, exact UI handoff and `product-prototype-reconciliation.yaml` checksums, Prototype revision and UI Mapping checksums, task-to-experience-change actions, and terminal/Page/Review Scene/prototype-element/UI component/frontend-source/acceptance mappings for UI-bearing work. Reject missing or conflicting references and never infer relationships from file names or row order. Re-run relevant checks when evidence is absent or stale. Confirm structural changes have a matching index update or an explicit, justified no-change assessment.
 
 ## Two-Phase Review Protocol
 
@@ -48,3 +48,5 @@ Report findings first, ordered by severity, with tight file and line references.
 Do not use `pass` when required checks did not run. Do not repair findings yourself; return the approved change set to the work-package executor and wait for concentrated rereview evidence.
 
 Read [review-contract.md](references/review-contract.md).
+
+Review findings and confirmation records are separate evidence. If a finding requires user acceptance, an exception, or a product/architecture decision, append a proposed record and stop at its owning node; chat cannot close a Gate or expand allowed scope.