这一部分开始解决“change 为什么总落不下去”#

Part 2 把 discussion、issue、proposal、design、specs、tasks 这条收紧链路先立住了。真正难的部分，现在才开始出现：文档明明已经有了，为什么 change 还是会落偏、落慢、落着落着又回到“AI 顺手乱铺实现”的老路？

所以 Part 3 不再按“前端一章、后端一章”去排，而是直接盯着主干开发里最容易失控的几个地方下刀。

这一部分的主线不是“多写代码”，而是“让代码按主线长”#

这里会按五个动作往前推：

• 先把 tasks.md 写成真正能跑的 Execution Graph，而不是施工顺序单。
• 再把主资产的官方路径收清楚，防止 AI 先把副线铺满。
• 再把事实层、证据层、投影层分开，避免 scanner、缓存、视图反客为主。
• 再把开发期 Harness 接进来，让 agent 能稳定推进、验证、回退和继续收敛。
• 最后把长任务不断线这件事做实，让项目不是只会“这轮聊完”，而是真的能跨 session 往前跑。

读完这一部分，手里应该多出什么#

读完 Part 3，最理想的状态不是“理解了更多概念”，而是手里已经多出下面这些东西：

1. 一张能驱动真实实现的 Execution Graph。
2. 一条围着主资产推进的官方路径，而不是一堆同时开工的副线。
3. 一套事实层、证据层、投影层的分层语言，能直接拿来判断哪里越位了。
4. 一套开发期 Harness 基线，知道哪些验证、观测和回退该先上。
5. 一组能支持长任务继续推进的状态资产，例如 progress log、handoff artifact 和 repo memory。