Ask a peer — Recued Docs

Some steps need a person who is not you. Maybe a second pair of eyes on a draft. Maybe a sign-off before money moves. Maybe a judgement call your recipe cannot make. A recipe can send 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. A door is a way in that you open on purpose. 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 each grant different things. It is easy to get the directions backwards.

To become a reviewer, someone who can be asked:

Open an MCP door for the person who will ask you. MCP is a shared language that AI apps use to call your server's tools. Grant it the peer question tool. Without that door, nothing reaches you.
On that peer's contract, grant the label they will name. A contract is the saved list of what one actor may do. Labels sit next to the rest of what that peer may do. You take them back in the same place.
Add a connection back to them, so your answer has a way home.

To ask, from the side that raises the question:

Add a connection to the reviewer. Use the secret key they gave you.
Open a door for them. Grant it the peer answer tool. That is how their answer can come back and wake up your run.
Run a recipe whose ask step names the same label they granted.

You call their door with the secret key they made. They answer through the secret key you made. Swap those one way, and their door refuses the question. Swap them the other way, and the question lands, they answer, and the answer never arrives. Your run waits forever.

#Labels

A label is a bit of text you choose yourself. Both sides must write it exactly the same way. It is matched letter for letter. Granting review:contract does not grant review:payroll. A label is a permission, not a category. Nothing is granted by default. With no grant, a peer cannot ask even one question. Not even a first one.

A label lasts as long as the contract lasts. Nothing else ends it. There is no timer. That is because a question can only be used in front of you. Every use of a label puts something on your screen. Taking the label back is the off switch.

#What travels

The question: short. This is the part that reaches a phone or a chat app.
The body: up to 16 KB of text to read. It opens on a screen where you are signed in. It is never put in the notification, on purpose. So a long or private draft is safe to send.
The answer: one of the choices the asker offered, plus a written reason. The asking recipe decides if the 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 keeps checking in a loop. When the answer arrives, the run goes on from the exact step that asked. If the peer says no, that is an answer too. Your recipe sees which choice they picked and what they wrote.

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

#For pack authors

The ask is a core operation, core.peer.ask. No single pack owns it. Any recipe can use it. Give it a connection, a label, a question, and the choices you will accept. You can also give it a body to read, and say whether a written reason is required. The peer-review pack is one small recipe built on exactly this. 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, not 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.