6 行
4.2 KiB
CSV
6 行
4.2 KiB
CSV
ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
|
|
R37-0,R37治理合同补建与范围冻结,为 AGENTS 多 agent 规则更新补建治理合同并锁定本轮仅做治理文档与提交准备,新 CSV 校验通过 且范围明确为 AGENTS agent modes 固化与提交留痕 不承接业务代码改动,python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv,none,DONE,DONE,DONE,issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv,[],"本轮仅治理协作规则与提交流程；不修改 server/src 或 client/src 业务代码。"
|
|
R37-1,Agent modes 治理规则固化与 review 修订落地,将 3 常驻加 2 按需模式固化到 AGENTS 并落实 qa 写权限 Test_Method 语义和 backend post-check 三处修订,AGENTS.md 包含 Agent modes 段落 且三处修订与现有 issues/README 和 docs/mcp-tools 边界一致,1) git diff --check 2) 核对 AGENTS.md 中 mode:qa 允许写 issues/*.csv 与 scripts/ 3) 核对回滚说明已移入 Notes 约束 4) 核对 backend post-check 已改为按变更类型执行,manual,DONE,DONE,DONE,AGENTS.md,"[""R37-0""]","若后续证明规则过严或过松，回滚方式为还原本次 Agent modes 段落并保留 CSV 审计记录。"
|
|
R37-2,治理变更提交与审计留痕,提交 AGENTS 与治理 CSV 变更并使用中文 commit message 引用本 Issue ID,生成 1 个仅包含治理变更的 commit 且 git log 最新提交可见 Issue ID,"1) git diff --stat 确认仅含 AGENTS.md 与 issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv 2) git commit -m ""R37: 固化 Agent modes 治理规则"" 3) git log -1 --oneline",manual,DONE,DONE,DONE,AGENTS.md|issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv,"[""R37-1""]","commit 仅承载治理变更；若提交前发现额外文件改动则先停止并重新确认范围。"
|
|
R37-3,下个真实迭代按新模式试跑并复盘,在后续一个同时涉及 backend frontend qa 的真实迭代中按新 Agent modes 跑一次并记录阻塞点,至少完成 1 次真实试跑 并能说明 handoff QA 回填 reviewer 触发条件是否顺畅,"1) 选择一个同时涉及 server/ 与 client/ 的真实 issue 组 2) 按 Agent modes 执行 3) 在 Notes 或后续治理 issue 中记录问题与修订建议",manual,DONE,DONE,DONE,TBD,"[""R37-2""]","已用 R38 员工管理试跑完成一次真实迭代。结论: Files 派工整体清晰 backend 侧唯一摩擦点是 /employees 复用 usersRoutes 需要显式 allowDepartmentFilter；QA 回填顺畅 命令式验证和合同状态映射明确；reviewer 触发条件当前无需细化 本轮未触及权限模型 状态机 workflow 或迁移。R39 后续观测: 围绕单一 profile 响应做 backend/frontend handoff 比 R38 更清晰 扩现有接口比新建专用端点更顺；qa-runner 的新增经验是即使 shell 初始 PATH 缺少 Node，也可通过显式注入 NVM 路径完成验证，R39 最终已完成 node --check、后端单测、client typecheck 和 build。R40 后续观测: 同页中的可看 可改 可导出边界不能只靠前端，最终需要前后端同时收口；hireDate 这类“看起来已有字段”的需求仍要先核对 PATCH schema 与 update data，再决定是否是纯前端改动；员工导出验证了 exports.js 路由模式可以继续平移复用。R41 后续观测: 日常运营类导入继续放在 system.users 域内比挂到 cutover console 更顺，Files 派工也更清晰；qa-runner 在这轮除了命令验证，还额外覆盖了 multipart 上传与一次性密码清单下载这类结果物校验；reviewer 仍无需默认启用，但同批上级引用会引入两阶段创建与 direct_manager_id 回填，这类跨行依赖以后仍应优先判定为后端主导问题。R42 后续观测: 这轮把 presence 历史读模型抽到共享服务后，backend 到 frontend 到 qa 的 handoff 更清晰，portal 与团队页不再各自维护一套考勤口径；exports.js 继续复用业务域服务依然顺手，说明导出模式还能沿用；reviewer 触发条件应从笼统的“权限/状态机/workflow”细化到“新增 source 或调整覆盖优先级”这类读模型语义变更。"
|