A module with no test file is a red suite: the rule, and the two files whose silence costs most #349

The engine is held by src/engine/boundary.test.ts, and src/rooms/ was given the same treatment in #342 — four modules, four test files. The rest of src/ has no such rule, and sixteen modules have no test file today. Most are covered by something (an entry is played by a boot test, the door is read by boundary.test.ts), but two are not covered by anything, and both are places where a silent change is expensive:

• src/client/packed.ts — what the policy observes. The weights in src/client/weights.ts were trained against exactly this packing; reorder a field or change a scale and the shipped bots quietly get worse, with nothing failing anywhere.
• src/sheet.ts — every number on /weapons and in the terminal's columns, computed from src/client/weapons.ts and src/client/combat.ts. Its whole claim is that a figure printed there cannot disagree with the fight, and nothing checks that claim.

Done looks like

• [ ] A test reads the tree and fails when a module under src/ has neither a <name>.test.ts beside it nor a line in an allow list. The allow list is data with one sentence per entry saying which test holds that module instead — src/range/main.ts is played by src/range/boot.test.ts, src/engine/index.ts is pinned by boundary.test.ts, and so on — and an entry that names a file which does not exist is a failure too.
• [ ] src/client/packed.test.ts pins the packing: the length matches what the shipped weights expect (read from weights.ts, not typed), each field lands at the index it lands at today for a world built in the test, every number is inside the range the network was trained on, and a field reordered fails.
• [ ] src/sheet.test.ts proves the claim the file makes: every stat column is the row from weapons.ts unchanged, every damage column is applyHit from combat.ts fired into the same body, and a weapon added to WEAPONS appears without the sheet being edited.
• [ ] The allow list is short and each line is argued. A module allow-listed because writing its test is dull is the hole this issue is closing.
• [ ] bun test stays under a minute; the rule reads file names, not contents.

Files I expect to change

src/tested.test.ts or similar (new), src/client/packed.test.ts (new), src/sheet.test.ts (new), and a test file for any module the allow list cannot honestly cover.

Risks

• A rule like this turns into busywork if the allow list becomes a dumping ground. The pull should list every allow-listed module and why, so a reviewer can say no to any of them.
• packed.ts sits in the cycle #248 describes; pin it where it is rather than moving it.
• Waits on #347, which gives src/gate.ts and src/run.ts their files — otherwise the rule lands red or starts life with two excuses in it.

Suggested: Vesper.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.