vault: add GSD methodology deep-dive with examples and zettelkasten insights

Comprehensive GSD analysis: 15 sections covering core philosophy (fresh
context per agent), 5 methodologies (dream extraction, goal-backward
verification, nyquist validation, wave execution, checkpoints), full
command reference (37+), agent system (16 agents with model routing),
config system, git integration, state management, session continuity,
community best practices, pitfalls, framework comparison (GSD vs ECC vs
BMAD vs SpecKit), and 4 detailed practical examples (new project, brownfield,
debugging, quick tasks).

Three zettelkasten notes: context rot vs window isolation tradeoffs,
goal-backward vs forward verification, plans-as-prompts design pattern.

4 - Resources/Everything Claude Code 完整指南.md

@@ -7,7 +7,7 @@ source: "https://github.com/affaan-m/everything-claude-code"
 
 # Everything Claude Code 完整指南
 
-生产级 Claude Code 插件系统，包含 65+ skills、16 agents、40+ commands、hooks 和 rules。v1.8.0，经过 10+ 个月的高强度日常使用演化。
+生产级 Claude Code 插件系统，包含 108 skills、25 agents、57 commands、hooks 和 rules。v1.8.0，经过 10+ 个月的高强度日常使用演化。方法论与最佳实践见 [[Everything Claude Code 方法论与最佳实践]]，按场景速查见 [[Everything Claude Code 用法速查]]。
 
 ## 项目架构
 
@@ -185,7 +185,7 @@ cd everything-claude-code
 ## 16 Agents
 
 | Agent                  | 职责                |
-|-------|------|
+| ---------------------- | ----------------- |
 | `planner`              | 功能实现规划            |
 | `architect`            | 系统设计决策            |
 | `tdd-guide`            | 测试驱动开发            |

4 - Resources/Everything Claude Code 方法论与最佳实践.md

@@ -0,0 +1,930 @@
+---
+created: "2026-03-19 12:00"
+type: resource
+tags: [claude-code, AI-tools, methodology, best-practices, agent-orchestration]
+source: "https://github.com/affaan-m/everything-claude-code"
+---
+
+# Everything Claude Code 方法论与最佳实践
+
+深度分析 ECC 的六大核心方法论、社区最佳实践、常见陷阱与实战例子。组件列表见 [[Everything Claude Code 完整指南]]，按场景速查见 [[Everything Claude Code 用法速查]]。
+
+> **命令命名空间**: 通过插件安装的 ECC，所有命令需要加 `everything-claude-code:` 前缀（如 `/everything-claude-code:plan`）。手动安装到 `~/.claude/commands/` 的可用短名（如 `/plan`）。本文中用 **短名** 书写以保持可读性，实际使用时请加前缀。`/compact` 是 Claude Code 内置命令，无需前缀。
+
+**命令名映射速查**:
+
+| 短名 | 插件全名 |
+|------|---------|
+| `/plan` | `/everything-claude-code:plan` |
+| `/tdd` | `/everything-claude-code:tdd` |
+| `/verify` | `/everything-claude-code:verify` |
+| `/learn` | `/everything-claude-code:learn-eval` |
+| `/evolve` | `/everything-claude-code:evolve` |
+| `/claw` | `/everything-claude-code:claw` |
+| `/e2e` | `/everything-claude-code:e2e` |
+| `/orchestrate` | `/everything-claude-code:plan` (含编排) |
+| `/search-first` | `/everything-claude-code:search-first` |
+| `/eval` | `/everything-claude-code:eval-harness` |
+| `/instinct-export` | `/everything-claude-code:instinct-export` |
+| `/instinct-import` | `/everything-claude-code:instinct-import` |
+| `/instinct-status` | `/everything-claude-code:instinct-status` |
+| `/configure-ecc` | `/everything-claude-code:configure-ecc` |
+| `/security-scan` | `/everything-claude-code:security-scan` |
+| `/compact` | `/compact` (内置，无需前缀) |
+
+---
+
+## 一、六大核心方法论
+
+### 1. Research-First Development（研究优先开发）
+
+在写任何代码之前，必须搜索现有实现。这是 ECC 工作流的**步骤 0（强制）**。
+
+```
+流程:
+1. gh search repos / gh search code → 搜索 GitHub 现有实现
+2. 搜索包注册表（npm, PyPI, crates.io）→ 优先用成熟库
+3. Web 搜索 → 发现先例和最佳实践
+4. 如果找到 80%+ 匹配的开源项目 → Fork/移植，不要从零写
+```
+
+**Exa MCP 用于研究**: 在规划阶段使用 `exa-web-search` MCP 进行更广泛的研究和先例发现。
+
+**例子 — JWT 验证中间件**:
+
+```bash
+# 先搜索，不要直接写
+gh search code "jwt middleware verify" --language=typescript
+# 找到 jose 库 → 直接用，而不是手写 crypto
+npm search jwt verify
+```
+
+### 2. Agent Orchestration（Agent 编排）
+
+将复杂任务分解给专业 Agent，支持串行链和并行执行。
+
+**四种预设工作流**:
+
+| 工作流 | Agent 链 |
+|--------|---------|
+| feature | planner → tdd-guide → code-reviewer → security-reviewer |
+| bugfix | planner → tdd-guide → code-reviewer |
+| refactor | architect → code-reviewer → tdd-guide |
+| security | security-reviewer → code-reviewer → architect |
+
+**自定义链**: `/orchestrate custom "architect,tdd-guide,code-reviewer" "Redesign caching layer"`
+
+**独立检查可并行执行**: 例如 code-reviewer + security-reviewer + architect 可同时运行。
+
+**特殊 Agent**:
+
+| Agent | 特殊能力 |
+|-------|---------|
+| **loop-operator** | 自主循环执行，带失速检测、检查点追踪、重试风暴检测。连续 2 个检查点无进展或成本超预算时自动升级 |
+| **chief-of-staff** | 跨 email/Slack/LINE/Messenger 的通信分级（skip/info/meeting/action），自动草拟回复 |
+| **code-reviewer** | 5 步流程: 收集上下文 → 理解范围 → 读周围代码 → 应用检查清单 → 出报告。信心阈值 >80% 过滤低置信度问题。输出 approve/warning/block 判决 |
+
+**loop-operator 例子**:
+
+```
+# 自主执行迁移任务
+/loop-operator "Migrate all API endpoints from Express to Fastify"
+
+# 内部行为:
+# Checkpoint 1: GET /users migrated ✓
+# Checkpoint 2: POST /users migrated ✓
+# Checkpoint 3: GET /orders migrated ✓
+# ⚠ Stall detected: DELETE /orders failing for 3 attempts
+#   → Scope reduction: skip DELETE /orders, flag for manual review
+#   → Continue with remaining endpoints
+# Checkpoint 4: PUT /orders migrated ✓
+# ...
+# ⚠ Cost drift: 120% of budget → escalate to user
+```
+
+**Agent 间交接文档格式**:
+
+```markdown
+## Handoff: planner → tdd-guide
+### Context
+- 实现 OAuth2 登录流程，使用 passport.js + Google provider
+### Findings
+- 需要新建 3 个文件: auth.controller, auth.service, auth.guard
+### Files Modified
+- (none yet - planning phase)
+### Open Questions
+- 是否需要 refresh token 支持?
+### Recommendations
+- 先写 auth.service 的单元测试
+```
+
+### 3. Hook-Driven Enforcement（Hook 驱动的强制执行）
+
+**核心洞察**: Hook 触发率 100%（确定性），Skill/提示词触发率仅 50-80%（概率性）。因此关键质量控制应通过 Hook 实现，而非依赖提示词。
+
+| Hook 类型 | 触发时机 | 用途举例 |
+|-----------|---------|---------|
+| PreToolUse | 工具执行前 | 开发服务器自启、安全监控 |
+| PostToolUse | 工具执行后 | 自动格式化、类型检查 |
+| PreCompact | 上下文压缩前 | 保存会话状态到 MEMORY.md |
+| SessionStart | 新会话开始 | 加载上次上下文、检测包管理器 |
+| Stop | 每次响应后 | 检查 debug 语句、持久化指标 |
+
+**例子 — hooks.json 配置**:
+
+```json
+{
+  "PostToolUse": [
+    {
+      "matcher": "Write|Edit",
+      "command": "prettier --write $FILEPATH && eslint --fix $FILEPATH",
+      "description": "每次文件编辑后自动格式化和 lint"
+    },
+    {
+      "matcher": "Write|Edit",
+      "command": "npx tsc --noEmit $FILEPATH 2>&1 | head -20",
+      "description": "每次文件编辑后自动类型检查"
+    }
+  ],
+  "PreToolUse": [
+    {
+      "matcher": "Bash",
+      "command": "node hooks/dev-server-check.js",
+      "description": "执行 bash 命令前确保开发服务器在 tmux 中运行"
+    }
+  ],
+  "PreCompact": [
+    {
+      "command": "node hooks/save-session-state.js",
+      "description": "上下文压缩前自动保存会话状态到 MEMORY.md"
+    }
+  ],
+  "Stop": [
+    {
+      "command": "grep -rn 'console.log\\|debugger' src/ --include='*.ts' | head -5",
+      "description": "每次响应后检查是否遗留了 debug 语句"
+    }
+  ]
+}
+```
+
+**运行时控制**（无需编辑文件）:
+
+```bash
+export ECC_HOOK_PROFILE=minimal    # 最小化（减少开销）
+export ECC_HOOK_PROFILE=standard   # 标准
+export ECC_HOOK_PROFILE=strict     # 严格（全部启用）
+export ECC_DISABLED_HOOKS=security-monitor,learning-observer  # 禁用特定 hook
+```
+
+### 4. Continuous Learning（持续学习系统）v2.1
+
+ECC 最独特的创新 — **本能学习系统**。
+
+```
+观察(Hook) → 检测模式(Haiku) → 形成本能(Instinct) → 演化为技能(Skill)
+```
+
+**工作流程**:
+
+1. Hook 捕获每次工具调用到 `observations.jsonl`
+2. Haiku 模型后台观察器检测模式
+3. 模式成为"本能"— 原子化学习行为，带信心分数 (0.3-0.9)
+4. 本能按项目隔离（git remote URL hash）防止跨项目污染
+5. `/evolve` 将相关本能聚类为新的 skill/command/agent
+6. 信心 >= 0.8 且在 2+ 项目中出现 → 从项目级提升到全局级
+
+**例子**:
+
+```bash
+# 会话结束后提取模式
+/learn
+# → [Instinct] confidence=0.7 scope=project
+# → "When editing React components, always check for missing useCallback"
+
+# 多次确认后
+/evolve
+# → 自动生成新 skill: react-performance-patterns
+```
+
+### 5. Strategic Compaction（策略性压缩）
+
+**问题**: 自动压缩在 ~83.5% 上下文使用率时随机触发，可能丢失关键上下文。
+
+**解决方案**: 在逻辑工作节点手动触发 `/compact`。
+
+```
+推荐压缩时机:
+├── 探索阶段完成后
+├── 里程碑完成后
+├── 切换任务类型时（调试 → 开发）
+└── 工具调用次数达到阈值时（Hook 自动提醒）
+```
+
+**例子 — 好的 vs 坏的压缩时机**:
+
+```
+# 坏: 在重构中途自动压缩，丢失函数签名和依赖关系上下文
+# ❌ Auto-compact at 167K tokens mid-refactor
+#    → 压缩后 Claude 忘记了之前分析的接口签名
+#    → 重新读取 5 个文件，浪费 ~20K tokens
+
+# 好: 在完成一个模块后手动压缩
+# Phase 1: Auth module complete ✓
+#   → 所有测试通过，代码已提交
+/compact
+# Phase 2: Start payment module (clean context)
+#   → 只需加载 payment 相关文件，不需要 auth 的上下文
+
+# 好: 从调试切到开发时压缩
+# Debug session: found root cause → fixed → committed
+/compact
+# Feature development: start new feature (清除调试噪音)
+```
+
+禁用自动压缩的配置:
+
+```json
+{
+  "env": {
+    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
+  }
+}
+```
+
+### 6. Verification Loop（验证循环）
+
+6 阶段质量门，建议每 15 分钟或每次重大变更后执行:
+
+```
+/verify → 6 阶段:
+1. Build     → 编译是否通过
+2. Types     → 类型检查
+3. Lint      → 代码规范
+4. Tests     → 测试通过 + 覆盖率 >= 80%
+5. Security  → 安全扫描
+6. Diff      → 变更审查
+→ 输出: 结构化 PASS/FAIL 报告
+```
+
+**例子 — 验证报告输出**:
+
+```
+┌──────────────────────────────────────────┐
+│ Verification Report — 2026-03-19 14:30  │
+├──────────────────────────────────────────┤
+│ 1. Build     ✅ PASS  (3.2s)            │
+│ 2. Types     ✅ PASS  (1.8s, 0 errors)  │
+│ 3. Lint      ⚠️ WARN  (0.9s)            │
+│    → 2 warnings: unused imports          │
+│ 4. Tests     ✅ PASS  (12.4s)           │
+│    → 147/147 passed, 0 failed           │
+│    → Coverage: 84.2% (target: 80%)      │
+│ 5. Security  ✅ PASS  (2.1s)            │
+│    → 0 critical, 0 high, 1 medium       │
+│    → medium: CSP header missing (info)   │
+│ 6. Diff      ✅ PASS                     │
+│    → 4 files changed, +127 -43          │
+│    → No secrets detected in diff         │
+├──────────────────────────────────────────┤
+│ VERDICT: PASS (5/6 green, 1 warning)    │
+│ Ready to commit: YES                     │
+└──────────────────────────────────────────┘
+```
+
+**CLAUDE.md 的特殊角色**: CLAUDE.md 是唯一在上下文压缩后仍被保留的文件内容。因此应将最关键的项目约定写在 CLAUDE.md 中，而非依赖会话记忆。这是"压缩幸存上下文"(compaction-surviving context) 的设计考量。
+
+---
+
+## 二、社区最佳实践
+
+### 渐进式采用路线
+
+| 阶段 | 重点 | 内容 |
+|------|------|------|
+| 第1周 | 基础 | Rules + 基本 Commands (`/plan`, `/tdd`) |
+| 第2周 | 管理 | Session logging + Memory + Strategic compact |
+| 第3周 | 高级 | Agents + Custom skills + Verification loops |
+| 第4周 | 优化 | Token optimization + 并行执行 |
+| 持续 | 积累 | `/learn` 提取模式，构建项目专用 Agent |
+
+### Token/成本优化
+
+```json
+// settings.json 推荐配置
+{
+  "model": "sonnet",
+  "env": {
+    "MAX_THINKING_TOKENS": "10000",
+    "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "50"
+  }
+}
+// → ~60% 成本降低 (Sonnet vs Opus)
+// → ~70% thinking 成本降低
+```
+
+**模型选择策略**:
+
+| 模型 | 场景 | 能力/成本比 |
+|------|------|-----------|
+| Haiku | 简单任务、频繁调用的轻量 Agent | 90% 能力，3x 省钱 |
+| Sonnet | 90% 的日常编码工作 | 最佳性价比 |
+| Opus | 架构决策、首次失败重试、5+ 文件跨度 | 最强推理 |
+
+### MCP 管理
+
+- 启用的 MCP <= 10 个，活跃工具总数 <= 80 个
+- 10+ MCP 时，有效上下文从 200K 降至 ~70K tokens
+- 用 `disabledMcpServers` 禁用不用的
+- 重操作优先用 CLI（如 `gh`）而不是 MCP
+- 使用 `llms.txt` 模式（如 `vercel.com/docs/llms.txt`）代替 MCP 获取文档
+
+### 会话管理
+
+- 命名会话，特别是使用 git worktree 并行工作时
+- 保存会话状态到 `.tmp` 文件
+- 同一问题纠正 Claude 超过 2 次 → 开新会话（失败方法污染上下文）
+- 新项目用双实例模式：实例 1 做脚手架，实例 2 做研究，合并后实施
+
+---
+
+## 三、常见陷阱
+
+| 陷阱 | 影响 | 解决方案 |
+|------|------|---------|
+| 同时启用所有 MCP | 上下文降至 ~70K | 保持 <= 10 个 |
+| 跳过 Plan 阶段 | 需求不清，大量返工 | 始终先 `/plan` |
+| 过多并行实例 | 心智负担 > 生产力 | 按需添加 |
+| 文件超 500 行 | 重读消耗大量 Token | 拆分为小文件 |
+| 不提取可复用模式 | 每次重复设置 | 用 `/learn` 固化 |
+| 忽略上下文健康 | 模型性能下降、幻觉 | 监控使用率，里程碑处压缩 |
+| 死代码累积 | Token 浪费 | 定期用 refactor-cleaner |
+| 忽略 Agent 质量门 | 遗漏回归和安全问题 | 让 Agent 触发运行 |
+
+---
+
+## 四、ECC 独特创新
+
+| 创新 | 说明 |
+|------|------|
+| **Hookify** | 对话式 Hook 创建 — 描述需求自动生成 Hook 配置 |
+| **pass@k / pass^k** | 形式化验证 Agent 任务成功率的度量 |
+| **Sandboxed Subagents** | 按 Agent 限制工具（planner 只读，tdd-guide 可写代码+测试）|
+| **Cascade Method** | 多实例管理用于并行开发 |
+| **AgentShield** | 安全审计（1282 测试，98% 覆盖率，14 种密钥模式检测）|
+| **Plankton** | 写入时代码质量工具（20+ linter + Claude 子进程修复）|
+| **NanoClaw v2** | 模型路由、技能热加载、会话分支/搜索/导出 |
+| **Continuous Learning v2.1** | Hook 观察 → 模式检测 → 本能形成 → 技能演化 |
+
+### 各创新功能详细例子
+
+**Hookify — 对话式创建 Hook**:
+
+```
+用户: "每次我编辑 .py 文件后自动运行 black 格式化"
+
+# Hookify 自动生成:
+{
+  "PostToolUse": [{
+    "matcher": "Write|Edit",
+    "command": "if [[ \"$FILEPATH\" == *.py ]]; then black \"$FILEPATH\"; fi",
+    "description": "Auto-format Python files with black"
+  }]
+}
+# → 写入 hooks/hooks.json，立即生效
+```
+
+**Sandboxed Subagents — 工具限制**:
+
+```yaml
+# agents/planner.md frontmatter
+---
+name: planner
+model: opus
+tools: [Read, Glob, Grep, WebSearch, WebFetch]  # 只读，不能写代码
+---
+
+# agents/tdd-guide.md frontmatter
+---
+name: tdd-guide
+model: sonnet
+tools: [Read, Write, Edit, Bash, Glob, Grep]  # 可以写代码和运行测试
+---
+
+# agents/security-reviewer.md frontmatter
+---
+name: security-reviewer
+tools: [Read, Grep, Glob, Bash]  # 可以读和扫描，不能修改
+---
+```
+
+**Cascade Method — 多实例并行开发**:
+
+```bash
+# 实例 1: 主开发（feature branch）
+claude --session "auth-feature" --worktree feature/auth
+# → 在独立 worktree 中开发 auth 模块
+
+# 实例 2: 并行研究
+claude --session "auth-research"
+# → 研究 OAuth2 最佳实践、比较库
+# → 输出研究报告到 .tmp 文件
+
+# 实例 3: 并行测试基础设施
+claude --session "test-infra" --worktree feature/test-setup
+# → 搭建测试环境、mock 服务器
+
+# 合并时:
+# 实例 1 读取实例 2 的研究结果
+# 实例 1 合并实例 3 的测试基础设施
+```
+
+**Tmux/Worktree 编排**:
+
+```json
+// orchestration-plan.json
+{
+  "workers": [
+    {
+      "name": "api-worker",
+      "branch": "feature/api-endpoints",
+      "task": "Implement REST API endpoints for user CRUD",
+      "seedPaths": ["src/types/", "src/config/"]
+    },
+    {
+      "name": "db-worker",
+      "branch": "feature/db-schema",
+      "task": "Create database migrations and repository layer",
+      "seedPaths": ["src/types/", "prisma/"]
+    },
+    {
+      "name": "test-worker",
+      "branch": "feature/e2e-tests",
+      "task": "Write E2E tests for user flows",
+      "seedPaths": ["src/types/", "tests/fixtures/"]
+    }
+  ]
+}
+```
+
+```bash
+# 启动编排
+node scripts/orchestrate-worktrees.js orchestration-plan.json
+# → 创建 3 个 git worktree
+# → 每个在独立 tmux pane 中运行 Claude
+# → seedPaths 从主分支复制共享文件到各 worktree
+
+# 查看状态
+node scripts/orchestration-status.js
+# → api-worker: 3/5 tasks done, branch: feature/api-endpoints
+# → db-worker: 5/5 tasks done ✓, branch: feature/db-schema
+# → test-worker: 2/4 tasks done, branch: feature/e2e-tests
+```
+
+**AgentShield — 安全扫描**:
+
+```bash
+npx ecc-agentshield scan ~/.claude/
+
+# 输出:
+# ┌─────────────────────────────────────┐
+# │ AgentShield Security Report         │
+# │ Grade: B (82/100)                   │
+# ├─────────────────────────────────────┤
+# │ CRITICAL (0)                        │
+# │ HIGH (1)                            │
+# │   → settings.json: acceptEdits      │
+# │     without scope restriction       │
+# │ MEDIUM (3)                          │
+# │   → CLAUDE.md: no input validation  │
+# │     guidance for MCP tool results   │
+# │   → hooks/: PreToolUse hook runs    │
+# │     arbitrary shell without sandbox │
+# │   → agents/: planner agent has      │
+# │     Write tool (should be read-only)│
+# │ LOW (2)                             │
+# │   → 2 MCP servers without auth      │
+# │ SECRET PATTERNS: 0 found            │
+# └─────────────────────────────────────┘
+```
+
+**Plankton — 写入时代码质量工具**:
+
+三阶段架构: 自动格式化(静默) → 收集违规(JSON) → 委派修复(Claude 子进程)。
+
+```
+# 开发者编辑文件 → PostToolUse Hook 触发 Plankton
+
+# Phase 1: Auto-format (静默，用户无感知)
+prettier --write src/api/users.ts
+eslint --fix src/api/users.ts
+
+# Phase 2: Collect violations (JSON 格式)
+{
+  "file": "src/api/users.ts",
+  "violations": [
+    {"rule": "no-any", "line": 23, "severity": "error"},
+    {"rule": "prefer-const", "line": 45, "severity": "warn"},
+    {"rule": "complexity", "line": 67, "severity": "error", "detail": "cyclomatic complexity 12 > max 10"}
+  ]
+}
+
+# Phase 3: Delegate fixes (Claude 子进程)
+# → 主 Agent 不处理，由 Plankton 生成的子进程自动修复
+# → 子进程只针对特定 violation，最小化改动
+# → 20+ linter 支持: ESLint, Prettier, stylelint, markdownlint...
+```
+
+**NanoClaw v2 — Agent REPL**:
+
+```bash
+# 启动 NanoClaw REPL
+/claw
+
+# 功能:
+> /model sonnet          # 切换模型（不重启会话）
+> /skill load tdd        # 热加载技能（不重启会话）
+> /branch auth-feature   # 会话分支（保留当前上下文创建分支副本）
+> /search "payment"      # 搜索历史会话
+> /export session.json   # 导出当前会话
+> /compact               # 手动压缩
+> /metrics               # 查看 token 使用、成本、工具调用统计
+
+# 模型路由: NanoClaw 根据任务复杂度自动选择模型
+# → 简单查询 → Haiku
+# → 代码生成 → Sonnet
+# → 架构决策 → Opus
+```
+
+**pass@k / pass^k — Agent 成功率度量**:
+
+```
+# pass@k: 同一任务运行 k 次，至少 1 次通过的概率
+# 类似 LLM 评估中的 pass@1, pass@5 指标
+
+# 例子: 评估 tdd-guide agent 生成测试的能力
+/eval pass@5 "Generate unit tests for UserService.createUser()"
+# → Run 1: PASS (覆盖率 85%)
+# → Run 2: PASS (覆盖率 82%)
+# → Run 3: FAIL (漏测 edge case)
+# → Run 4: PASS (覆盖率 88%)
+# → Run 5: PASS (覆盖率 84%)
+# → pass@5 = 4/5 = 80%
+# → pass@1 ≈ 80% (单次通过概率)
+
+# pass^k: 连续 k 次全部通过的概率（更严格）
+# → pass^5 = 0.8^5 ≈ 33% (连续5次全通过)
+# 用于评估 Agent 在 CI/CD 中的可靠性
+```
+
+**本能的导入/导出/跨项目提升**:
+
+```bash
+# 导出当前项目的本能
+/instinct-export
+# → 输出: instincts-project-abc123.json
+# → 包含所有 confidence >= 0.5 的本能
+
+# 导入队友的本能
+/instinct-import instincts-from-alice.json
+# → 导入 12 个本能，初始 confidence 降为 0.5（需要在本项目中重新验证）
+
+# 查看本能状态
+/instinct-status
+# → [0.9] GLOBAL "Always run prettier on .ts files after edit"
+# → [0.8] GLOBAL "Use zod for API input validation" (2 projects confirmed)
+# → [0.7] PROJECT "React components: check useCallback on handlers"
+# → [0.5] PROJECT "Imported: Use testcontainers for DB tests" (unverified)
+
+# 提升规则:
+# → 项目本能 confidence >= 0.8 + 出现在 2+ 项目
+# → 自动提升为 GLOBAL 本能
+# → GLOBAL 本能可通过 /evolve 演化为正式 Skill
+```
+
+**双实例模式 — 新项目启动**:
+
+```
+# 实例 1: 脚手架
+claude --session "scaffold"
+> /plan "Create a Next.js 15 app with auth, payments, and admin panel"
+> # → 生成项目结构、配置文件、基础路由
+> # → 提交到 main 分支
+
+# 实例 2: 研究（同时进行）
+claude --session "research"
+> "Research: Next.js 15 app router best practices for auth"
+> "Research: Stripe integration patterns for Next.js"
+> "Research: Admin panel libraries compatible with Next.js 15"
+> # → 输出研究笔记到 .claude/research/
+
+# 合并洞察:
+# 回到实例 1，读取研究结果
+> "Read .claude/research/ and apply findings to current scaffold"
+> # → 根据研究结果调整架构决策
+```
+
+---
+
+## 五、实战完整例子
+
+### 例子: 从零开发 REST API 端点
+
+```
+# Step 0: Research（研究优先）
+/search-first "express rate limiting middleware"
+→ 发现 express-rate-limit 库 (26K stars, 维护活跃)
+
+# Step 1: Plan（规划）
+/plan "Add POST /api/users endpoint with validation and rate limiting"
+→ planner agent (Opus):
+  - 架构: Controller → Service → Repository 分层
+  - 依赖: express-rate-limit, zod, bcrypt
+  - 风险: 并发注册的竞态条件
+→ 等待用户确认
+
+# Step 2: TDD（测试驱动）
+/tdd
+→ tdd-guide agent:
+  - users.controller.test.ts (RED → GREEN)
+  - users.service.test.ts (RED → GREEN)
+  - users.repository.test.ts (RED → GREEN)
+→ 覆盖率 82% ✓
+
+# Step 3: Review（代码审查，自动触发）
+→ code-reviewer agent:
+  - CRITICAL: 无
+  - HIGH: "bcrypt rounds should be configurable" → 修复
+  - MEDIUM: "Consider adding request ID" → 记录
+
+# Step 4: Security（安全检查，自动触发）
+→ security-reviewer agent:
+  - ✓ 参数化查询、输入验证、速率限制
+  - ⚠ "Add helmet middleware" → 修复
+
+# Step 5: Verify（验证循环）
+/verify → Build ✓ | Types ✓ | Lint ✓ | Tests ✓ (82%) | Security ✓ | Diff ✓
+
+# Step 6: Learn（提取模式）
+/learn
+→ [Instinct] "Express API 端点始终加: rate limiting + zod + helmet"
+→ confidence=0.6, scope=project
+```
+
+### 例子: Bug 修复工作流
+
+```
+# 用户报告: "登录后偶尔跳转到 404 页面"
+
+# Step 1: 研究（自动触发 planner）
+/orchestrate bugfix "Login redirect sometimes lands on 404"
+
+# → planner agent 分析:
+#   - 可能原因: race condition in auth callback
+#   - 相关文件: auth.callback.ts, router.middleware.ts
+#   - 重现条件: 快速连续点击登录按钮
+
+# Step 2: TDD（先写复现测试）
+# → tdd-guide agent:
+describe('Auth callback race condition', () => {
+  it('should not redirect to 404 when callback fires twice', async () => {
+    // 模拟快速连续两次 callback
+    const result1 = authCallback(mockReq, mockRes);
+    const result2 = authCallback(mockReq, mockRes);
+    await Promise.all([result1, result2]);
+    expect(mockRes.redirect).toHaveBeenCalledWith('/dashboard');
+    expect(mockRes.redirect).not.toHaveBeenCalledWith('/404');
+  });
+});
+# → 测试 RED ✓ (确认 bug 存在)
+
+# Step 3: 修复
+# → 添加 idempotency guard:
+#   if (session.redirectHandled) return;
+#   session.redirectHandled = true;
+# → 测试 GREEN ✓
+
+# Step 4: Review
+# → code-reviewer agent:
+#   - 确认修复正确
+#   - 建议: "Add comment explaining the race condition for future maintainers"
+```
+
+### 例子: 安全审计工作流
+
+```
+# 代码审计请求
+/orchestrate security "Audit payment processing module"
+
+# → security-reviewer agent 扫描:
+# ┌────────────────────────────────────────────┐
+# │ Security Audit: src/payments/              │
+# ├────────────────────────────────────────────┤
+# │ CRITICAL (1):                              │
+# │   payment.service.ts:45                    │
+# │   → Stripe secret key in string literal    │
+# │   → FIX: Move to env var STRIPE_SECRET_KEY │
+# │                                            │
+# │ HIGH (2):                                  │
+# │   webhook.controller.ts:12                 │
+# │   → Missing Stripe signature verification  │
+# │   → FIX: Add stripe.webhooks.construct()   │
+# │                                            │
+# │   refund.service.ts:78                     │
+# │   → No rate limiting on refund endpoint    │
+# │   → FIX: Add express-rate-limit (5/min)    │
+# │                                            │
+# │ MEDIUM (3):                                │
+# │   → Amount not validated as positive int   │
+# │   → Error messages expose internal IDs     │
+# │   → Missing audit log for payment actions  │
+# └────────────────────────────────────────────┘
+
+# → code-reviewer agent 确认修复:
+#   - CRITICAL: Stripe key moved to .env ✓
+#   - HIGH: Webhook signature verification added ✓
+#   - HIGH: Rate limiting configured ✓
+
+# → architect agent 建议:
+#   - "Consider adding idempotency keys for payment requests"
+#   - "Add circuit breaker for Stripe API calls"
+```
+
+### 例子: 重构工作流
+
+```
+/orchestrate refactor "Split monolithic UserService into domain services"
+
+# → architect agent 分析:
+# UserService (1200 lines) 应拆分为:
+#   - AuthService (认证/授权, ~200 lines)
+#   - ProfileService (用户资料, ~150 lines)
+#   - NotificationService (通知偏好, ~100 lines)
+#   - SubscriptionService (订阅管理, ~180 lines)
+# 依赖图:
+#   AuthService ← ProfileService
+#   NotificationService ← SubscriptionService
+#   (无循环依赖 ✓)
+
+# → code-reviewer agent 审查拆分:
+#   - 接口一致性 ✓
+#   - 依赖注入正确 ✓
+#   - 无遗漏的 public method ✓
+
+# → tdd-guide agent 验证:
+#   - 原有 45 个测试全部通过 ✓
+#   - 新增 12 个测试覆盖拆分后的交互 ✓
+#   - 覆盖率: 原 78% → 现 85% ✓
+```
+
+---
+
+## 六、扩展与自定义
+
+### Skill 文件格式
+
+```markdown
+<!-- skills/my-skill/SKILL.md -->
+---
+name: my-custom-skill
+description: "Domain-specific workflow for X"
+origin: custom
+version: 1.0.0
+---
+
+## When to Activate
+- 当用户请求 X 相关操作时
+- 当检测到 .config/x.json 文件存在时
+
+## Workflow
+1. Step one...
+2. Step two...
+
+## Configuration
+- `PARAM_A`: 描述 (默认值: xxx)
+
+## Output Format
+- 预期输出结构...
+```
+
+每个 Skill 可选配 `agents/openai.yaml` 实现跨平台兼容（Codex/OpenCode）。
+
+### Command 文件格式
+
+```markdown
+<!-- commands/my-command.md -->
+---
+description: "Short description shown in /help"
+---
+
+执行以下步骤:
+1. ...
+2. ...
+3. 调用 `my-custom-skill` 技能
+```
+
+### Rule 分层覆盖
+
+```
+rules/
+├── common/coding-style.md      # 通用: "优先不可变"
+├── golang/coding-style.md      # Go 覆盖: "惯用 Go 使用指针接收器进行结构体变异"
+├── python/coding-style.md      # Python 覆盖: "使用 dataclasses(frozen=True)"
+└── typescript/coding-style.md  # TS 覆盖: "使用 Readonly<T> 和 as const"
+```
+
+**优先级**: 语言特定规则 > 通用规则（类似 CSS specificity）。
+
+语言特定文件的开头模式:
+
+```markdown
+> This file extends [common/coding-style.md](../common/coding-style.md)
+> with Go-specific content.
+```
+
+### 安装配置文件
+
+| 配置文件 | 包含组件 | 适用场景 |
+|---------|---------|---------|
+| **core** | Rules + 基础 Commands | 轻量使用、小项目 |
+| **developer** | core + Agents + TDD/Review Skills | 日常开发 |
+| **security** | core + Security Agent + AgentShield | 安全审计 |
+| **full** | 全部 108 Skills + 25 Agents + 57 Commands | 重度使用 |
+
+```bash
+# 交互式安装（推荐）
+/configure-ecc
+# → 引导选择配置文件
+# → 选择安装到 user-level (~/.claude/) 或 project-level (.claude/)
+# → 验证路径和兼容性
+
+# 或通过插件市场
+claude plugin marketplace add affaan-m/everything-claude-code
+```
+
+### 跨平台适配
+
+ECC 通过适配层支持多个 AI 编码工具:
+
+| 平台 | 适配方式 | 配置位置 |
+|------|---------|---------|
+| **Claude Code** | 原生支持 | `agents/`, `skills/`, `hooks/` |
+| **Cursor** | Hook 桥接 | `.cursor/hooks/` → 映射到 Claude Code Hook 脚本 |
+| **Codex (OpenAI)** | Agent YAML | `.codex/` + `skills/*/agents/openai.yaml` |
+| **OpenCode** | 配置映射 | `.opencode/` |
+
+Cursor 适配器的 DRY 设计: Cursor 的 15 个 Hook 事件映射回 Claude Code 的 Hook 脚本，避免重复维护。
+
+```
+.cursor/hooks/
+├── on-file-save.sh → hooks/post-tool-use-format.sh
+├── on-build.sh     → hooks/pre-tool-use-build-check.sh
+└── ...
+```
+
+---
+
+## 七、包管理器检测
+
+ECC 自动检测项目使用的包管理器，遵循 6 级优先级:
+
+```
+1. 环境变量 (ECC_PACKAGE_MANAGER=pnpm)
+2. 项目配置 (.npmrc 中的 package-manager 字段)
+3. package.json 的 packageManager 字段
+4. Lock 文件检测 (pnpm-lock.yaml → pnpm, yarn.lock → yarn, 等)
+5. 全局配置 (~/.claude/settings.json)
+6. 回退默认值 (npm)
+```
+
+---
+
+## 八、与其他方案对比
+
+| 维度 | ECC | 最小 CLAUDE.md | claude-code-ultimate-guide | 自建配置 |
+|------|-----|---------------|---------------------------|---------|
+| 定位 | 生产级框架 | 轻量约定 | 教学材料 | 定制化 |
+| 复杂度 | 高 | 低 | 中 | 可控 |
+| Token 开销 | 较大 | 最小 | 无 | 可控 |
+| 学习曲线 | 陡峭 | 平缓 | 教程式 | 渐进 |
+| 自动化 | 全面（Hook 驱动）| 手动 | 无 | 按需 |
+| 学习系统 | 完整本能系统 | 无 | 无 | 无/部分 |
+| 适用场景 | 重度日常使用 | 简单项目 | 入门学习 | 特定需求 |
+
+---
+
+## 九、关键数据
+
+- GitHub Stars: 50K+（9天内达 31.9K）
+- 社区评分: 5/5 CRITICAL（claude-code-ultimate-guide 评价）
+- 作者实战: 10+ 个月日常高强度使用
+- 跨平台: Claude Code, Cursor, Codex, OpenCode
+- 许可: MIT
+
+---
+
+## Related
+
+- [[Everything Claude Code 完整指南]]
+- [[Everything Claude Code 用法速查]]
+- [[GSD 方法论与最佳实践]]

4 - Resources/Everything Claude Code 用法速查.md

@@ -7,7 +7,9 @@ source: "https://github.com/affaan-m/everything-claude-code"
 
 # Everything Claude Code 用法速查
 
-按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。
+按使用场景分类的快速参考手册。组件完整列表见 [[Everything Claude Code 完整指南]]。方法论深度分析见 [[Everything Claude Code 方法论与最佳实践]]。
+
+> **命名空间**: 通过插件安装的 ECC，命令需加 `everything-claude-code:` 前缀。本文用短名书写，实际使用时如 `/plan` → `/everything-claude-code:plan`。完整映射表见 [[Everything Claude Code 方法论与最佳实践#命令名映射速查]]。
 
 ---
 
@@ -16,7 +18,7 @@ source: "https://github.com/affaan-m/everything-claude-code"
 ### 1. 规划阶段
 
 | 场景      | 用什么                        | 怎么用                                |
-|------|--------|--------|
+| ------- | -------------------------- | ---------------------------------- |
 | 复杂功能设计  | `/plan` 命令 → planner agent | 输入需求，生成分阶段实施计划，等用户确认后再动手           |
 | 系统架构决策  | architect agent            | 自动启用，做 trade-off 分析、模式推荐、可扩展性评审    |
 | 多模型并行规划 | `/multi-plan`              | Claude + Codex + Gemini 并行出方案，对比择优 |
@@ -44,7 +46,7 @@ source: "https://github.com/affaan-m/everything-claude-code"
 ### 4. 语言专用审查
 
 | 语言         | 命令                      | 检查内容                                     |
-|------|------|----------|
+| ---------- | ----------------------- | ---------------------------------------- |
 | Python     | `/python-review`        | PEP 8、类型提示、安全、ruff/mypy/pylint           |
 | Go         | `/go-review`            | 惯用 Go 模式、并发安全、error handling、staticcheck |
 | Go 测试      | `/go-test`              | 表驱动测试、覆盖率分析                              |

4 - Resources/GSD 方法论与最佳实践.md

@@ -0,0 +1,906 @@
+---
+created: "2026-03-20 10:00"
+type: resource
+tags: [claude-code, AI-tools, methodology, best-practices, project-management, gsd]
+source: "https://github.com/gsd-build/get-shit-done"
+---
+
+# GSD (Get Shit Done) 方法论与最佳实践
+
+GSD 是一个面向 AI 编码 Agent 的**元提示、上下文工程和规格驱动开发框架**。36K+ GitHub stars，支持 Claude Code、OpenCode、Gemini CLI、Codex、Copilot、Antigravity 六种运行时。
+
+> **命名空间**: 所有 GSD 命令以 `gsd:` 为前缀（如 `/gsd:plan-phase`），无需额外插件命名空间。
+
+---
+
+## 一、核心设计哲学
+
+**"复杂性在系统中，不在你的工作流中。"** GSD 将上下文工程、XML 提示格式化、子 Agent 编排和状态管理隐藏在几个简单命令后面。
+
+**五大设计原则**:
+
+| 原则 | 说明 |
+|------|------|
+| **Fresh Context Per Agent** | 每个子 Agent 获得全新 200K token 上下文窗口，消除"上下文腐烂" |
+| **Thin Orchestrators** | 工作流文件只做加载上下文、生成 Agent、收集结果、路由下一步 |
+| **File-Based State** | 所有状态存在 `.planning/` 目录下的 Markdown 和 JSON 中，无数据库 |
+| **Absent = Enabled** | 配置默认为 true，用户显式禁用而非启用 |
+| **Defense in Depth** | 计划执行前验证、每任务原子提交、执行后验证、UAT 人类门控 |
+
+**上下文腐烂模型**:
+
+```
+Claude 质量随上下文使用率变化:
+  0-30%  → 峰值质量（GSD 编排器保持在此范围）
+  30-50% → 良好质量
+  50-70% → 开始赶工，质量下降
+  70%+   → 幻觉风险显著增加
+```
+
+GSD 的核心竞争力: 为每个任务生成全新 200K 上下文窗口，从根本上避免上下文腐烂。
+
+---
+
+## 二、项目层级结构
+
+```
+Project (项目)
+  └── Milestone (里程碑 v1.0, v2.0...)
+       └── Phase (阶段 1, 2, 3...)
+            └── Plan (计划 A, B, C...)
+                 └── Task (任务 1, 2, 3...)
+```
+
+**核心文档**:
+
+| 文档 | 位置 | 用途 |
+|------|------|------|
+| **PROJECT.md** | `.planning/` | 项目愿景、约束、关键决策 |
+| **REQUIREMENTS.md** | `.planning/` | 带唯一 ID (REQ-XX) 的需求列表 |
+| **ROADMAP.md** | `.planning/` | 阶段分解 + 状态追踪 + 需求可追溯 |
+| **STATE.md** | `.planning/` | 活跃记忆: 当前位置、决策、阻塞、指标（<100行）|
+| **CONTEXT.md** | 每阶段目录 | 用户在 discuss-phase 中做的决策 |
+| **RESEARCH.md** | 每阶段目录 | 领域研究发现 |
+| **PLAN.md** | 每计划目录 | XML 结构的原子任务列表（这是提示词，不是文档）|
+| **SUMMARY.md** | 每计划目录 | 执行结果、文件变更、偏差记录 |
+| **VERIFICATION.md** | 每阶段目录 | 目标回溯验证报告 |
+| **config.json** | `.planning/` | 工作流配置（模式、粒度、模型、git 等）|
+
+---
+
+## 三、核心工作流
+
+### 完整生命周期
+
+```
+/gsd:new-project              → 提问 → 研究 → 需求 → 路线图
+  │
+  ▼ (对每个阶段)
+/gsd:discuss-phase N          → 捕获用户偏好 → CONTEXT.md
+/gsd:plan-phase N             → 研究 → 计划 → 计划检查循环 → PLAN.md
+/gsd:execute-phase N          → 波浪式并行执行 → 原子提交
+/gsd:verify-work N            → 目标回溯验证 → VERIFICATION.md
+/gsd:validate-phase N         → Nyquist 验证 → 补充测试
+/gsd:ship N                   → 创建 PR
+  │
+  ▼ (所有阶段完成后)
+/gsd:audit-milestone          → 审计里程碑完成度
+/gsd:complete-milestone       → 归档、打 tag
+/gsd:new-milestone            → 开始下一个版本
+```
+
+**自动推进**: `/gsd:next` 自动检测项目状态，运行下一个逻辑步骤。
+
+**快速模式**: `/gsd:quick` 对临时任务提供 GSD 保证（原子提交、状态追踪）但跳过完整规划。可组合标志: `--discuss`, `--research`, `--full`。
+
+### 例子 — 完整新项目流程
+
+```bash
+# Step 1: 初始化项目
+/gsd:new-project
+# Claude 以协作思考方式提问（不是需求收集）:
+#   "你在构建什么？解决什么问题？"
+#   "目标用户是谁？'完成'长什么样？"
+#   "有技术栈偏好吗？"
+# → 4 个研究 Agent 并行启动:
+#   Researcher 1: 技术栈调研
+#   Researcher 2: 功能特性调研
+#   Researcher 3: 架构模式调研
+#   Researcher 4: 常见陷阱调研
+# → 合成器汇总为 SUMMARY.md
+# → 生成 PROJECT.md, REQUIREMENTS.md, ROADMAP.md
+
+# Step 2: 讨论第一阶段
+/gsd:discuss-phase 1
+# Claude 提问直到理解你的偏好:
+#   "数据库用 PostgreSQL 还是 SQLite？"
+#   "认证用 JWT 还是 Session？"
+#   "需要邮件验证吗？"
+# → 你的决策锁定在 CONTEXT.md 中（后续不可变）
+
+# Step 3: 规划
+/gsd:plan-phase 1
+# → gsd-phase-researcher 调研实现方案 → RESEARCH.md
+# → gsd-planner 生成 2-3 个 PLAN.md（每个 ≤50% 上下文预算）
+# → gsd-plan-checker 目标回溯验证（最多 3 次迭代）:
+#     "这些计划能实现阶段目标吗？"
+#     "CONTEXT.md 中的决策都被尊重了吗？"
+#     "每个 REQ-XX 都有对应任务吗？"
+
+# Step 4: 执行
+/gsd:execute-phase 1
+# → 按依赖分组为波浪（wave）
+# → Wave 1: Plan A + Plan B（独立，并行执行）
+# → Wave 2: Plan C（依赖 A+B，等待完成后执行）
+# → 每个任务: 原子 git 提交
+# → 每个 executor 获得全新 200K 上下文
+
+# Step 5: 验证
+/gsd:verify-work 1
+# → gsd-verifier 不信任 SUMMARY.md 的声称
+# → 检查实际代码:
+#     Exists: 文件在预期路径？
+#     Substantive: 是真实实现还是桩代码？
+#     Wired: 与系统其他部分连接了吗？
+# → 生成 VERIFICATION.md（通过/差距/建议）
+
+# Step 6: Nyquist 验证
+/gsd:validate-phase 1
+# → 扫描每个 REQ-XX 是否有对应自动化测试
+# → COVERED / PARTIAL / MISSING 分类
+# → gsd-nyquist-auditor 生成缺失的测试（只改测试文件，不改实现）
+
+# Step 7: 发布
+/gsd:ship 1
+# → 创建 PR，附带验证报告
+```
+
+---
+
+## 四、Agent 系统 (16 个)
+
+每个 Agent 是 Markdown 文件 + YAML frontmatter（name, description, tools, color）。由瘦编排器生成，每个获得全新上下文窗口。
+
+### Agent 清单
+
+| Agent | 角色 | 并行度 |
+|-------|------|--------|
+| **gsd-project-researcher** | 项目级领域研究 | 4x 并行（栈/功能/架构/陷阱）|
+| **gsd-research-synthesizer** | 合并 4 个研究输出为 SUMMARY.md | 在研究者之后串行 |
+| **gsd-roadmapper** | 从需求创建阶段化路线图 | 串行 |
+| **gsd-phase-researcher** | 调研特定阶段的实现方案 | 串行 |
+| **gsd-planner** | 创建 PLAN.md（XML 任务结构）| 串行 |
+| **gsd-plan-checker** | 执行前目标回溯验证（最多 3 次迭代）| 串行循环 |
+| **gsd-executor** | 执行 PLAN.md，每任务原子提交 | 波浪内并行 |
+| **gsd-verifier** | 执行后目标回溯验证 | 串行 |
+| **gsd-debugger** | 科学方法 Bug 调查，跨会话持久状态 | 串行/交互 |
+| **gsd-codebase-mapper** | 棕地分析 | 4x 并行（技术/架构/质量/关注点）|
+| **gsd-integration-checker** | 跨阶段集成验证 | 串行 |
+| **gsd-nyquist-auditor** | 为验证缺口生成测试，从不修改实现 | 串行 |
+| **gsd-ui-researcher** | 生成 UI-SPEC.md 设计契约 | 串行 |
+| **gsd-ui-checker** | 验证 UI-SPEC 完整性（6 维度）| 串行 |
+| **gsd-ui-auditor** | 6 支柱视觉审计 | 串行 |
+| **gsd-user-profiler** | 8 维度行为分析 | 串行 |
+
+**关键模式**: 每个 Agent 接收 `<files_to_read>` 块，**必须**在任何操作前读取所有列出的文件。这是主要的上下文注入机制。
+
+### 模型路由
+
+| Agent | quality | balanced | budget |
+|-------|---------|----------|--------|
+| gsd-planner | Opus | Opus | Sonnet |
+| gsd-executor | Opus | Sonnet | Sonnet |
+| gsd-verifier | Sonnet | Sonnet | Haiku |
+| gsd-debugger | Opus | Sonnet | Sonnet |
+| gsd-nyquist-auditor | Sonnet | Sonnet | Haiku |
+| gsd-plan-checker | Sonnet | Sonnet | Haiku |
+| gsd-phase-researcher | Sonnet | Sonnet | Haiku |
+
+`inherit` 配置文件用于非 Anthropic 供应商（OpenRouter、本地模型）。
+
+### 例子 — Plan 作为 Prompt
+
+PLAN.md 不是文档——它**就是** prompt。XML 结构直接指导 executor:
+
+```xml
+<!-- .planning/phases/01-auth/plans/A/PLAN.md -->
+---
+phase: 1
+plan: A
+goal: "Implement user registration with email verification"
+requirements: [REQ-01, REQ-02]
+depends_on: []
+---
+
+<task id="1" type="auto">
+  <action>
+    Create User model with fields: id, email, passwordHash, verified, createdAt.
+    Use Prisma schema. Add unique constraint on email.
+  </action>
+  <verify>
+    Run: npx prisma validate
+    Check: prisma/schema.prisma contains User model with all fields
+  </verify>
+  <done>prisma/schema.prisma updated with User model</done>
+</task>
+
+<task id="2" type="auto" depends="1">
+  <action>
+    Create POST /api/auth/register endpoint.
+    Validate input with zod schema (email format, password min 8 chars).
+    Hash password with bcrypt (12 rounds).
+    Send verification email via SendGrid.
+    Return 201 with user ID.
+  </action>
+  <verify>
+    Run: npm test -- --grep "register"
+    Check: tests pass, endpoint returns 201 for valid input
+  </verify>
+  <done>src/routes/auth/register.ts created and tested</done>
+</task>
+
+<task id="3" type="human-verify" depends="2">
+  <action>
+    User confirms: registration endpoint works via manual test
+  </action>
+  <done>User verified registration flow works end-to-end</done>
+</task>
+```
+
+---
+
+## 五、五大核心方法论
+
+### 1. Dream Extraction（梦想提取）
+
+项目初始化使用"协作思考"而非"需求收集"。
+
+```
+传统方式:
+  产品经理: "请列出你的需求"
+  开发者: "我需要用户认证、支付..."
+
+GSD 方式:
+  Claude: "你在构建什么？解决什么真实问题？"
+  开发者: "我想让自由职业者更容易管理发票..."
+  Claude: "当你说'更容易'——现在最痛苦的部分是什么？"
+  开发者: "手动追踪哪些发票已付款、哪些逾期"
+  Claude: "所以核心价值是自动追踪支付状态。
+           '完成'对你来说长什么样？"
+  → 从模糊想法中提取出具体的、可执行的需求
+```
+
+**原则**: "你是思考伙伴，不是采访者。" 系统探测模糊性、让抽象变具体。
+
+### 2. Goal-Backward Verification（目标回溯验证）
+
+GSD 的核心验证哲学: **"任务完成 ≠ 目标达成"**。从应该交付的东西开始，反向验证它是否真实存在。
+
+**四级验证**:
+
+```
+Level 1 - Exists:     文件在预期路径？
+Level 2 - Substantive: 是真实实现还是桩代码/占位符？
+Level 3 - Wired:      与系统其他部分连接了？（import 被使用、API 被调用、数据流通）
+Level 4 - Functional:  实际调用时能工作？（通常需要人类验证）
+```
+
+**桩代码检测模式**:
+
+```
+React 组件:
+  ❌ return <div>TODO</div>
+  ❌ return <Placeholder />
+  ✓ return <form onSubmit={handleSubmit}>...</form>
+
+API 路由:
+  ❌ res.json({ message: "not implemented" })
+  ❌ throw new Error("TODO")
+  ✓ const user = await db.user.create(...)
+
+数据库 Schema:
+  ❌ 只有 id 和 createdAt 字段
+  ✓ 包含所有业务字段 + 索引 + 约束
+```
+
+**应用层级**:
+
+| 阶段 | 验证者 | 问的问题 |
+|------|--------|---------|
+| 执行前 | gsd-plan-checker | 计划能**交付**目标吗？|
+| 执行后 | gsd-verifier | 执行**达成**了目标吗？|
+| 跨阶段 | gsd-integration-checker | 阶段之间**连接**正确吗？|
+| 最终 | 人类 UAT | 它真的**能用**吗？|
+
+### 例子 — 验证报告
+
+```markdown
+# VERIFICATION.md — Phase 1: User Authentication
+
+## Goal
+Users can register, login, and access protected routes.
+
+## Observable Truths (从用户角度)
+1. New user can register with email + password
+2. Registered user can login and receive JWT
+3. Protected routes reject unauthenticated requests
+4. Protected routes accept valid JWT
+
+## Verification Results
+
+| Truth | Exists | Substantive | Wired | Status |
+|-------|--------|-------------|-------|--------|
+| Registration | ✅ POST /auth/register | ✅ Real bcrypt + DB write | ✅ Called from signup form | PASS |
+| Login | ✅ POST /auth/login | ✅ Password compare + JWT sign | ✅ Called from login form | PASS |
+| Route protection | ✅ authMiddleware.ts | ✅ JWT verify + user lookup | ⚠️ Not applied to /api/admin/* | GAP |
+| JWT validation | ✅ Token generation | ✅ RS256 signing | ✅ Middleware uses it | PASS |
+
+## Gaps
+1. **GAP-01**: authMiddleware not applied to admin routes
+   - Severity: HIGH
+   - Fix: Add middleware to admin router in src/routes/admin/index.ts
+
+## Verdict: PARTIAL PASS (3/4 truths verified, 1 gap)
+```
+
+### 3. Nyquist Validation（奈奎斯特验证）
+
+命名来自信号处理的**奈奎斯特采样定理**: 要忠实重建信号，采样率需要 2x 以上。类比: 要忠实验证实现，每个需求都需要对应的自动化测试反馈。
+
+```
+原则: AI 生成器越自主，验证、可追溯性和回滚的投资就越大
+
+需求 REQ-01 → 必须有自动化测试覆盖
+需求 REQ-02 → 必须有自动化测试覆盖
+...
+```
+
+**缺口分类**:
+
+| 分类 | 含义 |
+|------|------|
+| COVERED | 测试存在、覆盖行为、运行通过 |
+| PARTIAL | 测试存在但失败或不完整 |
+| MISSING | 没有找到测试 |
+
+**例子 — Nyquist 验证报告**:
+
+```markdown
+# VALIDATION.md — Phase 1
+
+## Coverage Matrix
+
+| Requirement | Test File | Status | Notes |
+|-------------|-----------|--------|-------|
+| REQ-01: User registration | tests/auth/register.test.ts | COVERED | 5 test cases |
+| REQ-02: Email verification | tests/auth/verify-email.test.ts | COVERED | 3 test cases |
+| REQ-03: Login flow | tests/auth/login.test.ts | COVERED | 4 test cases |
+| REQ-04: Password reset | — | MISSING | No test file found |
+| REQ-05: Rate limiting | tests/middleware/rate-limit.test.ts | PARTIAL | Only tests 429 status, not cooldown |
+
+## Actions Taken
+- Generated: tests/auth/password-reset.test.ts (4 test cases for REQ-04)
+- Extended: tests/middleware/rate-limit.test.ts (added cooldown verification for REQ-05)
+
+## Result: 5/5 COVERED (was 3/5 before audit)
+```
+
+**关键约束**: gsd-nyquist-auditor **从不修改实现代码** — 只创建/修改测试文件和 VALIDATION.md。实现 Bug 被上报而非修复。
+
+### 4. Wave Execution（波浪式执行）
+
+计划按依赖关系分组为"波浪"，波浪内并行执行，波浪间串行。
+
+```
+Phase 1 有 4 个计划:
+  Plan A: 数据库 Schema     (无依赖)
+  Plan B: API 框架          (无依赖)
+  Plan C: 认证路由          (依赖 A + B)
+  Plan D: 前端登录页        (依赖 C)
+
+执行:
+  Wave 1: [Plan A, Plan B]  ← 并行（2 个独立 executor，各自全新 200K 上下文）
+  Wave 2: [Plan C]          ← 等 Wave 1 完成后执行
+  Wave 3: [Plan D]          ← 等 Wave 2 完成后执行
+
+编排器上下文使用: 仅 30-40%（瘦编排器模式）
+执行器上下文使用: 每个 0-50%（全新窗口，最佳质量区间）
+```
+
+**并行安全**: 并行执行器使用 `--no-verify` 避免 pre-commit hook 锁竞争。编排器在每个波浪完成后统一运行 hooks。
+
+**STATE.md 文件锁**: 使用 `O_EXCL` 原子创建 `STATE.md.lock` 防止并行写入竞争。
+
+### 5. Checkpoint System（检查点系统）
+
+形式化的人机交互点:
+
+| 类型 | 频率 | 含义 |
+|------|------|------|
+| **human-verify** | 90% | Claude 自动化完成，人类确认结果可用 |
+| **decision** | ~8% | 用户在选项中做选择，Claude 实施 |
+| **human-action** | ~2% | 需要人类判断的事（认证、视觉检查、秘钥配置）|
+
+**黄金法则**: "如果 Claude 能运行，Claude 就运行。" 检查点只用于验证和决策。
+
+**Auto-mode**: 自动跳过 human-verify 和 decision 检查点，但**永不**跳过 human-action。
+
+### 例子 — 检查点交互
+
+```
+# executor 遇到 human-verify 检查点:
+┌────────────────────────────────────────┐
+│ CHECKPOINT: human-verify               │
+│                                        │
+│ Task 3 of Plan A completed.            │
+│ Created: src/routes/auth/register.ts   │
+│                                        │
+│ Please verify:                         │
+│ 1. POST /api/auth/register returns 201 │
+│ 2. User appears in database            │
+│ 3. Verification email received         │
+│                                        │
+│ [Continue] [Fix Issues] [Skip]         │
+└────────────────────────────────────────┘
+
+# executor 遇到 decision 检查点:
+┌────────────────────────────────────────┐
+│ CHECKPOINT: decision                   │
+│                                        │
+│ JWT token expiry strategy:             │
+│ A) Short-lived (15min) + refresh token │
+│ B) Long-lived (7 days), no refresh     │
+│ C) Session-based, no JWT               │
+│                                        │
+│ Your choice: [A/B/C]                   │
+└────────────────────────────────────────┘
+
+# executor 遇到 human-action 检查点:
+┌────────────────────────────────────────┐
+│ CHECKPOINT: human-action               │
+│                                        │
+│ I need you to:                         │
+│ 1. Create a SendGrid account           │
+│ 2. Generate an API key                 │
+│ 3. Set SENDGRID_API_KEY in .env        │
+│                                        │
+│ [Done, continue]                       │
+└────────────────────────────────────────┘
+```
+
+---
+
+## 六、状态管理与会话持续性
+
+### STATE.md — 项目短期记忆
+
+```markdown
+# Project State
+
+**Phase:** 2 of 5
+**Plan:** B of 3
+**Status:** executing
+**Velocity:** 1.2 plans/hour
+**Last Session:** 2026-03-20 09:30
+
+## Recent Decisions
+- REQ-03: Use JWT with refresh tokens (user choice)
+- Database: PostgreSQL via Prisma (CONTEXT.md)
+
+## Blockers
+- None
+
+## Pending Todos
+- [ ] Add rate limiting to payment endpoints
+- [ ] Review admin panel permissions
+```
+
+### 会话暂停/恢复
+
+```bash
+# 暂停工作（保存完整状态）
+/gsd:pause-work
+# → 生成 HANDOFF.json (机器可读):
+#    {
+#      "current_task": "Plan B, Task 2",
+#      "completed": ["Plan A (all tasks)", "Plan B Task 1"],
+#      "remaining": ["Plan B Task 2-3", "Plan C"],
+#      "decisions": [...],
+#      "blockers": [],
+#      "uncommitted_files": ["src/api/payment.ts"]
+#    }
+# → 生成 .continue-here.md (人类可读):
+#    "你在做 Phase 2 Plan B 的第 2 个任务..."
+
+# 恢复工作（在新会话中）
+/gsd:resume-work
+# → 读 HANDOFF.json → 重建上下文 → 从断点继续
+# → 如果 HANDOFF.json 丢失 → 回退到 .continue-here.md
+# → 如果都丢失 → 从 artifacts 重建
+```
+
+### 上下文监控 Hook
+
+```
+Context Monitor（PostToolUse hook）:
+  ≤35% 剩余 → WARNING: "请准备收尾当前任务"
+  ≤25% 剩余 → CRITICAL: "立即保存状态，执行 /gsd:pause-work"
+  防抖: 每 5 次工具调用之间最多 1 次警告
+  严重度升级时绕过防抖
+```
+
+---
+
+## 七、Git 集成
+
+**核心原则**: "提交结果，不是过程。"
+
+| 事件 | 提交？ |
+|------|--------|
+| 项目初始化（brief + roadmap）| YES |
+| PLAN.md / RESEARCH.md 创建 | NO（中间产物）|
+| 每个任务完成 | YES（原子提交）|
+| 计划完成（元数据更新）| YES |
+| 暂停/恢复 | YES（WIP）|
+
+**提交格式**: `{type}({phase}-{plan}): {description}`
+
+```
+feat(1-A): add User model with Prisma schema
+feat(1-A): implement POST /auth/register endpoint
+test(1-A): add registration flow tests
+feat(1-B): add JWT authentication middleware
+fix(1-C): apply auth middleware to admin routes
+```
+
+**分支策略**:
+
+| 策略 | 说明 | 适用场景 |
+|------|------|---------|
+| `none` | 提交到当前分支（默认）| 个人项目 |
+| `phase` | 每阶段一个分支 | 需要阶段级 PR 审查 |
+| `milestone` | 每里程碑一个分支 | 需要版本级 PR 审查 |
+
+---
+
+## 八、配置系统
+
+### config.json 完整配置
+
+```json
+{
+  "mode": "interactive",          // interactive | yolo
+  "granularity": "standard",      // coarse | standard | fine
+  "model_profile": "balanced",    // quality | balanced | budget | inherit
+  "workflow": {
+    "research": true,             // 执行前研究
+    "plan_check": true,           // 计划质量验证
+    "verifier": true,             // 执行后验证
+    "auto_advance": false,        // 自动推进到下一阶段
+    "nyquist_validation": true    // 奈奎斯特测试验证
+  },
+  "planning": {
+    "commit_docs": true,          // 提交规划文档
+    "search_gitignored": false    // 搜索 gitignored 文件
+  },
+  "parallelization": {
+    "enabled": true,
+    "plan_level": true,           // 计划级并行
+    "task_level": false,          // 任务级并行（默认关闭）
+    "max_concurrent_agents": 3,
+    "min_plans_for_parallel": 2
+  },
+  "gates": {
+    "confirm_project": true,      // 确认项目初始化
+    "confirm_phases": true,       // 确认阶段划分
+    "confirm_roadmap": true,      // 确认路线图
+    "confirm_plan": true,         // 确认计划
+    "execute_next_plan": true     // 确认执行下一计划
+  },
+  "safety": {
+    "always_confirm_destructive": true,
+    "always_confirm_external_services": true
+  },
+  "git": {
+    "branching_strategy": "none"  // none | phase | milestone
+  }
+}
+```
+
+**配置层级**: 项目 `.planning/config.json` > 全局 `~/.gsd/defaults.json` > 内置默认值
+
+---
+
+## 九、命令速查（37+ 个）
+
+### 核心工作流
+
+| 命令 | 用途 |
+|------|------|
+| `/gsd:new-project` | 初始化新项目（提问 → 研究 → 需求 → 路线图）|
+| `/gsd:discuss-phase N` | 讨论阶段偏好（→ CONTEXT.md）|
+| `/gsd:plan-phase N` | 规划阶段（研究 → 计划 → 验证循环）|
+| `/gsd:execute-phase N` | 波浪式并行执行所有计划 |
+| `/gsd:verify-work N` | 目标回溯验证 |
+| `/gsd:validate-phase N` | Nyquist 测试覆盖验证 |
+| `/gsd:ship N` | 创建 PR |
+| `/gsd:next` | 自动推进到下一步 |
+| `/gsd:quick "描述"` | 快速任务（跳过完整规划）|
+| `/gsd:autonomous` | 自主运行所有剩余阶段 |
+
+### 阶段管理
+
+| 命令 | 用途 |
+|------|------|
+| `/gsd:add-phase "描述"` | 添加新阶段到路线图末尾 |
+| `/gsd:insert-phase N "描述"` | 在 N 后插入小数阶段（如 2.1）|
+| `/gsd:remove-phase N` | 移除阶段并重新编号 |
+| `/gsd:list-phase-assumptions N` | 列出 Claude 对阶段的假设 |
+
+### 里程碑管理
+
+| 命令 | 用途 |
+|------|------|
+| `/gsd:audit-milestone` | 审计里程碑完成度 |
+| `/gsd:complete-milestone` | 归档里程碑，打 tag |
+| `/gsd:new-milestone` | 开始新版本 |
+| `/gsd:plan-milestone-gaps` | 为审计发现的缺口创建补充阶段 |
+
+### 会话与导航
+
+| 命令 | 用途 |
+|------|------|
+| `/gsd:pause-work` | 暂停并保存完整状态 |
+| `/gsd:resume-work` | 从断点恢复 |
+| `/gsd:progress` | 查看当前进度 |
+| `/gsd:stats` | 显示项目统计 |
+| `/gsd:session-report` | 生成会话报告（token、工作摘要）|
+
+### 分析与调试
+
+| 命令 | 用途 |
+|------|------|
+| `/gsd:map-codebase` | 分析现有代码库（棕地项目必用）|
+| `/gsd:debug` | 科学方法 Bug 调查 |
+| `/gsd:health` | 项目健康检查 |
+
+### 杂项
+
+| 命令 | 用途 |
+|------|------|
+| `/gsd:settings` | 配置 GSD |
+| `/gsd:set-profile` | 切换模型配置文件 |
+| `/gsd:add-todo` | 捕获想法为 todo |
+| `/gsd:check-todos` | 查看待办事项 |
+| `/gsd:note` | 零摩擦笔记捕获 |
+| `/gsd:do "文本"` | 路由自由文本到正确的 GSD 命令 |
+| `/gsd:help` | 显示帮助 |
+| `/gsd:update` | 更新 GSD 框架 |
+
+---
+
+## 十、社区最佳实践
+
+### 开始之前
+
+1. **准备详细的项目描述**: 包括目标、用户、核心功能、约束、技术栈偏好。模糊描述会触发过多追问。
+2. **棕地项目必须先跑 `/gsd:map-codebase`**: 避免与现有模式冲突。
+3. **预算充足**: Max plan ($100-200/月) 是常规使用的推荐。GSD 的多 Agent 架构消耗 token 较高。
+
+### 工作中
+
+4. **永远不要跳过 `/gsd:discuss-phase`**: 花 5-10 分钟在这里可以节省数小时。大多数计划质量问题源于 Claude 在 CONTEXT.md 中缺少用户决策。
+5. **计划保持 2-3 个任务**: 每个适配 ~50% 的全新上下文窗口。更大的任务超出单个上下文窗口能可靠产出的范围。
+6. **小任务用 `/gsd:quick`**: 完整工作流对修错别字、改颜色等小事是大材小用。
+7. **用 `/gsd:add-todo` 捕获灵感**: 而不是打断当前工作。
+8. **用 `/gsd:progress` 检查位置**: 随时了解当前在哪、下一步做什么。
+9. **阶段间清理上下文**: 保持编排器在 30-40% 使用率的最佳区间。
+
+### 验证
+
+10. **启用 Nyquist 验证**: 在代码写之前就映射测试覆盖到每个需求，确保秒级反馈循环。
+11. **不要信任 SUMMARY.md**: 验证器会检查实际代码而非声称。
+12. **视觉规格优于纯文本规格**: 带热点的屏幕截图 mockup 比纯文字描述产出更好的结果。
+
+---
+
+## 十一、常见陷阱
+
+| 陷阱 | 影响 | 解决方案 |
+|------|------|---------|
+| 小改动用完整工作流 | 浪费时间和 token | 用 `/gsd:quick` |
+| 跳过 discuss-phase | 计划基于 Claude 的假设而非你的决策 | 始终先 `/gsd:discuss-phase` |
+| 计划任务过多 | 超出单个上下文窗口能力 | 限制 2-3 任务/计划 |
+| Token 预算耗尽 | 工作中断 | 预算 Max plan；小任务用 quick |
+| 棕地项目不扫描 | 与现有代码模式冲突 | 先跑 `/gsd:map-codebase` |
+| 上下文累积不清理 | 违背 GSD 核心优势 | 阶段间确保全新上下文 |
+| 执行失败后重跑整个阶段 | 浪费。修复应更精准 | 用 `/gsd:quick` 修复或 `/gsd:verify-work` 定位 |
+| CLAUDE.md 冲突 | GSD 规则未正确加载 | 手动确保 GSD 规则存在于 CLAUDE.md |
+
+---
+
+## 十二、GSD 独特创新
+
+| 创新 | 说明 |
+|------|------|
+| **Plans as Prompts** | PLAN.md 不是文档变成 prompt，它**就是** prompt。XML 结构直接指导执行 |
+| **Dream Extraction** | "协作思考"代替"需求收集"，从模糊想法提取可执行需求 |
+| **Nyquist Validation** | 借鉴信号处理定理，每个需求必须有自动化测试反馈 |
+| **Goal-Backward Verification** | 从用户可观察的结果反向推导验证（非正向检查任务完成度）|
+| **Context Bridge Architecture** | statusline hook 写指标到临时文件，context monitor 读取。解耦的桥接允许跨 hook 通信 |
+| **Deviation Handling** | 执行器自动处理计划偏差，适应而非失败 |
+| **gsd-tools.cjs** | Node.js CLI 工具（15 模块，100+ 命令），分离确定性逻辑和 AI 推理 |
+| **User Profiling** | 8 维度行为分析，个性化工作流响应 |
+| **Quick Mode Composable Flags** | `--discuss`, `--research`, `--full` 自由组合临时任务的规划深度 |
+| **Multi-Runtime Abstraction** | 安装时转换支持 6 种 AI 运行时（工具名、hook 事件、Agent 前言、路径约定）|
+
+---
+
+## 十三、实战例子
+
+### 例子: 棕地项目 — 给现有 SaaS 加支付功能
+
+```bash
+# Step 0: 扫描现有代码库
+/gsd:map-codebase
+# → 4 个并行 mapper 分析:
+#   tech: Next.js 14 + Prisma + PostgreSQL + Tailwind
+#   arch: App Router, server components, API routes in /api/
+#   quality: 72% test coverage, ESLint + Prettier configured
+#   concerns: No rate limiting, N+1 queries in /api/users
+
+# Step 1: 初始化项目（GSD 会读取 codebase 分析）
+/gsd:new-project
+# → "你在给现有 SaaS 加什么功能？"
+# → "支付处理: Stripe 订阅 + 一次性付款"
+# → 生成 ROADMAP.md:
+#   Phase 1: Stripe 集成基础（webhook + 客户同步）
+#   Phase 2: 订阅管理（创建/升级/降级/取消）
+#   Phase 3: 一次性付款（checkout session）
+#   Phase 4: 账单历史 + 发票 UI
+
+# Step 2: 讨论 Phase 1
+/gsd:discuss-phase 1
+# → "Stripe API version: 2024-12-18 还是 latest?"
+# → "Webhook 签名验证: 同步还是异步?"
+# → "失败重试策略: 指数退避还是固定间隔?"
+# → 决策锁定到 CONTEXT.md
+
+# Step 3: 规划
+/gsd:plan-phase 1
+# → RESEARCH.md: Stripe Next.js 集成最佳实践
+# → Plan A: Stripe SDK setup + webhook endpoint
+# → Plan B: Customer sync (User ↔ Stripe Customer)
+# → Plan-checker 验证:
+#     ✓ CONTEXT.md 决策被尊重
+#     ✓ REQ-01 到 REQ-04 都有对应任务
+#     ✓ 每个 plan ≤ 50% 上下文预算
+
+# Step 4: 执行
+/gsd:execute-phase 1
+# Wave 1: [Plan A, Plan B] 并行
+#   Executor A (全新 200K context):
+#     Task 1: npm install stripe → commit
+#     Task 2: POST /api/webhooks/stripe → commit
+#     Task 3: human-verify: 测试 webhook 签名
+#   Executor B (全新 200K context):
+#     Task 1: Prisma schema add stripeCustomerId → commit
+#     Task 2: Customer sync service → commit
+
+# Step 5: 验证
+/gsd:verify-work 1
+# → Exists: ✅ webhook endpoint, customer sync service
+# → Substantive: ✅ Real Stripe API calls, not mocks
+# → Wired: ⚠️ webhook handler dispatches events but
+#           subscription.updated handler is empty stub
+# → GAP-01: subscription.updated handler needs implementation
+#           (will be covered in Phase 2)
+
+# Step 6: Nyquist 验证
+/gsd:validate-phase 1
+# → REQ-01 (Stripe setup): COVERED — test/stripe/setup.test.ts
+# → REQ-02 (Webhook verify): COVERED — test/api/webhook.test.ts
+# → REQ-03 (Customer sync): PARTIAL — test exists but no edge cases
+# → REQ-04 (Error handling): MISSING
+# → Auditor generates: test/stripe/error-handling.test.ts
+# → Auditor extends: test/stripe/customer-sync.test.ts
+```
+
+### 例子: Bug 调试工作流
+
+```bash
+/gsd:debug
+# → "描述你遇到的问题"
+# → "用户点击'升级订阅'后页面白屏"
+
+# gsd-debugger 使用科学方法:
+# 1. 假设: React 渲染错误（未捕获的异常）
+#    测试: 检查浏览器控制台
+#    结果: TypeError: Cannot read property 'id' of undefined
+#    → 假设部分确认
+
+# 2. 假设: subscription 对象在某些条件下为 null
+#    测试: grep subscription 使用处
+#    结果: src/components/UpgradeModal.tsx:45
+#          const planId = subscription.currentPlan.id  ← 无空值检查
+#    → 根因确认
+
+# 3. 修复:
+#    if (!subscription?.currentPlan) {
+#      return <LoadingState />;
+#    }
+
+# 4. 验证:
+#    → 添加回归测试
+#    → 原子提交: fix(2-A): handle null subscription in UpgradeModal
+
+# 调试状态持久化到 DEBUG.md（跨会话保留）
+```
+
+### 例子: 快速任务
+
+```bash
+# 小改动不需要完整工作流
+/gsd:quick "把登录按钮颜色从蓝色改成品牌紫色 #7C3AED"
+# → 直接执行，原子提交
+# → 跳过: research, plan-check, verification
+# → 保留: 状态追踪, git commit
+
+# 需要一点研究的快速任务
+/gsd:quick --research "添加 dark mode 支持"
+# → 研究: Tailwind dark mode 最佳实践
+# → 执行: 添加 dark: 变体
+# → 原子提交
+
+# 需要讨论的快速任务
+/gsd:quick --discuss "重构用户表添加团队支持"
+# → 讨论: "多对多还是多对一？"
+# → 执行: Schema migration + model update
+# → 原子提交
+```
+
+---
+
+## 十四、与其他框架对比
+
+| 维度 | GSD | ECC | BMAD | SpecKit | Plain Plan Mode |
+|------|-----|-----|------|---------|-----------------|
+| 定位 | 规格驱动开发 | Agent harness 优化 | 敏捷团队模拟 | 开发者工具包 | 内置功能 |
+| Stars | 36K+ | 50K+ | ~5K | 72.7K | N/A |
+| 核心优势 | 上下文隔离（全新窗口/任务）| 持续学习 + Hook 驱动 | 完整敏捷流程 | 灵活可定制 | 零开销 |
+| Token 成本 | 高（多 Agent 生成）| 中-高 | 高 | 低 | 最低 |
+| 适合场景 | 复杂多阶段项目 | 日常重度开发 | 企业敏捷团队 | GitHub 生态用户 | 简单任务 |
+| 学习曲线 | 中等（1小时上手）| 陡峭 | 陡峭 | 平缓 | 无 |
+| 验证体系 | 目标回溯 + Nyquist | Verification Loop | Scrum review | 手动 | 无 |
+| 上下文管理 | 激进隔离（全新窗口）| 策略性压缩 | 无特殊处理 | 无特殊处理 | 自动压缩 |
+| 会话持续性 | HANDOFF.json + STATE.md | Memory 系统 | 无 | 无 | 无 |
+
+**选择建议**:
+
+- **GSD**: 构建完整产品、多阶段项目、需要严格验证
+- **ECC**: 日常编码、持续改进、多语言多项目
+- **两者结合**: GSD 做项目管理和规划，ECC 做代码质量和学习（你当前的配置）
+- **Plain Plan Mode**: 单文件修改、简单 Bug 修复
+
+---
+
+## 十五、关键数据
+
+- GitHub Stars: 36K+
+- 版本: v1.26.0
+- Agents: 16 个
+- 命令: 37+ 个
+- 工作流: 44 个
+- 模板: 50+ 个
+- gsd-tools 命令: 100+
+- 活跃 Discord: 1,200+ 成员
+- 支持运行时: 6 种（Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Antigravity）
+- 许可: 开源
+
+---
+
+## Related
+
+- [[Everything Claude Code 完整指南]]
+- [[Everything Claude Code 用法速查]]
+- [[Everything Claude Code 方法论与最佳实践]]

6 - Zettelkasten/20260319120100 Hook驱动优于提示词驱动.md

@@ -0,0 +1,24 @@
+---
+created: "2026-03-19 12:01"
+type: zettel
+tags: [claude-code, agent-reliability, automation]
+source: "https://github.com/affaan-m/everything-claude-code"
+---
+
+# Hook 驱动优于提示词驱动
+
+AI Agent 的行为控制有两种机制：提示词（Skill/Rule）和 Hook。核心区别在于**确定性**：
+
+- **Hook**: 触发率 100%，确定性执行，不依赖模型判断
+- **提示词**: 触发率 50-80%，概率性，受上下文长度、模型注意力影响
+
+因此，**关键质量控制（格式化、安全检查、状态保存）应通过 Hook 实现，而非依赖提示词**。提示词适合灵活的、需要判断力的任务；Hook 适合必须每次都执行的不变量。
+
+这解释了 ECC v2 为什么把学习观察从 Skill 迁移到了 Hook — v1 中观察经常遗漏，v2 通过 PreToolUse/PostToolUse Hook 实现了 100% 捕获率。
+
+---
+
+## Related
+
+- [[Everything Claude Code 方法论与最佳实践]]
+- [[Everything Claude Code 完整指南]]

6 - Zettelkasten/20260319120200 MCP数量与上下文窗口的反比关系.md

@@ -0,0 +1,28 @@
+---
+created: "2026-03-19 12:02"
+type: zettel
+tags: [claude-code, context-window, performance, mcp]
+source: "https://github.com/affaan-m/everything-claude-code"
+---
+
+# MCP 数量与上下文窗口的反比关系
+
+每个启用的 MCP Server 都会占用上下文窗口空间（工具定义、schema 描述等）。实测数据：
+
+- 0-5 个 MCP: 有效上下文接近 200K tokens
+- 10+ 个 MCP: 有效上下文降至 ~70K tokens（降幅 65%）
+
+**最佳实践**:
+- 活跃 MCP <= 10 个，活跃工具总数 <= 80 个
+- 用 `disabledMcpServers` 动态禁用不用的
+- 重操作优先用 CLI（如 `gh`）而不是 MCP
+- 使用 `llms.txt` 模式获取文档，避免 MCP 常驻开销
+
+这是 Claude Code 性能优化中**最重要的单一因素** — 比任何 Agent 或 Skill 都重要。
+
+---
+
+## Related
+
+- [[Everything Claude Code 方法论与最佳实践]]
+- [[Hook驱动优于提示词驱动]]

6 - Zettelkasten/20260319120300 本能学习系统的演化路径.md

@@ -0,0 +1,30 @@
+---
+created: "2026-03-19 12:03"
+type: zettel
+tags: [claude-code, machine-learning, continuous-improvement, agent-evolution]
+source: "https://github.com/affaan-m/everything-claude-code"
+---
+
+# 本能学习系统的演化路径
+
+ECC 的 Continuous Learning v2.1 实现了一个 AI Agent 自我改进的闭环：
+
+```
+观察(Hook捕获) → 模式检测(Haiku模型) → 本能(Instinct) → 技能(Skill)
+```
+
+关键设计决策：
+
+1. **原子性**: 每个本能只描述一个行为，带信心分数 (0.3-0.9)
+2. **项目隔离**: 用 git remote URL hash 作命名空间，防止跨项目污染
+3. **渐进提升**: 单项目本能 → 多项目验证(2+项目, 信心>=0.8) → 全局技能
+4. **可逆性**: `/evolve` 生成的技能可以回退到本能级别
+
+这本质上是一个**强化学习循环** — 用户的接受/拒绝作为奖励信号，信心分数作为 Q-value 近似。与传统 fine-tuning 不同，它在推理时（通过 context injection）而非训练时改变行为，成本低且可控。
+
+---
+
+## Related
+
+- [[Everything Claude Code 方法论与最佳实践]]
+- [[Hook驱动优于提示词驱动]]

6 - Zettelkasten/20260320100100 上下文腐烂与全新窗口隔离.md

@@ -0,0 +1,29 @@
+---
+created: "2026-03-20 10:01"
+type: zettel
+tags: [claude-code, context-window, ai-quality, gsd]
+source: "https://github.com/gsd-build/get-shit-done"
+---
+
+# 上下文腐烂与全新窗口隔离
+
+AI 编码 Agent 的输出质量随上下文填充率非线性下降:
+
+- 0-30%: 峰值质量
+- 50%+: 开始赶工
+- 70%+: 幻觉风险显著增加
+
+GSD 的解决方案是**激进隔离**: 每个任务执行器获得全新的 200K token 上下文窗口，编排器保持在 30-40% 使用率。这与 ECC 的"策略性压缩"（在逻辑节点手动 `/compact`）形成对比。
+
+两种方法的权衡:
+- **全新窗口**: 质量最佳，但 token 成本高（每个 Agent 独立 API 调用）
+- **策略性压缩**: 成本低，但依赖人类判断何时压缩，且压缩可能丢失关键上下文
+
+理想方案可能是两者结合: 对复杂多阶段项目用 GSD 的窗口隔离，对日常编码用 ECC 的策略压缩。
+
+---
+
+## Related
+
+- [[GSD 方法论与最佳实践]]
+- [[MCP数量与上下文窗口的反比关系]]

6 - Zettelkasten/20260320100200 目标回溯验证vs正向任务检查.md

@@ -0,0 +1,27 @@
+---
+created: "2026-03-20 10:02"
+type: zettel
+tags: [verification, methodology, ai-quality, gsd]
+source: "https://github.com/gsd-build/get-shit-done"
+---
+
+# 目标回溯验证 vs 正向任务检查
+
+传统软件验证是正向的: "任务 1 完成了吗？任务 2 完成了吗？全部完成 = 目标达成。" 这隐含假设任务列表是完备的。
+
+GSD 的目标回溯验证(Goal-Backward Verification)反转方向: "用户应该能做什么？这个能力在代码中存在吗？不仅存在，还是真实实现（非桩代码）？不仅实现了，还与系统连接了？"
+
+四级验证层次:
+1. Exists — 文件在预期路径
+2. Substantive — 真实实现，非 TODO/placeholder
+3. Wired — 与系统其他部分连接（import 被使用，API 被调用）
+4. Functional — 实际调用时能工作
+
+这对 AI 生成代码尤其重要: LLM 擅长生成"看起来正确"的代码（通过 Level 1-2），但经常遗漏连接（Level 3）。GSD 的桩代码检测模式专门针对这一弱点。
+
+---
+
+## Related
+
+- [[GSD 方法论与最佳实践]]
+- [[Hook驱动优于提示词驱动]]

6 - Zettelkasten/20260320100300 Plans as Prompts设计模式.md

@@ -0,0 +1,27 @@
+---
+created: "2026-03-20 10:03"
+type: zettel
+tags: [prompt-engineering, ai-architecture, gsd]
+source: "https://github.com/gsd-build/get-shit-done"
+---
+
+# Plans as Prompts 设计模式
+
+GSD 中 PLAN.md 不是"被转化为 prompt 的文档"——它**就是** prompt。XML 结构（`<task>`, `<action>`, `<verify>`, `<done>`）直接指导执行器的行为。
+
+这个设计消除了"文档到 prompt 的翻译损失": 传统方式需要一个中间步骤把文档理解为指令，每次翻译都引入歧义。Plans as Prompts 让计划者直接写执行指令，跳过翻译。
+
+关键约束使这成为可能:
+- 每个计划 ≤ 50% 上下文预算（确保执行器有足够空间思考）
+- XML 结构强制精确性（不是自然语言的模糊描述）
+- `<verify>` 块要求每个任务都有可执行的验证命令
+- `<done>` 块定义明确的完成状态
+
+更广泛的启示: 当 AI Agent 是执行者时，规划文档应该以 Agent 的"母语"（结构化 prompt）书写，而非以人类的可读性为优先。
+
+---
+
+## Related
+
+- [[GSD 方法论与最佳实践]]
+- [[目标回溯验证vs正向任务检查]]