alignment

Alignment

Declare every pattern you intend to follow and every design opinion you've formed — explicitly, with evidence and reasoning — so the human can correct them before implementation begins. Research produces facts; alignment is where you form and surface opinions for correction.

Prerequisites

Locate the inputs:

1. Brief — check conversation context first; fall back to design-docs/NN-name.brief.md; if absent, ask whether to run discovery.
2. Research — check conversation context first; fall back to design-docs/NN-name.research.md; if absent, ask whether to run research.
3. Glossary — load docs/glossary.md if present. If absent (first iteration), schedule creation at Phase 3 end (see Glossary maintenance below).

Process

Phase 1 — Synthesize

1. Read the brief, research, and glossary (if present).
2. From research, extract:
   • Codebase patterns with prevalence (dominant convention vs isolated instance).
   • Integration points and boundaries relevant to the brief's goals.
3. From the brief, extract:
   • Motivation, desired end state, constraints, non-goals.
   • Flagged term ambiguities — unresolved terms discovery surfaced for alignment to resolve.
   • Not-yet-specified items — unknowns discovery could not yet phrase as precise questions. Check each against the research findings: graduate the ones research has sharpened into open questions for Phase 3; carry the rest into the alignment document unchanged.
4. From the glossary, extract:
   • Canonical vocabulary to use throughout alignment.
   • Definitions that constrain pattern choices (e.g., "Customer owns CustomerId" forbids cross-context FKs).
5. Form opinions: which patterns to follow, which to deviate from, and why.

Phase 2 — Surface Patterns

Present patterns you intend to follow as a structured block:

• Pattern: [what]
• Found in: [where, prevalence — e.g., "12/15 files in internal/auth/"]
• Intend to follow: yes / no / partially
• Reason: [why]