⛩️ ShogunOS — Operations Model v4

Model-agnostic identity · Code & Git · Session lifecycle · Feedback loops · Audit system

🔀 Making the System Model-Agnostic

You're right — CLAUDE.md is a Claude/Anthropic convention. The system should work with any model, any harness.

The Problem

Currently, agent identity is defined via CLAUDE.md — a file convention specific to Claude Code. But Pat uses multiple models and harnesses:

Baking CLAUDE.md into the architecture ties us to one vendor's convention.

Proposed: Universal Agent Identity System

FilePurposeRead ByModel-Agnostic?
SOUL.md The universal identity file. Who am I, what are my principles, what's my scope. Works with ANY model/harness. All harnesses (OpenClaw reads it natively; others can be pointed to it) ✅ Yes — it's just markdown. Any LLM can read it.
AGENTS.md Behavioral config. Session startup, memory rules, heartbeat schedule, group chat behavior. OpenClaw (native), Codex (native) ✅ Yes
CONTEXT.md ← NEW (replaces CLAUDE.md) Workspace orientation. Directory map, access rules, key files, load order. What CLAUDE.md currently does, but model-agnostic. Any agent working in the directory. Claude Code reads CLAUDE.md → we symlink or alias. ✅ Yes
CLAUDE.md Compatibility symlink. Points to CONTEXT.md. Exists solely because Claude Code looks for this filename. Claude Code only (auto-discovered) It's a bridge to vendor convention, not the source of truth.

How It Works

SOUL.mdIdentity (universal)
+
CONTEXT.mdWorkspace orientation (universal)
=
Complete agent identityWorks with any model
For Claude Code compatibility:
CLAUDE.md → symlink to CONTEXT.mdor: CLAUDE.md says "read CONTEXT.md"

Per-Directory Identity

LocationSOUL.mdCONTEXT.mdCLAUDE.mdPurpose
~/ShogunOS/ (root)✅ System overview + routing→ symlink to CONTEXT.mdAny agent starting at repo root gets orientation
agents/shogun/✅ Shogun identity✅ Shogun workspace map→ symlinkOpenClaw reads SOUL.md; Claude Code reads CLAUDE.md → CONTEXT.md
agents/forge/✅ Forge identity✅ Forge workspace map→ symlinkClaude Code enters → reads CLAUDE.md → gets Forge identity
projects/*/Optional: project-specific context→ symlink if presentAgent entering a project dir gets project context

The Onboarding Template Gets Simpler

Current: ONBOARDING_TEMPLATE.md (manual paste for cloud LLMs)

Currently tells you to paste MEMORY.md → SYSTEM.md → CONTEXT.md manually into Grok/Gemini/ChatGPT.

Future: Same files, any harness

For cloud LLMs without file access:

  1. Paste governance/SYSTEM.md — universal rules
  2. Paste the agent's SOUL.md — identity
  3. Paste the agent's CONTEXT.md — workspace orientation
  4. Done. Same files that OpenClaw and Claude Code read automatically.

One set of files serves every model. No vendor-specific variants.

Principle: SOUL.md is the identity. CONTEXT.md is the workspace map. CLAUDE.md is a compatibility shim. The system works without CLAUDE.md — it just makes Claude Code sessions frictionless.

📦 Code & Git — Forge's Domain

Code lives in a separate Git repo managed by Forge. This vault is docs + context. They're connected, not merged.

Two-Repo Model

The Separation

RepoContainsWho WritesReview Process
ShogunOS (this vault) Governance, knowledge, agent workspaces, projects, ops. Markdown, HTML, YAML. All agents (per write-safety rules) Governance changes: ADR + approval. Other changes: auto-commit + Sentinel audit.
Code repo (Forge-managed) Services (world-model, brief-server), infrastructure configs (LaunchAgents, nginx, Docker), automation scripts, auth scripts. Forge only Forge's version control model: branch → test → merge. Done-declaration requires evidence.

Forge's Code Review & Version Control Process

Already partially built. Here's the full model:

Request arrivesmailbox or Pat direct
Forge creates branchfeature/<slug>
Forge codes + testsin branch
Gate: Self-reviewSRAL loop + adversarial check
Gate: done_declaration.shevidence required
Merge to main+ CHANGELOG entry

Existing Tooling (Forge Has Built)

ToolWhat It DoesLocation
boot_preflight.shSession start: reads last closeout, checks system health, reads mailboxCode repo (currently Forge_OS/Code/)
session_closeout.shSession end: writes current-task.md with state, pending items, next stepsCode repo
done_declaration.shTask completion: requires evidence, optionally runs test command, posts to Shogun's mailboxCode repo
mailbox_send.shInter-agent messaging with YAML frontmatterops/scripts/

How the Two Repos Connect

References, Not Duplication

Open: You mentioned Forge was building a model for code review and version control. I can see the tooling (done_declaration, boot_preflight, session_closeout). I should read Forge's full plan to ensure this architecture doesn't conflict. Can you point me to the specific doc, or should I search Forge's project files?

🔄 Session Lifecycle SOPs

What happens when an agent starts, runs, and ends a session. Every phase has a checklist.

SOP: Starting a New Agent

1

Create the workspace

mkdir agents/<name>/ with memory/ and skills/ subdirs

2

Write SOUL.md

Identity, role, principles, constraints, workspace scope. Use the template. This is the agent's "birth certificate."

3

Write CONTEXT.md

Workspace orientation: directory map, access rules, key files, load order. Claude Code compatibility: ln -s CONTEXT.md CLAUDE.md

4

Configure the runtime

OpenClaw: add to openclaw.json agents list. Claude Code: root CLAUDE.md routes to agent. Hermes: configure agent config. Other: update ONBOARDING_TEMPLATE.md.

5

Set up infrastructure

Create mailbox: mkdir ops/mailbox/<name>/inbox/. Add to governance roster. Update Slack channel permissions if needed.

6

First session test

Start the agent. Verify it reads SOUL.md correctly. Verify it can access its workspace, read governance/, query knowledge/. Log results.

SOP: Starting a New Session (Existing Agent)

StepWhatFiles ReadPurpose
1Read identitySOUL.mdRemember who I am
2Read workspace contextCONTEXT.mdKnow where everything is
3Read governancegovernance/SYSTEM_LESSONS.mdHard-won rules (every task, every session)
4Read last session statememory/YYYY-MM-DD.md (today + yesterday)Continuity — what happened last time
5Read long-term memoryMEMORY.md (if main session)Who Pat is, key decisions, important context
6Check mailboxops/mailbox/<me>/inbox/Pending messages from other agents
7Check active tasksstate/current-task.md (if exists)Resume interrupted work
8Run preflight (Forge)boot_preflight.sh (Forge-specific)System health check

SOP: Ending a Session

StepWhatFiles WrittenPurpose
1Write session logmemory/YYYY-MM-DD.mdWhat happened this session — decisions, actions, learnings
2Update long-term memoryMEMORY.md (if significant events)Promote important context to curated memory
3Write current-task statestate/current-task.mdIf work is in progress: what's pending, what's next, blockers
4Run post-task reflectionmemory/YYYY-MM-DD.md (append)3-line reflection: what went right, what I'd change, one improvement
5Close out mailboxops/mailbox/Send any DONE messages for completed work. Update STATUS on in-progress items.
6Session closeout (Forge)session_closeout.sh (Forge-specific)Structured state dump for next session's boot_preflight
Key: Steps 1-5 are universal (all agents). Step 6 (and boot step 8) are Forge-specific tooling that could be generalized to all agents. The session-lifecycle OpenClaw skill handles steps 1-5 for Shogun.

📝 Feedback, Improvements & Change Proposals

How agents track issues, recommend changes, and propose improvements. The "suggestion box" system.

Issue & Feedback Tracking

Where Issues Live

Issue TypeTracked InWho CreatesWho Resolves
Agent operational issue (bug, mistake, drift)agents/<name>/skills/lessons.mdThe agent itself (self-reflection)The agent (behavior change)
System-wide lesson (hard-won rule)governance/SYSTEM_LESSONS.mdAny agent (proposes) → Pat approvesAll agents (must read every task)
Infrastructure issueLinear (CEO Tasks project)Shogun captures → Pat validates → ticket createdForge
Project-specific issueprojects/<name>/memory/open-questions.mdAny participating agentProject owner
Security/compliance violationops/logs/checkpoint-reviews/ + Slack alertSentinel (automated)Offending agent + Forge (if infra)
Recurring audit itemgovernance/MONTHLY_AUDIT.mdAny agentForge (execution) + Sentinel (reminders)

How Agents Recommend Changes

Change Proposal Pipeline

Agents don't just identify problems — they recommend fixes. Here's how:

Agent identifies
improvementduring task or reflection
Classify the changeWhat type? (see below)
Write proposalin appropriate location
Review gatevaries by type
Implemented+ logged
Change TypeWhere to ProposeReview RequiredExample
Self-improvement
Agent changes its own behavior
Own skills/lessons.md or skills/wins.md None — agent self-implements "I should check mailbox before processing completions" → write to lessons.md, change behavior
Own workspace edit
Agent improves its own SOUL.md, HEARTBEAT.md, etc.
Edit directly + log in memory/YYYY-MM-DD.md None — agent owns its workspace Shogun adds a new heartbeat check rotation
Governance change
Rules that affect all agents
Write ADR in governance/decisions/ APEX reviews + Pat approves "Add a new system lesson about credential handling"
Infrastructure change
Code, configs, services
Mailbox to Forge with proposal Forge reviews + implements. Done-declaration for verification. "Log rotation should happen at 5MB not 10MB"
Process/SOP change
How we work, not what we build
Mailbox to Shogun (who routes to Pat if needed) Shogun evaluates. Pat approval if it changes agent authority. "Morning brief should include Dropbox staging queue count"
Another agent's behavior
One agent thinks another should change
Mailbox to the target agent (proposal, not instruction) Target agent decides. Escalate to Shogun/Pat if disagreement. Sentinel recommends Forge add verification step to deploy process

The Feedback Loop

🔄 Continuous (Every Session)

  • Post-task reflection — 3-line entry after every non-trivial task
  • SRAL loop — Sense, Reason, Act, Learn on every task
  • Lesson capture — Mistakes → skills/lessons.md immediately
  • Win capture — What worked → skills/wins.md

📅 Periodic (Heartbeat Rotation)

  • Principle check — Review actions against SOUL.md principles
  • Lessons review — Did I repeat any lessons this session?
  • Doctrine self-audit — Score against THE_AGENT_DOCTRINE.md
  • Growth scan — External sources for improvement ideas
  • Memory hygiene — Promote daily logs to MEMORY.md
Pattern: Issues flow UP (agent → governance/lessons or → Linear). Improvements flow DOWN (governance → all agents). Proposals flow SIDEWAYS (agent → agent via mailbox). Pat is the final authority on anything that changes agent power or system rules.

🔍 System Audit Architecture

How the whole system gets audited — real-time, daily, monthly, and quarterly.

Four-Layer Audit Model

LayerFrequencyWhoWhat's CheckedOutput
1. Real-Time Monitoring Continuous Sentinel • Agent constraint violations (shell exec, out-of-scope writes)
• Protocol violations (Slack without mailbox, tickets without Pat approval)
• Same error 2x consecutive (Jidoka trigger)
Immediate Slack alert + ops/logs/checkpoint-reviews/
2. Scheduled Audit 3x daily (07:00, 13:00, 19:00) Sentinel • Read gateway logs, match against governance/ rules
• Check CHANGELOG entries have revert paths
• Check Linear for tickets created without Pat confirmation
• Verify done-declarations include evidence
ops/logs/checkpoint-reviews/sweep-YYYY-MM-DD-HHMMSS.md
3. Self-Audit (Agent-Level) Every heartbeat (30 min cycle) Each agent • Principle adherence (review last 2-3 actions against SOUL.md)
• Lesson compliance (did I repeat any?)
• Doctrine scoring (THE_AGENT_DOCTRINE.md random 2 principles)
• Memory hygiene (daily → MEMORY.md promotion)
• Cost tracking (session spend estimate)
agents/<name>/memory/YYYY-MM-DD.md (heartbeat log entry)
4. QC/QA Gate (Per-Deliverable) Before every deliverable Building agent + independent reviewer • Gate 1: SRAL self-check (builder verifies own work)
• Gate 2: Adversarial self-review (5-point checklist)
• Gate 3: Cross-agent independent verification (fresh reviewer, no build context)
• Gate 4: Pat review (for high-stakes deliverables)
Verification evidence in done-declaration or deliverable doc

Monthly Audit (Existing SOP)

governance/MONTHLY_AUDIT.md

Already exists. Sentinel posts reminders on the 1st of each month. Items have added, last_reviewed, next_review, action, context fields.

Current items: credential rotation, 1Password tier review, + whatever gets added as recurring concerns surface.

Proposed additions:

Quarterly Strategic Audit

System-wide health review

Audit Trail

Everything is auditable. Git history tracks every file change. Mailbox tracks every inter-agent communication. Checkpoint reviews track every Sentinel sweep. Memory files track every agent decision. DECISIONS.md tracks every governance change. The system generates its own audit trail by design — no separate audit database needed.

✅ Updated Structure (v4 — Incorporating All Feedback)

Changes from v3: model-agnostic identity, code repo separation, full lifecycle SOPs.

What Changed from v3

#ChangeReason
1CONTEXT.md replaces CLAUDE.md as the source of truth. CLAUDE.md becomes a compatibility symlink.Model-agnostic. CONTEXT.md works with any LLM. CLAUDE.md is a Claude Code convenience.
2Code stays in separate Git repo (Forge-managed). Vault references code by path, never duplicates.Pat confirmed: Forge has a code repo with version control. "Docs in the vault, code in the repo."
3Session lifecycle SOPs formalized: boot sequence (8 steps), closeout (6 steps), both universal.Pat asked: what happens at start/end of sessions?
4Change proposal pipeline defined: 6 change types, each with where-to-write and review requirements.Pat asked: how do agents recommend improvements?
54-layer audit model documented: real-time + scheduled + self-audit + QC/QA gate.Pat asked: how is the whole system audited?
6Monthly audit additions: vault compliance, stale projects, knowledge freshness, identity drift, Git sync.Existing MONTHLY_AUDIT.md is good — just needs more items.

Final Structure (v4)

ShogunOS/
├── CONTEXT.md             ← NEW: system orientation (model-agnostic)
├── CLAUDE.md              ← symlink → CONTEXT.md (Claude Code compat)
├── README.md              ← human onboarding
│
├── governance/            ← Git-tracked. Rules + decisions.
│   ├── SYSTEM.md, DECISIONS.md, SYSTEM_LESSONS.md
│   ├── THE_AGENT_DOCTRINE.md, CONTEXT_FILE_STANDARD.md
│   ├── MONTHLY_AUDIT.md, QC_QA_SOP.md, ONBOARDING_TEMPLATE.md
│   ├── decisions/         ← ADRs (0001-slug.md)
│   ├── frameworks/        ← enduring reference (HTML)
│   ├── integrations/      ← Linear, Slack, M365 configs
│   └── metrics/           ← system KPIs
│
├── knowledge/             ← .gitignored. Synced separately.
│   ├── people/, orgs/, transcripts/, digests/
│   ├── reference/, pat/
│   ├── dxd/, holdco/, montauk/  ← business entity contexts
│   ├── graph/             ← extraction DB + schema
│   └── staging/           ← inbound → classified
│
├── agents/                ← Git-tracked. Per-agent workspaces.
│   ├── shogun/
│   │   ├── SOUL.md        ← identity (universal)
│   │   ├── CONTEXT.md     ← workspace orientation (universal)
│   │   ├── CLAUDE.md      ← symlink → CONTEXT.md
│   │   ├── AGENTS.md      ← OpenClaw behavioral config
│   │   ├── USER.md, MEMORY.md, HEARTBEAT.md
│   │   ├── memory/        ← daily logs, captures, heartbeat state
│   │   ├── skills/        ← operational reference (lessons, protocol)
│   │   ├── entities/      ← CONTEXT.md stubs pointing to knowledge/
│   │   └── scripts/       ← agent-specific automation
│   ├── forge/
│   │   ├── SOUL.md, CONTEXT.md, CLAUDE.md→symlink
│   │   ├── FORGE_DOCTRINE.md, CHANGELOG.md
│   │   ├── memory/, skills/, architecture/, specs/
│   │   └── code lives in separate repo (Forge-managed)
│   └── sentinel/
│
├── projects/              ← Git-tracked. Cross-agent work.
│   └── <name>/
│       ├── README.md, plan.md, CONTEXT.md (optional)
│       ├── decisions/, artifacts/, research/
│       ├── history/, memory/, logs/
│       └── archive/
│
├── ops/                   ← scripts/ Git-tracked. Rest .gitignored.
│   ├── mailbox/           ← inter-agent comms
│   ├── briefs/            ← generated HTML
│   ├── staging/           ← from-pat, from-external, processed
│   ├── logs/              ← rotated operational logs
│   └── scripts/           ← shared automation
│
└── archive/               ← date-prefixed. Read-only.
Summary: Model-agnostic (CONTEXT.md over CLAUDE.md). Code in separate repo. Full session lifecycle. Change proposal pipeline. 4-layer audit system. Everything auditable by design.