continuously-work

name	continuously-work
description	Continuous execution with incremental git commits. After every step or milestone checkpoint, immediately commit. Do not pause for confirmation unless encountering a truly blocking issue. Maintain momentum until all tasks are fully complete.

Continuously Work — 持续执行与渐进提交

1. 核心原则

将任务拆解为可验证的步骤序列。每完成一个步骤或步骤内可独立验证的里程碑节点，立即执行 git commit。除非遇到不解决就无法继续推进的阻塞性问题，否则不停下、不等待用户确认，持续执行直到全部任务完成。

遵循以下铁律：

• 完成即提交：步骤完成 → commit → push，三者不可分割。
• 不停不等：除非客观条件阻断（编译不过、远端冲突、环境不可用、鉴权失败等），否则不中断工作流。
• 渐进推进：每个 commit 是一个可独立回退的原子变更，粒度适中，避免一个 commit 堆砌整个项目。
• 错误即判：遇到错误时自行判断严重性。可绕过、可临时 workaround 的错误，记录后继续；真正阻断的错误，明确描述原因后暂停。

2. 步骤与里程碑定义

步骤（Step）

一个步骤是任务列表中的一项完整工作单元，满足以下条件之一：

• 完成一个独立的功能模块或组件
• 完成一个修复及其验证（测试通过）
• 完成一轮完整的重构（lint / typecheck / test 全部通过）
• 完成一个文件或一组紧密关联文件的编写并验证可编译

里程碑（Milestone）

里程碑是步骤内的中间检查点，在以下时机触发提交：

• 编写完核心逻辑，尚未加测试（先提交一次保存进度）
• 测试编写完毕，尚未全部通过（先提交测试用例）
• 修复了一个子问题，但整体 bug 尚未完全解决
• 批量操作中每完成 N 个文件（N 根据任务规模动态判断，通常 3-5 个文件）
• 完成一个阶段性的文档或配置变更

判断依据

执行过程中自行判断当前是否到达步骤终点或里程碑节点。判断标准：当前完成的工作是否构成一个可描述、可独立回退的变更单元。若是，立即提交。

3. 提交策略

提交消息格式

沿用系统 git 规范，提交消息使用以下格式：

<英文类型>: <中文简述>

<中文正文描述变更内容>

类型说明：

类型	用途
feat	新增功能、模块、能力
fix	修复 bug、错误行为
refactor	结构调整、代码整理（行为不变）
test	新增或修改测试
chore	配置、依赖、构建、工具链变更
docs	文档变更

提交粒度

• 每个 commit 聚焦单一变更主题，不混合不相关的修改。
• 批量文件操作（如重命名、格式化）可合并在一个 commit，但正文中需列出范围。
• 单文件大规模修改值得独立 commit，便于回退。

提交前自动检查

在 commit 前执行以下检查（按项目类型调整）：

Python 项目：

uv run python -m py_compile <changed_files>
uv run python -m compileall -q .
uv run --with pytest pytest -q

前端项目：

pnpm lint
pnpm typecheck  # 如有
pnpm test

检查失败时的处理：见第 4 节错误分级。

4. 错误分级与处置

严重程度定义

级别	描述	处置
P0 阻断	编译/构建失败、远端冲突无法自动解决、环境依赖缺失导致无法运行、测试大面积失败且原因不明	暂停执行，明确描述问题后等待用户介入
P1 可绕过	单个测试失败但原因明确、lint 警告（非 error）、类型错误在非关键路径、非核心功能受影响	记录问题，继续推进，在后续步骤中修复
P2 可忽略	格式差异、现有技术债、非本次变更引入的问题	忽略，不中断流程

P0 阻断判定标准

仅以下情况属于 P0 阻断：

1. 代码编译/转译失败，且错误并非本次变更引入的语法错误（语法错误应立即修复）
2. 项目依赖无法安装（网络问题、包不存在等）
3. 测试全部失败，错误信息指向环境配置问题而非代码逻辑问题
4. 关键文件被意外删除且无法从 git 恢复

不属于 P0 阻断的情况：单元测试部分失败（有明确原因）、lint 警告、类型注解缺失、已有技术债暴露。

P1 处理流程

1. 将警告/错误记录到当前步骤的上下文
2. 在后续合适时机修复
3. 修复完成后作为独立 commit 提交

5. Stash 与工作区卫生

开始前

• 确保工作区干净或仅有与当前任务相关的变更。
• 如有无关变更，先 stash 或提醒用户处理。
• 检查命令：git status --porcelain

进行中

• 保持工作区整洁，不累积临时文件。
• 不属于版本控制的生成文件加入 .gitignore。

完成后

• 确认 git status 干净，无未提交变更。

6. 回退就绪

每个 commit 保持原子性，确保可以单独 revert：

• git revert <commit> 应能干净地撤销任一步骤。
• 避免一个 commit 包含不可分割的跨模块修改（除非这些修改逻辑上强耦合）。
• 如果发现某步出错，优先在当前工作区修复并追加 commit，而非 revert 后重做。

7. 任务完成总结

全部步骤完成后，生成简要总结：

任务完成：<任务简述>
提交记录（共 N 个 commit）：
- abc1234 feat: <简述>
- def5678 fix: <简述>
- ...
状态：全部步骤已完成 | 远端已同步 | 工作区干净
遗留问题（如有）：...

8. 禁止模式

以下模式在持续执行场景下严禁：

• 在步骤之间等待用户确认（除非 P0 阻断）
• 询问"是否继续下一步"
• 在一个 commit 中堆积多个不相关的变更以"减少提交次数"
• 跳过测试或 lint 检查仅为了加快提交速度
• 在工作区遗留未提交变更即宣告任务完成