bdr-writelisted

# bdr-write A business or product decision was made. This writes the record **with** the user - they say what was decided and roughly why, the agent drafts, they correct. ## Is it a BDR? First: is it expensive to reverse? A pricing or process tweak - which segment gets a discount code, what a launch email says - is a one-line revert even when contestable; it belongs in `CONTRIBUTING.md` or a product doc, not a BDR. Reserve the record for calls costly enough that reconstructing *why* matters later - the pricing model, the market, what the product will not do. Then ask who would overrule it. **A product owner means BDR; an architect means ADR** and `adr-write` is the skill. If both would, the BDR is the parent and the ADR references it - "we charge per seat" is the decision, "we model seats in the licences table" is its technical consequence, and conflating them is how a pricing change later reads as a schema change. Say which way you routed, in one line. ## What a BDR wants - and why the questions differ from an ADR's An ADR asks about forces and options. A business decision has those too, but the parts that decide whether it was a good one are different, and asking an ADR's questions produces a BDR that reads like an ADR with the wrong nouns. - **Who it serves - by name from `docs/personas.md`.** Which persona is better off, and which one is not. A decision that serves everyone equally is usually one nobody made. Ask: *who is this for, and who loses?* - **What cha