validate

Validating the guild

There is no code left to unit-test. What can fail now is a member reading the schema and the process, understanding some of it, and doing something adjacent to what was needed.

docs/expectations.md is the specification that catches that, and because the data model is a database, every expectation in it is a SQL assertion with a stated expected result rather than prose to be interpreted. This skill runs them and reports what holds.

Read-only by default, and say so in the report. The only path that writes is --fixture, which is gated behind a confirmation and refuses a board holding real work.

The surface

invocation	what runs
validate	§3 — the eleven global invariants. They hold whatever just ran.
validate <process>	§3, then that process's preconditions, postconditions and anti-expectations.
validate --fixture <name>	Loads a fixture into a scratch database, then asserts against it. Writes.

<process> names a skill, and the section it maps to:

process	section	process	section
new-requirement	§4 the build flow	release	§9
brief	§5	qa	§10 the maintenance cycle
dashboard	§6	shift	§11 the unattended shift
check-in	§7

§8 names no process: it is the anti-expectations for emptying a board, and the fresh-file procedure that stands in for one. Its assertion, nothing was deleted, is G11 and runs with every other global.

<name> is one of empty, planned, in-flight, review-ready, messy, maintenance — docs/expectations-fixtures.md.

The shape every assertion has

Zero rows when healthy, the offending rows when not, so a failure names its own cause. finding-open-past-gate-repairs|1|REQ-001 tells you the row, the requirement and the rule; a boolean FAIL tells you to go looking. Any output at all is a failure.

A handful state a count or a value instead — §4.b expects exactly the plan gate row, §4.c expects N+10 | 2N+11 | 2, P4.a expects version 8. The sentence above each block says which. Read it; do not assume the zero-rows shape.