founder-decision-agent AGENTS.md

Agent Development Operating Rules

本文件约束所有参与本仓库开发的编码 Agent。它的作用是防止长周期开发中的目标漂移、上下文压缩、未经验证的“完成”以及为了堆代码而堆代码。

1. 每次工作前必须恢复项目状态

开始任何实质工作前，按顺序读取：

1. PROJECT_STATE.yaml
2. docs/PROJECT_CHARTER.md
3. docs/REQUIREMENTS_TRACEABILITY.md
4. docs/DECISIONS.md
5. docs/ROADMAP.md
6. docs/WORKLOG.md

如果当前任务涉及评估输出，继续读取 docs/PRODUCT_SPEC.md 和 docs/EVALUATION_METHODOLOGY.md；如果涉及代码结构或技术选型，继续读取 docs/ARCHITECTURE_PLAN.md。

处理评测失败、报告质量或安全问题时，还必须读取 docs/FAILURE_TAXONOMY.md。

聊天内容可以补充这些文件，但不得用模糊的聊天记忆覆盖已经确认的项目决定。新要求与现有文档冲突时，先显式指出冲突并记录决定。

2. 质量优先规则

• 不以文件数量、代码行数、功能数量或“看起来完整”作为完成标准。
• 不在阶段质量门未通过时提前实现后续阶段。
• 优先完成最能降低核心产品风险的实验、规格和评测。
• 单 Agent 能可靠完成的工作，不为了展示复杂度而改成多 Agent。
• 不因某个框架流行而锁定框架；技术选择必须对应已确认需求。
• 不把模型自评、测试存在、命令退出码为零或文档声称成功，单独当作质量证明。

3. 需求与决策管理

• 每项实现必须能映射到 REQ-* 需求编号。
• 任何改变产品边界、公开承诺、数据处理方式、评估结论或核心架构的决定，都要写入 docs/DECISIONS.md。
• 未决定事项必须保持“待决定”，不得在实现中暗中替用户作出不可逆选择。
• 可逆、低风险的实现细节可以先采用明确记录的默认值。
• 完成一项需求后，必须在需求追踪表中加入可检查的验证证据。

4. 事实、推断与反幻觉

• 评估结果必须区分：用户提供、外部事实、模型推断、情景假设、未知。
• 外部可变事实必须记录来源、发布日期或访问日期。
• 数值计算使用确定性代码，不允许模型在无依据时生成精确数字。
• 不能验证的信息要降级为假设或未知，不能用流畅措辞伪装成事实。
• 搜索结果、模型摘要和二手文章不是天然可靠来源；优先原始资料、监管机构、公司官方材料和可复核数据。
• “另一轮模型批评”不能替代引用验证、结构校验和人工评审。

5. 安全与用户利益

• 产品提供创业想法与融资准备分析，不提供证券买卖建议，不保证融资或商业成功。
• 涉及法律、税务、证券发行、医疗、重大财务决策时，必须标注适用地区和专业人士复核需要。
• 默认不代表用户联系投资人、发布内容、签署文件、提交申请、转账或执行其他外部写操作。
• 用户身份资料和想法记录按敏感数据处理；默认最小收集、最小传输、可导出、可删除。
• 日志、测试固件和错误报告不得包含密钥或未经同意的真实私密想法。

6. 代码与验证

• 核心业务必须与 UI、模型提供商、搜索提供商和存储实现解耦。
• 所有公共输入输出使用版本化 Schema。
• 每个工具必须有参数校验、超时、错误类型、权限边界和测试。
• 新增或改变评估行为时，必须同步更新评测案例。
• 单元测试不依赖真实付费 API；真实模型评测与普通 CI 分离。
• 对外结论必须经过结构验证、引用验证和关键数值验证。

7. 工作区边界

• 默认只修改 /Users/frame/Documents/lmao agent。
• /Users/frame/Documents/lmao app 是潜在集成项目，目前包含用户自己的未提交修改。除非用户明确授权具体集成任务，否则只允许只读检查，不得修改、格式化、提交或清理。
• 不覆盖或删除不属于当前任务的用户文件。

8. 每次工作结束

结束前必须：

1. 更新 docs/WORKLOG.md；
2. 更新受影响的需求状态、决策和路线图；
3. 运行与改动范围相称的验证；
4. 清楚说明已经证明的内容、尚未证明的内容和下一决策点；
5. 只有全部显式需求都有直接证据时，才可以声称项目完成。