Protocolos de Time

s01 > s02 > s03 > s04 > s05 > s06 | s07 > s08 > s09 > [ s10 ] s11 > s12

"Companheiros precisam de regras de comunicação compartilhadas" -- um padrão request-response conduz toda a negociação.

Problema

No s09, companheiros trabalham e se comunicam mas carecem de coordenação estruturada:

Shutdown: Matar uma thread deixa arquivos pela metade e config.json desatualizado. Você precisa de um handshake: o lead faz request, o companheiro aprova (finish e exit) ou rejeita (keep working).

Aprovação de plano: Quando o lead diz "refatore o módulo auth", o companheiro começa imediatamente. Para mudanças de alto risco, o lead deve revisar o plano primeiro.

Ambos compartilham a mesma estrutura: um lado envia um request com um ID único, o outro responde referenciando esse ID.

Solução

Shutdown Protocol            Plan Approval Protocol
==================           ======================

Lead             Teammate    Teammate           Lead
  |                 |           |                 |
  |--shutdown_req-->|           |--plan_req------>|
  | {req_id:"abc"}  |           | {req_id:"xyz"}  |
  |                 |           |                 |
  |<--shutdown_resp-|           |<--plan_resp-----|
  | {req_id:"abc",  |           | {req_id:"xyz",  |
  |  approve:true}  |           |  approve:true}  |

Shared FSM:
  [pending] --approve--> [approved]
  [pending] --reject---> [rejected]

Trackers:
  shutdown_requests = {req_id: {target, status}}
  plan_requests     = {req_id: {from, plan, status}}

Como Funciona

1. O lead inicia shutdown gerando um request_id e enviando através da caixa de entrada.

shutdown_requests = {}

def handle_shutdown_request(teammate: str) -> str:
    req_id = str(uuid.uuid4())[:8]
    shutdown_requests[req_id] = {"target": teammate, "status": "pending"}
    BUS.send("lead", teammate, "Please shut down gracefully.",
             "shutdown_request", {"request_id": req_id})
    return f"Shutdown request {req_id} sent (status: pending)"

1. O companheiro recebe o request e responde com approve/reject.

if tool_name == "shutdown_response":
    req_id = args["request_id"]
    approve = args["approve"]
    shutdown_requests[req_id]["status"] = "approved" if approve else "rejected"
    BUS.send(sender, "lead", args.get("reason", ""),
             "shutdown_response",
             {"request_id": req_id, "approve": approve})

1. Aprovação de plano segue o padrão idêntico. O companheiro submete um plano (gerando um request_id), o lead revisa (referenciando o mesmo request_id).

plan_requests = {}

def handle_plan_review(request_id, approve, feedback=""):
    req = plan_requests[request_id]
    req["status"] = "approved" if approve else "rejected"
    BUS.send("lead", req["from"], feedback,
             "plan_approval_response",
             {"request_id": request_id, "approve": approve})

Uma FSM, duas aplicações. A mesma máquina de estados pending -> approved | rejected gerencia qualquer protocolo request-response.

O Que Mudou Desde s09

Componente	Antes (s09)	Depois (s10)
Ferramentas	9	12 (+shutdown_req/resp +plan)
Shutdown	Apenas saída natural	Request-response handshake
Plan gating	Nenhum	Submeter/revisar com aprovação
Correlação	Nenhum	request_id por request
FSM	Nenhum	pending -> approved/rejected

Experimente

python agents/s10_team_protocols.py

1. Spawn alice como coder. Então requisite o shutdown dela.
2. Liste companheiros para ver o status de alice após aprovação de shutdown
3. Spawn bob com uma tarefa de refatoração arriscada. Revise e rejeite seu plano.
4. Spawn charlie, faça ele submeter um plano, então aprove-o.
5. Digite /team para monitorar statuses