Files

3.3 KiB
Raw Permalink Blame History

Codex 工作区约定

  1. 开始任何任务前,必须完整阅读根目录 PROJECT_PROGRESS.md。
  2. 完成任何实质性工作后,必须同步更新 PROJECT_PROGRESS.md 中的版本、日期、当前状态、已完成工作、验证结果、限制、下一步和变更日志。
  3. 不得把未运行的测试、未完成的最优性证明或未进行的 Cocos 实机回放写成已完成。
  4. 客观错误要增加回归测试;用户偏好要持久化到 colorBlock-level-generator/feedback/。
  5. 实际 Cocos 源码和可复现测试优先于历史说明;不要静默覆盖用户已有文件或未跟踪内容。
  6. 每次学习新反馈或改动工作台/生成器后,都必须同步维护 colorBlock-level-generator/docs/HUMAN_DESIGN_RULES.md 和本项目会话记忆 PROJECT_PROGRESS.md,即使没有新增规则也应记录执行状态或本次维护摘要;相关反馈写入 feedback/rules.json。规则总表须区分硬检查、启发式、人工规范和历史专项。此要求适用于复制文件夹后的所有接手者。
  7. 每次关卡设计、试玩反馈、原版研究或生成器迭代,还必须在同一份 colorBlock-level-generator/docs/MANUAL_SPATIAL_DESIGN_PRINCIPLES.md 中总结维护设计理念、卡点分类/解释/例子、直觉与数据双维难度、趣味定义及其与难度的关系、验收条件及实现边界;不要另建平行的“最新理念”文档。无新结论也记录维护摘要,与规则总表、feedback、PROJECT_PROGRESS同步。最优拖动/每块平均、可行解统计和人工评价必须分开。
  8. 每次用户要求的改动,必须逐项同步检查三个工作台:生成工作台、求解与设计分析台、关卡查重器;以及同一份设计理念文档、规则总表、feedback 和项目记忆。按 PROJECT_PROGRESS.md 第12.1节记录影响矩阵:已同步(具体实现与验证)、已检查无需改动(原因)、未完成(阻碍与下一步)。适用的算法、配置、API、界面、报告与测试必须真正同步,不能只写文档冒充实现;无关工作台不强行改算法。共享模块的改动要验证各消费入口,查重器不因同步要求承担可解性证明。此要求永久适用于复制目录后的接手者。
  9. 用户每次要求“学习/精读”(含学关卡、研究样本、吸收试玩反馈),都自动触发第6~8条的完整同步,不是只写研究笔记,也不需要用户再次提醒“更新生成器”。对已确认、可程序化且在现有任务范围内的结论,当轮落实相关代码/配置/报告/测试;假设不擅自升级为硬规则。无法落实的项目逐项标为未完成,说明证据或实现阻碍与下一步;无关工作台说明无需改动原因。交付逐项区分知识沉淀与工程实现,不以“已经学会”代替验收。
  10. 每次向用户交付或汇报项目改动时,都附上本次相关工作台/文件的可点击打开入口,使用实际存在的绝对路径;不要只报文件夹名。默认生成工作台为根目录 1-生成工作台.command(Mac),Windows 为 1-生成工作台.bat。若提供本地网页地址,必须确认服务正在运行;不要把直接打开 web/index.html 当作可用工作台。此偏好永久随项目交接。