squadcue

Design notes

SquadCue’s architecture follows patterns deliberately borrowed from systems we audited in July 2026:

Known limits (by design, for now): single user, localhost only, polling not websockets, vanilla JS single-file frontend. The multi-user path (OIDC, RBAC, actor context, per-workspace secrets) is documented but deliberately not built until there is a second human user.

Philosophy & non-goals (the charter)

SquadCue exists because one person actually runs their operation through it every day. That origin is the product. To keep it that way:

A feature ships only if we needed it in our own production first. The immortal-employees roadmap item exists because our sessions really did fill up and lose context mid-work; the single-shot-turn caveat exists because we really did lose a background job. Ideas that come from watching vendors demo at expos go into a candidate list and wait until our own operation hits the same pain. If we haven’t needed it for a month, it doesn’t ship.

Non-goals — things SquadCue will not become, even though every vendor booth suggests otherwise:

The metaphor is the spec. Agents are employees: they have names, memory, shifts, an inbox for things that need the boss. Any feature that can’t be explained in those terms probably doesn’t belong here.