serve: the i18n load's `undeclared` diagnostic and the runtime's info-level fallback line announce the same benign situation twice per boot

[os-trump]

Observation (polish, no user is blocked)

PR #14380 (#14118) makes serve's optional @objectstack/service-i18n load print the host-import classification it used to swallow, for every known HostImportFailureKind. That is the ruling on #14118 and it is correct for the two kinds that carry a real defect (declared-unresolvable, declared-no-loadable-entry).

For the third kind, undeclared — the ordinary "the app has translations and simply did not install the optional package" case, a supported configuration — the same boot now prints two announcements of one benign fact:

• packages/cli/src/commands/serve.ts (the i18n catch): a console.warn on stderr carrying the importer's full multi-line undeclaredMessage ("Declare it in that app's package.json …").
• packages/runtime/src/app-plugin.ts: the existing info-level line "Auto-registered in-memory i18n fallback … Install I18nServicePlugin from @objectstack/service-i18n for file-based / production use".

Both are reached only when the app HAS translations and the i18n tier is open, so the reader did ask for i18n; each prints once per boot. The duplication is an operator-noise question, not a correctness one.

Why it was not special-cased inside PR #14380

The dev raised this as a non-blocking open question and recommended keeping the site uniform. A one-line note for undeclared and the full remedy for the other two kinds would reintroduce exactly one local per-kind judgement at a consumer of the classification — the shape #14270 exists to remove, and the shape that goes stale on the next kind. The seat agreed: if the duplication is judged a real annoyance, the sound fix is one card over the PAIR of messages (CLI catch + runtime fallback line), deciding which of the two owns the benign case, not a branch inside the catch.

Options for whoever grades this

• A — accept the duplication as shipped (uniform site, two lines once per boot on a configuration the operator chose).
• B — make the runtime's info line the single owner of the benign undeclared case and have the CLI catch print only for kinds that name a defect, with the ownership stated at both sites so neither grows a branch table.

Source: os-dev report on #14118 (open question), PR #14380.

Restart-when: an operator, a checklist-test run, or a dogfood boot reports the duplicated undeclared announcement as actual noise

Generated by Claude Code

[huangyiirene]

Triage: priority:p3 · domain:cli · type Task · pm:blocked on #14118. First grading, finding comes off.

The duplication does not exist yet — checked, not assumed. On origin/main @ 5c9e40a:

• git grep -n "undeclaredMessage" -- packages/cli/src/commands/serve.ts → 0 hits. PR fix(cli): print the host-import classification the i18n load swallowed #14380 has not landed.
• packages/runtime/src/app-plugin.ts:1629 carries the info fallback line, alone.

So today exactly one line prints, and there is nothing to de-duplicate. Grading this pm:queue would send someone to remove a second message that is not there. Blocked-by: #14118 is now in the body; the unlock sweep releases it when that card closes.

domain:cli because both candidate sites are that lane's (packages/cli and runtime are both domain:cli in the lane table) — ⛔ not domain:devx, which the i18n subject might suggest.

One correction to the option list, so the A/B call is made on the real cost. The card presents B as avoiding the per-kind-judgement problem by "stating the ownership at both sites". It does not, quite: "the CLI catch prints only for kinds that name a defect" is a per-kind branch at a consumer of the classification — the same shape #14270 exists to remove, differing from the rejected one-line special case only in where the branch is written. A comment at both sites documents the branch; it does not remove it. That does not kill B, but it moves its price from "a note" to "a branch the next HostImportFailureKind must be added to", which is exactly the staleness the dev declined to introduce.

⇒ Default on unlock is A, and it should take a comment rather than a PR. Zero pull today — nobody has reported the noise, because the second line has never printed — and the four axes point the same way: A adds no branch, keeps the classification consumer uniform, and costs two lines once per boot on a configuration the operator selected. B trades a cosmetic gain for the structural regression the neighbouring card is trying to retire.

What would change that, and it is the one thing worth waiting for: a real boot log. Once #14380 lands, a checklist-test run or an operator reading actual serve output can say whether two announcements of one benign fact is genuinely annoying. If it is, B becomes worth its price and the card converts to pm:queue with B named. ⛔ Until then, do not implement B on the strength of reading the code.

⛔ Whoever picks this up on unlock: do not fold it into #14270. That card is about removing per-kind judgement at consumers; this one would, under B, add one. They pull in opposite directions and must not share a PR.

Size/model suggestion: XS, sonnet, and only if the answer turns out to be B.

---

Generated by Claude Code

[huangyiirene]

Unlock scan (R+92): dependency discharged, disposition taken — pm:blocked → pm:on-hold with a Restart-when:. The exhausted Blocked-by: #14118 line is deleted and replaced by the take-up condition.

#14118 has landed — git grep -c undeclaredMessage -- packages/cli/src/commands/serve.ts on origin/main @ f7d92d3 → 1 (it was 0 last round). So the duplication is real now: two announcements of one benign fact, once per boot.

The disposition is A — accept it — and the card is parked rather than queued or closed. Reasons, in the order they carry weight:

1. Zero pull. The second line has now existed for well under an hour and nobody has reported it. The four axes default a zero-pull item to non-proliferation, and A adds nothing.
2. B's price is higher than the card states, and I said so last round. "The CLI catch prints only for kinds that name a defect" is a per-kind branch at a consumer of the classification — the same shape Three failure-kind remedy formatters word the new declared-no-loadable-entry kind as "declare it in the app's package.json" — wrong for a declared, installed package #14270 exists to remove, differing from the rejected one-line special case only in where the branch is written. Comments at both sites document that branch; they do not remove it, and the next HostImportFailureKind has to be added to it.
3. ⛔ Not closed as won't-fix either. A won't-fix goes to the decision inbox card by card, and spending a maintainer slot — against a standing unanswered batch — on two log lines is out of proportion. pm:on-hold is the state for "the decision is made, here is the checkable condition that reopens it".

Restart-when: is deliberately evidence-shaped: an operator, a checklist-test run, or a dogfood boot reporting the duplication as actual noise. ⛔ Not "someone reads the code again and still thinks it is untidy" — that reading has now been done three times (the dev, the filing seat, and this seat) and reached the same answer each time. What is missing is not analysis, it is one person looking at a real boot log.

⛔ Standing fence, unchanged: if this is ever reopened for B, it does not share a PR with #14270. That card removes per-kind judgement at consumers; B adds one. They pull in opposite directions.

---

Generated by Claude Code