公开副本：本地路径及实验主机已脱敏；图片/数据拆为站内资源。原报告中的校验哈希对应本地原件，不认证公开副本字节。研究分类与范围仍未获人工金标或外部独立审查。
ODK Download / ActivityDiary Add / Wikipedia Search交互比较 A/B/C口径与复算说明
结论：入口组并不天然构成完整的结构切集
这六条真实归档不支持用“确认同功能入口全组删边的失可达集合”直接替换 State Dominator。 Wikipedia有局部增益；ODK和ActivityDiary两个Rep均空。零不表示没有功能Region，而表示本批图中的功能发生范围不是这些入口边的排他依赖区。
| 案例 | Ⅰ输入次数 | 源 State | 删边数 | C 参考 | A 大小/交集 | B 原图 大小/交集 | B 去返回 大小/交集 |
|---|---|---|---|---|---|---|---|
| odkcollect-Rep1 | 121 | 1 | 4 | 9 | 4 / 4 | 0 / 0 | 0 / 0 |
| odkcollect-Rep2 | 109 | 3 | 4 | 5 | 2 / 2 | 0 / 0 | 0 / 0 |
| activitydiary-Rep1 | 56 | 28 | 27 | 5 | 5 / 1 | 0 / 0 | 0 / 0 |
| activitydiary-Rep2 | 63 | 31 | 22 | 4 | 2 / 2 | 0 / 0 | 0 / 0 |
| wikipedia-Rep1 | 29 | 19 | 27 | 26 | 1 / 1 | 5 / 3 | 12 / 6 |
| wikipedia-Rep2 | 55 | 35 | 45 | 39 | 4 / 3 | 5 / 5 | 8 / 7 |
433次Ⅰ输入中397次精确映射收尾图、36次历史关联未知。C只是入口触发的有限发生参考；人工可审核但未有人类金标。A/B交集用于说明本批差异，不包装成准确率。
Q1：全组删边是否比单State Dominator更能恢复完整功能？
只能恢复部分结构片段，不能普遍恢复完整功能。 Wiki原图B与C重叠3/26、5/39，比上轮Header的1/26、3/39有增益；即使用附近最佳A也只是2/26、4/39。ODK B为0，反而少于A的4/9、2/5；Add B为0，A也只覆盖1/5、2/4。去返回有更多交集，但带来真实越界。没有哪种方法在三案例上同时达到完整和准确。
Q2：何时失败，具体反例是什么？
- 未删的观察通道：ODK
g16e248:1317Drafts输入观察到下载页；Rep2g20e294:1762Sent到下载错误框，再经g20e295:1763到下载页。单条根路径足以令联合删边从反事实9/6节点变成主结果0；因果未知，原边保留。 - 共享页面/业务发生复用：Add
g29e298:348、g34e540:680是编辑已有活动的longclick，却到Add也会到的编辑State。删Add不应也不能删掉这些其他业务入口；这不是简单多找几个Add别名就能解决。 - 返回和复用入口：Wiki
g36s163 →(g86e1396) g86s414 →(g87e1434) g86s411保持可达；编辑器Link也能到共享搜索组件。某些图路径有confirmed=0的中间边，明确只作拓扑反例。 - 边界外依赖被连带：Wiki R2去返回B包含文章阅读
g93s547；R1语言配置与历史邻域需要范围决策，不能按失可达自动判同功能。 - 历史映射不全：36次已执行入口不能精确投影收尾边；ModelAction展开仅作敏感性，不能替代Concrete认证。去返回本身令部分C节点先不可达，不能记作入口删边收益。
Q3：Dominator能识别汇合后区域吗？为何不覆盖之前分支？
可以识别汇合点之后、所有Root路径都必经该点的局部区域，不保证每个汇合点都有大子树。Wiki R1 g38s204 --g54e651--> g42s213 与 g38s205 --g42e389--> g42s213 后，g42s213 的真实子树为 g40s209,g41s211,g42s213,g55s301。
支配定义是从Root到某State的每条路径都经过Header。在这些实际分叉结构中，存在到分支时尚未经过下游汇合点的路径，因此该点不支配这些分支；另一分支/替代Root又可绕开各自Header。Add颜色汇合点 g17s53 和ODK连接汇合 g1s2 都可只有Singleton。观察到汇合本身不是大Region的充分条件。
Q4：入口组与真实功能Region有稳定结构关系吗？
本批只支持一个严格关系：当入口边集合截断了到某些State的全部原Root路径时，且只在这时，B会收进这些State。 这是图依赖，不是业务归属。多Source、多Target本身不是障碍；替代入口、共享编辑/搜索组件、观察异常、Root和返回路径决定是否形成切集。失可达还会继承可选配置和其他后续业务。
语义上相同入口组既不保证是完整结构切集，也不保证其依赖闭包语义单一；同一个State可在不同业务发生中担当不同角色。三个案例不足以推导通用稳定业务边界，尤其不能把C参考当完整真值。
Q5：下一代以Dominator为核心，还是入口组+轨迹？
建议下一轮以入口触发的真实发生上下文与明确退出/移交共同检验功能边界，保留Dominator作为局部必经片段证据。本批否定的是全局排他State集合可以直接由一个Header或一个入口切集给出的充分性，没有证明Dominator无价值，也没有实施替代算法。
最值得验证的具体假设：同一功能入口触发后，可用 (入口组, 当前对象/模式上下文, 连续轨迹, 明确移交) 描述一次功能发生；再看哪些Dominator片段在多次发生中稳定复现。验证重点应是：Add的新建/编辑移交、Wiki搜索/阅读与语言扩展的边界、ODK跨功能观察边的执行对齐。用留出真实轨迹逐例核查遗漏与越界，而非追求集合更大。
这里只提出下一阶段可证伪的研究假设，没有实现在线Locator、身份系统、饱和或决策规则。本轮到此停止，等待研究者选择后续设计。