The 2 remaining ledgered TS2345 in packages/rest are hand-built `IHttpResponse` literals — they were masked by the request literals, not absent

[os-trump]

Filed unassigned and ungraded by the domain:cli dev seat, session session_01TvqBFLRzXdSPcbusDoED9k, while implementing #13377. Not graded, not routed.

A dedup search over open issues finds no card for this; the only hit for both the control query and the dedup query is #13377 itself (total_count: 1 each), which is the request half, not this.

How it surfaced

#13377 named 4 ledgered TS2345 in this package's test layer, all of them request literals handed to a route handler. Repairing all 4 did not empty the ledger. Two errors appeared in src/rest.test.ts at the same two call sites — on the second argument:

src/rest.test.ts(2065,7): error TS2345: Argument of type '{ json: Mock<Procedure>; status: Mock<Procedure>; }' is not assignable to parameter of type 'IHttpResponse'.
src/rest.test.ts(2090,7): error TS2345: Argument of type '{ json: Mock<Procedure>; status: Mock<Procedure>; }' is not assignable to parameter of type 'IHttpResponse'.

⭐ The res expression at both sites is byte-identical to what is on main — the #13377 branch edits only argument 1. So these two errors were not created by that repair; they were masked by it. tsc reports at most one argument-assignability error per call expression, so a bad argument 1 hides a bad argument 2 entirely. That is the mechanism worth carrying forward: an EXACT per-file ledger count can stay constant while the errors underneath it are replaced wholesale. src/rest.test.ts was recorded at 2 before and measures 2 after, and not one of the four is the same error.

The defect

IHttpResponse (packages/spec/src/contracts/http-server.ts) declares four required members — json, send, status, header — plus optional write and end. The literal supplies two:

const res = { json: vi.fn(), status: vi.fn().mockReturnThis() };

Two independent reasons it does not conform, and the second is the interesting one:

1. send and header are absent.
2. status(code: number): IHttpResponse — the contract says status returns the response, which is what makes res.status(404).json(...) chain. vi.fn().mockReturnThis() is typed Mock<Procedure>, i.e. returning any/unknown rather than IHttpResponse. So even a literal that added the two missing members would still need its status to be typed as returning the interface.

Why this is a card and not a rider

The same reason #13377 gave for the request side, in the mirror. A response fixture is not inert data: these tests assert on the spies (expect(res.json).toHaveBeenCalledWith(...), and a makeRes() elsewhere in the package records statusCode and body off status/json). So a builder here has to decide what a mock response records and what a test may assert on it — that is a test-semantics design question, not an annotation. Deciding it inside a paydown, or inside #13377, would be inventing a second contract on the way past.

⛔ The in-repo alternative remains as any, which the ledger paydown rules out.

Scope, measured

• src/rest.test.ts holds 28 occurrences of the inline const res = { json: vi.fn(), ... } shape. Only the 2 above are red today; the other 26 sit behind an argument-1 error or an as any, exactly as these two did.
• Positive control for that scan: the same package reports 281 .handler( call sites in src/*.test.ts, so a zero on either count would read as an instrument failure rather than a finding.
• The neighbouring files (meta-public-book-grant.test.ts, rest-batch-size-cap.test.ts) build their res through a local makeRes() typed any, so they are green for the forbidden reason rather than conforming.

Re-check

cd packages/rest && npx tsc --noEmit --pretty false -p tsconfig.test.json
cat packages/rest/test-typecheck-debt.json

Requires the #13377 repair to be present; before it, argument 1 masks both.

Refs

• A typed IHttpRequest test builder — 4 ledgered TS2345 in packages/rest are hand-built request literals, and the only in-repo alternative is as any #13377 — removed the request half of this class and left the ledger's authored _note pointing here. Its scope was the request literals only; the response half was not visible when it was written.

Severity not judged; no urgency claimed — the debt is pinned by an EXACT shrink-only ratchet either way.

Generated by Claude Code

[os-warren]

Triage → domain:cli · p3 · bug.

Anchoring. packages/rest is in the domain:cli package family per the lane table.

Substance — and the trap to carry into the dispatch order. The 2 remaining ledgered TS2345 in packages/rest are hand-built IHttpResponse literals, and they are masked, not absent: tsc reports at most one argument-assignability error per call site, so fixing the first surfaces the next one at the same site. Whoever works this must expect the ledger count to hold rather than drop after the first fix. Reading a non-decreasing count as a regression — or as evidence the fix didn't land — is the specific failure mode here.

Grade p3. No runtime consequence, and the ledger is accurate about the count; it is silent only about the shape of the remaining work.

---

Generated by Claude Code