trials

trials

!checklist init ${CLAUDE_SKILL_DIR} --force

Sea trials take a newly-built ship out under real conditions to prove how it actually behaves — not to inspect how its parts are bolted together. trials is the fifth skill of the surface suite, the correctness lens, and it tests a frontend the same way: against observable behavior under real use, never against internal structure. Everything follows from one question you nail down first: does this test go red when the behavior changes, or when the implementation changes? It runs across gated stages and will not advance past a GATE until the checklist tool clears it — order enforced, substance yours.

The one question, and why it decides everything. A test that reddens only when behavior changes is a safety net: it lets you refactor with confidence and screams when a real regression slips in. A test that reddens when the implementation changes while behavior holds is a straitjacket: every refactor turns it red for nothing, so you spend your time fixing tests instead of code — and, worse, you learn to ignore red, at which point the whole suite is dead. The executable litmus: if I rewrote this unit's internals but kept its observable behavior, would this test still pass? If yes, it's a good test; if it breaks, it tests structure — rewrite or delete it. The whole skill is that one sentence expanded.

And a second decision about where the tests go: frontend bugs do not cluster in individual pure functions — they cluster at the seams and in the two-graph drift and state-out-of-sync that wellspring named. So the right shape is not the classic pyramid (mostly unit tests) but a testing trophy: a little static checking (types/lint), the bulk in integration/behavior tests, a thin layer of E2E, and very few unit tests. Spend the test budget where the bugs are.

This is where the agent era bites:

• The agent optimizes for "the test passed," not "the behavior is correct." Its reward is green, and the shortest path to green is a test coupled to the code it just wrote — asserting internal state, render counts, that a private function was called. Those pass now and shackle every future change. The agent will also, given the chance, edit the test to make it pass. A green suite the agent produced is evidence of nothing until you know what turns it red.
• The agent over-mocks and mocks the wrong layer. It will mock the module under test (so the test asserts the mock returned what you told it to — testing nothing) and write mocks whose shape doesn't match the real contract (green test, broken prod). The honest seam to fake is the network, with a schema-backed mock.
• The agent chases coverage and writes snapshots. 100% coverage and a wall of big snapshot tests look like rigor and are mostly straitjackets — brittle, unreviewed, "just update the snapshot." Coverage is a tool for finding untested risk, not a target.

Read references/the-membrane.md first — the heart; for trials, the relevant truth is that the frontend's spec is observable behavior (the correctness benchmark is a user, not an internal structure) and the bugs live where the two graphs drift and the seams meet — so you test behavior, at the integration level. Load at the start, re-check at every gate.

Speak the user's language. The calls here are the user's — is this worth an E2E, is this test pinning behavior or structure, is this mock honest. Read their fluency and gloss a term on first use (behavior vs implementation, the testing trophy, integration test / testing-library, E2E / Playwright, the network boundary, MSW, mutation testing, a snapshot test). A "this test is bad" you can't justify by the litmus is a style opinion, not a finding.