Session handover: project state, pending decisions, and 12 UI findings from the manual screenshots

[baozhoutao]

会话交接记录(2026-09-03)。原会话 session_01VR2khJ3Me96btawVsfG6jb 结束,本文记录接手方需要知道的全部状态。本工作项不派开发,只做交接留痕;其中第三节的界面问题待维护者决定是否立单。

一、当前状态

main 在 4a02994,CI(verify = validate + typecheck + vitest)每次 PR 与合入都跑,当前绿。无未合并 PR,无未推送改动,远端只剩 main 与平台指定分支 claude/standard-assessment-system-qvswav。

已交付

内容	位置
需求基准	docs/00-设计方案.md —— 第 1~10 章为客户 2026-09-02 确认的 V1.0 口径(不得擅改);第 11 章为 V1.1 送审稿的产品化补充,待客户确认
需求解读、总体蓝图	docs/01、docs/02(V0.3)
客户原始需求	docs/需求/KPI考核管理系统-功能性需求文档-V1.3.md
Word 成品	docs/交付/:设计方案 V0.9 / V1.0 / V1.1、操作手册 V0.1;由 pnpm docs:docx 与 pnpm docs:manual 从 markdown 源生成
分角色操作手册	docs/手册/(源稿 + 62 张真实截图)
应用	17 个业务对象、计分引擎、审核状态机、按方案动态共享规则、四维汇总、归档快照;单元测试 90、端到端 73

已合并的工作项:#2 数据范围动态共享、#5 共享服务加固、#9 设计基准 V1.0 与文档整改、#10 代码对齐确认口径、#13 界面术语。全部处于 status:PM验收中,等验收侧处理。

二、等客户/维护者拍板的事

1. 设计方案 V1.1 第 18~35 项(第 11 章 11.9 表 14):18 项产品化补充,每项给了产品默认、备选与建议档次(一期补强 9 项 / 二期 7 项 / 产品化候选 2 项)。客户逐条回复「同意默认 / 改为 X / 删除」后,文档升 V2.0,再按档次细化工作项。在此之前不要就这些内容立开发工作项。
2. 设计方案封面的编制方与客户方单位全称仍是占位「(待项目经理填写单位全称)」。
3. 第三节的 12 处界面问题是否立成缺陷工作项。
4. UI copy follow-ups: 「考核部门(出指标方)」 label ambiguity and missing English bundle entry for staff assignments</title> <parameter name="labels">["P3", "status:待细化"] #15(P3)「考核部门(出指标方)」的正式术语需需求侧确认后才能派发。

三、手册截图过程中发现的 12 处界面问题(尚未立单)

用各岗位真实账号走完整业务线时发现,均可复现,按影响排序:

1. 对象名与部分字段名显示英文:Entry Sheet / Entry Line / Indicator / Assessment Plan / Target / Weight (%) / Actual / Completion (%) / STATUS / FINAL SCORE 等。i18n.defaultLocale 已是 zh-CN,平台自身文案是中文,但这些 label 落到了 en 回退。
2. 报错提示带技术前缀:发布完整性检查、提交拦截等 toast 以 KpiError: 开头,违反 std-copy 红线②(禁异常原文)。业务正文本身是三段式,合格。
3. 审核记录列表渲染内部状态值:「原状态 / 新状态」列直接显示 draft / branch_checking / hr_reviewing / leader_approving / approved / archived,未映射为业务叫法(红线①)。
4. 核对任务确认后「处理人 / 处理时间」未盖章:执行「确认无误 / 提出争议」后两列仍为「—」。
5. 新建加减分、数据调整时「状态」为必填且无默认值:该字段本应由流程盖章、对用户只读。
6. 结果看板「人员得分」轴显示用户 id 而非姓名;「各组织单元平均得分」出现「(未指定)」柱(分管领导维度结果的组织单元为空)。
7. 填报单队列页签溢出:1440 宽下只显示 4 个,待领导审批 / 已通过 / 已归档 / 流程看板收进「还有 4 个」,分管领导找不到自己的队列。
8. 记录详情页没有「编辑」入口:参与主体等对象只能回列表行内编辑,而到人分工的浮层里有「编辑」,各对象不一致。
9. 明细行项按钮未汉化:Add line / Total / Columns。
10. 填报明细相关列表出现重复列:同时有「指标」与「Indicator」两列。
11. 日期显示为相对时间:方案「周期结束」显示「3 天前」而非日期。
12. 相关列表滚动时行内容压住页签栏(粘性头层级)。

判定:1、9、10、11、12 属平台通用渲染器行为,按 CLAUDE.md 只上报 objectstack-ai/objectstack,不在平台仓提交修复 PR;2、3、4、5、6 属本应用可修。

四、流程口径的一处实际问题

默认四节点流程下,人力审核驳回只能退到「分公司核对中」,而分公司核对人员对填报单只有读权限、没有驳回按钮,填报单退不回部门重填。这与已确认的第 10 章第 8 项(退回上一节点)一致,但实际不好用。手册 3.5 按现状写了两条可行路径。建议随 V1.1 第 27 项(审批人来源扩展与可配置退回节点)一并确认。

五、流程约定(接手方必读)

CLAUDE.md 是权威,以下是最容易踩的几条:

• 开发一律走 os-project-pm-dispatch:立工作项 → 认领(评论带会话 ID 与分支)→ 派 os-dev 子 agent 在独立 worktree 开发 → 收单核实(逐项跑命令,不采信自述)→ 独立评审子 agent 闸门(冷启动、只读)→ 阻塞与应修清零后由调度员合并。调度员不写业务代码、不自评。
• 平台问题只上报不修复:不认领平台 issue、不在平台仓开 PR;应用侧只允许带环境闸门的临时夹具并注明对应平台 issue。
• 方案分级要点、需求符合度清单、测试报告挂工作项评论,不作为 docs/ 文件维护;基准定稿前不出蓝图/分级/符合度/测试报告类文档(出早了必反复改版)。
• 测试取证截图禁止入库(走孤儿分支 acceptance-evidence);例外:操作手册配图随源稿归档在 docs/手册/图片/。
• PR 合并后 head 分支由 GitHub 自动删除;会话内 git push --delete 被代理拒绝,不要重试。
• 计分口径唯一真值 src/lib/scoring.ts,状态机唯一真值 src/hooks/sheet.hook.ts,禁在视图或公式字段里二次实现。

六、遗留的临时夹具

src/data/align-demo-units.ts:演示种子的组织单元 organization_id 为空,启动时补齐。这是平台缺陷 objectstack-ai/objectstack#14547 的临时夹具,只在 dev / test 生效,平台修复后连同 objectstack.config.ts 里的调用一起删除。

七、流程 skill 的改进建议

本项目实战中发现的 skill 问题已提到 baozhoutao/os-project-skills #66~#73(文档产出时机、设计方案作为基准的路径、敏感词检索范围、Word 归档、无 gh CLI 的替代出口、只上报不修复、评审轮次纪律、接口级证据档位)。接手方遇到同类问题可先查这批 issue。

[baozhoutao]

第三节界面问题的处置(2026-09-03,维护者拍板:只上报平台问题,应用侧缺陷等 V1.1 确认后再立单)

接手会话在独立实例(17.2.0,端口 3107,独立数据库)逐项复核后,平台侧问题已按「只上报不修复」提交到 objectstack-ai/objectstack:

第三节编号	平台 issue	复核结论
1 对象/字段名显示英文(含 10 的「指标 / Indicator 双列」)	objectstack-ai/objectstack#14882	服务端复现:Accept-Language: zh-CN 请求 /meta/object/kpi_entry_sheet 返回 Entry Sheet / Sheet / Status / Final Score;成因是 spec 的 localeChain 把回退链写死为 ['en'],不读 i18n.fallbackLocale,凡 zh-CN 包没提到的对象都先查 en 包再落回中文原文。10 不是独立缺陷:indicator(无 en 词条→指标)与 indicator_name(有 en 词条→Indicator)并列所致,随 1 一起消失
7 队列页签溢出	objectstack-ai/objectstack#14883	1440 宽实测:页签栏 1152px,只显示 4 个,「还有 4 个」;成因是视图页签组件 maxVisibleTabs 默认写死 4,不按宽度计算
9 Add line / Total 未汉化	objectstack-ai/objectstack#14884	行项目子表组件把 Add line、Total 写成英文字面量,未走词典;Columns 未定位到源码,已在 issue 里注明
11 日期显示相对时间	objectstack-ai/objectstack#14885	日期字段格式化器对「今天前后 7 天内」的值一律输出相对时间(3天前),之外才显示日期,所以同一行「周期开始 8月1日 / 周期结束 3天前」
12 相关列表压住页签栏	objectstack-ai/objectstack#14886	按手册截图上报;可能是网格固定操作列 sticky z-10 与页签栏层级之争,issue 中已标明「未做二分定位」
8 详情页无「编辑」入口	未上报	以管理员账号复核 不能复现:指标详情页、参与主体详情页(抽屉与整页)右上角均有蓝色「编辑」按钮。手册截图时用的是岗位账号,更可能是该岗位权限集/共享级别没放开编辑,属应用侧。建议留在本单待细化,等应用侧缺陷批次时用岗位账号复现后再定

应用侧可修的 2、3、4、5、6 按拍板暂不立单,待设计方案 V1.1 第 18~35 项确认后与一期补强项一起排。

另:本会话环境有 gh CLI(登录 baozhoutao),第五节「GitHub 只能用 MCP 工具」在本环境不成立,后续会话可先 gh auth status 再决定走哪条路。

[baozhoutao]

第三节补充第 13 处(2026-09-03,维护者浏览 3107 实例时发现)

现象:管理员在「填报单」列表点「新建」手工建了一张填报单(主体 华东分公司),打开详情页顶部红框报错 Component "page:header" failed to render / Minified React error #31,其余部分正常。

成因(已复核):

• 平台侧:记录的 name 为空时,页头标题回退到 subject 查找字段,把展开的组织单元对象直接当 React 子节点渲染 → 崩溃。已上报 [repo:objectui] page:header crashes with React #31 when the record's name field is empty — the title fallback picks a lookup field and renders its expanded record object as a JSX child objectstack#14888(只上报不修复)。
• 应用侧:sheet.hook.ts 的新建保护 kpi_sheet_insert_guard 对 kpi_admin 岗位放行,管理员手工新建的填报单没有名称、没有明细行、当前节点 0,是一张残缺单;设计方案 §5.4 / 表 2 明确填报单只由「发布方案」生成。REST 直接 POST 同样放行(复核时建的测试记录已删除)。待定:是否取消管理员例外(建议 A:一律拒绝手工新建,报错文案已就绪)或在手工新建时补齐名称(B)。按维护者拍板,应用侧缺陷暂不立单,记在此处随 V1.1 确认后一起排。

[baozhoutao]

第三节第 8 处更正(2026-09-03)

前一条评论说「第 8 处以管理员复现不了」——管理员看得到「编辑」,正是因为问题只发生在岗位账号上。#23 全流程实测用「部门填报人员」账号复现并定位:控制台的「编辑」按钮只看权限集的对象级 writeScope(填报人员是 own),不看共享服务按方案发放的记录级 edit 授权;同一账号经 REST 写实际值放行,界面却没有入口。属平台问题,已上报 objectstack-ai/objectstack#14912(只上报不修复)。第 8 处由「待细化」改判「平台能力受限」,随平台修复复测。

另:#23 同一批发现的「核对方按方案级而非下达级生成」已按维护者拍板另立 #27(待细化)。

[baozhoutao]

对设计方案 V1.1 第 11 章的补充意见(来源:维护者 2026-09-03 提供的一份早期客户绩效考核需求脑图)

该脑图是一个「上级打分 + 互评」型的个人绩效考核(月度考核表 70% + 季度个人评分表 30%,部门经理互评、分管副总评分、董事长增减分、按部门均分算绩效系数),与本项目「指标完成率」型的组织考核不是一类,主体设计不照搬。但它用一个真实客户的规则暴露了第 11 章几处写得还薄的地方。以下均为对第 18~35 项的补充意见,按规矩在客户回复前不立开发工作项,建议随 V2.0 一并提出:

#	补充点	对应事项	脑图里的原始规则	建议
1	逾期处置策略	第 18 项(通知、待办、截止、催办)	「5 号起每天提醒、次月 15 号前完成、未打分按 100 分计」——提醒 + 截止 + 逾期默认值三件套	第 18 项只有提醒与催办,没说逾期了系统怎么办。把「逾期处置」做成方案上的可配置项:阻断 / 视为确认 / 视为满分 / 视为未完成;不能把「不填就是满分」这种特定客户口径写死成默认
2	多评价人加权,别把个人考核单做成「自评 + 上级评」两个字段	第 24 项(个人考核单)	部门负责人分数 = 部门经理互评 30% + 分管副总 70%(直系 40%、其他平均 60%),董事长再 ±20;后来又改成「不给自己打分」	个人评价天然是「被考核人 × 评价人 × 评价角色 × 权重」的多行结构。第 24 项的数据模型一开始就按评价记录对象设计,自评做成开关;否则二期一碰互评就要重做。脑图末尾那条「9 月 23 日改为不给自己打分」也说明自评口径会反复
3	结果系数与按类别的映射	第 25 项(结果等级映射)	绩效系数是相对口径:部门均分 ±10 分内系数 1,每 10 分递增递减 10%;负责人和分管副总另走「成绩 ÷ 100」	需求 §1.1 明说考核结果要用来算绩效,所以第 25 项除了「得分区间 → 等级」,还应支持「得分 → 系数」,映射规则可按人员类别或主体类型分别配置,并把「相对组内均值」列进备选
4	汇总层审批与异常路由	第 30 项(结果确认与申诉)	系数不为 1 的人要先「审个人」,再由行政副总裁和总裁「审汇总」	现在领导审批落在每张填报单上,四维汇总结果生成后没有审批或发布动作;需求 §1.1 原话是「做一张汇总表再给上级领导审核」。建议在第 30 项的确认/申诉之上考虑「结果发布」状态:生成 → 确认期 → 汇总审批 → 发布,并允许只把异常项(如系数不为 1)路由到个人级审批
5	已被现方案覆盖、可作佐证	第 28 项等	指标复制功能;每季度三张月表「份数之和除 3」;预留人为调整权限;员工看自己、上级看直系下级、总裁看全部	分别对应方案复制上一版、第 28 项「三个月平均」默认值、数据调整 + 加减分、第 3 章数据范围——说明现方案主干是对路的,可在与客户确认第 28 项时引用

处置:留痕待用;客户回复第 18~35 项后,随 V2.0 编制一并提出,届时按档次细化。