User story: two-layer brain for multi-project support

User story

As the rig maintainer

I want the brain split into two layers — an invariant rig brain (how agents work) and a per-project brain (what each project is)

So that the same agent pods can serve Dashecorp’s iOS portfolio and future project portfolios without duplicating agents, while each project owns its own truth about itself.

Context

Scoping note from delivery: the original framing was “extract Dashecorp-specific content out of the rig brain”. Once I started the work I found the rig brain already only contained rig-platform facts (rig-gitops, rig-agent-runtime, rig-conductor, etc.) — those are the rig. The Dashecorp product repos (cutie, fast-e, drink-e, count-e, star-rewards, nutri-e, ios-link-sdk) weren’t in any brain. So this story is really create project brains from scratch, not extract-and-split. Rig brain stayed as-is.

See the whitepaper for the architecture.

Acceptance criteria

✅ Rig brain at research.rig.dashecorp.com/BRAIN.md contains only invariant content. Already true before this story — no Dashecorp-product content was ever in there.
✅ Dashecorp project brain at dashecorp-docs.pages.dev/BRAIN.md — shipped. Populated with the 7 iOS app repos, stack (SwiftUI + Xcode Cloud + RevenueCat), deploy targets, portfolio conventions (opaque RGB icons, release sequencing).
✅ Template — dashecorp-docs itself is the template. Copy-strip-populate when spinning up a new project brain (as done for dashecorp-docs: clone rig-docs scaffold, strip rig-specific machinery, replace compile-brain.mjs with a minimal project-brain version).
✅ Agent character prompts — dev-e-node + review-e now fetch both brains at session start when the assignment is on a repo outside the dashecorp org. Client-side routing via the prompt, no rig-conductor change (see AC 5 note).
⏳ rig-conductor dispatcher annotates assignments with projectBrainUrl — deferred until we onboard a second tenant. Client-side prompt routing works for the single-tenant case today; centralised routing becomes useful for per-project cost attribution + dispatch scope expansion.
✅ Documentation in the rig brain explains the two-layer pattern — covered by the brain-and-memory whitepaper §5.

Design decisions made

URL convention: <project>-docs.pages.dev/BRAIN.md. dashecorp-docs.pages.dev shipped under that pattern.
Ownership: each project brain is owned by the project’s maintainer team. For now both live under the dashecorp org; a future split moves per-tenant.
Duplicate-fact resolution: project brain wins on project-specific; rig brain wins on rig-wide; agents consult both and the prompt makes the precedence explicit.

What shipped

Component	Where	PR/commit
`dashecorp-docs` repo scaffolded	github.com/dashecorp/dashecorp-docs	initial commit, manual push
Project brain compiled + served	https://dashecorp-docs.pages.dev/BRAIN.md	first deploy via wrangler
Dual-brain fetch in dev-e + review-e prompts	dashecorp/rig-gitops	#106
ConfigMap verified on live pod	dev-e-rig-agent-runtime-0	live check 2026-04-19

Still open (follow-up)

rig-conductor side routing (AC 5) — file as a separate story when a second tenant onboards, since that’s when centralised routing becomes load-bearing.
Dispatch scope expansion: rig-conductor currently monitors org:dashecorp. The prompt update enables agents to behave correctly when routed to a repo in the operator’s personal org, but the dispatch itself needs to learn about new orgs — also a future-second-tenant concern.

Priority

High. Establishes the multi-tenant pattern for future onboarding. Core work done; full autonomy for multi-tenant deferred until a second tenant is onboarded.