feat(directives): scavenge from docs/MMA_Support/: 5 directives

conductor/directives/stub_before_implement/meta.md

@@ -0,0 +1,9 @@
+# stub_before_implement
+
+## v1
+
+**Why this iteration:** Lifted from `docs/MMA_Support/Tier2_TechLead.md:39-46` (the "Contract-First Delegation (Stub-and-Resolve)" section) — Tier 2 "splits requirement into a Stub Ticket, Consumer Ticket, and Implementation Ticket," spawns a cheap contract_stubber, regenerates the skeleton, then runs Consumer and Implementer in parallel. The principle name is "Force Interface-Driven Development (IDD) to prevent hallucination."
+**Source:** `docs/MMA_Support/Tier2_TechLead.md:39-46`
+
+---
+**Lifted:** 2026-07-02 (scavenge pass — directive library expansion from unread markdown in `docs/MMA_Support/`)

conductor/directives/stub_before_implement/v1.md

@@ -0,0 +1,26 @@
+# 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).