study-tool
585a7a28dd
- settings: study.mode fast|normal and study.parallel 1-5 - normal mode: one headless browser per video, visibility keep-alive, auto-degrade when the platform enforces order - report study/log/detail/save before isComplete; drop lastProgressTime on completion - complete periodType 10/13 container nodes and recompute counters via PUT calFinalScore - capture mode: POST /api/capture records all XHR/fetch including new tabs - UI: study mode in settings, capture / stop-capture menu items
2.6 KiB
2.6 KiB
AGENTS.md
本文档用于约束本项目中的 AI / 自动化开发行为。开发时优先遵循本文件，其次遵循用户当前消息。
基本原则
- 先读现有代码，再动手修改，优先沿用项目已有结构和写法。
- 写代码保持最少行数，能简单实现就不要引入复杂抽象。
- 标准格式、协议、解析、压缩、加密、日期等通用能力优先使用成熟稳定的库，不要手写底层实现，除非用户明确要求或项目已有实现必须沿用。
- 不要为了“兼容更多场景”写大量分支，只实现当前明确需要的功能。
- 项目尚未上线，不需要兼容旧数据；表结构或字段调整时直接按新设计修改，不写旧字段兼容、数据迁移兜底或删除旧表的清理逻辑，除非用户明确要求。
- 每次写完代码，不需要检查语法，不需要执行构建，用户会自己做。
- 不要改无关文件，不要顺手重构。
- 任何文件编辑、改动、删除或格式化前，必须先询问用户是否允许；只有得到明确同意后才能修改。
- 如果工作区已有用户改动，不要回滚，不要覆盖；只在必要范围内追加修改。
反复提醒沉淀
- 如果开发过程中总是遇到某个问题，或者用户反复提醒同一个注意事项，需要把该注意事项补充到本文件。
- 补充时写成明确、可执行的规则，避免只写模糊描述。
- 新规则应放到最相关的章节；找不到合适章节时放到“项目注意事项”。
文档规范
- README 保持简洁，只放项目介绍、核心功能、快速开始和文档入口。
- 后续待办写到
docs/progress/todo.md。 - 已实现但还需要用户测试确认的事项写到
OPTIMIZATION.md。 - 每次任务完成前，都要根据实际变更检查并更新
OPTIMIZATION.md和OPTIMIZATION.md；如果功能或待办没有变化，也要确认无需修改。 - 文档不要写过期日期；除非用户明确要求记录具体时间。
发版本流程
- 发版本时，先把
CHANGELOG.md的Unreleased变更整理成新的版本记录，并保留空的Unreleased标题。 - 每次提交必须将当前版本号进行提升，更新
metadata.yaml里面的version中的版本号。 - 将当前未提交的代码全部提交到 Git。
- 提交完成后，给当前提交打最新版本号对应的 tag，例如
v0.0.5。 - 发版本流程中不要执行编译、测试或构建，除非用户明确要求。
- 如果触发重要的决策，你需要将代码提交到
git中，并且将本次已经修改的内容进行总结