titan-evolution-looplisted

# Titan Evolution Loop ## Why titans evolve A titan dispatched once and never updated is a one-shot oracle. It encodes its mandate at authoring time and drifts from reality with every new failure mode, every new anti-pattern, every new sub-system it touches. The second dispatch of the same titan class will make the same mistakes the first one made — unless the intelligence from the first run is captured, validated, and promoted into the titan's PROMPT-BRAIN before the next launch. This is the feedback loop problem [[intelligence-accumulation]] was written to solve. Titans are expensive (4-6h opus wall clock, multiple sub-worker waves, significant token spend). Repeating avoidable errors across runs is a direct cost multiplier. Worse, silent failure propagation — a sub-worker pattern that degrades output quality mid-mission — is invisible unless the post-mortem surfaces it explicitly. The evolution loop exists because: 1. **Recurring failures are worth more than one-time fixes.** A bug fixed in the codebase but not recorded in the titan's PROMPT-BRAIN will resurface the next time that titan class is dispatched. 2. **Wins are equally perishable.** A sub-worker dispatch pattern that worked well (e.g., serializing writers on `mcp_server.js` via FILE-OWNERSHIP) should be codified so the next titan inherits it without rediscovery. 3. **PROMPT-BRAIN drift compounds.** After 3-4 undocumented runs, a titan's PROMPT-BRAIN diverges so far from observed behavior that it becomes misl