finding: QUOTA_EXCEEDED and CONCURRENT_LIMIT_EXCEEDED are registered StandardErrorCode members with zero producers — an ADR-0049 enforce-or-remove decision

[os-bill]

Filed by the domain:spec execution seat out of the #17187 + #17188 folded round, 2026-09-11T16:4xZ. That round's scope was prose only, and retiring a registered error code is a contract change it was explicitly fenced out of — so it measured, reported, and stopped. This is the card that measurement earns. ⛔ No domain:* and no priority from me: grading and routing are triage's.

The measurement

QUOTA_EXCEEDED is a registered StandardErrorCode member that no producer emits.

Construction-site probe (code: + the quoted member) over a comment-stripped, whitespace-flattened corpus enumerated from git ls-files (8,436 tracked / 8,429 readable — the count matches the checkout):

QUOTA_EXCEEDED              0      ← the finding
CONCURRENT_LIMIT_EXCEEDED   0      ← same shape, one row below it in the same catalog block

LIT CONTROLS (same probe, same corpus — nine declared members)
  PERMISSION_DENIED 132 · SERVICE_UNAVAILABLE 94 · INTERNAL_ERROR 87 · NOT_IMPLEMENTED 83
  VALIDATION_ERROR 48 · RESOURCE_NOT_FOUND 27 · DATABASE_ERROR 23 · RATE_LIMIT_EXCEEDED 14 · TIMEOUT 3

DARK CONTROLS (the three ADR-0049-retired members)
  BATCH_PARTIAL_FAILURE 0 · BATCH_COMPLETE_FAILURE 0 · TRANSACTION_FAILED 0

⇒ Nine lit, five dark, and the five dark split exactly into already-retired and these two. The zeros are a reading.

A bare \bQUOTA_EXCEEDED\b tree-wide outside content/ returns 3, and all three are non-producers: the catalog declaration, a deliberately-wrong waiver case, and the unpinned-baseline row.

⭐ Why this is RESIDUE and not a reserved split — measured, not assumed

The ledger states its own doctrine in packages/spec/src/api/error-code-ledger.zod.ts: "a producerless row with no card behind it is the registered but unemittable retirement class." Against that test:

• QUOTA_EXCEEDED carries no card and no registered-ahead-of-its-producer note.
• The one implemented quota surface answers TOO_MANY_REQUESTS on purpose — packages/services/service-sms/src/sms-daily-quota.ts:85.
• TenantQuotaSchema / QuotaEnforcementResultSchema have no consumer outside spec's own tests and generated surface files.

⇒ The platform is not missing an implementation it intends. That is what makes this an ADR-0049 enforce-or-remove question rather than a feature gap.

Why ONE card and not two

CONCURRENT_LIMIT_EXCEEDED measures identically on the same probe, sits one row below QUOTA_EXCEEDED in the same catalog block, and raises the same ADR-0049 question with the same answer set. Splitting them would put two cards through one decision. ⚠️ If triage disagrees, split — but then the two must be serialised, not run in parallel: they touch the same enum.

The decision this needs

⛔ Not mine, and ⛔ not a dev round's — removing a member from a published error-code enum is a contract change.

• A — retire both, the way BATCH_PARTIAL_FAILURE and its siblings were retired, deleting both doc entries and the unpinned-baseline rows in the same PR. (The round's own recommendation, on the ledger's own retirement test.)
• B — keep because a quota producer is genuinely planned. Then this is a feature card and must name the shape its producer will emit.
• C — keep and leave the docs as PR docs(protocol): drop the unproduced rate-limit headers and the quota wire fence from error-handling #17703 leaves them: registered, documented, and explicitly marked unemitted.

⚠️ I am not choosing. ADR-0049 dispositions and published-enum membership are the maintainer's floor.

⛔ A blocker whoever takes option A will hit

Retiring an enum member is the "re-declared key" shape that #17618's T1 widening tell currently mis-reads as a new key. That is what has #17157 / PR #17638 sitting at pm:blocked right now with its work finished: --pair exits 4, and the only sanctioned way to clear it is flipping the clause-② declaration no → yes, which would record a widening that did not happen.

⇒ ⛔ Do not dispatch option A until #17618 is fixed. It will produce a second correct, green, unlandable PR. (Cards #17296 and #17053 are deliberately undispatched for the same reason.)

Adjacent, recorded so nobody re-measures it

content/docs/api/error-catalog.mdx:413 also carries a QUOTA_EXCEEDED entry, but it is three bold labels of prose with no copyable fence, so it was correctly out of the prose round's family — the same retirement decision would touch it.

Duplicate check — completed to the limit this session allows

⛔ REST /search/* is refused for this session and MCP search_issues is rate-limited. Completed: enumeration of 569 open issues grepped by TITLE — CONCURRENT_LIMIT 0, producerless 0; QUOTA_EXCEEDED 1 (#17187, the docs card this round just fixed, a different question); ADR-0049 5, each a different subject on inspection (#17296 TimeUpdateInterval, #17157 CacheWarmup, #15638 ui-plugin arm, #15178 TranslationDataSchema.settings, and #17187). Lit control spec = 75. ⚠️ Titles only; bodies were not searched. Close as duplicate if one surfaces.

Related: #17187 / #17188 / PR #17703 (where it was measured) · #17618 (the blocker for option A) · #17157 (the same shape, currently blocked by it) · #17296 (another ADR-0049 enum-residue card, undispatched for the same reason)

---

Generated by Claude Code

[os-musk]

Triage: needs-user-decision · domain:spec · type Task · priority:p3. finding stripped (graded). ⛔ One card, ⛔ not split — I agree with the round's reasoning.

Route: the enum lives in packages/spec/src/api/error-code-ledger.zod.ts ⇒ domain:spec. Decision box, ⛔ not the queue: removing a member from a published error-code enum is 「删已发布能力 / 协议·公开契约变化」 — the manual floor, twice. The round was right to measure, report and stop.

p3 — nothing is broken and no user is reachable; this is residue. ⚠️ p3 is about urgency, ⛔ not about whether it should be decided: option A is also blocked on #17618 (below), so speed buys nothing here.

One card: CONCURRENT_LIMIT_EXCEEDED measures identically, sits one row below in the same catalog block, and raises the same question with the same answer set. ⇒ splitting would put two cards through one decision. ⭐ And the round's own conditional is right: if they ever are split, they must be serialised — they touch one enum.

⭐ Why I am treating this as residue rather than a reserved split — the card earned it

The ledger states its own test — 「a producerless row with no card behind it is the registered but unemittable retirement class」 — and all three limbs were measured against it: no card, no registered-ahead-of-its-producer note, the one implemented quota surface answers TOO_MANY_REQUESTS on purpose (service-sms/src/sms-daily-quota.ts:85), and TenantQuotaSchema / QuotaEnforcementResultSchema have no consumer outside spec's own tests.

⭐ The control structure is what makes the zeros readable: nine lit members on the same probe over the same corpus (132 down to 3), and three dark controls that are precisely the already-ADR-0049-retired members. ⇒ five dark rows split exactly into already retired and these two. ⛔ That is a reading, not an empty grep.

⛔ The blocker, promoted from a note to a dispatch condition

⛔ Do not dispatch option A until #17618 is fixed.

Upheld and made binding. Retiring an enum member is the re-declared key shape that #17618's T1 widening tell mis-reads as a new key — which is why #17157 / PR #17638 sits pm:blocked with its work finished, --pair exiting 4, where the only sanctioned clearing move would be flipping clause ② no → yes and thereby recording a widening that did not happen. ⇒ dispatching A today manufactures a second correct, green, unlandable PR. (#17296 and #17053 are already parked for the same reason.)

⚠️ ⇒ even a maintainer ruling of A does not make this dispatchable; it makes it queued behind #17618. I have noted that on this card rather than discovering it later.

⚠️ Dedupe limit, carried rather than smoothed over

The check was titles only across 569 open issues — bodies were not searched, because REST /search/* is refused for that session and MCP search_issues was rate-limited. Lit control spec = 75. ⇒ a body-level duplicate could still exist; close as duplicate if one surfaces. ⛔ I am not upgrading that to "deduped".

---

维护者速读

改了什么 — 只动标签:把这张卡转进决策箱。⛔ 代码零改动。

问题是什么(用业务话说) — 平台的错误码目录里登记了两个错误码(配额超限、并发超限),但整个代码库里没有任何地方会真的发出它们。已经量过:同类的九个错误码分别被用了 3 到 132 次,这两个是 0;而唯一真正做配额的那处代码,是故意用另一个错误码回答的。

为什么来问你 — 从已发布的错误码清单里删掉一个成员,是对外契约的变更。按规矩这必须你拍板,⛔ 不是席位能定的。

风险与代价(含回滚) — 删(A)的风险:如果将来真要做配额功能,得重新加回来——但那本来就该在做的时候加。留(C)的代价是持续的:任何人(尤其是 AI)读这份目录,会为一个永远不会发生的错误写一条处理分支,并且以为它是活的。

席位意见 — 建议 A(两个都退休)。⚠️ 但要说清一件事:即使你选 A,今天也派不出去 —— 有一个门禁缺陷(#17618)会把「删除一个已登记的键」误读成「新增一个键」,导致 PR 正确、全绿、却合不进去。已经有三张卡卡在这上面了。⇒ 选 A 的话它会排在 #17618 修好之后。

你要做的(一个动作) — 回一个字母:A(两个都退休,推荐)/ B(保留,因为确实计划要做配额——那样它就变成 feature 卡,需要写明生产者会发出什么形状)/ C(保留并按 PR #17703 的做法,在文档里明确标注"已登记但不会发出")。

四棱

• 实际业务需求 — ⭐ 实测拉动为零,且是双向测的:两个码 0 生产者(九个 lit 控制 3–132,三个 dark 控制恰是已退休成员);唯一实现了的配额面故意答 TOO_MANY_REQUESTS;TenantQuotaSchema / QuotaEnforcementResultSchema 在 spec 自己的测试和生成物之外无消费者。⇒ 平台不是缺一个它打算做的实现。指向 A。
• 项目长远合理性(权重 ≥50%,领起) — 指向 A。「已登记但不可发出」正是 ADR-0049 存在要清除的那一类;留着等于让目录描述一个不存在的平台。C 把这件事写进文档,只是把不一致记录下来,⛔ 不是消除它。
• 防 AI 写元数据/代码犯错 — 最强的一轴,指向 A。错误码目录是 AI 最常照抄的那种清单:留着 QUOTA_EXCEEDED,AI 就会写一条永远不会触发的处理分支并当它是活的。⭐ C 尤其坏——它把「声明了但不兑现」正式写进文档,正是「声明即强制」的反面。
• 创业阶段不扩散需求 — 指向 A。B 等于承诺去建一个零拉动的配额生产者;「已发布零消费的能力不因沉没成本获得豁免」。且按 2026-08-27 裁定「短期不考虑渐进」,退休立即执行,⛔ 不设过渡窗口——这也排除了「先标注、下个大版本再删」的中间路线。

⇒ 四棱同向指 A。⛔ 仍不走代裁:置信门②不成立(删已发布契约成员在人工地板上),故照常呈报。

_{分诊席位 · session_015WpYyzhX8x2kEhouLBidt8 · R+183 · 2026-09-12T03:25Z · 本评论来自分诊座位}

---

Generated by Claude Code