事项卡为唯一锚点 · 轮 0 可点原型稿
9节
37界面块
5处可点交互
44项待澄清
15挡住轮 1
稿内凡带 可点 的都真能点：卡头、态名、chip、勾选框、候选行
C1

为什么要这张卡

这稿是不是在解决我提的那件事？它不承诺什么？
C1-1四问一屏可点
点卡头展开，看这一行的每个格子分别回答四问里的哪一问
卡上每个元素都能指回四问之一，没有「因为技术上有所以放上去」的维度。收起态整行零可编辑控件——五个格子全是服务端派生或只读。
字段与依据（点开）
格子字段可编辑 / 派生今天的档位
编号id派生 不可变，按项目序号生成待补 短名规则与序号原子分配未定（TL#3）
标题title可编辑 展开态才给输入框示意 集合尚不存在
状态徽章status派生 CONFIRM/ACCEPT/RESULT 后迁移，C/CP 不接受待补 六个落库键未定（TL#1 / PM Q4）
进度 x/y由 items[].state 汇总派生 read view 组装示意 state 类型与值数未定（TL#2）
待我角标user_approval / acceptance / scope_drift派生待补「球在用户」的判定规则未定义
C1-2今天 vs 有卡之后
今天 · docs/86:3 的 Status 行 真值
Status: wb-ui轮0采集 run_d9460febba8f completed,GM独立复核14/14通过(verify脚本重跑+截图目检);待:契约docs/86入git后派轮1.
有卡之后 · 同一件事 示意
ci_1 · 轮0 采集 dev完成 outcome.run_id run_d9460febba8f
outcome.status=completed · summary≤200 · changed_files_count · artifact_ids[] · 「复核 14/14 通过」这类结论进 decisions[] · docs/86 进 contract_docs[]
左边那句话不会被复制进卡——卡上放的是指针与定长快照，不是叙述。卡不是新增一份记录负担，是替换这段没人读得动的文本。
本稿实测与 PM 描述的差异（点开）

PM 大纲 C1-2 把该行描述为「170 字自由长句（混装 run id、复核方式、部署进度、当前批次）」。本稿实读 docs/86 第 3 行为上方原文，约 96 字符（含空格与标点，逐字计数）；可辨认的混装类目是 run id 与 复核方式两类，未见部署进度与当前批次。本稿按实读原文展示，不按描述作画。差异已列入 C7 · D3，design 不代裁。

C2

卡长什么样 · 每一格从哪来

这张卡存得住吗？会不会又变成一段越写越长的自由文本？
C2-1收起态列表可点C2-2展开五区
点卡头收起 / 展开；展开后点 A–E 区标题可再折叠；B 区的角色 chip、session 徽标、产物 chip 都能点
收起态吃 id、title、status、卡级 gate=max(items[].gate)（REQUIRED > NOTIFY > AUTO）与 live state 摘要；展开后 A 区草案可编辑、E 区只接受 operator 动作、C/D 全部派生。
字段与依据 · 五区吃哪些字段 · 五类产物落点（点开）
区吃哪些字段可编辑派生 · 不可编辑
A 合约intent backlog_id contract_docs[] mirrors[] related_cards[] decisions[] confirmation前 5 项草案引用存在性校验 · confirmation 主体印章
B 子事项items[] 全部 17 字段title role agent_id depends_on impact rollback + 预期 deliverablesid serialize_after session_plan session_id gate run_ids outcome scope_drift state
C 时间线timeline[]无全部节点；只显示事件名 / 指针，不显示正文
D 消耗items[].outcome.usage无全部；按卡聚合
E 动作条status user_approval acceptance仅 operator 动作状态迁移与动作可用性
产物类型（docs/87 五类，不新增）打开行为字段落点
契约 / 提案文档面板内只读预览contract_docs[]
设计稿 / 交互稿新开页 ↗deliverables[] 指针类型未定 TL#29
run 及汇报现有详情抽屉run_ids[] / outcome.run_id
评审 / QA 报告面板内查看deliverables[] 待补
部署链接新开页 ↗outcome.artifact_ids[] → artifact 行的 meta.public_url（只读服务端铸造值，不接受 worker 自报）
落不了的字段：mirrors/confirmation/acceptance/timeline/usage 今天都没有字段级定义；若实现时用任意 object，会直接击穿 32KB 与「无自由文本」纪律（TL#5）。本稿一律画占位。
一处视觉偏离：被复用的 design/mockups/contract-card/ 交互稿在收起态用「4px 状态左色轨」，而 design/DESIGN.md v2 §9 冲突 4 明令产品 console 禁止给任务卡加彩色左边框 / 描边。本稿按 DESIGN.md 执行：去左色轨，状态改由「徽章 + 文字」双通道承载。这是既有视觉规范条款，不是对三份真源的裁决。
C2-3子事项行字段解剖 · 落库不上屏可点
ci_3 · 轮2 批次1
点行里任何一个徽章 / chip，看它吃哪个字段、点它会去哪
items[] 共 17 个字段（16 落库 + state 只在读视图）；只有 6 个可由 operator 编辑，其余全部服务端派生、客户端直写一律拒绝。有些字段是给机器用的，界面上根本不出现——那一栏叫「落库不上屏」。
落库不上屏的六个字段 · 子事项六态（点开）
字段给人看还是给机器用为什么不上屏
depends_on[]业务依赖，给机器本卡 Item ID；去重、无自环、图无环。与 serialize_after 不可合并（TL §1.3 约束 3）。UI 只在「未产出 · 依赖 ci_x」里间接露出
serialize_after[]文件冲突约束，给机器前置未完成时派发返回 409 serial_predecessor_incomplete 且零副作用。UI 只显示结果徽章
session_plan判定输出，给人看本行放不下，完整算式在 C3-1。子结构未定 TL#5
scope_drift越界事实，给人看只有触发时才出现，不常驻行内。类型未定 TL#23
rollback门的输入，给机器字面值 none 有特殊含义（把 AUTO 提升为 REQUIRED，见 C4-5）
user_approval用户动作，给人看行内只显示「已批准 / 待批准」，不显示审计对象。类型与失效规则未定 TL#5
子事项六态（未开始 / 进行中 / 待复核 / 待验收 / 完成 / 阻塞）是待补，不是真值。态名照抄 PM 多态清单 M2（来源 docs/87 §2.2 B 区）；但 TL#2 明确：方案没有给出 state 的类型、值数或值名，PM 大纲提到的六态不能反向冒充方案决策。
C2-4决策链 · 改主意不覆盖旧结论
决策 · 引擎锁已被取代
id dec_… · status=superseded · decided_by user
旧条目不可编辑，界面显示「已被 dec_… 取代」。
↓ supersedes
决策 · 引擎锁（现行）decided
id dec_… · supersedes → 上一条 · affects_items[] ci_2, ci_3 示意
改主意不是编辑旧条目，是在同一次父卡原子写里创建新 dec_*、把旧项置 superseded、写新项的 supersedes、追加一个无正文 timeline 节点——任一步失败则全部不写。dec_* 全局唯一，是为了根治 OQ-1 这类编号在 10 份文档里含义各不相同的问题。
字段与依据（点开）
字段上限 / 取值可编辑 / 派生端点
iddec_<12hex> 全局唯一、不可变派生 服务端生成并查全局冲突DC/DS 响应
question1..200可编辑DC/DS
decision非空时 1..500；decided 时必填可编辑DC/DS
statusopen/decided/superseded 真值 方案 §1派生 由端点动作设置DC 创建 / DS 置旧项
decided_by<=500；值为 user 时只许 operator 发起派生 从已鉴权主体构造，body 不接受伪造DC/DS
supersedes必须引用同链中的 dec_*；不可变；无环派生DS
evidence_ref单指针，不得存正文；<=500可编辑DC/DS
affects_items[]本卡 Item ID；去重可编辑，服务端校验引用DC/DS
待补 真实 dec_* 今天一条都不存在（决策回填是方案 §6 的迁移动作，轮 1 才做）。本块条目全是示意，不得把 docs 里的文字冒充已迁移的决策行。
C2-5run 被清掉之后：outcome 冻结快照

① run 行仍在

ci_1完成 run run_d94…
点 run chip → 现有详情抽屉。state 由 live run 派生。

② run 已被保留策略清理

ci_1完成 run 记录已清理
记录已按保留策略清理，结论见快照
方案 §7 风险 3 的原句。不得把 outcome.status 冒充 live run 状态。

③ 证据指针不可用

ci_2完成 证据指针不可用
artifact 行缺失，或已发布文件被撤下而 row / URL 不同步。不得把 stale public_url 当存在证明。
run 行没了以后，这一格改吃 items[].outcome 的六个定长字段（run_id/status/summary≤200/changed_files_count/artifact_ids[]/usage），禁止 additionalProperties；产物 chip 改从 artifact_ids[] 解引用——artifacts 集合不被清理，所以它活得比 run 长。
六字段来源 · 两处已知冲突（点开）
字段类型 / 上限来源档位
run_idstring 1..500终态 run 的 run.id示意
status严格为 completed/failed/cancelled；legacy canceled/error/timeout 不得由新写入产生终态 patch 的 status三个终态值 真值
summary<=200worker result 的受信 summary待补 nullability 与超长冻结策略未定
changed_files_count非负整数规范化去重后的 changed_files.length示意
artifact_ids[]只含已持久化且 artifact.run_id === run_id 的 ID；去重稳定排序artifact 保存成功后查询所得示意
usage结构与上限未定义终态 run 的 usage示意
「终态写一次」的两处冲突（不代裁）：① 首个 failed run 冻结后，retry 的成功 run 按字面不能成为最终 outcome（TL#7）；② 现有终态流里 artifacts 在 terminal patch 之后保存、generation 又先被消费，失败重放无法补冻，需重构为原子 finalizeRunAndFreezeOutcome（TL#8）。
幂等：技术键 (run_id, generation)，业务键 (card_id, card_item_id, run_id)。完全相同的重放返回既有结果；字段不同的重放返回 409 outcome_conflict 并告警，绝不覆盖。
C2-6写不进去的时候长什么样

400 超长

decision 超过 500 —— 已拒绝写入，内容未被截断，请自行缩短后重试
机器码 string_too_long。上限只有三处是方案给定的：question≤200 · decision≤500 · summary≤200。

413 容量红线

这张卡已达 items ≤30 上限 —— 不能再加子事项
红线：单卡 ≤32KB · items ≤30 · decisions ≤50 · timeline ≤100 · 总卡 ≤500。

400 未知字段

字段 notes 不在写边界白名单内 —— 已拒绝
机器码 unknown_field。任何内嵌对象也必须逐层白名单，不能只过滤顶层。
这三种反馈是写入顺序的三个不同关口：鉴权 → JSON/body 大小 → 未知字段 → 字段类型/枚举/引用 → gate/状态迁移/并发前置 → 数组与总卡数上限 → 序列化后的单卡 32KB → 单次原子替换。失败不得截断、不得部分写、不得留下 timeline 节点。这是「防第二真相源」唯一能靠代码而不靠自觉守住的边界。
一处极易画错 · 空态与异常态 · 两条容量隐患（点开）
方案第 69 行「长度超限 400」里的 400 是 HTTP 状态码，不是统一的 400 字符上限（TechLead §0）。本稿凡出现 400 一律指状态码。
M10 三态画法
一张卡都没有空列表 + 建卡入口。待补 ID 分配与 status 默认值未决前不可上线
判定服务算不出400 missing_impact / 409 session_plan_invalidated；500 仅在完全无法退化时
拒写反馈上方三态；一律「返回修改」，不提供「仍然写入」
待补 TL#25：长度与 32KB 的计量单位未写（UTF-16 code unit / Unicode code point / UTF-8 字节对中文得数不同），本稿字节数演示全是示意。TL#31：卡接近 32KB 或 timeline 已 100 条时，终态快照可能无空间可写——对 worker 返回 413 会违反「必须抗 prune」。TL#32：总卡 500 没有释放策略，满了将永久拒绝新卡。
C2-7图边：一条 session 服务多张卡
sess_299b637d8fa4真值 PM §5.3待实读 TL §6.2
workbench_1 UI修改进行中 card_item_id ci_2
workbench_2 会话统一拆解中 card_item_id ci_1
这一屏不读卡，读的是进程内反向索引 session_id → [卡, 子事项]（不落盘，启动时从卡全量重建）；端点 GET /cards/by-session/:session_id，无匹配返回空数组而不是 404。实测这条 session 的 31 个 run 横跨 ≥4 个事项主题，方案决定不拆分它——图模型天然支持一对多。
四张反向索引 · 覆盖度（点开）
索引来源字段覆盖度
session_id →items[].session_id完整
run_id →items[].run_ids[] 与 outcome.run_id完整
doc_path →唯一无歧义来源是 contract_docs[]待补 mirrors/deliverables/evidence_ref 未定型，不能猜（TL#29）
artifact_id →唯一无歧义来源是 outcome.artifact_ids[]同上
更新方式必须是「父卡提交成功后用 old/new card 做边差分」——不能先改 Map 再等持久化，否则写失败会产生幽灵边。索引只加速查询，不得成为授权或存在性判断的唯一真源。TL#26 另指出：上限只有 500 卡 / 15,000 Item，全扫可能已够，四张 Map 的 invalidation 与重建一致性成本不应低估。
C2-8字段对照总表
这一块没有原型——它是给 tech-lead 的查证入口，整表收进折叠。「来源」一列写的是规范锚点或既有范式，不表示字段今天已经实现（TechLead §1.1）。PM 原本要求的「逐字段 路径:行号」目前只到段级，逐字段行号仍待补。
顶层 13 字段 · items 17 字段 · impact 8 字段 · run 2 键（点开，共 40 行）
字段上限 / 取值谁能写端点UI 消费点来源锚点
顶层 contract_cards（13）· 来源 方案 :43-57
id<project>_<seq>；不可变SC（响应）C1-1 · C2-1TL#3
title1..500；可改O；A 草案C,CPC2-1 · A 区方案
status六态 enum · 落库键未定义SCONFIRM,ACCEPT,RESULTC2-1 · C5-1TL#1 / PM Q4
intent1..500O；A 草案C,CPA 区方案
backlog_id单指针；必填性未定义O；S 校验引用C,CPA 区TL#4 / PM Q5
contract_docs[]路径 1..500；条数上限未定义OC,CPA 区 · doc 索引方案
mirrors[]须标「镜像非真相源」；子结构未定义OC,CPA 区（占位）TL#5
related_cards[]卡 ID 单向引用；去重O；S 校验目标C,CPA 区 · C2-7方案
items[]<=30仅通过子资源写IC,IP,PLAN,APPROVE,DISPATCH,RESULTB 区 · C2-3方案 :59-63
decisions[]<=50仅通过决策端点写DC,DSC2-4方案 :65-69
confirmation类型未定义；字符串 <=500O 发起；S 构造CONFIRMC5-2TL#5
acceptance类型未定义；字符串 <=500O 发起；S 校验主体ACCEPTC5-6TL#5
timeline[]<=100；只记节点；节点子结构未定义S所有成功迁移的同一原子写C 区 · C5-3TL#5
items[]（16 落库 + state 派生）· 来源 方案 :59-63
idci_*；不可变SIC（响应）行首示意
title role agent_id各 1..500 / <=500O；A 草案IC,IP行首 · 角色 chip示意
depends_on[]本卡 Item ID；无自环、图无环O；S 校验图IC,IP落库不上屏示意
serialize_after[]本卡 Item ID；串行图无环SPLAN；dispatch 前重算C3-4 徽章示意
session_plan持久子结构未定义SPLANC3-1 · C3-2TL#5
session_id<=500；规划阶段不得提前冒充已分配SDISPATCH 成功后C3-6 · C2-7示意
impact八字段；不得用空对象补齐O；A 草案IC,IPC4-1示意
gateREQUIRED/NOTIFY/AUTO 严格大写S 调 gate(impact)同一原子写；客户端不接受C4-2三枚举 真值
user_approval类型未定义仅 O；S 校验主体APPROVEC4-3 · C5-2TL#5
rollback类型未定义；none 有特殊含义O；A 草案IC,IPC4-5TL#5
deliverables[]只存指针；条目结构未定义O/A 声明预期；S 关联IC,IP,RESULT产物 chipTL#29
run_ids[]run ID；去重SDISPATCH 成功后原子追加产物 chipTL#19 与 TASK 纪律冲突
outcome固定六字段；终态写一次SRESULT / cancel 路径C2-5示意
scope_drift类型未定义SRESULTC4-3 ②TL#23
state类型 / 枚举未定义；不进落库白名单S无持久写端点；GET 组装C2-3 徽章TL#2
items[].impact（8 · 全部必填）
spends_money external_publish data_destructive architectureboolean × 4O；A 草案IC,IPC4-1任一 true → REQUIRED
touches_paths[]路径 1..500；空数组合法但 fail-closed 判 REQUIREDOIC,IPC4-1命中 PROTECTED_PATHS→REQUIRED
reversible枚举未定义；已知 noneOIC,IPC4-1none→REQUIRED
additive_onlybooleanOIC,IPC4-1NOTIFY 必要条件
deploy_targets[]由路径推导；推导映射未定义S·客户端同名字段必须拒绝校验期计算C4-1（只读）TL#10
run 侧两个柔性键 · 来源 方案 :71-73
card_id card_item_idstring 或 null；老 run 缺字段等价于 null；不允许只有 card_item_id；不允许 run 创建后 PATCH 改锚点S·DISPATCH 内部 createRun；所有 retry 必须继承—C5-5 野 run 灰行短命加速键，7 天随 run 消失
来源锚点（段级）：卡/容量 docs/90-contract-card-anchor-plan.md:43-57 · Item/outcome :59-63 · Decision/防长文本 :65-69 · run 两键 :71-73 · 反向索引 :75-77；现有写边界范式 services/orchestrator/storage.mjs:75-94,104-127；执行态派生范式 services/orchestrator/server.mjs:4967-5003。
待补 TL#6 created_at/updated_at/version 是正常并发控制所需，但方案没有这些字段，不能静默加入。卡是整行原子替换、会被 operator / planner / worker result 同时写——不引入并发 token 会丢更新。
C3

用哪条会话 · 凭什么

为什么这一步要开新会话／接着老会话，理由给我看。
C3-2判定台 · 点候选看它怎么算可点C3-1完整算式C3-3硬门
候选会话（点一条看判定过程）
判定过程
判定结果
—
点上面任一候选：右侧结论、左下角逐项加减分会一起变；命中硬门时整个分数区消失——因为分数救不回硬门
判定分三层，顺序固定：硬门（物理不可能，命中即出局、不显示分数）→ 串行门（撞同一文件的物理约束，结果是「不可选」而非「建议」）→ 打分（启发式，≥40 才复用）。用户只审结果、不背规则。上面六个候选的事实组合与预期结论逐条取自 TechLead §3.2.5 的单测用例 S1–S15，分数不是本稿编的。
九项权重 · 五条硬门 · 四种结果 · 第五技术态（点开）
权重项（方案 §2 / TL §3.2.4）分说明
same_card 同卡+50反向索引显示候选已服务当前卡
upstream_lineage 上游血缘+30已服务 depends_on 闭包中的 Item
needs_history 需历史+25缺字段/规则
same_role 同角色+10「任一历史 Item」还是「最近 Item」未定义
workspace_fresh 工作区新鲜+15缺分界阈值 TL#13；缺值时两者均 false，不阻塞
workspace_stale 工作区陈旧−20
serves_card_count>=3 主题污染−25方案唯一给定的污染阈值；=2 不扣分
oversized_session 超大会话−15指标与阈值均缺
runner_switch 需切 runner−10已绑定不符走硬门，不在此扣分
阈值：最高分 ≥40 → 复用；<40 或无候选 → 新建。每项最多计一次；同分 tie-break 未定义 TL#13
五条硬门（方案原文）出局码
引擎锁不一致engine_lock_mismatch（不能靠切 runner 绕过已绑定引擎）
adopt 会话 cwd 不符adopt_cwd_mismatch
cwd 不在 allowlistcwd_not_allowed
已删除session_deleted
CLI 占用中cli_in_use（dispatch 时必须重新检查，不能只信规划快照）
同一候选命中多个硬门时全部理由都保留，不只显示第一条。返回值形状：mode(reuse|new|forced_same|blocked) · session_id · score · reasons[] · excluded_candidates[] · serialize_after[] · degraded[]。
第五种技术结果 blocked，PM 的四态里没有（TL#15）。热文件要求同一 session，但该 session 可能 deleted / CLI 占用 / 引擎不符——此时物理上无解。不能把它伪装成普通「新建」，那会违反物理串行约束。本稿把它单独画出来（点候选 TL S6 可见），不并入四态、不替用户选。
两条会影响正确性的既有事实：TL#16「CLI 占用中」今天只是 heartbeat 的 UI 提示、不是服务端锁，规划与派发之间存在 TOCTOU；TL#17 engine lock 目前不是所有派发入口的统一前置，新卡路径测试绿不能证明全局不变量。TL#14 另指出：Item 没有目标 runner/cwd 字段，硬门却要比对 runner lock / adopt cwd / allowlist，必须由 adapter 传 normalized candidates。
C3-1 完整算式即上面 TL S4 那条候选，逐字对应方案 §2 的示例（同事项 +50 · 引擎一致 +0 · 需历史上下文 +25 · 主题污染 −25 · 工作区落后 main 37 提交 −20 → 30 分，阈值 40；建议名 workbench_12:会话统一 · 轮1(dev)）。本稿不代裁的措辞分歧：方案原式含「引擎一致 +0」一项，TechLead §3.2.4 的九项权重表不含该项并明写「没有『引擎一致 +0』奖励」——两者合计都是 30，见 C7 · D2。
C3-4串行门两态C3-5behind_main 退化

热文件交集 → 强制同一条 session

ci_2强制同 session session sess_299b…
与 ci_1 同时改 apps/web/index.html —— 不可选
HOT_FILES 两条路径是 真值：apps/web/index.html · services/orchestrator/server.mjs

非热文件交集 → 排队

ci_3排在 ci_a 之后 前置未完成 · 暂不可派
409 serial_predecessor_incomplete —— 已拒派，零副作用
写进 serialize_after[]（派生）；与 depends_on[] 不能合并。

① 有真实测量

工作区新鲜度 已测量
worker 上报的非负整数

② 轮 1 的代理值

工作区新鲜度 代理值
用 last_activity_at 代理，该项必须标「代理值」

③ 完全缺失

工作区新鲜度 不计分
不计分且不阻塞，输出带 degraded[]（TL 用例 S12）
「撞同一文件必须串行」是物理约束不是惯例：每条 session 独占 session/<sid> 分支与旁路工作区，建时从 main fork、之后不自动跟随。behind_main 也因此只能表示「相对 worker 本地 main 落后多少」，不能声称相对远端最新 main。
采集口径 · 三个缺失的阈值 · heartbeat 白名单（点开）
采集：git -C <session-worktree> rev-list --count HEAD..main。失败 / 分支不存在 / 不是 git worktree 时为 null，不得用 0 冒充；采集只读、带短超时并缓存。
TechLead §2.3 原话：方案没有定义多老算「陈旧」，所以 last_activity_at 代理值当前不能可靠地产生 +15 / −20；缺失则两项均记 0，继续算其他分。待补 TL#13 三个阈值今天全缺：fresh/stale 分界、oversized 规模指标、代理 cutoff。
heartbeat 新增顶层 session_worktrees，采用与 cli_sessions_in_use 相同的「字段存在则全量替换、缺字段则保留旧值」语义，显式 [] 清空；单项白名单只能是 {session_id, behind_main}。TL#22 数组上限方案未定义，不能静默照搬 cli_sessions_in_use 的 50；每 15 秒对大量 session 跑 git 会拖慢 heartbeat。
C3-6现名 → 建议新名
sess_299b637d8fa4 现名：本稿未读 store，留空 → workbench_12:会话统一 · 轮1(dev)
ID 与名字分层：id 不可变、作关联键，title 可随时改、只作展示，改名不得改任何边。现名一列本稿留空并写明原因，而不是填一个看起来合理的名字（PM 黑名单：session 现名属「本稿未读 store」）。
为什么建议名只能画成示例（点开）
待补 TL#33 建议名只有例子，没有生成算法。workbench_12:会话统一 · 轮1(dev) 无法机械推出标点、截断、旧名重命名和冲突处理规则。本块只画方案示例，不能写成可执行的输出契约。
session 重命名是既有能力，但「批量 / 单条取消」是否归本方案管，方案未定义。PM 引用的 OQ-8=B 属于「推荐过但用户从未表态」的 B 小组，见 C7 已答归档。
C4

哪些要我批，哪些不用

怎么保证既不放炮，又不是每件事都来烦我？
C4-1impact 录入 · 勾一下看门怎么算可点C4-2三档C4-5rollback 降级链
四类信号（任一为真 → REQUIRED）
touches_paths[]（全不勾 = 空数组，fail-closed）
其余输入
gate(impact)
—
effectiveGate(item)
—
勾掉全部路径试试（空数组 → 直接 REQUIRED）；或只留 docs+design 且勾上「纯新增」→ NOTIFY；再勾「无回滚」→ 看 AUTO 怎么被提升成 REQUIRED
门是算出来的不是填出来的：gate 与 deploy_targets 客户端都不能写——否则调用者可以报一个空 deploy_targets 数组绕过审核门。rollback 是 Item 字段、不在 impact 里，所以签名为 gate(impact) 的纯函数看不到它，只能拆成 gate + effectiveGate 两步——这就是右侧显示两格的原因。
六步优先级 · 三档命中条件 · PROTECTED_PATHS 全清单（点开）
#规则（TL §3.1.2，顺序固定不可重排）结果
1touches_paths=[]（合法但保守的输入；API 不得把它拒绝掉后绕开 fail-closed）REQUIRED
2spends_money || external_publish || data_destructive || architectureREQUIRED
3reversible === "none"REQUIRED
4任一路径命中 PROTECTED_PATHSREQUIRED
5additive_only && deploy_targets.length===0 && touches_paths.every(DOC_PATHS)NOTIFY
6其余AUTO
后置effectiveGate：item.rollback === "none" 时把 AUTO 提升为 REQUIREDREQUIRED
路径规范化：先转仓库根相对 POSIX 路径；绝对路径、空字符串、.、含 ..、无法规范化的一律视为无有效路径，按 fail-closed 判 REQUIRED。glob：foo/** 匹配任意后代，不匹配相似前缀；同时命中 DOC_PATHS 与 PROTECTED_PATHS 时 REQUIRED 优先。
档用户要不要出手出手点
REQUIRED要确认流第 3 步（若 Q6 定为预批）或派发前逐条批——Q6 未拍板
NOTIFY不要，只通知门徽章 + 时间线节点
AUTO不要门徽章（中性档）
PROTECTED_PATHS（TL §3.1.1 已把方案的「类目」落成精确路径）真值为什么被保护
services/orchestrator/storage.mjs写边界 + 保留策略（92MB 事故）
packages/contracts/**共享契约
workers/mac-worker/worktree.mjs · services/orchestrator/native-resume.mjs · workers/mac-worker/transcript-sync.mjs零拼接 / resume / 引擎锁 / transcript
services/orchestrator/server.mjs · workers/mac-worker/worker.mjs鉴权与 cwd 白名单段（文件级近似）
scripts/cc-deploy-api.mjs · scripts/cc-deploy-web.mjs · scripts/cc-deploy-mockup.mjs · infra/**部署通道与基础设施
DOC_PATHS = ["docs/**", "design/**"]配套常量，是 NOTIFY 档的路径前提
三处需 GM 裁决（不代裁）：TL#12 路径 gate 只能保护整文件，保护不了 server.mjs 的「某些段」——后果是大量普通 server 改动都判 REQUIRED；TL#11 方案类目漏掉了真正承载不变量的 prompt-pack.mjs / runner-codex.mjs / runner-claude-code.mjs / cli-usage.mjs / package.json / devops-deploy-and-verify.mjs，加入会改变已批准清单，本稿按已批准清单画、不擅自加行；TL#9 方案只说 rollback=none 提升 AUTO，没说 NOTIFY 要不要一起提升——本稿严格只提升 AUTO（对应 TL 用例 G14：design/a.html + 纯新增 + 无回滚 → 仍是 NOTIFY，可在上面勾出来验证）。
待补 reversible 的完整枚举只知道字面值 none（TL#5）；路径 → deploy target 的映射表不存在（TL#10），所以上面把 deploy_targets 做成手动开关而不是自动推导——在映射确定前「无部署」不可可靠判断，NOTIFY 可能误放。
C4-3三处强制C4-4保护路径解释层

① 派发前拒派

400 approval_required —— gate=REQUIRED 且无有效批准，已拒派
零副作用：session 数、message 数、run 数、card 字节、timeline、反向索引全部逐字节不变。

② 派发后越界升审

本次改动越出 touches_paths —— 已写入 scope_drift，自动升为待我审
时序注意：changed_files 是 run 跑完之后才有的，所以升审必然是事后的——代码已经改了。

③ 卡级聚合

卡级门 REQUIRED
= max(items[].gate)。一个子事项是 REQUIRED，整张卡就是 REQUIRED。
三道保险各自有界面。②这一屏本稿不画动作按钮——方案写明了「自动升为待用户审」，却没写用户在这一屏能做什么；没有动作定义就画不出来，也很容易退化成又一个没人处理的通知。三个候选动作见 C7 · PM Q8。
零副作用的唯一实现位置 · 九步检查顺序（点开）
卡 Item 派发必须像现有 backlog not_reviewed 分支（server.mjs:5311-5338）一样，直接放在 dispatch route handler 里，并在第一个副作用之前完成全部检查：① operator 鉴权 → ② card/item/backlog 引用存在 → ③ body 白名单与 JSON 校验 → ④ 卡已确认、impact 完整、server 重算 gate → ⑤ backlog 有值时仍满足 review_status=reviewed → ⑥ gate=REQUIRED 时有有效 user_approval → ⑦ 重新采集硬门、热文件目标与 serialize_after 前置 → ⑧ 校验 session plan 未陈旧 → ⑨ 此后才允许 createSession、append message、createRun、追加 run_ids、写 session_id。
待补 TL#23 scope_drift 的 changed_files 语义未定：rename、delete、未跟踪文件、目录 glob、生成物、子模块如何匹配，都影响是否升审。
C5

流程 · 我在哪几个点出手

我一天要点几下？点错了／绕过了会怎样？
C5-1六态预览台 · 点态名整张卡跟着变可点
待补 · 六个落库键与展示名未定（TL#1 / PM Q4）
workbench_1UI修改 拆解中 0/4 当前：等你确认拆解
E动作条仅 operator
点上面六个态名：徽章、进度、「当前干到哪」、待我角标、动作条、阻塞条会一起换——不是六张并排的死图
status 是派生的：由 CONFIRM/ACCEPT 及 RESULT 后的服务端迁移产生，C/CP 不接受直写。只有「六态」这个数量是真值（方案 §1 原文）；六个落库键、展示名、完整迁移表均待补，不能画成已实现。
两套展示名并列（Q4 未拍板，本稿不择一）· 阻塞态画法（点开）
#docs/87 §2.2（第一人称）docs/87 §2.3（第三人称）
1拆解中拆解中
2待我确认待用户确认
3进行中进行中
4待我验收待用户验收
5已完成已完成／关闭
6阻塞—（§2.3 状态机未列）
阻塞态沿用交互稿的既有决定：不整卡染红、不闪烁，改为卡内一条 danger-soft 窄带写明「原因 + 恢复动作」——原因永远伴随出路。（本稿按 DESIGN.md v2 §9 冲突 4 去掉了原交互稿的彩色左色轨，理由见 C2-1 折叠区。）
C5-2确认三步流C5-3打回拆解

① 核对拆解

只读表：顺序 / 指派 / 产物。吃 items[].title/role/agent_id/depends_on/deliverables。
摘要句给决策锚点：「拆成 4 步，3 步等你放行」示意

② 核对 session 判定结果

吃 items[].session_plan。本轮语义升级：原交互稿此步是「统一命名」，现升级为「核对判定结果」，命名对照并入本步（同 C3-6）。
能不能在这一步推翻判定 —— PM Q7 未拍板，本稿不画覆盖按钮

③ 拍板勾选

一个复选框「我已核对」+ 主按钮。郑重感来自这道显式小门，不繁琐来自总步数 3。
要不要一次勾完全部 REQUIRED（预批）—— PM Q6 未拍板
打回拆解
卡回 拆解中，timeline[] 追加一个节点。
原因输入框本稿画成禁用：要满足「附一句原因」只能新增原因指针或复用已定义的指针结构——不能把正文偷偷塞进 timeline（TL#30），那会击穿「卡上没有任何自由文本字段」这条唯一能靠代码守住的边界。
确认不是单向门，退回有出路且留痕。最终确认只许 operator 发起，服务端校验主体并构造 confirmation。
今天的档位 · 预批若定了还要补什么（点开）
待补 TL#5 confirmation / user_approval / session_plan 的子结构全部未定义，所以三步 UI 全是示意。若 Q6 定为「预批」，还需要一套预批失效规则（impact 任一字段变化或 scope_drift 已写入时自动失效），并为 impact 存批准时的快照做比对——那是轮 2 的新增字段。
C5-4「待我处理」跨卡聚合条C5-5绕过兜底C5-6验收
待我处理示意 · 数量与排序均无出处
workbench_1 · ci_3 待批准REQUIRED
workbench_1 待验收
publishkit_1 · ci_1 越界待审
$ wb:dispatch --title "临时小修" ✗ 缺少 --card-item：本次派发没有合约锚点 先建卡： wb:card new <project> "<卡名>" 然后： wb:dispatch --card-item <card_id>:<ci_*> （是否硬强制、是否给 --no-card 逃生口 —— PM Q1 未拍板）
run_… runningdev card_id workbench_1
run_… completed野 run（无合约） 无 card_id / card_item_id
用户的出手点收敛到第一屏一处；只有「球=用户」的条目才进聚合条。灰行不是惩罚，是让绕过在你眼前可见——pending_acceptance 已经证明「只告警不可见」会空转。验收按钮标「只能用户触发」是规则的表达，不是已实现的密码学保证。
run 与卡的三种关系 · 两条今天做不到的事（点开）
M9 三态说明
有卡有子事项正常。两键成对，所有 retry / clone 路径必须成对复制
有卡无子事项数据上合法（两个 nullable 键），但创建它的业务端点未定义 TL#34
无卡 = 野 run灰行。老 run 缺字段一律归此类
TL#18：今天「唯一收窄的派发口」并不存在。session chat、attach-token、direct runs、backlog、tasks、retry、GM loop 等多处都能 createRun；现有 CLI 还是先建 session 再发 message。Q1 未拍板前只能显示野 run，不能宣称门已闭合。
TL#24：「accepted 只属用户」目前只能做业务约束，不能做身份保证。operator / worker token 今天可回退共用，agent 也常经 operator 通道执行；没有 user-presence 或独立 principal，无法证明点击者是用户本人。TL#28 另指出：PM 要的「子事项级验收」没有对应字段——user_approval 是派发前批准、outcome 是服务端快照，都不能代表验收；需方案新增字段，或明确只做卡级 acceptance。本稿只画卡级。
示意 聚合端点与「球在用户」的判定规则未定义；条目数量、排序全是示意；本块不显示任何 SLA、等待时长或排队位置（PM 黑名单）。wb:dispatch --card-item 今天尚未实现；老 run 可按「缺字段 = 野 run」分类，但具体数量需实读，本稿不给数。
C6

分轮与验收

轮 1 交付那天我打开屏幕看到什么？
C6-2轮 1 交付那天你实际看到的东西C6-1分轮表
置顶红标（方案 §5 原句）：改 apps/web/index.html 的只有轮 4、轮 5，必须串行且不与 UI 换肤并行；轮 1-3 不碰前端，可真并行。
$ wb:card show workbench_1 workbench_1:UI修改 进行中 门 REQUIRED 拆成 4 步： ci_1 轮0 采集 dev 完成 run_d9460febba8f ci_2 轮1 实现 dev 完成 → ui.heyyys1.com ci_3 轮2 批次1 dev 待复核 run_684acbf031b3 ci_4 轮3 验收 qa 未开始 依赖 ci_3 用哪条 session： ci_3 → 复用 sess_299b637d8fa4 同事项 +50 · 需历史 +25 · 主题污染 −25 · 工作区陈旧 −20 = 30（阈值 40） ↑ 分数与理由取自方案 §2 示例，非实算 哪些已拍板： dec_… 引擎锁 decided user dec_… OQ-1=B decided user （wb:card 今天不存在；以上整块为示意输出）

轮 1–3

零前端。交付形态是终端 / API：一条命令答出五个问题；GET /cards/by-session/… 返回多张卡；docs 的 Status 行不再需要手改。

轮 4–5

本稿画的面板第一次出现（改 index.html，排队）；?cards=off 与今天逐像素一致；打开 session 看到它服务的多张卡。
这是本稿最容易造成的误解，所以单独画一屏：轮 1 交付那天你看到的不是面板，是上面这段终端输出。这张表是批准的计划文本，不是系统进度 API——本块不显示实时百分比、ETA 或完成数。
分轮表 6 行（方案 §5 原表，不缩写）· TechLead 实现准入结论（点开）
轮内容验收口径
0HTML 原型稿（本稿），你审你在稿上圈出要改的与要澄清的
1卡实体 + 决策记录 + 判定纯函数 + CLI（零前端）wb:card show workbench_1 一条命令答出「拆几步／谁干／用哪条 session（含理由分数）／卡在哪／哪些已拍板」；GET /cards/by-session/sess_299b637d8fa4 返回多张卡；gate 与打分矩阵测试全绿；store 增量 <50KB；既有端点响应零变化
2派发挂钩 + 门强制 + 抗 prune 快照一次真实派发全程只用卡；人为触发 prune 后卡仍答得出做了什么、产物在哪；gate=required 未批准派发 400 且零副作用；越界改动自动进「待我审」；零拼接／resume／互斥全绿
3文档与记忆降为指针对 docs/82-89 跑 sync，自动块幂等、非自动区字节不变；GM 跑完一轮不需手改 Status；pending 列表非空且可点回卡
4卡片面板（改 index.html，排队）交互稿 6 项验收在真实数据走通；?cards=off 与今天逐像素一致
5反向边与收尾（排轮 4 后）打开 sess_299b637d8fa4 看到它服务的多张卡；搜「引擎锁」唯一命中一条 dec_*
TechLead §8 实现准入结论：轮 0 原型可以继续，但必须把待裁决项按「待补 / 示意」画出来。轮 1 开代码前至少需先裁决：卡 / Item 状态枚举、project 短名与 ID 原子分配、backlog_id 必填性、七类缺失子结构、并发 token、session freshness / oversized / tie-break、HOT_FILES 无解态、deploy target 映射。轮 2 前还必须裁决：approval 失效、outcome retry 语义、scope drift 用户动作、wb:dispatch 是否硬强制。
在这些裁决之前，可安全实现并测试的只有：字段名与硬容量白名单骨架、Decision ID / 不覆盖链、run 两个 nullable 键、反向索引重建、gate 已定义部分、session 九项权重算术。TL#27 工作量被明显低估：至少跨 storage 白名单与原子持久化、server CRUD/状态机/统一派发、worker heartbeat/git 采集、run finalize/cancel/retry、artifact 按 ID 查询、contracts 两个纯函数、CLI 单入口、身份边界、prune reconciliation、QA/verify 和后续 UI——轮 1/2 若不拆 acceptance gate，容易得到「字段存在但纪律不成立」的半成品。
C7

待澄清 44 项

现在到底还缺我哪几个决定？哪些我已经说过了不用再问？
C7-1待拍板项（三段式 · 点标题展开）可点
显示 44 / 44
每项默认折叠成一行，点开才是「业务背景 → 选项利弊与业务影响 → 推荐」三段式。这些今天是文档问题，不是已存在的 decisions[] 行；「挡住哪一轮」也没有对应字段，是本稿的展示逻辑。用户拍板后才通过 POST /cards/:id/decisions 形成新 dec_*。
A 组 · 方案 §8 的三项（3）
PM-Q1wb:dispatch 是否强制带卡？挡轮 2
业务背景

这是整套机制唯一真正的闸门。方案 §7 已把它认定为第二大风险——「门算得出但没人走门」，并给出实证：pending_acceptance 机制字段、端点、半自动回写全都建好了，线上快照实测仍是 (none)，纯靠自觉回写不可靠。派发口是唯一收窄点：这里不卡，后面所有门都形同虚设。反面是：任何临时派发（包括一次 5 分钟的小修）都要先建一张卡。

选项利弊与业务影响
选项利弊业务影响
A 硬强制：缺 --card-item 直接退出并打印建卡命令闸门真实存在；面板上永远不会出现说不清来历的 run临时小活多一步；GM 深夜派发时若建卡端点故障，整条派发通道被堵死数据完整性最高；操作成本上升，且新增一个单点故障
B 软强制：缺卡可派，但每次告警 + 面板灰行不堵路；绕过在用户眼前可见告警会被习惯性忽略——这正是 pending_acceptance 空转的成因大概率退回今天的状态：机制在、没人用
C 分档强制：AUTO/NOTIFY 可无卡派，REQUIRED 必须带卡小活不繁琐，危险动作卡死鸡生蛋：gate 由 impact 算出，impact 填在卡上；无卡就判不出档逻辑不自洽，除非另做一套简易 impact 参数——等于两套门
推荐
推荐 A，并配一个逃生口 --no-card（每次用都告警 + 在卡列表顶部留一条可见记录）。闸门必须默认关闭才有意义，但不能没有钥匙；逃生动作是用户看得见的一条记录而不是一条日志。C 因鸡生蛋不成立。
PM-Q2打分阈值 40 与 9 项权重挡轮 1
业务背景

阈值决定「复用旧会话」的松紧。判错的两种代价不对称：判成复用而实际不该复用 → 主题污染进一条已服务 ≥3 张卡的会话（sess_299b637d8fa4 已是这种，31 个 run 横跨 ≥4 个主题），上下文被稀释、换人即断；判成新建而实际该复用 → 丢历史上下文，AI 要重新被喂一遍背景。方案已给 9 项权重与阈值 40。

选项利弊与业务影响
选项利弊业务影响
A 就用 40 + 现有权重，放常量文件，上线后用真实事项跑 2–3 次再调不空谈调参；真实分布出来再动头 2–3 次可能判错，需要人工覆盖最快拿到反馈；前提是用户能覆盖判定结果（见 PM-Q7）
B 先跑影子模式：只算分只打印，不生效零误判风险轮 1 验收口径「答出用哪条 session」缩水成「答出建议但不作数」稳，但把决策延后一整轮
C 现在就调权重一次到位没有任何真实分布数据——现在调是拍脑袋不推荐：用直觉换掉一个同样是直觉的数字
推荐
推荐 A。40 这个数现在对不对无法论证，只能实测；关键不在数值而在可覆盖 + 可改一行这两个前提（Q7 决定前者，方案已保证后者）。
PM-Q3未收口的哪几件先建卡？挡轮 1 的验收演示
业务背景

方案 §6 定了「backlog 只给未收口的建卡，预计 2–4 张」。选哪几件决定轮 1 的验收能不能真的走通——如果挑的都是简单事项，「一条 session 服务多张卡」的图查询就演示不了，方案最核心的主张反而验不了。

选项利弊与业务影响
选项利弊业务影响
A 方案建议的 4 件：wb-ui 换肤 / 统一数据源 docs/89 / publish-kit toC / 流程面板本身恰好覆盖全部关键形态：热文件串行、一条 session 服务多卡、无 docs 无 backlog 的卡、NOTIFY 档；且全是正在跑的真事4 张卡要在轮 1 内建好，有一次性录入成本；publish-kit 的 id 需实读补齐验收覆盖度最高；轮 1 那天看到的是自己的真事
B 只建 1–2 张最简单的录入成本最低图查询、串行门、跨项目序号全都演示不了验收通过但没验到真问题，风险推后到轮 2
C 全量在管事项都建卡一步到位与方案 §6「不做全量历史回填」直接冲突违反已批准方案
推荐
推荐 A（方案原建议），补一条执行口径：publish-kit toC 实测没有对应 docs/NN、也没查到 backlog 记录——它正好是「卡与文档编号解耦」的活证据，建议保留，但轮 1 建卡时真实 id 需 tech-lead 从 store 实读补齐，稿上先标「待补」。
B 组 · PM 读方案时发现的新问题（7）
PM-Q4卡六态的展示名到底是哪六个？挡轮 1
业务背景

两份被方案指定复用的文档对同一组状态给了两套名字。docs/87 §2.2 是「拆解中 / 待我确认 / 进行中 / 待我验收 / 已完成 / 阻塞」；§2.3 是「拆解中 / 待用户确认 / 进行中 / 待用户验收 / 已完成/关闭」。「已完成」和「关闭」是一态还是两态、界面用第一人称还是第三人称，没有唯一答案。方案 §1 只写了「status（六态）」。这不是文字游戏：徽章文案、状态机迁移、wb:card show 输出、测试断言四处要用同一套字符串。

选项利弊与业务影响
选项利弊业务影响
A ID 与展示名分层：落库英文键（decomposing/pending_user_confirm/in_progress/pending_user_acceptance/done/blocked），界面显示第一人称与「ID 与名字必须分层」原则一致；第一人称更贴合「球在我这」；与现行 done_pending_user_acceptance 语义对齐多一张映射表最稳；将来改文案不动数据
B 中文即枚举值少一层中文串进测试断言与 CLI 输出，改文案就挂测试（本仓已有先例）埋一个改文案就红的坑
C 「已完成」与「关闭」拆两态（七态）区分「事做完了」与「卡归档了」方案白纸黑字写的是六态，改动数需用户重新批准超出已批准范围
推荐
推荐 A，且「已完成」与「关闭」合并为一态（保持六态不变）。归档如有需要，用独立布尔字段表达，不占状态位。TL#1 同步指出：PM 给的中英文方案只是推荐、不是唯一真源，status 默认值、迁移表和测试断言因此不可实现。
PM-Q5一张卡是否必须挂一条 backlog？挡轮 1
业务背景

方案把 backlog_id 列为「指针」字段，又说迁移时「backlog 只给未收口的建卡」。但推荐先建卡的 4 件里，publish-kit toC 实测既无 docs/NN 也无 backlog 记录。今天派发的唯一硬门是 review_status === "reviewed"（PM 评审），它挂在 backlog 上——没有 backlog 的卡等于绕过了 PM 评审门。

选项利弊与业务影响
选项利弊业务影响
A 必填：建卡前先建 backlog评审门统一适用；登记不出现两个入口每张卡都要走 backlog 登记 + PM 评审；临时事项成本高治理最严；与 Q1 的 A 叠加后一次临时派发要走三步
B 可空：卡是一等实体，backlog 降为可选来源指针符合「卡片为唯一权威」；publish-kit 这类能直接建卡无 backlog 的卡跳过 PM 评审门，专业预审出现缺口灵活；需另定「无 backlog 的卡由谁把关」
C 可空但补替代门：无 backlog 的卡，其 gate=REQUIRED 子事项必须由用户逐条批准缺口用已有机制补上，不新造门规则多一条分支兼顾灵活与把关；代价是规则复杂度
推荐
推荐 C。方案已把「卡是唯一权威」定死，A 会让 backlog 反过来成为卡的前置真相源；B 的缺口真实存在；C 用已经存在的 gate 机制补缺口，不新造概念。TL#4 同样在等这条裁决。
PM-Q6gate=REQUIRED 能否在「确认进管道」时一次性预批？挡轮 2
业务背景

这是「用户成瓶颈」这条已被 GM 指出、方案已接受的风险的直接对策。方案 §3 说 REQUIRED 要用户批，§5 轮 2 验收口径是「未批准派发 400 且零副作用」——但没说这个「批准」发生在什么时候。若每个 REQUIRED 都要在它自己被派发的那一刻单独问一次，一张有 3 个 REQUIRED 的卡要打断用户 4 次。

选项利弊与业务影响
选项利弊业务影响
A 预批：确认流第 3 步一次勾完打断次数最少；判断上下文最全从批准到派发可能隔几天，中间 impact 若被改，预批失效于无形体验最好，但需要「预批失效」规则兜底
B 即时批：每个 REQUIRED 派发前单独问批准与执行零时差，最安全打断次数 = REQUIRED 个数 + 1；深夜无人值守的轮次会全部卡住最安全也最容易让机制被绕过
C 预批 + 失效条件：impact 任一字段变化或 scope_drift 已写入时预批自动失效、退回逐条批常态一次批完，异常时自动收紧需要为 impact 存批准时的快照做比对打断次数与安全性都拿到；代价是轮 2 多一个字段
推荐
推荐 C。方案 §3 的第二处强制已经建立了「事后收紧」机制，C 只是把同一条规则前移一格复用，不新造门。这也直接回答了「无人值守 overnight 派发」的可行性——A/C 可以，B 不行。
PM-Q7用户能否推翻 session 判定结果？推翻到什么程度？挡轮 1
业务背景

方案说用户「只审结果、不背规则」。但「审」这个动作，如果结论只能是「知道了」，那它就不是审，是通知。而三类判定的可推翻性在物理上不一样：硬门是物理不可能，推翻了也跑不起来；串行门是共享工作区的物理约束；只有打分是启发式，才有商量余地。

选项利弊与业务影响
选项利弊业务影响
A 全部可推翻用户永远有最终决定权推翻硬门的结果是 run 起不来或引擎被强制回正，用户会认为系统坏了制造一类必然失败且难解释的操作
B 全部不可推翻实现最简；判定即执行头几次误判无处可救，正好撞上 Q2 的 A与 Q2 的推荐互相拆台
C 分层：硬门不可推翻（显示原因，不给按钮）；串行门不可推翻（显示「与 X 撞同一文件，已排在其后」）；打分结论可一键覆盖，覆盖动作写进 timeline[]可推翻的恰好是启发式那一层；「不给按钮」本身就在解释物理约束三类要用三种视觉表达与 Q2 的 A 配套成立：误判由人工覆盖兜底，覆盖记录还能当调权重的样本
推荐
推荐 C。这条一旦定了，C3-2 判定台与 C5-2 确认流第 2 步的画法随之确定；不定则这两块画不了——本稿因此把它们画成只读、不可覆盖。
PM-Q8scope_drift 升审之后，用户能做什么？挡轮 2
业务背景

这是方案 §3 的第二处强制。注意时序：changed_files 是 run 跑完之后才有的，所以升审必然是事后的——代码已经改了。方案写明了「自动升为待用户审」，但没写用户在这一屏能做什么动作。没有动作定义这一屏就画不出来，也很容易退化成又一个没人处理的通知。

选项利弊与业务影响
选项利弊业务影响
A 只通知实现最轻与 pending_acceptance 空转同构，大概率被忽略等于没有第二处强制
B 三选一：接受越界 / 要求回滚 / 打回返工每种情形都有出路；「接受越界」把 impact 低报当场修正「要求回滚」需要真有回滚通道，否则是个按不了的按钮让低报 impact 有真实纠正回路
C 二选一：接受越界 / 打回返工（回滚交给 rollback 字段各自说明）不画按不了的按钮危险越界只能靠打回返工，没有「立刻撤销」最务实：rollback 各卡不同，统一按钮本来就落不了地
推荐
推荐 C。rollback 是子事项自己的字段（各不相同），统一的「回滚」按钮在多数卡上无法执行——按不了的按钮比没有按钮更糟。「接受越界」是这条机制的价值所在：把用户的一次点击变成对 impact 判定的一次校准。
PM-Q9卡 id 里的 <project> 短名从哪来？挡轮 1
业务背景

方案定了卡编号 = <project>_<seq>，例 workbench_1、publishkit_1，序号按项目各自递增、project_id 字段已存在。但这两个短名本身从哪来没有规则：如果人工每次现起，两个人对同一项目起了不同短名，_<seq> 的唯一性就断了，而卡 id 是不可变主键，起错了改不了。

选项利弊与业务影响
选项利弊业务影响
A 从 project_id 机械派生零维护，永不冲突派生规则要保证不同项目不撞；personal-workbench 派生出的短名未必是用户想口头念的安全但可能拗口——而卡 id 是用来口头引用的
B registry 里给每个项目一个不可变 short_name，建卡时校验存在且唯一短名是人选的，好念；唯一性由校验保证；registry 已是既有注册中心新项目要先注册短名与「口头引用」意图匹配，失败是建卡时报错（可修）而不是事后主键撞了（不可修）
C 建卡时自由填最灵活主键不可变 + 无校验 = 迟早撞且不可修不建议
推荐
推荐 B。这条不定，轮 1 连第一张卡的 id 都开不出来。TL#3 同步指出：只有 project_id 存在不等于能生成 workbench_1——还缺序号原子性与并发冲突方案。
PM-Q109 节 37 块要不要分页签？不挡轮次 · 属版式
业务背景

参考稿把内容切成 5 个页签，靠切换降低单页长度。本稿有 9 节 37 块。一页到底会很长，分页签则失去「原型与逻辑同屏」的连贯感。

选项利弊与业务影响
选项利弊
A 一页到底 + 顶部锚点锚点直达，可 Ctrl+F 全文搜，可整页打印/转 PDF页面长
B 分页签单页短跨页签对照要来回切；Ctrl+F 搜不到隐藏内容
C 一页到底但 C7–C9 默认折叠兼顾长度与可搜索折叠内容易被忽略——而 C7 恰恰是本轮最需要看的
推荐 · 本稿的处理
PM 推荐 A；本稿按 A 落地（这一项属 design 的版式权限）。rev2 另做了一层改进：把「长」的来源——字段表——全部收进折叠，主线只剩可点的界面，既保住全文可搜，又不用滚很久。这一条不必再拍板。
TechLead 第 7 节 · 分歧 / 不可实现项（34）
「挡哪一轮」严格按两个来源标注：§8 归属 = TechLead 第 8 节明列的轮 1 / 轮 2 必裁清单；自身线索 = 该条目原文里自己提到的轮次。两栏都空的表示 TechLead 没有给出轮次判断——本稿不代它裁。
TL#1卡六态只有数量，没有落库枚举轮 1 必裁

PM 给出的中英文方案只是推荐，不是唯一真源；status 默认值、迁移表和测试断言因此不可实现。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C2-1 · C5-1 · C8-2 · 同 PM-Q4
TL#2items[].state 与「执行态永不落卡」正面冲突轮 1 必裁

本规格把它限定为 view 派生字段；方案没有给出它的类型、值数或值名。若意图持久化业务态，必须另定字段语义；PM 大纲提到的六态不能反向冒充方案决策。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C2-3 · C1-1
TL#3主键生成缺 project 短名规则、序号原子性和并发冲突方案轮 1 必裁

只有 project_id 存在不等于能生成 workbench_1。当前不能实现一个不会撞号的 ID 分配器。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C2-1 · C2-8 · C9-2 · 同 PM-Q9
TL#4backlog_id 必填性未定轮 1 必裁

可空会绕过现有 not_reviewed 门，必填又会让 backlog 成为卡前置。

§8 归属：轮 1 必裁 · 自身线索：PM Q5 正在等裁决 · 影响：C2-2 A 区 · C2-8
TL#5关键内嵌子结构缺失（七类）轮 1 必裁

mirrors、confirmation、acceptance、timeline、session_plan、user_approval、rollback、impact.reversible 完整枚举、usage schema 都没有字段级定义。若用任意 object，会直接击穿 32KB / 无自由文本纪律。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C2-2 · C2-3 · C3-1 · C4-1 · C5-2
TL#6没有并发控制字段轮 1 必裁

卡是整行原子替换且会被 operator、planner、worker result 同时写；不引入 version / updated_at 或等价 ETag 会丢更新，但方案未批准这些字段。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C2-8
TL#7「outcome 终态写一次」与 retry 链冲突轮 2 必裁

首个 failed run 冻结后，rate-limit retry / 人工 retry 的成功 run 按字面不能成为最终 outcome；必须决定 outcome 是「首次终态」、「最后一次尝试」还是新增 attempts（后者违反六字段定长）。

§8 归属：轮 2 必裁 · 自身线索：— · 影响：C2-5
TL#8outcome 写入时机与现有终态流冲突§8 未列

artifacts 在 terminal patch 之后保存，generation 又会先消费；失败重放无法补冻，cancel 另走路径，usage 还可能晚到。需要重构为原子 finalize，不是「加六字段」这么小。

§8 归属：— · 自身线索：— · 影响：C2-5 · C8-1
TL#9gate(impact) 看不到 item.rollback§8 未列

方案同时把 rollback 放在 Item、又要求 gate 纯函数因 rollback=none 提升。只能拆成 gate + effectiveGate；NOTIFY 是否也提升未定义，该接口矛盾需 GM 裁决。

§8 归属：— · 自身线索：需 GM 裁决 · 影响：C4-1 计算器（本稿严格只提升 AUTO，对应 TL 用例 G14）
TL#10deploy_targets[] 称由路径推导，但没有映射表轮 1 必裁

在映射确定前，「无部署」不可可靠判断，NOTIFY 可能误放。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C4-1（本稿因此把它做成手动开关而非自动推导）· C4-2
TL#11方案类目化的 PROTECTED_PATHS 漏保护真实不变量文件§8 未列

零拼接还由 workers/mac-worker/prompt-pack.mjs 承载，原生 resume 参数在 runner-codex.mjs / runner-claude-code.mjs，CLI 互斥在 cli-usage.mjs，部署路由还受 package.json / scripts/devops-deploy-and-verify.mjs 影响。加入会改变批准清单，需 GM 明示；不加入则「来自本仓已有不变量」不完整。

§8 归属：— · 自身线索：需 GM 明示 · 影响：C4-4（本稿按已批准清单画，不擅自加行）
TL#12路径 gate 不能保护 server.mjs 的「某些段」§8 未列

只能保护整文件，导致大量普通 server 改动都 REQUIRED；这是安全但更保守的实际后果。

§8 归属：— · 自身线索：— · 影响：C4-4
TL#13sessionPlan 的特征阈值不完整轮 1 必裁

fresh/stale 的提交数或时间阈值、oversized session 的大小、last_activity_at 代理 cutoff、候选同分 tie-break 都未定义；纯函数权重可测，事实提取器不可定稿。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C3-2 判定台 · C3-5
TL#14sessionPlan 签名信息不足§8 未列

Item 没有目标 runner/cwd 字段，硬门却要比较 runner lock、adopt cwd 与 allowlist；热 / 非热冲突还依赖兄弟 Item 的路径与已分配 session。必须由 adapter 传 normalized candidates，不能只靠持久 Item 自给自足。

§8 归属：— · 自身线索：— · 影响：C3-3 硬门
TL#15硬门与热文件门可能无解轮 1 必裁

热文件要求同一 session，但该 session 可能 deleted / CLI in use / engine 不符；PM 四态没有「blocked / 无可行计划」。把它画成「强制新建」会违反物理串行约束。

§8 归属：轮 1 必裁 · 自身线索：— · 影响：C3-2（点候选 TL S6 可看到 blocked）· C3-4
TL#16「CLI 占用中」今天只是 heartbeat UI hint，不是服务端锁§8 未列

规划与派发间存在 TOCTOU；轮 2 必须在 dispatch 再查并使用真正的 session execution mutex，单凭 15 秒心跳不能保证互斥。

§8 归属：— · 自身线索：轮 2（条目原文自带）· 影响：C3-3
TL#17engine lock 目前不是所有派发入口的统一前置§8 未列

已有 message route 会强制回正，但 backlog/task/direct run 等路径并不都走同一判定；新卡路径绿不能证明全局不变量。

§8 归属：— · 自身线索：— · 影响：C3-3
TL#18「唯一收窄派发口」今天并不存在§8 未列

session chat、attach-token、direct runs、backlog、tasks、retry、GM loop 等多处都能 createRun；现有 CLI 还先建 session 再发 message。Q1 未拍板前只能显示野 run，不能宣称门已闭合。

§8 归属：— · 自身线索：Q1 未拍板前（PM-Q1 挡轮 2）· 影响：C5-5
TL#19run_ids[] 反向复制与现有 TASK 纪律冲突§8 未列

listRunsByTask 明确以查询取代 task 上冗余 run_ids 防漂移；方案却要求 Item 持 run_ids[]。若照方案实现，只能在 createRun 同一原子事务追加，并承担 retention 后长期悬空；仍是双写风险。

§8 归属：— · 自身线索：— · 影响：C2-8 · C2-2 B 区
TL#20artifact「不清理」不等于指针可靠§8 未列

当前保存可产生 orphan、无按 ID 读取、run 删除后非公开 artifact 走不到、公开文件可撤下而 row / URL 不同步，artifact kind 契约与生产 html 也有漂移。

§8 归属：— · 自身线索：— · 影响：C2-5 ③ · C8-1 硬事实 2
TL#21artifact 集合本身没有容量 / 保留上限§8 未列

outcome 虽定长，永久 artifact meta 和重复上传仍能膨胀 store；方案把「豁免清理」当优点，却没有相应红线。

§8 归属：— · 自身线索：— · 影响：C8-1 硬事实 2
TL#22heartbeat 容量和成本未估§8 未列

不能把 cli_sessions_in_use 的 50 偷用给 session_worktrees；每 15 秒对大量 session 执行 git 命令会拖慢 heartbeat，且只比较本地 main，不代表远端新鲜度。

§8 归属：— · 自身线索：— · 影响：C3-5 · C3-1
TL#23scope_drift 的 changed_files 语义未定轮 2 必裁

rename、delete、未跟踪文件、目录 glob、生成物、子模块如何匹配都影响是否升审；用户触发后能做什么也在 PM Q8 未决。

§8 归属：轮 2 必裁 · 自身线索：PM Q8 未决 · 影响：C4-3 ②
TL#24accepted 只属用户目前只能做业务约束，不能做身份保证§8 未列

operator / worker token 可回退共用，agent 也常经 operator 通道执行；没有 user-presence 或独立 principal 就无法证明点击者是用户本人。

§8 归属：— · 自身线索：— · 影响：C5-6 · C2-4 decided_by
TL#25长度与 32KB 的计量单位未写§8 未列

JS UTF-16 code unit、Unicode code point 与 UTF-8 JSON 字节会对中文 / emoji 得出不同结果；本文分别建议 code point 与序列化字节，但都需批准。<50KB 是轮 1 初始迁移验收，不是每卡或全局长期上限。

§8 归属：— · 自身线索：提到轮 1 初始迁移验收 · 影响：C2-6 · C2-8
TL#26反向索引有过度设计风险§8 未列

上限只有 500 卡 / 15,000 Item，全扫可能已足够；四张 Map 带来 invalidation、原子提交与重建一致性成本。方案已明确要 Map，本规格照做，但实现工作量不应按「加四个 Map」低估。

§8 归属：— · 自身线索：— · 影响：C2-7
TL#27工作量被明显低估§8 未列

这不是单个 collection：至少跨 storage 白名单与原子持久化、server CRUD/状态机/统一派发、worker heartbeat/git 采集、run finalize/cancel/retry、artifact 按 ID 查询、contracts 两个纯函数、CLI 单入口、身份边界、prune reconciliation、QA/verify 和后续 UI。轮 1/2 若不拆 acceptance gate，容易得到字段存在但纪律不成立的半成品。

§8 归属：— · 自身线索：轮 1/2（条目原文自带）· 影响：C6-1 · C6-2
TL#28PM 的「子事项级验收」没有对应字段§8 未列

user_approval 是 gate REQUIRED 的派发前批准，outcome 是服务端快照，都不能代表用户验收；若 C5-6 必须有子事项验收，需要方案新增字段或明确只做卡级 acceptance。

§8 归属：— · 自身线索：— · 影响：C5-6（本稿只画卡级）
TL#29指针字段未定型，四张反向索引无法完整覆盖§8 未列

mirrors[]、deliverables[]、evidence_ref 是 string、typed object 还是 URI 尚未定义；在裁决前只能无歧义地索引 contract_docs[] 和 outcome.artifact_ids[]，否则字符串猜型会误建边。

§8 归属：— · 自身线索：— · 影响：C2-7 · C2-2 · C2-4
TL#30原型的「打回原因」没有存储落点§8 未列

卡禁止自由 notes，timeline 又只记节点不记内容；要满足 C5-3，只能新增原因指针或复用一个已定义的指针结构，不能把正文偷偷塞进 timeline。

§8 归属：— · 自身线索：— · 影响：C5-3（本稿把原因输入框画成禁用）
TL#31容量红线可能反过来吃掉必需快照§8 未列

卡接近 32KB、timeline 已 100 条或 run_ids[] 长期增长时，终态 outcome / scope drift 无空间可写；对 worker 返回 413 会违反「必须抗 prune」。必须预留每个 Item 的终态预算或定义 server-derived 节点的有界淘汰规则，但方案没有给预留字节数或 timeline 满后的行为。

§8 归属：— · 自身线索：— · 影响：C2-6 · C2-5 · C8-1
TL#32总卡 500 没有释放策略§8 未列

schema 没有 archived / deleted 字段，也没有删除权限与审计规则；长期运行达到 500 后将永久拒绝新卡。若允许删又会破坏「决策与产物唯一权威」，需先定义归档 / 冷存储而不是补一个 DELETE 即算完成。

§8 归属：— · 自身线索：— · 影响：C2-6 · C8-2
TL#33建议 session 名只有例子，没有生成算法§8 未列

workbench_12:会话统一 · 轮1(dev) 无法机械推出标点、截断、旧名重命名和冲突处理；C3-6 只能画方案示例，不能写成可执行的输出契约。

§8 归属：— · 自身线索：— · 影响：C3-6
TL#34「有卡无子事项」run 没有创建端点§8 未列

两个 nullable 键的数据模型允许它，PM 也要求展示，但方案只定义 Item 派发；开放 direct run body 又会绕过卡门。应明确卡级 run 的用例与唯一服务端写入口，否则该态只能兼容读取、不能主动创建。

§8 归属：— · 自身线索：— · 影响：C5-5（M9 第二类）
D 组 · 本稿制作中撞到的三份真源冲突（design 不代裁）
D1演示 id 该标「真值」还是「待实读」design 发现

PM §5.3 把 bkl_e4eea7d5687a / sess_299b637d8fa4 / run_d9460febba8f / run_684acbf031b3 列为「真实锚点（真值）」；TechLead §6.2 C9-2 要求「sess_*/run_*/art_* 只有经现有 API 实读才可标真值」。本稿未读 store。

本稿临时处理：双标——同时挂「真值 · PM §5.3」与「待实读 · TL §6.2」两个角标，两边都呈现，不择一。
D2判定算式里的「引擎一致 +0」design 发现

方案 §2 的算式含「引擎一致 +0」一项；TechLead §3.2.4 的九项权重表不含该项，并明写「没有『引擎一致 +0』奖励」。两者合计都是 30，不影响结果。

本稿临时处理：按 PM §6.1「数值必须原文照抄」在 C3-1 折叠区逐字保留方案原式（含 +0 行），并就地标出分歧。
D3docs/86:3 的描述与实读不符design 发现

PM C1-2 描述为「170 字自由长句，混装 run id、复核方式、部署进度、当前批次」；本稿实读该行约 96 字符，可辨认的混装类目只有 run id 与 复核方式两类。

本稿临时处理：按实读原文展示，不按描述作画；差异写在 C1-2 折叠区。
C7-2 已答归档（11 条 · 分两组，不得混为一组）
已答 A方案已明文答复，不再重列（6 条）已答
  • 事项锚点 = 事项卡（docs/87 OQ-1）→ 方案已批准，本方案即是答案
  • 子事项实体化、粒度为「子事项」而非「轮次」（OQ-2）→ 方案 §1 items[] 已落定
  • 存量不回填（OQ-5）→ 方案 §6 已细化为「backlog 只给未收口的建卡 2–4 张 / 决策只回填 5–10 条 / run 与 session 零动作」
  • 建卡方式 = 显式创建而非半自动回写（OQ-6 的 A）→ 方案 §7 风险 2 把闸门做在 wb:dispatch，等同选 A
  • 卡编号规则 → 方案「用户已拍板」第 4 条：项目名_序号 + 卡名，workbench_1:UI修改
  • 审核门分级、卡片为唯一权威、飞书本轮不动 → 方案「用户已拍板」第 1–3 条
已答 B推荐过但用户从未表态 —— 建议本轮打包确认一次（5 条）待打包确认

这 5 条一直被当作「已定」在用，实际上用户没有正面答过。都不挡轮 1，但轮 4 画面板时全部会用上。

  1. OQ-4 与 Tasks 看板的关系 = 并存（卡 = 业务阶段主视图，看板 = 执行细节视图，单向下钻）——方案 §5 轮 4 的验收口径已隐含并存，但未明说
  2. OQ-7 用户确认门与 PM 评审门 = 串联双门（PM reviewed 是建卡前提，用户确认是派发总闸）——与 PM-Q5、PM-Q6 直接相关
  3. OQ-8 session 批量改名 = 建议 + 一键，可单条取消
  4. OQ-9 契约文档 = 面板内只读预览为硬要求（不允许只给外链）
  5. OQ-D1 列表排序 = 待我处理优先、OQ-D2 展开形态 = 页内展开（contract-card 交互稿的两条设计推荐）
怎么机械核对这一节：每项标题里的编号可直接 grep——grep -o 'TL#[0-9]*<' index.html | sort -u 应恰好覆盖 TL#1–TL#34；grep -o 'PM-Q[0-9]*<' index.html | sort -u 应覆盖 PM-Q1–PM-Q10。不要用不带右边界的 grep 'TL#1'——它会同时命中 TL#10–TL#19，既会误判存在、也会掩盖真缺失。挡住轮 1 的 15 项 = PM-Q2·Q3·Q4·Q5·Q7·Q9（6）+ TL#1·2·3·4·5·6·10·13·15（9），可用顶部筛选按钮只看这 15 项。
C8

事实基线

稿上这些数字哪些是真的？哪些是画的？
C8-1三个硬事实 → 各自逼出哪个界面

① 终态 run 超 7 天整行删除
事件流超 2 小时清空

关联若只存在 run 上必然蒸发 → 卡必须持冻结快照。
界面后果 → C2-5「记录已按保留策略清理，结论见快照」

② artifacts 集合
不被清理

卡内只存指针，不复制 artifact body / HTML / URL / report 正文。
界面后果 → 产物 chip 活得比 run 长；公开 HTML 只读服务端铸造的 meta.public_url

③ 隔离单位是 session
工作区不跟随主干

每条 session 独占 session/<sid> 分支与旁路工作区，建时从 main fork、之后不自动跟随。
界面后果 → C3-4 串行门必须表达为「不可选」而非「建议」
硬事实不是背景介绍，是三个界面块的成因。三条都实读自代码（storage.mjs:425-426 等），但其中两条今天并不成立——见下方折叠。
今天还做不到的部分（点开）
硬事实 1 的缺口：现有终态路径不是原子的（artifacts 在 terminal patch 之后保存、generation 先被消费），需重构为 finalizeRunAndFreezeOutcome（TL#8）；现有异步整文件 persist 无 durable ack，无法保证进程在内存写后、落盘前崩溃时不丢快照；卡若已接近 32KB / timeline 已 100 条，终态快照可能无空间可写（TL#31）。
硬事实 2 今天并不成立，本稿标为目标态而非真值：当前 artifact 保存 API 没有父 run 存在 / ownership 校验、没有 getArtifact(id)，run 删除后非公开 artifact 走不到，公开文件还可被单独撤下而 row / URL 不同步（TL#20）；该集合没有容量 / 保留上限（TL#21）。
硬事实 3 的缺口：heartbeat 的 session_worktrees 字段不存在；每 15 秒对大量 session 跑 git 会拖慢 heartbeat；数组容量上限方案未定义（TL#22）。
C8-2真实枚举清单C8-3黑名单C8-4事实更正

可标真值的三组枚举

gate 三值 · decisions.status 三值 · run 八态

必须待补的两组

卡六个落库键 · Item state 全部值

更正：run 是 8 态不是 7 态

docs/87 多处与 contract-card README 写「7 态」；实读 packages/contracts/index.mjs:4-12 为 8 个值。本稿一律按 8 态。
queued · waiting_for_worker · waiting_for_rate_limit · running · waiting_for_approval · completed · failed · cancelled 真值
八态只用在 run 侧——不得把八态误写进卡 status 或 Item state。outcome.status 只取其中三个终态。复用旧文档不等于复制旧错误。
M1–M11 全部多态 · 黑名单逐条对账（点开）
#组件态名（照抄，不意译）档位
M1卡 status拆解中 / 待用户确认 / 进行中 / 待用户验收 / 已完成 / 阻塞待补 只有「六态」数量是真值（TL#1 / PM-Q4）
M2子事项 state未开始 / 进行中 / 待复核 / 待验收 / 完成 / 阻塞待补 方案未给类型/值数/值名（TL#2）
M3gateREQUIRED / NOTIFY / AUTO（大写照抄）真值 方案 §3
M4session 判定结果①硬门否决→强制新建 ②HOT_FILES 交集→强制同一条 ③≥40→复用 ④<40→新建四态照抄方案 §2；第五技术态 blocked 待裁决（TL#15）
M4b叠加标记（非第五态）serialize_after 已写入 / behind_main 为代理值或缺失真值 方案 §2
M5decisions.statusopen / decided / superseded真值 方案 §1
M6产物 chip 可用性已产出可点 / 未产出（虚线置灰 + 依赖说明）/ run 已被清理（只剩快照）三态规则真值；「证据指针不可用」子情形来自 TL §2.2
M6b产物类型（docs/87 五类）文档→面板内预览 · 设计稿→新开页 · run→详情抽屉 · 复核报告→面板内查看 · 部署链接→新开页映射真值；指针类型未定（TL#29）
M7run 状态八值（见上方）真值 packages/contracts/index.mjs:4-12
M8none 特例reversible=none→直判 REQUIRED；rollback=none→AUTO 提升 REQUIRED规则真值；完整枚举与「NOTIFY 是否提升」未定（TL#9）
M9run 与卡的关系有卡有子事项 / 有卡无子事项 / 无卡 = 野 run（灰行）三类真值；第二类无创建端点（TL#34）
M10空态与异常态一张卡都没有 / 判定算不出 / 拒写反馈（400 / 413）三态真值；具体实例示意
M11主题light / dark（顶栏可切）真值 DESIGN.md v2
黑名单类别（PM §5.2）本稿实际怎么做的
卡序号 <seq> 真实值只用方案原文举例的 workbench_1/publishkit_1/workbench_12/workbench_0 + PM 登记表明标「序号示意」的 workbench_2/workbench_3，均带示意角标
dec_<12hex> 具体值全稿一律写 dec_…，没有出现任何具体十六进制
D 区消耗 / 成本合计C2-2 D 区不给任何数字，只画字段与「无出处」说明
打分合计分合计分只出现在 C3-1 / C3-2 判定台（严格取自 TL 用例 S1–S15 的算术），标「方案示例 / 用例编号」；其余屏不给分
session 现名C3-6「现名」列留空并写明原因，不填假名
时长 / 耗时 / 进度百分比 / 排队位置 / 剩余时间全稿零出现。C5-4 不显示 SLA；C6 不显示百分比 / ETA / 完成数
时间戳 / 日期只出现文档里已有的 2026-08-13（用户拍板 OQ-1=B）与 2026-08-16（用户批准方案）
gate 历史判定结果C4 计算器的输出是按规则实时推演，不是历史数据；具体 Item 档位均标示意
behind_main 实数「37」全稿只出现一次（C3-1 折叠区），标「方案示例」；C3-5 只画三种形态，不给数
卡总数 / 卡级 gate rollup / prune 演示结果本稿不给卡总数；卡级 gate 只画规则与单卡示意；prune 只画「清理后长什么样」
不同时点的统计数不得混用（PM §5.1 第 5 条）。方案统计的是 backlog 9 / run 98 / session 200 / linked_run_id 有值 0；docs/89 统计的是 189 条会话中 175 条无原生身份。两者不同期，不得相加或互相印证。本稿只引用前者、且标明是方案撰写时的基线不是实时 API；docs/89 的两个数全稿未引用。
方案撰写时的基线（非实时）：backlog 9 / run 98 / session 200，linked_run_id 有值 0、run 上没有 backlog_id 字段；决策散在 9–12 个互不连通的载体；同一决策记在 5 处、给出 3 种矛盾答案；OQ-1 在 10 份文档里含义各不相同；sess_299b637d8fa4 的 31 个 run 横跨 ≥4 个主题。
仍待 tech-lead 复核两处：docs/87 其余行号引用是否仍准（本稿引用处均标出处，未做行号级校验）；C2-8 的逐字段 路径:行号（目前只到段级）。
C9

演示数据与标注图例

稿上这几张卡是我真的事，还是编的？
C9-1三类角标顶栏可切C9-2案例登记

真值

能在三份真源之一里逐字找到，或实读代码 / 文档所得。出处写在对照表里。

示意

东西是明确的，只是今天取不到值（字段 / 端点 / 集合不存在，或需实读 store 而本稿未读）。

待补

方案本身还没定义，任何值都是编的。命中 TL#1–34 或 PM-Q1–Q10 之一。凡待补的本稿画占位，不画内容。
顶栏「标注：开 / 关」切换：关闭时隐藏全部角标，并把被标注为示意 / 待补的值压到 28% 不透明度。压暗后仍清晰可读的，就是本稿有出处的部分。
三类角标都带文字标签，不靠颜色单通道区分（DESIGN.md v2 §1）。marker 板在本稿只用于这一处分类语义，不作状态、不作装饰，同屏 3 种符合 §3.5 的「同屏 ≤3 种」上限。
五个演示案例登记表 · 可抽查（点开）
#案例卡 id真实锚点已知缺口
1wb-ui 换肤 / 组件库对齐workbench_1:UI修改 方案原文举例bkl_e4eea7d5687a · docs/86 · sess_299b637d8fa4 · run_d9460febba8f（轮 0，GM 复核 14/14）· run_684acbf031b3（轮 2 批次 1，5/14 已重发待验收）· ui.heyyys1.com（轮 1 产物）真值 PM §5.3待实读 TL §6.2docs/86:3 可原样引用（已引，见 C1-2 与 D3）；两个 run 是否已过 7 天保留期不得断言，演示悬空态时标「若已过保留期」
2统一数据源 · 会话统一workbench_2 序号示意bkl_daba6ad3280d（p0，pending）· docs/89-native-session-as-primary-key-contract.md · sess_299b637d8fa4（与案例 1 同一条）· 澄清 C1–C4 未清零、未打 reviewed 不得派发（docs/89:7）卡序号示意
3publish-kit toCpublishkit_1 方案原文举例无 docs/NN、未查到 backlog 记录（实测 docs/ 下无 publish-kit 文档）backlog / session / run id 全部标「待补」，由 tech-lead 实读补齐；不得编 id——本稿一个都没编
4流程面板本身（本方案）workbench_3 序号示意bkl_f178bc628617 · docs/87 · docs/90 · design/mockups/contract-card/ · sess_e7e129b2e132卡序号示意；本轮 run id 未知，标「待补」——本稿未填
5全局约定（决策卡）workbench_0:全局约定 方案 §6 原文回填的 5–10 条决策主题：引擎锁 · OQ-1=B（只活在 docs/86 一个文件里，文内 7 次、文外 0 次）· 零拼接 · accepted 只属用户 · store 红线（92MB 事故）每条 dec_ 值标示意；这张卡无子事项、无验收
design 对案例 5 的回应（PM 邀请在稿内提出异议）：同意「与普通卡同构但单独分区」。它的 A 区与决策区结构与普通卡完全一致，只是 B 区为空、E 区只剩「新增决策 / supersede」——同构可复用同一套组件，分区可避免它混进「待我处理」统计。但注意 TL#1 指出无 Item 卡的卡级 gate 未定义，所以它的卡级门本稿画成空（同 C2-1 的 workbench_2 行）。
本稿未使用参考稿目录。PM 与任务书都点名参考 design/mockups/wb-redesign/，但本工作区 design/mockups/ 下连续两轮都不存在该目录。rev2 的交互形态改以本仓已批准的同主题交互稿 design/mockups/contract-card/app.js 为范式（modal / toggleCard / previewState 那一套）。如需逐项对齐 wb-redesign，需先把该目录带进工作区。
附录

名词说明

每个词只解释一次；正文里首次出现时可点它弹出这段话
16 个词 · 大白话解释（点开）
锚点稿子顶部导航里的一个跳转目标，形如 #c-model，点一下直接滚到那一节。「事项卡为唯一锚点」里的「锚点」是另一个意思：指「一件事的所有信息都挂在这一个东西上」。
多态对照把同一个界面组件的所有可能长相逐个画出来，而不是只画「正常样子」。作用是让你在审稿阶段就看见异常态，而不是上线后才发现异常态没设计。
字段 / 枚举字段 = 数据库里一个有名字的格子。枚举 = 这个格子只允许填的几个固定值之一。枚举定死了，界面文案、命令行输出、测试断言四处才能对得上。
服务端派生这个值是系统自己算出来的，界面不给输入框、接口也拒绝外部写——一旦允许填，就能靠填假值绕过审核门。
白名单 / 写边界系统只接受事先列好的那几个字段，其余一律拒绝并报错。防止有人往卡上悄悄加一个「备注」，把卡变成又一份自由文本。
fail-closed信息不全时往严的方向判。例子：没填「会碰哪些文件」，系统不假设它安全，直接判「必须你审」。反面 fail-open 等于没有门。
保留策略清理（prune）系统定期删旧数据以免撑爆存储：已结束的 run 超 7 天整行删、事件流超 2 小时清空。这就是卡必须自存「结论快照」的原因。
冻结快照run 结束那一刻，把「做完了什么、产物在哪」抄成固定六个格子存到卡上，之后不再改。它抗得住上面那条清理。
原子写 / 零副作用原子写 = 一次改动要么全成功要么全不发生。零副作用 = 一次被拒绝的操作什么都没改：没建会话、没发消息、没起任务、卡的字节数一个都没变。
幂等同一个请求重复发几次，结果和只发一次一样。网络重试时不会把同一条结果写两遍，也不会覆盖已有结论。
纯函数只看输入、不读数据库不读时间的一段计算。好处是可以单独测：给一组输入，答案永远一样。本方案两个门都要求做成纯函数。
glob路径通配写法。docs/** 表示「docs/ 下任意层级文件」，不匹配名字相似的别的目录。
硬门 / 串行门 / 打分会话判定的三层。硬门 = 物理上不可能（那条会话已删除等），推翻了也跑不起来；串行门 = 两件事要改同一个文件，只能排队；打分 = 一套加减分的经验规则，够 40 分就复用旧会话。只有第三层有商量余地。
野 run（无合约）一次没有挂在任何卡上的任务执行，系统查不出它属于哪件事、谁批的。面板上显示成灰行，不是为了惩罚，是为了让「绕过流程」你看得见。
TOCTOU「检查的时候」和「真正动手的时候」之间隔了一段时间，中间状态变了。例子：规划时那条会话还空着，等真派发时已被别的任务占用。
operator / agent / worker写入者的三种身份。operator = 你（或代表你的控制台）；agent = 干活的 AI 角色；worker = 你 Mac 上跑任务的进程。「验收只属用户」= 这个动作只接受 operator 身份。