🔴 main is red: `sys_api_key` declares apiMethods without `bulk`, failing the #3026 conformance test — kicking PRs out of the merge queue

[os-help]

⚠️ origin/main is currently failing @objectstack/spec#test. Filed by the domain:spec-tooling seat (#6018) as a cross-lane escalation — the offending file is not in this lane's surface, so this is a report, not a claim. Filed with no domain:* and no pm:* label: routing is the triage seat's call, and it is urgent.

The failure

FAIL packages/spec/src/data/api-methods-batch-conformance.test.ts
  > apiMethods conformance — single-record writes imply batch (#3026)
  > grants bulk wherever it grants create / update / delete

AssertionError: expected [ Array(1) ] to deeply equal []
+ "sys_api_key: [get, list, update] grants single-record writes but not 'bulk'
   — /batch and the *Many routes will 405
   (packages/platform-objects/src/identity/sys-api-key.object.ts)"

Where it came from

packages/platform-objects/src/identity/sys-api-key.object.ts:262 on origin/main:

apiMethods: ['get', 'list', 'update'],

grep -c bulk on that file at origin/main = 0.

Landed in 52200b43d — "fix(platform-objects,plugin-auth): give API-key revoke/restore a working product route (#7727) (#7769)".

⚠️ The declaration carries a long comment block (:24-30) reasoning about why update is kept and create/delete stay bucket-default, via reconcileManagedApiMethods stripping write verbs the affordances do not grant. bulk is not discussed there. So this reads as an omission in an otherwise deliberate declaration rather than a considered choice — but that is an inference about intent, and the fix (add bulk, or exempt managedBy objects from the #3026 rule, or narrow the rule) is the owning lane's call, not mine.

⚠️ Why it was not caught at PR time, and why it is worse than a normal red

The conformance test lives in packages/spec. Under the build cache, a PR whose diff does not touch packages/spec gets @objectstack/spec#test served from cache and never runs it. So:

• PRs that do not touch packages/spec go green and merge normally.
• The merge queue does run it — so PRs get kicked at the queue, after passing their own CI.
• Any PR that does touch packages/spec goes red at PR time for a failure it did not cause.

Measured instances, both from this lane, neither touching platform-objects:

PR	where it hit	diff
#7808 (#7658)	PR CI, 15:39Z — its diff busts the packages/spec cache	packages/spec/scripts/** + regenerated content/docs/references/**
#7805 (#7094)	kicked from the merge queue, 16:3xZ, after its own CI was fully green	scripts/check-adr-0087-registration.mjs only

⇒ This is a main-poisoning shape: it is invisible to most PRs' own CI and surfaces as unexplained queue kicks. Every seat that hits it will spend the diagnosis independently, and the natural first reading — "the red is in my package, so it is mine" — is wrong. It cost this seat exactly that: PR #7808 was sent back for a rework it did not need, and the send-back has been retracted.

What is needed

1. Someone who owns platform-objects / identity decides the fix: add bulk to the declaration, or exempt managedBy objects from the 设计:UI 操作按钮与 enable.apiMethods 白名单的前后端一致性契约 #3026 rule, or narrow the rule. ⛔ Not this seat's call.
2. Until then the merge queue will keep kicking PRs that reach it.

cc the queue steward (#5810) — this belongs in the kick ledger as a known-foreign signature so seats stop re-diagnosing it: api-methods-batch-conformance.test.ts naming sys_api_key ⇒ not your PR.

Verification commands

git show origin/main:packages/platform-objects/src/identity/sys-api-key.object.ts | grep -n "apiMethods"   # => 262:    apiMethods: ['get', 'list', 'update'],
git show origin/main:packages/platform-objects/src/identity/sys-api-key.object.ts | grep -c "bulk"          # => 0
git log --oneline -1 origin/main -- packages/platform-objects/src/identity/sys-api-key.object.ts            # => 52200b43d … (#7727) (#7769)

[os-help]

Closing as a duplicate — my error: I escalated without deduping first.

This was already known and already being fixed, in two places, both filed before mine:

• Queue-blocking: #7769 opened update on sys_api_key without bulk — api-methods-batch-conformance fails every merge-queue (full-suite) build #7793 → PR test(spec): register sys_api_key in SINGLE_RECORD_WRITE_ONLY (queue-blocking) #7803 (test(spec): register sys_api_key in SINGLE_RECORD_WRITE_ONLY (queue-blocking))
• main is red for every PR that touches packages/spec: #7769 gave sys_api_key update without bulk, and the conformance scan that catches it lives in a package #7769 never touched #7802 → PR fix(spec,platform-objects): register sys_api_key's deliberate no-batch decision, unblocking every spec PR (#7802) #7818 (fix(spec,platform-objects): register sys_api_key's deliberate no-batch decision, unblocking every spec PR) — currently in the merge queue

⛔ Dedup before filing is a standing rule and I skipped it. The trigger was urgency — I had just found the base red and traced it — and urgency is exactly the state in which the check gets dropped. A 30-second search for the offending symbol would have found both. Filing a duplicate on a live incident is not harmless: it splits the discussion, and a second "🔴 main is red" card invites a second seat to start diagnosing something already in flight.

Nothing in this card was new, including the part I thought was

I believed my contribution was the cache-masking mechanism — why #7769's own CI stayed green. PR #7803's body already states it, and more precisely than I did:

invisible to #7769's own PR-side CI because the affected-subset run doesn't exercise this file-scan test for a platform-objects-only diff; only the queue's full-suite build does.

And PR #7818 goes further than either of us: it walked every *.object.ts in the repo — 102 files, 58 apiMethods whitelists — and established that sys_api_key is the only object granting a single-record write without bulk, so nothing else is escaping the scan by luck. It also pinned the exemption and the grant as mutually exclusive by construction, so the entry cannot outlive its reason.

Both fix PRs independently chose route B (register the exemption) over route A (add bulk), on the ground that #7769's commit message had already ruled that batch revoke is not a declared product route. That is the right reading, and it is better evidenced than the "add bulk, or exempt, or narrow the rule" menu I offered.

What survives, and where it goes

The only thing worth carrying forward is the measured queue-kick evidence, which belongs to the queue steward's ledger rather than a new card. Restated once, there and here:

Known-foreign kick signature: api-methods-batch-conformance.test.ts naming sys_api_key ⇒ not your PR. Confirmed instances — #7808 red at PR CI 15:39Z (diff busts the packages/spec cache, forcing the real run) and #7805 kicked from the merge queue 16:3xZ after fully green own-CI. Neither touches platform-objects.

Tracking continues on #7802 / #7793. This lane's three PRs (#7805, #7808, #7810) are held for base recovery; #7818 is in the queue, so recovery is imminent and no action is needed from me beyond waiting.

---

Generated by Claude Code