Ticket graphs

INVARIANT: no capability that lived in the retired monolith is lost by OMISSION. The retirement is legitimate only once every behavior/requirement pair_loop.py accreted is accounted for as (a) PRESENT in peer_system, (b) CONSCIOUSLY DROPPED with a stated reason, or (c) carrying a RESTORE ticket. This ticket produces that accounting. It is FORENSIC and CONCRETE — it does NOT theorize about how to prevent recurrence (that is the companion ticket B). WHY THIS SHAPE: pair_loop.py grew by ACCRETION — every new requirement pushed more into one file. So 'what is missing' cannot be answered by reading peer_system; it must be answered by reconstructing what the MONOLITH accumulated and checking each item survived. METHOD (so the forensics cannot be skipped): 1. Reconstruct the monolith's accreted REQUIREMENT/FEATURE surface from ITS OWN HISTORY: git log --follow congruency/tools/pair_loop.py — every commit that pushed a requirement in — plus the EXCLUDED 3,079-line ollama_agent.py (~/new-omni-git), whose leaf CONTRACTS (only) were reused. Output an inventory: requirement -> source commit/section -> what it did. 2. Map each item onto peer_system (core.py round loop, runtime/ leaves, tournament/, registry.json languages{}). CLASSIFY each: COVERED / DROPPED-ON-PURPOSE(reason) / MISSING. 3. The MISSING list is the primary deliverable. KNOWN GAPS to confirm and place in the inventory: - The z3 REQUIREMENT-FITNESS method: used the z3 solver to IDENTIFY and FIX poorly-fit / irrelevant RFC requirements (prune/repair the requirement SET itself). Locate where it lived (old monolith? a tool? z3_mcp / solve_mcp — solve_function/check_criteria, the Z3-verified 5-why RCA), confirm the transition dropped it, and make its RESTORATION the first spawned ticket. Doubly relevant: a lost capability AND a tool for judging which accreted requirements were even worth keeping. - The EXCLUDED ollama_agent.py leaf set beyond the contracts reused. - The crank-ticket vs pair-ticket kind gap (RECOVERY.txt) — its premise is STALE (ticket.kind exists); pin the REAL remaining gap. - Equivalence coverage: the audit may NOT lean on 'peer_system is equivalent' — ORACLES.md admits there is no mechanical equivalence proof. Flag every behavior whose parity is asserted but unproven; that set is the hand-off to ticket B. DELIVERABLE: the MISSING inventory (table: requirement -> source -> peer_system status -> action) committed as peer_system/docs/CAPABILITY-PARITY-AUDIT.md, and ONE spawned restore/build ticket per confirmed gap — the z3 requirement-fitness restoration FIRST. REFERENCES: congruency/tools/pair_loop.py (retired subject, read-only) + its git history; the excluded ollama_agent.py; peer_system/{core.py, runtime/, tournament/, registry.json, README.md, PIPELINE_HANDOFF.txt, docs/ORACLES.md}; z3_mcp / solve_mcp. Companion: ticket B (prevention). Relates to pipeline tickets #479-#487 and deploy-governance RFC #488.

— browse congruency source (forge-parked tree)