manual_slop/conductor/directives/stub_before_implement/v1.md

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).