图 1-1四个毛病，四组对策
左边是作者观察到的固定失效模式。右边是它们被翻译成的具体机制。箭头不是比喻——每一根箭头都能指到一个真实文件。
图 1-1 · 症状 → 机制。橙色框属于 H04 总编排，青色属于 H06 原则层，蓝色属于 H07 能力层。
1-2为什么用"文字"当对策
看到"把工程判断写成 markdown"，第一反应通常是：这不就是 prompt 吗，能可靠吗？
pstack 的答案是——单靠一句 prompt 不可靠，所以它做了三件事。这三件事定义了后面每一层的形状。
机制一
拆小
一条原则只讲一个判据，24 条分开放。agent 每次只读相关的那几条，而不是一篇长文。
机制二
要出处
poteto-mode 原文要求："name each principle that shaped a decision"。引用必须点名，于是你能核对它是否真的照着做。
机制三
无畏并行
README 提出 "fearless parallelism"：当单 agent 能够先深扎（"go deep first"）且严格自证，多 agent 扇出才能真正并行。
1-3它明确不做的事
理解一个系统的边界，比理解它的功能更快。pstack 的四条边界：
- 不定义你的项目结构。它管流程，不管你的目录该怎么摆；只有
tailwind-css-basic、typescript-best-practices 这类少数技能带技术栈口味。
- 不提供新能力。它能调用的工具就是你 runtime 本来就有的
Agent、TaskCreate、Read。它改的是使用顺序和停止条件。
- 不做常驻服务。没有 daemon，除 H10 那几个脚本外没有可执行产物。
- 不保证结果。它把"什么叫可交付"写清楚了，交付本身还是要模型去做。
本层的检验问题：你能否说出 pstack 反对的四个毛病，以及每个毛病对应的机制在哪一层？
答得出就往 H02 走——那一层解释这些文字为什么能"每次都被重新加载"。