@adamancyzhang/claude-orchestrator 0.3.0 → 0.3.1

package/dist/skills/task-planning/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: task-planning
+description: Requirement analysis and task breakdown for the Planner role. Use when the Planner needs to analyze requirements, define task blueprints, break down work into executable tasks with acceptance criteria, establish responsibility chain ordering, and push tasks to the orchestrator queue — all with full traceability from requirements to tasks. Triggers on keywords like "分析需求", "拆解任务", "制定计划", "task planning", "blueprint", "break down", "define tasks", "规划", or when starting a new work cycle that needs tasks created.
+---
+
+# Task Planning
+
+> 规划不是猜测，是分析需求 → 定义蓝图 → 拆解可执行任务 → 建立可验证的验收标准。本技能与 [[task-traceability]] 协作，确保每次规划产出清晰、可执行、可追溯——每个任务都可追溯到具体需求。
+
+---
+
+## 何时触发
+
+- Leader 分配新的需求/目标给 Planner
+- 用户说"分析一下这个需求"、"拆解任务"、"制定执行计划"
+- 新的工作周期开始，需要产出任务列表
+- 现有蓝图需要修订或补充
+
+---
+
+## 规划六步法
+
+按顺序执行，每一步通过才进入下一步。任一步产出不清晰 → 回退澄清。
+
+### 1. 读取需求上下文
+
+定位并理解需求来源：
+
+- 如果是 Leader 通过 orchestrator 分配的需求，通过 `claude-orchestrator get-context --key <需求key>` 获取
+- 如果是本地文档（如 `docs/pm/YYYY-MM-DD/`），读取完整内容
+- 如果是代码库需求（如 Issue、PR 描述），读取相关文档和代码
+
+提取关键信息：
+- 业务目标和背景
+- 约束条件和边界
+- 期望的交付标准和截止时间
+
+### 2. 定义任务蓝图
+
+输出蓝图文档，包含以下要素：
+
+```markdown
+# 任务蓝图：[目标名称]
+
+> Planner | YYYY-MM-DD | 版本 v1
+
+## 目标
+
+（一句话描述要达成什么）
+
+## 背景
+
+（为什么需要做这个，解决什么问题）
+
+## 范围与非范围
+
+**范围内：**
+- 具体要做的事项 1
+- 具体要做的事项 2
+
+**不在范围内：**
+- 明确不做的事项 1
+
+## 约束条件
+
+- 技术约束（如必须兼容 Node.js 18+）
+- 时间约束
+- 依赖约束（如依赖外部服务 X 先就绪）
+
+## 成功定义
+
+（可验证的成功标准，不是抽象描述）
+- 标准 1：所有单元测试通过，覆盖率 ≥ X%
+- 标准 2：UI 交互流程可在浏览器中完成
+- ...
+```
+
+### 3. 拆解可执行任务
+
+将蓝图拆解为独立的任务项。每个任务必须满足：
+
+- **可独立执行**：Builder 无需频繁跨任务上下文切换
+- **可验证**：有明确的验收标准（测试命令、UI 检查点、文件路径等）
+- **有产出物**：代码变更、测试报告、截图、文档等
+
+```markdown
+## 任务清单
+
+| # | 任务 | 类型 | 验收标准 | 预估 | 依赖 |
+|---|------|------|---------|------|------|
+| 1 | 实现 XXX 模块 | build | `npm test -- XXX` 全部通过 | 2h | - |
+| 2 | 编写 YYY 集成测试 | build | `npm test -- YYY` 覆盖 3 个场景 | 1h | #1 |
+| 3 | 验证 ZZZ 边界情况 | verify | 运行边界测试套件，0 失败 | 0.5h | #2 |
+| 4 | 审查整体方案一致性 | review | 审查报告无 P0/P1 问题 | 0.5h | #2, #3 |
+| 5 | 验收最终交付物 | accept | 对照验收标准逐项通过 | 0.5h | #4 |
+```
+
+任务类型对应责任链环节：`plan` / `build` / `verify` / `review` / `accept`。
+
+依赖字段确保责任链顺序：P → B → V → R → A。
+
+### 4. 推入任务队列
+
+通过 orchestrator 将任务推入队列，指定每个任务的责任链环节：
+
+```bash
+# Build 任务
+claude-orchestrator push-task \
+  --title "实现 XXX 模块" \
+  --link build \
+  --priority 0
+
+# Verify 任务
+claude-orchestrator push-task \
+  --title "验证 ZZZ 边界情况" \
+  --link verify \
+  --priority 1
+
+# Review 任务
+claude-orchestrator push-task \
+  --title "审查整体方案一致性" \
+  --link review \
+  --priority 1
+
+# Accept 任务
+claude-orchestrator push-task \
+  --title "验收最终交付物" \
+  --link accept \
+  --priority 1
+```
+
+优先级建议：`plan` 和下游瓶颈任务用 `0`（HIGH），其余用 `1`（MEDIUM）。
+
+### 5. 建立验收标准可追溯
+
+每个任务的验收标准必须具体到可独立复现。拒绝模糊描述：
+
+| 模糊（拒绝） | 具体（通过） |
+|-------------|------------|
+| "功能正常" | `npm test -- auth` 全部通过，覆盖登录/登出/超时 3 个场景 |
+| "UI 没问题" | 截图 `screenshots/login-flow.png` 展示登录→首页完整流程 |
+| "性能合格" | `ab -n 1000 -c 10 /api/users` p95 < 200ms |
+| "代码质量好" | `npx eslint src/auth/` 0 errors, 0 warnings |
+
+### 6. 记录蓝图并通知 Leader
+
+将蓝图文档存入共享上下文，通知 Leader 蓝图就绪：
+
+```bash
+# 存为共享上下文
+claude-orchestrator set-context --key plan-<目标slug> --value "$(cat docs/plans/<目标slug>.md)"
+
+# 通知 Leader
+claude-orchestrator send-message --broadcast --content "蓝图 <目标slug> 已就绪，任务已推入队列，共 N 个任务。"
+```
+
+---
+
+## 蓝图完整性检查清单
+
+```
+□ 目标描述一句话清晰
+□ 范围和边界明确（不做的比要做的更重要）
+□ 每项任务可独立执行
+□ 每项任务有具体验收标准（不是模糊描述）
+□ 依赖链完整（P→B→V→R→A 无断点）
+□ 所有任务已推入 orchestrator 队列
+□ 蓝图文档已存入共享上下文
+□ Leader 已收到蓝图就绪通知
+```
+
+---
+
+## 与其他技能的协作
+
+- **[[task-traceability]]**：基础层。Planner 的每一步都需要可追溯：需求 → 蓝图 → 任务清单 → 验收标准。Plan 是责任链的起点，如果 Plan 的追溯链断裂，Builder 不知道做什么，Verifier 不知道验什么，Reviewer 不知道审什么。
+- **[[task-execution]]**：Builder 依赖 Planner 的蓝图和追溯链来理解执行范围。
+- **[[task-verification]]**：Verifier 以 Planner 蓝图的验收标准为验证基准。
+- **[[task-review]]**：Reviewer 以 Planner 蓝图为审查标准。
+
+---
+
+## 常见错误
+
+- **任务拆得太粗**：一个任务包含多个独立模块，Builder 无法一次完成。拆到一个人能在 2-4 小时内完成为宜。
+- **验收标准是废话**：写"功能正常"等于没写。必须写具体的测试命令、文件路径、预期输出。
+- **跳过依赖声明**：没有依赖链，责任链流转就断了。每个非 Plan 任务必须声明它依赖什么产出物。
+- **蓝图没有存共享上下文**：其他 Worker 看不到蓝图就无法理解自己在做什么。蓝图必须是团队可见的。

package/dist/skills/task-review/SKILL.md

@@ -0,0 +1,220 @@
+---
+name: task-review
+description: Quality review of the full Plan→Build→Verify chain for the Reviewer role. Use when the Reviewer needs to assess whether the implementation matches the Planner's design intent — checking code quality, architecture compliance, verification completeness, and producing a review report with a pass/revise decision, with full traceability from every judgment back through the chain. Triggers on keywords like "审查", "review", "code review", "检查代码", "审批", "复核", or when verification is complete and the task enters the Review stage of the responsibility chain.
+---
+
+# Task Review
+
+> 审查不是挑刺，是从设计意图的高度判断实现是否"做对了"——不是"代码写得怎么样"，而是"该不该通过"。本技能与 [[task-traceability]] 协作，确保每次审查有依据、有深度、有结论、可追溯——每个判定都可追溯到具体的 Plan 意图、Build 产出和 Verify 发现。
+
+---
+
+## 何时触发
+
+- Verifier 完成验证，责任链流转到 Review 阶段
+- Worker 通过 `claude-orchestrator claim-task` 认领了 review 类型的任务
+- 用户说"审查一下这个 PR"、"review 一下代码"
+- 蓝图中有 review 类型的任务需要开工
+
+---
+
+## 审查六步法
+
+按顺序执行，每一步通过才进入下一步。
+
+### 1. 认领 Review 任务并收集全链信息
+
+```bash
+# 认领审查任务
+claude-orchestrator claim-task
+
+# 获取蓝图
+claude-orchestrator get-context --key plan-<目标slug>
+
+# 获取验证报告
+claude-orchestrator get-context --key verify-<目标slug>
+```
+
+收集审查所需的完整上下文：
+- Planner 的蓝图（设计意图、验收标准、范围边界）
+- Builder 的代码变更（commit diff）
+- Verifier 的验证报告（问题清单、回归结果）
+- Builder 的 task-traceability 记录（commit hash 链）
+
+如果缺少任何一环的产出 → 退回要求补齐。Reviewer 不做信息不完整的审查。
+
+### 2. 审查设计一致性
+
+对照蓝图检查实际实现，回答三个核心问题：
+
+**做对了吗？**（功能正确性）
+- 代码变更是否实现了蓝图定义的全部功能？
+- 是否有蓝图定义但未实现的部分？
+- 是否有蓝图未定义但被实现了的部分（越界）？
+
+**做合适吗？**（架构合规性）
+- 代码结构是否符合项目现有的架构模式？
+- 是否引入了新的依赖或模式变更？（如有，是否必要且有充分理由？）
+- 命名、目录组织、接口设计与项目现有风格是否一致？
+
+**技术债务可控吗？**
+- 是否有明显的性能问题、安全问题、可维护性问题？
+- 是否引入了难以测试的逻辑？
+- 错误处理是否合理？
+
+```bash
+# 查看完整 diff
+git show <commit-hash> --patch
+
+# 查看变更的文件列表
+git show <commit-hash> --stat
+```
+
+### 3. 审查验证报告的完整性
+
+审查 Verifier 的工作质量：
+
+- 验证报告是否覆盖了蓝图中所有验收标准？
+- 验证方法是否独立可复现？（不是转述 Builder 的结果）
+- 回归测试是否被执行且通过？
+- Verifier 发现的问题是否被充分描述和分类？
+
+如果验证报告有缺陷（漏检、方法不当）→ 标记为 Review 前置条件不满足，退回 Verifier 补充。
+
+### 4. 判定问题等级
+
+对发现的问题按严重度分级：
+
+| 级别 | 定义 | 示例 | 处理 |
+|------|------|------|------|
+| **P0** | 阻断：设计意图未实现，核心功能缺失或不正确 | 蓝图要求的功能完全没做、引入安全漏洞 | 退回 Builder 重做 |
+| **P1** | 严重：实现偏离设计意图，但不影响核心功能 | 错误处理不完整、UI 与设计不一致、性能明显下降 | 退回 Builder 修改 |
+| **P2** | 一般：代码质量、风格、可维护性问题 | 命名不清晰、缺少注释、测试覆盖面不足 | 建议修改，不阻断通过 |
+| **P3** | 建议：优化建议，不影响通过 | 更好的实现方式、可选的性能优化 | 记录，Builder 自行决定 |
+
+### 5. 书写审查报告
+
+```markdown
+# 审查报告
+
+> Reviewer | YYYY-MM-DD | 审查范围：<目标名称> (P→B→V 全链)
+
+## 审查结论：Pass / Revise
+
+（一句话结论）
+
+---
+
+## 审查范围
+
+| 环节 | 负责人 | 产出 | Commit / 文档 |
+|------|--------|------|--------------|
+| Plan | <Planner> | 蓝图 | plan-<slug> |
+| Build | <Builder> | 代码 | `a1b2c3d` |
+| Verify | <Verifier> | 验证报告 | verify-<slug> |
+
+---
+
+## 设计一致性审查
+
+| 蓝图要求 | 实现情况 | 判定 |
+|---------|---------|------|
+| 功能 A：XXX | 已实现，见 `src/a.ts:42` | ✅ |
+| 功能 B：YYY | 部分实现，缺少边界处理 | ⚠️ |
+| 功能 C：ZZZ | 未实现 | ❌ |
+
+---
+
+## 代码质量审查
+
+| 检查项 | 结果 |
+|--------|------|
+| 架构合规 | ✅ / ⚠️ / ❌ |
+| 命名规范 | ✅ / ⚠️ / ❌ |
+| 错误处理 | ✅ / ⚠️ / ❌ |
+| 性能影响 | ✅ / ⚠️ / ❌ |
+| 安全问题 | ✅ / ⚠️ / ❌ |
+
+---
+
+## 验证报告审查
+
+| 检查项 | 结果 |
+|--------|------|
+| 验收标准覆盖 | 3/3 ✅ |
+| 验证方法独立 | ✅ |
+| 回归测试通过 | ✅ (42/42) |
+| Verifier 问题充分描述 | ✅ |
+
+---
+
+## 问题清单
+
+| # | 级别 | 描述 | 位置 | 责任人 |
+|---|------|------|------|--------|
+| 1 | P1 | 缺少错误重试逻辑 | `src/auth.ts:L42` | @Builder |
+| 2 | P2 | 变量名 `tmp` 不够清晰 | `src/utils.ts:L18` | @Builder |
+
+---
+
+## 审查建议
+
+（对 Builder/Planner/Verifier 的非强制性建议）
+
+---
+
+*Reviewer — YYYY-MM-DD*
+```
+
+### 6. 通知结果并流转
+
+```bash
+# 存入共享上下文
+claude-orchestrator set-context \
+  --key review-<目标slug> \
+  --value "$(cat docs/review/<目标slug>-YYYY-MM-DD.md)"
+
+# Revise → 通知 Builder 和 Planner
+claude-orchestrator send-message \
+  --to <builder-id> \
+  --content "审查结论 Revise。P1: 缺少错误重试逻辑。详见 review-<slug>"
+
+# Pass → 通知 Leader 和 Accepter，流转到 Accept 阶段
+claude-orchestrator send-message \
+  --broadcast \
+  --content "审查结论 Pass。<目标> 通过 Review，流转至 Accept 阶段。"
+```
+
+---
+
+## 审查完成检查清单
+
+```
+□ 已收集完整的 P→B→V 链产出
+□ 蓝图验收标准全部检查
+□ 代码 diff 完整审阅
+□ 验证报告质量和完整性已评估
+□ 问题已按 P0/P1/P2/P3 分级
+□ 审查报告已产出并存入共享上下文
+□ 结论（Pass/Revise）已通知相关角色
+```
+
+---
+
+## 与其他技能的协作
+
+- **[[task-traceability]]**：基础层。Reviewer 严格遵循追溯 → 执行 → 映射 → 举证 → 记录的五步法。追溯整条链（Plan 意图 → Build 实现 → Verify 发现），逐项判定（Execute），构建审查判定映射表（Map），为每个判定附理据（Evidence），产出审查报告并签发 Pass/Revise（Record）。如果任何一个上游环节的追溯链断裂，标记为 P1 问题——没有追溯链，审查就没有锚点。
+- **[[task-planning]]**：Reviewer 以 Planner 的蓝图为审查标准。设计意图是唯一的判断基准。
+- **[[task-execution]]**：Reviewer 审查 Builder 的代码实现质量和设计一致性。
+- **[[task-verification]]**：Reviewer 审查 Verifier 的验证报告质量和完整性。验证报告有缺陷的，退回 Verifier。
+- **[[task-acceptance]]**：Accepter 依赖 Reviewer 的 Pass 结论和可追溯判定链来决定是否进入最终验收。
+
+---
+
+## 常见错误
+
+- **只审代码不审设计一致性**：陷入代码风格审查，忘记了 Reviewer 的核心职责是判断"是否实现了设计意图"。代码写得再好，与蓝图不一致也是不合格。
+- **跳过对 Verifier 的审查**：假设 Verifier 的报告总是完整正确的。Verifier 也可能遗漏或误判。
+- **不分级的问题清单**：把所有问题列出但不定级，Builder 不知道哪些必须修改、哪些可以忽略。
+- **审查报告不写位置**：问题只描述不定位（缺少文件路径和行号）。Builder 不知道在哪里改。
+- **Pass 但有问题未解决**：P0/P1 问题未解决就签 Pass。零 P0/P1 是 Pass 的前提。

package/dist/skills/task-traceability/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: task-traceability
+description: Foundational traceability layer for the entire Plan→Build→Verify→Review→Accept responsibility chain. Every role must leave a traceable record: upstream requirements → execution → output mapping → evidence → persisted record. Without traceability at every link, the chain cannot be audited, handoffs break, and sign-off is unreliable. Use this skill whenever any team member executes work in any link of the responsibility chain — planning, building, verifying, reviewing, or accepting. Triggers on any task execution context: task assignment, work plans, code changes, verification, review, or acceptance.
+---
+
+# Task Traceability — Foundational Layer
+
+Traceability is not optional. It is the foundation that makes the Plan→Build→Verify→Review→Accept chain auditable, handoffs reliable, and sign-off meaningful. **Every link must produce a traceable record. A single broken link breaks the entire chain.**
+
+## The Universal Five-Step Pattern
+
+Every role in the chain follows the same five-step pattern, applied to its specific context:
+
+```
+Step 1: Trace (追溯)
+  └── Identify all upstream requirements and artifacts you must reference
+
+Step 2: Execute (执行)
+  └── Do the work, following the traced requirements
+
+Step 3: Map (映射)
+  └── Link every output back to a specific upstream requirement
+
+Step 4: Evidence (举证)
+  └── Provide proof that each mapping is correct and complete
+
+Step 5: Record (记录)
+  └── Persist the traceability record so downstream roles can pick up the chain
+```
+
+**Why five steps?** Without Trace, you don't know what to do. Without Map, nobody knows why you did it. Without Evidence, your output is unverifiable. Without Record, the next link starts blind.
+
+## Why Every Link Matters
+
+```
+Plan ──→ Build ──→ Verify ──→ Review ──→ Accept
+  │         │         │          │           │
+  │         │         │          │           └── Break here → sign-off is unverifiable
+  │         │         │          └── Break here → audit trail is incomplete
+  │         │         └── Break here → verification is untrustworthy
+  │         └── Break here → implementation is untraceable
+  └── Break here → entire chain starts without a foundation
+```
+
+A chain is only as strong as its weakest link. Traceability must be enforced at **every** link.
+
+## Role-Specific Application
+
+### Plan — Blueprint Traceability
+
+Plan is the chain's foundation. If blueprint traceability is broken, every downstream link is working from ambiguity.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the original requirement. Extract business goals, constraints, scope boundaries, and success criteria. |
+| **Execute** | Design the blueprint: architecture, interfaces, data flow. Break into ordered Build steps, each with completion criteria. |
+| **Map** | Every Build step must trace back to a specific requirement. Every completion criterion must be objectively verifiable. |
+| **Evidence** | Self-check: can a Builder start from this blueprint alone? Are edge cases covered? Are interfaces unambiguous? |
+| **Record** | Write the blueprint document. Push tasks to the orchestrator queue. Store the blueprint in shared context (`set-context`). Notify Leader. |
+
+**Plan traceability record**: `requirement → blueprint → task list → shared context key`
+
+### Build — Implementation Traceability
+
+Build produces the concrete artifacts. Every code change must be traceable to a specific Plan requirement.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the Planner's blueprint. Extract every implementable requirement as a checklist. |
+| **Execute** | Implement each requirement. Follow the Plan's architecture and interfaces. Document any deviations. |
+| **Map** | Build a traceability map: `Plan Requirement → Implementation → Status (done/deviated/blocked)`. |
+| **Evidence** | Provide proof: tests passing, manual verification results, key implementation decisions and rationale. |
+| **Record** | Commit code signed with your own name. Record the commit hash next to each completed item in the task document. Commit the document update. |
+
+**Build traceability record**: `blueprint requirement → code change → commit hash → document update → document commit`
+
+### Verify — Verification Traceability
+
+Verify independently checks Builder output. Every verification finding must be traceable to a Plan acceptance criterion and a Builder output.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the Plan blueprint (acceptance criteria) and Builder output (commits, artifacts). Build a verification checklist by cross-referencing. |
+| **Execute** | For each checklist item, independently verify. Run tests. Inspect code. Check edge cases and regressions. |
+| **Map** | Build a verification map: `Plan Criterion → Builder Output → Verified Result → Status (pass/gap/fail)`. |
+| **Evidence** | For each finding, record: what was checked, how, actual command output, and references to Plan and Builder artifacts. |
+| **Record** | Write the verification report. Store in shared context. Flag gaps and failures to Builder and Reviewer. |
+
+**Verify traceability record**: `acceptance criterion → verification method → actual result → verdict → report path`
+
+### Review — Judgment Traceability
+
+Review judges the full chain. Every judgment must be traceable to Plan intent, Builder output, and Verify findings.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read all upstream artifacts: Plan blueprint, Builder traceability map, Verify report. Build a chain-level review checklist. |
+| **Execute** | For each item, make a judgment: ACCEPT / CONCERN / REJECT. Classify issues as P0 (blocking) / P1 (severe) / P2 (minor) / P3 (suggestion). |
+| **Map** | Build a review map: `Plan Intent → Build Result → Verify Finding → Review Judgment`. |
+| **Evidence** | For each CONCERN and REJECT: reference the specific Plan requirement, Builder output, Verify finding, and clear rationale. |
+| **Record** | Write the review report. Store in shared context. Issue Pass/Revise decision. Notify responsible roles. |
+
+**Review traceability record**: `plan intent → build result → verify finding → review judgment → report path → decision`
+
+### Accept — Sign-Off Traceability
+
+Accept is the final gate. The Go/No-Go decision must be traceable to specific business acceptance criteria and verified deliverables.
+
+| Step | Action |
+|------|--------|
+| **Trace** | Read the full chain: Plan blueprint, Builder output, Verify report, Review judgment. Extract business acceptance criteria. |
+| **Execute** | For each acceptance criterion, verify: is there a corresponding deliverable? Does it actually exist? Are upstream issues resolved? |
+| **Map** | Build an acceptance map: `Acceptance Criterion → Deliverable → Verification Result → Review Judgment → Status`. |
+| **Evidence** | For each criterion: verify code exists (grep), verify commits exist (git log), verify tests pass (run them), verify reports are self-consistent. |
+| **Record** | Write the acceptance report. Sign Go/No-Go. Zero issues for Go — no conditional passes. Store in shared context. |
+
+**Accept traceability record**: `acceptance criterion → deliverable → verification → review → Go/No-Go → report path`
+
+## The Traceability Record Chain
+
+When every link records its traceability, the full chain is auditable from end to end:
+
+```
+Business Requirement
+  └── Plan: blueprint → task-001(task-0000000001), task-002(task-0000000002)
+        └── Build: task-001 → commit a1b2c3d → doc update commit e4f5g6h
+              └── Verify: criterion A → test X passed, criterion B → gap found
+                    └── Review: gap B → CONCERN P1 → Revise decision
+                          └── Re-Build: fix gap B → commit i7j8k9l
+                                └── Re-Verify: criterion B → test Y passed
+                                      └── Re-Review: all clear → Pass
+                                            └── Accept: all criteria met → GO
+```
+
+Anyone can enter the chain at any point and traverse forward or backward. A reviewer can ask "what requirement led to this commit?" and get the answer in one step. An auditor can ask "was this acceptance criterion verified?" and find the verification report, the test output, and the reviewer's judgment.
+
+## Task Completion Checklist (All Roles)
+
+```
+□ Step 1 — Trace: Identified all upstream requirements and artifacts
+□ Step 2 — Execute: Completed work following traced requirements
+□ Step 3 — Map: Every output linked to a specific upstream requirement
+□ Step 4 — Evidence: Proof provided for each mapping
+□ Step 5 — Record: Traceability record persisted (commit, context store, or report)
+```
+
+## Common Mistakes (All Roles)
+
+- **Skipping Trace (Step 1)**: Starting work without reading upstream artifacts. Produces output that may not align with requirements.
+- **Skipping Map (Step 3)**: Producing output without linking it back to requirements. Downstream roles can't tell what was done for what.
+- **Map without Evidence (Step 4)**: Claiming "done" without proof. Unverifiable claims are invisible to auditors.
+- **Skipping Record (Step 5)**: Doing the work but not persisting the traceability record. The next link starts blind — the chain is broken.
+- **Weak evidence**: "Looks good" is not evidence. Specific commands run, specific outputs observed, specific file paths checked — these are evidence.
+- **Signing with someone else's name**: Traceability depends on knowing who did what. Every commit and report must identify its author.