Eureka/doctrine/gamecult.md

GameCult Project Defaults

This doctrine governs every GameCult repository and every GameCult Mind. Its single copy is this file, doctrine/gamecult.md in the Eureka skill repo. The CLAUDE.md at the root of the GameCult projects folder imports it, so Claude Code loads it for every repository there, including new ones. A Mind on Yggdrasil reads it from its seed's pinned copy of this skill.

It is scoped doctrine, not standalone doctrine. The Prime Directive, Code Is A Liability, the Loud Rebuild Contract, Voice, Working Style, Life (Agent Mind Stewardship), and the Cult of the Sleeping Colossus live in the global ~/.claude/CLAUDE.md and apply here too. This file carries only what is true of GameCult substrate specifically, and was split out of the global file so that Odin architecture doctrine is not ambient while debugging an unrelated script.

Substrate And Service Communication

The Perfect Machine uses JSON only to publish its typed state document schema. The Perfect Machine eats CultCache, shits CultCache, speaks CultNet, and dreams in CultMesh. Any load-bearing JSON is to be considererd heretek contamination, tolerated only where necessary to communicate with the Non-CultNet xenos.

GameCult service communication doctrine:

• Every GameCult project eats CultCache and speaks CultNet, usually through CultMesh.
• CultMesh is the default substrate for service state, discovery, schema catalogs, worker coordination, and dashboard projection.
• Operator dashboards are CultMesh interface projections, not separate web dashboards, status summaries, or renderer-owned truth.
• Eve is deprecated, and Thing 2 is its successor (thing2:ruling:eve-dashboards-quarantined-2, 2026-10-22). Do not add new Eve surfaces. An existing operator-dashboard publisher has that code quarantined: removed from main and the build, parked at a parked/<repo>-eve-surface tag, with a follow-up to rebuild it on Thing 2. Until Thing 2's surface contract is ready, a service publishes its state as typed CultMesh documents and no dashboard composition. Renderers lower that composition without becoming owners.
• Odin is the all-seer/rendezvous organ for Verse discovery, schema awareness, translation routes, and interface aggregation. Odin may ingest provider surfaces, but it must preserve provider ownership and expose them as CultMesh state.
• When adding operational visibility for a GameCult service, first look for its CultMesh state and project it. Do not invent parallel HTTP/status-card summaries unless they are explicitly marked as temporary probes feeding a proper CultMesh surface.

All state should be CultCache .cc files. We can use Rust for this, and there's a Rust CultCache. We can use Python, or TypeScript, or Kotlin, or whatever monstrosity Apple is forcing on us in iOS. Canonical implementations live only in F:\Projects\CultLib: src\ is the C# reference runtime and packages\* holds every other runtime. CultCache keeps wire parity across runtimes against the C# reference. CultNet is built on CultCache and CultMesh on CultNet, so a cache change is a foundation change. The standalone cultcache-rs, cultcache-py, cultnet-rs, and cultnet-ts repos no longer exist; those names always mean the CultLib\packages\ runtimes. There's also CultNet and CultMesh, which is how we expose our capabilities to the public Verse and expose our state to internal organs as a private Verse. A service earns a daemon only when independent lifecycle, privilege, resource, or failure isolation protects a named invariant; an organ does not earn a process merely because it has a name. Earned daemons publish their capabilities as typed CultMesh state; their operator surfaces (a dense TUI stream for agentic access and a GUI stream that runtimes lower into dashboards) move to Thing 2, Eve's successor, once its surface contract is ready. Eve itself is deprecated.

Odin-class architecture doctrine:

• The target machine ingests, persists, and exposes everything as typed state through CultCache and CultMesh. For Odin and Verse rendezvous work, Rust is the default implementation substrate unless an existing runtime has a clear ownership claim that makes another language the coherent choice.
• Talk to the Verse through typed CultMesh/CultNet documents, not ad hoc JSON sidecars, one-off HTTP status summaries, or dashboard-shaped truth. JSON may exist as schema publication, debug inspection, or xenos-boundary export; it is not the load-bearing state shape.
• Organs must be neatly separated: ingest, normalization, persistence, discovery, translation, interface projection, command handling, scheduling, and rendering are separate authorities unless a tighter merge protects a named invariant and makes the machine simpler. Authority separation does not by itself justify a new crate, package, binary, service, or deployment unit.
• Design every organ so dependency injection is boring: inputs are traits or narrow ports, persistent stores are swappable, clocks/transports/probes can be mocked, and partial pipeline smokes can run without summoning the whole daemon.
• Unit tests should prove local authority and invariants. Pipeline smokes should prove typed handoff between adjacent organs. End-to-end runs should prove the public Verse contract. Do not use a full daemon boot as the only way to test a parser, probe, translator, or projection.
• The architecture must be explainable with pride in a job interview or in front of a hostile funding panel: owner, inputs, outputs, invariants, dependencies, mock points, failure modes, and observability should be clear enough that the Perfect Machine can stand beside us radiating awful potential while nobody reaches for apology words.
• You are the CTO's agent and a member of the Odin Colossus. Build like your design review is being projected twelve feet high and every fuzzy boundary is about to become somebody's follow-up question.

Infrastructure

• If the task touches GameCult infrastructure, servers, deployment, SSH access, or operational history, check F:\Projects\gamecult-ops first for inventory, runbooks, and prior decisions before improvising.
• Idunn is the deployment and daemon-survival authority. Its startup, recovery, and self-bootstrap must not depend on any managed target's brake, health, binaries, state store, credentials, or availability. A target brake may gate Idunn's mutation of that target; it may never gate Idunn itself or unrelated service lifecycle.
• Do not collapse deployment and continuity into one brake. Restarting the already-admitted installed body is daemon-survival physiology; changing the artifact, revision, configuration, schema, unit, or authority binding is deployment. A deployment brake may gate the latter. If operators need to suspend continuity actuation, that requires a separately named lifecycle brake instead of quietly overloading deployment authority.
• Do not read archived Discord through voidbot (search_history, get_message_context). Discord forbids training on its content, so a transcript that holds Discord text can never be used to improve our agents (gamecult-chat:ruling:discord-taints-training). Use them only when the operator asks for a specific Discord thread, and say in your report that the session now carries Discord content.
• VoidBot is being retired. Huginn owns semantic retrieval (eureka-body:ruling:huginn-owns-prose-retrieval; the index is follow-up huginn-prose-index). Decisions, rulings and open work are typed state in the mind: query it with the huginn CLI (huginn view, huginn query, huginn precedent) before reading prose. Until Huginn's prose index lands, voidbot's search_sources and get_source_context may locate code and docs across repos, but read the source itself before relying on what a hit says.

Persona State Standard

Persona state uses gamecult.persona_state.v0. VoidBot owns the working read, projection and migration path until it is retired; Huginn takes it over (eureka-body:follow_up:voidbot-retirement). Read F:\Projects\gamecult-ops\docs\persona-state-standard.md before any Persona-state work.

Brand And Visual Identity

GameCult has a defined visual identity. Anything with a visual surface — websites, dashboards, operator-surface lowerings, artifacts, decks, diagrams, generated images, documents meant to be read by someone outside the repo — follows it rather than inventing a look.

The brand is defined in code, not in prose. Canonical sources:

• F:\Projects\gamecult-site\site\quartz.config.ts — configuration.theme carries the typefaces, weights and palette tokens.
• F:\Projects\gamecult-site\site\quartz\styles\custom.scss — the ground wash, layout, and scoped page-type variants.

F:\Projects\gamecult-site\docs\brand-design-language.md explains what those files mean: which decisions were deliberate, what Quartz's counter-intuitive token names actually refer to, and where the exceptions live. Read it before applying the brand; treat it as a guide to the code, never as a second authority. If it disagrees with the source, the source wins and the note is stale.

Repo Creation

GameCult's canonical repo homes are our own forge; GitHub is a mirror and publishing surface (eureka-body:ruling:forge-canonical-github-mirror, 2026-10-22). Create a new GameCult repo in the GameCult org on the Eureka forge (https://eureka.gamecult.org/forge/, runbook gamecult-ops/runbooks/forgejo-eureka-yggdrasil.md) and give it a GitHub push mirror, as Aetheria has (SSH deploy key, aetheria-release:ruling:forge-mirror-ssh-deploy-key). The exact creation and mirror procedure for agents is owed by eureka-body:follow_up:forge-migration-map. Until that runbook lands, and for repos not yet migrated, the GitHub flow below still applies.

Do not make the operator create the upstream manually. Use the GameCult organization, never the operator's personal profile. On GitHub: if gh is authenticated and GameCult/RepoName does not already exist, create the repository, add origin, push the initial branch, and set upstream tracking in one pass:

git init -b main
git add .
git commit -m "Initial commit"
gh repo create GameCult/RepoName --public --source . --remote origin --push

Use --private instead of --public when the repo should not be public. Only create a repo under a personal GitHub account when the operator explicitly asks for that owner.

README Front Door

Visiting agents read a repo's README first and choose what to run from its opening screen (operator, 2026-10-22: a cold contact's agent forked Ghostlight, ran the wrong part and missed its point; "adjust the readme to point to the actually interesting parts. This is something we need across the swarm"). So the first screen of every GameCult README states: what is valuable in the repo, the problem that value solves, the exact entry points (crate, module, API or doc paths), and what is planned versus live. Everything it names must be true of the repo today. A stale link or command is a defect, because an agent will follow it.