Invariants Register

Every interface checks business rules so it feels right: it computes the price, counts the free allowance, disables the button after one click, hides what your plan doesn't include. Whether the server repeats those checks is invisible from the browser, and tests written through the interface always pass, because the interface never sends the wrong value. That gap is where money, credits and limits leak, and where one account reaches another's data.

This skill closes it the way a careful QA engineer does, on staging and never on production.

From the client to a register. It reads what your client checks and sends, with file and line, reconstructs the lifecycle of your key scenario (draft → paid → refunded, or whatever yours is), and writes each business rule as an invariant: the rule the server must keep, the client evidence, why it might not hold, a safe test, the oracle and the bug criterion. Rules expected to hold go in too, so the register can say what was proven sound.

Six classes of rule, none skipped. Values the client sends that the server must compute itself; limits counted in the browser; check-then-act races on a balance or a counter; idempotency of one-time operations (refunds, promo codes, confirmations), sequential and concurrent; ownership, so one account can't act on another's data; and transitions from the wrong state.

Proven on staging, read twice. Tests run only against the staging origins you list in invariants.config.json, with your test accounts. The bundled runner refuses any other origin, any production host, absolute URLs and more than five parallel requests, and doesn't follow redirects. Every result is read from the response and, when you give read-only data access, from the data: a response can say "rejected" while a balance moved.

Four verdicts, no guesses. Broken (violated, reproduced from a reset, both oracles agree), holds (rejected or recomputed, data correct), inconclusive (the oracles disagree; what would settle it), not run (unsafe, out of scope or no staging; kept as a unit-test specification). Severity separately: P0, P1, P2.

Every broken rule comes with its fix. The skill pairs each class of rule with the standard server-side remedy (recompute instead of accept, count on the server, one atomic conditional write, a unique key for one-time operations, ownership from the session, transitions guarded by state), so the register says what to change, not only what broke.

Tests that stay. Every invariant that ran becomes a node:test case in invariants.test.mjs, behind the same guard. A broken rule's test fails until the server is fixed, then keeps it fixed in CI. A CI guide comes with it: run after each staging deploy, one job at a time, and mark known-broken rules todo with a ticket so day one isn't a red build nobody can fix.

Pairs with Product Audit. The audit ends with server-side hypotheses for staging; this skill proves or clears them.

Safe by design. It asks first whose product it is, where staging is and which test accounts to use. No production requests, no real customers' data, no getting around rate limits, authentication or payment providers. Without staging, it stops at the register.