ShogunOS — Vault Stress Test & MoE Review

🧪 Workflow Stress Tests

Pat's real-world workflows and edge cases run against the proposed structure.

Scenario	Walkthrough	Result	Notes
1. Pat sends voice memo with 3 tasks in Slack Most common workflow	1. OpenClaw receives → Shogun transcribes via Whisper 2. task-capture classifies each task 3. Captures → `agents/shogun/memory/captures/2026-04-11.md` 4. If any task is Forge-routable → mailbox to `ops/mailbox/forge/inbox/` 5. Evening brief surfaces captures for Pat validation	PASS	Clean path. All files land in predictable locations.
2. Pat asks "what did Serge say last week?" Knowledge retrieval	1. Shogun receives question 2. Query world-model API (:8081) for "Serge" + recent transcripts 3. API searches `knowledge/transcripts/` + `knowledge/people/serge-glushenko.md` 4. Returns relevant snippets (not full files) 5. Shogun synthesizes and responds	PASS	Clean separation: knowledge/ is the data lake, world-model API is the query layer.
3. Pat drops a PDF in staging File triage workflow	1. PDF lands in `ops/staging/from-pat/` 2. Shogun detects on triage pass (or Pat says "check staging") 3. Classify: Is this a project artifact? Knowledge? Reference? 4. Process: Extract text, summarize if needed 5. Move to `knowledge/reference/` or `projects/*/artifacts/` 6. Remove from staging	PASS	But: PDFs are .gitignored. Need to decide: convert to MD before filing? Or keep PDFs in knowledge/ and gitignore that dir?
4. Forge needs to deploy a code change Engineering workflow	1. Forge (Claude Code) opens session at repo root 2. Reads root `CLAUDE.md` → identifies as Forge 3. Works in `agents/forge/code/` or relevant project dir 4. Writes to `agents/forge/architecture/` for ADRs 5. Logs to `agents/forge/memory/` 6. Commits via git ⚠️ But where does actual code live?	PARTIAL	Gap identified. Code (Python scripts, configs, LaunchAgents) isn't clearly placed. See Claude Code section.
5. New agent "Dispatch" needs to be created Agent onboarding	1. `mkdir agents/dispatch/` 2. Create SOUL.md + CLAUDE.md from template 3. `mkdir agents/dispatch/memory/ skills/` 4. `mkdir ops/mailbox/dispatch/inbox/` 5. Add to governance/ roster 6. Update root CLAUDE.md routing table 7. Configure in openclaw.json	PASS	Simple, repeatable process. 7 steps, all scripted.
6. Pat says "update the Orcrist capture plan" Cross-agent project work	1. Shogun receives → checks `projects/orcrist-capture/README.md` for owner 2. Reads current `projects/orcrist-capture/plan.md` 3. If Shogun owns: updates directly 4. If Forge owns: mailbox to Forge 5. Updates logged to `projects/orcrist-capture/logs/` 6. Decision captured in `projects/orcrist-capture/history/`	PASS	Project dir has all the context. No searching across vaults.
7. Two agents edit the same project file simultaneously Concurrency edge case	1. Shogun and Forge both open `projects/orcrist/plan.md` 2. Both make changes 3. Second writer overwrites first writer's changes ⚠️ No lock mechanism exists	RISK	Real problem. Mitigations: (1) ownership rule in README.md, (2) agents check before writing, (3) git history as safety net. See Write Safety section.
8. Sentinel detects Shogun violated a constraint Audit workflow	1. Sentinel reads gateway logs → detects violation 2. Writes checkpoint to `ops/logs/checkpoint-reviews/` 3. Posts alert to Slack #forge 4. Shogun reads alert on next heartbeat 5. Corrective action → logged in `agents/shogun/memory/`	PASS	Clean separation of concerns. Sentinel writes to ops/, not to agents/shogun/.
9. Pat says "what's the status of everything?" Status rollup	1. Shogun reads all `projects/*/README.md` (status field) 2. Reads `agents/shogun/memory/captures/` for unchecked tasks 3. Reads recent `ops/mailbox/shogun/inbox/` for pending items 4. Queries Linear API for ticket status 5. Synthesizes and responds	PASS	All status info in predictable locations. `ls projects/*/README.md` gives the full portfolio.
10. Obsidian Sync conflict on Cockpit Sync edge case	1. Pat edits `governance/DECISIONS.md` on Cockpit 2. Shogun appends to same file on Engine 3. Obsidian Sync creates conflict file 4. Need manual resolution	PARTIAL	Mitigations: (1) governance/ changes go through ADR process (not ad-hoc edits), (2) Pat edits via Slack not Obsidian for governance, (3) Obsidian Sync conflict files are visible in Obsidian UI.
11. Pat travels with Nomad — needs project context Remote access	1. Nomad has `governance/` + `agents/shogun/` via sparse checkout 2. Pat opens Obsidian → can read governance and Shogun notes 3. Needs a project file → `projects/` not synced 4. Options: (a) SSH to Engine, (b) expand sparse checkout, (c) Obsidian Sync includes projects/	PARTIAL	Need to decide: does Nomad sync `projects/`? Active projects only? All projects? Recommend: sync active projects only.
12. Knowledge gets stale — CRM contact changed jobs Knowledge maintenance	1. Network SME runs enrichment pass 2. Detects stale contact in `knowledge/people/john-smith.md` 3. Updates file with new info 4. world-model API re-indexes on next cycle 5. Next time Shogun queries "John Smith" → gets current data	PASS	Pipeline handles this. One file per person makes updates atomic.
13. Pat says "build me an investor portal" Major new project	1. Shogun creates `projects/dxd-investor-portal/` 2. Writes README.md (owner: Forge, participants: Shogun + Forge) 3. Mailbox to Forge with requirements 4. Forge creates plan.md, starts in artifacts/ 5. Code lives in... where? ⚠️ The code output isn't clearly addressed	PARTIAL	Same gap as #4. A project that produces code needs a clear code location. See Claude Code & Git section.
14. Morning brief fails to generate Service failure	1. 6:15 AM cron fires → Shogun starts brief generation 2. Linear API is down → partial data 3. Shogun writes what it can to `ops/briefs/` 4. Logs error to `agents/shogun/memory/` 5. Next heartbeat: retry?	PASS	Failure is logged, partial output still serves. Structure doesn't hinder recovery.
15. Pat says "I told you about this last month" Historical recall	1. Shogun checks `agents/shogun/MEMORY.md` (curated long-term) 2. If not there: checks `agents/shogun/memory/2026-03-.md` (daily logs) 3. If not there: queries world-model API for transcripts 4. If not there: searches `projects//history/` for Pat direction captures	PASS	Four-layer recall: curated memory → daily logs → knowledge API → project history. Good coverage.

Summary

10 PASS Clean workflows: task capture, knowledge retrieval, file triage, agent onboarding, project work, status rollup, audit, maintenance, brief generation, historical recall.

3 PARTIAL Need refinement: Obsidian Sync conflicts, Nomad sync scope, code output location.

2 GAPS Must address: (1) Where does code live? (2) Concurrent write safety.

🧠 Mixture of Experts — Panel Review

Five independent expert lenses evaluating the architecture. Each expert flags landmines and proposes fixes.

🏗️ Systems Architect

Verdict: Sound foundation, two structural gaps.

✓ Separation of concerns is correct: governance (rules), knowledge (data), agents (behavior), projects (work), ops (plumbing).
✓ Progressive disclosure aligns with Anthropic's context engineering guidance — small files eager-loaded, large corpus queried on demand.
✓ Flat-over-deep principle (max 3 levels) is the right call for agent navigability.
✗ Code has no home. The repo contains executable code (Python scripts, shell scripts, world-model service, LaunchAgent plists) but the architecture doesn't explicitly place it. Currently scattered across agents/forge/code/, agents/forge/world-model/, ops/scripts/, and agents/shogun/scripts/. Need a clear code/ or src/ convention.
✗ Config has no home. LaunchAgent plists, nginx configs, Docker compose files, systemd units — these are currently managed by Forge but don't have a designated location. They're infra, not docs.
Recommendation: Add top-level code/ directory for executable code, or keep it in agents/forge/ with an explicit infra/ subfolder for configs.

🔒 Security & Access Control

Verdict: Write safety is the biggest risk. Two critical recommendations.

✗ No write locking. Two agents can overwrite each other's changes on the same file. This is a real risk for governance/DECISIONS.md (append-only, multiple writers) and projects/*/plan.md (multiple agents).
✗ Agent boundaries are convention-based, not enforced. Nothing stops Forge from writing to agents/shogun/ except the CLAUDE.md instruction. A confused or drifting agent could violate boundaries.
✓ Git history provides an audit trail for all changes, which is a safety net.
✓ Sentinel audits can detect boundary violations after the fact.
Recommendation 1: Implement a write-access matrix by directory (see Write Safety tab). Some dirs need "single-writer" rules enforced by convention + Sentinel monitoring.
Recommendation 2: For append-only files (DECISIONS.md), use a script that locks the file, appends, unlocks — preventing concurrent corruption.

📊 Operations & Cost

Verdict: Operationally clean. Watch the knowledge/ size in Git.

✓ Log rotation in ops/ is well-defined (10MB/7 days). This prevents the current 32MB bloat.
✓ Staging pipeline has clear lifecycle — nothing should accumulate.
✓ Project archive after 30 days prevents dead weight.
⚠ knowledge/ is 475MB. If tracked in Git, every clone is 475MB+ plus history. Recommend: .gitignore knowledge/ and sync via Obsidian Sync or rclone. Git tracks governance/, agents/, projects/, ops/ only (~50MB).
⚠ project/*/logs/ could accumulate. Per-agent daily logs for each project = many small files. Need rotation rule: keep 30 days, archive older.
Recommendation: Define a Git-tracked vs. sync-only boundary. governance/ + agents/ + projects/ + ops/scripts/ = Git. knowledge/ + ops/logs/ + ops/briefs/ = sync-only.

🤖 Agent UX & Developer Experience

Verdict: Excellent navigability. One UX concern.

✓ Self-documenting names are a massive improvement over System_OS / 01-Knowledge-Base.
✓ Required files (SOUL.md, CLAUDE.md, README.md) create consistent entry points. An agent can always cat agents/*/SOUL.md or cat projects/*/README.md for a system overview.
✓ Template system prevents blank-page paralysis.
⚠ Agent "skills/" is ambiguous. OpenClaw has a formal SKILL.md pattern in ~/.openclaw/workspace/skills/. The agent workspace skills/ folder holds different content (lessons, protocol — reference docs, not SKILL.md files). This could confuse agents that look for SKILL.md files.
Recommendation: Rename agent skills/ to playbook/ or reference/ to avoid collision with OpenClaw's skill system. Or keep it and add a README.md in skills/ clarifying it's operational reference, not SKILL.md skills.

👤 CEO / Stakeholder Experience

Verdict: Much better than current state. One gap for Pat's workflow.

✓ Pat can ls projects/ to see all active work — huge improvement over digging through 3 vaults.
✓ Briefs served via HTTP — Pat doesn't need to open Obsidian to see status.
✓ ops/staging/from-pat/ is a clear drop zone — Pat knows exactly where to put files.
⚠ Where does Pat take quick notes? Pat often uses Obsidian for quick thoughts. Currently drops them in various places. Need a designated "Pat's notes" location that Shogun monitors. Could be ops/staging/from-pat/ or a dedicated knowledge/pat/notes/.
⚠ Entity context (DxD, HoldCo) buried under agents/shogun/entities/. If Pat is looking for DxD context, he has to know it's inside Shogun's workspace. Should DxD context live in knowledge/dxd/ instead? Or should entities/ be top-level?
Recommendation: Move business entity operating contexts to knowledge/ (where Pat would intuitively look). Keep only agent-specific entity stubs (CLAUDE.md) in agents/shogun/entities/.

MoE Consensus Findings

Finding	Severity	Fix
Code has no explicit home	High	Add `code/` or `infra/` convention — see Claude Code tab
Concurrent write risk	High	Write-access matrix + single-writer rules — see Write Safety tab
knowledge/ too large for Git	Medium	Define Git-tracked boundary — see Git tab
Agent skills/ naming ambiguity	Low	Add README.md to skills/ or rename to playbook/
Entity contexts buried in agent dir	Medium	Move business context to knowledge/, keep agent stubs
Pat's quick notes have no home	Low	`ops/staging/from-pat/` handles this

💻 Claude Code Interaction Model

How Forge (Claude Code) interacts with the vault. The CLAUDE.md chain. Where code lives.

How Claude Code Works Today

The CLAUDE.md Chain

When Claude Code opens a session, it reads CLAUDE.md files from the working directory upward:

Root ~/ShogunOS/CLAUDE.md — Currently says "You are Forge." This is the entry point for every Claude Code session.
Subdirectory CLAUDE.md — If Claude Code cds into agents/forge/, it reads that CLAUDE.md too (extends parent).
Project CLAUDE.md — A project could have its own CLAUDE.md with project-specific instructions.

Key insight: Claude Code almost always IS Forge. Pat launches Claude Code at the repo root → it reads root CLAUDE.md → it becomes Forge. This is correct and should be preserved.

Proposed CLAUDE.md Architecture

File	Contains	Who It Serves
`~/ShogunOS/CLAUDE.md`	System overview + Forge identity + vault map + operating principles. This is the PRIMARY identity file for Claude Code.	Forge (Claude Code)
`agents/forge/CLAUDE.md`	Forge-specific workspace details: project list, key files, current priorities	Forge when working in its own dir
`agents/shogun/CLAUDE.md`	Shogun-specific orientation (for when Claude Code reviews Shogun's workspace)	Any agent reviewing Shogun's dir
`projects/*/CLAUDE.md`	Optional: project-specific instructions for Claude Code sessions on that project	Forge when working on a specific project

Design: Root CLAUDE.md stays Forge-oriented. Shogun runs on OpenClaw (reads SOUL.md/AGENTS.md, not CLAUDE.md). There's no conflict — they use different identity systems.

Where Does Code Live?

The Problem

The repo contains multiple types of executable code with no clear placement:

Service code — world-model Python app (currently in agents/forge/world-model/)
Automation scripts — mailbox_send.sh, sentinel_alert.sh (currently in various scripts/ dirs)
Infrastructure configs — LaunchAgent plists, nginx configs, Docker compose
Project code outputs — investor portal HTML, dashboard code

Recommendation: Keep Code in agents/forge/ with Clear Subdirs

Code is Forge's domain. Other agents don't write code. So code stays in Forge's workspace, organized by purpose:

Code Type	Location	Example	Git-Tracked?
Service code (applications)	`agents/forge/services/`	world-model app, brief server	Yes
Infrastructure configs	`agents/forge/infra/`	LaunchAgent plists, nginx, Docker compose	Yes
Shared scripts	`ops/scripts/`	mailbox_send.sh, log-rotate.sh	Yes
Agent-specific scripts	`agents/*/scripts/`	Shogun's briefing generator	Yes
Project code outputs	`projects/*/artifacts/`	Investor portal HTML	Yes (if text), No (if binary)
Runtime data (ChromaDB, venvs)	`agents/forge/services/*/data/`	chromadb_store/, .venv/	No (.gitignored)

Why not top-level code/? Because code is Forge-owned. Putting it in agents/forge/ maintains the ownership principle. Shared scripts go in ops/scripts/ because any agent can use them. This matches the "who writes it?" principle throughout the system.

Claude Code Workflow

Step	What Happens	Files Touched
1. Pat or Shogun requests work	Mailbox → `ops/mailbox/forge/inbox/`	Mailbox message
2. Forge (Claude Code) starts session	Reads root CLAUDE.md → becomes Forge	`CLAUDE.md`
3. Forge reads the request	Checks inbox, reads project context	`ops/mailbox/`, `projects/*/README.md`
4. Forge works	Writes code, configs, architecture docs	`agents/forge/`, `projects//artifacts/`
5. Forge commits	`git add` + `git commit` with descriptive message	Git index
6. Forge reports done	Writes DONE message to Shogun's mailbox	`ops/mailbox/shogun/inbox/`
7. Forge logs	Updates memory + changelog	`agents/forge/memory/`, `agents/forge/CHANGELOG.md`

🔒 Write Safety — Who Can Write Where

The concurrent-write problem is real. Here's the access matrix and mitigation strategy.

Write Access Matrix

Directory	Write Model	Who Writes	Concurrent Risk	Mitigation
`governance/`	Single-writer + approval	APEX proposes → Pat approves. No ad-hoc edits.	Low	ADR process gates all changes. Sentinel monitors for unauthorized writes.
`governance/DECISIONS.md`	Append-only, serialized	Any agent can append (via script)	Medium	Use `decisions-append.sh` with file locking (`flock`). Never edit existing entries.
`knowledge/`	Pipeline-owned	Network SME, Librarian, ingestion pipelines	Low	Each agent owns specific subdirs. Network SME → people/. Transcript skill → transcripts/. No overlap.
`agents/<name>/`	Owner-only	Only the named agent	None	Sentinel flags any write by non-owner. CLAUDE.md boundaries.
`projects/*/README.md`	Owner-only	Only the project owner (listed in README.md)	Low	Owner updates status. Others read only.
`projects/*/plan.md`	Owner-only	Only the project owner	Low	Same as README.md.
`projects/*/artifacts/`	Multi-writer, file-level ownership	Any participating agent writes their own files	Medium	Each agent creates their own files (no two agents edit the same file). Naming convention: `agent-slug.md`.
`projects/*/logs/`	Multi-writer, no overlap	Each agent writes `YYYY-MM-DD-agentname.md`	None	Filenames prevent collision by design.
`projects/*/history/`	Append-only	Any agent adds new files (never edits old)	None	New files only. Old history files are immutable.
`projects/*/memory/`	Owner-only	Project owner maintains context.md, open-questions.md	Low	Single maintainer.
`ops/mailbox/`	Multi-writer, no overlap	Any agent writes to any inbox, unique filenames (timestamped)	None	Timestamp + sender in filename prevents collision.
`ops/briefs/`	Single-writer	Shogun generates all briefs	None	One generator.
`ops/staging/`	Multi-writer intake, single-writer triage	Anyone drops files. Shogun triages exclusively.	Low	Intake is additive. Triage (move/delete) is Shogun only.
`ops/logs/`	Service-owned	Each service writes its own log file	None	One writer per log file by definition.
`ops/scripts/`	Forge-only	Forge maintains all shared scripts	None	Single maintainer.

The Three Write Models

1. Owner-Only (safest)

One agent owns the file/dir. Nobody else writes.

Used for: agent workspaces, project README/plan, governance files, ops/scripts

Enforcement: CLAUDE.md instructions + Sentinel monitoring

2. Multi-Writer, No Overlap (safe by design)

Multiple agents write, but file naming prevents collision.

Used for: mailbox (timestamped), project logs (agent-named), project history (date+slug), staging (intake)

Enforcement: Naming convention makes collision impossible

3. Append-Only, Serialized (requires tooling)

Multiple agents append to the same file. Requires locking script.

Used for: DECISIONS.md only

Enforcement: decisions-append.sh using flock for file-level locking. Never edit existing content — only append new entries.

Key insight: By designing the naming conventions correctly, most concurrent-write risk disappears. The only truly dangerous pattern (two agents editing the same file) is eliminated everywhere except DECISIONS.md, which gets a locking script.

📦 Git & GitHub Strategy

What's tracked, what's synced, how code ships.

Git-Tracked vs. Sync-Only

Directory	Git-Tracked?	Size	Rationale
`governance/`	✅ Yes	~1 MB	Constitutional docs need version history. Every change auditable.
`knowledge/`	❌ No (.gitignored)	~475 MB	Too large for Git. Synced via Obsidian Sync + rclone. World-model API is primary access.
`agents/`	✅ Yes (except runtime data)	~5 MB	Agent identity and skills need version history. .gitignore: chromadb_store/, .venv/, *.log
`projects/`	✅ Yes	~10 MB	Project decisions and artifacts need audit trail.
`ops/scripts/`	✅ Yes	~100 KB	Automation scripts are code — need version control.
`ops/mailbox/`	⚡ Optional	Variable	Historical value but high churn. Could .gitignore and rely on filesystem.
`ops/briefs/`	❌ No	Variable	Regenerated daily. No version history needed.
`ops/staging/`	❌ No	Variable	Transient. Files move to final home.
`ops/logs/`	❌ No	Variable	Rotated. Already .gitignored.
`archive/`	⚡ Selective	~46 MB	Keep lightweight archives. .gitignore large binary archives.

Estimated Git Repo Size After Restructure

~16 MB Git-tracked content (governance + agents + projects + ops/scripts). Down from current ~50MB+ with cleaner boundaries. The 475MB knowledge/ is out of Git entirely.

Git Workflow

Who	Commits	Branch Strategy	Push Cadence
Forge	Code changes, infra configs, architecture docs	Direct to `main` for routine. Feature branches for major changes.	After every significant work session
Shogun	Does NOT commit directly. Shogun runs on OpenClaw, not Claude Code.	N/A	N/A — Shogun's writes are picked up in Forge's next commit, or auto-committed via a cron job
Auto-commit cron	Catches Shogun's memory writes, mailbox messages, captures	`main`	Every 30 min (if changes exist)
Pat (Obsidian)	Direct edits via Obsidian Sync → Engine	Obsidian Sync handles. Git picks up on next auto-commit.	Passive

GitHub Remote

Current State

Remote: github.com/patrickrmadden-byte/ShogunOS (private repo)

Issue: 34 local commits with no shared ancestry to GitHub. Forge flagged this as a pain point — needs a sync reconciliation.

Post-Restructure

Force-push the new structure as a clean starting point (after backup)
Or: create a new branch v2-restructure and merge
GitHub becomes the off-site backup + collaboration point
GitHub Actions could run Sentinel checks on every push (future enhancement)

Code vs. Docs: "Docs in the vault. Code in the repo." — the existing Forge principle stays. The repo IS the vault. There's no separate code repo. All code (services, scripts, infra configs) is tracked in Git alongside docs. The .gitignore boundary separates tracked (small, auditable) from untracked (large, transient).

🔧 Proposed Improvements

Changes to the v3 blueprint based on stress testing and MoE review.

#	Change	Why	Impact
1	Add `agents/forge/services/` for application code and `agents/forge/infra/` for infrastructure configs	Code currently has no explicit home. Forge owns all code.	Resolves stress test scenarios #4 and #13
2	Move business entity operating contexts (DxD, HoldCo) to `knowledge/`. Keep only CLAUDE.md stubs in `agents/shogun/entities/`	MoE CEO expert: Pat looks for DxD info in the knowledge base, not inside Shogun's workspace	Better discoverability for Pat
3	Create `ops/scripts/decisions-append.sh` with file locking for DECISIONS.md	Only append-only multi-writer file in the system. Needs locking.	Eliminates concurrent-write risk
4	.gitignore `knowledge/` entirely. Sync via Obsidian Sync + rclone.	475MB is too large for Git. World-model API is primary access anyway.	Repo drops from ~525MB to ~16MB
5	Add auto-commit cron (every 30 min) for Shogun's writes	Shogun runs on OpenClaw (no Claude Code, no git access). Its writes need to be committed.	Shogun's memory, captures, and mailbox messages get version-tracked
6	Add README.md to `agents/*/skills/` clarifying it's operational reference, not OpenClaw SKILL.md files	MoE Agent UX expert: naming ambiguity with OpenClaw's skill system	Prevents agent confusion
7	Add project log rotation: 30 days, then consolidate to single archive file	MoE Ops expert: project logs could accumulate without bounds	Prevents project dir bloat
8	Add Nomad sync rule: `governance/` + `agents/shogun/` + active `projects/` (via Git sparse checkout)	Stress test #11: Pat needs project context on travel	Resolves Nomad access gap

Updated Structure (Incorporating Fixes)

Changes from v3 shown with NEW tags:

ShogunOS/
├── CLAUDE.md              ← Forge identity (Claude Code entry point)
├── README.md              ← Human onboarding
│
├── governance/            ← Git-tracked. Read every session.
│   ├── SYSTEM.md
│   ├── DECISIONS.md       ← append via decisions-append.sh (flock)
│   ├── SYSTEM_LESSONS.md
│   ├── THE_AGENT_DOCTRINE.md
│   ├── decisions/
│   ├── frameworks/
│   ├── integrations/
│   └── metrics/
│
├── knowledge/             ← .gitignored. Synced via Obsidian/rclone.
│   ├── people/
│   ├── orgs/
│   ├── transcripts/
│   ├── digests/
│   ├── reference/
│   ├── pat/
│   ├── dxd/               ← NEW: DxD business context (moved from entities)
│   ├── holdco/            ← NEW: HoldCo context (moved from entities)
│   ├── montauk/           ← NEW: Montauk context (moved from entities)
│   ├── graph/
│   └── staging/
│
├── agents/                ← Git-tracked.
│   ├── shogun/
│   │   ├── SOUL.md, CLAUDE.md, MEMORY.md, HEARTBEAT.md
│   │   ├── memory/
│   │   ├── skills/
│   │   │   └── README.md  ← NEW: clarifies these aren't SKILL.md files
│   │   ├── entities/      ← CLAUDE.md stubs only (business context in knowledge/)
│   │   └── scripts/
│   │
│   ├── forge/
│   │   ├── SOUL.md, CLAUDE.md, FORGE_DOCTRINE.md, CHANGELOG.md
│   │   ├── memory/
│   │   ├── skills/
│   │   ├── architecture/
│   │   ├── services/      ← NEW: application code (world-model, brief-server)
│   │   ├── infra/         ← NEW: LaunchAgents, nginx, Docker configs
│   │   ├── specs/
│   │   └── code/          ← symlinks to service code if needed
│   │
│   └── sentinel/
│
├── projects/              ← Git-tracked.
│   └── <name>/
│       ├── README.md, plan.md
│       ├── decisions/, artifacts/, research/
│       ├── history/, memory/, logs/
│       └── archive/
│
├── ops/                   ← scripts/ Git-tracked. Rest .gitignored.
│   ├── mailbox/
│   ├── briefs/
│   ├── staging/
│   ├── logs/
│   └── scripts/
│       ├── mailbox-send.sh
│       ├── decisions-append.sh  ← NEW: flock-based append for DECISIONS.md
│       ├── auto-commit.sh       ← NEW: 30-min cron for Shogun's writes
│       └── log-rotate.sh
│
└── archive/

Result: All MoE findings addressed. All stress test gaps closed. Write safety handled by design (naming conventions) + tooling (flock script). Code has a home. Git boundary is clean.

🔬 Vault Architecture — Stress Test & MoE