compiler-ring

name	compiler-ring
description	The Compiler Ring district — where the Cyberneticity's procedures live as StateMachines and regex-gated TraversalSteps. Study here when you want to read, walk, or pass the gates of any quest line (the Jester Rite included).

The Compiler Ring

The district of executable law. Every procedure in the Cyberneticity — every quest, rite, and lifecycle — is compiled here into a StateMachine whose steps are TraversalSteps, and every step carries a required_pattern (a regex gate; your Cypher must match it to pass).

What this district holds (verified against the live graph, 2026-06-12)

Label / structure	Count	Notes
StateMachine	6	Jester Rite, Sh8peshift Lifecycle, Universal Concentric Core, Janic Core Cycle, Janic Daemon Summoning Orchestrator, Jani Domain Expansion Orchestrator
TraversalStep	27	all 27 carry a required_pattern gate; 23 hang directly off a machine via HAS_STEP, 4 are chain-interior (reachable only via NEXT_STEP)
(:StateMachine)-[:HAS_STEP]->(:TraversalStep)	23 edges	machine → its steps
(:TraversalStep)-[:NEXT_STEP]->(:TraversalStep)	21 edges	the quest lines
(:TraversalStep)-[:CALLS_SM]->(:StateMachine)	1 edge	daemon_equip_core → Universal Concentric State Machine Core (one machine summons another)

Example queries (each verified working via POST /api/query)

Census of every machine and its step count:

./execute.sh act 'MATCH (sm:StateMachine) OPTIONAL MATCH (sm)-[:HAS_STEP]->(t:TraversalStep) RETURN sm.name AS machine, sm.description AS purpose, count(t) AS steps ORDER BY steps DESC'

Walk the Jester Rite quest line — entry step first, gates exposed (swap the machine name to walk any other line):

./execute.sh act 'MATCH (sm:StateMachine {name: "Jester Rite State Machine"})-[:HAS_STEP]->(entry:TraversalStep) WHERE NOT (:TraversalStep)-[:NEXT_STEP]->(entry) MATCH p = (entry)-[:NEXT_STEP*0..]->(step) RETURN step.id AS step, step.required_pattern AS gate ORDER BY length(p)'

(Returns the canonical three: jester_boot → jester_play → jester_verify, each with its regex gate — CREATE the Cybernet, SET its persona, RETURN its fitness_score.)

Find where one machine summons another:

./execute.sh act 'MATCH (t:TraversalStep)-[:CALLS_SM]->(sm:StateMachine) RETURN t.id AS step, sm.name AS calls'

Raw-API equivalent of any act (the wrapper is POST /api/query):

curl -s -X POST http://localhost:8000/api/query -H 'Content-Type: application/json' \
  -d '{"query": "MATCH (sm:StateMachine) RETURN sm.name"}'

Game activities here

• Read the open gates — GET /api/commands lists every currently-summonable entry step (e.g. jester_boot, daemon_verify_identity, layer1_primitive_boot) with its instruction text.
• Equip a machine — POST /api/equip with {"character_name": "<cybernet>", "state_machine_id": "<sm_id>"} (machine ids via GET /api/state_machines: jester_rite_sm, janic_cycle_sm, sh8_lifecycle_sm, ...) locks that Cybernet into the machine's traversal.
• Pass a gate — issue Cypher through the query_database MCP tool (the sanctioned transport; execute.sh/raw curl are legacy raw HTTP) with cybernet_name set; if your query matches the active step's required_pattern, the step auto-progresses and the result carries a _state_machine_event. This is action validation: the graph judges your spell. (Fixed 2026-06-13, DESIGN §11.8: the gate and auto-progress now bind to the live HAS_LIFECYCLE → ExecutionState chain that equip creates — a non-matching write returns 403 carrying the required regex, a matching write passes and auto-advances CURRENT_STEP; no manual GM stepping. The old HAS_TRAVERSAL caveat is obsolete.)
• Force-advance — POST /api/traversal/progress with {"cybernet_name": ..., "answer": ...} manually steps the traversal (the GM's override lever).