Module versions: draft and published are not two states of a switch
A module version is where a capability gets somewhere to live — draft is fully editable, published is frozen, and there's no un-publish.
"A module" and "a version of a module" are the same row on the wire, at /catalogue/versions. Every authoring decision turns on the difference, so it's worth being precise about which one you're looking at before you touch anything.
Draft: where authoring happens
A new module version opens as a draft, named with a slug and a version string you type yourself — arnona and 1.3.0, say — plus a label in every language the platform authors in (Hebrew, Arabic, Russian and English; a module the server won't publish without all four, because that label is the source-badge caption under every answer sourced to it, in every resident's own language). Inside a draft, capabilities can be declared, re-declared and corrected freely, because nothing outside the platform can see the version yet and no city is serving its contract.
Publishing is a gate, and it only runs one way
Publishing compiles the real tool for every capability in the version and refuses the whole version if even one fails. Once it succeeds, the contract is exactly what every municipality's prompts, evals, flows, rules and portal blocks may already be written against — and there is no un-publish. The publish control on the version's own screen states that consequence before the press, not after, and asks for it twice: a first press replaces the button with the warning sentence and a second control that names the version out loud.
Publishing is the slowest write this console asks for — it compiles every capability in the version — and it changes what forty cities could already be relying on. Read the version's capability table once before you press it, not after.
What stays editable after publish, and what doesn't
Once a version is published, its contract (face 2 — the input/output shape every prompt and rule already depends on) is frozen for good. What's still revisable is face 1, the semantics: summary, "use when," "do not use when," disambiguation and synonyms — through reviseCapabilitySemantics, on the capability's own detail screen, not on the version page. The version page itself states plainly which of the two states it's showing (a neutral "draft" note or a locked "frozen" note) and links to the one operation that actually applies, rather than offering an edit control that would be refused.
Two links off every version, for the two questions this page can't answer
Every version's header carries two links: one to its sibling versions (the same module slug, searched in the versions list), and one to that module's live capabilities, filtered to it in the ordinary catalogue. Both exist because a version's own screen is deliberately narrow — it's a record in a master–detail whose records are module versions, not capabilities, and forcing the two questions onto one screen is exactly the confusion the split avoids.
If you only need to fix wording on an already-published capability — a summary that quietly misleads the model, an English synonym nobody thought to add — you don't need a new version at all. Open that capability directly and revise its semantics; a new module version is for a genuinely new contract.