Every ticket as the root of its provenance graph — goal, patch, approval, runs and (as the ticket-class build lands) mandate, manifestations, guarantees, journey, artifacts and children. Rendered through the <<<TicketGraphList>>> tag.
[rules] Turn the 25 verified RFC specs into executable rules (AUTO / MANUAL / residue)
goal
Turn the 25 verified spec artifacts in peer_system/specs/ into EXECUTABLE rules.
WHY THE SPECS, NOT THE RFC TICKETS
The 2026-07-19/20 spec tournament (~3.9M tokens) already derived each requirement, judged it
normative, and wrote a Deterministic test PLUS a Negative control -- in prose. The expensive
derivation is paid for. This run is transcription and wiring, a fraction of that cost.
DISPOSITION -- every spec resolves into three piles, nothing is silently dropped:
AUTO passed requirement whose deterministic test names something checkable (a command, a
file, a countable property) -> becomes an executable test.
MANUAL passed requirement needing a human to read an artifact and judge -> checklist item.
RESIDUE rejected, unverified, or combination-broken -> stays FLAGGED.
NAMING -- follow the existing precedent, one file per rule:
tests/test_rfc<NNNN>_<rule_slug>.py
(cf. test_rfc0003_tool_names_are_verb_noun_snake.py,
test_rfc0013_store_consumers_route_through_shared_clients.py,
test_rfc0016_no_raw_fs_bash_git_tool_in_tool_set.py)
EVERY RULE CARRIES ITS NEGATIVE CONTROL. A check that cannot fail proves nothing: each generated
test must be run against the spec's negative-control input and shown to REJECT it. A rule that
passes its negative control is not shipped.
ORDERING -- this lands BEFORE the peer_system menu rewrite (per-choice schemas, compute_menu
inside the loop). The menu is itself a schema and a number of these rules land directly in it.
KNOWN INCONSISTENT, do not mechanize, carry as residue: #170, #208, #220, #410. Of those, #208 and
#410 are also unusable (no satisfiable witness) and are already recorded in specs/FLAGGED.txt.
#187 is the clean exemplar: 9 requirements, 0 impossible combos, 0 unusable, empty unsat core.
#175 is the partial-adoption case: implement what passed, flag only the residue.
WHY THIS TICKET EXISTS
To carry the telemetry. The build runs under a ticket so the work stays traceable to what was
asked, and so the result can be read back later against this statement of intent.
patch
none
approval
unapproved
runs
no runs recorded
mandate (clauses)
not yet recorded — lands with the ticket-class build
manifestations
not yet recorded — lands with the ticket-class build
guarantees
not yet recorded — lands with the ticket-class build
journey (blunders & successes)
not yet recorded — lands with the ticket-class build
artifacts (forge)
not yet recorded — lands with the ticket-class build