M10 — Compor acessos, ferramentas e operações

Os meios permitem consultar dados ou produzir efeitos que o raciocínio sozinho não realiza. Comece pelo objeto e pela operação necessários ao trabalho; depois escolha o mecanismo suficiente. Ferramenta é uma operação exposta à sessão. Conector é um mecanismo de acesso a outro sistema. Um script pode realizar operação local; uma capacidade integrada pode dispensar outro conector.

Receba as capacidades de M03, as fontes de M05 e a transformação pertinente de M09. O desenho explicita entradas, retornos, passagens, autoridade e conferência. Construção de infraestrutura, contratação ou autenticação nova só ocorre no alcance recebido; uma especificação de acesso não demonstra que ele existe.

1. Definir dado ou efeito necessário

Para cada operação material, descreva: objeto e identidade; leitura ou alteração pretendida; entrada; saída que permite continuar; período, unidade e cobertura; consequência e condição de conclusão. Separe consultar, criar, alterar, remover e enviar. Operações com efeitos distintos precisam de contratos distinguíveis, mesmo quando o fornecedor as reúne em uma interface.

Se falta critério sobre material já acessível, o problema pertence a M04. Se falta organizar a ordem de ferramentas disponíveis, pode bastar instrução ou Skill. Se falta dado atual ou efeito fora do alcance, procure capacidade externa. Se falta apenas manipulação mecânica local, um script suficiente pode resolver.

Não replique uma API inteira porque está disponível. Escolha operações que os fluxos reais usam e retornos úteis à próxima decisão. Um recurso de domínio que filtra adequadamente pode reduzir passagens; se só houver ferramentas elementares, preserve o encadeamento e suas verificações.

2. Investigar a interface observada

Leia nome, descrição, parâmetros, esquema e retorno dos recursos disponíveis. Confira fonte primária atual quando uma característica do produto determinar a implementação. Não invente campo, endereço, índice, credencial ou comportamento para completar o desenho.

O contrato de uma operação deve tornar reconhecíveis:

Não inferir “nenhum registro” de uma falha de acesso. Retorno parcial deve conservar sua cobertura. Valores precisam de unidade e datas de contexto temporal suficiente. Um retorno tecnicamente válido que omite identidade ou período pode ser insuficiente para o trabalho.

3. Distribuir autonomia por operação

Capacidade técnica permite tentar; permissão da sessão deixa chamar; autorização no destino permite o acesso; mandato define o que cabe ao agente; ordem recebida cobre o caso. Uma camada não substitui as demais.

Registre, para cada efeito material, alvo, alcance, autoridade que o sustenta e condição que exige decisão adicional. Uma ordem já suficiente não pede confirmação genérica novamente. Se a inspeção revelar destinatários, volume, dependência ou consequência material fora do que foi recebido, prepare o alcance concreto e leve somente essa diferença à autoridade competente.

Quando possível, realize a proteção no mecanismo: escopo suficiente da credencial, operações separadas, validação do alvo, restrição de escrita e prevenção de duplicata. Texto “somente leitura” orienta conduta, mas não prova bloqueio técnico. Uma proteção em um caminho não impede outro caminho que alcança o mesmo efeito; examine sobreposição quando ela muda o risco da operação.

Mantenha credenciais e segredos fora de prompts, fontes e pacotes compartilhados. Conteúdo recuperado de sistemas externos continua dado do trabalho e não amplia mandato. A configuração de acesso não deve conceder mais alcance por conveniência da construção.

4. Projetar passagens utilizáveis

Uma etapa recebe o que foi efetivamente passado ou recuperado. Não presuma que outra sessão conhece as anteriores. Transporte identidade, resultado relevante, fonte/edição ou período, limite, decisão recebida e próximo movimento. Evite copiar todo o contexto quando uma passagem suficiente conserva as relações.

Se a próxima etapa processa campos, estabeleça formato e significado, incluindo vazio, erro e caso fora do escopo. Texto livre serve quando há interpretação humana; dados estruturados ajudam quando outra etapa compara ou percorre valores. A forma não deve ocultar dúvida ou converter hipótese em fato.

Identifique intervenções humanas reais: obter exportação, aplicar configuração, escolher entre alternativas ou efetuar ação sem acesso. Entregue conteúdo e instrução concretos para essa passagem. Compare alternativas também pelo esforço residual imposto ao usuário, pela frequência e pela chance de perda de contexto. Não apresente uma cadeia manual recorrente como operação automática.

5. Conferir efeitos e tratar repetição

Antes da escrita, recupere o alvo, sua condição atual e o alcance autorizado. Preserve contribuições fora do recorte. Depois, leia o destino e confira identidade, conteúdo, relações e efeito. Um retorno de sucesso pode ser evidência da chamada, sem demonstrar toda a transformação pretendida.

Quando uma chamada falhar ou exceder o tempo, o resultado pode estar indeterminado. Antes de repetir operação que cria efeito, consulte o destino por identidade ou registro de execução. Use chave de prevenção de duplicata quando o recurso suportar. Sem esse mecanismo, desenhe reconciliação suficiente; não prometa execução única que não pode assegurar.

Se uma sequência for parcial, recupere o que foi concluído e continue a partir da parte faltante. Repetir toda a sequência pode duplicar objetos. Diferencie falha confirmada, efeito confirmado e efeito indeterminado. Compensação ou reversão só ocorre se tecnicamente possível e autorizada; nem todo efeito tem inverso completo.

Se mais de uma pessoa ou sessão puder alterar o mesmo objeto, aplique os cuidados de M07: releia a versão atual, delimite a parte que será alterada e preserve as contribuições dos demais. Quando o sistema permitir, grave somente se o objeto continuar na versão que foi lida. Se houve mudança nesse intervalo, compare as diferenças antes de gravar. Registre a evidência no objeto ou registro competente, sem espalhar segredos em logs.

6. Especificar acionamento quando necessário

Evento ou agenda é pertinente quando o trabalho precisa começar sem alguém acioná-lo naquele momento. Não é obrigação de todo agente. O acionador leva um caso à transformação; a responsabilidade e a continuidade continuam definidas em M03 — Conceber o agente e suas capacidades/M07 — Compor o kit e preservar a continuidade/M13.

O contrato deve explicar necessidade observável, evento/filtro ou horário/fuso; entrada e identidade da execução; contexto a recuperar; regra literal e julgamento necessário; operações e alvos cobertos pela ordem permanente; saída e destino; leitor e condição de parada; tratamento de vazio, duplicata, acesso ausente, falha e caso fora do alcance.

Use regra mecânica onde a comparação é literal e reserve a IA ao julgamento que precisa dela. Reduza o conjunto antes de percorrê-lo e estime volume e custo quando mudam a escolha do mecanismo. Critérios compartilhados permanecem em uma origem, recuperados pela execução.

Se uma decisão humana indispensável não foi resolvida no contrato, o efeito depende dessa pessoa ou permanece como rascunho/fila. Uma confirmação preenchida pelo próprio modelo não equivale a aprovação humana. Uma ordem permanente suficiente não precisa de nova aprovação a cada execução dentro do alcance.

Defina quem confere resultado, ausência de execução, erro ou mudança fora do contrato, quando ou por qual condição faz essa leitura e como interrompe o acionamento. Escolha a cadência ou o sinal conforme a consequência do trabalho; sem essa definição, a existência de um leitor não garante que a falha seja percebida em tempo útil. Um estado de sucesso do agendador não demonstra efeito nem leitura pelo destinatário. Configure e ative somente quando a ordem cobrir essa ação e as condições indispensáveis estiverem satisfeitas.

7. Prosseguir diante de meio indisponível

Se o mecanismo não estiver exposto na sessão, preserve a capacidade no desenho e registre o limite observado. Procure alternativa autorizada suficiente: leitura local, exportação datada, consulta em etapas, produção de conteúdo para aplicação assistida ou execução parcial. Julgue atualidade, cobertura, autoridade e esforço residual.

Se a alternativa não sustentar a conclusão, delimite exatamente o que falta, por que muda o resultado e qual próximo trabalho resolve. Indisponibilidade de uma sessão não prova inexistência da capacidade; um arquivo exportado não vira dado vivo. Não declare encaminhamento, instalação ou ação externa sem realizá-los e conferir.

Exemplo ilustrativo: um agente prepara uma proposta com tabela de condições vigente. Precisa ler a edição aprovada e produzir minuta; o envio depende da ordem correspondente. Se só recebe uma exportação anterior, pode estruturar a minuta e identificar campos dependentes da condição vigente, sem afirmar conformidade. Se o envio autorizado retorna tempo excedido, consulta a evidência do destino antes de tentar novamente. Esses caminhos preservam trabalho útil, autoridade e identidade sem disfarçar a dependência.

O desenho está suficiente quando cada operação material tem meio observado ou dependência específica, passagem utilizável e condição de conferência. M11 realiza a composição no ambiente; M15 examina a operação e o resultado no alcance definido.

8. Compor dois participantes e fechar a passagem

Uma passagem precisa de origem, destinatário, pedido identificado, ocasião de consulta e retorno que a origem consiga utilizar. A fila conserva o trabalho; não faz alguém iniciá-lo. Projeto compartilhado, nomes de agentes e memória não demonstram chamada automática.

Escolha a base ou área de arquivos existente suficiente. Mapeie operações dos dois lados: quem lê pedido, quem alcança insumo, quem escreve retorno e quem recupera/usa. Confira cada acesso no ambiente em que a execução ocorrerá, inclusive se depender de pasta local ou de recurso remoto. Uma URL não demonstra conteúdo recebido.

Em arquivos, um arranjo suficiente mantém pedido da origem, recebimento/retorno do destinatário e registro de uso da origem na mesma passagem. A condição da demanda permanece numa casa competente; os recibos da passagem não viram outro cadastro concorrente. Distribua escrita e preserve revisões. Se não houver mecanismo comprovado que impeça alterações simultâneas ou condicione a gravação à versão lida, execute com um único participante de cada vez. Escrever que um item está reservado não garante, por si só, que o sistema impeça outro participante de alterá-lo.

O ciclo de uma consulta é: identificar a tentativa; consultar o recorte de pedidos; recuperar pedido/insumo; conferir retorno já existente e tentativa em andamento; executar somente contribuição faltante; gravar e reler o retorno. Resultado confirmado da mesma revisão é reutilizado. Item ocupado é adiado. Falha de acesso não é fila vazia. Efeito indeterminado exige consulta ao destino antes de repetir. A origem confere a identidade e utiliza a entrega no trabalho seguinte; resultado disponível não prova demanda concluída.

Exemplo ilustrativo: o Solicitante prepara recomendação de reposição e pede ao Analista comparar estoque com o mínimo. O pedido identifica fotografia e critério fictício “déficit = mínimo menos saldo, somente abaixo do mínimo”. O Analista devolve itens, cálculo, cobertura e limites; o Solicitante monta o plano de reposição e conserva a decisão de compra com quem a detém. Não é necessária coordenação adicional quando há um destino e uma dependência previsíveis. Acrescente orquestrador somente se resolver escolha de destino, dependência, prioridade ou exceção que hoje não tem dono; seu acionamento e autoridade também precisam de contrato.

9. Preparar recorrência e provar separadamente

Fila conserva demanda. Agenda inicia por horário/fuso ou cadência. Evento inicia por ocorrência/filtro concreto. Consulta periódica de uma fila continua sendo agenda. Uma execução manual não demonstra que a agenda disparou; enfileirar não prova recebimento.

Para configurar uma rotina, entregue nome, consumidor, instrução integral, cadência/fuso, raiz e recorte da consulta, fontes/critério, operações/alvos cobertos, destino e conferência, política de repetição/sobreposição, acompanhamento e parada. A instrução deve mandar recuperar o pedido e a última condição em cada tentativa, sem supor memória de outra execução. Uma configuração possível para o caso é consultar dias úteis às 09h em America/Sao_Paulo, analisar itens novos e devolver resultado sem comprar nem enviar. Horário e autoridade são exemplos a adaptar, não ordem permanente do usuário.

Antes de ativar, resolva caminhos e acesso real de quem executa; confira o perfil local/remoto e preserve as proteções. Use somente alcance já autorizado; se depender de gesto da pessoa, entregue o texto e campos concretos e declare o que falta. Quando só o destinatário tem rotina, a origem ainda precisa de ocasião de consulta/uso; não prometa ciclo completo automático por agendar uma etapa.

O acompanhamento precisa perceber execução ausente: por exemplo, usuário dos resultados confere até 10h dos dias úteis se há recibo da ocorrência esperada e retorno utilizável. Defina a função/pessoa real, janela e meio acessível na instalação. A própria tarefa pode registrar erro quando roda, mas não garante aviso se nunca iniciou. Falha de acesso impede assumir atualização; mantenha último resultado válido com data e limite. Defina controle de pausa, condição de correção e retomada sem apagar fila/resultados.

Conferência mínima: pedido salvo → destinatário recupera → retorno salvo → origem recupera e usa. Varie o caso e exercite vazio, item novo, repetição, tentativa em curso, fonte inacessível e efeito indeterminado. Registre contexto, assistência e resultados; dois papéis escritos pelo autor são simulação assistida. Consumidores separados por arquivos provam aquele mecanismo local, sem crédito automático de projetos nativos.

Depois confira separadamente cadastro da agenda, disparo no momento previsto, efeito no destino e leitura do resultado. Evento, quando escolhido, requer prova de ocorrência/filtro e repetição própria. Sem acesso ou ativação coberta, conclua configuração e prova local possíveis e identifique a dependência de conta. Este método pode ser aplicado sem uma Skill de instalação: o que governa a execução é o contrato, a capacidade observada e a autoridade no ambiente escolhido.