13 lines
3.3 KiB
Markdown
13 lines
3.3 KiB
Markdown
# Codex 工作区约定
|
||
|
||
1. 开始任何任务前，必须完整阅读根目录 [`PROJECT_PROGRESS.md`](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` 当作可用工作台。此偏好永久随项目交接。
|