The daemon behind it drives the coding CLIs you already pay for, on your own machine, and calls a change done only when a deterministic check passes. A second agent judges it too — and can reject, but is never enough to approve.
The judge is identity-distinct where the roster allows one and a single runner where it doesn’t, so the veto is the guarantee, not the separation. Brainstorms, docs and demos share the project, not that check. Below is not a mock — it is the interface.
Tokens, cost, and rework per CLI — live during the run, not on the invoice.
add rate-limiting to the public API/ws — phase ladder, unit list, burn, diffsEvery panel below is a real route in the SPA, fed by a real route on the daemon — nothing rendered here is privileged. The governance vocabulary you’ll meet (deny-dominates gates, evaluator ≠ creator) is crew’s; the skin surfaces it and never grades anything. The board auto-cycles — click a panel to pin it.
The run board itself: launch from a brief, watch the phase ladder and unit list move, read live output, answer the steering timeline.
A deny-dominates gate is the deterministic floor a run must clear. Steering is the layer above it: the ecosystem’s doctrine, authored as rules and projected into the record as citable law a run can point at. And the record isn’t written by the agents that use it — they propose, you promote. The vocabulary is crew’s and the store is estate’s; the skin surfaces both and grades nothing.
Rules across architecture, development, security, testing, operations, compliance and
design/UX — authored in git or here, projected into the record as rules a run can
cite. One home, type-filtered: GET /governance/rules.
An agent never writes to the record. A run proposes a memory or a policy; it lands
pending in a queue with its provenance; you approve or reject. Nothing enters
doctrine without a human call — POST /proposals/:id/approve.
estate’s MCP is read-only; every write rides crew’s governed operator path. The skin shows you the corpus and the queue and never self-writes, never grades — the promote button is yours, and only yours.
The Steering surface is /steering/{policies,memories} — one home, two
sub-sections, each carrying a manage view and a proposals queue. Run the seven types
against your own dev-behavior corpora under Testing; verdicts land caught, gap or
false-positive, so a rule earns its keep before it ever governs a run.
A project groups runs, chats and docs, and its activity feed merges crew’s durable
core events with the document engine’s bus events carrying the same project_id.
A governed run and the deck you write about it land in the same room — flip the view
below and watch the same project re-render.
run r-7c19feature workflow · build → adversarial-review → test — held once, steered, landedgate decisionschema-drift DENY → approved with steer · on the decisions ledgerdoc payments-deckthe document engine’s deck, in this same feed — created, drafted, deliveredchat c-2214roster fan-out: “what breaks if we shard the ledger?” — three seats answeredwicked.interactive.doc.createdthe deck asks for a first draft — over the bus, from the document engine crew proxiesgoverned run answersa crew run drafts it — heartbeats stream while it workswicked.interactive.draft.completeda real draft, idempotency-keyed — replays can’t double-deliverrun r-7c19 · evidencethe coder’s run sits in the document view too — same feed, one projectGET /api/v1/projects/payments-refresh/activity
same project · same feed · rendered as the run board view
Where this stands: the Project model is shipped in the control plane — nine routes, the merged feed, durable gate prompts across member runs — and the studio’s dedicated project browser is shipped in this skin: project pages, the per-project dashboard, and the four-mode shell, all riding that daemon.
A feature starts as a question, becomes a change, and ends as something you show someone. All four share one project — but only one carries the gate.
Launch a run against your own repos, watch the worker’s raw output live, clear the gates yourself. A deterministic check and a separate judge must both agree — either can stop it, neither can approve alone.
the deepest surface here, by a wide margin
Write in a document canvas, point at an element to leave a note for an agent, and teach one document a brand. Three formats over one wire — self-contained HTML, PDF, PPTX — and the document service does the rendering.
a brand you teach one document stays with that document
Put one question to several models in the same thread and see how many seats answered — then hand the thread off as a run the moment it turns into actual work.
“3 of 5 seats”, or “3 polled” when the count is unknown — never backfilled
A wizard authors the steps; the document service runs them in a real browser and hands back a recording of the click-through — a screen capture, not a narrated film.
the thinnest surface here — judge it last
The two-sided check covers code, and only code. Documents do have human gates — an agent asks in the thread, you answer there — but not the deterministic check plus independent judge a code run carries. All four share the project; they do not share that verdict. Docs, decks and demos also need wicked-garden and a reachable document service to open at all — code runs and chat never gate on either.
Real work spans repos. A change in an engine lands in the daemon that embeds it and the
console that renders it — and an agent that can only see one of them answers
“not found” about the other two, confidently, because a per-repo graph has no way
to know it was asked about something outside itself. Attach repos to a project and crew
builds one co-located code graph over all of them
(POST /api/v1/projects/:id/graph/refresh). Runs filed into that project are
bound to it.
register across a project holding studio + crew + core returns
8 hits — 4 in wicked-core, 3 in wicked-crew, 1 in
wicked-studio — each attributed to the repo it came from, spanning
Rust and TypeScript in one answer. Blast radius works the same way.
The binding decision is recorded on both outcomes. “This run sees the project” and “this run sees one repo, because X” are equally facts about what the run could observe — and the second is the one you need when a worker reports that a sibling repo does not exist.
Co-located is not linked. Each repo is indexed under its own label and edges do
not resolve across repos — studio → api-types → crew does not
traverse. What you get is per-repo results gathered into one answer with the repo named
on every hit. Every response carries linkage: "co-located" and a note
saying so, so a consumer cannot mistake it for a cross-repo trace.
A refresh is wicked-estate index per member, bounded at ten minutes
each — so it never happens implicitly at launch, and a missing or stale graph
degrades the run to its own repo’s graph and says so. It needs an estate that supports
--repo co-location, capability-probed before anything is indexed — an older
binary accepts the flag, ignores it, and exits 0.
A run needs more than a picture of the code it’s about to change — it needs to know what
the code is for. Every registered repo carries a requirements graph:
requirements and their edges, browsable and searchable right here. It’s the forward edge of
the record — and it’s becoming the source of truth a run is measured against, not a
spec doc that rots in a folder. GET /domain-graph ·
per-repo requirements_graph.json.
Browse and search a repo’s requirements and the graph that links them — tokenized
match, risk and domain filters, pagination.
GET /repos/:id/requirements.
The requirements graph is the intent a governed run answers to. “Done” is re-derived from evidence against it — never asserted by the agent that wrote the code — so the record leads the work instead of trailing it.
Each node carries how sure the record is and where it came from, so a heuristic reads as
a heuristic, never a fact. What the graph doesn’t know yet, it says it doesn’t
know — graph is honestly null until it’s generated.
Elevated from one panel in the cycle to the point of the thing: the app’s intent, versioned beside its code, that every governed run is answerable to. Where estate holds the record, this is the part of it that points forward.
Studio imports zero crew source. The only artifact the two products share is the
published wire contract — wicked-crew-api-types. Everything on this page rides
/api/v1 and the /ws CoreEvent stream; there is no back channel.
How the SPA finds its daemon is one deliberate seam — flip it.
$ npx wicked-crew serve # UI + API · one port · same origin
apiBase() → window.location.origin + '/api/v1'
wsBase() → wss? + window.location.host # /ws CoreEvents
Crew’s release build copies studio’s built dist/ into the daemon’s serving
tree — one command, one port. No host is baked into the bundle:
--port / CREW_PORT just work.
$ VITE_API_HOST=127.0.0.1:7701 npm run build
$ npx serve dist # any static server · SPA fallback
apiBase() → http://127.0.0.1:7701/api/v1
wsBase() → ws://127.0.0.1:7701 # same contract, other origin
The daemon’s loopback CORS admits any localhost origin, so a standalone
studio on its own port drives a local daemon out of the box — the daemon stays fully
functional headless either way.
e2e/studio_standalone_test.py builds the SPA, serves dist/ from a plain
static server, points it at a live daemon, and drives a real browser through a real flow —
list runs → open a run → approve a human gate → watch CoreEvents over WS.
Four planes, four contracts. Hover or tab through a plane to see its role and what crosses its seams — every cross-plane interaction goes through the contract, never around it.
Brainstorm it, build it under a check nothing self-approves, then produce the doc, deck or demo.
Evaluator ≠ creator — no agent grades its own homework. “Done” is re-derived from evidence, never asserted.
Multi-model review councils, graph-aware refactors, repo playbooks — plus an open naming contract to ship your own pack.
A 102-language code graph, memory, and knowledge in one binary (MCP) — including the injected edges grep never sees.
Doc storage and lineage, HTML/PDF/PPTX rendering, demo recording. crew proxies it — you depend on it, you don’t visit it.
The studio ships bundled inside wicked-crew: npx wicked-crew serve
starts the daemon and serves this skin same-origin on one port — nothing else to
install. Running the skin standalone against any daemon is equally supported;
it’s the same build, pointed by one env var.
Prefer the whole family? npx wicked-installer is the interactive,
cross-CLI installer for every wicked-* product — Claude Code, Antigravity, Codex,
OpenCode and Pi.
npx wicked-crew serve # daemon + this studio · one port · same originNode ≥ 22. The daemon serves the studio at its own origin — open the printed URL and launch a run. wicked-studio npm v0.6.5
VITE_API_HOST=127.0.0.1:7701 npm run build
npx serve dist # any static server · SPA fallback to index.html