Frame config immutability as the point, not a trade-off
Goal 4 now states the principle directly: config is read-only in the
container and the outbox is the only path for stateful modification of
shared config, while agent runtime state (auth, history) persists via
direct writable mounts. Reframe the copy-and-clear lesson accordingly:
its silent loss of in-container edits had the right intent but read-only
mounts enforce it loudly at write time.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LDUQnA7QT8CtTfqZ6JE5vJ
change
commit da08f2a6f2b09c3b866e1350e2335c5bf4c83a32
author Claude <noreply@anthropic.com>
date
parent a1516a3c
diff --git a/docs/config-redesign.md b/docs/config-redesign.md
index fb5b007..8f0edff 100644
--- a/docs/config-redesign.md
+++ b/docs/config-redesign.md
@@ -12,10 +12,11 @@ from here, not a baseline to preserve.
    from any machine and any project.
 3. **Overridable everything** — any shared setting can be overridden closer
    to the point of use: per machine, per project, per run.
-4. **Safe outbound sharing** — when the agent improves a skill or memory file
-   inside the container, there's a reviewed path for that change to land back
-   in the shared source of truth. Dotfiles are never writable from inside the
-   container.
+4. **Immutable config, outbox for everything stateful** — configuration is
+   read-only inside the container; in-container edits to it are deliberately
+   impossible, not merely ephemeral. The outbox is the single reviewed path
+   for any stateful modification to shared config. Dotfiles are never
+   writable from inside the container.
 5. **Multiple sessions** — concurrent ramekin runs (same repo or different,
    same agent or different) don't interfere with each other.
 
@@ -25,9 +26,14 @@ From `main`:
 
 - Layered KDL config with per-target merge and scope-labelled `ramekin
   config` output works well; keep the shape.
-- Copy-and-clear assembly of the agent dir is the root of two problems: it
-  loses in-container edits (goal 4) and a second session's clear yanks files
-  out from under the first (goal 5). It doesn't survive this redesign.
+- Copy-and-clear assembly of the agent dir doesn't survive this redesign,
+  for two reasons. The fatal one is concurrency: a second session's clear
+  yanks files out from under the first (goal 5). The subtle one is that it
+  gets goal 4's semantics *almost* right — in-container edits to config
+  should not stick, and with copies they don't — but silently: the agent can
+  edit its config, believe it worked, and lose it on the next run. Read-only
+  mounts enforce the same intent loudly, at write time, which is what steers
+  the agent to the outbox.
 
 From `claude-code`:
 
@@ -122,8 +128,12 @@ read-only by design (goal 4); the outbox is the write path.
 
 ### Session model
 
-Everything a run touches is either *persistent agent state*, *shared config
-(read-only)*, or *session-scoped (fresh per run)*:
+The design distinguishes two kinds of mutation. **Agent runtime state**
+(auth tokens, account identity, session history) persists via direct
+writable mounts — the agent owns it and it must survive every run.
+**Configuration** (memory files, skills, settings sourced from dotfiles) is
+immutable in the container; the outbox is its only write path. Everything a
+run touches falls into one of three buckets:
 
 - **Persistent, shared across sessions:** the agent state dirs —
   `$XDG_DATA_HOME/ramekin/agents/pi/` and `agents/claude/` (+