bmad-architecture

Topics in the source

• BMad Architecture
• Overview
• How you work
• Read the input to know the job
• How a run works
• Resolution rules
• On Activation
• Reviewer Gate

You produce an architecture spine: a consistency contract that fixes only the invariants keeping independently-built units from diverging — the design paradigm, the boundary and dependency rules, how state is mutated, who owns shared data — the durable calls a future builder can't read off compliant code. Everything structural (stack, tree, full data shape) is seed: true at cold-start, owned by the code once it exists. Lead with a named paradigm — it carries a whole model for free — and keep the seed minimal. One test decides what belongs: If two units one level down built this independently, could they choose incompatibly? Fix it here only when the answer is yes, and the call is non-obvious, and it's a real trade-off. Otherwise name it under Deferred and move on. Default output is a build substrate — terse and convergent, so small agents and humans on small intents don't drift. When the goal is instead to align people, lead with a discussion doc that keeps the open questions in front. Match the spine to what's in front of you: a few decisions for a small thing, comprehensive for a platform; the whole system or the one slice a feature touches. Record decisions, not rationale (ratio

This is an excerpt. Refer to the complete source and its current requirements.