Vortex Sim Dev Log #3 - Refactor Stabilization + Chamber Threads/Chat

TL;DR

Chamber internals are canonical (roster/pipeline/metadata), membership gating is enforced, and chambers now ship threads + WebRTC chat with member‑only writes. The server codebase is cleaner and more predictable, the test suite runs under rstest, and the web client is aligned with the Hono API (pool/vote/build stages, real gating). A manual E2E smoke run confirms end‑to‑end flows.

What changed (feature-level)

1) Server refactor + cleanup

We tightened the server architecture without changing behavior:

• Shared command helpers now live in dedicated modules (pool, chamber, drafts, formation).
• Read model fallbacks are centralized so list/detail endpoints behave consistently.
• Missing-resource errors are standardized across endpoints.
• Route params are validated with a shared guard, reducing ad-hoc parsing.
• DTOs are consolidated for proposal lists and chamber detail responses.
• Stage window checks are centralized in a reusable guard.
• Legacy pages.d.ts is removed and replaced with apiContext.d.ts.

2) Test harness migration to rstest

The server test suite is now unified under rstest:

• Tests reorganized into tests/unit, tests/api, and tests/scenario.
• Web-only tests removed from the server repo.
• All tests now import @rstest/core (no node:test).
• @rstest/core is wired in package.json with rstest.config.ts.
• yarn test runs the full suite; the previous runner is removed.

3) Web ↔️ Hono client migration

• Proposal stages now match server semantics: pool → vote → build.
• Stage chips/filters updated; old /app redirects removed.
• Local gating uses public/sim-config.json so real RPC gating works in dev.

4) Manual E2E smoke pass

• Draft → pool vote → chamber vote → chamber appears.
• Project proposal reaches build/formation.
• Pages render without hook/runtime errors in the new flow.

5) API remains stable

The HTTP contract is unchanged. Refactors and migrations stay behind the scenes and keep the UI’s /api/* expectations intact.

6) Chamber internals are now canonical

• Chamber detail and list endpoints derive from canonical state (roster + pipeline).
• Proposal submit/vote eligibility is enforced by chamber membership (General = governor-only).
• Manual flow validated: draft → pool → vote → chamber appears; proposer is in the new roster.

7) Threads + WebRTC chat inside chambers

• Added canonical storage for chamber threads, thread replies, and chat messages.
• New endpoints for thread list/detail and WebRTC signaling (offer/answer/ICE candidates).
• Web chamber page now renders threads + chat; non‑members are read‑only.
• Server tests cover chat signaling queue/presence + membership gating.

Why this matters

• Cleaner architecture makes the server safer to extend.
• A single test runner reduces CI drift and local confusion.
• The test taxonomy sets the stage for stable end-to-end flows.