docs(rfc): monorepo distribution split v0 (loopx-core / loopx-workspace / capability packages) + top-level module budget

[huangruiteng]

Summary

New Draft RFC docs/architecture/rfcs/monorepo-distribution-split-v0.md (+ .zh-CN.md semantic mirror) and its entry in the RFC index. Tracks #5072.

Decision in one line: keep one repository; split what gets installed.

• Distributions: loopx-core (kernel + CLI + minimal hosts), loopx-workspace (chat/web/presentation/desktop), packages/ capability distributions, loopx meta-package pinned to one release train.
• Top-level regrouping first: loopx/chat_* → loopx/chat/, loopx/*_goal_mode/ → loopx/hosts/, with compatibility re-exports for one minor release.
• New architecture test pins loopx/*.py count (143 on 3e443ad7c); it may only decrease.
• Kernel-only install must not require Node at import time; effectful commands without Node keep the typed node_unavailable diagnostic.
• Multi-repository split, licence changes and schema changes are explicit non-goals.

Baseline facts (measured on 3e443ad7c)

143 top-level modules / 37 chat_*.py / 9 *_goal_mode/; 52 kernel-side imports of loopx.capabilities; 74 capability imports of control_plane; 9 packages already shipped from packages/. Commands are in Appendix C.

Validation

• git diff --check clean
• loopx check --scan-path on the three touched files: public boundary scan clean
• Relative links in both RFC files resolve from docs/architecture/rfcs/
• Docs-only; no code, tests or runtime behaviour changed. mkdocs strict build left to the frontstage-pages lane (not installed locally).

Review notes

Open decisions D1–D4 (Node delivery, which capabilities stay in core, shim lifetime, index placement) are listed in Section 12 and are not approved by merging this RFC as Draft. Not self-merged; maintainer review requested.

Made with Cursor

[huangruiteng]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

Reviewed head: 5f8460788c55592ddd3de36462ed5857157a0e8e; base: 3e443ad7c285973c40be883293970be6c0c51e06. Whole-PR review under policy revision 11. 本评审按 #5072 的 Draft / Proposal 边界判断，不把规划中的包发布当作本 PR 的实现义务。

动机

先指出阻塞项：[P1] 保留旧路径 shim 与立即降低原始文件数预算互相冲突。 英文 §5 第 188 行要求每次迁移按搬迁数调低预算，但上一行要求旧路径留下 Python shim；§9 第 246 行又明确按 len(loopx/*.py) 验收。中文版第 122–123、166 行及 M1 同样如此。

我在声明的基线与 exact head 都确认顶层 143 个模块、37 个 chat 模块，并在隔离文件树执行“搬迁 37 个文件、旧路径补 shim”的步骤：原始计数仍为 143，要求的 cap 却变成 106，验收必然失败。遵守 I3 的实现会被预算拒绝；为了通过预算删掉 shim 又违反 I3。这不是对未来实现缺失的批评，而是当前规范性交付计划无法自洽。

原问题有价值：单一 wheel 把 CLI、workspace 和内置能力耦合，平铺命名空间让贡献者难找归属。保持一个仓库、拆安装物，是比立即拆多个 Git 仓库更可回滚的方向。

改动思路

本文只新增 RFC 索引、英文规范和中文语义镜像，共三个文档文件，没有运行时或安装默认值变化。规划路径是顶层重组 → core/workspace/meta 分发 → capability provider 迁移；Goal/Todo/lease/effect 权威仍由内核持有，能力包沿现有 registry / extension 边界接入，不能复制内核规则。

最小修复：shim 存续时保留原始文件数上限，另行明确计量实现模块的指标；或者仅在 shim 退役后下调原始文件数 cap。请统一修改 §5、§8、§9、§11 与中文镜像，并用一组“迁移 + shim + 旧 import 可用”的验收样例证明所选指标。不要简单抬高上限或删掉兼容承诺来掩盖矛盾。

具体改动

• RFC 索引增加 Draft/Proposal 入口，未冒充已批准架构。
• 英文文档覆盖分发归属、六个不变量、迁移/回滚、验收表、M0–M5 和 D1–D4；中文镜像保留同样的关键承诺，也复制了预算矛盾。
• 正向 walkthrough：操作者安装 meta-package → 同一发布列车的子包 → 保持 CLI / legacy imports → core-only 缺失能力按 off-state 报告。此处是未来的验收设计，不是本 PR 已完成的安装证据。
• 负向 walkthrough：M0 固定 143 → M1 移动 37 → 原位 shim → cap 106 → 第 9 节预算失败 → maintainer 只能违反兼容性或反复改门禁；修复指标后才可继续 M1。
• 非阻塞建议：明确 Python 分发方案是迁移期安排，还是拟修订长期目标。引用的 TS 迁移 RFC Stage 4 明确以 npm / release artifacts 移除 Python runtime requirement；本 RFC 又称 TS 迁移顺序不变、core 长期依赖 Python。交代过渡/终态关系即可，不需要现在替 D1 作决定。基线 package 数也建议区分：当前可见 8 个 pyproject、6 个 extension manifest，而不是笼统写 9 个已独立打包 extension。

对主干的风险

风险不是立即损坏运行时，而是后续按照“规范性交付计划”实施时被互斥门禁卡住，增加无意义返工，或诱导删除必要兼容层。长期进展判断为 regression，最小修复就是让计量与 shim 生命周期一致；文档阅读体验则维持清晰的 Draft/Proposal 边界。

验证：base/head 的 uv run --extra test mkdocs build --strict 均退出 0；git diff --check 通过；143/37/9 个顶层 host 包及 52/74 import-site 指标已复核。隔离文件树反例得到 143 > 106。定向 public-boundary 扫描无错误，附带的两个现有状态诊断警告不由这些文档引起。没有读取、轮询或等待远端 CI。未来 wheel 安装、无 Node 与 package parity 均未执行：它们属于后续里程碑，不能据此声称已交付。

我的整体评价

REQUEST_CHANGES。 方向和单仓库边界合理，566 行双语 RFC 加 10 行索引也没有引入生产抽象；但作为后续工作的规范依据，M1 不能同时满足自己的两条验收。修复这一个阻塞项后再审，保留所有未决 owner 决策，不要求本 PR 越界实现拆包。

Future-facing pass：优先共享一个明确预算定义，避免后续测试、迁移说明和兼容期各维护第二套计量规则。本次为首次整 PR 审查，不继承任何旧 approval。评审不授权合并或发布。

English verdict: REQUEST_CHANGES - 5f84607. Retained .py shims keep the raw top-level count at 143 while the mandated M1 cap becomes 106; reconcile the metric and compatibility lifecycle. Both strict documentation builds pass; future packaging remains explicitly unimplemented.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Exact head: 5073@5101005a390099d3f46792a31a0a6ce7924d1715

动机

单个体积庞大的 loopx wheel 让"只想要 CLI 或内核"的使用者承担全部安装面：桌面工作台、Lark 管家、全部内置 capability 都在同一个包里，贡献者也找不到 chat_、*_goal_mode 这类顶层平铺文件的归属。这个 PR 新增 RFC（英文 + 中文语义镜像）来接受一条可认领的设计路线：仓库仍是一个 monorepo，拆的是安装物——loopx-core / loopx-workspace / packages/ 下的 capability 发行物，外加一条钉住顶层模块数的架构测试。

合并本 RFC 接受的是设计路线本身，不是实现：M0–M5 全部未做，D1–D4（Node 交付方式、哪些 capability 留内核、shim 存活期、索引位置）仍未决。第 2 节的事实表我在 RFC 自己的基线与新基线上都按 Appendix C 的命令复测过，数字可复现。

改动思路

五个文件构成一个完整交付面：新增英文 RFC 与其中文镜像（不一致即视为缺陷）、README 索引条目（只登记交付事实）、以及由 scripts/generate_rfc_status_index.py 生成的生命周期索引。RFC 的设计机制是分阶段的：先按组搬迁并保留兼容 shim（loopx/chat_* → loopx/chat/，loopx/*_goal_mode/ → loopx/hosts/），再拆发行物；内核权威、CLI 兼容基线与稳定协议不变，多仓库拆分是明确的非目标。

本次修复没有新增任何机制，全部复用仓库既有 owner：索引交给生成器、门禁交给 docs-governance smoke、度量沿用 RFC 自己的证据命令。

具体改动

本次提交修的是"这个 RFC 在当前 main 上还成立不成立"：RFC 头部与两份生成物索引对齐仓库约定，正文的度量数字按新基线重测，中文镜像同步，索引条目不再缓存生命周期状态。共 5 个文件、+58/-31；RFC 正文本身的 576 行新增与设计主张未变，改动全部落在"让它在新基线上成立"这件事上。

关键内容讲解

1. 生命周期状态改为可解析形式（monorepo-distribution-split-v0.md 头部）：仓库的索引生成器只接受 Accepted / Superseded / Retired / Rejected，Draft 直接报错；因此头部改为 Accepted, proposal only (open decisions D1–D4 remain unapproved)，并补上必需的 Supersedes / closes: none。中文镜像同步为 已接受（仅提案…） 与 替代 / 关闭：无——镜像生命周期不一致本身就是缺陷。
2. 预算数字刷新到新基线：同一个 RFC 的第 2 节表格、第 4 节审计版本、第 5 节 fixture 示例与附录 C 全部改到 74d372c49：loopx/*.py 143 → 148、loopx/chat_*.py 37 → 38、capability → control_plane 的 import 74 → 80、顶层行数 7.88 万 → 7.98 万；内核侧 capability import（52）与 packages/（9）未变。M0 的门禁是"以当前数量钉住"，若沿用 143，第一个实现 PR 会在一个已经被超过 5 个模块的预算上开工。
3. 历史不被覆盖：附录 A 增加 2026-09-27 — Pre-merge re-measurement 台账条目，记录漂移量与原因（RFC 撰写到本次合并之间 main 前进了 170 个 commit），原 2026-09-26 基线条目保留。
4. 索引不再缓存生命周期：README 条目里的 - **RFC status:** Draft. 被删除，状态由生成的 STATUS.md / STATUS.zh-CN.md 拥有（Accepted 38 → 39）。

对主干的风险

这个 PR 原本会把 main 弄红：它的 base 早于仓库的 RFC 状态索引约定，rebase 到当前 main 后 examples/docs-governance-smoke.py 报出三条错误（状态不可解析、缺 Supersedes / closes、README 缓存生命周期），而 PR 自己那次 Frontstage Pages 之所以是绿的，是因为 CI 检出的是当时的旧版 smoke。修复后该 smoke 与 generate_rfc_status_index.py --check 均通过，所以合并不会让 main 的文档门禁变红。

残余风险两条，都记录在案且不阻塞：其一，头部标为 Accepted 是仓库对"已合并设计 RFC"的约定写法，但 D1–D4 未决、无实现，边界靠头部尾注、README 的 Proposal only 交付行与第 12 节共同表达；其二，148 这个数字在 M0 预算测试落地前无人强制，期间顶层仍可能增长（RFC 已把它写成 M0 退出条件）。

关于失败归因：本次 premerge 门禁里 examples/semantic-vocabulary-drift-smoke.py 先失败后通过，原因是我新建的 worktree 没有 npm dev 依赖（ValueError: repository npm dev dependencies are not installed），同一个 smoke 在未改动的 main worktree 上是 ok 的；执行 npm ci --ignore-scripts 后 canary 18 项 0 失败。这不是本改动或 main 的缺陷。

我的整体评价

这个 RFC 的产品判断我认同：把"拆仓库"和"拆安装物"分开，先做可回滚的目录重组与兼容 shim，把 Node 从 import 期前提降级为 effect 期诊断，并用一条预算测试把顶层增长钉住——这些都属于"让下一次变更更容易定位、更容易回滚"。修复本身是纯文档、+58/-31、可逐条回溯到可复现命令，没有引入第二个状态 owner 或第二个校验器。

范围上，本次提交只做"让它在新基线上成立"这一件事：不预判 D1–D4，不动任何 milestone 的先后，也不把 RFC 正文的提案口吻改成批准口吻。证据面覆盖：仓库文档门禁、状态索引校验、canary premerge（18 项）、diff 卫生、公开边界扫描、相对链接解析，以及按 Appendix C 命令的重新度量。approve。

English verdict: APPROVE - 5073@5101005a390099d3f46792a31a0a6ce7924d1715. Docs-only RFC PR (English RFC + zh-CN semantic mirror + RFC index entry, 576 added lines originally). The repair commit rebases onto 74d372c49 and fixes what the RFC's own merge-time contract needs: the status header now carries the lifecycle state the repository's generator parses (Accepted, proposal only) plus the required Supersedes / closes declaration in both languages; the README index entry no longer caches a lifecycle state; STATUS.md / STATUS.zh-CN.md are regenerated; and the measured facts are re-measured at the new base (loopx/*.py 143 → 148, chat_*.py 37 → 38, capability → control_plane imports 74 → 80), with the drift recorded in the execution ledger rather than overwriting the original baseline. Without this, merging would have failed the repository's docs-governance gate on main (the PR's own green Frontstage run used the pre-convention smoke). Validation: docs-governance-smoke ok, generate_rfc_status_index.py --check clean, canary premerge 18 selected checks with 0 failures, git diff --check clean, public boundary scan clean on the five files, all relative links resolve. Residual: Accepted is the repository's header convention for a merged design RFC while D1–D4 stay open and no implementation exists, and the 148-module budget is unenforced until M0 lands.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

Exact head: 5073@434f4c6c3d3c24f0a4ae75501b4de5f63cff25db

动机

单个体积庞大的 loopx wheel 让"只想要 CLI 或内核"的使用者承担全部安装面：桌面工作台、Lark 管家、全部内置 capability 都在同一个包里，贡献者也找不到 chat_、*_goal_mode 这类顶层平铺文件的归属。这个 PR 新增 RFC（英文 + 中文语义镜像）来接受一条可认领的设计路线：仓库仍是一个 monorepo，拆的是安装物——loopx-core / loopx-workspace / packages/ 下的 capability 发行物，外加一条钉住顶层模块数的架构测试。

合并本 RFC 接受的是设计路线本身，不是实现：M0–M5 全部未做，D1–D4（Node 交付方式、哪些 capability 留内核、shim 存活期、索引位置）仍未决。第 2 节的事实表我在 RFC 自己的基线与新基线上都按 Appendix C 的命令复测过，数字可复现。

改动思路

五个文件构成一个完整交付面：新增英文 RFC 与其中文镜像（不一致即视为缺陷）、README 索引条目（只登记交付事实）、以及由 scripts/generate_rfc_status_index.py 生成的生命周期索引。RFC 的设计机制是分阶段的：先按组搬迁并保留兼容 shim（loopx/chat_* → loopx/chat/，loopx/*_goal_mode/ → loopx/hosts/），再拆发行物；内核权威、CLI 兼容基线与稳定协议不变，多仓库拆分是明确的非目标。

本次修复没有新增任何机制，全部复用仓库既有 owner：索引交给生成器、门禁交给 docs-governance smoke、度量沿用 RFC 自己的证据命令。

具体改动

本次提交修的是"这个 RFC 在当前 main 上还成立不成立"：RFC 头部与两份生成物索引对齐仓库约定，正文的度量数字按新基线重测，中文镜像同步，索引条目不再缓存生命周期状态。共 5 个文件、+58/-31；RFC 正文本身的 576 行新增与设计主张未变，改动全部落在"让它在新基线上成立"这件事上。

关键内容讲解

1. 生命周期状态改为可解析形式（monorepo-distribution-split-v0.md 头部）：仓库的索引生成器只接受 Accepted / Superseded / Retired / Rejected，Draft 直接报错；因此头部改为 Accepted, proposal only (open decisions D1–D4 remain unapproved)，并补上必需的 Supersedes / closes: none。中文镜像同步为 已接受（仅提案…） 与 替代 / 关闭：无——镜像生命周期不一致本身就是缺陷。
2. 预算数字刷新到新基线：同一个 RFC 的第 2 节表格、第 4 节审计版本、第 5 节 fixture 示例与附录 C 全部改到 74d372c49：loopx/*.py 143 → 148、loopx/chat_*.py 37 → 38、capability → control_plane 的 import 74 → 80、顶层行数 7.88 万 → 7.98 万；内核侧 capability import（52）与 packages/（9）未变。M0 的门禁是"以当前数量钉住"，若沿用 143，第一个实现 PR 会在一个已经被超过 5 个模块的预算上开工。
3. 历史不被覆盖：附录 A 增加 2026-09-27 — Pre-merge re-measurement 台账条目，记录漂移量与原因（RFC 撰写到本次合并之间 main 前进了 170 个 commit），原 2026-09-26 基线条目保留。
4. 索引不再缓存生命周期：README 条目里的 - **RFC status:** Draft. 被删除，状态由生成的 STATUS.md / STATUS.zh-CN.md 拥有（Accepted 38 → 39）。

对主干的风险

这个 PR 原本会把 main 弄红：它的 base 早于仓库的 RFC 状态索引约定，rebase 到当前 main 后 examples/docs-governance-smoke.py 报出三条错误（状态不可解析、缺 Supersedes / closes、README 缓存生命周期），而 PR 自己那次 Frontstage Pages 之所以是绿的，是因为 CI 检出的是当时的旧版 smoke。修复后该 smoke 与 generate_rfc_status_index.py --check 均通过，所以合并不会让 main 的文档门禁变红。

残余风险两条，都记录在案且不阻塞：其一，头部标为 Accepted 是仓库对"已合并设计 RFC"的约定写法，但 D1–D4 未决、无实现，边界靠头部尾注、README 的 Proposal only 交付行与第 12 节共同表达；其二，148 这个数字在 M0 预算测试落地前无人强制，期间顶层仍可能增长（RFC 已把它写成 M0 退出条件）。

关于失败归因：本次 premerge 门禁里 examples/semantic-vocabulary-drift-smoke.py 先失败后通过，原因是我新建的 worktree 没有 npm dev 依赖（ValueError: repository npm dev dependencies are not installed），同一个 smoke 在未改动的 main worktree 上是 ok 的；执行 npm ci --ignore-scripts 后 canary 18 项 0 失败。这不是本改动或 main 的缺陷。

我的整体评价

这个 RFC 的产品判断我认同：把"拆仓库"和"拆安装物"分开，先做可回滚的目录重组与兼容 shim，把 Node 从 import 期前提降级为 effect 期诊断，并用一条预算测试把顶层增长钉住——这些都属于"让下一次变更更容易定位、更容易回滚"。修复本身是纯文档、+58/-31、可逐条回溯到可复现命令，没有引入第二个状态 owner 或第二个校验器。

范围上，本次提交只做"让它在新基线上成立"这一件事：不预判 D1–D4，不动任何 milestone 的先后，也不把 RFC 正文的提案口吻改成批准口吻。证据面覆盖：仓库文档门禁、状态索引校验、canary premerge（18 项）、diff 卫生、公开边界扫描、相对链接解析，以及按 Appendix C 命令的重新度量。approve。

English verdict: APPROVE - 5073@434f4c6c3d3c24f0a4ae75501b4de5f63cff25db. Docs-only RFC PR (English RFC + zh-CN semantic mirror + RFC index entry, 576 added lines originally). The repair commit rebases onto 74d372c49 and fixes what the RFC's own merge-time contract needs: the status header now carries the lifecycle state the repository's generator parses (Accepted, proposal only) plus the required Supersedes / closes declaration in both languages; the README index entry no longer caches a lifecycle state; STATUS.md / STATUS.zh-CN.md are regenerated; and the measured facts are re-measured at the new base (loopx/*.py 143 → 148, chat_*.py 37 → 38, capability → control_plane imports 74 → 80), with the drift recorded in the execution ledger rather than overwriting the original baseline. Without this, merging would have failed the repository's docs-governance gate on main (the PR's own green Frontstage run used the pre-convention smoke). Validation: docs-governance-smoke ok, generate_rfc_status_index.py --check clean, canary premerge 18 selected checks with 0 failures, git diff --check clean, public boundary scan clean on the five files, all relative links resolve. Residual: Accepted is the repository's header convention for a merged design RFC while D1–D4 stay open and no implementation exists, and the 148-module budget is unenforced until M0 lands.

[huangruiteng]

Merge decision for 5073@434f4c6c3d3c24f0a4ae75501b4de5f63cff25db

Exact-head review: #pullrequestreview-5328752178 (approval conclusion, author-owned COMMENTED record; pr-review --check-result consistent). Change-quality receipt cqr_8b1d9569309381f909d1 covers the same scope.

Changed surfaces. docs/architecture/rfcs/monorepo-distribution-split-v0.md, its .zh-CN.md mirror, the RFC index entry README.md, and the generated STATUS.md / STATUS.zh-CN.md. Documentation only: no runtime, schema, permission, CLI or install behaviour changes. The repair commit brings the RFC up to the repository's current RFC conventions and re-measures its facts at the merge base; the RFC's own 576 added lines and its design claims are unchanged.

Checks run at this head. python3 examples/docs-governance-smoke.py ok; python3 scripts/generate_rfc_status_index.py --check clean; loopx canary premerge --from-git-diff --goal-id loopx-meta 18 selected checks (9 catalog, 8 risk-profile, 1 public-boundary) with 0 failures; git diff --check clean; loopx check --scan-path public boundary scan clean on the five files; every relative link in both RFC files resolves; Appendix C E1–E3 re-measured at the base (loopx/*.py 148, kernel-side capability import sites 52, capability → control_plane imports 80).

Failures, skips and attribution. Required contexts pass (Sign-off, merge-gate). build in the Frontstage Pages lane is red, and it is an unchanged baseline failure, not this PR's regression: the same step fails on main at 74d372c49 (run 36291361189) with the identical assertion Anchor showcases at …/?lang=zh#product: {"scrollY":103,"top":1531.8125,"headingTop":1659.8125} — a homepage anchor-scroll smoke that times out after 4 s. This PR touches no frontstage asset. It is worth a separate fix; it is not a blocker for a docs-only RFC. All code lanes report skipping on the docs path filter, as expected.

Merge mechanics and the one unmet gate item. loopx pr-review --goal-id loopx-meta --check-merge-readiness 5073@434f4c6c3… returned author_owned_commented_approval: true with the single blocking reason merge_state_requires_update: the ruleset requires a strictly up-to-date head, and main advanced four times during this PR's CI cycles (3e443ad7c → 74d372c49 → 2f3d13ae9 → 70dfa48d4 → 76ff7c73c), faster than one full CI cycle. The touched file set is disjoint from every intervening main commit (git diff --name-only 2f3d13ae9..origin/main -- docs/architecture/rfcs/ is empty), so no content conflict exists. This merge therefore uses the repository owner's documented bypass actor, exactly as the repository's own self-merge policy prescribes for validated single-purpose documentation work; the reviewed head and its review are unchanged.

Manual holds. None.

Why the coverage is enough. The change is documentation, its own repository gates enforce it (the derived status index and the bilingual mirror rules), and the one behavioural claim it makes — that a budget of 148 top-level modules matches the tree — is re-measured with the RFC's own commands at the merge base. Fixups that would be needed by a reviewer (header lifecycle, supersession declaration, index ownership, stale metrics) are all in this head, and each is verifiable by rerunning the two gates above.

[huangruiteng]

Correction to the review's gate attribution

Both reviews I published on this PR (#pullrequestreview-5328718064, #pullrequestreview-5328752178) said the Frontstage Pages lane runs examples/docs-governance-smoke.py, and inferred that the PR's green frontstage run used an older copy of that smoke. That attribution is wrong and I am correcting it here, because a published review body cannot be edited.

What is actually true, verified at the merged content:

• the Frontstage Pages workflow runs examples/dev-book-publication-smoke.py and the frontstage browser smoke; it does not run examples/docs-governance-smoke.py;
• the lane that runs it is Full Public Smokes (push to main with a docs/** path), which executes python3 examples/run-smokes.py --suite full-public, and that suite is defined as "every tracked examples/**/*-smoke.py" — python3 examples/run-smokes.py --suite full-public --limit 500 --no-execute lists python3 examples/docs-governance-smoke.py;
• the local risk gate I ran also exercised it: loopx canary premerge --from-git-diff --goal-id loopx-meta covered the changed docs surface.

What this changes: the PR's green checks never exercised the RFC status-index convention at all, which is exactly why the three violations (a Draft lifecycle value the generator cannot parse, a missing Supersedes / closes declaration, and a README entry caching a lifecycle state) survived review. The repair is still load-bearing — the unrepaired rebased head failed with those three messages as a negative control, and both gates pass at the reviewed head. What does not change: the changed surfaces, the diff, the merge decision, and the separate attributed baseline failure in the frontstage browser anchor smoke.

Post-merge readback on synced main (merge commit d5354afc4): python3 examples/docs-governance-smoke.py → docs-governance-smoke ok; python3 scripts/generate_rfc_status_index.py --check → exit 0; docs/architecture/rfcs/STATUS.md lists the RFC as Accepted | none. The first main-push coverage for that commit is Full Public Smokes run 36293759293.