platform-objects: the `pages.*` third of the hand-authored bundles is outside the new default-locale parity walk — its sources live in other packages, so nothing compares them at all

[hotlong]

Observation filed while implementing #8721 (the default-locale content-parity assertion for the hand-authored apps / dashboards half). Not fixed there — out of that card's fence, and the fix is a different mechanism. Filed unassigned for triage.

What is covered after #8721, and what is not

packages/platform-objects/src/apps/translations/en.ts has exactly three top-level sections. The parity assertion added in #8721 walks two of them:

section	source of truth	compared against en.ts?
apps.*	setup.app.ts, studio.app.ts, account.app.ts — same package	yes, verbatim
dashboards.*	dashboards/system_overview.dashboard.ts — same package	yes, verbatim
pages.*	other packages (see below)	no — by nothing, in any locale

The three pages.* entries and where their strings are really authored:

• marketplace_installed — packages/cloud-connection/src/marketplace-ui.ts
• cloud_connection_settings — packages/cloud-connection/src/cloud-connection-ui.ts
• connect_agent — packages/mcp/src/connect-ui.ts

The #8721 assertion cannot reach them, and the reason is structural rather than an oversight: platform-objects does not depend on @objectstack/cloud-connection or @objectstack/mcp and must not, so a static walk in that package's own test has nothing to compare to. The test states the exclusion deliberately; this issue is the tracking half of that statement.

Why it is worth a card even though nothing is stale today

Checked at the time of filing — all three are currently in parity with their sources, e.g. connect_agent serves Connect an Agent plus the same subtitle sentence connect-ui.ts declares. So this is an unexercised hole, not a live defect.

What makes it worth tracking is that it is the same shape as the defect #8721 was filed for, in the same file, one section over: a leaf value copied by hand from a source in another file, with no gate comparing the two. #8721 happened because a widget was converted and its four bundles kept the pre-conversion string under a fully green build. A page header edited in cloud-connection or mcp would do exactly that here, and would additionally do it in all four locales including en, which is now the one locale the rest of this bundle guarantees.

Candidate shapes (not decided here)

1. Extend pnpm check:app-nav-i18n — it already boots the real composition to judge the merged nav tree, so it is the one existing gate that can see pages contributed by other packages. Comparing pages.* default-locale values against the composed page metadata would sit naturally beside what it already does.
2. Move the three pages.* entries into bundles owned by the packages that author the strings, so each one is a same-package comparison. Larger, and it touches how the merged translation data is assembled.

Option 1 looks much cheaper and needs no ownership change; option 2 removes the class rather than gating it. Sizing is triage's call.

Backlink: #8721.

[hotlong]

Triage — first grading (finding → queue), plus a re-route.

Verdict: promoted to pm:queue, re-routed domain:metadata → domain:cli, type Task.

Why promotable rather than held

No live defect — the card measured all three pages.* entries in parity at filing time, and I did not re-measure. What makes it queue-able anyway is that it is the same mechanism that already produced one measured live defect, one section over in the same file (#8721's widget_recent_events, serving its pre-conversion title in all four locales under a fully green build). The hole is unexercised, not speculative, and the cheaper named route closes it with a gate that already exists.

The re-route — read from the code, not from the title

The anchoring rule takes the domain of the package the fix lands in:

• Route 1 (the card's option 1) lands in packages/cli/scripts/check-app-nav-i18n.mjs — domain:cli.
• Route 2 (move the three entries into the packages that author the strings) lands in packages/cloud-connection and packages/mcp — both also domain:cli — plus a removal in packages/platform-objects.

Either route is majority-cli. The gate's own header states the structural reason directly: it lives in packages/cli because that is the composition root and the only workspace package depending on all the contributors at once — "a gate in platform-objects could not import the plugins (they depend on it, not the other way round) and would be measuring the shell." That is the same fact that makes this card exist.

domain:metadata was the domain of the package that observed the hole. Right instinct at file time; the fix does not land there.

Route is a mechanism assumption, not a ruling

Route 1 is recommended — much cheaper, no ownership change, and it extends a gate that already boots the real composition. It rests on one thing nobody has measured: whether the page metadata carrying marketplace_installed / cloud_connection_settings / connect_agent actually flows through the composition that gate boots. The gate walks the merged nav tree today; pages are a different surface.

The dispatching seat should carry this as a falsifiable assumption, not a decided route: if the booted composition cannot see those three page headers, report the fork rather than forcing route 1 — route 2 is then the honest answer, and it is a materially larger card.

Serial note

#8721 is in flight on packages/platform-objects/src/apps/translations/. Route 1 does not touch that path, so the two are file-disjoint. Route 2 is not — if the fork above sends this to route 2, it serializes behind #8721.

---

Generated by Claude Code