wangsli/hyb-oa
1
0
派生 0
代码 工单 合并请求 工作流 8 软件包 项目 发布 百科 活动

R39: 完成员工档案汇报链查询

浏览代码
这个提交包含在：
wangsli
2026-03-28 17:42:09 +08:00
父节点 f33431fdb8
当前提交 1cac1447b1
共修改 6 个文件，包含 347 行新增和 9 行删除
下载 Patch 文件 下载 Diff 文件 展开所有文件 折叠所有文件
issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv
+1 -1
查看文件
@@ -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 或迁移。"
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。"
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 或迁移。 已用 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。
issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv
+5
查看文件
@@ -0,0 +1,5 @@
ID,Title,Description,Acceptance,Test_Method,Tools,Dev_Status,Review1_Status,Regression_Status,Files,Dependencies,Notes
R39-0,R39执行合同建档与范围冻结,为员工档案页汇报链查询创建独立合同并锁定本轮只做 profile 读模型扩展与档案页只读展示,CSV 校验通过 且明确本轮不承接独立组织页 PeoplePage 总览 汇报关系编辑与权限口径重构,python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv,none,DONE,DONE,DONE,issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv,[],本轮继续沿用现有 GET /employees/:id/profile 权限门与响应入口 若实现中发现负载过重仅记录到复盘 不当轮拆专用端点
R39-1,员工档案汇报链读模型与接口扩展,扩展 GET /employees/:id/profile 返回 organization.reportingChain 与 organization.directReports 读模型,profile 响应稳定返回 organization.reportingChain 与 organization.directReports reportingChain 顺序为最高层到当前员工 directReports 仅含直属下级且坏数据循环不会导致接口失败,"业务流程: 管理员打开某普通员工档案接口返回完整上行汇报链 打开某经理档案接口返回直属下级列表 顶层负责人仅返回本人 archived 上级或下级仍带状态展示。验证命令: cd server && node --check src/routes/employees.js && npm test -- tests/unit/routes/employees.profile.test.js",manual,DONE,DONE,DONE,server/src/routes/employees.js|server/tests/unit/routes/employees.profile.test.js,"[""R39-0""]","后端仅扩现有 profile 响应 不新增 /reporting-line 专用端点。已实现 buildEmployeeOrganization 循环保护和最大深度保护 并通过 __testables 暴露给单测。已验证: node --check src/routes/employees.js 通过；npm test -- tests/unit/routes/employees.profile.test.js 3/3 通过。"
R39-2,员工档案页汇报链卡片,在员工档案页右侧新增汇报链与直属下级只读卡片并扩展前端类型接线,EmployeeProfilePage 右侧在离职阻塞项下方展示汇报链与直属下级 使用现有 StatusBadge 无上级或无下级时显示稳定空态 且不影响现有档案编辑与生命周期展示,"业务流程: 管理员进入员工档案页 在右侧看到汇报链卡片与直属下级卡片 当前员工作为汇报链最后一项 archived 节点带状态标识 无直属下级时显示暂无直属下级。验证命令: cd client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,client/src/api/employees.ts|client/src/pages/EmployeeProfilePage.tsx,"[""R39-0"",""R39-1""]","前端已接入 EmployeeProfile.organization 并在右侧新增汇报链/直属下级卡片 不新增导航或组织树交互。已验证: cd client && npm run typecheck 通过；cd client && npm run build 通过。"
R39-3,QA回归与R37-3后续观测补充,按 agent modes 完成 R39 单项验证 最小回归 CSV 状态回填 并补充这轮 handoff 复盘,后端与前端验证通过 R39 各状态正确回填 且 Notes 记录扩 profile 响应与新建专用端点的取舍 以及 backend frontend qa handoff 观察,"业务流程: 验证普通员工档案的完整上行汇报链 经理档案的直属下级 顶层负责人仅显示本人 无下级员工显示空态 archived 节点带状态标识 并确认 PeoplePage 与 DepartmentsPage 未受影响。验证命令: cd server && node --check src/routes/employees.js && npm test -- tests/unit/routes/employees.profile.test.js && cd ../client && npm run typecheck && npm run build",manual,DONE,DONE,DONE,issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv|issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv|server/src/routes/employees.js|client/src/api/employees.ts|client/src/pages/EmployeeProfilePage.tsx,"[""R39-1"",""R39-2""]","试跑观察: 扩现有 profile 响应比新建专用端点更顺 因为权限门 查询入口和缓存 key 都可直接复用；backend/frontend handoff 比 R38 更清晰 这次契约直接围绕单一 profile 响应组织 边界更窄；reviewer 仍无需默认启用 但若后续扩到组织架构浏览或权限口径调整 再单独引入。已解决命令环境问题: 通过显式注入 NVM PATH 执行 node/npm。最小回归结果: server node --check 通过，server 单测 3/3 通过，client typecheck/build 通过。"
1 ID Title Description Acceptance Test_Method Tools Dev_Status Review1_Status Regression_Status Files Dependencies Notes
2 R39-0 R39执行合同建档与范围冻结 为员工档案页汇报链查询创建独立合同并锁定本轮只做 profile 读模型扩展与档案页只读展示 CSV 校验通过 且明确本轮不承接独立组织页 PeoplePage 总览 汇报关系编辑与权限口径重构 python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv none DONE DONE DONE issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv [] 本轮继续沿用现有 GET /employees/:id/profile 权限门与响应入口 若实现中发现负载过重仅记录到复盘 不当轮拆专用端点
3 R39-1 员工档案汇报链读模型与接口扩展 扩展 GET /employees/:id/profile 返回 organization.reportingChain 与 organization.directReports 读模型 profile 响应稳定返回 organization.reportingChain 与 organization.directReports reportingChain 顺序为最高层到当前员工 directReports 仅含直属下级且坏数据循环不会导致接口失败 业务流程: 管理员打开某普通员工档案接口返回完整上行汇报链 打开某经理档案接口返回直属下级列表 顶层负责人仅返回本人 archived 上级或下级仍带状态展示。验证命令: cd server && node --check src/routes/employees.js && npm test -- tests/unit/routes/employees.profile.test.js manual DONE DONE DONE server/src/routes/employees.js|server/tests/unit/routes/employees.profile.test.js ["R39-0"] 后端仅扩现有 profile 响应 不新增 /reporting-line 专用端点。已实现 buildEmployeeOrganization 循环保护和最大深度保护 并通过 __testables 暴露给单测。已验证: node --check src/routes/employees.js 通过；npm test -- tests/unit/routes/employees.profile.test.js 3/3 通过。
4 R39-2 员工档案页汇报链卡片 在员工档案页右侧新增汇报链与直属下级只读卡片并扩展前端类型接线 EmployeeProfilePage 右侧在离职阻塞项下方展示汇报链与直属下级 使用现有 StatusBadge 无上级或无下级时显示稳定空态 且不影响现有档案编辑与生命周期展示 业务流程: 管理员进入员工档案页 在右侧看到汇报链卡片与直属下级卡片 当前员工作为汇报链最后一项 archived 节点带状态标识 无直属下级时显示暂无直属下级。验证命令: cd client && npm run typecheck && npm run build manual DONE DONE DONE client/src/api/employees.ts|client/src/pages/EmployeeProfilePage.tsx ["R39-0","R39-1"] 前端已接入 EmployeeProfile.organization 并在右侧新增汇报链/直属下级卡片 不新增导航或组织树交互。已验证: cd client && npm run typecheck 通过；cd client && npm run build 通过。
5 R39-3 QA回归与R37-3后续观测补充 按 agent modes 完成 R39 单项验证 最小回归 CSV 状态回填 并补充这轮 handoff 复盘 后端与前端验证通过 R39 各状态正确回填 且 Notes 记录扩 profile 响应与新建专用端点的取舍 以及 backend frontend qa handoff 观察 业务流程: 验证普通员工档案的完整上行汇报链 经理档案的直属下级 顶层负责人仅显示本人 无下级员工显示空态 archived 节点带状态标识 并确认 PeoplePage 与 DepartmentsPage 未受影响。验证命令: cd server && node --check src/routes/employees.js && npm test -- tests/unit/routes/employees.profile.test.js && cd ../client && npm run typecheck && npm run build manual DONE DONE DONE issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv|issues/2026-03-28_12-36-28-r37-agent-modes-governance.csv|server/src/routes/employees.js|client/src/api/employees.ts|client/src/pages/EmployeeProfilePage.tsx ["R39-1","R39-2"] 试跑观察: 扩现有 profile 响应比新建专用端点更顺 因为权限门 查询入口和缓存 key 都可直接复用；backend/frontend handoff 比 R38 更清晰 这次契约直接围绕单一 profile 响应组织 边界更窄；reviewer 仍无需默认启用 但若后续扩到组织架构浏览或权限口径调整 再单独引入。已解决命令环境问题: 通过显式注入 NVM PATH 执行 node/npm。最小回归结果: server node --check 通过，server 单测 3/3 通过，client typecheck/build 通过。