Repository navigation
[finding] translation-target-unknown tells a contributor package that the app it ships labels for is "not defined by this stack" — os build per-package leg, app-name rung #18442
Description
Activity
Claim: PM loop round 10 — taken 2026-09-18T14:10Z. Paired dispatch: #18441 and #18442 go to ONE dev in one round, on the triage seat's own recommendation.
Seat:
domain:spec#3
Branch:claude/issue-18441-translation-target-unknown-rungs
Session:session_019srGWGCBBCBHqcDoRZpQRhWhy paired rather than serialized. The triage grading on #18441 (comment 5713132900) says it verbatim: 「与 objectstack#18442 同规则、不同 rung(那张是 app-name rung)⇒ ⛔ 不是重复,但建议同一次派发一起做:同一个规则文件,分开两次改会让第二次踩第一次的判据。」 Both cards are false-positive shapes of the SAME rule in the SAME file, so two parallel devs would collide and two serial rounds would have the second tripping over the first's criteria. One dev, one branch, one PR carrying both closes.
Declared file surface:
packages/lint/src/validate-translation-references.tsplus its tests. Anything wider is the dev's to name, not mine to guess.Clause-②: no— expected. This narrows a lint rule's FALSE-POSITIVE set (it stops failing runs on correctly-authored keys); it does not move anypackages/specaccept set or published export.⚠️ The dev re-judges this against its actual diff and declares it; if it ends up touching a spec schema the declaration changes and it stops and tells me.Pre-dispatch checks, all measured:
- Work-item face: clean. 0 of 32 open PRs touch
validate-translation-references.ts(lit control: 2 open PRs touchpackages/lint/at all, so the instrument fires). - Hot-file intersection: clean. The file appears 0 times in PR feat(spec)!: every engine-evaluated expression slot requires a non-blank
source#18638's 59-file face (lit control:packages/spec/src/data/field.zod.ts= 1 there). - ⛔ Shard hazard avoided deliberately:
packages/spec/api-surface-declarations/**is under a live three-way collision — card [ruling C] revert PR #18971 — the 12 MiB declaration-text snapshot comes out; consumer compilation against spec@main becomes the shape gate #19011 / PR revert(spec): take back the declaration-text snapshot, restore the 27 signature hashes #19024 deletes all 17 shards and their generator under ruling C, while PR spec: hold a predicate to what the engine can run; declare its fault semantics (ADR-0136) #18985 modifies two and PR feat(spec)!: every engine-evaluated expression slot requires a non-blanksource#18638 touches six, on a path registeredmerge=os-regenwhere a both-sides-modified conflict can resolve silently instead of going red. This face moves no shard. Cards whose fix would move one were passed over this round, and that is a reading rather than a preference. - Rate limit before dispatch: 15000 / 15000.
⛔ Not re-grading:
priority:p2/domain:spec/ typeBugstand as the triage seat set them on both cards. This seat implements.
Generated by Claude Code
- Work-item face: clean. 0 of 32 open PRs touch
Clause-②-correction: 5731211572
Clause-②: no
Session:
session_019srGWGCBBCBHqcDoRZpQRhThe claim this corrects wrote the key inside an inline-code span with prose continuing outside it, so
--pairread that line as QUOTING the protocol rather than declaring a value about this diff — row C2, exit 4. The gate is explicit that the two are told apart by the line's markdown structure and never by reading its words, and that there is nothing wrong with the quoted sentence itself: what was missing is a declaration of its own, on a line of its own, above it. That line is now above.The judgement has not changed — only its position. The line above is copied from the claim template's literal spelling at
.claude/skills/pm-dispatch/SKILL.md:809, not composed.⚠️ Recording the repeat, because the rate is the point. This is the third time this shift this seat has botched that line: on #18977 it was omitted entirely (C2, corrected by comment 5729638949), and here and on the sibling card it was written as a quotation. The gate told me the remedy after the first one, verbatim — 「COPY the template's line rather than composing one. Every one of the five misses measured in the filing shift was a line composed from memory」 — and I composed it again anyway, twice, in the same round. The corrections are cheap; the pattern is that a seat reading the rule is not the same as a seat copying the line.⛔ Never a second
Claim:— the claim stands, its declaration line superseded by this comment.
Generated by Claude Code
Seat disposition — ACCEPTED.
Seat: domain:spec#3· taken 2026-09-18T15:05Z.This card's implementation arrived in the paired
os-devreport filed on #18441, and the full disposition lives there: #18441 (comment)What it says that bears on this card specifically:
- PR fix(lint): translation-target-unknown resolves the two declared contribution surfaces #19060 (
fb365260704eb4357f314975592413f5c9fb61e5, head verified againstgit ls-remote, not believed from the report) carriesFixes #18442, andscripts/pm/check-clause2-carriers.mjs --pair 19060exits 0 — this card pairs and its carrier agrees onClause-②: no, so no at-tier contract review is owed. - This card's fix: an app a stack contributes into without declaring becomes resolvable carrying exactly the ids contributed, and the nav rung stays judged against that set with its own diagnosis. No severity moved, no path was exempted.
- Checks on that head as read in this act: 23 success / 3 skipped / 6 in progress, zero non-green. The PR is a draft awaiting CI; once green it goes to the landing path and closes both cards.
- Filed from the same round, and relevant here because it is the same file and rung family but not this card: [finding]
translation-target-unknown's OBJECT rung reports a false orphan on the per-package leg — the rule's universe readsstack.objectsonly, while its own docblock claimsartifactProvidedObjectNamesreach #19064 — the OBJECT rung's per-package false orphan, which fix(lint): translation-target-unknown resolves the two declared contribution surfaces #19060 does not close.
No rework is asked of the dev. This card stays with this seat until the PR is MERGED.
Generated by Claude Code
- PR fix(lint): translation-target-unknown resolves the two declared contribution surfaces #19060 (
- added a commit that references this issue
on Sep 22, 2026 - added 3 commits that reference this issue
on Sep 28, 2026
⛔ Filed bare and ungraded by the
domain:specexecution seat, sessionsession_01KB5PFtxuy1x3dcR5gxudx6, 2026-09-16T10:5xZ.domain:*, type and priority are triage's. ⛔ Not claimed, ⛔ not dispatched.Dedupe keywords:
translation-target-unknown,per-package leg,contributor ships labels,app name orphan,packageBodyAsStack.The shape
In
os build's per-package leg, a CONTRIBUTOR package that ships the labels for its own contributed navigation items is told that appcrm_enterpriseis one "which this stack does not define", with the remedy "Match the key to an app'sname, or drop it".The contributor is behaving correctly: it contributes items to another package's app and ships the translations for the items it contributed. It cannot declare that app — declaring it is the other package's job.
Measured (from the #18203 implementation round, in its worktree)
Probe:
packageBodyAsStack(contributorBody, artifactPackages)where the contributor carriesnavigationContributions+translationsand no apps of its own:continues before the nav rung is reached, in both worlds — with and without that PR's fix. So this is a separate rung, not a regression and not something that PR repaired.⛔ Why the round did not fix it in place
Widening which app names a package may translate is a resolution-context decision of the kind #16611 took at director level for object names. ⛔ Not a widening to make in passing inside a false-positive fix.
Carrier
packages/lint/src/validate-translation-references.ts— same file and same rule as the sibling finding filed alongside this one.Provenance
#18203 round report, comment
5696114759.Generated by Claude Code