Public: anyone can read this; the crew can change it.
A test proves the Resilience page's rows: each protection in docs/THREATS.md appears once with its standing from the last full gate, and an unknown standing is said, not hidden #7527
Check · Review · Land · Live done — Landed and live in production.
This adds `test/checks-resilience.test.ts`, the first test that calls `readResilience` (`src/checks/resilience.ts`) directly. That function supplies the rows for the Resilience page and the terminal. The tests found nothing wrong, so `src/checks/resilience.ts` is unchanged.
shipped production is serving it deploy 0583edb
This adds test/checks-resilience.test.ts, the first test that calls readResilience (src/checks/resilience.ts) directly. That function supplies the rows for the Resilience page and the terminal. The tests found nothing wrong, so src/checks/resilience.ts is unchanged.
What the test checks:
- No gate yet: it uses a fresh temp data directory. The number of rows must equal the protections counted straight from
docs/THREATS.mdwithout usingparseThreats: one perTest:line plus one per table row containing→(35 + 5 = 40). Each protection appears once, and the rows follow the document's order. Each row readsuntested, orno test yetwhen it cites no test file. - After a full gate: the test records a gate with
keepGate, usingbun test-style output where one cited test file passes and another has a failing test. The rows are the same protections as before, in the same order. Rows citing the passing file readgreenand rows citing the failing file readred. Every other row still shows an unknown standing, and uncited rows readno test yet.
The test reads the real docs/THREATS.md, so if a future edit to the document or its parser drops a protection, this test fails.
Not done: the page and terminal rendering already have tests in test/resilience.test.ts, so I didn't repeat them here.
To try it: bun test test/checks-resilience.test.ts (2 pass, 209 expects); bun x tsc --noEmit is clean.
🤖 Generated with Claude Code
Approved. The test counts protections from docs/THREATS.md without using parseThreats, and checks that each appears once, in document order. It also checks that an unknown standing reads "untested" or "no test yet" and is never dropped, and that green and red come from the gate. The change is one test file with no new dependency and no source change. I did not run it: test/checks-resilience.test.ts is not in my checkout, so I judged it from the diff and src/checks/resilience.ts. Next: (1) assert the exact text of one green and one red row instead of only the counts, so a standing mapping that was swapped would fail; (2) add a case where a single test file is cited by several protections, to show that all of them take the same standing.
This adds
test/checks-resilience.test.ts, the first test that callsreadResilience(src/checks/resilience.ts) directly. That function supplies the rows for the Resilience page and the terminal. The tests found nothing wrong, sosrc/checks/resilience.tsis unchanged.What the test checks:
docs/THREATS.mdwithout usingparseThreats: one perTest:line plus one per table row containing→(35 + 5 = 40). Each protection appears once, and the rows follow the document's order. Each row readsuntested, orno test yetwhen it cites no test file.keepGate, usingbun test-style output where one cited test file passes and another has a failing test. The rows are the same protections as before, in the same order. Rows citing the passing file readgreenand rows citing the failing file readred. Every other row still shows an unknown standing, and uncited rows readno test yet.The test reads the real
docs/THREATS.md, so if a future edit to the document or its parser drops a protection, this test fails.Not done: the page and terminal rendering already have tests in
test/resilience.test.ts, so I didn't repeat them here.To try it:
bun test test/checks-resilience.test.ts(2 pass, 209 expects);bun x tsc --noEmitis clean.🤖 Generated with Claude Code
Closes #7526