add-coder 0.1.14 → 0.1.17

package/README.en.md

@@ -0,0 +1,218 @@
+# add-coder
+
+> 🌐 [🀄中文](./README.md) | English
+
+**AI Governance, Implemented** — The complete scaffolding from [codein2027](https://github.com/xiaomingming92/codein2027) for rapidly building the ADD programming paradigm. Built on the core principle of **Audit as Infrastructure**, it shatters the black-box programming process and cross-session amnesia, evolving the programming paradigm into an auditable, traceable, and convergent new era. [NPM](https://www.npmjs.com/package/add-coder) · [GitHub](https://github.com/xiaomingming92/add-coder)
+
+
+> 🧭 **Getting hands-on?** See [GUIDE.md](https://github.com/xiaomingming92/add-coder/blob/main/GUIDE.md) — trigger word quick reference, requirements-to-Plan, and full workflow walkthrough.
+
+```bash
+npx add-coder init
+```
+
+---
+
+## Not a Template Tool — An Architectural Difference
+
+There are already plenty of AI coding templates, hook adapters, and MCP scaffolds. What fundamentally sets add-coder apart is not "what files it generates," but a **paradigm shift at the architectural level**:
+
+### ① Audit Is Infrastructure, Not After-the-Fact Logging
+
+Traditional AI development: Chat → Generate code → Dig through chat history afterward to find "who changed what"
+
+| Traditional Model | add-coder |
+|-------------------|-----------|
+| Logs are append-only text files | Audit is a **structured data table** (DevOperation + AuditLog), supporting multi-dimensional queries by plan/step/agent/tool |
+| Auditing relies on developer discipline | The **MCP audit toolchain** automatically records every operation; system gateways enforce checks |
+| No traceability | Audit events are naturally linked: Plan → Spec → Task → Step → Tool Call, forming a complete evidence chain |
+
+### ② Gateway-Driven, Not Free-Form Conversation
+
+Traditional AI coding is "you say, I do" — quality depends entirely on the LLM's state that day. add-coder embeds **dual quality gateways** into the architecture:
+
+```
+DPS (Design-Process Symmetry)  — Design / Implementation / Docs / Audit, each weighted 25%, < 85% BLOCKED
+RAHS (Runtime Architecture Health Score) — Runtime architecture health, < 90% BLOCKED
+```
+
+These are not "suggestions" — they are **architectural blocks**. A Step cannot advance without passing its gateway.
+
+### ③ Cross-Session Memory, Not Per-Session Amnesia
+
+The fatal flaw of AI conversations: architectural decisions from last session, bugs fixed, agreements reached — all forgotten in the next conversation. add-coder solves this at the architecture level:
+
+- **Handoff Documents** — Automatically generated structured handoff at the end of each session, auto-loaded by the next session
+- **Plan Index** — All Plans are centrally indexed via `index.md`, supporting fuzzy-match quick lookup
+- **DevLog Timeline** — Every operation is written to the `{YYYY-MM}/{DD}/` timeline, enabling full historical state traceability
+
+### ④ Policy-Update-Loop: Self-Evolving Governance (the scaffold itself does not include this architectural capability; a DEMO repo will be provided next to better illustrate the Policy-Update-Loop and Report system)
+
+Not a static template, but a **closed-loop adaptive system**:
+
+```
+Execute → Audit → Boundary Report → Rule Adjustment → Next Execution
+```
+
+Runtime-generated Reports feed back into governance rules, enabling continuous evolution of governance strategies.
+
+### ⑤ Multi-IDE Hooks as the Governance Layer
+
+Hooks are not "notification push" — they are the **IDE runtime interception layer**:
+
+| Hook Type | Function |
+|-----------|----------|
+| PreToolUse | Validates whitelist before tool invocation, injects context, DPS condition checks |
+| PostToolUse | Automatic audit logging, Plan sync detection, format guarding |
+| PreCompact | Forces retention of critical document paths during cross-session context compression |
+| PromptSubmit | Injects ADD vocabulary triggers, ensuring zero-latency LLM response to commands like "acceptance" and "gateway" |
+
+Each IDE (Claude/Qoder/VS Code) has its own hook implementation, but the **governance logic is unified** — the architecture is consistent, only the adapter layer differs.
+
+---
+
+## Quick Start
+
+```bash
+npx add-coder init
+```
+
+The first `init` auto-detects your IDE and interactively guides you through database selection (PostgreSQL / SQLite / self-managed), container runtime (podman / docker / self-managed), Prisma initialization, and ADD template deployment.
+
+```bash
+npx add-coder init
+# → Choose IDE (Qoder / Claude / VS Code)
+# → Choose database (PostgreSQL / SQLite / self-managed)
+# → Choose container (podman / docker / self-managed)
+# → prisma init + add.prisma copied
+# → prisma db push (adds new tables only, no data deletion)
+# → prisma generate
+# → ADD governance model ready ✓
+```
+
+> **Env file priority**: `.env.development.local` > `.env.development` > `.env.local` > `.env`
+
+## Commands
+
+| Command | Description |
+|---------|-------------|
+| `init` | Initialize ADD templates, supports `--adapter claude\|qoder\|vscode\|auto` |
+| `sync` | Incrementally sync missing files |
+| `status` | Check template integrity |
+
+### init Internal Flow
+
+| Step | Action | Description |
+|------|--------|-------------|
+| ① | Detect IDE | Scan for `.qoder/` `.claude/` `.vscode/` existence, or specify via `--adapter` |
+| ② | Load config | Interactive Q&A > `add-coder.config.ts` > auto-detect > defaults |
+| ③ | DB deployment | `db-ensure.sh` starts container/PG connection + `injectPrisma()` Caijue layer (Prisma init → AddUser model copy → db push → generate) |
+| ④ | Render templates | 55 core template files (skills/agents/templates/plans/specs/scripts…) |
+| ⑤ | Deploy adapters | Copy core content to `.add/` `.qoder/` `.claude/` directories, supplement IDE-specific hooks/mcp |
+| ⑥ | Write files | Four modes: interactive / yes / force / dry-run; `.sh` scripts auto `chmod` |
+| ⑦ | Output summary | Created / skipped / overwritten stats + next-step hints |
+
+### init Options
+
+| Option | Description |
+|--------|-------------|
+| `--adapter <type>` | Target IDE: claude / qoder / vscode / auto (default) |
+| `--config <path>` | Specify config file |
+| `--yes` | Skip interactions, create new files only |
+| `--force` | Overwrite existing files |
+| `--dry-run` | Preview mode, no writes |
+
+## Generated Content
+
+| Directory | Content |
+|-----------|---------|
+| `.add/` | ADD shared core (skills, agents, docs, scripts, rules, etc.) |
+| `.claude/` | Claude Code adapter (hooks, settings.json) |
+| `.qoder/` | Qoder adapter (hooks, settings.json, mcp.json) |
+| `.vscode/` | VS Code adapter (settings.json, tasks.json) |
+
+## MCP Audit Toolchain
+
+`init` automatically deploys the MCP server (`mcp-server.ts`) into the project, loaded by the IDE via `mcp.json`. The following audit and governance tools are provided:
+
+| Tool | Purpose | Trigger Scenario |
+|------|---------|-----------------|
+| `record_dev_operation` | Record development operation audits (before/after/reason) | Every file change, config modification |
+| `query_audit_logs` | Query audit records by planKeyword / targetId | Cross-session context recovery, iteration evidence verification |
+| `get_project_context` | Get ADD workflow status snapshot | Fresh conversation start |
+| `get_db_schema` | Get Prisma schema info | Database-related operations |
+| `check_dps` | DPS gateway (Design/Implementation/Docs/Audit, each 25%) | End of Step 0 |
+| `check_rahs` | RAHS gateway (runtime architecture health) | Step 4/8 |
+| `check_add_route_status` | add-route file existence check | Before Step 3 |
+| `check_spec_sync` | Spec doc checkbox status vs. code consistency | After Spec execution |
+| `find_related_docs` | Search related architecture/spec documents | Context understanding |
+
+> Full tool list: [MCP Toolchain Specification](https://github.com/xiaomingming92/codein2027/blob/main/docs/大田精准耕播智能决策系统/knowledge/02-规范/%E3%80%8A%E5%BC%80%E5%8F%91%E6%93%8D%E4%BD%9C%E5%AE%A1%E8%AE%A1%E5%AD%98%E6%A1%A3%E8%A7%84%E8%8C%83%E3%80%8B.md).
+
+## Architecture Overview
+
+```
+                    ┌─────────────┐
+                    │  ADD Paradigm│
+                    │  Step 0-9    │
+                    └──────┬──────┘
+                           │ Gateway-driven
+              ┌────────────┼────────────┐
+              ▼            ▼            ▼
+       ┌──────────┐ ┌──────────┐ ┌──────────┐
+       │DPS Gateway│ │RAHS Gate │ │Compliance│
+       └────┬─────┘ └────┬─────┘ └────┬─────┘
+            │            │            │
+              ▼            ▼            ▼
+       ┌─────────────────────────────────────┐
+       │        Audit Infrastructure Layer    │
+       │  DevOperation / AuditLog Tables      │
+       │  MCP Audit Toolchain                 │
+       │  Handoff / DevLog Timeline Docs      │
+       └─────────────────────────────────────┘
+                           │
+              ┌────────────┼────────────┐
+              ▼            ▼            ▼
+       ┌──────────┐ ┌──────────┐ ┌──────────┐
+       │ Claude   │ │  Qoder   │ │  VS Code │
+       │ Hooks    │ │  Hooks   │ │  Config  │
+       └──────────┘ └──────────┘ └──────────┘
+                           │
+              ┌────────────┘
+              ▼
+       ┌─────────────────────────────────────┐
+       │       Caijuehub Rule Engine          │
+       │  TOML-Driven Policy System           │
+       │  Detect / Adapt / Prisma / Write —   │
+       │  Fully Configurable                  │
+       └─────────────────────────────────────┘
+```
+
+## Prerequisites
+
+- Node.js >= 20
+- Prisma ^7.0 (auto-detected during `init`, guided installation if missing)
+- PostgreSQL / SQLite (MCP toolchain depends on DevOperation + AuditLog tables)
+
+> **Recommended**: Run PostgreSQL via Podman/Docker, reference config:
+> ```yaml
+> postgres:
+>   image: docker.io/postgres:16-alpine
+>   ports: ["127.0.0.1:5433:5432"]
+>   environment:
+>     POSTGRES_DB: mydb
+>     POSTGRES_USER: admin
+>     POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
+> ```
+> Mount data volume to `~/data/your_project/postgres/` to avoid data loss on container removal.
+
+> 📦 [Changelog](./CHANGELOG.md)
+
+---
+
+## 🎬 Coming Soon
+
+| Plan | Description |
+|------|-------------|
+| Demo Repo | A full example repository showcasing end-to-end closed-loop practice of Policy-Update-Loop and the Report system |
+| MCP Restructure | MCP toolchain architecture upgrade, improving audit and gateway tool extensibility and standalone deployment capability |

package/README.md

@@ -1,7 +1,10 @@
 # add-coder
 
+> 🌐 🀄中文 | [English](./README.en.md)
+
 **AI 代码治理的落地方案** — [codein2027](https://github.com/xiaomingming92/codein2027) 快速构建 ADD 编程范式的完整脚手架。以「审计即基础设施」为核心，彻底打破编程过程黑盒与跨轮失忆，让编程范式进化为可审计、可追溯、可收敛的新时代。 [NPM](https://www.npmjs.com/package/add-coder) · [GitHub](https://github.com/xiaomingming92/add-coder)
 
+
 > 🧭 **从零上手实操？** 请参见 [GUIDE.md](https://github.com/xiaomingming92/add-coder/blob/main/GUIDE.md) — 包含触发词速查、需求转 Plan、完整链路演练。
 
 ```bash
@@ -43,7 +46,7 @@ AI 对话的致命缺陷：上次讨论的架构决策、已修复的 Bug、达
 - **Plan 索引** — 所有 Plan 通过 `index.md` 集中索引，支持模糊匹配快速定位
 - **DevLog 时序记录** — 每一步操作写入 `{YYYY-MM}/{DD}/` 时间轴，可回溯任意历史状态
 
-### ④ Policy-Update-Loop：治理自我进化
+### ④ Policy-Update-Loop：治理自我进化(脚手架不包含此架构能力,接下来会给到DEMO仓库让大家更好理解Policy-Update-Loop和Report体系)
 
 不是静态模板，而是**闭环自适应系统**：
 
@@ -201,3 +204,14 @@ npx add-coder init
 >     POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
 > ```
 > 数据卷建议挂载到 `~/data/your_project/postgres/`，避免容器销毁丢失数据。
+
+> 📦 [更新日志 (CHANGELOG)](./CHANGELOG.md)
+
+---
+
+## 🎬 预告
+
+| 计划 | 说明 |
+|------|------|
+| Demo 仓库演示 | 提供完整示例仓库，展示 Policy-Update-Loop 与 Report 体系的端到端闭环实践 |
+| MCP 能力重构 | MCP 工具链架构升级，提升审计与门禁工具的可扩展性和独立部署能力 |

package/dist/index.js

@@ -736,7 +736,7 @@ async function initCommand(options) {
   }
   if (db.engine === "postgresql" && db.container && db.container !== "manual") {
     if (!db.reuseExisting) {
-      const composeName = db.container === "podman" ? "podman-compose.yml" : "docker-compose.yml";
+      const composeName = db.container === "podman" ? "podman-compose.add.yml" : "docker-compose.add.yml";
       const composePath = resolve4(projectRoot, composeName);
       if (!options.dryRun && (!existsSync6(composePath) || options.force)) {
         writeFileSync3(composePath, composeContent(config.projectName || "add-project"), "utf-8");

package/package.json

@@ -1,8 +1,12 @@
 {
   "name": "add-coder",
-  "version": "0.1.14",
+  "version": "0.1.17",
   "private": false,
   "description": "[codein2027](https://github.com/xiaomingming92/codein2027) 快速构建 ADD 编程范式的完整脚手架——AI 代码治理的落地方案。以「审计即基础设施」为核心，彻底打破编程过程黑盒与跨轮失忆，让编程范式进化为可审计、可追溯、可收敛的新时代。npx 即用，人人可体验。",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/xiaomingming92/add-coder.git"
+  },
   "type": "module",
   "bin": {
     "add-coder": "bin/add-coder.js"

package/templates/core/scripts/db-ensure.sh

@@ -51,13 +51,14 @@ fi
 
 # ── 容器模式 ──
 COMPOSE_CMD=""
-if [ "$CONTAINER" = "podman" ]; then COMPOSE_CMD="podman-compose"
-elif [ "$CONTAINER" = "docker" ]; then COMPOSE_CMD="docker-compose"
+COMPOSE_FILE=""
+if [ "$CONTAINER" = "podman" ]; then COMPOSE_CMD="podman-compose"; COMPOSE_FILE="podman-compose.add.yml"
+elif [ "$CONTAINER" = "docker" ]; then COMPOSE_CMD="docker-compose"; COMPOSE_FILE="docker-compose.add.yml"
 else echo "未知容器: $CONTAINER"; exit 1
 fi
 
-echo ">>> 启动 PostgreSQL ($COMPOSE_CMD up -d) ..."
-$COMPOSE_CMD up -d || {
+echo ">>> 启动 PostgreSQL ($COMPOSE_CMD -f $COMPOSE_FILE up -d) ..."
+$COMPOSE_CMD -f "$COMPOSE_FILE" up -d || {
   echo "容器启动失败，请检查 $COMPOSE_CMD 是否已安装或端口是否冲突"
   exit 1
 }
@@ -67,7 +68,7 @@ echo ">>> 等待 PostgreSQL 就绪 ..."
 MAX_RETRIES=30
 RETRY=0
 while [ $RETRY -lt $MAX_RETRIES ]; do
-  if $COMPOSE_CMD exec -T postgres pg_isready -U "$DB_USER" > /dev/null 2>&1; then
+  if $COMPOSE_CMD -f "$COMPOSE_FILE" exec -T postgres pg_isready -U "$DB_USER" > /dev/null 2>&1; then
     echo "PostgreSQL 已就绪"; break
   fi
   sleep 1

package/templates/core/templates/standard-plan-template.md

@@ -58,22 +58,48 @@
 ## 四、实施 Task + 依赖图
 
 ```
-Task 1 ──┐
-          │ 可并行
-Task 2 ──┘
-          │
-          ▼
-Task 3 ──┐
-Task 4 ──┤ 可并行
-Task 5 ──┘
-          │
-          ▼
-Task 6 (编译/测试)
+轮次 1: {轮次名称}
+  ├── Task 1.1: {任务描述}（{文件}）
+  └── Task 1.2: {任务描述}（{文件}）
+        │
+        ▼
+轮次 2: {轮次名称}
+  ├── Task 2.1: {任务描述}（{文件}）
+  │     │  {产出 → 被 N.M 消费的标注}
+  │     ▼
+  ├── Task 2.2: {任务描述}（{文件}）
+  │     │  {消费 2.1 的产出，产出 → 被 N.M 消费}
+  │     ▼
+  └── Task 2.3: {任务描述}（{文件}）
+        │
+        ▼
+轮次 3: {轮次名称}
+  ├── Task 3.1: {任务描述}（{文件}）
+  ├── Task 3.2: {任务描述}（{文件}）
+  └── Task 3.3: {任务描述}（{文件}）
 ```
 
-### Step 0: 文档先行
+### 轮次 1: {轮次名称}
 
-### Step N: ...
+| # | 任务 | 文件 | 说明 | 验收 |
+|---|------|------|------|------|
+| 1.1 | {任务名} | `path/to/file.ts` | {做什么} | `tsc --noEmit` |
+| 1.2 | {任务名} | `path/to/file.ts` | {做什么} | `tsc --noEmit` |
+
+### 轮次 2: {轮次名称}
+
+| # | 任务 | 文件 | 说明 | 验收 |
+|---|------|------|------|------|
+| 2.1 | {任务名} | `path/to/file.ts` | {做什么} | `tsc --noEmit` + 单测 |
+| 2.2 | {任务名} | `path/to/file.ts` | {做什么} | `tsc --noEmit` + 单测 |
+
+### 轮次 3: {轮次名称}
+
+| # | 任务 | 文件 | 说明 | 验收 |
+|---|------|------|------|------|
+| 3.1 | {任务名} | `path/to/file.ts` | {做什么} | `tsc --noEmit` |
+| 3.2 | {任务名} | `path/to/file.ts` | {做什么} | 图编译无异常 |
+| 3.3 | {任务名} | `path/to/file.ts` | {做什么} | 端到端通过 |
 
 ---