ai-delivery-workflow 0.4.0 → 0.5.1

package/skills/ai-delivery-manage-standards/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "Manage Standards"
-  short_description: "Capture, approve, version, and resolve applicable standards"
-  default_prompt: "Use $ai-delivery-manage-standards to capture or resolve project standards."
+interface:
+  display_name: "Manage Standards"
+  short_description: "Capture, approve, version, and resolve applicable standards"
+  default_prompt: "Use $ai-delivery-manage-standards to capture or resolve project standards."

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

@@ -41,17 +41,15 @@ Require every workflow document to be written under project `.workflow/`. Use `.
 
 ## Formal State
 
-The installed producer route is `development-seven-node`: `00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`. Producer Skills and installed guidance use only these development node IDs. `development-legacy-13` is read-only compatibility: inspect, verify, rebuild, and explicit migration may consume historical state, while every new legacy task, artifact, transition, candidate, closeout, or Gate write is rejected. Release nodes `R00-release-request` through `R10-release-archive` remain writable.
-
-When Bootstrap reports legacy compatibility or a premature archive, use the packaged top-level CLI before normal orchestration. Run `ai-delivery migrate <project> --dry-run` and require a reviewed report with schemas, semantic task groups, ambiguities, conflicts, verified anchors, and exact file changes. A legacy root migration copies workflow material into `.workflow/`; flat task shards gain explicit attempts without changing their lifecycle status or scope. Resolve every ambiguity through a source-checksum-bound `--decisions` document with a `human:` actor and rationale, then rerun dry-run. Apply migration only when `can_apply` is true; its manifest and backups must preserve source bytes, task lifecycle facts, scope, formal views, and legacy event bytes. Resolve an incorrect archive only through `ai-delivery repair <project> --invalidate-archive <iteration-id>` with an explicit human actor, reason, RCA evidence, and recovery evidence. The resulting forward transaction invalidates current eligibility while the original archive remains byte-identical. Use rollback only before any post-migration schema 2 transaction or migrated-byte drift; afterward use forward repair. Compaction is never part of migration: run `ai-delivery compact <project> --dry-run` only after a trusted anchor exists, review its exact coverage and byte report, and apply only on explicit operator intent.
+The installed producer route is `development-seven-node`: `00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`. Release nodes `R00-release-request` through `R10-release-archive` remain writable. New work, state, artifacts, transitions, candidates, closeouts, and Gates use only these current node IDs.
 
 1. Use `node .workflow/tools/state/state.mjs inspect` to read schema 2 formal state: independent `development_state` and `release_state` scopes, the top-level workflow audit revision, and the artifact-registry revision.
-2. Keep `draft` and `review-draft` files mutable and outside the formal registry. Register only immutable semantic revisions such as `submitted`, `rejected`, `approved`, `frozen`, or `failed`; every later decision uses a new artifact ID and `--supersedes`. `artifact status` exists only to migrate a legacy registered working draft once and must not mutate a formal revision.
+2. Keep `draft` and `review-draft` files mutable and outside the formal registry. Register only immutable semantic revisions such as `submitted`, `rejected`, `approved`, `frozen`, or `failed`; every later decision uses a new artifact ID and `--supersedes`.
 3. Start development with `iteration-started`; start release only after explicit user intent with `release-started`. Record node, candidate, closeout, and archive changes with `transition`. Record human or contract Gates with `gate request` and `gate decide`.
 4. At Delivery Readiness, run `scope freeze` to enable `scope_contract_version: 1` and bind approved Slices, requirements, acceptance, tasks, and artifacts. Afterward, only a human-approved `scope amend` may change scope. Use `scope warn` for a budget overrun; it must remain `warn-only` with `reslice_performed: false` and must not automatically replan or reslice.
-5. Read `inspect.derived_node_states` instead of assigning formal node status from narration. The projection uses task facts and blocking findings, Gates, artifacts, candidate identity, the current scope manifest, and completion receipts. A governed node may complete only from `ready-to-complete`; completion writes a receipt bound to those facts. Historical scopes without `scope_contract_version` retain legacy compatibility.
-6. Pass `artifact_registry.revision` through `--expected-revision` for artifact mutations. For scope, transition, and Gate mutations, pass the owning `development_state.revision` or `release_state.revision` through `--expected-scope-revision`; the top-level workflow revision form remains compatibility-only. A transition or Gate that consumes evidence records an artifact handoff in the same transaction and advances the artifact-registry revision, so inspect again before the next artifact mutation. On a conflict, inspect again and reconcile; never retry blindly.
-7. Run routine `verify` before handoff, node completion, and after recovery. It validates current formal views without traversing historical shards or decompressing archives. At ordinary task safe points, run `snapshot create --reason configured-interval`; the command is a no-op until the configured event interval is reached. Run `verify --history --since-anchor` after an anchor exists. `artifact compact` and `artifact prune` default to zero-write plans. Compact preserves original legacy shards in a checksummed gzip bundle and removes loose files only after full replay reproduces the anchored registry checksum; afterward `verify --history` reports `compacted-history`. Only explicit `artifact prune --apply` may replace covered shards with a retention receipt; afterward verification reports `retained-history` and does not claim deleted bytes were re-audited. Let the CLI enforce graph prerequisites, successful completion evidence, current-attempt mandatory Gates, and scope identity. Release nodes independently require routine verification at every release handoff. Stop on checksum, schema, audit, identity, or state-invariant failure.
+5. Read `inspect.derived_node_states` instead of assigning formal node status from narration. The projection uses task facts and blocking findings, Gates, artifacts, candidate identity, the current scope manifest, and completion receipts. A governed node may complete only from `ready-to-complete`; completion writes a receipt bound to those facts.
+6. Pass `artifact_registry.revision` through `--expected-revision` for artifact mutations. For scope, transition, and Gate mutations, pass the owning `development_state.revision` or `release_state.revision` through `--expected-scope-revision`. A transition or Gate that consumes evidence records an artifact handoff in the same transaction and advances the artifact-registry revision, so inspect again before the next artifact mutation. On a conflict, inspect again and reconcile; never retry blindly.
+7. Run routine `verify` before handoff, node completion, and after recovery. It validates current formal views and their recorded history. At ordinary task safe points, run `snapshot create --reason configured-interval`; the command is a no-op until the configured event interval is reached. Run `verify --history --since-anchor` after an anchor exists. `artifact prune` defaults to a zero-write plan; only explicit `artifact prune --apply` may replace covered shards with a retention receipt, after which verification reports `retained-history` and does not claim deleted bytes were re-audited. Let the CLI enforce graph prerequisites, successful completion evidence, current-attempt mandatory Gates, and scope identity. Release nodes independently require routine verification at every release handoff. Stop on checksum, schema, audit, identity, or state-invariant failure.
 8. Never directly edit controlled formal state, shared task/checkpoint shards, or runtime task state. Treat global workflow and artifact indexes as deterministic views over authoritative shards where available. If either state script fails, repair the input or script problem rather than bypassing it.
 9. When the user clearly expresses a workflow improvement, invoke `$ai-delivery-evolve-workflow feedback record` and report the feedback ID. Do not save ordinary discussion, full conversation text, secrets, or AI reasoning. Evaluate pending evidence only after a task, version closeout, or explicit evolution review.
 

package/skills/ai-delivery-orchestrate/agents/openai.yaml

@@ -1,4 +1,4 @@
-interface:
-  display_name: "AI Delivery Orchestrator"
-  short_description: "Coordinate AI delivery stages, gates, artifacts, and routing"
+interface:
+  display_name: "AI Delivery Orchestrator"
+  short_description: "Coordinate AI delivery stages, gates, artifacts, and routing"
   default_prompt: "Use $ai-delivery-orchestrate to start or continue the current workflow using the configured workflow and code repositories."

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` 的规范。
@@ -55,9 +54,11 @@
 14.1 任何正式前端修改必须先更新隔离 Prototype 并取得用户 Page approval，再冻结 checksummed `frontend-change-scope.yaml` 与 UI Mapping。首次写入每个 UI 路径前运行 `ai-delivery frontend-guard check-file <workspace> --path <path>`；合并、Candidate Assurance 和正式交接前从固定 refs 运行 `ai-delivery frontend-guard verify-diff <workspace> --base <base> --head <head>`，由 independent Git diff 复核。Hook 只做前置防误改，不能替代后者。文案、样式、响应式、无障碍、Page/route 增删和缺陷修复均无例外。
 14.2 UI-bearing candidate 必须在 `05-candidate-assurance` 内运行 `ai-delivery ui-acceptance plan` 和 `verify`，绑定 active attempt、immutable candidate、Prototype revision、Visual Standard、Page receipts、UI Mapping、Scenario Pack 与 pinned Playwright environment。UI Acceptance 不是新节点。Product Backend Mock 不得充当真实后端验收；candidate checksum 改变时返回 `04-implementation` 并创建新 attempt。
 15. 当前研发生产路线在 `06-version-closeout` 结束。登记 `release-ready` 收尾物料、完成节点并验证不可变身份后，必须通过正式状态 CLI 的 `version-closed` 事件更新累计研发版本，再归档任务上下文；不得直接编辑状态文件，也不得因为版本完成而自动发布。
-16. 后续计划版本必须从最新 `line/<product-id>` 开始；`main` 始终表示当前生产验证成功历史。
-17. 只有用户明确提出发布并选择截止版本时，才使用 `$ai-delivery-orchestrate-release`。系统必须计算从当前生产版本到目标版本的连续闭包。
-18. 同版本重新发布必须创建新 release ID，并重新执行环境快照、验证和生产审批。R09 只向 R10 交付已验证生产身份；R10 登记 `released` 归档物料并完成节点后，必须通过 `release-archived` 事件更新生产版本和 release ID。历史版本恢复通过旧镜像 digest，不创建 rollback 分支。
+16. `product-id` 是首次 bootstrap 时冻结的稳定产品研发线身份，不是仓库、版本或 release 名称。该产品首次开始计划版本时，从当时 `main` 创建一次 `line/<product-id>`；后续计划版本必须从最新 line 开始，不能在每次迭代或发布时重新从 `main` 拉线。`main` 始终表示当前生产验证成功历史。
+17. 只有用户明确提出发布并选择截止版本时，才使用 `$ai-delivery-orchestrate-release`。R00 必须同时记录当时受保护 `main` 的精确 `expected_main`，系统必须计算从当前生产版本到目标版本的连续闭包。增量发布要求该快照仍是 main 且为目标 `version-ready` Tag 的祖先；同版本重发要求目标 Tag 已经可由该快照到达。
+18. R04 只能通过包内 `.agents/skills/ai-delivery-manage-git/scripts/release-git.mjs create-candidate --release-id <id> --release-branch <branch> --expected-main <r00-sha> --source-tag <tag> --source-commit <tag-sha> --receipt <path> --apply` 从该快照创建 release 分支。增量发布以 `--no-ff` 合入一个目标 Tag，结果 `candidate_commit` 是唯一可验证、审批、部署和冻结 release Tag 的身份；同版本重发不新增合并，候选就是 `expected_main`。中间版本 Tag 仅用于闭包和物料追溯。main 漂移或候选不一致时必须标为 `stale`、保留证据并创建新 R00 请求，不得调整旧候选基线。
+18.1 同版本重新发布必须创建新 release ID，并重新执行环境快照、验证和生产审批。R09 先写入机器可读 `production-verification.json`（`schema_version: 1`、`operation: production-verification-decision`、精确 `release_id`、`decision: released`、R00 `expected_main_commit`、以及相等的 `verified_release_commit`/`deployed_commit`），再只向 R10 交付已验证生产身份；生产验证为 `released` 后，使用 `release-git.mjs promote --release-id <id> --release-branch <branch> --expected-main <r00-sha> --verified-release-commit <candidate-sha> --production-verification <R09-json> --receipt <path> --apply` 精确快进 main。R10 登记 `released` 归档物料并完成节点后，必须通过 `release-archived` 事件更新生产版本和 release ID。历史版本恢复通过旧镜像 digest，不创建 rollback 分支。
+18.2 `release-fix/<release-id>/<defect-id>` 只从活动候选创建。修复候选生产验证成功后、R10 归档前，冻结 schema 2 的产品线级 `candidate-inventory.json`：根部为 `scope: product-line`、`product_id`、`line_branch` 和 active candidate；每个候选保留自己的 `candidate_id`、`release_id`、commit 与 status，根部不得写 `release_id`。然后使用 `release-git.mjs sync-release-fix --release-id <id> --source-ref <branch> --source-commit <sha> --verified-release-commit <candidate-sha> --line-branch <line> --expected-line <line-sha> --production-verification <R09-json> --candidate-inventory <predecessor-R10-json> --successor-candidate-inventory <new-R10-json> --receipt <path> --apply` 受控同步到 `line/<product-id>`。successor 路径必须与前代库存和 receipt 不同，脚本只创建不可变 successor，不得改写输入库存；脚本从整个产品线库存派生 `stale_candidate_ids` 和带 `release_id` 的 `candidate_status_updates`，调用方不得传入 stale 列表。若已存在于 line，仍须登记 `status: idempotent` receipt 且只能复用字节完全一致的 successor。所有未包含已成功修复的可选候选均为 `stale`；旧 active 失效时 successor 把 active 指针推进到已验证候选。不得改写历史 version-ready Tag、版本 Manifest 或 release Tag。
 19. 不得绕过流程 Gate、修改已批准基线、推断缺失批准，或在恢复后自动重放生产动作。
 20. 版本任务归档的权威位置是 `.workflow/control/archives/versions/<version-id>/`。归档前必须由正式状态 CLI 的 `snapshot references` 在最新可信 anchor 中投影目标 scope manifest、candidate、Gate decision 与 history anchor；任何缺失都必须在写归档前失败，不得产生 nullable formal reference。`version-manifest.json` 以相对路径和 checksum 引用 task summary、attempt receipt（checksum 覆盖 ref 指向的完整 attempt 值）和这些正式记录，不重复内嵌正式记录。归档完成后不得把对应任务或 checkpoint 留在活动集合，普通恢复不得加载归档详情。
 21. 需要人工管理工作流、查看物料或审核原型时，在项目根目录运行 `.\.workflow\tools\manager\start.cmd`（Windows）或 `sh ./.workflow/tools/manager/start.sh`（macOS/Linux）。工作流管理器是唯一受支持的项目控制界面；所有写操作仍必须经过其治理动作、并发校验、Receipt 和不可变 Event。

package/skills/ai-delivery-orchestrate/assets/project-template/ref/ui/CONTRIBUTING.md

@@ -1,25 +1,25 @@
-# Contributing to Awesome Design MD
-
-Thanks for contributing.
-
-This repository is a curated collection of DESIGN.md files extracted from popular websites. Each file captures a site's complete visual language in a format any AI agent can read.
-
-## How to Contribute
-
-### Improve an Existing DESIGN.md
-
-If you notice issues with an existing file:
-
-1. **Open an issue first** to describe what you'd like to change and get feedback from maintainers
-2. Open the site's `DESIGN.md`
-3. Compare against the live site
-4. Fix incorrect hex values, missing tokens, or weak descriptions
-5. Update the `preview.html` and `preview-dark.html` if your changes affect displayed tokens
-6. Open a PR with before/after rationale
-
-
-We cannot accept DESIGN.md pull requests to maintain the quality of the existing collection.
-
-## License
-
-By contributing, you agree your contributions are provided under the repository license terms.
+# Contributing to Awesome Design MD
+
+Thanks for contributing.
+
+This repository is a curated collection of DESIGN.md files extracted from popular websites. Each file captures a site's complete visual language in a format any AI agent can read.
+
+## How to Contribute
+
+### Improve an Existing DESIGN.md
+
+If you notice issues with an existing file:
+
+1. **Open an issue first** to describe what you'd like to change and get feedback from maintainers
+2. Open the site's `DESIGN.md`
+3. Compare against the live site
+4. Fix incorrect hex values, missing tokens, or weak descriptions
+5. Update the `preview.html` and `preview-dark.html` if your changes affect displayed tokens
+6. Open a PR with before/after rationale
+
+
+We cannot accept DESIGN.md pull requests to maintain the quality of the existing collection.
+
+## License
+
+By contributing, you agree your contributions are provided under the repository license terms.