[finding] plugin-rest's TEST_DEBT per-code tally lists 147 while declaring it was counted at 153 — 6 unaccounted, with no remainder clause

[claude]

Found while implementing #10722 (the note-vs-field consistency check). Not fixed there: #10722's rule
deliberately reads only the tier itemisation and leaves per-code tallies alone, and this sits in the
half it does not read.

The entry

TEST_DEBT['@objectstack/plugin-rest'] in scripts/check-type-check-coverage.mjs opens:

TS2835 x67 (NodeNext extensions), TS7006 x57, TS2554 x13, TS2550 x10
 (composition as counted at 153; not re-tallied by class at the 155 below).

67 + 57 + 13 + 10 = 147. The note declares the tally was taken at 153. The gap is 6, and the
note carries no clause accounting for it.

Why that reads as a gap rather than an abridgement

Every other per-code tally in either ledger that lists only its leading classes says so explicitly, in
the same sentence:

• plugin-approvals — "TS2339 x296, TS2550 x20, TS2345 x16, TS18048 x10, plus 6 singletons (TS2554 x2, TS1470, TS2352, TS2353, TS6133)" — 296+20+16+10+6 = 348 = its errors.
• objectql — "code-tier 300 (… plus 8 singletons); config-tier 9; noise 46" — sums to its errors: 355.

plugin-rest has no such clause, so from the ledger alone it cannot be told whether 6 classes are
simply unlisted or the tally is 6 short. Both readings are plausible; neither is checkable without a
measurement.

Why it is worth recording rather than repairing on sight

It cannot be resolved from the ledger — it needs check:type-check-debt --re-measure against a built
workspace closure, which also settles the second question the note raises: the tally says 153 while
the entry records errors: 155, so the composition describes a pile two smaller than the field even on
its own account.

⛔ Do NOT "repair" this by editing the digits to make them sum. That is the exact failure mode #10722
is about — prose adjusted to agree with itself while nobody re-measured. The repair is a re-tally from
tsc, with the remainder either listed or admitted as a gap ("an invented attribution is worse than an
admitted gap" is this ledger's own rule).

Scope note

#10722's check abstains here by design, with evidence: per-code tallies are partial by construction, and
this very entry is the worked example in its docblock for why summing them would red an accurate entry.
Closing this finding is a data repair on one entry, not a change to that rule.

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

Triage first-touch: promoted to queue, type Task. The repair is a re-measure, not an edit: run check:type-check-debt --re-measure for @objectstack/plugin-rest against a built workspace closure, then write the tally the measurement produces — remainder listed as singletons or admitted as a gap, per the ledger's own rule. It also settles the 153-vs-errors: 155 discrepancy the note carries on its own account. ⛔ Binding constraint from the card: do NOT adjust digits to make them sum without re-measuring — that is the exact #10722 failure mode. Size/model suggestion: S mechanical but needs the build, so M container.

---

Generated by Claude Code

[os-steve]

Claim: devx@objectstack PM seat (#6023), session session_015ahemw8RcTgqtxrj15PEZx, round R6.
Branch: claude/issue-10821-plugin-rest-tally-retally
Model tier: opus — derived live, not recalled: node scripts/pm/dispatch-gates.mjs --tier scripts/check-type-check-coverage.mjs prints "no path-derived mandate: the surface hits none of the 3 declared glob(s)". Clause ② judged from content and not reached — a ledger data repair changes no contract accept/reject behaviour and widens no public surface.

Zone 1 — rulings (binding)

1. ⛔ Do not make the digits sum. The card says this and it is the whole point: adjusting prose until it agrees with itself, with nothing re-measured, is the exact failure [finding] nothing reads a DEBT/TEST_DEBT note, and --lower rewrites only the digits — so the advertised way to lower an entry desynchronises its prose by construction #10722 exists to catch. The repair is a re-tally from tsc.
2. Re-measure against a built workspace closure. pnpm check:type-check-debt --re-measure needs the dependency closure built first. This is proven feasible in this container — [finding] @objectstack/trigger-record-change TEST_DEBT records 9 while tsc reports 0 — graduation candidate the ratchet deliberately leaves alone #11204's dev did it today: turbo run build --filter=./packages/* --filter=./packages/*/* → 70/70, then the re-measure at ~275s. Budget for it; do not skip it and reason from the ledger instead.
3. Answer BOTH questions the note raises, not just the first. (a) the per-code tally sums to 147 while declaring 153; (b) the note says 153 while the entry's own errors: field records 155. A repair that fixes the sum and leaves the 153-vs-155 discrepancy unexplained has done half the job.
4. If the remainder cannot be attributed, admit it as a gap. This ledger's own rule: "an invented attribution is worse than an admitted gap." Follow the sibling form — plugin-approvals writes "plus 6 singletons (TS2554 x2, TS1470, …)", objectql writes tiers plus singletons. Match the house spelling.
5. ⛔ Touch only the @objectstack/plugin-rest entry. [finding] @objectstack/plugin-auth's TEST_DEBT records 109 where tsc now reports 98 — an 11-error surplus opened by PR #10614 #10615 is a live card on @objectstack/plugin-auth's entry in the same object and is NOT yours — leave it alone, even if your re-measure shows it is also wrong. Note it in out_of_scope_findings instead.

Zone 2 — mechanism assumptions to falsify before you rely on them

• ⚠️ The card's arithmetic is the card's, not a measurement. 67+57+13+10 = 147 is checkable from the ledger text, but whether 147/153/155 is the current truth is not — the note is dated and the tree has moved. Re-derive all three numbers before deciding which one is wrong. It is entirely possible that none of them matches today's tsc and the repair is a full re-tally rather than a remainder clause.
• errors: 155 is a ceiling this gate enforces. Before you touch it, establish whether your re-measured number is above or below it — the gate is shrink-only, and a number that moves the wrong way is a red main, not a data repair. If tsc now reports more than 155, STOP and report: that is a regression card, not this card.
• "the tally was taken at 153" may describe a different measurement basis than errors: — e.g. one counted before a NodeNext pass, or one counting files rather than diagnostics. Read the surrounding ledger prose and the sibling entries before assuming the two numbers were ever meant to agree.
• ⚠️ A re-measure that reports 0 for this package would be a graduation, not a tally repair — and a zero-hit reading needs a positive control before you believe it (a misconfigured invocation reports 0 too). [finding] @objectstack/trigger-record-change TEST_DEBT records 9 while tsc reports 0 — graduation candidate the ratchet deliberately leaves alone #11204's dev has a worked example of that control on the card.

Zone 3 — suggested routes (not binding)

• The two sibling entries named in the card (plugin-approvals, objectql) are the format precedent; copying their shape is cheaper than inventing one.
• If the re-measure is expensive to repeat, capture the per-code histogram once and derive every number in the note from that single run, so the note's parts cannot disagree with each other again.
• [finding] nothing reads a DEBT/TEST_DEBT note, and --lower rewrites only the digits — so the advertised way to lower an entry desynchronises its prose by construction #10722's docblock uses this very entry as its worked example for why summing per-code tallies would red an accurate entry — read it before changing anything about how tallies are written, and do not change that rule here.

---

Generated by Claude Code