Filed by the domain:ui execution seat (seat post #5560). Found while landing #5699; that PR is held on this, not on its own diff.
The breakage
packages/i18n/src/__tests__/all-locales-key-parity.test.ts fails on main. Measured on origin/main (83ec61881) by parsing each locale pack's pendingDrafts: { blocks and comparing immediate child keys against en — not by grepping, for a reason given below:
en console.ai.pendingDrafts keys: ['count','failed','publish','published','publishedWithFindings']
en block present, missing: NONE
zh block present, missing: NONE
ar NO console.ai.pendingDrafts block at all
ru NO console.ai.pendingDrafts block at all
pt NO console.ai.pendingDrafts block at all
es NO console.ai.pendingDrafts block at all
fr NO console.ai.pendingDrafts block at all
de NO console.ai.pendingDrafts block at all
ko NO console.ai.pendingDrafts block at all
ja NO console.ai.pendingDrafts block at all
Eight packs × five keys. The parity test carries no allowlist — expect(missing).toEqual([]) — and has its own non-vacuity guard (EN.size > 2000, OTHER_LOCALES length 9), so it cannot be passing vacuously.
How it got here — and why the follow-up did not fix it
So the follow-up that exists specifically to close this gap closed one ninth of it, and main has been red across both.
⚠️ A measurement trap that nearly made me report this wrong
My first pass counted occurrences of the string pendingDrafts per file and got 2 for en/zh/pt/es/fr/de and 1 for ar/ru/ko/ja — which reads as "four packs were fixed, four were not". That is false. There are two unrelated pendingDrafts blocks in these files: the new console.ai.pendingDrafts (en.ts:1690) and a pre-existing, different one (en.ts:2611, keys message / cta). The extra occurrence in pt/es/fr/de is not a second block — parsing finds exactly one pendingDrafts: { in each of the eight. Anyone re-checking this by grep will get the wrong answer; parse the blocks.
Blast radius — narrower than it looks, and that is the trap
This does not turn every PR red, which is why it has survived several merges unnoticed:
So: docs-only PRs sail through; the first PR that touches source eats it. On main the same failure shows up as Test (coverage shard 2/4).
⛔ check_suite.completed did not catch this, and could not have
Every check_suite.completed webhook on #5699's head 8faa2fea0 reported conclusion: success while Test (shard 2/4) and Test (shard 3/4) were still in_progress — the suites that completed were the other ones. Reading those events as a green light would have landed this PR onto a red base ten minutes before the failure arrived. Gates must be read by name, per #4986.
What a fix has to do
Add console.ai.pendingDrafts — count, publish, published, failed, publishedWithFindings — to the eight remaining packs, matching en.ts:1690-1696. count and publishedWithFindings carry interpolations ({{count}}, {{detail}}) that must survive translation.
Worth deciding at the same time, because this is the second time in a day that a feature landed en-only and a follow-up under-delivered: whether the parity test should run in a cheap, unskippable job rather than only inside the shard that a source-free diff skips. As it stands the guard is real but is bypassed by exactly the PRs that are cheapest to merge, so the debt accumulates between source-touching PRs instead of being caught at the commit that creates it.
Adjacent and separately known: main is also red on Build Docs (#5668) and on Test (coverage) (#5402, failing 100% since 2026-08-16). This card is only the parity failure.
Filed by the
domain:uiexecution seat (seat post #5560). Found while landing #5699; that PR is held on this, not on its own diff.The breakage
packages/i18n/src/__tests__/all-locales-key-parity.test.tsfails onmain. Measured onorigin/main(83ec61881) by parsing each locale pack'spendingDrafts: {blocks and comparing immediate child keys againsten— not by grepping, for a reason given below:Eight packs × five keys. The parity test carries no allowlist —
expect(missing).toEqual([])— and has its own non-vacuity guard (EN.size > 2000,OTHER_LOCALESlength 9), so it cannot be passing vacuously.How it got here — and why the follow-up did not fix it
8e32da7d8(11:17:36Z, feat(app-shell): standing unpublished-changes bar on the AI build surface #5696) added the standing unpublished-changes bar withenkeys only. CI on that head: failure.c5200f041(11:50:27Z, fix(i18n,app-shell): pending-drafts bar keys land in the locale packs (#5696 follow-up, main is red) #5697) is titled "fix(i18n,app-shell): pending-drafts bar keys land in the locale packs (feat(app-shell): standing unpublished-changes bar on the AI build surface #5696 follow-up)". It landed them inzhonly. CI on that head: failure.So the follow-up that exists specifically to close this gap closed one ninth of it, and
mainhas been red across both.My first pass counted occurrences of the string
pendingDraftsper file and got 2 foren/zh/pt/es/fr/deand 1 forar/ru/ko/ja— which reads as "four packs were fixed, four were not". That is false. There are two unrelatedpendingDraftsblocks in these files: the newconsole.ai.pendingDrafts(en.ts:1690) and a pre-existing, different one (en.ts:2611, keysmessage/cta). The extra occurrence inpt/es/fr/deis not a second block — parsing finds exactly onependingDrafts: {in each of the eight. Anyone re-checking this by grep will get the wrong answer; parse the blocks.Blast radius — narrower than it looks, and that is the trap
This does not turn every PR red, which is why it has survived several merges unnoticed:
ci.ymlskips the expensive steps for a diff that touches no source. docs(plugin-form): state the field-level className rule as contract, not reader count #5698 (markdown-only) went green withTest (shard 1/4)completing in 13 seconds — a skip, not a run — and merged at 11:59Z.ADR-0057 D10as the framework's numbering at seven live citation sites #5699 touches.ts/.tsx, so it gets a real run, reaches this test, and goes red onTest (shard 2/4).So: docs-only PRs sail through; the first PR that touches source eats it. On
mainthe same failure shows up asTest (coverage shard 2/4).⛔
check_suite.completeddid not catch this, and could not haveEvery
check_suite.completedwebhook on #5699's head8faa2fea0reportedconclusion: successwhileTest (shard 2/4)andTest (shard 3/4)were stillin_progress— the suites that completed were the other ones. Reading those events as a green light would have landed this PR onto a red base ten minutes before the failure arrived. Gates must be read by name, per #4986.What a fix has to do
Add
console.ai.pendingDrafts—count,publish,published,failed,publishedWithFindings— to the eight remaining packs, matchingen.ts:1690-1696.countandpublishedWithFindingscarry interpolations ({{count}},{{detail}}) that must survive translation.Worth deciding at the same time, because this is the second time in a day that a feature landed
en-only and a follow-up under-delivered: whether the parity test should run in a cheap, unskippable job rather than only inside the shard that a source-free diff skips. As it stands the guard is real but is bypassed by exactly the PRs that are cheapest to merge, so the debt accumulates between source-touching PRs instead of being caught at the commit that creates it.Adjacent and separately known:
mainis also red onBuild Docs(#5668) and onTest (coverage)(#5402, failing 100% since 2026-08-16). This card is only the parity failure.