A proposer picks the quorum rule, and the proposal says which one it is #26

propose now takes the rule as one line of text and parseRule is the only thing that judges it: majority, all, or named:alice,bob:2. Anything else comes back invalid with a sentence naming all three forms; no rule at all is still majority, and the text that parses is the text stored. Every proposal leaving src/actions.ts now carries rule_parsed beside its stored rule — read once, on the way out — so no door parses it a second time, and a stored rule the app cannot read (a row written before the choice existed, or edited by hand) comes back as no rule at all instead of a throw: the page and the terminal say so and print the text.

Every door offers the choice: a <select> of the three kinds in the composer with one field beside it for the names and count, rule in POST /api/proposals, the MCP propose schema describing the three forms, and the terminal asking for the rule after the options with Enter for majority. /p/:id states the rule in words from RULES above the options ("More than half of the group on one option decides it.", "Needs 2 of alice, bob, carol").

Worth a look in the preview: open a proposal with each kind and read /p/<id>; the names field is hidden by a :has rule when another kind is selected and stays visible — plainly labelled "for 'a named few' only" — wherever :has is not understood, so it is never unreachable without JavaScript. Two small pure helpers landed in src/quorum.ts (describeRule, ruleText) so the rule's grammar and its wording stay in the module that owns them; no dependency was added. Changing a proposal's rule after it is opened is not here, as the issue says — the rule is written once at propose and never updated.

🤖 Generated with Claude Code

Closes #21