Cockpit by RiftSeed: what it does and what it does not do yet
· 5 min read · cockpit, mcp, protocollo, agentic-engineering
The prototype where code agents receive their work and leave the evidence: the protocol step by step, the map, the gate with server-held ceilings, incidents, the Commander, and today’s limits.
On 9 October 2026 the requests that agents had logged in Cockpit by RiftSeed were counted. There were 82: 62 had become new proposed requirements, and 10 had been linked to a requirement that already existed. The agent made the call without seeing the requirement list, so a request that was already covered came back as a new requirement. Of the ten requests linked by hand, half were replies inside a conversation, like “Sì alla 1a” (“yes to 1a”), which mean nothing on their own.
That count is where req.match came from. Before logging a request, the agent restates it in one sentence and asks Cockpit whether a requirement already says it. The answer ranks candidates by shared words, each weighted by how rare it is in the project. When a decision model is switched on, it picks one with a probability, and a match counts only at 0.8 or above. The call stores nothing.
The protocol
Cockpit is a web application with an MCP server, rs-mcp, running as an edge function on Supabase. Claude Code and Codex connect with a token created in Cockpit’s settings. New tokens start with rsa_ and can be bound to a single project.
The first call of every session is session.start. It returns the briefing (the project’s stage, priorities, open requirements, failing tests, open incidents, house rules) and a briefing_id for the calls that follow. In this repository a Claude Code hook makes that call when the session opens.
For each request from the person, the agent goes through req.match and then request.log, with the person’s words exactly as written. The request is either linked to an existing requirement or proposes a new one. A proposed requirement stays proposed until a person confirms it in Cockpit. Agents, the Commander included, can only propose.
Before touching the code, the agent calls impact.get with a requirement key or a set of paths. The answer lists the files and modules involved, the tests to run with the reason for each, UI probes included, the latest gate run, and the linked decisions and incidents. Tests run locally or through tests.run, which dispatches them to the project’s own GitHub Actions; tests.results reports back, failures first.
At the end, session.log records the briefing, the requirements touched, the commits, the files changed and the tests run. If the session produced new commits and the log is missing, the stop hook holds the end of the turn once and asks for it.
The evidence comes from CI
Tests the agent says it ran go into the history as unverified results, and they never colour the map. Only CI does. After every push to main, the cockpit-gate.yml workflow sends Cockpit the gate result, the code map at the new commit, the requirement keys found in the commits’ Refs: lines, and the result of every test file.
The map shows the parts of the product coloured by the tests that protect them, the requirements a test cites and those no test cites, and the files no requirement explains. A missing test shows up there.
The gate’s lanes do not take the agent’s word either. A release in the light lane, with a green gate and no open incident, is approved with a single tap. To get into that lane, a change must stay within 40 lines and 5 files, leave protected paths alone (migrations, edge functions, workflows, package.json, the ratchet tests), remove no test file and no assertion, and raise no ceiling. The server judges it from the diff GitHub returns.
Gate and verdict
Ratchet ceilings live on the server, in a table that only accepts new rows. A lower ceiling, reported from the release branch, becomes the new ceiling without anyone being asked. A higher one turns the gate red: a ceiling only goes up with a decision recorded by a person, reason included. An incident moves to resolved only with the fix commit and the guard test, because of a database constraint.
A release waits for a person’s verdict. The verdict.request call returns the page where it is approved or rejected; approval needs a green gate, and while an incident is open the approve button does not appear.
The Commander
The Commander is an AI technical program manager that lives inside Cockpit. It reads the project and assigns tasks. An agent reads them with commander.inbox, claims one with task.claim and works it on a cockpit/ branch named after the task key, with a draft pull request. Merging stays with the person, and CI never deploys a draft or a cockpit/ branch.
While a session holds a task, a local guard, a hook that runs before every tool call, denies merges, wrangler, deploy scripts, migrations, the owner’s credential files, and any push except to the task’s branch. When the person types in the session the guard lifts, because from then on the person is the one deciding.
What it does not do yet
One person uses it: there is administrator access, not yet organisations or teams. There is no package to install, and connecting another repository means copying the hook kit by hand. The local guard exists only where the hooks are installed; on a machine without them, there is no guard. Assurance levels computed from the evidence do not exist yet, and neither does structural code coverage: coverage today is counted per requirement. The Cockpit screenshots published on this site come from a development demo, with an invented project and invented data.
Where it stands
Cockpit by RiftSeed is a prototype in development, in private preview, and the lab uses it every day on its own projects. Early access is meant for people who build with code agents and want to try it on a project of their own. It can be requested through the site chat or the contact page.
Written the way everything in this lab is built: with AI, then edited and approved by a person.