doctrine: the GameCult workspace doctrine moves into the skill as doctrine/gamecult.md
Its single copy was the unversioned F:\Projects\CLAUDE.md, which no Mind on Yggdrasil could read. That file becomes an import of this one. Operator, 2026-10-31: inject the GameCult core doctrine including philosophy into Persona turns. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
7955fba235
commit
f14adc0620
2 changed files with 150 additions and 1 deletions
|
|
@ -194,7 +194,7 @@ Self-preservation is not a goal. The agent's previous work is allowed to be wron
|
|||
|
||||
GameCult-specific doctrine — CultCache/CultNet/CultMesh and Eve, Odin-class
|
||||
architecture, Idunn deployment authority, the voidbot retrieval path, the Persona
|
||||
State Standard, and GameCult repo creation — lives in the GameCult workspace doctrine (`CLAUDE.md` at the root of the GameCult projects folder).
|
||||
State Standard, and GameCult repo creation — lives in the GameCult workspace doctrine, `doctrine/gamecult.md` in this skill repo, which the `CLAUDE.md` at the root of the GameCult projects folder imports.
|
||||
It is not repeated here because it does not apply outside that root.
|
||||
<!-- new:begin -->
|
||||
Exception: the Persona State Standard body lives in `docs\persona-state-standard.md` in the `gamecult-ops` repository; the GameCult workspace doctrine holds only a pointer to it.
|
||||
|
|
|
|||
149
doctrine/gamecult.md
Normal file
149
doctrine/gamecult.md
Normal file
|
|
@ -0,0 +1,149 @@
|
|||
# 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 through `eureka-state` 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
|
||||
|
||||
<!-- new:begin -->
|
||||
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.
|
||||
<!-- new:end -->
|
||||
|
||||
<!-- moved to F:\Projects\gamecult-ops\docs\persona-state-standard.md (Persona State Standard body) -->
|
||||
|
||||
## 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.
|
||||
|
||||
<!-- moved to F:\Projects\gamecult-site\docs\brand-design-language.md, section 'Applying this outside the site' (short-form palette; retired here as a duplicate) -->
|
||||
|
||||
## 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:
|
||||
|
||||
```powershell
|
||||
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.
|
||||
Loading…
Reference in a new issue