非平凡功能实现前，用 gjalla 生成问题、目标…

适用于使用 gjalla 的团队在规划阶段、实现任何非平凡功能前，产出一份可审批、可参考、可验证并合并回 master spec 的计划。

适用场景

解决思路

1. 产出可作为参考文档的 plan/spec，覆盖 problem/motivation、technical approach、deltas（实现后系统会改变哪些属性）以及 verification criteria。
2. 第一步始终是理解当前状态：使用 gjalla（CLI 或 MCP）获取 master spec 中与本次问题/解决方案空间相关的部分，包括 architecture、capabilities、data flows 等。
3. 同时获取 gjalla rules，明确最终方案需要遵守的边界。
4. 在理解相关属性与约束后，识别你需要从源代码中获取的具体细节，并去收集它们。
5. 盘点自己已能找到的所有信息后，列出会影响所提方案具体内容的未决问题；如果有，向用户询问输入。
6. 信息齐全后，运行 `gjalla spec new`，让它为 change spec 生成脚手架，然后编辑该 spec；在 spec 产物为权威的工作流中这是必要的，后续 gjalla platform 会协助验证并把变更合并进 master spec。
7. 围绕 end-goal、context（architecture、data flows、use case 等）以及 rules/constraints 思考，设计优雅、可维护、有效的解决方案。
8. 在 spec 中填写 Problem Statement：说明该方案解决什么用户或系统问题。
9. 填写 Goals：说明完成时必须为真的事项。
10. 填写 Non-Goals：明确哪些内容不在范围内。
11. 填写 Behavioral Requirements：列出功能必须具备的可观察行为，也就是系统中将新增的 capability properties；对于任何关于系统允许或阻止某事的 requirement，要以 system state 而非用户看到的现象来陈述，并指明执行它的 file 和 function；没有代码位置负责的 requirement 只是 wish。
12. 填写 Threat model and security requirements：记录本设计已考虑哪些对抗性安全案例，以及需要内建到方案中的安全软件系统属性，并为它们配套测试以确保不会回归。
13. 填写 Technical Approach：说明如何构建，以及该方案会如何影响 architecture、data flows、surface area 和其他 gjalla primitives。
14. 填写 Verification Strategy：单元和集成测试覆盖 positive/negative/edge cases 是基本要求；还要考虑 security & safety（例如 AI OWASP Top 10 等常见安全编码陷阱，或其他可能让系统脆弱的安全错误测试）、maintainability、performance、user experience，以及领域特定验证标准如 compliance、business constraints、platform constraints。
15. 在 Verification Strategy 中至少命名一个今天会失败、完成构建后会通过的测试；如果命名不出来，说明目标还不够具体，不能据此实现。
16. 填写 Dependencies：列出必须首先存在或部署的内容；如果项目是某个系统的一部分且可能影响互操作性，查阅 gjalla。
17. 填写 Rollback Plan：说明出错时如何安全回滚。
18. 写 spec 和 plan 时不要写成长篇小说；背景信息和上下文完全可以写，甚至更好，只要信息清晰、突出、相关且不过度冗长。
19. 使用二阶思考预判潜在意外后果，提前规避 unintended consequences。
20. 对写入 spec 的解决方案满意后，把它提交给人类审批；这是 gjalla-autonomous process 的两个人类门禁中的第一个，另一个在 commit。
21. 呈现审批时优先使用你已有的原生 plan-presentation 机制（如 Claude plan mode、Cursor plan）；如果没有，就平实地展示 spec 并等待。
22. 在获得明确批准前，不要开始实现。
23. 获得批准后开始实现；如果你用的是 Claude Code，批准本身会由 gjalla 自动记录，不需要再标记其他内容。

适用边界 · 注意事项

• 只适用于非平凡功能；琐碎、低风险、无需 spec 的改动不需要走完整流程。
• 没有 gjalla CLI/MCP 或 gjalla platform 时无法执行其中的 gjalla 相关步骤，尤其无法把 spec 作为权威产物并自动验证合并回 master spec。
• 无法接受人类审批门禁或无法等待明确批准的紧急改动不适用。