决策智能工作台：需求拆解与三线分工

01交付包定性：这是一份「交互契约」，不是代码底座

源码考古结论（决定我们以什么为准）

• 以 canonical-case-a-fixture.ts（720 行）为唯一权威数据模型：23 种对象类型 × 14 种关系 × 9 种状态 × 7 种 mutation 原语 + 纯 reducer + 一致性校验器。这份类型层就是可落库的领域模型草案，mutation 流就是 Agent→UI 的增量契约。
• 两套事件模型不兼容：Case A（对象图 + mutation，无 lane 字段）与 Case B（13 镜头数组，lane/actor 齐全但 13 个表面全是硬编码 JSX）。必须先统一——lane/actor 补进 canonical 事件，镜头（Scene）降格为事件流的派生视图。
• StrategicDecisionDemo 是孤儿代码（无任何文件 import），它是 V4 引擎的前身。价值只有两点：frame 1 的「上桌」输入面是最完整的输入面参考；14 帧叙事顺序可直接当「战略选择类 Case」的验收脚本。不要移植它的代码。
• 同一功能存在分叉实现（报告大纲编排两版、Case A 播放两版），产品侧未裁决，进需求评审合并成一套后再动工。
• Mock 依赖 Next.js 16.0.7 带已知安全警告——仅限本地演示，不作为生产起点。

02产品内核：四层语法

整个产品可以压缩成四层状态机，所有界面都是它们的投影。这四层也是服务端 schema 设计的直接输入。

什么时候必须问人（从两个 Case 归纳的判据）

只有四类事件打断人，其余一律自己往前跑、把摩擦如实显示：①口径/标准定义（什么算"真实需求"——机器无权定义业务口径）；②正式决定签署（责任不可转移）；③高影响现实动作授权（按可逆性分级：可回滚走规则内自动通过，高影响必须指定授权人，越界动作被策略引擎主动拦截并缩小范围）；④组织规则回写（学习成果限范围 + 30 天试用 + 到期自动结算，Case 不得静默改变组织规则）。

03功能全景

六大模块 · 每项标注它背后真正要做的服务端能力。「装饰」= Mock 里的演示装置，不进产品。

已判定为演示装饰、不进产品：自动播放器与倍速、tick 手动步进、全部硬编码数字（健康环 92 分、假设强度 72/43/81、贡献账本 118+71+42…）、假过滤按钮、假上传 dropzone、伪造波形与恢复曲线、所有只弹 toast 的按钮。但 narrationCue 里的每句话是验收标准不是注释（"300ms 内出现工作脉搏""页面没有被替换""不是整案重跑""侧问不污染主流程"）。

04基座已覆盖的部分：不要重造

raixis-desktop（main @ f8707a9）PRD 阶段一、二已全部落地。下面是与新需求直接相关的已建成能力与扩展点。

基座缺口（新需求的前置改造）

• 连接即会话：一 socket 一 session，服务端不持久化——多面板并行、跨设备续跑、服务端权威事件流都堵在这条上。改造点：以 (userId, workspace) 为键的 session registry + 消息加 sessionId 路由（PRD 3-1 本就排在阶段三）。
• App.tsx 巨石组件（1023 行 + 28KB CSS）：多面板对象表面落地前必须先拆成「面板容器 + 面板注册表」。这是承接新需求最先要付的重构成本。
• 鉴权两处欠账：JWT 验签未下沉（每请求回调 star_ai /users/me）+ token 存 localStorage 违背 PRD 1-2。已入 star_ai ledger（20260827），开工前先还。
• 服务端常驻调度器尚不存在：改变条件求值、监测规则、预测到期结算、凭据到期检测四处都要定时器——客户端不在线也得跑。这是「必须有服务端」的最强论据，写进架构决策记录。

可直接复用 star_ai 侧资产：事实闸/溯源徽章 → 章节核验与来源反查；enc2 信封加密 → 凭据保管库；导出工具链（pandoc/libreoffice/CJK 字体）→ 报告与 Deck；QA map-reduce → 整稿核验；ECI 沙箱模型 → 高危动作隔离执行；飞书通知 → Gate 待办与阈值告警。

05三大自研引擎

除去可复用部分，真正必须从零自研的核心只有三块。它们决定产品成败，也是三条任务线的技术锚点。

引擎一 · 对象图与事件溯源存储

append-only 事件表 + 7 种 mutation 原语落库 + snapshot 物化与定期 checkpoint + 任意时点重建 API。三个 fixture 已暴露的坑必须在 schema 期解决：① patch 找不到目标直接 throw——真实多 Agent 并发 + 网络乱序必炸，要幂等 + 乱序缓冲 + 死信；② object.version 无并发控制——要 OCC（读版本 CAS 写）；③ 关系失效路径完全没设计（relation.state=superseded 定义了但 720 行从未用过）——结论被推翻时支撑它的边如何级联失效，是重开引擎的第一个坑。

引擎二 · Gate 引擎（人机责任关口）

scope 分级挂起（local 只 pause 依赖前沿，需要依赖 DAG）、通知/超时/代理人、裁决留痕进 Decision Record。最大认知陷阱：Mock 里每个 Gate 选项预置了完整后果（选"严格口径"→14 家变 3 家），真产品绝不能照抄——结果必须由裁决后重新调度 Agent 真算。但 UI 又承诺了选项旁的后果预览，所以需要影子 dry-run：在不落库的 shadow snapshot 上试算每个选项的影响面，成本与延迟要提前评估并设计降级（先给"预计影响 N 个对象"，点开再细算）。低估这一点 Gate 体验会塌。

引擎三 · Material Event → Impact Set 选择性重开（护城河）

外部变化 → 材质性判定（是否命中某对象的 sourceIds 或某阈值的输入）→ 沿关系图反向闭包算最小重开集合（带可解释路径）→ 只把受影响对象置 contested/superseded 并局部重算，其余 verified 保持有效 → 原位 diff 修订 + supersede 链。这同时是成本控制手段（不整案重跑 LLM）与产品差异点（"你离开后发生了什么"）。建议单独立项先做 spike，验证传播算法的可解释性与性能。

06三条任务线（自选认领）

按产品架构切成三条边界清晰的线，与此前开源研读的三条线一一对应——不指定谁负责哪条，三人自己选；原则上每人主责一条、通晓三条。接口契约 = canonical fixture 的类型层 + 桥协议扩展，三线之间不需要开会定接口，照契约做。

三线接口与共同纪律

• 依赖方向：C 产出带 anchor 的标准化对象 → A 落图建边；B 的 Gate/重算产生 mutation → A 存储与传播；A 的对象图 → C 的报告投影与预览反查。任何跨线需求先落到 protocol/schema 变更，PR 里 @ 相关线主责人。
• 主链路 UI 外壳（面板容器/阶段状态机/桥协议演进）由技术负责人把控，不拆给任务线——这是三线的粘合层。
• 每条线的直接参照 = 你研读过的开源项目；已有结论（Semantica 只做隔离 PoC 不整包引入、WrenAI 走隔离适配层、Univer 需 Tauri 专项 PoC）直接沿用，不重新调研。

07里程碑

验收脚本：StrategicDecisionDemo 的 14 帧叙事（战略选择类）+ Case B 的 13 镜头（经营异常类）+ narrationCue 全部断言。

08需求评审待决清单

Mock 没有回答、动工前必须由产品/技术共同钉死的问题。

09红线与纪律

工程纪律：fixture 即契约（改契约先改 protocol 包再改两端）；遗留问题一律进 star_ai ledger；生产只合 main；每条线的 PR 按仓库 PR 模板写。