WorkBuddy
eee042c855
原型（执行会话/目标-…-d85687/ui/mcn-workbench.html） - 功能入口卡改三段纵向（图标／标题／描述各一行），68 → 111.19px，对齐 mcn-work-shop 参考卡（同视口 1249×1277 实测 133px），补 --sh-L1 投影；主因是排布不是字号 - 左侧导航重建：由「纯图标 ＋ 悬停提示」改为 64px 药丸浮栏，图标 24 在上、名字常驻在下 （名字一律 2 字，说明走 data-tip）；真值取自 tiaoyue 源站实测 （栏 64／内衬 3／圆角 100／项 56×78／字 12px-500-行高 16） - 密度 A 方案：≤1000 卡最小宽 200→160、≤820 统计条最小宽 132→96 （两处 auto-fit 只在真装不下时才缩）⇒ 768／700／560 三处转绿，其余 10 个视口未动 - 移动档隐藏导航条横向滚动轨（16px 轨道曾吃掉 52px 条高的三成，还白吃 16px 主区） 取证通道 - _tools/cap.py 改为「只连不起」：只连 9223 常驻实例，视口走 Emulation.setDeviceMetricsOverride， 不再自起 headless Chrome（顺带解除 500px 视口下限，390×844 可测） - _tools/check_js.py 新增第 5 道门禁（node --check ＋ 模板内注释反引号扫描） 文档 - 复盘-为什么第一版做得很差.md（新建）：13 轮时间轴／四类反作用／三重归因／已修与仍欠 - 3d-审查报告.md：更正 §九 那条假 ✓（把「§5.5 五条逐条过完」记成机核，实际零覆盖， 正是「五道闸门全绿却难看」的开关），补 §十二 功能入口卡高差、§十三 tiaoyue 导航逐条对照 - 3b-实测记录.md／DESIGN.md／3c-GPT 参考版与会诊／布局排版参考 ×2 机制与记忆 - .workbuddy/collab/collabctl.py：off --ws 不再全机扫描（原先一次杀掉他区＋看板共 5 个进程） - .workbuddy/memory/：本轮纪律与实测真值 - .gitignore：补排运行时噪音（ui/_scratch／__pycache__／浏览器取证临时目录／*.bak-*／一次性脚本） 闸门：语法全过／骨架八页 39 板块／变异对照 15-15／逐视口 14 绿（500×844 唯一红，缺口待拍板）／命名 2060-0-27
7.1 KiB
7.1 KiB
骨架优化方案 v2（②③分段 · 按各自权责）
取代 v1：
骨架优化方案-v1-作废-形态误归②段.md（v1 把「形态」整层划给了②段，口径错了，已留档作废）。 v1 错在哪：②段《界面布局》里「账号矩阵列表 —— 一行一个账号」这类形态描述本就不该由②段写； 而形态判定的权威工具layouts-tooling.md文首明写「⛔ 本文件是stage-delivery自己的东西」，§0 就是「先判形态，再挑骨架」⇒ 形态归③段。 写于：2026-10-08 08:5x，主会话。用户口径：「制定骨架是 2、3 步技能交叉知识，必须用 3 步骤技能，而且第 3 步可以往更好的体验修改」。
〇、骨架分两层，各归各段（判据：②段 SKILL.md §②—③ 交接口）
| 层 | 归谁 | 具体是什么 |
|---|---|---|
| 块级骨架 | ②段定死 | 有哪几页 / 每页几个板块、板块怎么排 / 跨页关系 / 每页主操作 / 每条信息在哪一档 |
| 形态与版式 | ③段 | 判形态（列表型／详情型／侧区型…）、挑版式骨架、每个板块的视觉实现与交互行为、状态与空态、响应式 |
- ②段口径原文：「骨架是判断基准，必须在②段定死」「③段不许新增／移动／删除板块，缺板块要回②段改」⇒ 冻结的是块级，不是形态。
- ③段口径原文（
layouts-tooling.md）：「⛔ 本文件是stage-delivery自己的东西」「工具型页面的版式在本项目只有这一份来源」⇒ 形态是③段的地盘，且③段有裁量权把它往更好的体验改。 - ⇒ v1 的错误：把「P1 做成矩阵」「P5 做成对照」这类形态决策当成块级改动推给②段，方向反了。
一、归②段的改动（块级，只这几处）
1.1 删掉越界的形态措辞（⛔ ②段写了形态 ＝ 侵了③段的地盘）
- P1 板块 2 原写「账号矩阵列表 —— 一行一个账号，行内三件事」⇒ 删掉「一行一个账号」与「行内」，只留块名与承载内容。
- P2 板块 2「对标内容列表」、P3 板块 2「条目列表」、P7 板块 1「待复盘列表」、P8 板块 1「发布记录列表」⇒ 块名里的「列表」同样是形态词，改成中性块名（如「对标内容」「资产条目」「待复盘项」「发布记录」）。
- 理由：块名一写「列表」，③段就被迫画列表 —— 这正是「像后台」的源头之一。
1.2 给 AI 产出补块位（功能已有，落位缺失）
2a里 AI 相关功能都有状态流转（如idle → 抓取中 → 已出候选 → 已采纳／忽略、AI 调用失败可重试、重复生成不覆盖），但2b的 P4 板块清单里没有一个块承载它。- ⇒ P4 增加一块：AI 产出与采纳（承载当前环节的 AI 产出、采纳／驳回／改后再用）。⛔ 这不是加功能，是把
2a已有的功能落到位。 - P7 同理：现有「归因结论区 —— 由人确认」把两件事混在一块，拆成 归因结论（可编辑）与 确认与改判 两块。
- P2 的「评论区洞察区」承载的是 F3 的 AI 候选选题，块名补一句「含 AI 候选」即可，不必加块。
1.3 板块分档要跟着改的
- P4 新增的「AI 产出与采纳」档位＝主屏常驻（判据：删掉它，当前环节的产出没地方看也没法采纳，主操作「推进到下一环节」做不成）。
- P7 拆出的「确认与改判」档位＝主屏常驻；「归因结论」同样主屏常驻。
- P1 的「异常值提示」若③段决定把异常标进矩阵格子，档位从「可点入」降为并入主视觉 ⇒ 回②段改档，⛔ ③段不能自己改档。
二、归③段的改动（形态与体验，③段自己定、自己负责改好）
2.1 逐页判形态（用 layouts-tooling.md §0 的「先判形态，再挑骨架」）
- P1：页面上能数出「并列的同类记录」（账号）⇒ 判列表型；但列表型里 §1 行式列表与 §2 表格式清单都不等于「一行一条」——矩阵是表格式清单的一种排布（轴转置：账号做行、日期做列），③段可以这么画，⛔ 不需要②段改块名。
- P2：并列同类记录（对标内容）⇒ 列表型；主视觉要不要带缩略图卡，是③段的视觉实现范畴。
- P3：并列条目 ＋ 单条详情 ⇒ 侧区型（§4 主从侧区：列表↔详情两个工作面来回）。
- P4：围绕单个对象（一条内容）展开 ⇒ 详情型（§3 详情面板）；七个环节轨道属于交互实现，归③段。
- P5：一稿多版并列 ⇒ 列表型（版本之间要对照，§2 表格式清单的高密度变体适用）。
- P6：单对象（一个账号）＋ 记忆流水 ⇒ 详情型 ＋ 时间线（时间线是③段的呈现选择）。
- P7：单条内容的表现与归因 ⇒ 详情型；表现数据做成数据主视觉是③段的视觉实现。
- P8：并列记录 ＋ 三样对账 ⇒ 列表型 ＋ 对照区。
2.2 ③段要补的版式档（现有 §0 只有三类，不够用）
layouts-tooling.md §0 现有形态只有 列表型／详情型／侧区型 三类，本产品至少要再补四类：
- 矩阵型（两个维度交叉的网格：账号 × 日期）—— P1 用。
- 对照型（同一母体的多个版本并排比较）—— P5、P8 用。
- 流水线型（多环节轨道 ＋ 当前环节工作区，可回退）—— P4 用。
- 时间线型（只追加、不覆盖的流水记录）—— P6 记忆条目用。
⛔ 补档要落在 layouts-tooling.md（③段自己的工具库），⛔ 不是回②段改。
⚠️ 它是全局技能包里的文件 ⇒ 改它会影响到别的工作区，动之前要由用户拍板（见主会话转出的待拍板项）。
2.3 体验上③段可以（也应当）主动改的
- 数据密度：现在是每块包成 24px 圆角白卡 ＋ 大留白，评审判定为「没认出品类」；③段有权把主视觉换成数据本身（紧凑行／列右对齐／颜色只用于涨跌与异常），⛔ 不需要②段批准。
- AI 生成中态：P4 新增的 AI 产出块，生成中显示进度与可中断、失败可重试，是交互行为范畴 ⇒ ③段定。
- 状态与空态：每一块的空态长什么样、加载中什么样，全部归③段。
- 响应式：窄屏怎么变，归③段（现有 B-15 那一条窄屏装不满 6 行，也属③段自己的账）。
三、执行顺序（按权责分头走）
- ②段（本方案 §一）：删形态措辞 → 给 AI 产出补块位 → 改相应分档。
- ③段（本方案 §二）：按新块名重判形态 → 补
layouts-tooling.md的四个档 → 重做原型视觉与交互。 - 机检基线同步：
ui/_tools/check_skeleton.py现在拿旧骨架当权威，②段改完块名后必须同步，否则逐位比对会误报。
⛔ 顺序要点：形态问题在③段解决，块级问题才回②段。v1 把两件事都推给②段，是这次最大的偏差。