hyb-oa/issues/2026-03-28_15-35-48-r39-employee-reporting-line.csv

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 通过。