📝 Add Athanor trunk/fork provenance and headless fork-session research

Co-Authored-By: Claude <noreply@anthropic.com>

docs/workpad/journals/2026-10-15-21-grotto-work.md

@@ -20,6 +20,48 @@
 - Re-dispatched the orientation research (researcher, model: opus) over the new files → reports/2026-10-15-21-grotto-orientation-baseline.md.
 - Report back: reports/2026-10-15-21-grotto-orientation-baseline.md (stamped claude-opus-5-5). Grotto exists only as decisions in goals/drop-superpowers-0.2.2.md, with no code yet. No planning role reads project docs systematically. Hypothesis: nested CLAUDE.md files load lazily (only when a path under them is touched), so the planner sees constraints only along the paths it happens to open. That would make the superpowers "luck" structural. Superpowers itself has one checklist line for this. The report lists 7 placement options and gives no verdict. Unverified: the details of the Python project, superpowers v7, and whether nested CLAUDE.md files load in subagents.
 - User: the one superpowers sentence ("Explore project context — check files, docs, recent commits") may be load-bearing. The 0.2.2 session found that single sentences steer Opus 5.5 more than expected. There's precedent: a misread sentence contributed to the chatgpt-importer blow-up (counted under "even 0.2.0 athanor had issues"). An experiment is running in the other project, comparing plan + implementation from Spire 0.2.2 against superpowers. Igor's observation, a hypothesis not a decision: the planner's one orientation line says "Read the code the plan touches", which names code and not docs. That may actively narrow attention, so the gap could be the wording rather than a missing stage.
+- Committed the journal + report (ec7c299, Haiku 5.5 subagent) and pushed main: 8028411..ec7c299, fast-forward, includes the rebased b881162. In sync with origin. Waiting for the user's experiment results (Spire 0.2.2 vs superpowers, plan + implementation).
+- Pulled bbda8fc: reports/2026-10-15-22-spire-vs-superpowers-plan-and-build-experiment.md. Igor read it for synthesis.
+  - Plans: B (superpowers) beat raw A; C (attacked A) beat B narrowly.
+  - Build: the blind judge chose to merge Spire. Its edge came from route-level count pins, the attacker's fallback clause and a fresh reviewer; two of those three come from the attacker.
+  - "Code in plan adds nothing" is supported, n=1, with confounds.
+  - Rule discovery: confirms both of this session's hypotheses (wording: "read the code" vs "docs they might need to check"; and Bash reads bypassing on-demand nested CLAUDE.md loading). Plus luck: a single `cat` right after an `ls`.
+  - Proposals for planner, attacker, athanor, reviewer and Igor, including: Conventions section in the plan, attacker conventions pass, Skill tool for planner/attacker/reviewer.
+  - Igor note: this session's own system prompt (auto mode) carries the same "read files with cat … instead of Read" nudge, so the harness factor isn't limited to bypass mode.
+- Talked through the probe's shape. **The user endorsed Igor's recommendation as the direction**; it's still at document-preparation stage, so no goal or plan has been written yet:
+  - Both artifacts. A separate **orientation probe** runs *after design, before plan*, by an agent with no stake in the plan, cheap tier (mechanical sweep: Haiku/Sonnet). It explicitly opens CLAUDE.md/AGENTS.md along the target paths and the layers called into, the ADRs those cite, sibling areas (reader↔writer), and 1–2 similar implementations with paths. It stamps the commit and writes **separate notes** at a fixed path.
+  - Plan carries an inline **Conventions section** (rules relied on or at risk, file:line), which is what the plan binds to.
+  - The attacker's conventions pass **diffs notes vs. section**: a rule in the notes that the plan neither follows nor explicitly waives is a finding. This makes a miss detectable; a section alone can't show absence.
+  - Notes are revisited by the planner when stuck, by the attacker (mandatory diff) and by the reviewer (convention-deviation check).
+  - Caveats: the notes are a floor, not a fence (the planner's wording must still say docs + conventions); cap similar implementations; drift → notes are per-change, not a knowledge base.
+  - Open (user's call): whether the probe notes feed adept folders, which would tension with grotto standing alone.
+- User raised the token angle from the experiment report; discussed below.
+- Token angle discussed. Spire 78.05 M all / 2.69 M excl. cache; superpowers 54.57 M / 4.12 M. The Athanor's 1M-context cache reads dominate the Spire total. Model mix and unpriced columns block a cost verdict.
+- User: was the superpowers orchestrator (the SDD controller) measured, given that the Athanor was? The report doesn't say. Its "10 agents without reviewers" fits controller + 9 implementer dispatches, but that isn't stated. The general bias is real either way: orchestration living in a measured subagent gets counted, orchestration in the root doesn't. On Spire's side the root's work (Igor dispatching 4 reviewers, writing the addendum) is explicitly uncounted. Open thread: check the other project's audit to see whether the controller transcript was summed.
+- User: Spire looks more cost-efficient, since cache reads cost 10 %. Igor's rough check at 10 %: Spire 75.4 M reads → 7.5 M + 2.69 M ≈ 10.2 M input-equivalent; superpowers 50.5 M → 5.0 M + 4.12 M ≈ 9.2 M. That's roughly even, not clearly Spire. The "excl. cache read" column mixes input, cache writes and output (all priced differently), and the model mix differs (superpowers is more Sonnet). The controller question is still open. A real answer needs per-column, per-model pricing.
+- User asked how forks work and what the Athanor did. Explained from athanor.md:32, implementation SKILL.md:49 and spawning-claude-code.md:56-64. The Athanor built B1.1, B1.4 and B2.1 inline because no fork type was offered. **Igor correction:** the earlier claim that working forks "would cut most of the 7.5 M" was overstated. A fork is assumed to start with the caller's full transcript, so it would re-read the same context; the saving is only that the Athanor's own context grows less for later turns. Net effect unmeasured.
+- User: their original Athanor intent was different. The Athanor learns plans + design (not code), delegates on that basis and reads implementer reports. For a hard task it trains up ONE implementer early with background info, then forks THAT implementer per subsection. The current docs have the Athanor read the code (trunk) and fork itself. Either this wasn't communicated, or evidence overruled it. Dispatched a provenance research (researcher, opus) → reports/2026-10-15-23-athanor-trunk-fork-provenance.md. Igor note: the spawning reference says a fork copies the *caller*, so "fork the trained implementer" may only be expressible if the implementer forks itself. Possible harness constraint.
+- Provenance report back: reports/2026-10-15-23-athanor-trunk-fork-provenance.md (claude-opus-5-5, uncommitted). Finding (c), close to (a):
+  - On 10-05 the user's idea was journaled as a "trunk implementer, forks per task, updated by orchestrator", i.e. separate from the Athanor.
+  - The Opus redesign subagent moved the trunk into the Athanor on the reasoning "fork copies the caller". It took that from Igor-skill wording, not from a test.
+  - Igor proposed "intake=trunk"; the journal says "User: fully agreed". The actual words aren't preserved.
+  - "Athanor learns plans, not code" was never written down, and was never blocked by the harness either; it was lost as a side effect.
+  - Harness (official docs, fetched today): a fork copies the caller only; forks can't fork; fork mode makes every subagent background (clashes with foreground-sequential). Whether a subagent can fork itself is undocumented.
+  - Overlooked route: the trained implementer forks itself per subsection (depth limit, sub-orchestrator).
+- (Past midnight, now 10-16.) User: the fork idea isn't good via the Agent tool, except perhaps by starting such an agent with `claude -p`. Igor: headless sessions can be resumed and forked by session id (`--resume <id> --fork-session`, unverified in the current CLI), which would make "train one implementer, fork it per subsection" expressible from outside the caller. Caveats: outside the Agent-tool notification and accounting machinery; permissions, plugins and model must be passed explicitly; transcripts must be counted.
+- 00:44 — Dispatched a headless-fork verification (researcher, opus). It may run a minimal local test with haiku in the scratchpad, ~10 invocations. Report → research/2026-10-16-00-claude-headless-fork-sessions.md.
+- Headless-fork report back: research/2026-10-16-00-claude-headless-fork-sessions.md (claude-opus-5-5). Local test: 7 runs, ~$0.13, CLI 2.1.283.
+  - The pattern works: `claude -p --resume <base> --fork-session` once per subsection. Forks see the base and not each other, the base is unaffected, parallel forks work, forks of forks work.
+  - The cache is shared only with identical flags (14.6 k read per fork vs 0 when flags differed). The cache lifetime is 1 h, so forks spaced further apart pay full price again.
+  - Launch flags do not carry over: forks need permission mode and tools re-passed. A headless permission prompt is denied, not answered. The system prompt and model carry over. The spire plugin loads without `--bare`.
+  - Running from a subagent's Bash is unguarded and untracked: the orchestrator must block on Bash or poll the JSON output. Transcripts are per fork under ~/.claude/projects/.
+  - Oddities: `--model haiku --permission-mode plan` ran on sonnet-5. The nested run inherited Desktop tools and the messaging channel. The `claude` on PATH is older than the host's.
+- Follow-up verification appended to the headless-fork research (8 runs + 1 nested, ~$0.35).
+  - Depth: the count is per process. A nested `-p` can spawn subagents and further `-p` runs. The limit is silent: the Agent tool just disappears.
+  - Model oddity: plan mode upgrades Haiku to Sonnet. The init event still reports haiku; only modelUsage shows the real model.
+  - Desktop env: removing 12 vars with `env -u` drops the Desktop tools. `--bare` needs an API key, since it refuses OAuth. The messaging socket is the nested run's own pipe; whether it can reach the host is unverified.
+  - Cache TTL (docs): 1 h for main conversations, incl. `-p` and `--fork-session`, on a subscription within plan usage; otherwise 5 min, which also covers Agent-tool forks and subagents. Configurable via CLAUDE_CODE_PROMPT_CACHE_TTL / CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL. A hit resets the timer. Forks must run from the same cwd.
+  - Version: two installs (~/.local/bin 2.1.283 vs the Desktop's $CLAUDE_CODE_EXECPATH 2.1.299). Use one binary and a full model id for the base and all forks.
 
 ## Adepts
 
@@ -28,6 +70,16 @@
 ## Artifacts
 
 - docs/workpad/reports/2026-10-15-21-grotto-orientation-baseline.md — orientation baseline for grotto (what exists, how roles orient, placement options)
+- docs/workpad/reports/2026-10-15-23-athanor-trunk-fork-provenance.md — how the trunk moved from a separate implementer into the Athanor
+- docs/workpad/research/2026-10-16-00-claude-headless-fork-sessions.md — headless `claude -p --resume --fork-session` mechanics, local tests + follow-up
+- Input (user's): docs/workpad/reports/2026-10-15-22-spire-vs-superpowers-plan-and-build-experiment.md
+
+## Open threads
+
+- Was the superpowers SDD controller's transcript summed in the experiment's token totals? Check the other project's audit.
+- Probe design (user-endorsed direction) → goal or grotto design document when document prep is done.
+- The user's original Athanor model (learns plans, not code; train one implementer, fork it per subsection) is now expressible via headless forks. Not decided.
+- The spawning reference (spawning-claude-code.md:56-64) has rows that today's research answers; not edited yet.
 
 ## Open threads