The Starting Point
The developer had a signal from the interactive fiction community: people want to play text adventures together, and the current solution — screen-sharing over Discord or Zoom — is awkward. The person sharing their screen owns the keyboard. Others have to dictate commands verbally. Quieter players stop contributing.
That was it. No spec, no architecture, no tech stack decision. Just a pain point and a hunch that a purpose-built tool could do better.
DevArch skill used: /brainstorm multiuser
The brainstorm skill runs an iterative Q&A session, probing assumptions, challenging decisions, and capturing everything to docs/brainstorm/multiuser/overview.md. The developer drives direction; DevArch drives completeness.
What Emerged
The Core Insight
The brainstorm identified the real problem: the command line cannot be shared, and there is no way to take turns entering commands. "Prettier Discord" was the wrong frame. The right frame was closer to "networked game controller with a handoff mechanism."
Product Shape
Through conversation, the project converged on open-source, self-hostable platform software — the Mastodon/Gitea model, not the Discord/Jackbox.tv model. Anyone can deploy their own instance. An IF club for its members. An author for beta testers. A teacher for a classroom. A comp organizer for a testing window.
Lock-on-Typing Input Model
The brainstorm's signature decision: when any player starts typing a command, all other inputs lock out until that command completes. No turn-passing ceremony. No queue. The "controller" is held only for the duration of a single command, then released automatically. Everyone else sees the keystrokes in real time.
This emerged from probing the social dynamics: explicit turn-passing creates ceremony that kills spontaneity. Free-for-all creates collisions. Lock-on-typing splits the difference — first keystroke wins, but the lock is transient.
Security Analysis
Sharpee story files are executable JavaScript, not sandboxed VM bytecode like classic IF formats. The brainstorm walked through the full threat model: what a malicious story file can do in a browser, what the browser sandbox prevents, and what mitigations are needed for a multi-user platform that runs untrusted code.
The session evaluated six isolation approaches — from Deno's permission model to Firecracker microVMs — and converged on Deno with explicit permissions as the right fit for a community-scale platform.
Decisions Resolved
Docker deployment
Single container, Node server + Deno sandbox. Operator fronts with their own reverse proxy.
SQLite persistence
Saves are opaque blobs, room-scoped. One save timeline per room, shared by all participants.
No auth system
Join codes + durable session tokens. No accounts needed. The entire MVP ships without an auth layer.
Full event logging
Every command, output, chat message, role change, and lifecycle event is persisted for replay and review.
Role hierarchy
Primary Host → Co-Host → Command Entrant → Participant. Authority flows top-down through explicit promotion.
14-day room expiry
Rooms idle for 14 days are recycled. Natural storage bound, no perpetual-room sprawl.
No filesystem access
Story sandbox runs with zero permissions. Save/restore routes through a server API, not disk.
Lock-on-first-keystroke
60-second AFK timeout. Co-Host force-release for stuck situations. Race arbitrated by server timestamp.
What DevArch Did
The brainstorm skill didn't generate this architecture. The developer made every decision. What DevArch did was:
- Structure the exploration. The checklist tracked coverage: problem, core concepts, user activities, security, architecture, hosting. Nothing was skipped by accident.
- Probe the edges. "What happens if two people start typing at the same time?" "What can a malicious story file actually do?" "Who runs the instance?" Each question pushed the design toward completeness.
- Capture decisions in place. Every resolved question was written to the brainstorm document as it happened — not reconstructed afterward from memory.
- Separate decided from open. The document cleanly marks what's resolved and what's deferred, so the next session knows exactly where to pick up.
The output: a 400+ line architectural document covering product shape, session model, input mechanics, security posture, hosting, persistence, room lifecycle, and user flows — all produced through conversation before a single line of code was written.