R41: 完成员工批量导入

这个提交包含在:
2026-03-28 18:57:02 +08:00
父节点 2eff8e01a2
当前提交 3cf8b43f74
共修改 7 个文件,包含 1477 行新增和 63 行删除
@@ -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。R40 后续观测: 同页中的可看 可改 可导出边界不能只靠前端,最终需要前后端同时收口;hireDate 这类“看起来已有字段”的需求仍要先核对 PATCH schema 与 update data,再决定是否是纯前端改动;员工导出验证了 exports.js 路由模式可以继续平移复用。"
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 回填,这类跨行依赖以后仍应优先判定为后端主导问题。"
1 ID Title Description Acceptance Test_Method Tools Dev_Status Review1_Status Regression_Status Files Dependencies Notes
2 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 业务代码。
3 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 审计记录。
4 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 仅承载治理变更;若提交前发现额外文件改动则先停止并重新确认范围。
5 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 路由模式可以继续平移复用。 已用 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 回填,这类跨行依赖以后仍应优先判定为后端主导问题。
@@ -0,0 +1,5 @@
ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
R41-0,R41执行合同建档与范围冻结,为员工批量导入创建独立合同并冻结本轮只做员工加账号一体化导入 不承接考勤增强与 mixed-mode 导入,CSV 校验通过 且明确导入语义为员工档案 账号 角色一起创建 初始密码为系统生成的一次性口令,"python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-03-28_17-58-04-r41-user-bulk-import.csv",none,DONE,DONE,DONE,issues/2026-03-28_17-58-04-r41-user-bulk-import.csv,[],"合同已建档并校验通过。本轮入口固定在 UserManagementPage,不复用 cutover_console_v1 与 migration-runs。"
R41-1,用户批量导入后端 dry-run 与 apply,在 users 域内新增批量导入 dry-run apply 两个接口 支持 csv xlsx 校验预览与全量事务写入,管理员可上传模板文件执行 dry-run 获得逐行错误与标准化预览 apply 成功时整批创建 employee 与 employee_roles 并返回一次性密码清单 任一行失败整批回滚,"业务流程: system.users 用户上传员工模板 执行 dry-run 后查看行级错误 再 apply 成功创建账号与员工。验证命令: cd server && node --check src/routes/users.js && npm test -- tests/unit/routes/users.import.test.js",manual,DONE,DONE,DONE,server/src/routes/users.js|server/tests/unit/routes/users.import.test.js,"[""R41-0""]","已新增 /api/users/import/dry-run 与 /api/users/import/apply,支持 csv xlsx 解析 文件内重复校验 部门精确匹配 同批上级引用 与全量事务回滚。已验证: node --check src/routes/users.js 通过;npm test -- tests/unit/routes/users.import.test.js 5/5 通过;npm test -- tests/unit/routes/users.list.test.js 3/3 通过。"
R41-2,用户管理页导入入口与密码清单下载,在 UserManagementPage 增加批量导入弹窗 支持模板下载 文件上传 dry-run 结果展示 apply 与一次性密码清单下载,用户管理页显示批量导入按钮 dry-run 有错误时 apply 不可用 apply 成功后可下载 employeeNo name email oneTimePassword 清单 不影响现有单条新建流程,"业务流程: 管理员打开用户管理页 下载模板 上传 csv xlsx 执行 dry-run 查看结果 再 apply 并下载密码清单。验证命令: cd client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,client/src/api/users.ts|client/src/pages/UserManagementPage.tsx|client/src/pages/user-management/UserImportDialog.tsx,"[""R41-0"",""R41-1""]","已新增 UserImportDialog 和 users import API 类型;前端不重写业务校验,只透传后端行号 字段 错误信息。已验证: cd client && npm run typecheck 通过;cd client && npm run build 通过。"
R41-3,QA回归与R37-3继续复盘,完成批量导入单项验证 状态回填 并把导入域与 cutover 域的边界观察补充到治理复盘,R41 各状态正确回填 且 Notes 记录为何不复用 cutover console 为什么员工导入继续沿用 users 域语义,"业务流程: 验证 dry-run 缺表头 重复值 部门错误 上级错误 apply 全量回滚 apply 成功 下载密码清单 非 system.users 无入口 且单条新建 启停 角色分配不回归。验证命令: cd server && node --check src/routes/users.js && npm test -- tests/unit/routes/users.import.test.js && cd ../client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,issues/2026-03-28_17-58-04-r41-user-bulk-import.csv|issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv|server/src/routes/users.js|client/src/pages/UserManagementPage.tsx,"[""R41-1"",""R41-2""]","复盘结论: 员工导入继续留在 system.users 域内比挂到 cutover console 更清晰,因为它是日常运营动作而不是迁移动作;dry-run 再 apply 的双阶段足够顺畅,且能在 apply 阶段重跑校验避免文件变更或库状态漂移;同批上级工号引用可落地,但实现上需要后端显式做两阶段创建和二次回填 direct_manager_id。"
1 ID Title Description Acceptance Test_Method Tools Dev_Status Review1_Status Regression_Status Files Dependencies Notes
2 R41-0 R41执行合同建档与范围冻结 为员工批量导入创建独立合同并冻结本轮只做员工加账号一体化导入 不承接考勤增强与 mixed-mode 导入 CSV 校验通过 且明确导入语义为员工档案 账号 角色一起创建 初始密码为系统生成的一次性口令 python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-03-28_17-58-04-r41-user-bulk-import.csv none DONE DONE DONE issues/2026-03-28_17-58-04-r41-user-bulk-import.csv [] 合同已建档并校验通过。本轮入口固定在 UserManagementPage,不复用 cutover_console_v1 与 migration-runs。
3 R41-1 用户批量导入后端 dry-run 与 apply 在 users 域内新增批量导入 dry-run apply 两个接口 支持 csv xlsx 校验预览与全量事务写入 管理员可上传模板文件执行 dry-run 获得逐行错误与标准化预览 apply 成功时整批创建 employee 与 employee_roles 并返回一次性密码清单 任一行失败整批回滚 业务流程: system.users 用户上传员工模板 执行 dry-run 后查看行级错误 再 apply 成功创建账号与员工。验证命令: cd server && node --check src/routes/users.js && npm test -- tests/unit/routes/users.import.test.js manual DONE DONE DONE server/src/routes/users.js|server/tests/unit/routes/users.import.test.js ["R41-0"] 已新增 /api/users/import/dry-run 与 /api/users/import/apply,支持 csv xlsx 解析 文件内重复校验 部门精确匹配 同批上级引用 与全量事务回滚。已验证: node --check src/routes/users.js 通过;npm test -- tests/unit/routes/users.import.test.js 5/5 通过;npm test -- tests/unit/routes/users.list.test.js 3/3 通过。
4 R41-2 用户管理页导入入口与密码清单下载 在 UserManagementPage 增加批量导入弹窗 支持模板下载 文件上传 dry-run 结果展示 apply 与一次性密码清单下载 用户管理页显示批量导入按钮 dry-run 有错误时 apply 不可用 apply 成功后可下载 employeeNo name email oneTimePassword 清单 不影响现有单条新建流程 业务流程: 管理员打开用户管理页 下载模板 上传 csv xlsx 执行 dry-run 查看结果 再 apply 并下载密码清单。验证命令: cd client && npm run typecheck && npm run build manual DONE DONE DONE client/src/api/users.ts|client/src/pages/UserManagementPage.tsx|client/src/pages/user-management/UserImportDialog.tsx ["R41-0","R41-1"] 已新增 UserImportDialog 和 users import API 类型;前端不重写业务校验,只透传后端行号 字段 错误信息。已验证: cd client && npm run typecheck 通过;cd client && npm run build 通过。
5 R41-3 QA回归与R37-3继续复盘 完成批量导入单项验证 状态回填 并把导入域与 cutover 域的边界观察补充到治理复盘 R41 各状态正确回填 且 Notes 记录为何不复用 cutover console 为什么员工导入继续沿用 users 域语义 业务流程: 验证 dry-run 缺表头 重复值 部门错误 上级错误 apply 全量回滚 apply 成功 下载密码清单 非 system.users 无入口 且单条新建 启停 角色分配不回归。验证命令: cd server && node --check src/routes/users.js && npm test -- tests/unit/routes/users.import.test.js && cd ../client && npm run typecheck && npm run build manual DONE DONE DONE issues/2026-03-28_17-58-04-r41-user-bulk-import.csv|issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv|server/src/routes/users.js|client/src/pages/UserManagementPage.tsx ["R41-1","R41-2"] 复盘结论: 员工导入继续留在 system.users 域内比挂到 cutover console 更清晰,因为它是日常运营动作而不是迁移动作;dry-run 再 apply 的双阶段足够顺畅,且能在 apply 阶段重跑校验避免文件变更或库状态漂移;同批上级工号引用可落地,但实现上需要后端显式做两阶段创建和二次回填 direct_manager_id。