coordination loop

Coordination Loop — Master ⇄ T1/T3 Sub-Sessions

Each sub-session runs in its own Claude Code app window. They are separate processes; the master cannot directly message them, and they cannot directly message the master. Coordination is file-based and Linear-based, period.

Sub-sessions live

Track Session title cwd Branch Linear
T1 “Set up T1 sub-session for underwriting” sooner-underwriting-sandbox n/a (not a git repo yet) APP-1863
T3 “Set up T3 application forms project” sooner-gtm-forms t3/sooner-application-forms GTM-59

How a handoff actually flows

1. Sub-session (T1 or T3) hits a question the master needs to resolve
        ↓
2. Sub-session writes a stub file:
       sooner-coordination/handoffs/T<n>-YYYYMMDD-<slug>.md
   Stub schema is in session-topology.md
        ↓
3. Sub-session keeps working on whatever isn't blocked by the question
        ↓
4. Gabriel opens master window, says "anything in handoffs?"
        ↓
5. Master reads handoffs/ at the start of every turn anyway,
   surfaces the question, makes a call (or escalates to Gabriel)
        ↓
6. Master writes the resolution stub:
       sooner-coordination/handoffs/master-resolution-<original-slug>.md
   Or just edits the original stub's "resolution" section
        ↓
7. Gabriel switches back to the sub-session window, says
   "handoffs/master-resolution-X.md has the answer"
        ↓
8. Sub-session reads, unblocks, ships
        ↓
9. Master moves the resolved pair to handoffs/resolved/YYYYMMDD/

The async cost: every handoff costs one user-mediated context switch (steps 4 and 7). That’s the price of file-based coordination across windows.

What stays in each session

Concern Master T1 T3
implementation-notes.html owns reads reads
forms-inventory.html owns (regenerates from explorer passes) reads reads + pushes fixes that the master then re-renders
session-topology.md owns reads reads
kickoff-prompts/ owns n/a n/a
handoffs/ reads + resolves writes + reads writes + reads
sooner-underwriting-sandbox/contracts/* n/a owns reads (vendored)
sooner-underwriting-sandbox/matrix-browser.html (planned, deployed at /matrices) n/a owns reads (linked)
sooner-gtm-forms/forms/*, form/*, app/* n/a n/a owns
sooner-gtm-forms/underwriting-funnel/field-map.json (planned) n/a reads owns
sooner-gtm-forms/underwriting-funnel/consequences-rules.json (planned) n/a n/a owns
Linear ticket movements reads, occasionally bridges owns APP-1863 owns GTM-59
Cross-track gap detection owns flags own gaps flags own gaps

Cadence

What to do if a sub-session goes quiet

If T1 or T3 hasn’t shipped anything for >24h:

  1. Open the master, ask “anything in handoffs?”
  2. Master reads handoffs/ + last Linear comments on APP-1863 / GTM-59 + git log on the respective repo.
  3. Master writes a “kick” stub into handoffs/ summarizing what it thinks should happen next. Sub-session picks up next time it’s opened.

What to do when the kickoff prompts go stale

If the standing instructions in kickoff-prompts/T1-kickoff.md or T3-kickoff.md no longer reflect priority:

  1. Master updates the kickoff file.
  2. Next time the sub-session is opened with a fresh context (new Claude Code window or /clear), paste the updated prompt.
  3. Sub-sessions already running don’t need to re-read — they continue with their in-memory standing instructions. Update them via a handoff stub if a directive changes mid-session.

Anti-patterns to avoid