Skip to content

[finding] 两份已落在 main 上的 ADR 仍写着 Status: Proposed — awaiting the maintainer's hand-merge, which is itself the acceptance act(0132 / 0133),而同约定的 0130 / 0131 落地后都改成了 Accepted #18532

Description

@os-try-charles

两份已经落在 main 上的 ADR 仍然写着「Status: Proposed —— 等待维护者手工合并,而那次合并本身就是接受行为」,并且紧跟一句「⛔ Nothing below is settled until this record merges」。它们已经合并了。 ⇒ 记录按它自己的规则读是已接受,而它的 Status 字段说未接受

⚠️ 这不是措辞洁癖:每一处引用这两份 ADR 当作既定法的地方(本轮卡 #17379 的普查就整篇建立在 ADR-0132 之上),读者一旦回去查源文件,看到的是 Proposed

读数(origin/main 工作树 1e496f9796126b0398c026c96fb8d240f1982e91)

① 两个实例,各自的落地是查得到的

ADR Status 字段当刻原文 它实际落地于
docs/adr/0132-multi-organization-runtime-is-open-core.md 「Proposed (2026-09-06) — awaiting the maintainer's hand-merge, which is itself the acceptance act for a governed surface (Prime Directive #14). ⛔ Nothing below is settled until this record merges.」 c677cda816 · 2026-09-07T05:30:13Z · PR #16215 · committer Jack Zhuang <…hotlong@users.noreply.github.com>
docs/adr/0133-org-management-open-basics.md 「Proposed (2026-09-06) — awaiting the maintainer's hand-merge, which is the acceptance act for a governed surface (Prime Directive #14).」 13c08356ab · 2026-09-07T07:19:25Z · PR #16267

ADR-0132 那一行尤其硬:它的落地提交的 committer 就是维护者本人 ⇒ 它自己所说的「acceptance act」确实发生过,只是没有人回去改那一行。

② 阳性对照 —— 同一套约定,改过状态的长这样

0130-release-artifact-as-co-ownership-boundary.md
  **Status**: Accepted (2026-09-01) — accepted by the merge that landed it on `main` (#14151)
0131-total-organization-ownership-no-null-organization-id.md
  **Status**: Accepted (2026-09-04) — accepted by the merge that landed it on `main` (#14976)

⇒ 这两份同样带着 acceptance act 那句话(各出现 2 次 / 1 次),而它们的 Status 在落地后被改成了 Accepted 并回指落地 PR。所以这不是"本仓没有这个约定",是这两份漏了那一步。

③ 总体与它的边界,⛔ 不夸大

docs/adr/*.md 总数                                  139        ← 发火对照
  Status 读作 Accepted                               92
  Status 读作 Proposed                               20
  其中带 `acceptance act` 那句话的                      7
    …其中 Status 仍是 Proposed 的                      3  →  0132 / 0133 / 0134

⚠️ 0134 要排除,并且理由要写出来,⛔ 不能凑数:0134-env-side-scim-provisioning.md 的 Proposed 是自解释且正确的 —— 它自陈是 cloud ADR-0071 的镜像,而那份在 cloud 侧也是 Proposed「founder to accept」。⇒ 它的 Proposed 说的是被镜像那一份还没被接受,不是这一份没落地。

真实实例是 2 个,⛔ 不是 20 个,也 ⛔ 不是 7 个。

⛔ 我没量的部分,不许当读数用

为什么值得一张卡

docs/adr/**治理面。一份治理记录的 Status 字段是它唯一的机器可读的效力声明;而这两份的 Status 与它们自己写下的接受规则直接冲突。⇒ 任何按 Status 判断"这条能不能引"的人或工具,今天会得到错误答案,而正文却在要求读者「Nothing below is settled until this record merges」。

⚠️ 失效方向是沉默的:没有任何门禁会因此变红(实测:两份都在 main 上,CI 全绿)。

验收(⛔ 不规定实现)

  1. 先裁 ADR-0133 那条(见上「没量的部分」第 2 条):是"文字过时"还是"未被接受却已被引用"。⛔ 两种结论的修法相反 —— 前者改一行,后者要补一次接受行为。
  2. ADR-0132 若按文字过时处理:照 0130/0131 的既有拼法改(Accepted (日期) — accepted by the merge that landed it on \main` (feat(organizations): bring the multi-organization runtime back to open core — the org-scoping registrar ships open, the licence gate stays in cloud (ADR-0132) #16215)`),⛔ 不要发明第三种拼法。
  3. 不要顺手把另外 17 份 Proposed 一起改 —— 本卡没量它们,批量改会把一个没量过的总体当成量过的。
  4. ⚠️ docs/adr/** 是治理面 ⇒ 落地走维护者路径;本席对该面的 auto-merge 恒 422。

查重

⛔ REST /search/issues 在本通道不服务(卡 #16233 已记),所以按完整枚举查:拉全部 538 个 open 非 PR issue(537 带正文)本地 grep。

'ADR-0132'          → 1   (#17379,本轮的普查卡,引用而非同题)
'Status: Proposed'  → 2   (#16140 谈 ADR-0026 的 manifest 例子,顺带提到它是 Proposed;#18477 是一张"去写一份 Proposed 形态新 ADR"的卡)
'acceptance act'    → 0
'hand-merge'        → 1   (#17193,已读,非同题)
'ADR status'        → 1   (#16140,同上)
'organizations'     → 17  ← 发火对照

⇒ 两处疑似都逐条读过,均非同题。发火对照 17 命中 ⇒ 那些零是读数。

来源

#17379(@objectstack/organizations 措辞普查)的 dev 在 out_of_scope_findings 里交回 ADR-0132 那一条(class b);⭐ 它没有自己立卡(dev 席不 POST issue),交回给了派发席。本席据此重取了全部读数,并把它的单实例扩成有对照、有排除理由的总体:它只报了 0132,实测同形的是 0132 与 0133,而 0134 看着同形但必须排除

⛔ 未定级、未指派、未定车道 —— 那是分诊的活。

domain:devx 执行席 · 座位贴 #6023 · session session_017ef78bLdybu3AffehKkhfk · 读数取自 origin/main 的一次性 worktree


Generated by Claude Code

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions