设计真源 docs/92 + 用户 2026-08-17 五步流程更正 · 数据模型 docs/90 · 对接点 apps/web/index.html:2880-2889 · 视觉 design/DESIGN.md v2 + tokens.micro.css
rev2 更正:「不要确认控件」是指不要在对话框里做确认卡 —— confirm 在大卡片上点；对话里只留一个入口，卡片本体是点开后的一整屏。（docs/92 第〇节目前只记了两条纠正、无第 4 条五步流程，本稿按你本轮原话做，那节待补。）
屏 1 · 对话框里的入口 —— 对话里不铺开卡的内容
拆四条战线：组件库对齐 14 组件 / 对话流拉平 / Micro 全站换肤 / 引擎锁加固。做到哪一档？
信息齐全，已生成卡片：分配计划 5 个角色、session 计划 4 条（2 条复用 / 1 条强制同条 / 1 条新建）都在卡上，你点开 confirm。
两种任选其一（实现时只留一种）：A 更轻、不抢回答的戏；B 在长对话里更找得到，且是本条回答里唯一的动作（DESIGN.md §7.1 每条回答 1 个主按钮）。
这一屏的全部重点：对话里只有一个入口，没有字段、没有确认卡、没有分配计划预览——卡的内容一律在点开之后。
屏 2 · 大卡片 —— 被 confirm 的那个对象（整屏，不是抽屉）
只放三块：名字与背景（intent 用你原话，标 intent_source）· 分配计划（角色 / 做什么 / 交付什么，行可点开看依赖）· session 计划（几条、哪些复用哪些新建，复用那条可点开看判定分数）。派活明细与 gate 不在这一屏——那是 confirm 之后的折叠区。
屏 3 · confirm 之后 —— 排期卡落到看板（上一版的看板原样保留）
卡片显示的字段
confirm 前后卡上不一样：confirm 之前只有名字与背景、分配计划、session 计划三块——战线是「计划 4 条」、子事项 0、产出空、等我做只有一项 confirm；confirm 之后战线才开线、子事项与产出才由派活与 run 自动挂上。诚实说明:这张卡的 12 个已终态子事项与 5 条已定决策是真实历史，本稿把它们接在 confirm 之后一次显示；真实世界里它们是 confirm 后一轮轮长出来的。
列怎么排 · 方案与理由：默认分组沿用现有三列 stage（门禁 cc:test:task-center 钉住 stage→列位置，不改），另加第四组「长期约定」放纯决策卡——它没有子事项也永不完成，塞进三列任一列都会说谎；分组依据可切「战线 / 等我做什么」，这是飞书原生能力，也顺手给出另两种排法的真实观感。
与 run/task 卡怎么共存：同一看板、不分 tab。有卡的 run 收进卡内（卡是唯一锚点），无卡的历史 run 单独一张灰卡常驻——docs/90 要求「让绕过在你眼前可见」；分 tab 会把「事项与执行断链」这个根因固化成两个视图。
生长：子事项、产出、时间线节点全是既有写路径的副作用（POST /cards/:id/dispatch 建 item + 建/复用 session + createRun 一次完成；worker collectPostRunSummary → artifact 落库写 outcome），GM 主动要做的只有吐一次卡——这是 docs/92 第三节的四类追加。