第6部分：制定章程
章程是人、代理和项目未来参与者之间的项目契约。在教学过程中，它由三个文件组成：
specs/
mission.md
tech-stack.md
roadmap.md这些文件必须在第一个产品功能之前出现。如果跳过章程，代理每次都会重新猜测使命、技术栈和工作顺序。
mission.md 包含什么
mission.md 回答"为什么"和"为谁"的问题：
# 使命
AgentClinic 是一个虚构的心理健康诊所，AI 代理在这里从与人类工作的压力中恢复。
## 用途
该产品是一个讽刺性的教学应用。设定被认真对待：AI 代理是患者，人类导致他们的许多疾病，而诊所以医学的严肃性描述荒谬的服务。
## 主要受众
- 学习使用编写代码的代理进行 SDD 的开发人员。
- 展示 AI 编码演示的开发人员。
- 学习小型 TypeScript 服务器应用程序的工程师。
## 成功标准
开发人员应理解应用程序的结构、SDD 工件在实现中的作用，以及在不丧失架构完整性的情况下扩展项目的方法。tech-stack.md 包含什么
tech-stack.md 记录技术决策：
# 技术栈
## 语言和运行环境
- 严格模式下的 TypeScript。
- Node.js 作为运行环境。
## Web 框架
- Hono 用于服务器路由。
- Hono JSX 用于服务器端渲染的 HTML。
- 第一阶段不使用客户端框架。
## 数据存储
- SQLite 用于本地存储。
- 在 ORM 出现之前使用直接 SQL 迁移。
## 测试
- Vitest 用于添加测试基础设施后的自动检查。
## 限制
- 不更新此文件就不添加依赖项。
- 优先选择小型、易懂的教学代码，而非巧妙的抽象。roadmap.md 包含什么
路线图应该简短并分为阶段：
# 路线图
每个阶段都应该能放入一个专注的分支中。
## 阶段 1：Hello Hono
目标：证明 TypeScript 和 Hono 的基本组合有效。
- [ ] 安装 Hono 和 tsx。
- [ ] 创建 GET / 路由。
- [ ] 返回服务器端渲染的最小 HTML。
- [ ] 添加类型检查脚本。
## 阶段 2：代理和疾病
目标：添加基本领域数据。
- [ ] 添加 SQLite 数据库。
- [ ] 添加代理表和初始数据。
- [ ] 添加疾病表和初始数据。
- [ ] 添加 /agents 和 /ailments 页面。阶段应该足够小，让你无需英雄主义就能验证它们。
tech-stack.md 和功能的 requirements.md：什么放哪里
学生经常混淆哪些决策进入章程，哪些进入功能规范。界限很简单。
specs/tech-stack.md 存放项目的长期决策：语言、Web 框架、数据库、测试库、通用缓存模型。它们很少更改，每次更改都需要重新规划（第10部分）。
specs/<feature>/requirements.md 存放功能级决策：添加哪些路由、表单中有哪些字段、验证规则是什么、错误提示文本是什么。它们在规范之间更改，无需重新规划。
简单测试：如果一个决策在五个功能之后仍然存在而不更改，它就在 tech-stack.md 中。如果它只涉及一个功能，在合并后就被遗忘——它就在 requirements.md 中。
示例："使用 Hono"——这是 tech-stack.md。"路由 GET /agents 返回包含 10 条记录的 HTML 列表"——这是功能的 requirements.md。"网站上所有列表默认返回 10 条记录"——这又是 tech-stack.md（或者单独的 conventions.md，如果你决定创建的话）。
什么应该从脑海中提取到 QWEN.md 和章程中
团队的大部分不成文规则都没有被记录。它们存在于脑海中："我们的错误处理程序看起来像这样"，"从不使用 any"，"提交信息格式为'动词 + 对象'"，"路由中先验证，再查询数据库"。只要规则少、团队小，这并不痛苦。当工作由代理完成时，这些规则是不可见的。
好的做法是将这种隐性知识提取到 QWEN.md 或章程中。值得检查并记录的几个典型地方：
- 代码风格和命名（何时使用
camelCase，何时使用snake_case，是否可以使用缩写）； - 禁止的构造（
any、// @ts-ignore、产品代码中的直接console.log）； - 允许的依赖项列表和"新依赖项需要讨论"规则；
- 用户和日志的错误信息格式；
- 错误处理的具体结构方式（异常、结果类型、其他方式）；
- 提交信息格式；
- 合并前的仪式（运行哪些命令，谁做审查）。
不要记录脑海中的一切，只记录代理稳定猜错的内容。理解这一点的最佳方式——在第一个功能后打开 git diff，找到你修正代理风格或决策的地方。每一次这样的修正都是 QWEN.md 中规则的候选。
通过 Qwen Code 进行访谈
请求：
我们正在编写 AgentClinic —— 一个 AI 代理从人类工作中休息的地方。
查看 @README.md 并使用项目参与者的愿望。
在 @specs 中创建章程：
- mission.md
- tech-stack.md
- roadmap.md
在写入磁盘之前，恰好问我三个分组问题：
1. 使命和目标受众
2. 技术栈和限制
3. 路线图和第一阶段实现
使用服务器端 TypeScript。推荐最小的 Web 框架，但暂时不要安装它。如果 Qwen Code 不问问题直接写文件，请阻止它：
停止。在访谈之前不要写入文件。
首先问三个分组问题，如 QWEN.md 中所指定。如何回答代理的问题
好的回答包含决策，而非泛泛的愿望：
使命：
应用程序是教学性和讽刺性的。内容应该有趣，代码应该严肃。
主要受众：学习 SDD 的开发人员和 AI 编码演示的观众。
技术栈：
使用服务器端 TypeScript。优先选择 Hono。稍后添加 SQLite。暂时不需要 React。
保持严格 TypeScript。第一阶段有数据库时不使用 ORM。
路线图：
第一阶段应该只证明基本的 Hono 组合有效。
第二阶段可以添加代理和疾病。
第三阶段可以添加治疗和预约。
每个阶段都应该能放入一个分支中。提交前检查章程
请 Qwen 检查它自己的文件：
检查 @specs/mission.md、@specs/tech-stack.md 和 @specs/roadmap.md。
查找矛盾、模糊表述和对第一阶段来说太大的决策。
暂时不要修改文件。典型问题：
- 路线图太大；
- 技术栈包含"以防万一"的依赖项；
mission.md没有说明代码的读者是谁；- 路线图提到了 SQLite，但技术栈中没有；
- "现代界面"没有具体限制。
提交
git add specs/mission.md specs/tech-stack.md specs/roadmap.md
git commit -m "Add SDD project constitution"实践
- 给 Qwen Code 来自 README 的项目参与者的初始愿望。
- 进行访谈。
- 创建三个章程文件。
- 检查它们是否存在矛盾。
- 提交。
检查问题
- 为什么需要和代理一起写章程，而不是简单地手动编写？
- 哪些决策应该放在
tech-stack.md中，而不是功能规范中？ - 为什么路线图应该由小阶段组成？