任务完成报告：DeepSeek Harness 插件级 DAG 知识库 RC2 → 0.1.7-rc.2 全量重建

留档日期：2026-09-27 ｜ 复杂度：17/20（Deep）｜ 轨道：plan + build ｜ 库：0927-dsh-plugin-dag-017rc2

一、当时情况

用户需求：把 0927-dsh-plugin-dag-017rc2 的插件分析更新到最新版 dsh，并同步更新到 GitHub 仓库；建议先做架构审查。

探索后确认的环境事实：

• 目标目录 = GitHub zako-mio/deepseek-harness-plugin-dag 的本地仓（public，默认分支 v0.1.1-rc.2，master 停在 RC7→RC8），工作区干净。
• 另有 archive/dsh-architecture-map（含 09-custom 自定义层 + changelogs 的本地维护库，无 remote，其 SKILL 明令禁止 push）。
• 库现状（现场跑门控实测）：180 节点 / 578 边 / 39 组 / 17 层 / 50 seam / 230 页，quality-gate-l3.py ALL PASS。
• 上游最新 = dsh-v0.1.7-rc.2（commit 477b4f42，2026-09-24），基线为 v0.1.1-rc.2（2026-08-21）。
• 本机部署的 dsh 为 0.1.5-rc.2（落后目标 2 个 minor）。

关键量化事实（本次任务的性质判定依据）：

二、制定计划

架构审查（产出级，按 architecture-judgment 的「评审与设计裁决」档；规模三问命中 Q2）：

• 结论 = 有条件放行。放行的前提是放弃增量级联——原方法的省力假设（「80% 包仅版本号变化」）在本轮被实测证伪（210/210 全变、0 个版本号-only），沿用会产出大面积过期内容。
• 整改项：① 先修脚本基础设施的硬编码路径；② 分级基准必须从新 bundle patch 重新采集；③ 每条依赖保留源码行引用；④ 公开库推送前做私有信息扫描。

用户拍板四项：① 两个库都更新；② 目标版本 dsh-v0.1.7-rc.2；③ 全量重推导 + 用好委派并行；④ 新建 v0.1.7-rc.2 分支并切换为默认分支。

（后续追加约束：子 Agent 并行上限 3。）

执行计划 P0–P7：基线冻结 → 管线自建 → 分级重采集 → 21 分片并行分析 → 数据层重建 → 页面重生成 + 门控 → 文档收口 → GitHub 同步 → 维护图融合同步。

三、执行情况

P0 基线冻结

• 官方 tarball 落 05-source/dsh-v0.1.7-rc.2/，SHA256 761df167…（32MB）。
• 仓库卫生决策：旧版把解压树也提交进 git（rc8 + rc.2 共 88MB / 15712 文件）。新版树 155MB，直接提交会把公开仓库从 46MB 推到 200MB+，故改为 tarball + SHA256 入库、解压树 gitignore，并留 README.md 说明解压与复现命令。

P1 管线自建（不复活旧管线）

旧脚本依赖跨任务的 Windows 路径 D:\Opencode_Download\...\PACKAGE-MAP.json、stage-00-l2-inventory.json、stage-01-l3-r4.json 等，且其输入在 0.1.7 下全部失效。故新建自包含确定性管线（07-checkpoint/v017-*.py）：

v017-inventory.py（解 bundle patch + 枚举 321 包）→ v017-facts.py（逐包扫 src 提 E1 import 含行号 / E2 inject·ctx·事件 / 插件导出特征）→ v017-classify.py（分类 + 分组）→ v017-make-shards.py（21 片）。

过程中修掉两个自身 bug（均为「静默污染」型）：

1. id 规范化多剥一层 dsh- 前缀 → 全部 E1 边指向错误 id。复核时发现并修正。
2. type_only 判定把「类型导入 + 运行时 ctx 调用」误判为纯类型 → 56 条运行时边被排除出分层，图层被压平成 6 层。改为「机制含 E2/E3 一律不算纯类型」后恢复为 19 层。

P2 21 分片并行分析（子 Agent 上限 3）

• 契约外置落盘（v017/CONTRACT.md），每片只读自己的分片输入、只写自己的输出文件（同域隔离 + 文件域唯一写入方）。
• 共 21 片 / 239 插件，分 7 轮 × 3 并行完成。
• 回盘复验（不采信自述）：21/21 片存在、239/239 条目、0 缺失/多余 id、0 自环、0 指向装配框架的边、0 条无 file:line 证据。

P3 数据层重建

• 239 节点 / 1077 节点间边 / 536 seam 边 / 73 seam / 50 组 / 19 层。
• 环处理：SCC 分析显示只有 1 个 8 节点环（client UI ↔ dsh-api-remotes 的注册回环）。策略选「DFS 反馈边标记 soft」——保留展示、不参与分层，零信息损失。
• 不变量校验：每条运行时边 level[from] > level[to]，0 违例。

P4 页面重生成 + 门控

• 按 schema 约定修正：edges 仅节点间边（纯 seam 边入 edges 会让 gen-html KeyError），seam 边改由 external-seams.referred_by 表达，并新增 seam_edges 顶层键保留证据。
• 清理 46 个陈旧页面 → 全量重生成 312 插件页 + 50 组页 + 8 特殊模块页 + MD 镜像 + 交互图。
• 门控 ALL PASS；同时强化门控（纳入 v017 全部 JSON、特殊模块全集、seam_edges 一致性、分层方向一致性）。

P4b headless 验证暴露并修复 3 个既有缺陷

1. 交互图 URL 路由缺失：三张下钻截图字节数完全相同 → 发现 ?drill= 从未生效；而旧脚本的断言 zcount>0 在无路由时也成立 ⇒ 历史上一直是假绿。已补齐 ?drill=/#Gxx 深链并把断言改为「下钻视图 ≠ 组级视图」。
2. 图例统计取错数据源：图例从 L1-only 的 core-dag.json 取数，显示「90 个 / 32 组」，而实际 DATA 是 239 / 50。已改为从 webapp-dag.json 取数并动态列组名。
3. 门控判据对象不匹配：原用全边做环检测，与「type-only 不参与拓扑」的分层策略冲突（TS 类型环合法）。已改为运行时边必须无环 + 类型环仅 WARN。

P5 文档收口

README 全量重写、index.html 统计与说明更新、RC2-0.1.7-DIFF-REPORT.md 新建、05-source/.../README.md 新建（解压与复现）。

四、完成情况

最终数据：239 节点（L1 90 / L2 82 / L3 67）/ 1077 节点间边 + 536 seam 边 / 19 层 / 50 组 / 73 seam / 8 特殊模块 / 312 插件页。

五、反思/分析/建议

1. 「增量升级」的地基是「多数包没变」，这个前提必须每轮重测。本轮 210/210 全变 ⇒ 省力优化直接失效。判据应由实测推导，不能由历史轮次外推——这正是本轮先做架构审查、用逐包哈希先量化再决策的价值。
2. 旧管线的「可复用」是假象：脚本能跑 ≠ 输入有效。跨任务绝对路径（D:\...）与旧中间产物（stage-00/01-*）让旧管线在换版本后静默失效。自建管线时把路径本地化 + 输入自产作为硬约束，是这次能一次跑通的原因。
3. 子 Agent 自述必须回盘复验，但复验要给对判据：本次两次实质缺陷（id 前缀、type-only 误判）都是主流程自己的脚本 bug，子 Agent 无从发现；而「分片条目数 / 证据格式」这类契约项，子 Agent 自检与回盘结果完全一致。⇒ 复验的重点应放在主流程的组装与判据上，而非重复核对子 Agent 已自检的项。
4. 门控「全绿」必须逐条追问判据对象：旧的 headless 下钻断言在无路由时恒真（假绿），旧的图例统计取错数据源。二者都是门控存在但不检查该检查的东西。已改为非空断言 + 正确数据源，并新增两项一致性检查。
5. 公开库的仓库卫生要有明确取舍：解压树入库让仓库 5 周内膨胀到 200MB+，收益（可离线 diff）远低于 tarball + SHA256（同样可复现）。已在 .gitignore 与 05-source/README.md 固化该约定。
6. 遗留建议：① 把 07-checkpoint/v017-* 的「分片 → 委派 → 合并」流程固化为可续跑 SOP（当前 21 片委派是人工编排）；② 交互图可对 type_only 边加虚线样式，供人工区分运行/类型依赖；③ headless-verify 可加「点击组节点」的真实交互路径（当前走 URL 深链）。
7. 下一步（可选）：把本机 dsh 部署从 0.1.5-rc.2 升到 0.1.7-rc.2，并按 dsh-architecture-map 的融合单流程重跑自定义层（~/.dsh 8 插件）兼容性审计——本次未涉及部署升级。

六、追加决策：留档迁移 + 本机部署升级

6.1 留档目录迁移（用户决策）

• 整仓（含 .git 与远端绑定）由 Mission-file/2026-08/0822-plugin-dag-v0.1.1-rc2 原子 mv 至 Mission-file/2026-09/0927-dsh-plugin-dag-017rc2。
• 全量核对：迁移前后文件数均 31338、目录大小均 456MB、git status 干净、git remote 不变、HEAD 仍为 f91c383。
• 收尾清扫：剩余 13 个（维护库另 24 个）残留硬编码绝对路径脚本改为 dirname(dirname(__file__)) 自推导（含 Windows 反斜杠形式），py_compile 全量 0 失败；全库「旧路径 / 旧目录名」残留 0。

6.2 本机 dsh 部署升级（用户决策：升到 0.1.7-rc.2，插件继续不挂）

• 前置断言：无运行中 dsh 进程 / 3080 空闲 / systemd inactive / 磁盘余 897G。
• 执行：mv 原子备份到 ~/.dsh-backups/dsh-0.1.5-rc.2-20260927（1.8G，零拷贝）→ git clone --depth 1 --branch dsh-v0.1.7-rc.2（commit 477b4f4）→ 回灌 .env / launch-web.sh / launch-headless.sh → pnpm install（39.8s）→ pnpm run build（exit 0，343 client artifacts）。
• 验证：--version = 0.1.7-rc.2；.dsh-build/client-build-environment.json = 0.1.7-rc.2 / 477b4f4 / 343 artifacts；systemd 启动成功、127.0.0.1:3080 监听、带 token 首页 HTTP 200（34303 bytes）且 __DSH_BOOT__ 与 60+ 客户端插件包已加载；引导日志 0 error；随后按惯例还原服务为 inactive。
• 性能适配：构建耗时较长，按用户要求改为后台非阻塞 + 短轮询执行，并对构建进程 renice +15 降低对交互的影响。
• ⚠ 未通项与归因：模型调用返回 QUOTA: Insufficient Balance。按「旧树 vs 新树同时验证」方法，在旧树（0.1.5-rc.2 备份）复现同一错误（不同 request_id），且新树源码中无该字符串 ⇒ 判定为账户余额问题，非升级回归；另 all_proxy SOCKS 告警在两棵树同样出现，属既有环境项。需用户处理账户余额后模型调用方可通。
• 插件状态：8 个自定义插件维持不挂（注释化可逆），与用户决策一致。

七、增补：主页排版 · 索引设计 · 主 DAG 默认布局改版（2026-09-27）

本轮为页面层改版（不动 DAG 数据层，239 节点 / 1077 边不变），范围锁定三个页面：根主页 index.html、组索引 03-groups/index.html、主交互图 04-interactive/index.html。流程 = 需求对齐（3 轮 question）→ 只读原型 09-prototype/ 评审 → 并行执行 → 双门控 + headless 复验 → 收口。

7.1 当时情况

用户原始诉求：「主页排版、索引设计和主 DAG 图各节点默认位置有问题，先对齐需求。」

三个页面的改造前实测问题：

（改造前取证：index.html 统计卡为 .stat{display:inline-block;margin:4px}；04-interactive/index.html 为 cy.layout({name:'dagre',rankDir:'LR'…}) + #graph{position:fixed;left:0;right:0} 与 #side{width:300px;right:0}；external-seams.json 经脚本复核 count=73、empty_desc=73。）

7.2 制定计划

需求对齐（3 轮 question 的决策点）：

1. 索引设计范围 —— 裁定三者都算（主页 + 组索引 + 主图），作为同一套入口体系一并改，避免各改各的。
2. 主页定位 —— 重排为仪表盘：统计卡等宽自适应、零孤行、全部可点、关键页显式入口。
3. 主图目标 —— 一屏可读 + 按区排布 + 保留按组高亮（不牺牲既有交互能力）。
4. 落地方式 —— 改脚本 + 补生成器，产物一律由生成器派生、不手改（主页此前为手工维护，本轮补出唯一生成器）。

关键「数据实测否决」过程（两版分区方案被实测否决）：

流程约束：先出只读原型 demo（落 09-prototype/，不碰任何生产页）供评审，通过后才全量改生产页与生成器。

7.3 执行情况

并行子 Agent 分工与集成收口：

• 三条线并行：① 主页（gen-root-index.py）；② 组索引 + 插件页骨架（gen-html-l3.py）；③ 主图数据 + 下钻几何（gen-overview.py + inject-data-l3.py）。
• 竞态与收口：主页生成器需要 03-groups/index.html 的锚点（#L1/#F1…），而二者并行产出 ⇒ 由主 Agent 在全部任务结束后重跑依赖方（gen-root-index.py 最后执行），消除「引用未就绪锚点」的时序竞态。

事故与回滚（02:43）：

• 现象：某子 Agent 执行 python3 07-checkpoint/gen-html-l3.py --help；该脚本当时无 argparse，--help 被忽略而全量执行，重写 239 插件页 + 51 组页 + 8 特殊模块页，冲掉动态 DAG 注入层（dyn-dag）。
• 取证：以目录级 md5 快照比对 02-plugin-pages/、03-groups/、08-special-modules/，确认非预期变化；对照 inject-data-l3.py 幂等注入产物缺失定位「注入层丢失」。
• 回滚：git checkout -- <路径>/ 三目录恢复至事故前快照；随后重跑「生成器 → 注入器」正确管线。
• 根因封堵（三层）：① gen-html-l3.py 改为 argparse 显式 --only 分阶段、默认不写盘；② 生成器一律默认 dry-run + 显式 --write；③ inject-data-l3.py 改为幂等同步器（payload 与页内 DATA 一致则不改字节），杜绝历史「用只有插件数据的 payload 覆盖整行」类事故再现。

假绿返工（下钻视图第一轮判据）：

• 第一轮 headless 判据用 includeLabels:false 统计节点包围盒相交数 ⇒ 放过了标签碰撞（标签已渲染但未纳入判据）。
• 实测暴露：含标签重叠 G06=249 / EXT=359 / G09=126 / G23=119；边默认 opacity 0.95 糊屏。
• 处置：判据改为含标签的 renderedBoundingBox() 两两相交 == 0 + 出界 == 0 + zoom≥0.9，边默认 opacity 降到 0.12，并把强判据写进 headless 验证（对 50 组 + EXT 逐一执行）。

7.4 完成情况

交付物明细：

• 3 个页面：index.html（主页仪表盘）、03-groups/index.html（区 → 簇 → 组卡片索引）、04-interactive/index.html（主 DAG 默认网格布局 + 下钻 + hover 差异化）。
• 8 个生成器 / 门控：

• README：更新（本轮改版说明 + 页面入口 + 生成器用法）。
• 原型目录：_demo/ → 09-prototype/（07-checkpoint/_demo/ → 07-checkpoint/prototype/）。

实测数字对比表（阈值 — 改造前 — 改造后）：

文件清单（本轮新增 / 修改）：index.html、03-groups/index.html、04-interactive/index.html、07-checkpoint/gen-root-index.py、07-checkpoint/gen-overview.py、07-checkpoint/gen-html-l3.py、07-checkpoint/inject-data-l3.py、07-checkpoint/headless-verify-l3.py、07-checkpoint/quality-gate-readable.py、07-checkpoint/_demo/（3 个 demo 生成器）、README.md。

7.5 反思/分析/建议

1. 无 argparse 的生产脚本不可试探执行。gen-html-l3.py --help 因无 argparse 被忽略而全量执行，冲掉 239 页注入层。建议：生成器一律默认 dry-run + 显式 --write 才写盘，并把写盘范围收窄到最小目录。
2. 事后注入层是「重跑即静默丢失」点。生成器重跑会覆盖注入内容且不报错。建议：重跑生成器必须补跑注入器（gen → inject 成对），并为注入层设专用覆盖判据（缺 dyn-dag 即 FAIL）。
3. 判据断言范围窄于被检对象的完整渲染形态 ⇒ 假绿。includeLabels:false 只测节点框、放过标签碰撞。对称失效：哑火门控（判据对象已被删除 → 恒 FAIL），quality-gate-readable.py 在干净基线上就 FAIL 属此类。建议：判据落地前先实测对象存在性 + 内置负向自测（负例必须 FAIL、正例必须 PASS）。
4. 有环图无良定义拓扑分层，确定性几何反推比自动 fit 更可靠；并行产出的依赖方须由主 Agent 收口。组级图 35/51 成环 ⇒ 自动分层与自动 fit 都不可控，改「Python 侧算坐标 + preset」后一屏可读（zoom 0.92）；主页依赖组索引锚点属并行竞态，由主 Agent 在全部任务结束后重跑依赖方收敛。建议：几何布局走确定性算路 + 断言，跨任务依赖统一在末尾收口。