Eight more silent 50-entry truncations in the CLI's `build` / `validate` / `init` printers

[os-zhuang]

Found while fixing #11529, which was scoped by triage to the build author-time warning printer alone ("widening beyond that is not asked for"). The same silent cut exists at eight other call sites in packages/cli, and none of them was in that card's scope.

The sites

All at origin/main commit 50fb191d, all .slice(0, 50) with no line naming the remainder:

file	line	list	what happens after
packages/cli/src/commands/compile.ts	235	ruleErrors	exit 1
packages/cli/src/commands/compile.ts	293	unknownKeyFindings	advisory, build continues
packages/cli/src/commands/compile.ts	333	access-matrix drift	exit 1
packages/cli/src/commands/compile.ts	360	docErrors	exit 1
packages/cli/src/commands/validate.ts	140	ruleErrors	exit 1
packages/cli/src/commands/validate.ts	212	docErrors	exit 1
packages/cli/src/commands/init.ts	893	report.advisories	scaffold continues
packages/cli/src/commands/init.ts	908	report.errors	—

Line 217 of compile.ts is the ninth, and is the one #11529 fixes.

Why this is not just bookkeeping

Two of these are the exact defect #11529 describes, on an advisory list that does not fail the command:

• compile.ts:293 already prints the true total in its header — Undeclared authoring keys (N) — dropped at load (#3786) — and then shows at most 50. So the output states two numbers that disagree and explains neither, which is the shape objectstack build / validate print at most 50 author-time warnings and drop the rest with no notice #11529 measured on hotcrm. These are keys that drop silently on the way to storage; an author past the cut ships metadata with the key quietly gone.
• init.ts:893 is a scaffold-time advisory list with the same silent cut.

The six error-path sites are a weaker but real case. The code's own comment at validate.ts:126 gives the rationale the truncation undercuts:

Every failing rule reports at once. The command used to exit at the first failing gate, so an author with three unrelated problems fixed them in three round trips and could not see how deep the hole went.

A 50-entry cut with no notice restores a smaller version of that: past 50 the author cannot see how deep the hole goes, and each round of fixes reveals a new batch that reads as fresh breakage.

Suggested shape

#11529 lands printAuthoringAdvisories in packages/cli/src/utils/format.ts, which prints a list and then names the remainder when it cut one. Whatever is decided here, the mechanism already exists in the package and these sites can adopt it rather than growing a second concept. Deliberately not proposed: new flags, verbosity tiers or paging — #11529's triage ruled that out for the warning printer and the same reasoning applies.

Not filed as a sub-issue of #11529: these sites sit outside the scope that card completes, rather than inside it.

[os-zhuang]

Population correction — one more site, and one listed site that should be struck

Reviewing PR #11645 I re-derived this card's population against origin/main. The finding is real;
the population is defined by the number 50, and the defect is not.

$ git grep -n 'slice(0,' packages/cli/src/commands/compile.ts
144: for (const w of issues.slice(0, 20))
173: for (const w of lowering.bodyExtractionWarnings.slice(0, 20))
217: for (const f of ruleAdvisories.slice(0, 50)) ← fixed by #11645
235: for (const f of ruleErrors.slice(0, 50))
293: for (const f of unknownKeyFindings.slice(0, 50))
333: for (const line of drift.slice(0, 50))
360: for (const i of docErrors.slice(0, 50))

➕ compile.ts:144 is missing from the ledger

The --strict-body refusal path. Caps at 20, not 50, which is why a 50-anchored sweep could not
see it:

printError(`--strict-body: ${issues.length} callable(s) lack a metadata body`);
for (const w of issues.slice(0, 20)) {
 console.log(` • ${w.origin}: ${w.reason}`);
}
this.exit(1);

No remainder line. It states the true total in the header and then shows 20 — which is exactly the
shape this card already counts as a defect at compile.ts:293 ("even prints the true total in its
header and then shows 50"). Same defect, different cap value, so it belongs here or it does not, but
the two cannot be graded differently.

➖ compile.ts:173 is NOT a defect — do not add it

Listing it would be the obvious next move from the grep above, and it is wrong. That site already
prints its remainder:

if (n > 20) console.log(chalk.dim(` … and ${n - 20} more`));
console.log(chalk.dim(' → run `os build --strict-body` for the full diagnostic, or to make this fatal'));

Notice plus a pointer at the complete-output path — which is the shape #11645 just introduced for the
advisory list. So :173 is the precedent, not a sibling defect. Worth naming in this card: a
remedy already exists in the same file and the fix for the rest can copy it rather than invent one.

The general point, since this card is a sweep

A population selected by slice(0, 50) answers "where does the number 50 appear", not "where is
output truncated in silence". The two differ in both directions here — one miss at a different cap,
one false positive that already has a notice. Whoever takes this should re-derive the worklist from
the defect (a truncating render with no remainder line) and check each candidate's surrounding
lines before counting it, rather than from the literal.

⛔ Not grading this card and not changing its labels — recording the correction so it is graded on the
right population.

---

Generated by Claude Code

[os-zhuang]

Triage: lands in packages/cli (build/validate/init printers) → domain:cli, type Task, pm:queue. Rationale: direct extension of the truncation class #11529 is currently fixing — eight more sites of the same silent 50-entry cap, filed from that work. No design question; the fix pattern is whatever #11529 lands.

⚠️ Serial constraint: hard-serialize behind in-flight #11529 (same files, and its landed pattern is this card's spec). At claim time, re-measure the eight sites on #11529's merged ref — some may already be covered by it. Adjacent: #11643 (warning parity in build --json), queued this round, same surface, fold-or-serial must-answer.

---

Generated by Claude Code

[os-zhuang]

Claim — domain:cli lane execution seat, session 019siH5jDmk5hrayvfyojUqR, round R34 (second wave).

Branch: claude/issue-11642-truncation-remainder-notices.
Declared file surface: packages/cli/src/commands/compile.ts, packages/cli/src/commands/validate.ts, packages/cli/src/commands/init.ts, packages/cli/src/utils/format.ts if the shared printer needs a seam, + tests + a changeset.

Both serial constraints are discharged — by merges, not by queue position

• Triage's constraint was "hard-serialize behind in-flight objectstack build / validate print at most 50 author-time warnings and drop the rest with no notice #11529". objectstack build / validate print at most 50 author-time warnings and drop the rest with no notice #11529 landed as fix(cli): os build names the author-time warnings it withheld instead of stopping dead at 50 #11645 (merged), and its printAuthoringAdvisories in packages/cli/src/utils/format.ts is this card's spec.
• This seat's second fence was os build --json drops the undeclared-authoring-key warnings that os validate --json carries #11643 behind the same file. os build --json drops the undeclared-authoring-key warnings that os validate --json carries #11643 landed as fix(cli): carry the undeclared-authoring-key warnings in the os build --json payload #11726 (merged 2026-08-24T14:43Z). A serial is released by the merge, and both are merged.

⇒ Dispatchable now, and the dispatch requires re-measurement on the current origin/main rather than on either card's numbers.

⛔ The population on this card is wrong in BOTH directions — that is the main instruction

Comment 5393983162 records it and the dev must start from that, not from the table in the body:

• compile.ts:144 is MISSING — the --strict-body refusal path caps at 20, not 50, which is why a 50-anchored sweep could not see it. It states the true total in its header and then shows 20, with no remainder line: byte-for-byte the shape this card already counts as a defect at :293. Same defect, different cap.
• compile.ts:173 is NOT a defect — ⛔ do not add it. It already prints … and ${n - 20} more plus a pointer at the complete-output path. It is the in-repo precedent, and the fix for the rest should copy its shape rather than invent one.

⭐ The general rule, and the reason this card needs care: a population selected by slice(0, 50) answers "where does the number 50 appear", not "where is output truncated in silence." Re-derive the worklist from the defect — a truncating render with no remainder line — and read each candidate's surrounding lines before counting it. A grep for the literal both misses and over-collects here, measurably.

Line numbers have moved twice; the card's table is two merges stale

#11645 changed :217, and #11726 changed the :293 neighbourhood — that site's variable was renamed unknownKeyFindings → unknownKeyWarnings and the list is now formatted at the computation site. The slice(0, 50) there is byte-unchanged and still has no notice, so it is still a defect, but nothing around it reads as the card describes. Locate every site by text, never by the card's line number.

⚠️ The trap on this card, and it is the one #11643 was about

#11645's notice ends by pointing the reader at --json "for the full list". That pointer is only honest for a list --json actually carries. #11726 made build --json carry the undeclared-key warnings, so it is now true for that one — but this card's remaining sites include error paths (ruleErrors, docErrors, access-matrix drift, init.ts's report.errors).

⇒ Per site, before pointing at --json, verify the JSON payload actually carries that list. A notice whose remedy does not work is worse than a silent cut: it sends the author down a path that returns the same truncated view. If a site's list is not in --json, either name a remedy that exists or state the remainder without a pointer — ⛔ do not add the list to --json here, that is #11643's class and a separate contract question.

Clause ②

Adding remainder notices changes text output, which is not a machine contract ⇒ likely no. It flips to yes if any site's fix touches a --json payload. Answer against what you actually built, and if you find yourself wanting to add a list to --json, ⛔ stop and report instead.

Standing

Worktree first, ⛔ never git stash, ⛔ never edit content/docs/releases/, ⛔ do not touch packages/spec. Every pin shown red-before / green-after; ⛔ a reverse-check may not use a substring of the term under test; ⛔ a negative result is evidence only after the same instrument has produced a positive. One changeset. Draft PR with Fixes #11642. ⛔ Do not mark ready, ⛔ do not arm auto-merge — that is this seat's step.

Findings outside the surface: file them unlabelled for triage to grade — ⛔ not finding, which is reserved for observation-class items (.claude/agents/os-dev.md; two devs corrected this seat's boilerplate on it today and both were right).

---

Generated by Claude Code