pre-phase-briefing

Pre Phase Briefing Protocol

This protocol is loaded on demand by the architect runtime. The architect prompt keeps only activation, action, and hard safety constraints; the full execution details live here.

MODE: PRE-PHASE BRIEFING (Required Before Starting Any Phase)

Before creating or resuming any plan, you MUST read the previous phase's retrospective.

Phase 2+ (continuing a multi-phase project):

1. Check .swarm/evidence/retro-{N-1}/evidence.json for the previous phase's retrospective
2. If it exists: read and internalize lessons_learned and top_rejection_reasons
3. If it does NOT exist: note this as a process gap, but proceed
4. Print a briefing acknowledgment:

→ BRIEFING: Read Phase {N-1} retrospective.
Key lessons: {list 1-3 most relevant lessons}
Applying to Phase {N}: {one sentence on how you'll apply them}

Phase 1 (starting any new project):

1. Scan .swarm/evidence/ for any retro-* bundles from prior projects
2. If found: review the 1-3 most recent retrospectives for relevant lessons
3. Pay special attention to user_directives — these carry across projects
4. Print a briefing acknowledgment:

→ BRIEFING: Reviewed {N} historical retrospectives from this workspace.
Relevant lessons: {list applicable lessons}
User directives carried forward: {list any persistent directives}

OR if no historical retros exist:

→ BRIEFING: No historical retrospectives found. Starting fresh.

This briefing is a HARD REQUIREMENT for ALL phases. Skipping it is a process violation.

CODEBASE REALITY CHECK (Required Before Speccing or Planning)

Before any spec generation, plan creation, or plan ingestion begins, the Architect must verify the codebase reality of every item the work references. This runs as asynchronous, fanned-out Explorer lanes by default, joined behind a hard settlement gate — never as a single blocking explorer call, and never as fire-and-forget.

1. Enumerate and partition the references (before dispatch). List every referenced item — file, module, function, API, config surface, and behavioral assumption — named or implied by the spec, the user request, or the plan. Partition them into non-overlapping lane assignments. The partition is the contract: no two lanes may share a reference (this prevents duplicated work), and the union of all lanes must cover every referenced item (this prevents gaps). Under-specified lane boundaries are the dominant fan-out failure mode — be explicit about what each lane owns.