Repository navigation
Session handover: project state, pending decisions, and 12 UI findings from the manual screenshots #22
Description
Activity
第三节界面问题的处置(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再决定走哪条路。第三节补充第 13 处(2026-09-03,维护者浏览 3107 实例时发现)
现象:管理员在「填报单」列表点「新建」手工建了一张填报单(主体 华东分公司),打开详情页顶部红框报错
Component "page:header" failed to render / Minified React error objectstack-ai/objectstack#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 确认后一起排。
- 平台侧:记录的
第三节第 8 处更正(2026-09-03)
前一条评论说「第 8 处以管理员复现不了」——管理员看得到「编辑」,正是因为问题只发生在岗位账号上。#23 全流程实测用「部门填报人员」账号复现并定位:控制台的「编辑」按钮只看权限集的对象级
writeScope(填报人员是own),不看共享服务按方案发放的记录级edit授权;同一账号经 REST 写实际值放行,界面却没有入口。属平台问题,已上报 objectstack-ai/objectui#10107(只上报不修复)。第 8 处由「待细化」改判「平台能力受限」,随平台修复复测。另:#23 同一批发现的「核对方按方案级而非下达级生成」已按维护者拍板另立 objectstack-ai/objectstack#27(待细化)。
对设计方案 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 编制一并提出,届时按档次细化。
会话交接记录(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.mddocs/交付/:设计方案 V0.9 / V1.0 / V1.1、操作手册 V0.1;由pnpm docs:docx与pnpm docs:manual从 markdown 源生成docs/手册/(源稿 + 62 张真实截图)已合并的工作项:#2 数据范围动态共享、#5 共享服务加固、#9 设计基准 V1.0 与文档整改、#10 代码对齐确认口径、#13 界面术语。全部处于
status:PM验收中,等验收侧处理。二、等客户/维护者拍板的事
三、手册截图过程中发现的 12 处界面问题(尚未立单)
用各岗位真实账号走完整业务线时发现,均可复现,按影响排序:
i18n.defaultLocale已是zh-CN,平台自身文案是中文,但这些 label 落到了 en 回退。KpiError:开头,违反 std-copy 红线②(禁异常原文)。业务正文本身是三段式,合格。draft / branch_checking / hr_reviewing / leader_approving / approved / archived,未映射为业务叫法(红线①)。Add line/Total/Columns。判定: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是权威,以下是最容易踩的几条:docs/文件维护;基准定稿前不出蓝图/分级/符合度/测试报告类文档(出早了必反复改版)。acceptance-evidence);例外:操作手册配图随源稿归档在docs/手册/图片/。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 objectstack-ai/objectstack#66~#73(文档产出时机、设计方案作为基准的路径、敏感词检索范围、Word 归档、无 gh CLI 的替代出口、只上报不修复、评审轮次纪律、接口级证据档位)。接手方遇到同类问题可先查这批 issue。