ai-delivery-workflow 0.4.0 → 0.5.0

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/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/AGENTS.md

@@ -55,9 +55,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.