Vortex Sim Dev Log #18 - Feed Routing, Invision Truth, And Initiatives

Updated: 2026-06-30

• Rebuilt Feed routing around explicit, shared scope rules.
• Added a dedicated System feed for legitimacy, decentralization, and stability events.
• Corrected Invision decision closure and documented every status band through hover hints and Vortexopedia.
• Fixed Formation tier-credit timing at the M1 acceptance boundary.
• Improved proposal source chips and glassy cards across all four themes.
• Delivered Initiatives across server, web, proposal creation, Feed, and profile history.
• Hardened Initiative transactions, lifecycle rules, roles, board projection, and proposal provenance.
• Deployed the Initiative release to the VPS while preserving every existing production table and runtime configuration.

Dev Log #18 began with a Feed inconsistency. Urgent could contain more records than All Activity, private faction events could enter broader scopes, and system-health signals competed with day-to-day governance work.

The repair expanded into a wider pass across Feed routing, Invision semantics, Formation rewards, release discipline, and the first complete version of Initiatives.

Feed Scopes With Clear Ownership

Feed categories now follow one shared routing model across server and web.

All Activity is the complete visible timeline for the current viewer. Urgent is a bounded subset containing records that require timely attention. My Feed carries personal activity and direct notifications. Chambers, Factions, Formation, and System each receive events owned by that domain.

The new System scope contains legitimacy, decentralization, and stability signals. Decentralization threshold changes now produce the same durable Feed events already used for legitimacy and stability. Private faction invitations remain personal, while public faction activity stays within its appropriate public surfaces.

The API supports stage and entity exclusions directly. The web consumes those controls through a shared routing helper, which keeps counts and displayed records aligned. That closes the class of bugs where one tab applied local filtering after pagination and quietly disagreed with another tab.

Proposal Cards And Theme Surfaces

Proposal source chips now show the exact chamber, faction, or Initiative name. Lifecycle information stays in the adjacent stage chip, removing labels such as “General Chamber pool” beside a separate Proposal Pool marker.

Long source names can use the available width without colliding with neighboring chips. Shared layout rules handle wrapping, spacing, and alignment across Feed and Proposals.

Light and Sky received another glass treatment. Their cards allow more of the animated background to pass through while preserving text contrast. Pointer ripples are scoped to each card and disappear at the card boundary. Night and Fire retain their deeper surfaces, giving every theme its own atmosphere within the same component grammar.

More Accurate Invision Signals

Decision closure now measures proposals that reached accepted, failed, or remanded outcomes during the observed period. Accepted throughput remains a separate metric, so closure and forward progress can be read independently.

Invision status bands now explain themselves. Stability labels such as Stable, Watch, and Unstable, and decentralization labels such as Broad, Mixed, and Concentrated, have anchored hover hints and full Vortexopedia entries. The explanations describe the score range and the system condition represented by each band.

These changes make the dashboard easier to audit. A user can move from the headline score to its components, caps, floors, confidence, and band definition without guessing what a label means.

Formation Credit At The Correct Boundary

Policy and Formation proposals follow different reward moments.

An accepted policy proposal applies its status effects at acceptance. A Formation proposal enters execution after its initial chamber vote, while its tier and Formation credit become earned when M1 is accepted.

The server now enforces that boundary explicitly. Tests cover both flows, protecting policy rewards from delay and Formation rewards from arriving before execution has produced its first accepted milestone.

Major Update: Initiatives

Initiatives provide persistent workspaces where active Human Nodes can organize work before and around formal governance.

The server now stores:

• Initiative identity, summary, status, and tags
• Admin, steward, and member roles
• Ordered board columns and cards
• Durable discussion threads and replies
• Initiative chat messages
• Proposal associations with recorded provenance

The web adds an Initiatives directory, creation flow, and full workspace page under Governance. Each workspace combines its board, threads, chat, members, role controls, settings, and associated proposals.

The board uses five operational states: Backlog, In Progress, Proposal Ready, Blocked, and Done. Proposal Ready signals that an item has enough shape to begin formal proposal work. Proposal creation remains an explicit action with its usual validation and chamber lifecycle.

Admins and stewards can associate proposals with Initiatives they manage. The server validates the role during submission and stores one immutable primary Initiative link for each proposal. That provenance appears on proposal cards, proposal stage headers, Feed records, profile activity, and the Initiative workspace.

Governance authority remains anchored in the existing proposal and chamber rules. Initiative association contributes context, attribution, and a route back to the originating workspace. Voting power, quorum weight, chamber membership, CM, MM, and tier progression continue to come from their established sources.

The First Initiative Bug Hunt

A populated local preview exposed behavior hidden by empty workspaces.

Board cards could render twice when a column id matched its key. Draft hydration could lose an Initiative selection while reference data was loading. Directory reads fetched more nested content than the list needed. Archived workspaces still exposed operational controls. Optional fields could retain stale values after users cleared them.

The cleanup addressed those paths at their ownership boundaries:

• Initiative creation now completes in one database transaction.
• Final-admin checks serialize per Initiative.
• Paused workspaces reject operational writes.
• Archived workspaces remain read-only, with an explicit admin reactivation path.
• Directory responses carry compact counts; full board, thread, reply, and chat payloads stay on workspace detail routes.
• Board ordering is deterministic.
• Card owners must be active Initiative members.
• Optional text fields can be cleared.
• Tags are deduplicated.
• Proposal provenance remains stable through veto reconsideration.
• Authentication and hydration requests avoid duplicate work.

The board label Proposal also became Proposal Ready, making the workflow state precise in both API data and interface copy.