When authoring a launch-prompt that would trigger PHASE-N IMPLEMENTATION work (build a server, ship an SDK, deploy a service, author production code) — as distinct from research / scoping / spike / eval-refresh / methodology work — surface the master-plan calendar BEFORE authoring or dispatching. Master plan + per-repo BUILD-PLAN files define WHEN each milestone is scheduled. Check.
Then distinguish two different deliverables:
- Author future-Phase artefact — the launch-prompt lives on disk as a queued artefact for when the milestone arrives; current-period authoring discipline applies but NO execution dispatch
- Dispatch for execution now — the launch-prompt fires immediately + commits substantive code/SDK/server artefacts to a repo
These are different commitments. The first preserves option value; the second burns hours + locks downstream architecture.
Why: 2026-05-23 batch-imp-21 v1.0 + v1.1 authored Sprint 1 server launch-prompt for Phase-1 M1 SDK substrate. BUILD-PLAN.md v1.8 §3.4.1 schedules Sprint 1 M1 at “M7-M8; ~Sprint 1-2” — Months 7-8 of Phase-1, which is ~Q4 2026 / Q1 2027. Phase-1 Sprint 0 setup-week itself is Q3 2026 per §3.0.4. We dispatched the Sprint 1 server build in May 2026 — 6-9 months early. The autopilot session passed §0 PRECONDITION GATE + asked about dispatch mode; Rich caught the timing mismatch with “i am surprised we are doing a sprint of coding for inheritkit” + killed the Sprint 1 session. No execution-commits landed; batch-imp-21 v1.1 launch-prompt stays on disk as the future-Phase-1 artefact. ~30-60 min of context burned on §0 gate + substrate-sweep (no lasting damage but a real friction event).
Root cause: I treated “task-168 PART B PARTIAL gate” + “PART B pending Sprint 1” (per A-281) as if PART B closure was due now. The “Sprint 1” reference is to Phase-1 Sprint 1, NOT a current-calendar sprint. Naming collision led to misreading.
How to apply:
- Before authoring or dispatching a Phase-N implementation launch-prompt, run a calendar-check:
- Read master plan + per-repo BUILD-PLAN.md for the milestone’s scheduled month/sprint
- Compare to current date
- If scheduled month is > 1 month future: explicitly flag in launch-prompt frontmatter as
phase_timing: "future — scheduled M7-M8 ~Q4 2026; current artefact is queued not executable"(or similar) - If scheduled month is current: dispatch is appropriate
- If unclear: ask Rich before dispatching
- “Sprint N” in launch-prompt context = Phase-1 Sprint N (per master plan), NOT current-calendar sprint. Disambiguate explicitly.
- Distinguish “task-X PART B PENDING-SPRINT-1” status (which means “PART B will land when Sprint 1 executes per master-plan calendar”) from “task-X PART B blocked / urgent / now-required”.
- Operator-first lens (per A-277): is there a real partner-firm customer demanding this implementation now? If not, the build is speculative engineering at calendar-future cost. Default to defer.
- When Rich says “can these run in parallel?” or similar dispatch-question, surface the calendar-check answer BEFORE confirming. Don’t conflate “launch-prompt is well-authored + technically ready” with “appropriate to dispatch now”.
Anti-pattern: dispatching a Phase-N implementation launch-prompt because (a) the §0 gate passes + (b) the launch-prompt structure looks ready + (c) Rich confirmed dispatch. Those conditions are necessary but NOT sufficient — the timing question is independent + must be checked.
Related: feedback-claude-p-dispatch-pattern-with-execution-directive (dispatch mechanics — this memory adds dispatch GATING discipline on top of dispatch mechanics) + feedback-compound-launch-prompts-amplify-context-degradation-risk (compound prompts risk surface; this risk surfaces ONE LAYER UP — appropriate-time-to-dispatch).