@pigcloud/skills 1.0.5 → 1.0.7

package/skills/domain-modeling/references/distillation-checklist.md

@@ -1,152 +1,44 @@
-# 蒸馏质量验收检查清单
-
-> 用于验证蒸馏产物是否符合规范
-
----
-
-## 静态检查清单
-
-### 目录结构检查
-
-- [ ] `distilled/` 目录存在
-- [ ] `README.md` 存在且内容完整
-- [ ] `00-overview.md` 存在且包含"给 AI 的关键约定"
-- [ ] `01-glossary.md` 存在
-- [ ] `domain/_index.md` 存在
-- [ ] `domain/<对象>.md` 每个核心对象一个文件
-- [ ] `api/_index.md` 存在且包含典型编排
-- [ ] `api/<域>/<用例>.md` 每个用例一个文件
-- [ ] `reference/schema/*.md` 字段级 Schema
-- [ ] `reference/enums.md` 存在
-- [ ] `reference/error-codes.md` 存在
-- [ ] `reference/model-code-conflicts.md` 存在
-- [ ] `requirements/_index.md` 存在
-
----
-
-### 领域对象检查
-
-- [ ] 每个对象有"一句话定义"
-- [ ] 每个对象有"业务语义"段落
-- [ ] 每个对象有"生命周期/状态"段落
-- [ ] 每个对象有"关键属性"表（语义级）
-- [ ] 每个对象有"组合/关系"说明
-- [ ] 每个对象有"核心业务规则"段落
-- [ ] 每条规则有执行方标注（【服务端强制】/【调用方需预判】等）
-- [ ] 每个对象有"相关能力"链接
-- [ ] 每个对象有"明细索引"
-
----
-
-### API 接口检查
-
-- [ ] 每个接口有"业务场景"说明
-- [ ] 每个接口有"能力边界"说明（做什么/不做什么）
-- [ ] 每个接口有"输入"表（参数/类型/必填/说明/约束）
-- [ ] 每个接口有"输出"表（字段/说明）
-- [ ] 每个接口有"关键规则"段落
-- [ ] 每条规则有执行方标注
-- [ ] 每个接口有"涉及的数据对象"链接
-- [ ] 每个接口有"可能的错误"表
-- [ ] 每个接口有"调用示例"（真实可用）
-- [ ] 每个接口有"写权限分级"
-
----
-
-### 明细层检查
-
-- [ ] Schema 表有"对应领域属性/API字段"列
-- [ ] 枚举表有 ✅/⚠️ 标记
-- [ ] 错误码表有"AI 应如何向用户解释"列
-- [ ] 冲突清单有"本体/需求"、"代码"、"AI 影响"三列
-
----
-
-### 交叉引用检查
-
-- [ ] 所有链接使用 `[[slug]]` 格式
-- [ ] 对象↔接口↔Schema 三者互相链接
-- [ ] 无明显断链（链接目标不存在但未标记"待补")
-
----
-
-### 命名规范检查
-
-- [ ] 文件名使用小写 kebab-case
-- [ ] API 字段沿用代码实际返回的命名
-- [ ] 枚举值使用业务实际值（含中文）
-
----
-
-## 动态验证清单
-
-### 读/查询场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 名称→ID 解析 | AI 能正确调用主数据接口解析名称 | ✅/❌ |
-| 查询参数 | AI 能正确构造查询参数 | ✅/❌ |
-| 结果解读 | AI 能正确解读返回结果 | ✅/❌ |
-
-### 写/录入场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 必填字段 | AI 能识别必填字段并提示用户 | ✅/❌ |
-| 用例编排 | AI 能按正确顺序调用接口 | ✅/❌ |
-| 服务端维护字段 | AI 不传入服务端维护字段 | ✅/❌ |
-| 回显确认 | 写操作前回显给用户确认 | ✅/❌ |
-
-### 统计场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 口径理解 | AI 能正确理解统计接口口径 | ✅/❌ |
-| 参数构造 | AI 能正确构造统计参数 | ✅/❌ |
-
-### 规则反例场景
-
-| 测试 | 验证内容 | 结果 |
-|------|----------|------|
-| 规则预判 | AI 能预判违反规则的错误 | ✅/❌ |
-| 错误解释 | AI 能根据 error-codes.md 解释错误 | ✅/❌ |
-
----
-
-## 验证结论
-
-| 检查项 | 通过数 | 总数 | 通过率 |
-|--------|--------|------|--------|
-| 目录结构 | | 13 | |
-| 领域对象 | | 9 | |
-| API 接口 | | 10 | |
-| 明细层 | | 4 | |
-| 交叉引用 | | 3 | |
-| 命名规范 | | 3 | |
-| 动态验证 | | 12 | |
-
-**总通过率要求**: >= 90%
-
----
-
-## 验证记录
-
-| 日期 | 验证人 | 通过率 | 备注 |
-|------|--------|--------|------|
-| | | | |
-
----
-
-## 发现的问题
-
-1. 
-2. 
-3. 
-
----
-
-## 修复计划
-
-| 问题 | 修复方案 | 状态 |
-|------|----------|------|
-| | | 待修复/已修复 |
+# 领域提炼检查清单
+
+> 用于检查领域建模提炼结果是否满足规范、是否可交接、是否可复用。
+
+---
+
+## 目录结构
+
+- [ ] `distilled/` 目录已创建
+- [ ] `README.md` 已说明提炼目标
+- [ ] `00-overview.md` 已说明 AI 的关键约束
+- [ ] `01-glossary.md` 已收录术语
+- [ ] `domain/_index.md` 已建立索引
+- [ ] `domain/<name>.md` 每个核心域有独立文件
+- [ ] `api/_index.md` 已建立接口索引
+- [ ] `api/<group>/<name>.md` 每个接口组都有独立文件
+- [ ] `reference/schema/*.md` 字段级 Schema 已整理
+- [ ] `reference/enums.md` 枚举已整理
+
+## 内容检查
+
+- [ ] 领域边界已明确
+- [ ] 核心概念已抽取
+- [ ] 术语表与代码命名一致
+- [ ] 当前事实与推断已区分
+- [ ] 关键不变量已记录
+
+## 证据检查
+
+- [ ] 每个结论都有代码、文档或会议纪要支撑
+- [ ] 关键例子可追溯到原始来源
+- [ ] 没有把猜测写成事实
+
+## 交接检查
+
+- [ ] 输出可以交给 `spec-refinement`
+- [ ] 输出可以交给 `technical-design`
+- [ ] 输出可以交给 `knowledge-capture`
+- [ ] 文件命名遵守 kebab-case
+
+## 备注
+
+- 如果某个目录暂时没有内容，也要在索引里明确说明。
+- 如果有未确认项，单独列在“待确认”区域，不要隐藏。

package/skills/feature-build/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: feature-build
-description: 在代码、重构或集成工作需要保持在既定边界内时，实现已批准的设计变更
-lifecycle_stage: build
+description: 在代码、重构或集成工作需要保持在既定边界内时，实现已批准的设计变更
 rule_profile: implementation
 dependencies:
   - technical-design
@@ -14,7 +13,7 @@ triggers:
   - service
   - mapper
 inputs:
-  - executable spec
+  - executable spec-refinement
   - design decisions
   - confirmed task breakdown plan
   - rules bundle
@@ -33,7 +32,7 @@ workflow:
   - hand off to test-design
 gates:
   - stop at implementation
-  - do not rewrite the spec
+  - do not rewrite the spec-refinement
   - do not change the agreed boundaries
   - do not bypass the rules bundle
 refs:
@@ -59,7 +58,7 @@ Implement the approved design without changing the agreed scope.
 
 - Load the selected rules bundle first.
 - Implement only the confirmed scope from the approved design.
-- Split work into small tasks before implementation if the spec is still too coarse.
+- Split work into small tasks before implementation if the spec-refinement is still too coarse.
 - Treat the task as the smallest implementation unit.
 - Validate each task locally before starting the next one.
 - Record evidence immediately after each task is complete.
@@ -68,7 +67,7 @@ Implement the approved design without changing the agreed scope.
 ## Inputs / Outputs
 
 - Inputs:
-  - executable spec
+  - executable spec-refinement
   - design decisions
   - confirmed task breakdown plan
   - rules bundle
@@ -90,14 +89,14 @@ Implement the approved design without changing the agreed scope.
 
 ## Replay Signals
 
-- Input signal: confirmed spec, approved design, confirmed task breakdown plan, and selected rules bundle.
+- Input signal: confirmed spec-refinement, approved design, confirmed task breakdown plan, and selected rules bundle.
 - Output to verify: code changes, implementation notes, validation evidence, self-test evidence, task-level evidence.
-- Stop signal: spec rewrites, scope expansion, or bypassing the rules bundle.
+- Stop signal: spec-refinement rewrites, scope expansion, or bypassing the rules bundle.
 - Handoff signal: implementation is ready for `test-design`.
 
 ## Gotchas
 
-- Do not rewrite the spec while implementing.
+- Do not rewrite the spec-refinement while implementing.
 - Do not expand the boundary because implementation is inconvenient.
 - Do not bypass the rules bundle for convenience.
 - Do not leave validation evidence implicit.
@@ -108,7 +107,7 @@ Implement the approved design without changing the agreed scope.
 ## Stop Rules
 
 - Stop at implementation.
-- Do not rewrite the spec.
+- Do not rewrite the spec-refinement.
 - Do not change the agreed boundaries.
 - Do not skip the rules bundle.
 - Do not bypass the rules bundle.
@@ -120,3 +119,4 @@ Implement the approved design without changing the agreed scope.
 - `skills/references/engineering-delivery-method.md`
 - `skills/references/engineering-delivery-template.md`
 - `rules/index.md`
+

package/skills/feature-build/references/comment-specification.md

@@ -1,102 +1,89 @@
-# 娉ㄩ噴瑙勮寖
-
-> 浠ｇ爜娉ㄩ噴鏍囧噯锛岀敤浜庝繚鎸佸彲璇绘€у拰鍙淮鎶ゆ€с€傝繖閲屽彧淇濈暀娉ㄩ噴瀵嗗害銆佹ā鏉垮拰妫€鏌ラ」锛涘叿浣撲笟鍔?鍒嗗眰鍩虹嚎浼樺厛寮曠敤 [rules/overlays/pig-cloud.md](/D:/work/java/pig-skills/rules/overlays/pig-cloud.md) 鍙婂叾瀛愯鍒欍€?
-## Class Comment
-
-### 蹇呰鍐呭
-
-| 鍐呭 | 璇存槑 |
-|------|------|
-| 绫昏鏄?| 涓€鍙ヨ瘽鎻忚堪鑱岃矗 |
-| 浣滆€?| 鍒涘缓鑰?|
-| 鏃ユ湡 | 鍒涘缓鏃ユ湡 |
-| 鐗堟湰 | 鍙€?|
-
-### 妯℃澘
-
-```java
-/**
- * 璁㈠崟鏈嶅姟瀹炵幇绫伙紝澶勭悊璁㈠崟鐩稿叧涓氬姟閫昏緫
- *
- * @author zhangsan
- * @date 2026-06-16
- */
-@Service
-@RequiredArgsConstructor
-public class OrderServiceImpl implements OrderService {
-}
-```
-
-## Method Comment
-
-### 蹇呰鍐呭
-
-| 鍐呭 | 璇存槑 |
-|------|------|
-| 鏂规硶璇存槑 | 涓€鍙ヨ瘽鎻忚堪鍔熻兘 |
-| 鍙傛暟璇存槑 | 姣忎釜鍙傛暟鐨勫惈涔?|
-| 杩斿洖璇存槑 | 杩斿洖鍊煎惈涔?|
-| 寮傚父璇存槑 | 鍙兘鎶涘嚭鐨勫紓甯?|
-| 鍓嶇疆鏉′欢 | 鎵ц鍓嶉渶瑕佹弧瓒崇殑鏉′欢 |
-| 鍚庣疆鏉′欢 | 鎵ц鍚庣殑鐘舵€佸彉鍖?|
-
-### 妯℃澘
-
-```java
-/**
- * 鍒涘缓璁㈠崟锛屾牎楠屽簱瀛樺苟鐢熸垚璁㈠崟璁板綍
- *
- * @param dto 璁㈠崟鍒涘缓璇锋眰DTO
- * @return 璁㈠崟ID
- * @throws BusinessException 搴撳瓨涓嶈冻鏃舵姏鍑?
- */
-public Result<Long> create(OrderCreateDTO dto) {
-}
-```
-
-## Logic Comment
-
-### 閫傜敤鍦烘櫙
-
-- 澶氭潯浠跺垽鏂?- 鐘舵€佹祦杞?- 澶嶆潅璁＄畻
-- 澶栭儴璋冪敤
-- 鏁版嵁杞崲
-- 鍒嗛〉/鎵归噺閫昏緫
-
-### 瑙勫垯
-
-- 鐢?`Step 1/2/3` 鏍囪娴佺▼
-- 鍙В閲婁笟鍔℃剰鍥撅紝涓嶈В閲婃樉鑰屾槗瑙佺殑璇硶
-- 澶嶆潅閫昏緫蹇呴』鐣欎笅鑳界湅鎳傜殑涓婁笅鏂?
-## External Call Comment
-
-### 蹇呰鍐呭
-
-- 璋冪敤鐩殑
-- 璋冪敤鎺ュ彛
-- 浼犲叆鍙傛暟
-- 棰勬湡杩斿洖
-- 寮傚父澶勭悊
-
-### 绀轰緥
-
-```java
-// 杩滅▼璋冪敤锛氭煡璇㈢敤鎴蜂俊鎭紝鐢ㄤ簬璁㈠崟鍒涘缓鍓嶆牎楠?UserDTO user = userApi.findById(dto.getUserId()).assertSucceed();
-```
-
-## Comment Density
-
-| 灞傜骇 | 寤鸿瀵嗗害 |
-|------|---------|
-| Entity | 绫绘敞閲?+ 瀛楁娉ㄩ噴 |
-| DTO/VO | 绫绘敞閲?+ 瀛楁娉ㄩ噴 |
-| Mapper | 绫绘敞閲婂嵆鍙?|
-| Service | 绫绘敞閲?+ 鏂规硶娉ㄩ噴 + 閫昏緫娉ㄩ噴 |
-| Controller | 绫绘敞閲?+ 鏂规硶娉ㄩ噴 |
-| Convert | 绫绘敞閲婂嵆鍙?|
-
-## Anti-rationalization
-
-- 浠ｇ爜寰堟竻妤氾紝涓嶉渶瑕佹敞閲?- 娉ㄩ噴浼氳繃鏃讹紝鎵€浠ヤ笉鍐?- 浠ュ悗鍐嶈ˉ娉ㄩ噴
-- IDE 鍙互鑷姩鐢熸垚灏卞浜?
-
+# 注释规范
+
+> 代码注释标准，用于保持可读性和可维护性。这里只保留注释密度、模板和检查项；具体业务分层基线优先引用 `rules/overlays/pig-cloud.md` 及其子规则。
+
+## Class Comment
+
+### 必要内容
+
+| 内容 | 说明 |
+|------|------|
+| 类说明 | 一句话描述职责 |
+| 作者 | 创建者 |
+| 日期 | 创建日期 |
+| 版本 | 可选 |
+
+### 模板
+
+```java
+/**
+ * 用户服务。
+ *
+ * <p>负责用户查询、创建与基础校验。</p>
+ */
+```
+
+## Method Comment
+
+### 必要内容
+
+| 内容 | 说明 |
+|------|------|
+| 方法说明 | 方法做什么 |
+| 参数说明 | 每个参数的含义 |
+| 返回说明 | 返回值含义 |
+| 异常说明 | 可能抛出的异常 |
+| 前置条件 | 调用前要满足什么 |
+| 后置条件 | 执行后的状态变化 |
+
+### 模板
+
+```java
+/**
+ * 根据用户 ID 查询用户信息。
+ *
+ * @param userId 用户 ID
+ * @return 用户信息
+ * @throws BusinessException 用户不存在时抛出
+ */
+```
+
+## Inline Comment
+
+### 使用场景
+
+- 多条件判断
+- 状态流转
+- 复杂计算
+- 需要解释意图但代码本身又不适合再拆函数的地方
+
+### 规则
+
+- 注释要解释“为什么”，不要重复“是什么”。
+- 复杂逻辑必须留下能看懂的上下文。
+- 用短句说明约束、边界和原因。
+
+## 示例
+
+```java
+// 远程调用：查询用户信息，用于订单创建前校验
+UserDTO user = userApi.findById(dto.getUserId()).assertSucceed();
+```
+
+## 注释密度
+
+| 场景 | 建议 |
+|------|------|
+| Entity | 类注释 + 字段注释 |
+| DTO/VO | 类注释 + 字段注释 |
+| Mapper | 类注释即可 |
+| Service | 类注释 + 方法注释 + 逻辑注释 |
+| Controller | 类注释 + 方法注释 |
+| Convert | 类注释即可 |
+
+## 不建议
+
+- 代码很清楚，不需要注释。
+- 注释会过时，所以不注释。
+- 以后再补注释。
+- IDE 自动生成就够了。

package/skills/knowledge-capture/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: knowledge-capture
-description: Capture reusable decisions, requirement knowledge, realtime code facts, CodeWiki facts, and handoff notes; use when an upstream task already produced evidence and you need to normalize it, persist it, or hand it off without redoing analysis.
+description: 当上游任务已经产出证据，需要整理、沉淀或交接而不想重做分析时，提炼可复用的决策、需求知识、实时代码事实、CodeWiki 事实和交接笔记
 lifecycle_stage: capture
 rule_profile: capture
 dependencies: []

package/skills/{performance-check → performance-audit}/SKILL.md

@@ -1,7 +1,6 @@
 ---
-name: performance-check
-description: 当需要性能结论时，对变更中的延迟、吞吐量或资源瓶颈进行审查
-lifecycle_stage: review
+name: performance-audit
+description: 当需要性能结论时，对变更中的延迟、吞吐量或资源瓶颈进行审查
 rule_profile: performance
 dependencies:
   - feature-build
@@ -40,7 +39,7 @@ refs:
   - rules/index.md
 ---
 
-# Performance Check
+# Performance Audit
 
 ## Purpose
 
@@ -115,3 +114,5 @@ Find performance bottlenecks and optimization opportunities.
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
 - `rules/index.md`
+
+# Performance Audit

package/skills/project-bootstrap/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: project-bootstrap
-description: 当项目需要初始化时，为新工作区装载合适的技能和规则包
+description: 当项目需要初始化时，为新工作区装载合适的技能和规则包
 lifecycle_stage: scaffold
 rule_profile: scaffold
 dependencies: []
@@ -58,7 +58,7 @@ Create a new workspace with the right skills and rules layout.
 - Input signal: client type, workspace markers, desired rules bundle.
 - Output to verify: starter structure, installed bundle, setup notes.
 - Stop signal: product scope design or application code generation.
-- Handoff signal: the workspace is ready for `workflow-router` or `spec`.
+- Handoff signal: the workspace is ready for `workflow-router` or `spec-refinement`.
 
 ## Examples
 
@@ -78,3 +78,4 @@ Create a new workspace with the right skills and rules layout.
 - `skills/references/prompt-replay-checklist.md`
 - `skills/references/full-chain-replay-scenarios.md`
 - `rules/index.md`
+

package/skills/references/business-fact-extraction.md

@@ -177,7 +177,7 @@ Use the strongest source available first:
 
 ## Auto-Write Pack
 
-Use `skills/extract-business-facts/scripts/write-knowledge-base.js` when the staged readout should be written into the knowledge base.
+Use `skills/business-fact-extraction/scripts/write-knowledge-base.js` when the staged readout should be written into the knowledge base.
 
 ### Input Shape
 
@@ -200,7 +200,7 @@ Use `skills/extract-business-facts/scripts/write-knowledge-base.js` when the sta
 ### Command
 
 ```bash
-node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-pack.json
+node skills/business-fact-extraction/scripts/write-knowledge-base.js --input fact-pack.json
 ```
 
 ### Behavior
@@ -214,7 +214,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 ## Handoff Targets
 
 - `domain-modeling` when the facts need boundary or concept normalization
-- `spec` when the facts need to become a user-confirmable spec
+- `spec-refinement` when the facts need to become a user-confirmable spec-refinement
 - `knowledge-capture` when the facts are stable and ready to persist
 
 ## Sample Readout
@@ -252,7 +252,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 - decision: inventory must be reserved before order confirmation
 - reason: avoid overselling
 - date or context: 2026-06-22, order flow review
-- affected artifact: checkout spec
+- affected artifact: checkout spec-refinement
 - notes: failure should return a clear stock shortage message
 
 #### `knowledge-base/requirements/acceptance.md`
@@ -292,7 +292,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 
 ### 1. Source Input
 
-- PRD / spec note: checkout must not confirm when stock is insufficient
+- PRD / spec-refinement note: checkout must not confirm when stock is insufficient
 - code evidence: `order-service` reserves inventory before creating the order
 - runtime evidence: shortage returns a stock error before commit
 
@@ -330,7 +330,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
         "decision": "inventory must be reserved before order confirmation",
         "reason": "avoid overselling",
         "date or context": "2026-06-22, checkout review",
-        "affected artifact": "checkout spec",
+        "affected artifact": "checkout spec-refinement",
         "notes": "shortage returns a clear error"
       }
     ],
@@ -357,7 +357,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 ### 4. Persist
 
 ```bash
-node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-pack.json
+node skills/business-fact-extraction/scripts/write-knowledge-base.js --input fact-pack.json
 ```
 
 ### 5. `knowledge-capture`
@@ -392,7 +392,7 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 - decision: inventory must be reserved before order confirmation
 - reason: avoid overselling
 - date or context: 2026-06-22, order flow review
-- affected artifact: checkout spec
+- affected artifact: checkout spec-refinement
 - notes: failure should return a clear stock shortage message
 
 ### CodeWiki Update
@@ -412,3 +412,4 @@ node skills/extract-business-facts/scripts/write-knowledge-base.js --input fact-
 - context: checkout path
 - why it failed: allowed overselling under concurrent requests
 - how to avoid it: reserve before committing the order
+

package/skills/references/engineering-delivery-method.md

@@ -2,14 +2,14 @@
 
 ## Goal
 
-Help engineering teams turn an approved spec into executable work, decide complexity before coding, implement inside `feature-build`, self-verify locally, and then hand off to validation and review.
+Help engineering teams turn an approved spec-refinement into executable work, decide complexity before coding, implement inside `feature-build`, self-verify locally, and then hand off to validation and review.
 
 Use [`engineering-delivery-template.md`](engineering-delivery-template.md) when you need the copyable one-page form.
 
 ## Flow
 
-1. Start from an approved spec or executable design.
-2. Align the spec with current project facts and selected rules.
+1. Start from an approved spec-refinement or executable design.
+2. Align the spec-refinement with current project facts and selected rules.
 3. Plan the task execution direction before coding.
 4. Decide whether the change is simple or complex before coding.
 5. If the change is complex, produce `technical-design` first.
@@ -61,3 +61,4 @@ Use [`engineering-delivery-template.md`](engineering-delivery-template.md) when
 - `skills/references/project-requirement-alignment.md`
 - `skills/references/flow-test-cases.md`
 - `skills/references/full-chain-replay-scenarios.md`
+

package/skills/references/engineering-delivery-template.md

@@ -2,7 +2,7 @@
 
 ## How to Use
 
-- Start from an approved spec or executable design.
+- Start from an approved spec-refinement or executable design.
 - Fill this page before implementation.
 - Keep each task small enough to implement and self-test independently.
 - Do not add long background text.
@@ -73,8 +73,9 @@ Rules:
 
 ## Minimum Acceptance
 
-- The spec is split into small tasks.
+- The spec-refinement is split into small tasks.
 - The execution direction is explicit before confirmation.
 - Every task has a done criteria and a self-test.
 - The implementation was verified task by task.
 - The handoff includes evidence, not just code.
+