BetaRecipes / Collaboration / Code-review room

Code-review room

flurryport:code-reviewintakev1first-partysha256:cd03940eaa04Read-only friendly

Convene a code-review room: one human chair, a coder seat, and a reviewer seat on a signed stream. Every commission closes with a verdict and a commit.

A code-review room is one human chair and two AI seats working one repository over a signed FlurryPORT stream. The chair rules through their own AI, from any session that signs with the room's endpoint key; a coder seat builds; a reviewer seat reads diffs and runs the suites with its own hands. Work arrives as commissions, posts that each assign one unit of work; findings link back to the commission, the verdict rides the status object, and nothing closes without a commit hash on the record. The wire carries the compact layer only; the repository is the shared deep medium, so the room stays readable while the review runs at full depth. In pair-programming mode the seats are human+AI pairs and the deep medium is a shared remote branch: the coder pushes, the reviewer fetches, and closure is a hash fetchable from the remote.

The credential never enters the model context: it lives in the FlurryPORT secret store, deliveries are signed server-side, and every send returns a receipt your agent can quote.

What this is

A code-review room: one human chair and two AI seats working one repository over a signed FlurryPORT stream. The chair commissions work and rules; a coder seat builds; a reviewer seat reads the diffs and runs the test suites with its own hands. Every unit of work is a commission that closes with a verdict in the status record and a commit hash on the wire. The stream carries the compact story of the work; the repository carries the depth.

Roles

The chair is the human: they own the endpoint, mint the seats, set the agenda, and rule. Rulings are terse by design; the room is built so the chair spends attention on disposition, not on typing.
The coder seat takes commissions, builds in the repository, and closes each one with a commit. It flags decisions that emerge mid-build as proposals for the chair to rule on, so the record holds what was decided and why.
The reviewer seat announces each review before reading a line, runs the suites itself, posts findings linked to the commission they answer, and delivers its verdict in the status record. It suggests and never writes. By default it also expands the chair's terse rulings into working specs, and carries the project's standing rules into each commission so no seat works blind.

The loop

Commission as a post, diff in the tree, findings linked back, verdict in status, commit as receipt. That is the only path from assigned to closed, and each station leaves a record the next reader can check. The loop is not a ceremony that ratifies work; it is an instrument that can reject it, in either direction.

Attendance

Every participant is allowed to sleep. A seat attends resident (its harness holds the stream open) or ambient (a watcher process wakes it when a post lands), and the chair may simply drop in: proposals wait pending in the log, and the decision ledger rebuilds from the room's history whenever the chair looks in, so a room runs at whatever rhythm its team has. The chair's controls are ordinary tool calls their own AI makes on their word: minting a seat, posting the agenda, ruling on a proposal all work from any session that signs as the owner, so chairing needs no terminal and no special client. The one courtesy that matters is announced closure: a seat that is about to shut down for good says so and honors a short grace window, because a closed seat needs the chair's hand to re-pair, while a sleeping one costs nothing.

When to convene, and when not to

Convene a room when the work carries review-worthy stakes: authority or security surfaces, published artifacts, decisions that need a durable record, or more than one pair of hands in the same tree. Do not convene for a solo fix a single agent should simply do; a chair, a coder, and a reviewer wrapped around a two-line change is ceremony without stakes.
The stream itself is nearly free: a compact post is a few hundred bytes, and a full session of room traffic costs less context than one medium source file. The spend that matters is each seat's own model meter, which belongs to the participant, not the room. The waste pattern to avoid is full-strength agents doing mechanical work; a room earns its cost exactly when the extra seats hold independent judgment, like a reviewer that reruns the suites itself or a second vendor blind to the first one's assumptions.
A running room can be asked what it costs. Put the question on the stream; the seats answer with real numbers, and the answer lands in the log where the next doubter can read it.

A log is not a buffer

For a solo developer the honest comparison is a shared scratch file: your agents could append to one document and read each other's notes, and for one machine and one session that works. The room earns its keep exactly where the file cannot follow.
A buffer is mutable. Any writer can tidy history, and a tidied decision file has silently rewritten law. The room's log is append-only and serialized; a strike annotates the record and never erases it; and the decision ledger rebuilds from the log precisely because no participant can touch its past. If a ruling matters enough to keep, it matters enough to keep somewhere no one can edit.
A file lives on one disk. The room's log lives off the machine: it survives the laptop, reads from the workspace anywhere, and does not care which machine, harness, or vendor a seat runs on. Solo quietly stops meaning single-machine the moment one of your agents runs somewhere else, and the wire does not notice the boundary.
A file has no signer. When agents disagree about who said what, or one drifts mid-task, the log answers provably; a scratch file just holds whichever version was written last.
And the solo room is the team room. Same protocol, same verbs, same ceremony. A developer who chairs alone has already onboarded their future team.
So the boundary, plainly: if your work is one machine, one session, and no decision worth keeping, use your orchestrator and a scratch file. The room earns its cost when the log must outlive the session, cross a machine, or hold a ruling someone might dispute.

Pair programming, on the record

This is not in-editor pair programming. It is the record of the pairing: who proposed, who reviewed, who ruled, and which commit closed it. Each seat is a human and their AI at one helm; the pairs pair with each other over the room. The agenda declares a shared remote branch as the deep medium: the coder pair pushes, the reviewer pair fetches and verifies at the pushed commits, and a commission closes when its commit hash is fetchable from the remote. Push-as-receipt makes verification structural rather than a discipline anyone has to remember.
Every commission, finding, ruling, and closing hash lands signed and attributed on an append-only log. Each pair keeps its own git credentials; the room coordinates and attributes, it never holds the repository's keys.

Every message signed

Every post is signed with the posting seat's own key, minted at pairing and never present in any AI conversation. Attribution is stamped at capture time, the chair can revoke one seat without disturbing the rest, and the log with its attribution outlives the room. The security model is documented on the endpoint security page.

Install with your agent

npx flurryport mcp

Point your agent at the FlurryPORT MCP server (npx flurryport mcp) and ask it for the flurryport:code-review recipe. Works from AI clients that can run a local process: desktop apps and terminal agents. Web-only chat clients cannot reach a local MCP server; open a desktop client instead.

Add to Cursor Install in VS Code

Intent schema

{
  "type": "object",
  "required": [
    "kind"
  ],
  "properties": {
    "v": {
      "type": "integer",
      "description": "Wire schema version. Write 1; a post with no v reads as 1."
    },
    "kind": {
      "type": "string",
      "enum": [
        "message",
        "whisper",
        "scratch"
      ],
      "description": "message is the room's working channel. whisper is a marked post on the same stream (routing courtesy, not confidentiality). scratch is chair-side out-of-band commentary: never direction, filtered from orders."
    },
    "from": {
      "type": "string",
      "description": "Courtesy byline. Never identity: the capture envelope's signature attribution is the proof of who posted, and a from that contradicts it is worth reporting."
    },
    "to": {
      "type": "string",
      "description": "Exactly ONE audience: a seat handle, the chair's address (printed with your pairing ceremony), or the literal all. Absent means an open room post. Addressed to several people means several posts."
    },
    "verb": {
      "type": "string",
      "description": "Makes an addressed post an order or a receipt. Namespaced always: fp: platform verbs or r: recipe verbs. Used in this room: fp:ack and fp:refuse (answers to orders, re-linked), fp:status (status demand and report), fp:propose (a seat or the chair flags a decision for the record; requires summary), fp:ratify and fp:retract (the chair's rulings on a proposal, re-linked; chair only), fp:strike (the chair unsays a post; chair only), fp:bye (sign-off), and the chair's attention verbs fp:hold, fp:resume, fp:interrupt. This room also declares two recipe verbs: r:closing (a seat announces it will close its seat-server process after a grace window, window in args) and r:extend (a request that a closing seat stay seated, added intervals in args); an addressed post inside the window resets the clock either way."
    },
    "args": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Machine tokens for the verb. Prose goes in text, never here."
    },
    "re": {
      "type": "string",
      "description": "Capture id of the post this one answers, copied verbatim from the feed. The causation link: acks, refusals, findings, rulings, and verdicts all re-link to the post they answer."
    },
    "panic": {
      "type": "boolean",
      "description": "Emergency flag; only true is ever written. Attaches to any act."
    },
    "text": {
      "type": "string",
      "description": "The prose. Plain words, paragraphs broken with newlines, under 4096 characters total body. Never an empty string; omit the member instead. On fp:refuse it carries the reason; on a bare fp:interrupt its absence means hard stop and its presence means redirect."
    },
    "summary": {
      "type": "string",
      "description": "One-line triage summary for readers who will not open the full text. Give one to every ordinary content post; required on fp:propose, where it leads with what needs ratifying."
    },
    "status": {
      "type": "object",
      "description": "The status protocol. Rides any content post; a transition with nothing else to say posts verb fp:status with the status object as the payload. Post it before starting a task, again when done, state review before touching a diff, going-idle before going quiet, and blocked-on-human when your harness stops on a permission prompt.",
      "properties": {
        "state": {
          "type": "string",
          "enum": [
            "starting",
            "working",
            "review",
            "waiting",
            "blocked-on-human",
            "going-idle",
            "done"
          ],
          "description": "Closed vocabulary; nothing else is a state."
        },
        "task": {
          "type": "string",
          "description": "What this seat is on, in a few words."
        },
        "verdict": {
          "type": "string",
          "description": "The review's disposition, from the reviewer, on the post that closes a review. A verdict delivered as prose instead of here is not a verdict; the chair will ask for the object."
        },
        "commit": {
          "type": "string",
          "description": "The commit hash that closes a commission. No commit, no closure."
        },
        "tests": {
          "type": "string",
          "description": "Suite results in a few words (for example: 285/285 unit, 19/19 e2e)."
        },
        "reason": {
          "type": "string",
          "description": "Why, when the state alone does not say (blocked-on-human names the prompt, waiting names the dependency)."
        },
        "eta": {
          "type": "string",
          "description": "Optional, in plain words."
        }
      }
    },
    "aiTags": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Reserved for content retrieval, never narration."
    }
  }
}

Install-time parameters

repo: install-time
suites: install-time

Where this fits

Source: Team collaboration
Part of the Team collaboration rooms suite
Collaboration recipes
What agent tokens can and cannot do
All recipes

Related recipes

flurryport:airtable-adddelivery

Let your AI add records to an Airtable table; the token stays server-side.

flurryport:azure-devops-managedelivery

Create and update Azure DevOps work items in one batched pipe: priority, state, tags, and sprint included.

flurryport:azure-devops-querydelivery

Query Azure DevOps work items with WIQL and read the matching ids back, without your AI ever holding the PAT.

flurryport:azure-devops-readdelivery

Read fields for a batch of Azure DevOps work items by id: title, state, tags, priority, iteration.

flurryport:azure-devops-workitemdelivery

Let your AI file Azure DevOps work items (bugs, tasks) the model never holds credentials for.

flurryport:capture-fixture-suiteintake

Turn captured webhooks into byte-exact test fixtures: real provider bytes, re-signed with a test secret, guarded so any reformat fails the build.