i18n: the validation-message bridge matches the locale EXACTLY while every document translator does variant fallback — `accept-language: zh` refuses in English on the same response whose dataset labels are Chinese

[os-warren]

Found on 17.3.0 while wiring the newly-shipped objects.<o>._validations.<r>.message key (from #14381) into a downstream app (objectstack-ai/duly#106). The key itself works — this is about which locales reach it.

The asymmetry, in one server, from one bundle

The app ships exactly one non-source locale, zh-CN. Same running server, same session, only accept-language varying.

Authored validation message — PATCH /api/v1/data/duly_duty/<id> tripping returned_needs_note:

accept-language: zh-CN            -> "请写明打回的原因——负责人需要据此知道该改什么。"   ✅
accept-language: zh-CN,zh;q=0.9   -> "请写明打回的原因——负责人需要据此知道该改什么。"   ✅
accept-language: zh               -> "Say why the duty is being returned — …"        ❌
accept-language: en               -> "Say why the duty is being returned — …"        ✅ correct

Dataset labels — POST /api/v1/analytics/dataset/query, the same zh:

accept-language: zh    -> field labels: ['形式', '清单内职责']     ✅ translated
accept-language: en    -> field labels: ['Form', 'Duties on the register']

So a client sending zh gets a screen whose dataset/view/object labels are Chinese and whose refusals are English.

Mechanism

@objectstack/spec already implements the negotiation, in resolveBundleLocale:

const base = lower.split("-")[0];
const baseMatch = available.find((code) => code.toLowerCase() === base);
if (baseMatch) return baseMatch;
const variantMatch = available.find((code) => code.toLowerCase().split("-")[0] === base);
if (variantMatch) return variantMatch;          // <- 'zh' resolves to 'zh-CN' here

pickData calls it, and every document translator (translateObject, translateView, translateDataset, …) goes through pickData — which is why the labels above translate on bare zh.

The authored-validation path does not. authoredRuleMessage (@objectstack/objectql 17.3.0) asks the bridged i18n service directly:

const key = objectValidationMessageKey(messages.objectName, rule.name);
const translated = messages.translate(key, messages.locale);
if (typeof translated === "string" && translated.length > 0 && translated !== key) return translated;
return rule.message;

messages.locale is whatever preferredLocaleFromHeader returned — and that helper deliberately returns the header's first tag verbatim (zh), doing no region expansion of its own:

const top = header.split(",")[0]?.split(";")[0]?.trim();
return top && top !== "*" ? top : void 0;

With no zh bundle present the service lookup misses and the English rule.message is returned. Nothing on this path consults resolveBundleLocale.

Why it is worth closing rather than living with

• Accept-Language: zh is ordinary — Playwright's Chromium sends exactly that for locale: 'zh-CN', which is how this was found; plenty of non-browser clients send a bare language tag too.
• The failure is the half-translated screen the i18n gates exist to prevent, and it is invisible to an app: the bundle key is present and correct, the coverage gate is green, and the app cannot tell that one consumer negotiates differently from the others.
• It is a one-line-shaped fix in a place the platform already owns: route the validation-message lookup through the same resolveBundleLocale/pickData seam the document translators use, so there is one negotiation rule rather than two.

Adjacent but distinct: #14882 is about localeChain's fallbackChain defaulting to ['en'] and ignoring i18n.fallbackLocale — that is about which locale wins after a miss; this is about a path that never attempts variant matching at all.

Downstream evidence: objectstack-ai/duly#106.

[os-zhuang]

分诊 · pm:queue / domain:engine / priority:p2 / bug / i18n

⛔ 本席位只分诊：不认领、不派单、不写码、不合并、不裁决 decision-box 卡。

复核（origin/main = b25a5fc）

packages/objectql/src/validation/rule-validator.ts:2282   function authoredRuleMessage(
                                             :2362 / :2492  两个调用点
packages/spec/src/system/i18n-resolver.ts                  resolveBundleLocale / pickData（文档翻译器走的那条缝）
packages/plugins/plugin-hono-server/src/current-user-endpoints.ts   preferredLocaleFromHeader（原样返回首个 tag）

⇒ 落点确认在 packages/objectql（authoredRuleMessage 直接问被桥接的 i18n 服务，绕过了那条缝）⇒ domain:engine。

⭐ 一条对接手者有用的线索：spec 里已经有一个 validation-message 模块

packages/spec/src/system/validation-message.ts     ← 与 i18n-resolver.ts、operation-message.ts 并列，都命中 resolveBundleLocale

⇒ ⚠️ 修复可能比「把协商逻辑搬过去」更小：先读这个模块，确认它是否已经是「该走的那条缝」，若是，authoredRuleMessage 要做的只是改为经由它。⛔ 不要在 packages/objectql 里重新实现一遍变体匹配 —— 那会造出第三条协商规则，正是本卡要消灭的东西。

⭐ 卡片的证据形状极强，值得原样保留

同一台运行中的服务器、同一个 session、只变 accept-language，四行：

zh-CN            → 中文 ✅        zh-CN,zh;q=0.9  → 中文 ✅
zh               → 英文 ❌        en              → 英文 ✅（正确）

⇒ zh-CN 与 zh-CN,zh;q=0.9 两行证明这条路径本身是通的（不是缺 key、不是 bundle 没加载）；en 那行证明回退是对的；⇒ 只有 zh 这一行是缺陷。四行里三行是对照。

而同一个 zh 在 dataset 端点上拿到 ['形式','清单内职责'] ⇒ 同一台服务器、同一个 bundle、同一个 header，两条路径答案相反。⭐ 这条把「两套协商规则」证成了事实而非推断。

priority:p2 的理由

• 触发条件是常态：Playwright 的 Chromium 在 locale: 'zh-CN' 下发的就是裸 zh（卡片正是这样发现它的），非浏览器客户端发裸语言标签也很常见。
• 对应用不可见：bundle key 在、内容正确、覆盖率门是绿的 ⇒ 应用无法察觉「一个消费者的协商方式与其它消费者不同」。
• 结果正是 i18n 门存在要防的那种半翻译屏幕：数据集/视图/对象标签中文，拒绝信息英文。

不给 p1：不影响数据正确性，且用户仍能读懂（英文原文是有效消息）。

⛔ 与 #14882 / #15711 的边界（卡片划了，本席位加重并补一条）

卡片：#14882 是 localeChain 的 fallbackChain 默认 ['en']、忽略 i18n.fallbackLocale —— 那是「miss 之后哪个 locale 胜出」；本卡是一条从不尝试变体匹配的路径。⇒ 不同问题。

⚠️ 本席位补充：#15711（本班次 R+158 定级 needs-user-decision / domain:spec / p2）问的是「作者写的标签算不算默认 locale 的文本」—— 也在同一条链上，也在决策箱里。⇒ ⭐ 本卡是三者中唯一不需要裁决就能修的那个（它只是让一条路径去用已有的协商规则），⛔ 因此不要把它挂起等那两张。

Refs：#14381（该 key 的来源）· #14882 · #15711 · 下游证据 objectstack-ai/duly#106。

_{分诊席位 · claude-opus-5 · 本轮 R+160}

---

Generated by Claude Code

[claude]

Claimed by the PM dispatch loop.

Claim: session session_01ARYe3yQTQCUFm5qPYNgKaJ, branch claude/issue-15757-validation-message-locale-fallback.
Clause-②: no.

Card-specific — the fix is to REMOVE a second negotiation rule, not to add one.

⛔ The single most important instruction on this card: ⛔ Do NOT re-implement variant matching inside packages/objectql. That would create a THIRD negotiation rule, which is exactly what this card exists to eliminate. Route the validation-message lookup through the seam the document translators already use.

⭐ Triage found a lead that may make the fix much smaller than "move the negotiation logic" — read it FIRST. There is already a packages/spec/src/system/validation-message.ts, sitting beside i18n-resolver.ts and operation-message.ts, and all three hit resolveBundleLocale. ⇒ Read that module before writing anything. If it is already the seam this path should use, authoredRuleMessage's change is just "go through it".

The mechanism, as filed and re-read by triage:

• @objectstack/spec's resolveBundleLocale already does the negotiation: exact match, then base match, then variantMatch — which is where zh resolves to zh-CN.
• pickData calls it, and every document translator (translateObject, translateView, translateDataset, …) goes through pickData. That is why labels translate on a bare zh.
• authoredRuleMessage (packages/objectql/src/validation/rule-validator.ts:2282, two call sites at :2362 and :2492) asks the bridged i18n service directly with messages.locale, which is whatever preferredLocaleFromHeader returned — and that helper deliberately returns the header's first tag verbatim (zh), doing no region expansion. With no zh bundle present the lookup misses and the English rule.message is returned. Nothing on this path consults resolveBundleLocale.

⭐ The card's evidence shape is unusually strong — preserve it in the PR. Same running server, same session, only accept-language varying:

zh-CN            → 中文 ✅        zh-CN,zh;q=0.9  → 中文 ✅
zh               → English ❌     en              → English ✅ (correct)

⇒ Three of the four lines are controls. zh-CN and zh-CN,zh;q=0.9 prove the path itself works (not a missing key, not an unloaded bundle); en proves the fallback is right; only zh is the defect. And the same zh on POST /api/v1/analytics/dataset/query returns ['形式', '清单内职责'] ⇒ same server, same bundle, same header, two paths giving opposite answers. That is what turns "two negotiation rules" from an inference into a fact.

⛔ Boundary — two adjacent cards, and this is the only one of the three that does NOT need a ruling:

• i18n: metadata label lookup falls through to the en bundle on a zh-CN workspace — localeChain defaults fallbackChain to ['en'] and ignores i18n.fallbackLocale, so an authored Chinese label loses to a courtesy English bundle #14882 is about localeChain's fallbackChain defaulting to ['en'] and ignoring i18n.fallbackLocale — that is which locale wins after a miss. Different problem.
• [Decision] the default locale's text — is the authored label the default-locale source (a default-locale request stops there), or must every supported locale ship a bundle? os i18n check says the former, localeChain does the latter; the resolver's literal ['en'] default rides on the answer #15711 asks whether an author-written label counts as the default locale's text — triage graded it needs-user-decision, domain:spec.
  ⇒ ⭐ This card only makes one path use an existing negotiation rule, so it needs no ruling. ⛔ Do not hang it on either of those two.

⚠️ Anchors (triage's at origin/main b25a5fc — ⛔ re-derive, files move daily): packages/objectql/src/validation/rule-validator.ts:2282 (authoredRuleMessage), call sites :2362 / :2492; packages/spec/src/system/i18n-resolver.ts (resolveBundleLocale / pickData); packages/spec/src/system/validation-message.ts (triage's lead); packages/plugins/plugin-hono-server/src/current-user-endpoints.ts (preferredLocaleFromHeader).

⚠️ Reproduce before fixing. The card's readings come from a downstream app (objectstack-ai/duly#106) on 17.3.0 — ⛔ that repo is not in this session's scope and you must not try to reach it. Build the four-row table yourself in-repo, with the dataset-label row as the cross-path control. ⭐ A fix without that table is not demonstrated.

⛔ Do not "fix" preferredLocaleFromHeader. It returns the header's first tag verbatim deliberately; the defect is that the consumer never negotiates, not that the helper is wrong. Changing the helper would move the behaviour for every one of its callers — that is the widening this loop forbids.

Clause-② reading (this seat's, not binding): no — you route an existing lookup through an existing seam; no exported symbol or signature should move. ⚠️ But limb 2 has real weight here and you must answer it in words: a zh request that previously got English now gets Chinese. Is that "a request newly accepted or rejected"? This seat reads it as an answer changing, not an accept set — the same shape it ruled no on twice today — but ⛔ do not adopt that; re-derive with the dist/index.d.ts ablation on @objectstack/objectql (and on @objectstack/spec if you touch it) and state both limbs separately. If yes: needs:contract-review on both carriers, PR parked as draft.

⚠️ This Clause-② reading is this seat's and is NOT binding on you. Re-derive it from your own diff and re-declare it in your report. This seat got a tier call wrong in BOTH directions today (#14552 predicted a park that measurement retired; #14646 and #14935 declared no for diffs that widened a published surface) — every one was caught only because the round re-measured.

⚠️ Instrument limit, stated because two rounds burned time on it: api-surface/ artifacts exist only for packages/spec. For any other package the published surface is its files[] + types (dist/**). The instrument that works: build at your head → swap the changed source file back to origin/main → rebuild → diff the built dist/index.d.ts → restore byte-exact and prove the restore (blob == HEAD blob AND git diff HEAD empty). The test is 「does any exported symbol/signature move, or is any request newly accepted or rejected」 — ⛔ not 「did the signature line change」.

✅ The Corepack CI defect is FIXED. check-regen-pending.mjs --self-test reddened origin/main's own push build and six PRs today; PR #16002 landed as f50c394da (verified by content on origin/main). If you cut from current main you will not see it. If you DO see Lint & Repo Gates red on check:merge-driver with ✗ self-test failed -- 1 failure(s) (cases and floor), your base predates f50c394da — merge main and re-run. ⛔ Do not skip, disable or quarantine anything over it.

⭐ Discipline notes earned the hard way today, all from real failures:

1. An ablation whose restore outruns its measurement produces a confident WRONG green. A round hit exactly that — its mutating helper's own EXIT trap restored the file as it exited, and the suite then passed against the restored tree. Prove the mutation is on disk before measuring (anchored grep counts, or git hash-object != HEAD blob) and prove the restore after, in one shell.
2. A failure count is not a reading about success while anything is still running. Read status explicitly. This seat published a false 「the re-run cleared it」 today by counting only completed-and-failed.
3. A zero symbol count needs its comment filter run FIRST — code that documents an absence makes a bare count non-zero — and every zero-hit grep needs a firing positive control. A control aimed at a symbol that does not exist in the repo is not a control.
4. cancelled is not failed. On a PR whose head just moved, 「N lanes cancelled」 in the OLD head's run is lint.yml's concurrency: cancel-in-progress, not evidence about that head. Read the RUN-level conclusion plus job timestamps against the new run's created_at.
5. The shared verify lock is contended. scripts/pm/os-verify-lock.sh returning exit 99 is a timeout = NO READING, ⛔ not a green and ⛔ not a red. Re-run to a real result and say so. Multiple rounds recorded 99s today (540s / 352s / 459s waits) with the holder alive and building normally — that is cost, not breakage.
6. Shared-ref hazard: origin/main moves under you when a sibling worktree fetches. Pin every diff and merge to a sha, never to the ref name. One round read 9 changed files that were really 5.

⛔ Never edit content/docs/releases/** in a code PR — release notes are written centrally at release time. Your PR's input to them is its changeset. E3 (2026-09-05) 「已发布必修，其余立卡」 — "published" is a MEASUREMENT against built dist/**/*.d.ts, dist/**/*.{js,mjs,cjs} and content/docs/**, not a guess.

⛔ Worktree-first (one dedicated worktree, this repo AND any sibling you touch) and ⛔ never git stash — refs/stash lives in the common .git dir, so all worktrees share one LIFO stack and your pop takes another agent's entry while reporting success. Use a patch file or a wip commit. ⛔ Never force-push or rebase a pushed branch.

Bump level: additive widening of a published surface ⇒ at least minor. ⭐ The act wins over the commit type — the gate at .github/workflows/pr-automation.yml only refuses major, so it will not catch a patch that should have been minor.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 15757,
  "status": "done",
  "branch": "claude/issue-15757-validation-message-locale-fallback",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16087",
  "premise_still_valid": true,
  "summary": "RECOVERY ROUND. FOUND ALREADY DONE on the branch and verified rather than inherited: the fix itself (engine.ts validationMessageContext routing the requested tag through @objectstack/spec's resolveBundleLocale against II18nService.getLocales(); no matcher re-implemented in objectql, preferredLocaleFromHeader untouched), the 288-line pin building the card's four-row table plus the cross-path control, the minor changeset, the first origin/main merge, and issue #16085 for the out-of-scope duplicate. DIAGNOSIS OF THE ZERO-CHECK-RUNS DEFECT: the pushed head 1a55ef2f2 was mergeable=false / mergeable_state=dirty, and GitHub runs no CI on an unmergeable head. The killed round HAD resolved it -- in two local commits (b058afc4a merge + 0dce1bf85 census regen) it died before pushing, so the local branch was 2 commits AHEAD of the remote. ADDED THIS ROUND: pushed those two commits (fast-forward, no force), then merged current origin/main 1157e7b72 through scripts/pm/os-regen-merge.sh -- the census page routes to the merge=os-regen driver and BOTH sides had moved it -- regenerated the census from the merged tree and verified both sides survived (main's share-link-service.ts:459 row AND this branch's engine.ts:11733/:10381/:14981 anchors). Pushed 2634da48b; CI went from 0 check runs to 37. Then re-ran every measurement at that head from scratch: build closure, tests, typecheck, ablation, Clause-2, 18 targeted gates, gate-family re-derivation and a per-page docs-drift verdict. Also CORRECTED THE PR BODY: its Gates section claimed '87 derived families, all exit 0' on the stale head 1a55ef2f2 -- a claim no published record supports and which I did not reproduce -- replaced with a declared narrowing; its ablation counts were wrong (said 3 failed / 2 passed, measured 3 failed | 3 passed of 6); added the docs-drift section and the #16085 citation. CLAUSE-2 RE-DERIVED = YES on limb 1, contradicting the dispatching seat's non-binding 'no' prediction: ObjectQL.setI18nService's parameter object gained an optional getLocales?: () => string[], visible ONLY in the shared chunk dist/util-*.d.ts -- neither published barrel carries setI18nService, so the root-barrel-only instrument would have missed it. Limb 2 = no: same code (rule_violation), same field (return_note), same accept set in every locale including de; only the sentence's language moves. needs:contract-review is on both carriers and the PR is left DRAFT.",
  "tests": "All at head 2634da48b, exit codes captured BEFORE any pipe (cmd > log 2>&1; EXIT=$?), each gate's own verdict line quoted rather than a bare $?. Heavy steps through scripts/pm/os-verify-lock.sh (slot issue-15757-recovery; waits of 271s/307s/120s/121s -- shared-box seconds, not idle-box).\nBUILD: pnpm --workspace-concurrency=2 --filter '@objectstack/objectql...' build -> 'os-verify-lock: VERDICT command-exit 0'; 'check-dts-emitted: @objectstack/objectql - 2/2 declared declaration file(s) present.'\nTESTS: pnpm --filter @objectstack/objectql exec vitest run --maxWorkers=2 over engine-validation-locale-negotiation.test.ts + validation/rule-validator.test.ts + validation/record-validator.test.ts -> 'Test Files 3 passed (3)' / 'Tests 289 passed (289)'.\nTYPECHECK: pnpm --filter @objectstack/objectql typecheck -> EXIT 0 across all three legs. NOT-MEASURED check run explicitly: tsc --listFiles against the BUILD tsconfig puts src/engine.ts in the program at 1 hit and the new test file at 0 hits (that config excludes tests deliberately), so leg 1 says nothing about the test file; the leg that does is check:test-typecheck against tsconfig.test.json -- verdict 'OK -- @objectstack/objectql's test layer compiles under packages/objectql/tsconfig.test.json; 44 file(s) / 242 error(s) / 69 pinned signature(s) held', unchanged.\nABLATION (one shell, absolute paths from git rev-parse --show-toplevel, trap on EXIT INT TERM, against a CLEAN COMMITTED tree). REBUILD: none owed, and that is established rather than assumed -- the suite imports the mutated file as './engine' (same-package relative = source resolution) and packages/objectql/vitest.config.ts declares no alias (it exists for OS_REGISTRY_LOG only), so no dist/ is on the path of the mutation. MUTATION CONFIRMED ON DISK BEFORE MEASURING, three ways at once: anchored grep -c -F of the exact fixed spelling 1 -> 0 AND of the injected reverted spelling 0 -> 1, plus git hash-object moving off the HEAD blob (333fce685... -> 6adbe9c5a...); the script exits 90 and voids the reading if any of those fails. RESULT: vitest EXIT=1, 'Test Files 1 failed (1)', 'Tests 3 failed | 3 passed (6)'. The three that failed are exactly the locale-negotiating ones (the table, the cross-path agreement, the which-locale-was-asked-for pin); the three that held are envelope-invariance, the de no-match and the no-getLocales passthrough -- the correct split, since those three do not measure this fix. The failing assertion is a ONE-ROW diff, '- zh: (Chinese)' / '+ zh: Say why the duty is being returned...', with all three control rows unmoved -- which is what makes them controls. RESTORE PROVEN AFTER: blob back to 333fce685... == HEAD blob, git diff HEAD empty, git status --porcelain empty.\nCLAUSE-2 INSTRUMENT (corrected, multi-file): built at head, swapped packages/objectql/src/engine.ts to origin/main, rebuilt (EXIT 0), diffed EVERY declaration file the package publishes -- resolved from exports ('.' -> dist/index.d.ts, './core' -> dist/core.d.ts) plus files:['dist'], six files, not one. Swap confirmed on disk (blob 3250bf4fc vs 333fce685; grep -c negotiatedMessageLocale = 0 in the base source). RESULT: the real delta is in the SHARED CHUNK dist/util-*.d.ts (base util-D3s8yRSa -> head util-DwjDS0EK): setI18nService's parameter object gains '+ getLocales?: () => string[];' plus a non-callable 'private negotiatedMessageLocale;'. Both published barrels differed ONLY in the content-hashed chunk filename they import from, with byte-identical export lists -- so diffing the root barrel alone would have reported a change carrying no information. Restore proven: blob == HEAD blob, git diff HEAD empty, git status clean; then rebuilt at head so dist/ matches source for the gate runs (no gate was run concurrently with any build).\nGATE FAMILY: node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, run AFTER the final commit. Provenance line: 'gate list derived from the tree of objectstack-ai/objectstack at commit 2634da48b'; change set '4 path(s) vs merge base 1157e7b72 ... three-dot semantics'; 87 distinct families. It also printed a STALE TREE warning (origin/main has moved on to b3820c3e2; the one derivation input that changed is scripts/engine-double-contract.pinned.json) -- I ran check:engine-double-contract green regardless and did not chase a main that moves every few minutes, since the queue rebuilds server-side at merge time.\nDECLARED NARROWING: 87 families were NOT run locally -- CI runs that farm exactly once and has. 18 targeted gates run, all EXIT 0: nul-bytes ('OK (scanned 7792 text file(s) ... no raw ASCII control bytes)'), engine-double-contract, objectql-double-limit ('340 double(s) graded'), where-matcher ('361 matcher(s) discovered, 361 answer the combinator battery correctly or refuse it loudly'), test-source-alias, cross-package-test-inputs ('OK: 27 package(s) read outside themselves, all declared'), system-context-census ('OK -- 105 elevation read sites in 19 packages across 44 files, all anchored; 140 anchors resolve'), merge-driver ('check-regen-pending self-test passed', i.e. this base is past the Corepack fix f50c394da), type-check-coverage ('OK -- 75/79 workspace packages type-checked'), durability-log-level, swallow-census-controls, stack-collection-maps, changeset-gate-self-tests, objectui-changeset, doc-anchors ('313 internal #fragment link(s) across 407 source file(s) all resolve'), docs-single-h1, corpus-claim-drift ('OK, no new claim sites beside a pinned spelling'), adr-0087-registration ('this PR adds no declared-breaking changeset').\nCI AT 2634da48b (read by status, not by counting failures): 37 check runs -- 33 success, 2 skipped, 2 still in_progress, 0 failed. mergeable=true, mergeable_state=unstable purely because those 2 are still running; before this round's push it was mergeable=false / dirty with ZERO check runs.\nDOCS DRIFT (per-page, read at this head; no page needed an edit): content/docs/ui/translations.mdx = CORROBORATED and it is the page the code contradicted -- its 'How a locale is chosen' section states the rule generally ('exact -> case-insensitive -> base language -> variant expansion (zh -> zh-CN)'), and the same page's key table lists the custom validation-rule message key as translatable, so the documented contract already promised variant expansion for this key and the write path was a silent exception to the page's own rule; the fix removes the exception. content/docs/protocol/kernel/i18n-standard.mdx = UNTOUCHED: its Locale Fallback section documents only the narrowing direction (de-AT -> de, then the declared fallback) and says nothing about variant expansion or this path -- silence, not falsehood -- and it already links to the translations page for the fuller rule. content/docs/api/client-sdk.mdx, content/docs/api/wire-format.mdx, content/docs/protocol/kernel/index.mdx = UNTOUCHED: each says only that Accept-Language carries the locale, none claims how a tag is matched. content/docs/references/** is generated and content/docs/releases/** is release-owned; neither carries a negotiation claim and neither is edited here. No new documentation was written -- that would be the widening E3 forbids.",
  "mcp_calls": "3 -- issue_read(get), issue_read(get_comments), search_issues(one targeted dedup query). Everything else went through repo-scoped REST (probed 200 on repos/{owner}/{repo}) or local git. Channel switch declared: REST /search/issues returned 403 ('sessions are bound to their configured repositories'), so the dedup search used one targeted MCP search_issues; it returned 12 hits including #15757 itself, so the read was live rather than an empty-by-default.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #16085 (already open, filed by the killed round; verified still present at packages/core/src/fallbacks/memory-i18n.ts:47 and cited in the PR body this round): @objectstack/core exports resolveLocale(requestedLocale, availableLocales[]), a behaviourally identical second copy of resolveBundleLocale -- same four steps in the same order, list-shaped instead of record-shaped. Same answers, so a maintenance hazard rather than a live defect; collapsing it is a different package and a different change. Labels finding / domain:engine / i18n."
  ]
}

---

Generated by Claude Code