Pre-stage substrate for another in-flight session
When another Claude session is mid-flight on a Q-lock / batch / declaration, the orchestrator session (or any other parallel-safe session) can pre-stage substrate that the in-flight session MAY pick up. This is a parallel-safe extension of feedback_spikes_inline_not_tasked.md — the spike happens NOT in the session that needs the substrate, but in a sibling session that can do it without conflict.
Why this matters
Some inline-spike opportunities surface DURING another session’s execution. The in-flight session can’t take the time to spike them (different file-isolation scope; would interrupt its own phase progression). But a sibling session CAN. The result: substrate is ready when the in-flight session reaches the discovery moment.
This is distinct from:
- Tasking the spike (defers → loses learning per spike-inline-not-tasked)
- Asking the in-flight session to spike (interrupts its phase progression)
- Skipping the spike (locks in aspirational substrate)
Pre-staging from a sibling session captures the spike yield without disrupting any session’s file-isolation.
When this rule applies
| Trigger | Example |
|---|---|
| In-flight session has known DECISION fork that substrate could inform | Q-044 fork (IP vs Crypto) — sibling can pre-stage T-file research for both candidates |
| In-flight session has known DEFERRAL fallback that substrate could pre-empt | ω.4 task-73 BAILII fallback — sibling can pre-verify URL works |
| In-flight session’s downstream commits could be made stronger with verified substrate | Saturation session §11 residual classification — sibling can pre-spike which residuals are actually spike-able |
| Another session reads X file at session-open — sibling can author X content first | Q-044 reads docs-strategy CLAUDE.md T-file topic-mapping — sibling adds entry pointing at pre-staged substrate |
Parallel-safe placement rules
Pre-staging output MUST live in a location the in-flight session does NOT own. Safe locations:
| Location | Safe for | Discovery probability |
|---|---|---|
~/off-github/library/projects/inherit/ | T-file-pattern substrate research; any topic deep-dive | HIGH (feedback_check_t_files_first_for_any_inherit_v2_work is canonical TT session-open discipline) |
~/.claude/projects/-home-richardd-testatetech/memory/ (off-tree) | Methodology refinements; one-shot recall content | MEDIUM (MEMORY.md auto-loads; one-line entries surface) |
~/testatetech/docs-strategy/docs/superpowers/specs/2026-04-29-multi-phase-audit/<topic>-prestage-<slug>.md | Pre-stage research for upcoming Q-lock or batch | MEDIUM (added to launch-prompt’s “Read these FIRST” list) |
| Edit of a launch-prompt file for a QUEUED (not running) session | Final pre-fire methodology injection | HIGH (session reads launch prompt on fire) |
Unsafe (DO NOT touch when target session is running):
- Files the in-flight session OWNS per its file-isolation discipline
- Shared state files (active-work-log; arch-state; ledger; registry) — race on these
- The in-flight session’s launch-prompt file itself (post-launch modifications won’t be picked up + may confuse if Rich re-reads)
Cost-benefit framing
Low-cost (≤15 min sibling work):
- Pre-staging is cheap; no harm if in-flight session doesn’t pick up
- At-worst becomes durability-capture for future sessions on same topic
- At-best derisks the in-flight session’s natural discovery cost
Diminishing returns:
- Pre-staging more than ~3-4 items per in-flight session = micro-managing; let the session self-organise
- Pre-staging while the in-flight session is past the relevant decision point = wasted work
Anti-patterns
- Modifying an in-flight session’s launch-prompt — they’ve already loaded it; modifications won’t propagate
- Touching files the in-flight session OWNS — file-isolation violation; pull —rebase doesn’t help when sessions race on the same file
- Pre-staging without parallel-safety analysis — verify the location is in the in-flight session’s NOT-owned space before authoring
- Pre-staging MORE than the in-flight session needs — light-touch; pre-stage ≤3 items per in-flight session OR you’re micro-managing
- Skipping discovery-probability assessment — pre-staging to a location the in-flight session won’t read = wasted spike
Empirical precedent ledger
| # | Date | Pre-stage | In-flight target | Discovery outcome |
|---|---|---|---|---|
| 1 | 2026-05-20T10:30 | CA 2006 s.541 URL spike at WebSearch (verbatim text captured) | ω session (running) — would-have-used in ω.4 phase | Captured in i4; saturation-launch-prompt §11.5 directs saturation session to verify ω.4 outcomes + re-spike if needed |
| 2 | 2026-05-20T10:30 | Q-044 IP + Crypto substrate scan at off-github (this memory’s sibling i1) | Q-044 session (running) — may pick up at [A] context-load OR [D] formulation | TBD; if Q-044 already past [D], no harm; durability-capture stands |
| 3 | 2026-05-20T10:30 | Saturation launch-prompt §11.5 NEW sub-section + invoke spike-inline-not-tasked memory | Saturation session (QUEUED at C; not yet running) | HIGH discovery probability — session reads launch prompt on fire |
When this rule does NOT apply
- Single-session work (no in-flight other session)
- The substrate spike requires write access to a file the in-flight session owns
- The in-flight session is past the relevant decision point
- The pre-staging cost > the discovery-probability × yield
Companion files / related memories
- feedback_spikes_inline_not_tasked — parent rule; this feedback EXTENDS spike-inline to cross-session orchestration
- feedback_do_now_over_task_list_addition — grandparent rule
- feedback_batch_compression_lowers_defer_threshold — empirical compression evidence
- feedback_research_artefact_forward_traceability — pre-staged artefacts should still have forward-traceability frontmatter
- feedback_actively_use_t_files_in_scorecard_authoring — pre-staged T-files compound on this discipline
Why locked now
Rich-locked 2026-05-20 after observing the pattern surface during the Q-044 + ω + saturation 3-session orchestration. The pattern was implicit in spikes A-G (recipient identifications happened in this session, not in BATCH κ’s session because BATCH κ was already closed). The pattern is now explicit + reusable for future multi-session orchestration.