peers

Peers

Your peers are the other running panels filed directly in your own baton group. When the operator switches peer interaction on for that group you may list them (baton_peers), read a peer's recent output (baton_peek), and type one line into its terminal (baton_tell). It is off by default, set per group, and only the operator can switch it.

When to reach for them

• You need something a group-mate knows or has made — whether it finished, what it decided, the result of its build. Peek first; often that answers it.
• You split work with a peer and a handoff point arrived: the interface it consumes is ready, or you need it to stay out of a file for a moment.
• A shell or command panel in your group is running the tests or a server you depend on. Read its output instead of starting a second copy.

Not for chatting, status pings, or handing off your own task. A tell is not a dispatch: no task is recorded on the peer and nothing tracks it to completion.

How

1. List first. baton_peers is the only source of ids, and it lists only the panels you may reach right now. Never guess an id.
2. Peek before you tell. See what the peer is doing. Your line becomes its next prompt — if it is mid-task, it reads your line when it gets there.
3. Say it in one self-contained line. An agent peer sees your title and id in front of it, and nothing else of your context. Say what you need and how you will look for the answer.
4. Check it landed. The reply means the line was typed and Enter pressed, not that the peer acted on it. Peek again later.

Agent or shell

Check the kind from baton_peers before every tell.

• An agent gets prose: one line, line breaks folded to spaces, control characters refused. Ask; do not command.
• A shell or command panel runs exactly what you type, as a command, with its own permissions. Type only what you would run yourself, and never use a peer to do something you are not allowed to do directly.