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.

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正向任务检查]]