# Rotinas Cowork — passagens, fila e recorrência Edição candidata 1.0.1 · 05/11/2026. Use ao preparar trabalho entre projetos ou execução recorrente. Este apoio contém método suficiente para a instalação avulsa; não exige Notion, outro plugin ou API própria. Preparação não comprova implantação de conta. ## 1. Começar pela contribuição Identifique o resultado que o trabalho precisa produzir, quem pede, quem contribui e quem usa o retorno. Aproveite a demanda e a fila existentes quando suficientes. Duas contribuições previsíveis não exigem um terceiro agente: um projeto registra a necessidade; o destinatário consulta, produz e devolve; a origem confere e utiliza. Um orquestrador se justifica quando precisa escolher destino, ordenar dependências, conciliar prioridade ou tratar exceção sem dono. Escreva essa contribuição antes de acrescentá-lo. Receba o que a pessoa já informou e descubra os meios disponíveis. Só leve a ela uma escolha que realmente dependa de sua realidade ou autoridade; apresente alternativas com consequência concreta. Não exija que escolha protocolo, runtime ou formato de persistência. ## 2. Escolher e conferir o meio | Situação | Realização suficiente | Conferir | |---|---|---| | Ambos consultam e escrevem na mesma base autorizada | Uma demanda com pedido, retorno e uso, sem duplicar cadastro | Identidade, leitura/escrita por operação, filtro e atualização concorrente | | Ambos alcançam uma área de arquivos | Pasta de intercâmbio com contribuições separadas | Mesmo destino real, leitura de insumos, escrita e releitura de cada lado | | Um lado só recebe conteúdo transferido | Passagem assistida com conteúdo integral/arquivo e retorno explícito | Quem transporta, quando, cobertura e esforço residual | | Existe chamada nativa adequada | Chamada somente após observar interface e efeito | Destinatário, contexto recebido, retorno, repetição e autoridade | Não trate memória, nomes de agentes ou presença no mesmo produto como chamada entre projetos. O arquivo ou a URL do distribuidor não substitui o destino da instância do usuário. Mapeie cada operação antes de configurar: | Operação | Quem faz | Evidência necessária | |---|---|---| | Registrar pedido identificado | Solicitante | Objeto salvo e relido no destino competente | | Encontrar e ler pedido/insumos | Destinatário | ID/revisão, fonte e conteúdo efetivamente recuperados | | Reservar/processar | Consumidor designado | Política de concorrência e identificação da tentativa | | Gravar retorno | Destinatário | Mesmo pedido/revisão, resultado relido e limites | | Recuperar, conferir e usar | Solicitante | Artefato/ação seguinte que aplica o retorno | | Acompanhar ocorrência/ausência | Função definida pelo usuário | Histórico acessível, janela de atraso e ocasião de leitura | Registre a restrição real do mecanismo. Instrução de escrita limitada orienta conduta; não demonstra bloqueio técnico. Evite expor pastas alheias apenas para facilitar intercâmbio. ## 3. Contrato pronto de pedido e retorno Preencha com o caso. Estes nomes de campos são um formato por arquivos, não campos obrigatórios de plataforma. Em uma base existente, mapeie-os às propriedades e ao corpo disponíveis. ```json { "id": "PED-001", "revisao": 1, "origem": "Projeto Solicitante", "destinatario": "Projeto Analista", "contribuicao": "Comparar a fonte com o critério indicado e devolver uma recomendação fundamentada", "insumos": [{"local": "Insumos/fonte.csv", "edicao": "fotografia identificada", "periodo": "período do caso"}], "criterio": "Critério suficiente e sua fonte/edição", "aceitacao": "Resultado, sustentação e limites utilizáveis pela origem", "efeitos_autorizados": "Ler estes insumos e gravar retorno nesta passagem", "decisao_reservada": "Aprovar ou executar a ação final de negócio", "retorno": "Fila/PED-001/r1/retorno.json" } ``` Antes de aceitar o trabalho, o destinatário confirma destinatário, revisão, contribuição, suficiência dos insumos, autoridade e destino. Se falta algo indispensável, devolve impedimento específico em lugar acessível; não fabrica resultado nem pede tudo novamente. ```json { "pedido": "PED-001", "revisao": 1, "tentativa": "EXEC-identificada", "situacao": "resultado_disponivel", "resultado": "Resultado ou localização identificável do artefato", "fontes_recebidas": ["local e edição/período realmente lidos"], "cobertura": "O que foi examinado e o que ficou de fora", "conferencia": "O que foi relido/calculado/confrontado", "efeitos": "Confirmados, não realizados ou indeterminados", "limites": "Incertezas e dependências materiais", "proximo_movimento": "Como a origem deve usar a contribuição" } ``` A origem recupera esse retorno pela mesma identidade, confere se responde ao pedido e registra seu uso: decisão preparada, documento composto, etapa seguinte ou recusa fundamentada. “Resultado disponível” encerra a contribuição do destinatário; a demanda só termina conforme seu próprio critério. Uma pendência de uso continua visível na condição competente. ## 4. Um arranjo por arquivos, sem estado concorrente ```text Trabalho/ Projeto-A/Demanda.md ← condição da demanda, mantida pela origem Projeto-A/Plano.md ← resultado que usa o retorno Insumos/fonte.csv ← fotografia ou fonte do caso Fila/PED-001/r1/ pedido.json ← origem registra e preserva a revisão recebimento.json ← destinatário registra tentativa/impedimento retorno.json ← destinatário entrega e relê uso.md ← origem registra como utilizou Execucoes/ ← recibos de consulta, inclusive vazio/erro ``` Os caminhos são relativos à raiz de trabalho compartilhada resolvida na instalação. A pasta da fila identifica a passagem; não cria outra demanda de negócio. “A fazer”, “em processamento” e outras condições são mapeadas ao vocabulário que a pessoa já utiliza. Não acrescente um segundo campo de condição editável em outra casa. Neste arranjo, processamento serial e contribuições separadas reduzem disputa. `recebimento.json` é evidência de uma reserva lógica; escrita comum não garante exclusão atômica. Se vários consumidores ou acionadores puderem operar ao mesmo tempo, use mecanismo de exclusão/atualização condicional comprovado ou limite o desenho a um consumidor serial. Uma marca expirada não libera sozinha nova tentativa: confira parada e destino anterior. ## 5. Consultar, executar e retomar Em cada consulta, registre identidade da tentativa e instante efetivo. Liste apenas pedidos elegíveis para o destinatário e recupere revisão/insumos necessários. Trate estas condições antes de produzir efeito: | Condição encontrada | O que fazer e preservar | |---|---| | Fila consultada sem pedidos elegíveis | Registrar vazio com cobertura; não inventar trabalho | | Pedido novo suficiente | Confirmar escopo, receber, executar, reler e devolver | | Retorno existente da mesma revisão | Conferir integridade/efeito; reutilizar sem regravar nem duplicar | | Pedido/revisão não corresponde ao retorno | Preservar arquivos e registrar divergência; não aceitar por nome parecido | | Tentativa anterior em andamento | Adiar o item e registrar sobreposição, sem substituir a reserva | | Fonte/fila sem acesso | Distinguir caminho inexistente, permissão negada e indisponibilidade; não registrar vazio | | Parte concluída, outra falhou | Preservar o confirmado e retomar só a parte faltante | | Efeito possivelmente ocorreu sem recibo | Consultar o destino antes de repetir; manter indeterminado se não houver prova | | Pedido fora do escopo | Retornar limite e destinatário/meio apropriado quando conhecido | Depois de escrever retorno, confira conteúdo e identidade no destino. Se houver resultado existente mas recebimento incompleto, reconcilie os registros; não repita a operação só para completar o histórico. Uma revisão nova precisa explicitar o que mudou e se invalida o resultado anterior. ## 6. Caso neutro — dois projetos **Projeto Solicitante:** preparar recomendação de reposição de estoque. **Projeto Analista:** comparar saldo com mínimo e devolver déficit por item. **Fonte:** fotografia de estoque e critério fictício “abaixo do mínimo, déficit = mínimo menos saldo”. Por exemplo, saldo 9 e mínimo 12 dão déficit 3. O resultado não autoriza compra. O Solicitante registra pedido com edição da fotografia, critério, destino e limite. O Analista consulta a fila, lê a fotografia, calcula somente o sustentado e devolve tabela com itens, déficit, cobertura e limites. O Solicitante lê o retorno e monta seu plano, identificando os itens sugeridos e a decisão de compra ainda necessária. Sem escolha de destinos ou dependência extra, nenhum terceiro orquestrador é necessário. A prova atravessa pedido salvo → leitura pelo destinatário → retorno salvo → leitura e uso pela origem. Para testar transferência, use novos valores/itens em uma segunda ocorrência e preserve as entradas/saídas. Execução de dois papéis pelo mesmo autor é simulação assistida; consumidores separados por arquivos demonstram esse mecanismo local, sem provar dois projetos Cowork. ## 7. Fila, agenda e evento Fila conserva trabalho; consulta manual começa pela pessoa; agenda inicia a consulta num horário/fuso; evento inicia pela ocorrência/filtro. Ler a fila periodicamente é agenda, mesmo que o conteúdo da fila tenha mudado. Enfileirar não demonstra que o destinatário iniciou; executar agora não demonstra que o horário recorrente funcionou. Uma rotina pode entregar apenas a contribuição do Analista. Nesse caso, o uso pelo Solicitante precisa de ocasião própria: consulta manual, outra agenda ou evento realmente disponível. Não prometa ciclo completo automático configurando só um lado. ### Configuração pronta para adaptar e aplicar **Nome:** Conferir pedidos de análise de estoque. **Cadência proposta:** dias úteis às 09h. **Fuso:** America/Sao_Paulo. **Consumidor:** Projeto Analista, serial. **Efeito:** ler pedidos/fontes e gravar retorno na fila de teste. **Ativação:** não realizada por este documento. O instalador resolve na instância a raiz de trabalho, o local dos critérios e o destino dos recibos e entrega a instrução abaixo com esses caminhos reais. Não agende texto com localizadores ainda não resolvidos. > Na raiz de trabalho compartilhada desta instância, consulte Fila e processe os pedidos destinados ao Projeto Analista. Recupere pedido, revisão, contribuição, critério e insumos do próprio item. Registre esta tentativa do Projeto Analista em Execucoes, com identidade da tentativa, instante e cobertura reais e resultado ou erro. Identifique a ocorrência prevista quando ela vier do acionador; não invente horário de agenda numa execução manual. Confira retorno já existente e tentativa em andamento antes de agir. Reutilize resultado confirmado da mesma revisão, adie item ocupado e informe fonte/fila inacessível sem tratar falha como vazio. Para item novo suficiente, leia os insumos, aplique o critério recebido, grave retorno identificado na localização pedida e releia seu conteúdo. Limite-se a leitura e ao retorno de análise: compra, envio e alteração de sistema de negócio não estão cobertos. Preserve efeitos confirmados; após efeito indeterminado, consulte o destino antes de repetir. Se nenhum item for elegível, registre execução vazia. Termine com itens concluídos, reutilizados, adiados, impedidos e destino dos resultados. Não declare que a origem utilizou o retorno sem evidência. **Acompanhamento proposto para o caso:** a pessoa que utiliza a recomendação acompanha a execução do **Projeto Analista**. Até 10h de cada dia útil, confere no histórico da tarefa e em `Execucoes/` o recibo do Analista correspondente à ocorrência esperada das 09h, verificando tentativa, instante real, cobertura e resultado ou erro. Para cada pedido processado, confere o retorno produzido pelo Analista em `Fila//r/retorno.json`, com a identidade/revisão do pedido e a situação efetiva. Ausência do recibo esperado ou erro de acesso impede assumir análise atualizada; ela verifica o mecanismo antes de usar informação antiga como nova. Nome/papel real e disponibilidade precisam ser definidos com a pessoa na implantação. A tarefa não detecta sozinha que nunca iniciou. **Prova de uso pela origem:** em etapa própria, o **Projeto Solicitante** consulta os retornos do Analista, confere e aplica a contribuição em seu plano. O plano em `Projeto-A/` e o registro `uso.md` da passagem demonstram esse uso quando efetivamente produzidos e conferidos. A agenda das 09h pertence ao Analista: ela não garante a execução do Solicitante, a produção do plano nem a decisão humana. A ocasião de retomada da origem precisa ser definida separadamente. **Parada/retomada:** pausar pelo controle efetivamente disponível quando mudar fonte, alvo, ordem ou persistir erro que impeça operação confiável. A retomada começa pela última tentativa/resultado confirmados. Mudança de agenda não apaga a fila nem os resultados. A função de acompanhamento e o controle de pausa devem estar acessíveis. ### Perfil de execução e aplicação na conta Siga o [perfil Cowork](perfil-cowork.md) quando incluído na edição; se ausente, mapeie diretamente conta/superfície, instrução recebida, fonte, ferramenta e persistência pelos critérios deste apoio. A documentação de [tarefas agendadas](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork), consultada em 05/11/2026, distingue execução remota de tarefas que exigem arquivos/apps locais. Confira o perfil efetivo e a dependência do computador antes de prometer disponibilidade. O [artigo de projetos](https://support.claude.com/en/articles/14116274-organize-your-tasks-with-projects-in-claude-cowork) distingue metadados na conta e arquivos locais. Estar no projeto não prova acesso remoto à pasta. Após ordem suficiente para configurar/ativar, use os controles reais da conta: revise nome, instrução, cadência, fuso, pasta/recursos, modo de aprovação e identidade; salve e releia. Não mude proteções para fabricar execução. Registre identificação recuperável da tarefa, próxima ocorrência e como pausar. Se a interface exigir gesto da pessoa, entregue os campos já preenchíveis e acompanhe a conferência; não anuncie ativação antes dela. ## 8. Conferência por camada 1. **Preparado:** contrato, mapa de operações, instrução e configuração completos; caminhos resolvidos na instância. 2. **Execução manual:** novo item, vazio, repetição, sobreposição e falha, com conteúdo e resultado salvos. Distinguir reserva sem trava de concorrência realmente bloqueada. 3. **Agenda configurada:** cadastro relido, identidade, cadência/fuso e próxima ocorrência. Não prova disparo. 4. **Agenda executada:** ocorrência esperada consta no histórico e a transformação produziu efeito conferido no destino. Registrar atraso/omissão. 5. **Evento:** se escolhido, ocorrência e filtro reais produzem execução identificada; replay e fora do filtro são provas próprias. 6. **Uso e continuidade:** origem usa o retorno, outra conversa recupera a demanda e o acompanhamento percebe falha/ausência no prazo definido. Guarde na casa da instância pedido/revisão, insumos, contexto recebido, ações, saídas literais, intervenção, conferência, efeito e limite. Casos/gabaritos de avaliação ficam fora do pacote operacional. Sem acesso ou ativação coberta, conclua preparação e prova local suficiente, deixando dependência de conta específica; não converta documento em prova de agenda.