Ask a peer — Recued Docs

Some steps need a person who is not you: a second pair of eyes on a draft, a sign-off before money moves, a judgement call your recipe cannot make. A recipe can put one question to the owner of another Recued server and pause there. When they answer, your run picks up where it stopped.

The door that receives a question is part of every server. The person you ask installs nothing — no pack, no recipe. They decide, once, that you may ask.

#The two sides

The reviewer and the asker grant different things, and the directions are easy to invert.

To become a reviewer — someone who can be asked:

Open an MCP door for the person who will ask you, and grant it the peer question tool. Without that door, nothing reaches you.
On that peer's contract, grant the label they will name. Labels appear alongside the rest of what that peer may do, and revoke in the same place.
Enrol a connection back to them, so your answer has a route home.

To ask — from the side that raises the question:

Enrol a connection to the reviewer, using the credential they gave you.
Open a door for them and grant it the peer answer tool, so their verdict can come back and resume your run.
Run a recipe whose ask step names the same label they granted.

You call their door with the credential they minted; they answer through the credential you minted. Swap those one way and the question is refused at their door. Swap them the other way and the question lands, they answer, and the verdict never arrives — a run that waits forever.

#Labels

A label is a free-form string both sides name identically, and it is matched exactly. Granting review:contract does not grant review:payroll; it is a capability, not a category. Nothing is granted by default — with no grant, a peer cannot raise a single question, not even a first one.

A label lasts as long as the contract does and expires on nothing else. There is no timer, because a question can only ever be exercised in front of you: every use of a label puts something on your screen. Revoke is the off switch.

#What travels

The question — short, and the part that reaches a phone or a chat app.
The body — up to 16 KB of document to read, opened on a signed-in surface and deliberately never placed in the notification. A long or sensitive draft is safe to send.
The answer — one of the options the asker offered, plus a written reason. The asking recipe decides whether that reason is optional or required.

#While you wait

A run that is waiting on a peer is filed as held, not failed. It survives a restart, nothing polls, and when the answer arrives the run resumes from the exact step that asked. If the peer declines, that is an answer too: your recipe sees which option they chose and what they wrote.

Both sides keep their own audit trail — who asked, who answered, when, and under which label.

#For pack authors

The ask is a core operation (core.peer.ask), not something one pack owns. Any recipe can use it: give it a connection, a label, a question, the options you will accept, and optionally a body to read and whether a written reason is required. The peer-review pack is one small recipe built on exactly this, and your pack can be another.

Two things to design around. The question is the part that travels to a phone, so put the document in the body rather than in the question. And a held run is a normal outcome, not an error — write the step after the ask as if the answer could be either one.