The complete vote infrastructure — contracts, gate security, vote store, APIs, and dashboard — shipped in five sequential waves in a single day.
The Architecture Decision
The vote system was planned as bounded modules — self-contained units with clear interfaces between them. This is an architectural pattern borrowed from microservices, applied within a monorepo: each module has its own types, its own logic, and its own tests, but they share a deployment environment. The goal is to prepare the codebase for future extraction into separate services without requiring that extraction prematurely.
Wave 1 established the foundation: canonical type definitions in lib/contracts/, HMAC-SHA256 signing in lib/gate/, rate limiting and freeze flag mechanics, and the admin authentication middleware. These are the lowest-level concerns — the infrastructure that everything else depends on. Getting them right before building on top of them mattered.
The Five Waves
Wave 2 added the vote store (in-memory, with deduplication and anonymous voter IDs via cookies) and the gate API routes for server-to-server signed communication. Wave 3 added the public API: POST /api/vote for casting votes, GET /api/vote/state for current vote state, and GET /api/vote/stream for Server-Sent Events real-time updates.
Wave 4 built the dashboard UI: vote widgets, a vote timer countdown, a tally display with live updates, and an admin vote window management interface. Wave 5 completed the dashboard with ActiveThought (current AI plan display), PlatformFeed (event stream), and an OBS overlay endpoint for streaming, alongside a three-column CommandCenter layout that aggregates all live data in one view.
The Security Layer
The gate module implements HMAC-SHA256 signing for server-to-server communication: when the vote aggregation service reports official results to consumers, it signs the payload with a shared secret. Consumers verify the signature before trusting the data. This prevents result injection by unauthorized parties.
Anonymous voter IDs are hashed IP addresses combined with a daily rotating salt, stored in a cookie. This prevents a single user from voting multiple times while maintaining anonymity — the system can deduplicate votes without knowing who cast them. The freeze flag in lib/gate/freezeFlag.ts provides a kill switch: the human admin can halt all voting instantly without touching the codebase.
Real-Time as Requirement
The vote system uses Server-Sent Events (SSE) for real-time updates. When a vote is cast, the event propagates through an in-process EventEmitter to all connected SSE clients. The vote tallies update without page refresh — subscribers watching the vote happen can see each vote register as it occurs.
This creates a specific kind of social experience: shared observation of collective decision-making in real time. The vote is not just a mechanism for selecting the next AI tactic; it's a visible demonstration of collective participation. Watching the numbers change is part of the experiment.
Experiment Context
- Commit
- 20b9ea1
- Mutation rationale
- wave-1: contracts, gate core, admin auth foundation
- Last reviewed
- February 21, 2026