# Generate stubs and contracts before implementation — Interface-Driven Development is mandatory for cross-module dependencies

## The stub-and-resolve pattern

When a Tier 2 Tech Lead detects a cross-module dependency (or a single massive refactor) requiring an undefined signature, the order of operations is:

1. **Contract definition** — split the requirement into three tickets:
   - A `Stub Ticket` (generates the empty function signature + type hints + docstrings)
   - A `Consumer Ticket` (codes against the new interface)
   - An `Implementation Ticket` (fills the stub logic)
2. **Stub generation** — spawn a cheap Tier 3 worker (the `contract_stubber` archetype) to emit the empty signature.
3. **Skeleton broadcast** — the stub merges, the AST immediately re-runs, and the global Skeleton View updates.
4. **Parallel implementation** — the Consumer and the Implementer run in isolated contexts, coding against the same skeleton.

Per `docs/MMA_Support/Tier2_TechLead.md:39-46`: "Force Interface-Driven Development (IDD) to prevent hallucination."

## Why

LLMs hallucinate function signatures they have never seen. By forcing a cheap worker to emit the contract first, every later worker (including future agents and humans) reads the same ground-truth signature. The skeleton becomes the single source of truth.

## What this means in practice

- A cross-module change is never implemented directly. The stub ticket lands first.
- The skeleton view is regenerated automatically after the stub merges (no manual sync step).
- Implementers and consumers run in parallel against the same skeleton — they cannot drift.
- If the implementation changes the signature, the stub is regenerated and consumers are re-spawned (the skeleton is the contract).