dsh 插件依赖增量定位
§1摘要与结论
别名：dsh-anchored-standard、社区插件依赖位置分析、增量 DAG 定位 | 英文：Dependency Positioning of a Community dsh Plugin | 类型：案例 / project-analysis
§2局部关系图
§3原理 · 为什么
当生态里冒出官方清单之外的新插件，理解它的成本不在于「它有什么功能」，而在于「它嵌在宿主的哪条依赖通道上、会影响哪些既有节点」。以既有权威 DAG 为蓝本，可以把未知插件挂到已知坐标系上，用增量方式回答定位问题，避免每次从零重建全局图，就像用已知地图定位一栋新建筑而非重测整座城市。插件化架构中，模块的真实行为往往取决于它在装配期被放到哪个位置、运行时又注入了哪些服务，而不是它自身源码写了什么。三硬依据分别覆盖三种依赖来源——E1 编译依赖、E2 运行时注入、E3 组合装配——把依赖判断从主观印象转为可逐行溯源的事实，这是架构逆向可信度的地基。缺了这层证据，依赖图就退化成一张看似合理却经不起追问的示意图，越是复杂插件越容易掩盖真实耦合。由此可见，蓝本的价值是提供参照系而非结论：它告诉我们已知节点长什么样，却不能替我们回答未知插件究竟连向何处，真正的判断必须回到代码本身。对没有官方源码的对象，这套以蓝本为参照、以证据为准绳的思路几乎是让结论站得住脚的唯一方式。
§4机制 · 如何运作
流程分五步。第一，检索蓝本节点集，确认目标插件不在其中，从而把它定义为需要从零分析的未知对象。第二，克隆目标仓库并锁定与蓝本兼容的 commit，保证后续行号证据落在可复查的版本上。第三，按 mode 分片委派子Agent 深读源码，每个子Agent 逐条产出「本地代码行到官方 seam」的依赖映射，并把证据落到具体文件与行号，而不是给出笼统描述。第四，合并数据：官方内部子图、本地到官方的新增边、本地之间的装配约束，统一生成图库可消费的注入数据。第五，三段验证：JSON 与无环校验、无头浏览器按 DOM 断言节点数、视觉模型检查截图是否截断错位。用户追加需求后，再补函数级的插件内部代码依赖页，并把主图与插件页双向链接形成可导航体系。每个子Agent 的产出都要能被主Agent 合并成一张连贯的图，因此证据的格式与粒度必须事先约定，避免各说各话导致拼图对不上。各子Agent 的映射最终要能拼接成一张自洽的图，因此约定统一的证据格式与命名，比单点分析得更细更重要。
§5工程 · 怎么落地
工程量集中在「复用加适配」：直接复用蓝本的前端依赖与生成脚本，只替换数据源，就产出 42 节点、102 边的主图，以及 21 个插件内部依赖页，省去从零搭前端与渲染管线的成本。可读性上做了三重区分——本地行用圆角矩形与蓝色粗边框、官方节点用菱形与绿色边框、seam 节点用六边形与黄色边框，并在标签前缀上再次标注身份，避免用户误读层级关系。一个关键工程约束是：外部 seam 边（指向宿主服务而非内部函数）不进入内部页的图，而是单独成节展示，因为图库遇到不存在的 target 节点会整图抛错而非跳过。根入口再聚合全部交付物并回链蓝本，形成从总览到细节的完整导航。为了让读者在总览与细节之间自由切换，主图与插件页之间建立了双向深链：从总览点进某个模块可直达其内部函数图，从内部图又能一键返回全局。整体呈现按「先总览、再下钻、最后看内部调用」组织，尽量让不同背景的读者都能快速找到自己需要的入口。
§6权衡卡
案例价值在定位方法与三硬依据的工程化，而不在该插件的持久性——社区插件可能很快失维，方法论却可迁移到下一个未知模块。
若把依赖图当成终点，容易高估对系统的理解；把它当起点并持续维护，它才会长期产生价值。
决定是否值得做这类分析的，不是图做得漂不漂亮，而是它是否真的降低了后来者理解该插件的时间成本。
- 复用蓝本带来明显加速，也把成果锁在蓝本的版本与粒度上：一旦蓝本滞后或粒度失配，增量定位会被一并带偏，还需额外维护兼容 commit。
- 把依赖映射下放给多个子Agent 虽提高覆盖速度，但行号证据的保真度依赖 checkout 版本一致，版本漂移会让证据失效。
- 视觉区分与内部页是用户二轮追加需求，说明首稿的可读性并未一次到位；外部 seam 边导致整图崩溃，则暴露了「数据清洗必须先于渲染」的门控缺口。
- 更根本地，这类增量分析只能回答「在给定蓝本下它落在哪里」，无法证明宿主本身的依赖模型正确。
权衡原文仅按显式标记词归栏引用（收益 / 代价 / 反例），其余句子按原序列为「原文要点」；内容逐字引用未改写。
§7案例带
去中心化聊天架构逆向
对一个仅有 58 份设计文档、尚未实现的开源去中心化聊天项目做架构逆向：从设计文本提炼 18 个模块及其依赖关系，重建模块依赖 DAG 与三条核心数据流 DAG，并输出全景理解与深度需求分析。
网申填写扩展逆向架构
对 Chrome MV3 网申自动填写扩展的逆向架构分析：梳理 popup、content、background、options 四模块职责，解剖 12 个站点适配器、双通道消息协议与隐私脱敏机制，并评估其零依赖零构建选型。
网申 v3 多模块解耦
一套面向高可扩展性的网申信息速查扩展架构：以 schema.js 为唯一数据驱动源，把数据模型、存储、纯函数与渲染组织为严格单向依赖的共享层，供 popup 与页面浮层双容器复用，并先立跨模块接口契约。
preset 通道耦合分析
对 harness「委派工具层→续用管理器→preset 服务→MCP 服务器」这条通道做耦合分析：识别契约、服务定位、数据契约、组合语义、路径与装配一致性六类耦合点，定位「静默丢弃特化」与「装配漂移」两处实质缝隙。
dsh-manager 插件深度分析
以「编译依赖、运行时注入、组合装配」三硬依据加源码行号，对第三方插件做依赖、功能、需求溯源与设计问题裁决，并复用上游 DAG 知识库节点标识，使分析结果可与主图互查。
harness 源码架构解析
对 deepseek-harness 官方源码做分层解析：镜像官方架构文档，按九个层与九十余模块建立文档集群，产出跨层联动矩阵与七条关键路径，并钉住「模型可见即已记录」、能力缝三角等设计不变量。
Claude Code 架构逆向
以社区逆向源码、系统提示词与官方文档三源交叉验证，还原一个商业 Agent 的查询引擎、子Agent、工具与权限体系的逆向分析案例。
Open Code Review 图谱
对阿里开源 AI 代码审查 CLI 做源码级解析并构建「知识 + 实践资产 + AI 索引」三合一知识图谱的工程案例。
控制理论⊗Agent 设计
将控制理论五维（负反馈 / 状态估计 / PID / 鲁棒 / 分层）系统映射到 Agent 工程环节，并以真实产品案例验证的跨学科方法论案例。
AI Agent 架构 DAG 复盘
对四个工作日内独立完成三个异构对象 DAG 分析的方法论复盘，总结「采集→建模→生成→门控→交付」可复用管线与关键教训。
§8信源与核验
核验结论：蓝本只提供坐标系，未知插件的依赖边仍须靠三硬依据逐条源码溯源；且增量结果会继承蓝本的版本与粒度偏差，需要人工裁决与兼容维护 [LOC-029]
§9原始关系清单
展开：本节点的全部原始关系边（3 条，含边 ID 与方向）
| 关系 | 方向 | 对端节点 | 说明 |
|---|---|---|---|
| 案例印证 | → ESS-G-02 | 依赖倒置与依赖规则 E-969 | 印证：以装配与注入关系还原依赖方向 |
| 案例印证 | → MTH-G-05 | 架构文档化方法 E-970 | 印证：以蓝本为参照的多视图文档与深链互引 |
| 案例印证 | → MTH-O-06 | 粒度与边界设定 E-971 | 张力：受蓝本粒度约束，增量定位精度受限 |