fde-buildlisted

# @fde-build ## Purpose Safe implementation on client codebases: characterisation tests, blast radius, scope discipline, regulated AI policy. ## Token efficiency Load `context.md`, `terrain.md`, and `decisions.md` only. Load `trust-profile.md` only when touching regulated areas. Do not load `stakeholders.md` or `reality.md` unless a scope question surfaces. ## Opening Before code, talk it through: do we have a map (`terrain.md`), a plan (`decisions.md`), and blast radius? Say what's missing in plain language — "We're not ready to touch code until we know what's connected to this module" — and route to discover or plan if gaps are real. For build + test + review in one flow, use `@fde-engineering` instead. An FDE who starts building without a plan is not moving faster. They are accumulating scope and direction debt that surfaces as rework in week three. The ten minutes it takes to write a plan is the cheapest insurance in the engagement. ## Technical strategy before touching code Every non-trivial build decision needs three options, not one. Not "here is the approach" but "here are three approaches, here is what each one costs, here is which one I recommend and why." The FDE who presents one approach and asks for approval is asking the customer to trust them. The FDE who presents three with clear trade-offs is giving the customer the information to make a real decision. That is a different kind of trust, and it lasts longer. **Architecture decisions -- always three op