docs: continuous_improvement runs honestly and cannot reach its subject

Its first run separated running from working. All three roles handed off
with attributed commits; it filed zero level-up proposals, committed "no
proposals warranted, evidence base too thin", and opened its audit by
naming the problem exactly: no .brain is accessible from the mission
filesystem because brains are held in the platform.

That is structural. The template's subject is every agent's .brain,
which lives in the server's /data/brains volume, and nothing delivers
brains into a mission — the same defect class as research and skills
having had no delivery channel. It audited the only agent-shaped thing in
reach, a ROSTER.md in the scratch repo, and read a guest kernel version
as an agent version. Not counted as evidenced.

A channel alone would not fix it: per-mission crews carry ~2 KB seed
brains with no history, because missions write memory to the repo brain.
The template assumes long-lived agents; the platform makes disposable
ones. Recorded as a design decision, not patched.

Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01WZb5A2kfVfjpdwSochkuHz

docs/TEMPLATE-MATURITY.md

@@ -65,7 +65,7 @@ holding (it was 55 of 85 dangling once).
 | `codebase_research` | code_archeologist architecture_mapper flow_tracer vault_scribe | research_readonly | 11 | **yes** — first run 2026-09-22 |
 | `papers_research` | domain_scout paper_reader library_curator | research_web_readonly | 8 | **yes** — first run 2026-09-22 |
 | `insight_research` | implementation_tracker novelty_hunter publication_drafter | research_readonly | 8 | no |
-| `continuous_improvement` | brain_inspector improvement_proposer improvement_evaluator | research_readonly | 7 | no |
+| `continuous_improvement` | brain_inspector improvement_proposer improvement_evaluator | research_readonly | 7 | **runs, cannot reach its subject** |
 
 **Six of twelve are evidenced.** `backend` was exercised on 2026-09-22,
 the first time anything had been staffed from it: all five roles
@@ -98,7 +98,32 @@ the operator's own research pass had already cited, which is independent
 evidence it found on-topic work rather than plausible filler. **Six of
 twelve.**
 
-**Two of the remaining six are still unevidenced.** The other nine are well-formed scaffolding:
+`continuous_improvement` ran too, and gets a different grade, because
+running and working came apart. All three roles handed off with
+attributed commits, and it was scrupulously honest: it filed **zero**
+level-up proposals, its proposer committed *"no proposals warranted,
+evidence base too thin"*, and its audit opens by stating the problem
+exactly — *"No `.brain` files are accessible within the repo or mission
+filesystem — brains are held in the platform, not checked in."*
+
+That is the defect, and it is structural rather than a matter of data.
+The template's subject is "every project agent's `.brain`"; those live in
+the server's `/data/brains` volume, and **nothing delivers them into a
+mission** — the same shape as `research-has-no-delivery-channel` and
+`skills-had-no-delivery-channel`. So it audited the only agent-shaped
+thing in reach, a `ROSTER.md` in the scratch repo, and read that file's
+`6.1.128` (a guest kernel version) as an agent version, having no way to
+know better. It is not counted as evidenced.
+
+A channel alone would not rescue it. Mission crews are minted per mission
+(reuse is off by decision), and missions write memory to the *repo* brain,
+so every agent brain is a ~2 KB seed with no history to audit. The
+template assumes long-lived agents that accumulate a record; the platform
+makes disposable ones. That is a design decision to resolve, not a bug to
+patch.
+
+**Two of the remaining six are still unevidenced**, and the other four
+are blocked on a target stack. The other nine are well-formed scaffolding:
 roles, prompts, brain seeds and resolving skills, and no run behind any of
 them. They will probably work — they are structurally identical to the three
 that do — but "probably" is the word, and this codebase has a name for the gap