mirror of
https://github.com/stablyai/orca.git
synced 2026-11-14 09:57:48 +00:00
Jinwoo Hong
bd56be7146
* feat(orchestration): mail agents on a paired server with send --on, replies come back by themselves * fix(orchestration): gate --on on the carrying Orca, ack retried deliveries, refuse payloads and federated workers * chore(orchestration): annotate peer-mail row casts and drop a wall-clock wait in its test * chore(orchestration): name mail-between-servers codes server_mail_unsupported and mail_requires_server_pairing * docs(cli): list --on in the orchestration reply usage * fix(orchestration): name --environment, the flag on main, in agent mail refusals and the guide * chore(orchestration): mark the two deliberate agent-kind branches mail between servers needs * docs(cli): leave --on out of the reply usage; it is accepted only to refuse it * fix(orchestration): keep peer conversations to peer ids, survive resets and re-pairs, keep pulling on a registry error - A server takes only peerconv_ conversation ids, so a paired computer cannot name another Orca's dispatch in the relay. - A replayed reply after a mail reset is acknowledged, not retried forever; reset tasks keeps replies waiting to be pulled. - A re-paired server starts a new conversation instead of refusing every later send and reply. - A failed registry read keeps the pull loop retrying. - Drop the two ast-grep-ignore lines that only #40193's rule needed. * fix(orchestration): worker-start --on runs on the caller's own Orca, like send --on An inherited ORCA_ENVIRONMENT sent worker-start --on to that server, so the --on command the agent refusal suggests did not work. One rule now keeps send, reply and worker-start with --on on the caller's own Orca. * fix(orchestration): refuse reply --on on both sides of a conversation between servers The side that opened the conversation still took --on when it named the right server; the reply usage says --on is accepted only to refuse it.