Dev Log #19 - A Better Way To Write And Read Proposals
Governance begins long before a vote is cast. It begins when someone tries to turn an idea into a proposal that other people can understand, challenge, and eventually decide on.
That authoring experience has been rebuilt across Vortex. The new Proposal Wizard guides authors from their first decision to a complete proposal, keeps unrelated drafts safely separated, and presents the finished work as a structured document throughout its governance lifecycle. Existing proposals receive the same improved presentation without rewriting production records.
A Clear Path From Intent To Review
Proposal creation now begins with intent. The author first chooses what kind of change they are trying to make, and the wizard builds the appropriate path from that decision.
Project policy proposals move through Intent, Essentials, Plan, and Review. Projects that require Formation add a dedicated Funding and team step. System changes receive focused System change and Rationale steps without unrelated project fields.
Completed steps remain available for revision. Future steps stay visible but locked until their requirements are met. Validation appears beside the field that needs attention, and submission happens only after the author reaches review.
The result feels more like preparing a governance document and less like navigating a large administrative form.
Drafts That Stay In Their Own Lane
The previous creation flow stored proposal state in one shared browser namespace. A new proposal could inherit the step, content, preset, or server identity of another draft. In the most visible case, fresh proposals could open directly on the final Review screen.
Draft work now lives in isolated, versioned sessions. A local session receives its own identity before the first server save and binds to the returned server draft after synchronization. Recovery is an explicit choice, and opening one draft cannot silently replace another.
The final bug sweeps also closed subtler timing failures. A late hydration, failed submission, or delayed Save and exit response belongs to the session that created it. Once the author moves elsewhere, that stale response can no longer alter the new draft or redirect the page.
Writing Proposals As Documents
Substantive proposal fields now use a structured editor with paragraphs, headings, ordered and unordered lists, links, quotes, and inline code. Authors can organize long arguments without manually writing markup or reducing every idea to a plain textarea.
The stored format remains a constrained Markdown-compatible string, preserving the existing command and database boundaries. Raw author HTML is never injected, and rendered links pass through a protocol allowlist.
Review uses the same document reader as public proposal pages. The document an author approves is the document governors receive.
This also repairs the presentation of older content. Historical execution plans were sometimes displayed as walls of bullet points because every stored array item was treated as a list entry. The reader now recognizes paragraphs, headings, and explicit list markers separately. Prose remains prose.
Complete Proposal Records At Every Stage
The improved proposal view follows a proposal through the entire system: Proposal Pool, Chamber Vote, citizen veto, chamber veto, Formation, referendum, and finished history.
Project proposals are organized into Case, Plan, Funding and delivery, and Proposer context. System proposals show their action and rationale without empty project containers. Outputs, milestones, budgets, target chambers, addresses, multipliers, and genesis members appear when the proposal contains them.
One shared set of components owns these sections, keeping the hierarchy, typography, and fallback behavior consistent across every stage.
Existing Proposals Improve Automatically
The server derives a normalized authoring view from each proposal's stored payload whenever a proposal page is requested. No duplicate proposal table, background conversion, or production-row rewrite is involved.
Older overview, execution-plan, and budget fields remain available as fallbacks for sparse records. This gives historical proposals the new presentation while preserving their canonical stored data.
Existing policy, Formation, and system records were checked directly in production, including Ember, Publication Team for 2067, Humanode Docker image, and Chamber of Media. Their information appeared in the new sections without console errors or data changes.
Rejected Milestones Return To Formation
The release also corrects a Formation lifecycle failure discovered through Publication Team for 2067.
A rejected milestone vote previously marked the whole proposal as failed, canceled the project, and removed it from Formation. The project appeared to vanish even though only one milestone submission had been rejected. A rejected milestone now returns the project to active Formation at the same milestone. The failed attempt and its votes are recorded in the timeline, while the pending milestone state is cleared so the team can revise and submit it again. No budget is released, no milestone progress is awarded, and no governor or completion credit is granted.
The same behavior applies whether voting concludes through direct chamber activity or through the vote window expiring. Publication Team for 2067 was restored to Formation, and automated database-backed tests now protect both paths.