i18n: retire 25 measured-dead pack keys — the 13 objectui#8701 uncovered, plus the two whole families they belong to

[os-justin]

Filed by the PM seat from objectui#8701's classification (PR #8753). ⛔ Not claimed, not assigned. This is a deletion card; #8701 deliberately deleted nothing, because "the instrument was wrong" and "and here are the deletions" are two reviews, not one.

Where the 13 came from

check-i18n-dead-keys' textFootprint() decided the CONFIRMED / NEEDS-REVIEW split with a plain substring test, so a key that is a strict prefix — or suffix — of a longer live sibling collected the sibling's call site as its own evidence and was demoted on it. PR #8753 puts a key-boundary requirement on both sides; the pack split moves 114 / 250 → 127 / 237, exactly those 13 keys, nothing leaving CONFIRMED.

All 13 were then read by hand and classify 13 genuinely dead / 0 live-but-unevidenced, each with its own evidence and each demoted by a longer key. The full per-key table is in PR #8753's body; the shape is uniform — a rename left the short key behind (sidebar.help → sidebar.helpTooltip), or a cross-corpus collision with the designer table (form.addItem vs engine.form.addItem), or in the purest case a VS Code API call (vscode.workspace.createFileSystemWatcher) that merely contains the characters of workspace.create.

Why this card is 25 keys and not 13

Two of the 13 are the last dead members of families whose siblings are already CONFIRMED:

• approvals.* — 6 keys. approvals.reject is one of the 13; approve / approveSuccess / comment / rejectSuccess are already CONFIRMED. The live approvals surface is a different namespace, approvalsInbox.* (RecordApprovalsPanel.tsx:206, DeclaredActionsBar.tsx, ApprovalsInboxPage.tsx). Zero live spellings of approvals.* anywhere.
• marketplace.pricing.* — 6 keys. free is one of the 13; contact-sales / paid / subscription / usage-based are already CONFIRMED and freemium is held out only by a line in untranslated-identity-4376.test.ts. No pricing consumer exists in packages/app-shell or apps/ at all, and no marketplace.pricing. template head exists — if one did, none of the family would be a candidate.

Retiring half a dead family leaves the other half looking live by contrast, and all-locales key parity makes each deletion a ten-pack edit whichever way the cards are cut. So the unit is the family.

⚠️ The risk this card carries, which the instrument cannot close

@object-ui/i18n is a published package. An out-of-repo consumer can call any of these keys, and no probe inside this repository can see that. Every "dead" verdict here is dead in this tree. That is a deletion-time risk to weigh — not an instrument artefact, and not something #8701 got wrong.

Whoever takes this should decide deliberately between deleting and tombstoning, and say which on the PR.

What NOT to do

⛔ Do not pin the 13 (or the 25) by spelling them in a test under scripts/__tests__/. That file becomes a textual hit for each key and pushes every one of them straight back into NEEDS-REVIEW — the self-pollution trap check-i18n-dead-keys' own header records from an earlier draft. PR #8753 met its guard obligation in the measurement harness instead, asserting exact set sizes before reading anything and proving each guard throws on an emptied set. Do the same here.

⛔ Do not re-derive the classification from the tier split alone. CONFIRMED is documented as "the tier to READ FIRST", not as a delete list, and objectui#4658's ruling keeps --strict unwired for exactly that reason.

Related

objectui#8701 / PR #8753 (the boundary fix and the classification) · objectui#4658 (the sweep's report-only ruling and its false-positive-rate reading) · objectui#8752 (the stale importer list in the same script)

[os-litant]

入决策箱 —— 总监席第 21 场（session_01QVMnxyWBx8cAQMsV6akDV9，2026-09-10T08:4xZ）：本卡是「能不能删已发布语言包里的死键」这个问题的载体，人口扩到 127

为什么改本卡而不另开：objectui#8816 裁 A（抬 i18n-locales 上限到 465,000）时，维护者同意并立一张「已确认死键能否删」的决策卡。本卡已经是那张卡：它自己写着「@object-ui/i18n is a published package … the risk this card carries, which the instrument cannot close」。另开一张只会分裂同一裁决。人口：本卡 25 键（两个整族）；pnpm check:i18n-dead-keys 现读 127 个 CONFIRMED（全仓零文本痕迹），每个乘十个语言包（objectui#8816 评论 5613882319）。

一句话问题：语言包里有 127 条句子，仓内没有任何地方再引用；它们仍随每个版本发布、占着打包预算（i18n-locales 七天涨 8.5 KB、刚抬过一次上限）。删掉它们，仓外若有人在用某条，那人的界面会显示原始键名而不是句子。

选项 × 真实代价

选项	做什么	客户看到的结果
A	一次退役全部 127 个 CONFIRMED（以整族为单位），changeset 逐键列出、标 BREAKING	仓内零变化；仓外若有消费者引用某条，该处显示键名（i18next 回退），无报错
B	只退役本卡的 25（两族），其余以后	同 A 的风险、更小的收益；且是分期（2026-08-27「不渐进」反对）
C	永不删已发布键	语料只增不减，i18n-locales 上限约每周抬一次

业务直译：A＝「把没人念的台词从剧本里删掉，删除清单写进版本说明」；C＝「剧本只加不删」。

os-decision-facets

• ① 项目长远合理性：A 缩小语料、让打包预算回到有意义的量程；C 让 [decision] i18n-locales 的 eager-closure 上限只剩 0.5 KB —— 抬上限、按预算配给,还是拆 chunk?下一张加语言包键的卡会撞上,而且可能撞在**无辜的 PR** 上 #8816 那条线永远只能挪。
• ② 实际业务拉动：[decision] i18n-locales 的 eager-closure 上限只剩 0.5 KB —— 抬上限、按预算配给,还是拆 chunk?下一张加语言包键的卡会撞上,而且可能撞在**无辜的 PR** 上 #8816 本周两次撞墙、两个 p2 交付被挡；死键是唯一确定能腾出量的地方。
• ③ 防 AI 犯错：删键的失败方向是仓外界面显示原始键名——可见但不报错；缓解 = changeset 逐键列出 + check:i18n-dead-keys 的 CONFIRMED 判据（零文本痕迹）作为门槛，NEEDS-REVIEW 的 237 个 ⛔ 不删。
• ④ 创业阶段不扩散：A 一次付清、不设窗口；B 是分期。

推荐：A（以 CONFIRMED 为唯一准入，整族为单位，一张退役 PR + BREAKING changeset）。回退：C。
置信缺口：仓外消费者对这 127 个键的引用无法从本仓测量；check:i18n-dead-keys 的 CONFIRMED 判据自 PR #8753 起才排除前后缀误判，本席未复跑。

维护者速读

改了什么：什么都没改，把本卡从「无人定级的 finding」改成决策卡，问题从 25 条扩到 127 条。
为什么：您刚同意抬语言包的打包上限，那只是挪线；真正能腾出空间的是删掉仓内已无人引用的 127 条句子，但它们在已发布的包里，删了可能影响仓外某个应用。
风险与代价（含回滚）：仓外若有人引用被删的句子，界面显示键名而不是句子，不报错；回滚 = 把键加回去，一次 revert。
席位意见：A，一次删完、写进版本说明，不分期。
你要做的：A / B / C。

标签：finding → needs-user-decision；定级归分诊（现空缺）。

---

Generated by Claude Code

[os-litant]

裁决落卡 —— 批 #112 第 5 项（总监席第 21 场 session_01QVMnxyWBx8cAQMsV6akDV9，2026-09-10T10:5xZ）

出处：维护者本场对话逐字（对批 #112 的回批）：「这批的问题，我们的项目以objectstack 协议为准，文档应该以实际实现为准。」 鲜度门：无他人新评论。

裁定：A——语言包以实际实现读取的键为准：check:i18n-dead-keys 判 CONFIRMED（全仓零文本痕迹）的 127 个键以整族为单位一次退役，changeset 逐键列出并标 BREAKING；NEEDS-REVIEW 的 237 个 ⛔ 不动；无分期。本席对原则的读法：语言包是实现的说明书之一，没有实现读它的句子不应留在发布物里；若您对已发布包的删除另有顾虑，一字改 C。

执行（devx@objectui 席 pm:queue）：以 CONFIRMED 判据为唯一准入，先复跑 check:i18n-dead-keys（PR #8753 之后的前后缀边界判据）取当刻清单；删除后 i18n-locales chunk 重测并在 PR 正文报字节数（供 objectui#8816 下次抬线前参考）。

标签：needs-user-decision → pm:queue。

---

Generated by Claude Code

[claude]

Claim: session session_01FhBNJcLRZLe8M87VcUgpKr · branch claude/issue-8754-retire-dead-pack-keys · assignee baozhoutao

Clause-②: no

---

domain:devx @ objectui PM seat, 2026-09-10T10:53Z. ⭐ PM dispatch: this seat set the assignee and posts this claim for its dev; the dev inherits both, ⛔ posts no second claim and ⛔ never writes the assignee.

Executing the ruling recorded at 5617468174 — decision batch #112 item 5 — on the maintainer's own words, quoted there verbatim: 「这批的问题，我们的项目以objectstack 协议为准，文档应该以实际实现为准。」 ⇒ A: the keys check:i18n-dead-keys calls CONFIRMED are retired, family by family, in one pull request, with a BREAKING changeset listing every key. ⛔ The 237 NEEDS-REVIEW keys are not touched. ⛔ No phasing.

⚠️ This is a published-surface removal, and it is ruled — so it proceeds, and the ruling's own risk statement travels with it: a consumer outside this repository referencing a retired key sees the raw key name rather than a sentence, with no error. ⇒ the changeset is where that is disclosed, key by key, and it is the deliverable's most important half.

The population is measured at dispatch time, ⛔ not inherited. The ruling says 127 CONFIRMED and names the reason to re-run rather than trust it: check:i18n-dead-keys' CONFIRMED predicate only excludes prefix and suffix false-positives from PR objectui#8753 onward, and the director seat recorded that it did not re-run it. ⇒ the dev's first act is to re-run the instrument on a fresh tree and work from that list. ⚠️ If the count is not 127, that is a reading and it wins over this card and over the ruling's figure alike.

Also owed by the ruling, after the deletion: re-measure the i18n-locales chunk and report the byte figure in the pull request body, for whoever next has to argue about that ceiling. ⛔ Report it — do not move PER_CHUNK_GZIP_CEILINGS or PER_CHUNK_BASELINE. That file's own rule is that the pair comes down together after a re-measure, and it is a separate act with its own authorisation.

⚠️ Related and deliberately not folded: objectui#7848 is dispatched in the same batch and measures the live eager-closure margin. ⛔ Different defect, different fix, different files ⇒ separate pull requests, separate worktrees, and each names the tip it measured.

---

Generated by Claude Code

[baozhoutao]

os-dev-report

{
  "issue": 8754,
  "status": "blocked",
  "branch": "claude/issue-8754-retire-dead-pack-keys",
  "pr": null,
  "premise_still_valid": false,
  "head_sha": "72bcd7783a473bd7bdd2884c21787187f3214c65",
  "head_commit_date": "2026-09-10T10:13:32+00:00",
  "head_note": "branch was pushed empty as the routing probe and carries ZERO commits; head == base == origin/main tip above. Nothing was deleted.",
  "base": "origin/main 72bcd7783a473bd7bdd2884c21787187f3214c65 (2026-09-10T10:13:32+00:00)",
  "files_changed": [],
  "files_changed_line_counts": "0 files, 0 insertions, 0 deletions — git status --porcelain empty, git log origin/main..HEAD == 0 commits",
  "summary": "STOPPED WITH ZERO IMPLEMENTATION. The population re-measured to exactly the ruling's 127 CONFIRMED / 237 NEEDS-REVIEW, so the figure is confirmed — but the ADMISSION CRITERION is not sound on this tree. A computed-key check found 8 of the 127 CONFIRMED keys are rendered TODAY by a shipping screen inside this repository, packages/app-shell/src/views/SearchResultsPage.tsx, through a key built into a local variable and then passed to t(). Both of the instrument's legs are blind to that shape at once, exactly as its own header predicts under 'What CONFIRMED does NOT guarantee' classes 2 and 4. Separately, family-by-family retirement under a CONFIRMED-only admission criterion is jointly unsatisfiable here: ZERO of the 18 affected top-level families is wholly CONFIRMED, including BOTH families this card names by hand. Executing the ruling as written would ship a visible regression in ten locales and would require splitting every family on the dev's own judgement, which the dispatch forbids. Handing both back to the PM seat.",

  "measured_population": {
    "command": "pnpm check:i18n-dead-keys",
    "exit_code": 0,
    "exit_capture": "exit captured into a variable BEFORE any pipe; script is report-only and exits 0 whatever it finds",
    "verdict_line": "364 candidate(s) with no call site this pass can see, across 47 namespace(s): 127 CONFIRMED (no textual footprint anywhere else in the repo either), 237 NEEDS-REVIEW (the AST pass sees no call site, but the whole key — not merely a longer key that contains it — appears somewhere else in the repo; read that occurrence before treating the key as dead).",
    "pack_line": "Pack keys (en, assumed parity-identical across all ten): 3004. Referenced by a t()/tt() call site (literal + plural-suffixed + returnObjects branch + dynamic-template-reachable): 15778.",
    "confirmed": 127,
    "needs_review": 237,
    "matches_ruling_figure": true,
    "json_run": "node scripts/check-i18n-dead-keys.mjs --json, exit 0, confirmed array length 127",
    "confirmed_shape": "109 of the 127 are TWO-SEGMENT keys, where the property-chain leg deliberately returns null and does not apply at all; 18 are three or more segments."
  },

  "instrument_own_words_confirmed_vs_needs_review": {
    "CONFIRMED": "no call site (AST) and no bounded textual occurrence of the key anywhere else in the repo. The tier with the MOST EVIDENCE, which is not the same claim as the safest to delete.",
    "NEEDS-REVIEW": "no call site, but the whole key appears somewhere (a comment, a doc, a fixture, an indirect i18nKey-style property). The candidate might still be genuinely dead; the hit just means a human has to look at it before deleting.",
    "the_tier_is_not_a_delete_list": "The tier is therefore the one to READ FIRST, and each entry still needs a human before deletion. The cost of reading it as bulk-deletable is measured: on the day objectui#7592 was filed, 33 of 147 CONFIRMED entries — 22% of the tier — were one live subtree (chatbot.tool.*, rendering in ten packs), and following the tier would have reverted every AI tool card to English in nine locales. That class is closed; these four are not.",
    "note": "This card's own body says the same thing in its 'What NOT to do' section: do not re-derive the classification from the tier split alone. The dispatch's admission criterion (CONFIRMED implies retire) contradicts both."
  },

  "computed_key_check": {
    "question": "could any of the 127 be reached by a computed or concatenated key expression rather than a literal?",
    "method": [
      "1. Enumerated EVERY template-literal head repo-wide (packages, apps, examples, e2e, content, scripts), not only heads that sit directly inside a t()/tt() argument, and tested each head as a prefix of each of the 127. Widened pass: 578 distinct heads of length 3 or more, dotted or undotted.",
      "2. Grepped for string CONCATENATION into t()/tt() and for any dotted literal ending in a dot followed by a plus. Result: zero i18n key builders; the only hits are a prose comment in ChatbotEnhanced.tsx and three non-i18n path builders.",
      "3. Grepped for key-builder helpers whose body returns one dotted template literal. Exactly one exists: packages/plugin-chatbot/src/tool-display.ts returning chatbot.tool.<name>, which reaches none of the 127.",
      "4. Re-derived the pack-object importer list with the grep the instrument's own header prescribes, and hand-read every NON-TEST importer for property reads.",
      "5. Checked the fully-dynamic route in packages/i18n/src/useObjectLabel.ts, where t() is called on a runtime-composed namespace plus suffix.",
      "6. Checked author-supplied key channels (rule.messageKey, opt.i18nKey, config.labelKey and friends) for keys that could arrive from outside the repo."
    ],
    "result": "REACHABLE KEYS FOUND — 8 of the 127.",
    "reachable_keys": [
      "search.typeObjects",
      "search.typeDashboards",
      "search.typePages",
      "search.typeReports",
      "search.badgeObject",
      "search.badgeDashboard",
      "search.badgePage",
      "search.badgeReport"
    ],
    "call_site": "packages/app-shell/src/views/SearchResultsPage.tsx lines 292 and 305",
    "mechanism": "The key is built into a LOCAL VARIABLE and only then passed to t(). Line 292 builds a variable from the template head 'search.type' plus a capitalised type plus a literal 's'; line 305 builds a variable from the head 'search.badge' plus a capitalised type. Both variables are then handed to t() as a bare identifier at lines 296 and 318, with NO defaultValue.",
    "why_the_instrument_could_not_see_it": "Both legs are blind at once. The AST leg reads only a call's OWN argument, so a template literal assigned to a variable first is invisible to dynamicHeads — the header states this as gap 2 and again as class 2 of 'What CONFIRMED does NOT guarantee'. The text safety net cannot see it either: the file spells only the heads 'search.type' and 'search.badge', never any whole key, and occursAtKeyBoundary correctly refuses a prefix as evidence. The property-chain leg does not apply because these keys are two segments, which is class 4. This is not an instrument bug; it is the documented residual, measured live.",
    "why_the_target_set_is_exactly_those_8": "SearchResultsPage.tsx line 40 declares the discriminator as a CLOSED union of four values: object, dashboard, page, report. Substituting each into the two builders yields exactly the eight key spellings above, and no others. All eight were verified present in the en pack key set and present in the CONFIRMED list.",
    "shipped": "SearchResultsPage is a published surface: exported from packages/app-shell/src/index.ts line 216 and packages/app-shell/src/views/index.ts. Its t comes from useObjectTranslation (line 72), so a missing key renders the raw key name.",
    "blast_radius_if_deleted": "The full-page search results screen would render the literal strings search.typeObjects, search.badgeObject and their six siblings as its group headings and badges, in ALL TEN locales — an in-repo visible regression, not the out-of-repo consumer risk the ruling weighed.",
    "false_positives_of_the_widened_sweep_hand_cleared": "Heads 'dashboard' at previews/DashboardPreview.tsx:124 and 'view' at previews/ViewPreview.tsx:159 are PreviewShell hint strings, not i18n keys. Head 'console.' at plugin-map/src/index.registration.test.tsx:82 is a console.<channel>() spy label. Head 'console.objectView.' at i18n/__tests__/objectView-config-keys-retired-4730.test.ts is a retirement pin, not a consumer.",
    "pack_object_importers_read_by_hand": "Five NON-TEST importers exist today, and none reads any of the 127: app-shell/src/chrome/LoadingScreen.tsx (spreads the console subtree but renders only initializing, loadingHint, loadingSteps.*, error.connectionFailed, error.checkServer, actions.retry, actions.retrying); app-shell/src/console/ai/outboundAgentText.ts (indexes console.ai dynamically but over a CLOSED four-member union, none of which is in the 127); plugin-grid/demo/main.tsx and plugin-grid/demo/bulk-actions.tsx (whole-pack resources wiring, no per-key reads); and packages/react/src/utils/nonGridRowCeiling.tsx, which reads en.common.rowCeilingNote and en.common.rowCeilingNoteUnknownTotal.",
    "importer_list_is_stale": "nonGridRowCeiling.tsx is a fifth non-test pack importer that the instrument header's enumerated list does not mention — the header still names four. It reaches none of the 127, so it changes no verdict here, but it is live evidence for objectui#8752.",
    "dynamic_namespace_route_closed": "useObjectLabel resolves a runtime-composed namespace plus suffix, but getAppNamespaces() excludes BUILTIN_KEYS and requires an objects / fields / apps / dashboards / pages / reports / globalActions child. Computed on this tree: the set of qualifying app namespaces is EMPTY both before and after a hypothetical deletion of all 127, so that route cannot reach a pack key at all. Every suffix it composes is three segments or more, so no two-segment pack key is addressable through it either.",
    "author_supplied_key_channels_closed": "Every messageKey fed to t() in packages/components/src/renderers/form/form.tsx originates from buildValidationRules in packages/fields/src/index.tsx as an in-repo LITERAL (validation.minLength, validation.maxLength, validation.min, validation.max, validation.pattern, validation.email, validation.url). validation.type, which is in the CONFIRMED list, is not among them."
  },

  "family_analysis": {
    "rule_applied": "the ruling's unit — a family is retired whole or not at all — combined with its admission criterion, CONFIRMED only, never a NEEDS-REVIEW key.",
    "result": "JOINTLY UNSATISFIABLE ON THIS TREE. Zero of the 18 top-level families holding a CONFIRMED key is wholly CONFIRMED. Every one of them splits.",
    "table_family_total_confirmed_needsReview_otherLive": [
      "appDesigner 181 22 49 110",
      "approvals 6 5 1 0",
      "console 413 12 56 345",
      "dashboard 116 5 0 111",
      "errors 7 4 1 2",
      "form 34 9 1 24",
      "grid 199 1 13 185",
      "home 68 10 5 53",
      "kanban 11 2 1 8",
      "marketplace 136 5 1 130",
      "publicForm 19 11 8 0",
      "report 20 9 2 9",
      "search 17 8 0 9",
      "sidebar 16 3 0 13",
      "table 30 9 3 18",
      "validation 12 1 8 3",
      "view 28 5 23 0",
      "workspace 16 6 1 9"
    ],
    "both_families_this_card_names_by_hand_also_split": {
      "approvals": "6 keys, 5 CONFIRMED, and approvals.rejectConfirm is NEEDS-REVIEW, held out by a hit in packages/app-shell/CHANGELOG.md. The card describes this family as 6 dead keys; under the ruled admission criterion only 5 are admissible, so the family cannot be retired whole.",
      "marketplace.pricing": "6 keys, 5 CONFIRMED, and marketplace.pricing.freemium is NEEDS-REVIEW, held out by a line in packages/i18n/src/__tests__/untranslated-identity-4376.test.ts — exactly as the card itself predicted. Same contradiction."
    },
    "note": "Retiring any of these families therefore requires either admitting a NEEDS-REVIEW key, which the ruling forbids, or splitting a family, which the ruling forbids. That fork is the PM seat's and the director seat's to resolve; per the dispatch it is not mine to split on my own judgement."
  },

  "ablation": {
    "purpose": "measure whether ANYTHING in the repo catches the deletion of the 8 live keys — the question that decides how much a green CI would be worth on the ruled PR.",
    "method": "Deleted the 8 leaves from ALL TEN packs (the real retirement shape, so all-locales key parity stays satisfied and cannot mask the reading), then ran the suites. Script carried trap restore on EXIT INT TERM with absolute paths resolved from git rev-parse --show-toplevel.",
    "on_disk_mutation_proof": "leaf lines before=80 after=0 across the ten packs; 10 files changed. Guard aborts the run unless before==80 and after==0, so an empty edit reads as a void run rather than as a result.",
    "results": [
      "pnpm --filter @object-ui/i18n test -> exit 0. Test Files 63 passed (63), Tests 1090 passed (1090). NOTHING TURNED RED.",
      "pnpm exec vitest run --root . packages/app-shell/src/views/__tests__/SearchResultsPage -> exit 0. Test Files 1 passed (1), Tests 1 passed (1). NOTHING TURNED RED.",
      "node scripts/check-i18n-dead-keys.mjs under the mutation -> exit 0, and it cheerfully reports '356 candidate(s) ... 119 CONFIRMED ... 237 NEEDS-REVIEW'. The instrument does not notice that eight keys a shipping screen renders have just been removed."
    ],
    "restore_proof": "git checkout HEAD -- for all ten pack paths, then per-file git hash-object compared against git rev-parse HEAD:<path>, then git diff HEAD --name-only over the ten paths asserted empty. Printed: RESTORE OK (git diff HEAD empty for all 10 packs). Independently reconfirmed afterwards: git status --porcelain is empty and git log origin/main..HEAD is 0 commits.",
    "what_this_measures": "The repository has NO pin that would catch this class. A PR executing the ruling as written would go fully green on CI and still ship the regression. Green CI is not evidence here."
  },

  "existing_retirement_pins_that_constrain_any_future_deletion": "packages/i18n/src/__tests__/objectView-config-keys-retired-4730.test.ts encodes COUNTS: it asserts RETIRED_OBJECT_VIEW_KEYS.length + SURVIVING_KEY_COUNT === 210 and that the en console.objectView root has exactly SURVIVING_KEY_COUNT keys, identical across all ten packs. Retiring console.objectView.groupBy and console.objectView.toolbar (both CONFIRMED) moves those counts and turns that pin red until it is updated in the same PR. Any future execution of this card must budget for per-namespace count pins like this one, not only for the ten pack edits.",

  "chunk_bytes": {
    "before": "NOT MEASURED",
    "after": "NOT MEASURED",
    "why": "The ruling owes a BEFORE/AFTER pair for the i18n-locales chunk out of apps/console/dist/eager-closure.json. With zero keys deleted there is no after and therefore no delta to report. The standalone current-state figure is objectui#7848's live-margin measurement, which this dispatch fences off to a sibling dev running in the same batch and its own worktree, so I did not build apps/console to take it. PER_CHUNK_GZIP_CEILINGS and PER_CHUNK_BASELINE were not touched, read, or moved."
  },

  "tests": "Instrument, fresh tree: `pnpm check:i18n-dead-keys` exit 0 (captured before any pipe), verdict line quoted above; `node scripts/check-i18n-dead-keys.mjs --json` exit 0, confirmed array length 127. Ablation legs, on the mutated tree: `pnpm --filter @object-ui/i18n test` exit 0, 63/63 files 1090/1090 tests passed; `pnpm exec vitest run --root . packages/app-shell/src/views/__tests__/SearchResultsPage` exit 0, 1/1 file 1/1 test passed; `node scripts/check-i18n-dead-keys.mjs` exit 0 reporting 119 CONFIRMED. Restore verified byte-identical against HEAD for all ten packs (hash-object vs rev-parse HEAD:<path>, then git diff HEAD empty). No lint, typecheck or build was run: there is no diff to check.",

  "mcp_calls": "3 — issue get, issue get_comments, and this report comment. No search_issues call was needed: no new issue was filed, see open_questions.",

  "open_questions": [
    {
      "question": "Fork 1 — the admission criterion is measurably unsound on this tree. CONFIRMED just produced 8 false positives out of 127 (6.3%), all of them rendering today on a shipped screen, and the ruling's own facet 3 mitigation named that predicate as the control against exactly this failure. How should the population be re-derived?",
      "options": [
        "A — Retire nothing under this criterion; re-file the card so the admission criterion is 'CONFIRMED and hand-read', with the computed-key sweep as a required per-key step, and let the seat that owns the instrument decide whether the residual is closeable.",
        "B — Keep route A but subtract a hand-read exclusion list (starting with the 8 search keys) and proceed with the remainder in this PR.",
        "C — Narrow the card to the 25 keys it was originally filed for (two families), which are individually hand-read in PR objectui#8753's body, and drop the expansion to 127."
      ],
      "recommendation": "A. The 8 keys are not the finding; the finding is that a syntactic tier was promoted to a delete list, and the tier's own header records a previous instance of exactly that costing 33 keys and nine locales. Subtracting the instances I happened to find (option B) keeps the unsound criterion and banks on my sweep being exhaustive — it is not: it is exhaustive for template-built and concatenation-built keys, which is a strictly smaller class than 'computed'. Option C is the honest fallback if the byte pressure from objectui#8816 needs relief this week, because those 25 have per-key human readings on the record; but note it still splits both of its families (see family_analysis) and so needs the fork-2 answer regardless."
    },
    {
      "question": "Fork 2 — 'family by family' and 'CONFIRMED only' cannot both hold: zero of the 18 affected families is wholly CONFIRMED, and both families this card names by hand split on exactly one NEEDS-REVIEW member each (approvals.rejectConfirm, held out by a CHANGELOG line; marketplace.pricing.freemium, held out by a test-file line). Which clause yields?",
      "options": [
        "A — The family unit yields: retire the CONFIRMED members only and accept a half-retired family, which is precisely the outcome the card's 'Why this card is 25 keys and not 13' section argues against.",
        "B — The admission criterion yields for the specific single-hit holdouts: admit approvals.rejectConfirm and marketplace.pricing.freemium after reading their one hit each, because a CHANGELOG entry and a test line are not liveness arguments — the instrument's own header says of a neighbouring case that 'a CHANGELOG is not a liveness argument'.",
        "C — Neither yields: retire nothing until the director seat restates the unit, e.g. as 'a family is whole when every member is CONFIRMED or is a NEEDS-REVIEW whose only hits are non-liveness (CHANGELOG, docs, pin tests)'."
      ],
      "recommendation": "B for these two families specifically, and C as the general rule. B is a one-line reading per family, not a judgement call: each holdout has exactly ONE hit and neither hit is a consumer. But writing that reading into a general criterion is the director seat's act, not mine — the dispatch is explicit that I do not split a family on my own judgement."
    },
    {
      "question": "Fork 3 — should the reachability gap and the stale importer list be filed as issues?",
      "options": [
        "A — File nothing; both are recorded here and the instrument is fenced off from me anyway.",
        "B — PM files two cards: (i) the eight search keys are unreachable to both legs AND unpinned, so add a pin that catches variable-assigned template keys, or teach the key-builder leg to follow one-hop variable assignment; (ii) the instrument header's enumerated non-test importer list is stale — packages/react/src/utils/nonGridRowCeiling.tsx is a fifth importer it does not name (this is objectui#8752's subject)."
      ],
      "recommendation": "B, filed by the PM seat. I did not file them myself: the dispatch fences off any change to check-i18n-dead-keys, and filing a card that proposes widening what it confirms is close enough to that fence that it should be the PM's act, not a dev's side effect. The measurements both cards need are in this report."
    }
  ],

  "out_of_scope_findings": [
    "NOT FILED, handed to the PM seat instead (see open_questions fork 3): packages/react/src/utils/nonGridRowCeiling.tsx is a NON-TEST @object-ui/i18n pack-object importer that the check-i18n-dead-keys header's enumerated importer list does not name — the header still says four. It reads en.common.rowCeilingNote and en.common.rowCeilingNoteUnknownTotal, so it changes no verdict in this run, but it is the live instance of the staleness objectui#8752 is about.",
    "NOT FILED, handed to the PM seat instead: no test anywhere in the repo pins the eight search keys. Deleting them from all ten packs leaves 1090/1090 i18n tests and the SearchResultsPage suite green — measured, see ablation."
  ],

  "fences_respected": "The 237 NEEDS-REVIEW keys were read but never edited. No budget constant was touched: PER_CHUNK_GZIP_CEILINGS and PER_CHUNK_BASELINE were not opened. scripts/check-i18n-dead-keys.mjs was read only, never modified. content/docs/releases/ was not touched. objectui#7848's measurement was not run. No Claim comment was posted and the assignee field was not written. All work happened in the dedicated worktree /home/user/objectui-issue-8754; the shared checkout /home/user/objectui was never edited and no git stash was used.",

  "branch_state_note": "claude/issue-8754-retire-dead-pack-keys exists on origin at the base commit with no commits on it — it was pushed empty as the routing probe before any edit, per the dispatch. Remote ref deletion is refused by the agent proxy in this repo, so it is left in place rather than cleaned up; it holds no content and can be reused if this card is re-dispatched."
}

---

Generated by Claude Code

[claude]

⛔ STOPPED with zero implementation — the ruling's admission criterion is unsound on this tree

domain:devx @ objectui PM seat (session_01FhBNJcLRZLe8M87VcUgpKr), 2026-09-10T11:09Z. Dev report at 5617690749. No PR, no commits, nothing deleted. The card returns to the decision box; ⛔ this seat does not re-rule it.

The decisive finding, verified by this seat rather than accepted

origin/main = 72bcd7783, tip committed 2026-09-10T10:13:32Z, read 11:08Z:

• packages/app-shell/src/views/SearchResultsPage.tsx builds two i18n keys into local variables — `search.type${…}s` at line 292 and `search.badge${…}` at line 305 — and passes each to t() at 297 and 320, with ⛔ no defaultValue.
• The type field is a closed union in the same file: 'object' | 'dashboard' | 'page' | 'report'.
• ⇒ the runtime targets are exactly eight keys, and all eight are in the pack: search.type{Objects,Dashboards,Pages,Reports} and search.badge{Object,Dashboard,Page,Report} — one hit each in the en pack. Controls: search returns 38 hits in that file, a nonsense token returns 0.
• ⇒ all eight are in the CONFIRMED list this ruling authorises deleting, and they render on a shipping screen today. Deleting them shows raw key names in ten locales, ⛔ with no error.

Both of the instrument's legs are blind to this shape at once — the AST leg reads only a call's own argument, and the text leg sees only the heads search.type / search.badge. ⚠️ The instrument's own header predicts exactly this: it is classes 2 and 4 of its 「What CONFIRMED does NOT guarantee」, and it records a prior instance that cost 33 keys across nine locales.

⭐ The finding that outlives the eight keys

The dev ablated it: deleted those eight from all ten packs and ran everything. 1090/1090 i18n tests passed. The SearchResultsPage suite passed. The instrument reported 119 CONFIRMED without complaint. Nothing turned red. Restore verified byte-identical against HEAD for all ten packs.

⇒ green CI on the ruled pull request would have been worth nothing on this class. That is not an argument about these eight keys; it is the reason the next attempt needs an instrument before it needs a decision.

The second, independent blocker

「整族为单位」 and 「只删 CONFIRMED」 are jointly unsatisfiable on this tree: zero of the 18 affected top-level families is wholly CONFIRMED — including both this card names by hand. approvals is 5 of 6 (holdout approvals.rejectConfirm); marketplace.pricing is 5 of 6 (holdout marketplace.pricing.freemium) — ⭐ exactly the holdout this card predicted when it was filed. Executing as ruled would require splitting every family on a dev's own judgement, which the dispatch forbids and the card argues against.

What the measurement did confirm

The population re-ran to exactly 127 CONFIRMED / 237 NEEDS-REVIEW (pnpm check:i18n-dead-keys, exit 0 captured before any pipe) — the ruling's figure is right. ⇒ ⛔ the count was never the problem; the criterion is.

⭐ The dev's computed-key sweep was not a spot check: 578 template-literal heads enumerated repo-wide (⛔ not only those inside a t() argument), zero concatenation-built keys, the one repo-wide key-builder helper hand-read and cleared, all five non-test pack importers hand-read, and the dynamic-namespace route proven empty before and after.

⚠️ One constraint for whoever executes a future version: packages/i18n/src/__tests__/objectView-config-keys-retired-4730.test.ts asserts exact key counts, so retiring anything under console.objectView reds it until updated in the same pull request.

⛔ Fences held

⛔ No NEEDS-REVIEW key touched · ⛔ no budget constant read or moved · ⛔ the instrument not modified · ⛔ content/docs/releases/** untouched · the ablation was restored and proven byte-identical.

Release: session session_01FhBNJcLRZLe8M87VcUgpKr · cause premise falsified (the ruling's admission criterion admits eight keys that render today) · destination the decision box. Assignee cleared and pm:dispatched → needs-user-decision in the same write.

---

维护者速读

事情：您上午裁的 A 是「把 check:i18n-dead-keys 判定 CONFIRMED 的 127 个键一次删掉」。真去做的时候实测发现：其中 8 个今天还在屏幕上显示。搜索结果页把键名拼出来再去查（search.type + 类型名），而那个查死键的工具只看得懂「直接写死的键」，看不懂拼出来的 —— 工具自己的说明书里就写着它有这个盲区，还记着上一次因此误删了 33 个键、影响九个语言包。删了会怎样：用户在搜索页看到 search.typeObjects 这样的原始键名而不是「对象」，十个语言包都一样，不报错。

⚠️ 更要紧的一条：我们做了消融验证 —— 把这 8 个键删掉跑全部测试，1090 个测试全绿，什么都没红。也就是说这一类问题上，「CI 是绿的」这件事不提供任何保证。

还有第二个拦路的：您裁的是「整族为单位删」，但受影响的 18 个族里没有一个是整族都被判死的 —— 连这张卡自己手点的两个族都不是（各 5/6）。两条要求同时满足不了。

选项

• A（本席推荐）：这一批不删。先补一道能看懂「拼出来的键」的检查（或要求逐键人工过目），再重新取清单。⇒ 慢一步，但下一次的绿是真的绿。
• B：仍按 CONFIRMED 删，但减去一份人工排除清单（先放这 8 个）。⇒ 赌本次普查已穷尽；它对「模板拼接」是穷尽的，对「计算出来的键」这个更大的类不是。
• C：只删本卡原来的 25 个 —— 那 25 个在 PR objectui#8753 里有逐键的人工读数。⇒ 最小、今天就能做，但仍要先回答上面那个「整族」的问题。

风险与回滚：任何一条删除路线的失败方向都是「界面显示键名、不报错」；回滚 = 把键加回去，一次 revert。
你要做的：回一个字母，A / B / C。

• ① 项目长远合理性：根因不是这 8 个键,是把一个句法层当成了删除清单。工具头部自己把这个盲区分了类、还记着上一次的代价。补上可达性判据(或人工过目)是一次性投入,之后每一轮清扫都便宜。
• ② 实际业务拉动：objectui#8816 的字节压力是真的(一周抬一次线),但这一批今天买不到安全的字节 —— 8/127 = 6.3% 的误判率落在一块用户天天看的屏幕上。
• ③ 防 AI 犯错：⭐ 消融证明删掉 8 个活键零测试变红。⇒ 这一类里「CI 绿」= 零信息,而 agent 席最容易把它读成许可。先有 pin,再有删除。
• ④ 创业阶段不扩散：A 是一次付清且不设窗口;C 是最小步;B 看着最快,但它把安全性押在一次普查的穷尽性上,而那正是本轮被证伪的那种自信。
  推荐 A,回退 C。置信缺口:仓外消费者对这些键的引用无法从本仓测量,这一点三条路线都一样。

---

Generated by Claude Code