add-coder 0.2.3 → 0.2.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "add-coder",
|
|
3
|
-
"version": "0.2.
|
|
3
|
+
"version": "0.2.4",
|
|
4
4
|
"private": false,
|
|
5
5
|
"description": "[codein2027](https://github.com/xiaomingming92/codein2027) - A complete scaffolding for building the ADD programming paradigm, the implementation layer for AI code governance. Core principle: Audit as Infrastructure. Breaks the black-box programming process and cross-session amnesia, evolving programming paradigms into an auditable, traceable, and convergent new era. npx-ready.\n\n[codein2027](https://github.com/xiaomingming92/codein2027) 快速构建 ADD 编程范式的完整脚手架——AI 代码治理的落地方案。以「审计即基础设施」为核心，彻底打破编程过程黑盒与跨轮失忆，让编程范式进化为可审计、可追溯、可收敛的新时代。npx 即用，人人可体验。",
|
|
6
6
|
"repository": {
|
|
@@ -92,6 +92,7 @@
|
|
|
92
92
|
"predev": "npm run db:ensure",
|
|
93
93
|
"dev": "tsup --watch",
|
|
94
94
|
"db:ensure": "bash scripts/db-ensure.sh",
|
|
95
|
+
"sync": "bash scripts/sync-magic-dirs.sh",
|
|
95
96
|
"lint": "eslint src/",
|
|
96
97
|
"lint:fix": "eslint src/ --fix",
|
|
97
98
|
"generate": "tsx src/caijuehub/transcribe.ts",
|
|
@@ -26,6 +26,7 @@
|
|
|
26
26
|
| P2 | ADD-13 DPS 上游文档质量闸门 | Plan 概括度 → Review 注意力稀释 → Specs 遗漏 → 实现偏差。`check_dps`（DPS ≥ 85）在 Step 0 末尾量化阻断 | ✅ 已实现 | 2026-06-11 引入 |
|
|
27
27
|
| P2 | ADD-14 RAHS 下游执行健康度闸门 | 范围保真度 + 类型安全 + 审计完整度 + Spec 合规 + 阶段对称性。`check_rahs`（RAHS ≥ 90）在 Step 4/8 量化阻断 | ✅ 已实现 | 2026-06-11 引入 |
|
|
28
28
|
| P2 | ADD-15 add-route 闭环自检 | Step 3 代码完成后必须调用 `check_add_route_completeness` 扫描 add-route Step 完成度，防止执行遗漏。返回 complete 方可进入 Step 3.5 | ✅ 已实现 | 2026-06-11 引入 |
|
|
29
|
+
| P2 | ADD-17 HITL 磋商临时文件机制 | doc-format-guard 要求 Plan/Review 文件包含完整章节才放行，HITL 第一步只写总览表会被 guard 阻断。用 `{name}.temporary.md` 做磋商（不受 guard 检查），人类拍板后再写正式文件并删除 temporary.md | ✅ 已实现 | 2026-07-23 引入 |
|
|
29
30
|
|
|
30
31
|
|
|
31
32
|
### P0 规则：不可跳过
|
|
@@ -66,6 +67,7 @@ AI 助手必须先恢复到基线、找到对应的 SKILL 文件并按步骤执
|
|
|
66
67
|
| ADD-14 | `add-paradigm` Step 4 末端 + Step 8 收敛 + MCP `check_rahs` | Step 4 合规检查 / Step 8 收敛判定 |
|
|
67
68
|
| ADD-15 | `add-paradigm` Step 3.6 + MCP `check_add_route_completeness` | Step 3 代码完成后自检 |
|
|
68
69
|
| ADD-16 | `add-paradigm` Step 9 | runtime-fix plan 收敛后，关闭 gateway.md 运行时发现 |
|
|
70
|
+
| ADD-17 | `add-paradigm` 独立能力：生成 Plan / Step 0 | Plan/Review HITL 磋商时（写入 temporary.md 绕过 guard，拍板后写正式文件） |
|
|
69
71
|
|
|
70
72
|
---
|
|
71
73
|
|
|
@@ -759,6 +761,34 @@ ADD-0.1 要求"文档先行"（先改文档再改代码）。ADD-16 是对 ADD-0
|
|
|
759
761
|
|
|
760
762
|
---
|
|
761
763
|
|
|
764
|
+
## ADD-17：HITL 磋商临时文件机制
|
|
765
|
+
|
|
766
|
+
**Plan 和 Review 的 HITL 磋商必须在写入正式文件之前完成，但 doc-format-guard 要求 `.qoder/plans/` 和 `.qoder/reviews/` 下的文件包含完整章节才放行。HITL 第一步只写总览表、不写正文——会被 guard 阻断。**
|
|
767
|
+
|
|
768
|
+
### 流程
|
|
769
|
+
|
|
770
|
+
```
|
|
771
|
+
① AI 写 {name}.temporary.md（只含 HITL 总览表，放项目根目录，不受 guard 检查）
|
|
772
|
+
② 人类审阅 HITL 表 → 逐行拍板（同意/调整）
|
|
773
|
+
③ AI 根据确认后的 HITL 表生成完整 Plan/Review → 写入正式路径（guard 放行）
|
|
774
|
+
④ 删除 temporary.md
|
|
775
|
+
```
|
|
776
|
+
|
|
777
|
+
### 适用范围
|
|
778
|
+
|
|
779
|
+
| 文档类型 | temporary 磋商 | 正式写入路径 |
|
|
780
|
+
|---------|:---:|------|
|
|
781
|
+
| Plan（标准版/精简版） | ✅ 需要 | `.qoder/plans/{YYYY-MM}/{DD}/` |
|
|
782
|
+
| Review（方案/实现） | ✅ 需要 | `.qoder/reviews/` |
|
|
783
|
+
| Spec / Tasks / Checklist | ❌ 不需要 | 直接写入 `.qoder/specs/` |
|
|
784
|
+
| Handoff | ❌ 不需要 | 直接写入 `.qoder/plans/` |
|
|
785
|
+
|
|
786
|
+
### 与 ADD-0.1 的关系
|
|
787
|
+
|
|
788
|
+
ADD-0.1 要求"文档先行"——HITL 磋商本身就是文档先行的一种形式（先对齐方向再产出文档）。temporary.md 机制确保 HITL 的"先拍板再展开"哲学不因 guard 的"完整章节校验"而被破坏。
|
|
789
|
+
|
|
790
|
+
---
|
|
791
|
+
|
|
762
792
|
---
|
|
763
793
|
|
|
764
794
|
## 项目技术约束
|
|
@@ -51,7 +51,7 @@ description: "Audit-Driven Development paradigm workflow. Invoke when starting a
|
|
|
51
51
|
- **标准版** `standard-plan-template.md`：多模块、跨系统集成、含架构选型或数据模型设计。
|
|
52
52
|
2. **读取模板**：读选定的模板文件，禁止凭记忆
|
|
53
53
|
3. **命名规范**：`{项目名}-{功能名}-plan-v1.md` → `{{magicDir}}/plans/{YYYY-MM}/{DD}/`（按当天日期创建子目录）
|
|
54
|
-
4. **HITL
|
|
54
|
+
4. **HITL 总览（先写 temporary.md）**：doc-format-guard 要求写入 `.qoder/plans/` 的文件必须包含完整章节，但 HITL 第一步只写总览表不写正文。因此先在项目根目录写 `{plan-name}.temporary.md`（只含 HITL 表，不受 guard 检查），人类拍板后再写正式 Plan 文件并删除 temporary.md。
|
|
55
55
|
5. **HITL 确认后展开**：人类拍板后，再填写以下正文章节。
|
|
56
56
|
6. **必含章节（标准版）**：
|
|
57
57
|
- PLAN 元信息（名称/时间/关联文档/ADD-7审计策略表）
|
|
@@ -121,6 +121,8 @@ description: "Audit-Driven Development paradigm workflow. Invoke when starting a
|
|
|
121
121
|
>
|
|
122
122
|
> **每次根据模板生成文档时（plan/spec/review/handoff），MUST 先重新读取对应的模板文件，再填充内容。禁止凭记忆生成——模板可能已在迭代中更新，记忆中的版本可能不完整。**
|
|
123
123
|
|
|
124
|
+
> **Review 的 HITL 磋商（temporary.md 机制）**：生成方案 Review（`review-template.md`）或实现 Review（`review-implementation-template.md`）时，和 Plan 一样——doc-format-guard 要求完整章节才放行，HITL 第一步只写总览表会被阻断。因此 Review 也走 temporary.md 流程：先写 `{review-name}.temporary.md`（只含 HITL 发现总览表）→ 人类拍板 → 生成完整 Review 写入 `.qoder/reviews/` → 删除 temporary。具体步骤见下方 Step 3.5.3（实现 Review）和 Step 0 方案 Review 产出。
|
|
125
|
+
|
|
124
126
|
#### 0.2 搜索相关项目文档
|
|
125
127
|
|
|
126
128
|
调用 MCP 工具 `find_related_docs` 查找与当前变更相关的项目文档：
|
|
@@ -808,7 +810,7 @@ check_add_route_completeness({ planKeyword: "<Plan 核心关键词>" })
|
|
|
808
810
|
|
|
809
811
|
### 3.5.3 生成实现审查文档
|
|
810
812
|
|
|
811
|
-
|
|
813
|
+
按 HITL temporary.md 流程执行：读取 `review-implementation-template.md` → 先写 `{name}-review-implementation.temporary.md`（只含 HITL 发现总览表）→ 人类一次性拍板 → 逐条展开详细分析 → 写入 `.qoder/reviews/`（guard 放行）→ 删除 temporary。详见上方模板生成规则处的 Review HITL 磋商说明。
|
|
812
814
|
|
|
813
815
|
### 3.5.4 生成运行时审查文档（所有 [T] 项通过后）
|
|
814
816
|
|