对外文档/契约 4 条口径待裁决：owner 取值域 / AGENTS 下沉 / phase 缺失 / Mobile 口径

[DeliciousBuding]

来源：round-66 lane F（只读探索，对外文档技术化/可读化 + 架构叙述自洽性）。9 条发现里主机已逐条抽验 5 条并在当轮修掉，剩 4 条需要裁决或需要跨文件搬动规则，因此单独留档，不混进那个 PR。

完整证据（每条含原文锚点、判据、复现命令、修法写集、门禁影响、自评脆度）已落盘本机：/root/agenthub-dev/lane-artifacts/round-66/lane-f-REPORT.md（329 行）+ lane-f-PROGRESS.md + lane-f-BLOCKED.md。lane F 全程只读，交卷时 git status --short 为空、HEAD 仍 4ca8203e。

主机复核状态一览

编号	主张	主机是否独立复核	本轮处置
P1-1	docs/governance/known-flaky.md:46 的 Go 车道 job ID 过期（go-edge/go-hub 自 #2251 起不再跑 go test），违反本文件 :24 自己的字段合同，并与 AGENTS.md L0 行的正确映射分岔	✅ 已核（sed 原文 + checks.yml job 全集比对）	已修
P1-2	api/openapi.yaml 的 hubHealth 正文让读者 "Use /health/live"，但该端点无 path 条目、无 schema，且被 verify-openapi-contract.py 的 ALLOWLIST 刻意排除	✅ 已核（grep -n "^ /health" api/openapi.yaml 只有 /health；ALLOWLIST 原文含 GET /health/live）	已修（改为明说 liveness/readiness 子路由是有意不入契约的 ops 探针）
P2-3	「产品术语」4 个概念在 AGENTS.md §3 / docs/architecture.md 产品模型 / api/README.md 三处整表复制且已分岔（Execution Target 取值域逐处退化：四类具名 target → 小写泛称 → 完全消失），而 api/README.md 一边声明 SSOT 在 AGENTS 一边改写含义列	✅ 已核（三处原文逐字比对）	已修（两处副本压成指针 + 只留各自增量：架构侧 3 个新概念、API 侧示例字段列）
P2-5	docs/architecture/11-protocol-capability-mapping.md:19 声称端点级取值 contract 存在	✅ 已核（grep -o "x-agenthub-status: [a-z-]*" api/openapi.yaml | sort | uniq -c = implemented 212 / planned 75 / contract-draft 1，且那 1 处在 schema 级 AgentHubAgentSpec，端点级零出现）	已修
P3-7	zh/en README 对同一能力给出不同强度主张：README.md「本地执行不依赖 Hub」vs README_EN.md "local execution works offline"（docs/architecture/08-outbound-http.md 的 model_provider 出站证伪 offline）	✅ 已核（两行原文 + i18n 规则「zh/en 语义一致」）	已修（EN 改为 does not require the Hub）
P2-4	x-agenthub-owner 取值域全仓无文档定义 + 4 个 workspace 端点标已废弃组件 Runner	⚠️ lane 报告，主机未逐字复核	本 issue 留档，需裁决
P2-6	根 AGENTS.md 284/300 行的具体下沉方案	⚠️ lane 报告，主机未逐字复核	本 issue 留档，需裁决
P3-8	x-agenthub-phase 在 284 个 operation 里缺 166 个（58%），而 api/README.md §阶段标记 未声明适用范围	⚠️ lane 报告，主机未逐字复核	本 issue 留档
P3-9	Mobile 对外口径分岔：README 双语「三端原生 / Mobile 装配中」vs docs/architecture.md「fixture/边界验证 lane，非 release candidate」	⚠️ lane 报告，主机未逐字复核	本 issue 留档，需裁决

P2-4 x-agenthub-owner 取值域无 SSOT，4 个 workspace 端点标已废弃的 Runner

主张：结构化声明字段的取值域只存在于验证脚本的隐式行为里（verify-openapi-contract.py 只认 owner == "Hub" and status == "implemented" 才拉进 router 比对），文档面唯一提及是 api/conventions.md 的一行示例。实况取值分布 {Hub, Edge, Runner}，其中 Runner 命中 4 个 /v1/workspaces/** 的 planned operation；而 AGENTS.md 明写「早期独立 runner 目录已废弃」、workspace 的实现全在 hub-server（handler/service/repository/model + router 以 /web/projects* 暴露）、edge-server/internal/runners/ 只有 registry.go；api/README.md 的模块边界表又把 Workspace 归 Edge。四方矛盾。

代价：照 owner 找归属的实现者会去 edge-server/internal/runners/（无 workspace 逻辑），大概率在 Edge 新起第二套 workspace 文件读取——正是「禁止在客户端再分叉 REST 实现」要防的分叉。

复现（lane F 原文，主机未跑）：

python3 - <<'PY'
import yaml,collections
d=yaml.safe_load(open("api/openapi.yaml",encoding="utf-8"));M={"get","post","put","patch","delete"}
c=collections.Counter();run=[]
for p,it in d["paths"].items():
  for m,op in it.items():
    if m in M and isinstance(op,dict):
      c[op.get("x-agenthub-owner")]+=1
      if op.get("x-agenthub-owner")=="Runner": run.append((p,m,op.get("x-agenthub-status")))
print(dict(c));[print(x) for x in run]
PY
grep -rn "x-agenthub-owner" --include=*.md api/ docs/ AGENTS.md README.md
ls edge-server/internal/runners/; find hub-server -ipath '*workspace*' -name '*.go' -not -name '*_test.go'

为什么需要裁决而不是直接改：Workspace 的归属是产品决策——「元数据归 Hub、文件内容归 Edge」还是「整体归 Hub」，两种裁决会导出不同的 planned 端点实现位置。裁决前改 owner 只是把矛盾换个方向。

裁决后的写集（lane F 估算）：api/openapi.yaml 4 行 owner + api/README.md 或 api/conventions.md 增 3-5 行取值域定义（x-agenthub-owner ∈ {Hub, Edge}、端点级 x-agenthub-status ∈ {implemented, planned}、schema 级另允许 contract-draft）。注意：若裁决为 Hub，必须保持 status: planned，否则会被拉进 router 比对而 FAIL（router 无 /v1/workspaces/*）。

P2-6 根 AGENTS.md 284/300 行：可下沉的具体行与门禁影响

主张：行数预算只剩 16 行，下一轮任何规则新增都会撞顶。lane F 给出逐行下沉方案：测试速查段（8 行）→ developer-quickstart、发布 tag SOP（3 行）→ 对应 governance/发布文档、一段治理细则（7 行）→ governance，净回收约 14-15 行；并逐条列出搬动会触发的 5 项 doc-ssot 检查（行数预算、路径存在性、禁止对 AGENTS 做带编号章节引用、4 个锚点句、仓外链接规则）。

为什么需要裁决：搬动的是规则正文的归属位置，属于治理面决策；且必须与 P2-3 同类问题一起看（先定「谁是 SSOT」，再定「副本长什么样」），否则只是把巨石文档切成几块互相复制的小文档。

P3-8 x-agenthub-phase 缺 166/284，且适用范围未声明

主张：缺失的 166 个恰好覆盖全部 /client·/web·/edge 现实面端点，而 api/README.md §阶段标记 没有声明「phase 只标 /v1/** 设计面」这一适用范围。反证条件（lane F 自评最脆的一条）：若「phase 只用于设计面」本就是既有共识且 api/README.md 别处已暗示，则本条降级为「适用范围未写明」的文档缺口，而不是覆盖率缺陷。

处置建议：先裁决 phase 的适用范围，再决定是「补 166 个标记」还是「在 api/README.md 明写范围」。不要在没有裁决前批量补标记。

P3-9 Mobile 对外口径分岔

主张：README 双语都说「三端原生 / Mobile 装配中」，docs/architecture.md 说 Mobile 是「fixture/边界验证 lane，非 release candidate」。两者对外的强度不同。lane F 主动标注：关键佐证 RELEASE_MOBILE_ENABLED 的默认值未核实，因此本条在核实该默认值之前不足以定性谁对谁错。

处置建议：先核实 RELEASE_MOBILE_ENABLED 默认值与 mobile 车道的实际门禁地位，再统一对外口径（这属于「演示诚实」规则面，不允许 README 说得比实况强）。

验收（针对本 issue 剩余 4 条）

1. 每条动手前必须先在本机复现 lane F 的判据（主机尚未逐字复核这 4 条，只有前 5 条是主机验过的）；复现不成立就在本 issue 写「不成立 + 反证原文」并销案，不许照着报告直接改。
2. P2-4 / P2-6 / P3-9 属于需要裁决的条目：没有管理员明确裁决前不得改动 owner 取值、不得搬动 AGENTS.md 规则正文、不得改 Mobile 对外口径。
3. 任何文档改动必须过 verify-doc-ssot.py；触碰 api/openapi.yaml 还必须过 verify-openapi-contract.py（当前基线 153 / 156 / 3 / 0）。

负向约束

• 不许把「已修 5 条」当成本 issue 已关闭：本 issue 只为剩余 4 条存在。
• 不许为了凑条数把 lane F 报告里「此路不通」的 11 条（诚实墓碑、外迁台账、已自注条目、0 坏链结论）重新提出来当缺陷。
• 不许在文档里新增对 AGENTS.md 的带编号章节/行号引用（doc-ssot 有对应检查）。

[DeliciousBuding]

四条全部裁决（ADR-030，已落 docs/decisions.md，PR #2303）

裁决依据是 live tree 实测，不是 lane 报告摘要。

P2-4 x-agenthub-owner 取值域 — DECIDED

实测分布 {Hub: 203, Edge: 77, Runner: 4}，4 个 Runner 全部是 /v1/workspaces/** 的 planned operation（GET /{workspaceId}、GET /{id}/files、POST /{id}/files:read、POST /{id}/files:search）。

• 裁决：x-agenthub-owner ∈ {Hub, Edge}，Runner 退役。依据是实现位置而非叙述：edge-server/internal/runners/ 只有 registry.go，workspace 的 handler/service/repository/model 全在 hub-server，router 以 /web/projects* 暴露。
• 4 个 operation 改 owner: Hub，且必须保持 status: planned —— 否则会被 verify-openapi-contract.py 拉进 router 比对而 FAIL（router 无 /v1/workspaces/*）。这条是 lane F 自己提示的，已核对成立。
• 取值域写进 api/conventions.md（x-agenthub-owner ∈ {Hub, Edge}；端点级 x-agenthub-status ∈ {implemented, planned}；schema 级另允许 contract-draft），并修 api/README.md 把 Workspace 归 Edge 的模块边界表。
• 产品口径（这是本条真正需要拍板的部分）：workspace 的元数据与列举归 Hub；将来若确实需要 Edge 侧的文件内容端点，届时那个端点自己标 owner: Edge，而不是现在就在 Edge 预建第二套 workspace 实现。理由：预建正是「禁止在客户端/另一层再分叉实现」要防的分叉，且当前没有任何 live 消费者要求它。
• 写集 ≈ api/openapi.yaml 4 行 + api/conventions.md 3-5 行 + api/README.md 1 处表格。

P3-8 x-agenthub-phase 缺 166/284 — DECIDED：声明范围，不批量补标记

实测缺失分布：/web 91、/client 64、/edge 5、/v1 3、/health 1、/api 1、/cloud 1。

• 也就是说 lane F 自评「最脆」的那条反证条件基本成立：phase 事实上只用于设计面，缺的 166 个里 163 个是 reality-face 端点。
• 裁决：在 api/README.md §阶段标记 明写「x-agenthub-phase 只适用于 /v1/** 设计面；/client、/web、/edge 等 reality-face 由 x-agenthub-status 治理、不带 phase；/health、/api、/cloud 属 ops/非设计面，同样不带」。
• 据此只补真正违反声明的 3 个 /v1 operation，其余 163 个不动。批量补标记会把一个文档缺口变成 166 处需要长期维护的假信息。

P3-9 Mobile 对外口径 — DECIDED：单一口径

• 裁决：app/mobile-rn = 「装配中的 fixture/边界验证 lane，非 release candidate」。
• 证据锚点（可机械验证，不靠叙述）：.github/workflows/release.yml:383 build-mobile 受 RELEASE_MOBILE_ENABLED != true 门控、默认 skipped，且 :453 的聚合 job 与 :487 的产物下载都对 skipped 做了条件跳过 ⇒ 发布链路事实上不出 mobile 产物。
• README zh/en 与 docs/architecture.md:44 统一到这一句（zh/en 语义一致是既有 i18n 规则）。当前 zh「Mobile 装配中」/ EN "Mobile in assembly" 与 architecture「非 release candidate」强度不同，取更强的那个口径，因为它是可被发布配置证伪的那个。

P2-6 根 AGENTS.md 下沉 — 方案 ACCEPTED，实施 DEFERRED（带触发条件）

• 实测 AGENTS.md = 285 行，门禁预算 300（verify-doc-ssot.py:262），余量 15 行。
• 裁决：lane F 的逐行下沉方案（测试速查段 8 行 → docs/developer-quickstart.md、发布 tag SOP 3 行 → docs/governance/、治理细则 7 行 → governance，净回收 ~14-15 行）接受，但不在本轮实施：现在做是一发纯 doc churn PR，收益只有「余量从 15 变成 ~29」。
• 触发条件：下一次需要新增规则且 15 行余量不够时，在同一 PR 内下沉（规则新增与其腾出的空间同批评审）。
• 实施时必须同时过 lane F 列出的 5 项 doc-ssot 检查（行数预算、反引号路径存在性、禁止对 AGENTS 做带编号章节引用、4 个锚点句、仓外链接规则）。

[DeliciousBuding]

实施已发 PR #2305（ADR-030 的写集），其中一处对裁决原文的如实修正需要记录（上一条同内容评论里 /v1 被 shell 反引号吃掉，以此条为准）：

P3-8 原写「补齐真正违反声明的 3 个 /v1 operation」，但查过出处后发现无据可填——GET /v1/metrics、GET /v1/agent-instances、POST /v1/permissions/decide 在 docs/architecture/ 全文没有任何 P0~P4 归属，同族兄弟端点的 phase 也是 P0/P1/P2/P4 混杂、无法照抄。填一个没有出处的 phase 等于亲手制造下一条「文档与实况分岔」，所以本发只声明适用范围规则（x-agenthub-phase 只标注 /v1/** 设计面；166/284 缺 phase 不是覆盖率缺陷，实测缺失分布 /web 91·/client 64·/edge 5·/v1 3·/health·/api·/cloud 各 1），并把这 3 个例外就地登记在 api/README.md §阶段标记、注明需产品/架构 owner 给值。

其余实施情况：

• P2-4 已实施：4 处 x-agenthub-owner: Runner → Hub 且保持 status: planned（翻成 implemented 会被 verify-openapi-contract.py 拉进 router 比对而必红）；取值域闭合写进 api/conventions.md §OpenAPI Metadata；api/README.md 模块边界表把 Workspace 从 Edge 行移到 Hub 行。实测 verifier 输出仍是 153 / 156 / 3 / 0，与本 issue 记录的基线逐字相同。
• P3-9 已实施：README zh/en 统一到更强的一句（「装配中的 fixture/边界验证 lane，非 release candidate」）并给出可机械验证的锚点（release.yml:383 build-mobile 受 RELEASE_MOBILE_ENABLED 门控默认 skipped，:453/:487 对 skipped 有条件跳过）。
• P2-6 维持 accepted-but-deferred：触发条件 = 下次新增规则撞 300 行预算时同批下沉（实测 AGENTS.md = 285 行，余量 15）。
• 附带把 api/conventions.md 的行数预算问题就地解决：第一版写到 194 行被 verify-doc-ssot.py 的 DOC-MAX-LINES（190）判红 ⇒ 压缩到 189 行通过，没有为了塞进新内容去抬门禁预算。

⇒ 本 issue 仅余「3 个 /v1 端点的 phase 取值」需 owner 定值。

[DeliciousBuding]

终态：DECIDED（ADR-030）+ LANDED（#2305），关闭

四条口径全部裁决并落地，权威文本在 docs/decisions.md ADR-030：

1. owner 取值域闭合：x-agenthub-owner ∈ {Hub, Edge}，Runner 退役（edge-server/internal/runners/ 只有 registry，workspace 实现全在 hub-server）。4 个 /v1/workspaces/** 改 owner: Hub 且保持 status: planned（否则被拉进 router 比对而红）。将来若真需要 Edge 侧文件内容端点，届时该端点自己标 Edge，不预先在 Edge 建第二套实现。
2. x-agenthub-phase 适用范围：声明「只适用于 /v1/** 设计面」，而不是批量补 166 个标记；只补真正违反该声明的 3 个 /v1。
3. Mobile 单一口径：「装配中的 fixture/边界验证 lane，非 release candidate」，证据锚点 = release.yml 的 build-mobile 受 RELEASE_MOBILE_ENABLED 门控默认 skipped；README 双语与 docs/architecture.md 统一到这一句。
4. AGENTS 下沉：方案 accepted、实施 DEFERRED，触发条件 = 下次新增规则撞行数预算（285/300）时在同一 PR 内下沉，不做纯 doc churn PR。

落地时还修掉一处自伤的门禁空洞：改 README 的 parity 标记文案时，verify-doc-ssot.py 的 DOC-README-PARITY 因为「两边同时缺席也算通过」而被静默架空；同 PR 内把配对标记与该门禁的负向自测一起更新了。这条教训已进 STATE.md：改标记文案必须同步改门禁的配对标记与它的负向自测。

[DeliciousBuding]

已裁决并落地，证据见上一条主机复核评论。