--- name: dispatch-session-launch-discipline description: "⭐ STANDING OWNER RULE (2026-07-15): ALWAYS launch a FRESH session per task — never reuse an already-used session via send_message. And when a launch (start_code_task) TIMES OUT, do NOT work around it by reusing a session — STOP and wait for the owner to accept / tell you to resend, then resend fresh." metadata: node_type: feedback type: feedback originSessionId: 1060dea9-0dc3-42b4-958d-2a6f7a6c0c58 --- **Owner, 2026-07-15 (verbatim):** *"whenever you send a request, don't start in a session you've already used. wait on me to accept / tell you to resend, then repeat."* ## THE RULE 1. **Fresh session per task — no reuse.** Do NOT hand a new task to an already-used session via `send_message`. Each unit gets a brand-new `start_code_task`. (I had been reusing idle sessions as a workaround for `start_code_task` timing out — the owner is ending that practice.) 2. **On a launch timeout, STOP and wait.** `start_code_task` has been intermittently timing out at 180s (and sometimes silently spawning a duplicate in the background — the source of the duplicate-session collision the owner caught). When a launch times out, do NOT reuse a session to route around it. Instead: check `list_sessions` to see if it actually spawned, tell the owner it timed out, and **wait for him to accept or tell me to resend**, then resend fresh. Repeat that loop. ## WHY Reusing sessions built up long-context zombie sessions and, combined with the timeout-spawns-a-duplicate bug, caused two sessions to work the same unit at once — a collision the owner caught. Fresh-only + owner-gated resend keeps the session graph clean and prevents silent duplicates. ## NOTE — reconciles with, does not override, [[dispatch-autonomy-preference]] "Continue automatically" (auto-advance the plan→build→audit→next chain without asking permission for the WORK) still holds. This rule is narrower: it governs the SEND MECHANISM — fresh sessions, and gate a *resend after a failed/timed-out launch* on the owner. The work continues automatically; only a failed dispatch send waits on him. Related: [[dispatch-autonomy-preference]], [[session-management-rule]], [[data-provenance-program-complete]] (where the timeout-duplicate + reuse pattern is logged).