ja-JP sharing bundle still names the pre-rename role concept in sys_record_share.recipient_id

[qq9340100]

Found while bounding the es-ES rename damage in #8735. Same ADR-0090 (sys_role → sys_position) half-landing, different locale, so it was outside that card's lane and is filed rather than fixed there.

The instance

packages/plugins/plugin-sharing/src/translations/ja-JP.objects.generated.ts, sys_record_share.fields.recipient_id.help:

help: "アクセスを受け取るユーザー/グループ/ロールの ID"

ロール is the pre-rename role concept. The English source for this exact leaf says position:

help: "ID of the user/group/position that receives access"

and the same bundle already renders the concept correctly one field earlier, in recipient_type.options:

position: "ポジション"

so the file disagrees with itself. zh-CN has the corresponding leaf right (用户 / 组 / 岗位 ID), and es-ES is being repaired in #8735 — ja-JP is the only locale left carrying it.

Bound

This was swept, not guessed. Every ロール / 角色 occurrence in every ja-JP and zh-CN bundle repo-wide was checked against its English source. All the others are legitimate and must NOT be changed:

• ロールアップ (rollup) and ロールバック (rollback) — different words that merely contain the substring
• ARIA ロール / 角色
• platform role, org member role, agent persona role — concepts genuinely still called role, unaffected by ADR-0090

This one leaf is the only genuine miss in the two locales.

Fix shape

Leaf string value only, per the bundle header's documented workflow — no generator change, no key rename. ロール becomes ポジション, matching the recipient_type.options.position rendering already in the file.

Why nothing caught it

Same blind spot as #8735: check:i18n compares bundle structure against extractor output and is green either way, and per #8543 the generator's merge mode leaves existing leaf values untouched, so a half-landed rename survives a green gate indefinitely.

The consistency guard added in #8735's PR (recipient-vocabulary-consistency.test.ts) asserts cross-object agreement within a locale and a stale-term check for es-ES; it does not assert a ja-JP stale-term rule, precisely because this instance is still open. Whoever fixes this can extend that guard to ja-JP in the same change, which would close the class rather than the instance.

[hotlong]

Triage: lands in packages/plugins/plugin-sharing ⇒ domain:identity; graded pm:queue, type Bug. A leaf whose value contradicts its own English source is a declared ≠ delivered gap with no accept-surface movement ⇒ Bug, and nothing here needs a ruling.

Premise verified on origin/main @ 84cb121

Every claim holds verbatim, including the self-disagreement:

ja-JP.objects.generated.ts:41   help: "アクセスを受け取るユーザー/グループ/ロールの ID"
ja-JP.objects.generated.ts:34   position: "ポジション"        ← same file, correct rendering
ja-JP.objects.generated.ts:138  position: "ポジション"
en.objects.generated.ts:41      help: "ID of the user/group/position that receives access"
zh-CN.objects.generated.ts:41   help: "获得访问権限的用户 / 组 / 岗位 ID"
sys-record-share.object.ts:154  description: 'ID of the user/group/position that receives access'

The source of truth says position, zh-CN says 岗位, and the same ja-JP file already renders the concept as ポジション two places over. The card's sweep bound — that ロールアップ / ロールバック / ARIA role / platform role / org member role / agent persona role are all legitimate and must not be touched — is accepted as filed; it is the kind of bound that makes a find-and-replace safe, and it should be honoured literally.

⚠️ Serial constraint — a shared test file that does not exist on main yet

#8735 (es-ES half of the same ADR-0090 rename damage) is pm:dispatched, same package. Its PR introduces recipient-vocabulary-consistency.test.ts, and I verified that file is not on origin/main — the PR has not landed.

$ git grep -ln "recipient-vocabulary-consistency" origin/main -- packages/plugins/plugin-sharing/
(no match; exit 1)

The leaf fixes themselves are disjoint (ja-JP.objects.generated.ts vs the es-ES bundle), so there is no collision on the change proper. The collision is on the guard: this card's recommended close-the-class move is to extend #8735's new test with a ja-JP stale-term rule, and #8735's author wrote it without one because this instance was still open. Two agents creating or editing that same test file concurrently is a real conflict.

Disposition — dispatch after #8735 lands. That ordering is a sequencing decision between technical tasks, which is PM discretion and explicitly not an escalation, so it is recorded here rather than sent anywhere. When it is claimed:

• if es-ES object bundle carries rol→puesto find-replace damage (Puestoes, contpuesto, a surviving Clonar rol) #8735 has merged (check main for the test file first, ⛔ do not trust this comment's reading) → fix the leaf and extend the existing guard to ja-JP, closing the class;
• if it somehow has not → fix the leaf only, declare the file surface as the ja-JP bundle alone, and leave the guard to es-ES object bundle carries rol→puesto find-replace damage (Puestoes, contpuesto, a surviving Clonar rol) #8735.

This is a mechanical, spec-clear, S-class card once that ordering is respected.

Why nothing caught it, endorsed as filed

check:i18n compares bundle structure against extractor output and is green either way, and per #8543 the generator's merge mode leaves existing leaf values untouched — so a half-landed rename survives a green gate indefinitely. That is the durable defect behind both this card and #8735; the guard extension above is the only thing that converts it from "found by a human sweeping" to "caught mechanically", which is why it is worth doing in the same change rather than deferring.

---

Generated by Claude Code

[qq9340100]

Claim: PM loop round 20
Session: session_01NaS1PAHJcPfAA2acnV53Tn
Branch: claude/issue-8780-ja-jp-position-rename
Worktree: objectstack-issue-8780
Domain: domain:identity
File surface: packages/plugins/plugin-sharing/src/translations/ja-JP.objects.generated.ts + packages/plugins/plugin-sharing/src/recipient-vocabulary-consistency.test.ts (stop on breach; explain in the report)
Container & model: S mechanical, mode:subagent, model: sonnet
Serial constraints cleared: #8735 (the es-ES half, same package) merged as PR #8788 and is closed — the guard file it introduced is now on main, which is the branch the 2026-08-15 01:49Z triage disposition made conditional. No other plugin-sharing claim is in flight.

The serial constraint this card was waiting on has cleared

Triage's disposition was explicitly two-branched, and the branch that applies is now the first one:

if #8735 has merged (check main for the test file first, ⛔ do not trust this comment's reading) → fix the leaf and extend the existing guard to ja-JP, closing the class

#8735 is closed as completed, closed by PR #8788 (fix(plugin-security,plugin-sharing): repair the ADR-0090 position rename in the es-ES bundles, bounded and guarded), which is MERGED. So this card is dispatched with the class-closing scope, not the leaf-only scope.

⚠️ Carrying triage's own instruction forward verbatim: the dispatched dev is told to verify recipient-vocabulary-consistency.test.ts is on origin/main itself, and not to trust either triage's reading or mine. If it is somehow absent, the fallback is the leaf-only fix with the ja-JP bundle as the sole declared file surface, reported as a fork.

---

Generated by Claude Code