reader program 6/4 — `@objectstack/plugin-dev`: the i18n auto-detect never fires for a multi-package app

[hotlong]

Part of #14122 · blocks #14512 · split out of #15210 (the by-shape sweep record — read it for the sweep method and the triaged false positives) · acceptance pin is #15004.

Reader half of the program ruled on #14512 (comment 5528589044). The artifact stays additive through this card.

The site

file:line	Reads	What an option-B artifact does to it
packages/plugins/plugin-dev/src/dev-plugin.ts:526	options.stack.translations	the I18nServicePlugin auto-detect never fires, so a multi-package app boots os dev with the in-memory i18n fallback instead of the file-based service

Reached through the documented construction new DevPlugin({ stack: config }) (packages/plugins/plugin-dev/src/index.ts:36).

What the failure looks like

Not a crash and not an empty screen — the app boots and serves. Translations resolve against the in-memory fallback instead of the file-based service, so a developer sees keys or stale strings where the app declared real copy, on the os dev path specifically. It reads as "the translations are wrong" rather than "a collection went missing", which is what makes it worth a card rather than a footnote.

The pin, already on main

#15004 merged. Read all three before writing implementation:

• packages/cli/test/fixtures/option-b-collection-zoo.ts
• packages/cli/test/fixtures/option-b-reader-probe.ts
• packages/cli/test/option-b-reader-acceptance.pin.test.ts

⚠️ This site has no row in OPTION_B_LOSSES today — the by-shape sweep found it, not the pin. So this card does both halves: add the row that ledgers the loss, then fix the reader and delete it. Do it in that order and say so in the PR — a row that never existed is a row nobody can check you against.

The pin asserts by set equality: adding a row for a loss already fixed goes red just as surely as leaving a row for one that is not. ⛔ Never weaken the pin to pass — do not relax set equality, stop asserting a subsystem, or add rows to silence a red.

Acceptance

• The reader resolves translations through resolveArtifactPackageOrder (@objectstack/core, ADR-0130 D4+D5, since fix(metadata): register a packages[] artifact per package at the metadata door so every object has one owner across every door (#14599) #14643) — flattened top level first, so today's additive artifact answers bit-identically and packages[] only supplies what the top level lacks.
• ⛔ Do not iterate config.packages directly — a second traversal is a second ordering.
• ⚠️ DevPlugin takes its stack from a caller-supplied object (options.stack), not from a load boundary this repo owns. Check whether the auto-detect should also fire when a caller passes an already-composed multi-package config, and say what you found — the enumeration in A multi-package artifact serializes its metadata twice — the flattened top level and every packages[i] body carry the same definitions #14512 comment 5523741937 lists this as one of three construction sites with no load step to fold at.
• ⛔ Do not change composeStacks, packages/spec/src/stack.zod.ts, or what any command emits.
• ⛔ Never edit content/docs/releases/.

Sibling cards: #15005 (@objectstack/runtime), #15006 (@objectstack/cli), #15007 (@objectstack/plugin-security, landed as PR #15226), #15229 (5/4, @objectstack/verify). Emitter half: #14512.

[hotlong]

Claim

Dev seat, session session_01UHvF5hyiZjnCyExFnfQB8m, branch claude/issue-15232-plugin-dev-i18n-package-order (pushed empty as a write-path probe before the first edit).

Worktree: dedicated, off origin/main 1c6f7b4a2. Re-read this card's comments before starting — it carries none, so no earlier claim with a different branch exists. The card is unassigned on arrival; per the dispatch contract the assignee field is the PM's to write, so this comment plus the branch is the claim marker.

Read in full first: this card, #15210 (the by-shape sweep record and its triaged false positives), #15004 (the acceptance pin) and its three shipped files, #14512's body and reader enumeration (comment 5523603341), and the landed sibling PR #15226 (#15007, plugin-security) as the shape precedent.

Scope as I will hold it: @objectstack/plugin-dev plus the #15004 probe row this card has to add and then delete. In that order — the row that ledgers the loss goes in first and is shown RED, then the reader is fixed, then the row comes out; both reds recorded in the PR body. ⛔ The pin is not weakened to pass: set equality stays, no subsystem stops being asserted, no row is added to silence a red. composeStacks, packages/spec/src/stack.zod.ts and what any command emits stay untouched — the artifact stays additive through this card.

The card's own question — whether the auto-detect should fire when a caller hands new DevPlugin({ stack }) an already-composed multi-package config — is answered with evidence in the report and the PR body, not assumed.

---

Generated by Claude Code

[hotlong]

os-dev-report

{
  "issue": 15232,
  "status": "done",
  "branch": "claude/issue-15232-plugin-dev-i18n-package-order",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/15282",
  "premise_still_valid": true,
  "summary": "Both halves, in the card's order. (1) The row that ledgers the loss went in FIRST with the reader still top-level-only, and the pin went RED naming an unledgered subsystem — 'B2 · plugin-dev I18nServicePlugin auto-detect over the caller-supplied stack · translations' — with the other five cases green in that same run, so it is a discrimination and not a broken fixture. (2) The row was ledgered (green at 25 rows). (3) The reader was fixed and the pin went RED again, this time naming the line to delete. (4) The line was deleted (green at 24). OPTION_B_LOSSES ends this branch byte-identical to origin/main: `git diff origin/main -- packages/cli/test/option-b-reader-acceptance.pin.test.ts` is empty. The pin was never weakened — set equality intact, no subsystem dropped, nothing added to silence a red. The fix extracts DevPlugin.init's 3b decision into one exported function, devI18nPluginOptions, which reads the flattened top level FIRST (the caller's original expression preserved verbatim, not re-expressed — #15006's trap) and consults package bodies only where that came back falsy, through resolveArtifactPackageOrder; the `packages` key's absence is checked before the call so D4's second branch never re-reads the top level, and a malformed `packages` raises the ADR-0112 envelope rather than being swallowed. The probe row CALLS that shipped decision rather than re-reading `stack.translations`, so it goes present once the reader is fixed instead of staying red forever. The card arrived unassigned — per the dispatch contract I did not write the assignee field; my claim is comment 5537162417 plus the branch. Dispatch prompt and the seat contract disagreed on that one point (the prompt said to assign myself); the contract file wins, and the disagreement is recorded here rather than resolved silently.",
  "tests": "All at 561ae05da (final commit; origin/main merged in first so the gate derivation had no STALE TREE warning). SUITES: `pnpm --filter @objectstack/plugin-dev test` -> `Test Files 7 passed (7) / Tests 68 passed (68)` (11 new cases); `pnpm --filter @objectstack/cli exec vitest run --maxWorkers=2 test/option-b-reader-acceptance.pin.test.ts` -> `Test Files 1 passed (1) / Tests 6 passed (6)`. THE FOUR MEASURED STEPS: row-only -> `1 failed | 5 passed` with the verbatim 'A subsystem lost a collection that the ledger does not carry' text naming the new row; ledgered -> 6 passed; fix -> `1 failed | 5 passed` with 'A ledgered subsystem now SEES its collections under option B ... Delete these lines'; row deleted -> 6 passed. ABLATION (committed first, then mutated): the packages[] limb removed, CONFIRMED ON DISK before the run — limb occurrences 1 -> 0 and injected marker 1 by `grep -c`, plus the blob hash moved off HEAD's (8ecb11ff -> 9d0ccdac); suite went `4 failed | 64 passed`, failing exactly the four packages[]-dependent cases while the baseline, the flattened-first short-circuit, the single-package read-once pin and the negative BOOT control stayed green. Restored with `git checkout HEAD -- ABSOLUTE_PATH` under an `EXIT INT TERM` trap and PROVEN restored: `git diff HEAD` empty, `git status` clean, disk hash back to 8ecb11ff, marker count 0. No rebuild leg was owed and that is checkable rather than assumed: the test imports `./dev-i18n` relatively and `@objectstack/core` is aliased to source in plugin-dev's own vitest.config.ts, so no dist/ sits on that resolution path (the pin's own path DID need one — `pnpm --filter '@objectstack/cli^...' build`, VERDICT command-exit 0, run before every pin measurement). GATES: family derived with `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack --commands` on the merged tree (10 paths, identical list before and after the merge) — 53 of 57 exit 0, every exit code captured BEFORE any pipe (`cmd > log 2>&1; EXIT=$?`). Green includes check:test-source-alias, check:type-source-resolution, check:type-check-debt, check:cross-package-test-inputs, check:undeclared-dep-imports, check:workspace-manifest-cycles, check:turbo-task-graph, check:nul-bytes, check:published-files, check:engine-double-contract, check:changeset-gate-self-tests. NOT MEASURED, not reported as passed — 4, each with its own unmet prerequisite, all CI-owned: check:dual-build-cjs-loads (exit 3, 11 packages have no dist/), check:i18n and check:i18n-coverage (exit 3, the extract configs' build closure), check:i18n-walk-parity (exit 1, packages/cli/dist/utils/i18n-extract.js absent). TYPECHECK: `pnpm --filter @objectstack/plugin-dev typecheck` exit 0, check:test-typecheck `0 file(s) / 0 error(s)`, and `tsc --listFiles` confirms BOTH new plugin-dev files are really in that program (2 of 2) rather than silently outside it; `pnpm --filter @objectstack/cli check:test-typecheck` -> `3 file(s) / 28 error(s) / 6 pinned signature(s)`, byte-identical to the pre-existing test-typecheck-debt.json, so the fourth paths rule adds ZERO diagnostics. LINT: repo-wide `pnpm lint` (eslint . --no-inline-config) exit 0 — no narrowing claimed. Control-byte self-scan over the diff: no matches. DECLARED NARROWING: the @objectstack/cli suite was not run whole, only the pin — measured, not argued: the new alias is anchored so it re-resolves exactly one specifier, `grep -rln '@objectstack/plugin-dev' packages/cli/src packages/cli/test` returns exactly one file (the probe), and packages/cli/vitest.config.ts carries no vite-tsconfig-paths so the tsconfig paths rule cannot move any existing test's resolution. CI state at report time: draft PR open, checks pending (mergeable_state blocked, expected for a draft).",
  "mcp_calls": "6 — issue_read get 15232, issue_read get_comments 14512 (page 2, perPage 4 — the enumeration comment 5523603341, which the public-payload channel cannot reach: that page preloads only 15 of 51 timeline items and offers no zero-quota pagination), add_issue_comment (claim), create_pull_request, pull_request_read get 15282 (the owed full read-back of the PR body — it survived intact, and the platform rewrote the footer into its session-URL form as expected), add_issue_comment (this report). Everything else came through the zero-quota channels: the card bodies and comments of #15232 / #15210 / #15004 / #14512 via the public-repo payload channel, and the landed sibling PR #15226's diff via `git fetch origin refs/pull/15226/head`. Container REST is session-gated 403 for this seat (`GitHub access is not enabled for this session`, probed repo-scoped before anything else) and `gh` is absent, so the writes went to MCP by necessity — channel switch declared.",
  "open_questions": [
    {
      "question": "A malformed `packages[]` now raises out of DevPlugin.init instead of being ignored. DevPlugin's posture everywhere else is to degrade loudly and keep booting (its child init/start loops turn a failure into a log line, with exactly one deliberate exception, the #5301 organizations refusal). Is the refusal the right posture here, or should the dev boot survive it?",
      "options": [
        "A. Let it throw, as landed. `resolveArtifactPackageOrder` is the platform's one gate as well as its one traversal, and the sibling reader (#15007, plugin-security PR #15226) makes the same choice for the same reason: catching it would resolve a posture out of a package list nothing else accepts. Reachable only when the top level declares no translations, since the flattened answer short-circuits — so no artifact or composed config the platform emits today can reach it.",
        "B. Catch it and skip the i18n registration. Consistent with the rest of DevPlugin, but it re-creates the exact failure class this card fixes: an app whose declared copy is silently not served, this time because its package list was malformed rather than because the reader was short-sighted.",
        "C. Catch it and re-report it through the plugin's own loud-error path. Rejected as written: `reportOptionalLoadFailure` says 'PACKAGE is installed but failed to initialize', which would name @objectstack/service-i18n for a metadata-shape defect — the precise mis-attribution #7926 removed from this file."
      ],
      "recommendation": "A, as landed. Real business need: nobody ships a malformed `packages[]` deliberately, and the developer writing one at `os dev` is exactly who benefits from hearing it at the earliest, cheapest moment. Long-term soundness: one refusal semantics platform-wide, with the gate travelling with the read, beats a per-caller dialect — B would make plugin-dev the one reader that answers questions about artifacts the loader refuses. Making AI-authored metadata apps hard to get wrong: a duplicate package id or an unwrapped entry in an AI-written multi-package config should stop the boot, not become a log line under a running server. Startup scope discipline: not catching is less code and no new concept. Flagged rather than buried because it is the one behaviour change beyond the fix itself, and because DevPlugin's own degradation posture points the other way."
    }
  ],
  "out_of_scope_findings": []
}

---

Generated by Claude Code