R40: 完成档案编辑扩展与员工导出
这个提交包含在:
@@ -2,4 +2,4 @@ ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regr
|
||||
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。"
|
||||
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 路由模式可以继续平移复用。"
|
||||
|
||||
|
@@ -0,0 +1,5 @@
|
||||
ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
|
||||
R40-0,R40执行合同建档与范围冻结,为档案编辑扩展与员工列表导出创建独立合同并锁定本轮不承接批量导入 考勤增强与批量操作,CSV 校验通过 且明确本轮只做 profile patch 小改动 管理员编辑态与员工导出链路,python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-03-28_17-12-07-r40-profile-edit-and-people-export.csv,none,DONE,DONE,DONE,issues/2026-03-28_17-12-07-r40-profile-edit-and-people-export.csv,[],本轮沿用现有 /employees/:id/profile 与 /exports 基础设施 reviewer 不默认启用
|
||||
R40-1,档案编辑扩展,让 system.users 管理员在员工档案页直接编辑 title hireDate probationEndDate lastWorkingDate 并保持普通员工仅能编辑原 4 个字段,管理员保存 title hireDate probationEndDate lastWorkingDate 后刷新值保持 普通员工打开自己档案时这些字段仍为只读 且 department directManager employeeNo name phone email 维护边界不变,"业务流程: 管理员打开员工档案 修改职位 入职日期 试用期截止和离职日期后保存成功 刷新后值保持。普通员工打开自己档案时 仅 workLocation emergencyContactName emergencyContactPhone notes 可编辑。验证命令: cd server && node --check src/routes/employees.js && cd ../client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,server/src/routes/employees.js|client/src/api/employees.ts|client/src/pages/EmployeeProfilePage.tsx,"[""R40-0""]","已在 PROFILE_PATCH_SCHEMA 与 employee.update 中补写 hireDate,并把 report.dashboard.view 对他人档案的 patch 显式收紧为只读。已验证: cd server && node --check src/routes/employees.js 通过;cd server && npm test -- tests/unit/routes/employees.profile.test.js tests/unit/routes/employees.patch.test.js 通过;cd client && npm run typecheck && npm run build 通过。"
|
||||
R40-2,员工列表导出,在人员管理页按当前筛选条件导出员工列表并复用现有 exports.js 与 blob 下载基础设施,PeoplePage 仅对 system.users 显示导出按钮 导出支持 csv xlsx 并复用 q status departmentId 筛选 产出列为工号 姓名 部门 职位 手机 邮箱 账号状态 入职日期,"业务流程: system.users 用户进入人员管理页 设置 q status departmentId 后导出 CSV 和 Excel 文件内容与筛选一致。仅 report.dashboard.view 用户进入人员管理页时看不到导出按钮。验证命令: cd server && node --check src/routes/exports.js && cd ../client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,server/src/routes/exports.js|client/src/api/exports.ts|client/src/pages/PeoplePage.tsx,"[""R40-0""]","已新增 /api/exports/employees 与 exportEmployees,并在 PeoplePage 复用现有 dropdown + blob 下载模式。已验证: cd server && node --check src/routes/exports.js 通过;cd server && npm test -- tests/unit/routes/exports.employees.test.js 通过;cd client && npm run typecheck && npm run build 通过。"
|
||||
R40-3,QA回归与R37-3继续复盘,按 agent modes 完成 R40 单项验证 状态回填 并记录 hireDate 误判与导出模式复用的后续观察,R40 各状态正确回填 且 Notes 记录 hireDate 需补后端 system.users 与 report.dashboard.view 能力差异 员工导出是否证明 exports.js 模式可继续复用,"业务流程: 验证管理员档案编辑扩展 普通员工只读约束 PeoplePage 按组合筛选导出和非 system.users 无导出入口 并确认 R39 汇报链卡片不回归。验证命令: cd server && node --check src/routes/employees.js && node --check src/routes/exports.js && cd ../client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,issues/2026-03-28_17-12-07-r40-profile-edit-and-people-export.csv|issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv|server/src/routes/employees.js|server/src/routes/exports.js|client/src/pages/EmployeeProfilePage.tsx|client/src/pages/PeoplePage.tsx,"[""R40-1"",""R40-2""]","试跑结论: hireDate 从以为前端可接到确认需补后端 是一次有效纠偏;system.users 与 report.dashboard.view 的能力边界已同时在前端和后端收敛,避免只隐藏按钮但 API 仍可写;员工导出证明 exports.js 模式可继续平移复用。已验证: node --check employees.js/exports.js 通过;server 单测 3 文件 7 测试全部通过;client typecheck/build 通过。"
|
||||
|
在新工单中引用
屏蔽一个用户