Da ideia à decisão: requisitos, painel de arquitetos e ADR

Todo projeto que eu vi dar errado começou escolhendo serviço antes de escrever requisito. requirements_check existe para forçar a ordem certa. Ela recebe três campos: workload (o texto livre do problema), requirements (lista) e constraints (lista). Não recebe SLA nem orçamento como número mágico, e é de propósito: a descrição da ferramenta diz "No inferred SLA or budget".

O que ela devolve é um espelho mais honesto do que você escreveu. Repete workload, requirements e constraints exatamente como entraram e acrescenta decisionsToClarify, sete pontos que sempre precisam de resposta antes de desenhar:

• resultado de negócio e dono do workload;
• classificação, residência e retenção dos dados;
• tráfego normal e de pico, payload e crescimento;
• SLO, p95/p99, RTO e RPO;
• autenticação, autorização e tenancy;
• orçamento com moeda e região de preço;
• habilidades do time, dependências e restrições de migração.

Repare no que não aconteceu: ninguém chutou que 300 pedidos/minuto são 5 RPS sustentados (o pico tem forma, e a ferramenta não a conhece), ninguém assumiu que "clientes no Brasil" significa residência obrigatória em sa-east-1. A lista é a mesma para qualquer workload, e é isso que a torna útil: é um checklist determinístico, não uma opinião. O modelo do seu cliente lê a lista e vai atrás das respostas com você. nextTools já aponta o caminho: architecture_pattern, aws_knowledge_search e decision_record.

Todo resultado chega com kind: "heuristic-design-aid", validated: false e um limitation dizendo que não é revisão oficial da AWS, auditoria de segurança, deploy nem cotação. Leia isso como contrato, não como rodapé.

Quando um time me chama, a primeira coisa que faço não é opinar: é perguntar como quatro pessoas diferentes perguntariam. architect_panel faz isso de forma reproduzível. Você passa subject, artifactType (requirements, design, code, iac, api-contract, data-model, pipeline ou incident), roles (qualquer combinação dos 10 personas; o padrão é solution, security e finops) e knownFacts, a lista do que você já sabe.

No marketplace eu convoquei solution, security, data e finops sobre um artifactType: "design", com dois fatos conhecidos: "Budget: USD 1,500/month" e "SLO: 99.9% monthly". Cada persona volta com mandate, askFirst, checks, toolsToCall, deliverables e antiPatterns. A lista askFirst é filtrada pelos knownFacts: o Arquiteto de Soluções tem seis perguntas no catálogo, mas no resultado aparecem cinco, porque "Budget per month and pricing region?" casa com o fato "Budget: ..." e sai. O filtro é simples: compara a primeira palavra da pergunta, em minúsculas, com o texto dos fatos. Por isso "SLO: 99.9% monthly" não remove "SLO, p95 latency, RTO and RPO?" (a primeira palavra é "SLO," com vírgula). Saber como o filtro funciona evita esperar inteligência onde existe uma regra.

toolsToCall vem ordenado pelo artifactType: para design, as ferramentas de foco são c4_model, service_compare, threat_model, well_architected_review e cost_model; as que a persona domina sobem primeiro, até seis por papel. O bloco synthesis fecha com três regras que eu assino: conflito entre papéis (custo versus resiliência) se resolve num decision_record; todo achado tem dono, evidência e critério de validação; o que é desconhecido continua desconhecido.

A descrição da ferramenta diz "Lens, not a verdict". O painel não decide nada. Ele faz o modelo do seu cliente adotar quatro pontos de vista e dá a cada um a lista certa de ferramentas. Cada papel também existe como prompt (architect_solution, architect_security...) e como recurso moretes://personas/<id>.

architecture_pattern responde a uma pergunta diferente: "se o padrão é este, que peças entram e que perguntas eu ainda devo?". São cinco padrões fechados: serverless-api, container-api, event-driven, rag e agent-platform. Cada um devolve services, fit, tradeoffs, nodes, questions e um mermaid pronto para colar na documentação. Para os eventos do pedido alimentando cobrança, estoque e notificações, o padrão é event-driven: EventBridge, SQS, Lambda, DynamoDB e CloudWatch. O encaixe é "eventos de negócio assíncronos com consumidores desacoplados"; os trade-offs são consistência eventual e ordenação, duplicidade e evolução de schema; e as duas perguntas que ela devolve são as que eu faria: qual é o escopo de deduplicação, e quem é dono da recuperação da DLQ e da autorização de replay.

O parâmetro provider (aws, azure, gcp, oci ou oss; padrão aws) é o que torna a ferramenta honesta para quem não vive só na AWS. Ele não troca o padrão: acrescenta serviceMapping, uma lista de pares que lê cada serviço AWS pela categoria de capacidade em equivalents.json (EventBridge é event-bus, SQS é queue, Lambda é serverless-functions, DynamoDB é nosql-kv, CloudWatch é observability). Quando um serviço não tem categoria mapeada, o valor é a string no mapping in snapshot, não um palpite. O mermaid continua com os nós do padrão (Producer, EventBridge, SQS, Consumer), porque o diagrama é do padrão, não do fornecedor. Equivalência aqui é funcional: cota, modelo de consistência e dimensão de preço mudam de nuvem para nuvem, e a ferramenta diz isso em vez de esconder.

service_compare recebe uma family (compute, database, messaging ou rag-store) e as suas constraints, e devolve options com service, fit e tradeoff para cada alternativa. Para mensageria com "ordering per customer", "two consumer teams" e "replay within 7 days", voltam quatro opções: SQS (entrega bufferizada; o consumidor é dono da idempotência e da DLQ), SNS (fanout por push; política de entrega do assinante), EventBridge (roteamento e integração; governança de schema) e Step Functions (estado explícito de workflow; transições e limites de execução). Não há coluna de nota, não há "recomendado", e a descrição avisa: "No automatic winner or fabricated scores". O campo decisionRequired diz o que fazer: coletar evidência do workload e preço atual antes de escolher. As constraints voltam no resultado, mas quem as cruza com as opções é o modelo, e quem assina é você.

service_equivalents é a tabela multi-cloud por trás do provider. São 43 categorias de capacidade (queue, event-bus, serverless-functions, relational-db, vector-search, agent-runtime, kms, iac...), com from e to entre aws, azure, gcp, oci e oss; aceita também query para achar a categoria por texto. Pedindo queue, event-bus, serverless-functions e relational-db de aws para azure, gcp e oss, o Amazon SQS vira Azure Service Bus queues / Queue Storage, Pub/Sub (pull) / Cloud Tasks e RabbitMQ / NATS JetStream; o Amazon EventBridge vira Azure Event Grid, Eventarc e NATS / Knative Eventing. O resultado carrega kind: "reference-snapshot", snapshotDate: "2026-10-24" e uma limitation explícita: equivalência é funcional, não idêntica; cotas, consistência, preço e disponibilidade regional diferem. É o tipo de honestidade que eu quero de uma ferramenta: ela diz de quando é a foto e manda confirmar na documentação de cada fornecedor.

decision_record é a única ferramenta desta aula que produz um documento. Os campos são os do ADR clássico: title, context, options (de 2 a 10), decision, consequences e status (proposed, accepted ou superseded; o padrão é proposed). O resultado é markdown com as seções Context, Options, Decision, Consequences e uma seção Validation que a ferramenta acrescenta sempre: "Record owner, test evidence, pricing date and review date before adoption". A descrição diz "Does not invent acceptance": você pode passar status: "accepted", mas ninguém vai aprovar por você.

No marketplace, o ADR do exemplo é "Use SQS FIFO per tenant for order events". Contexto: eventos em ordem por cliente, pico de 300 pedidos/min, consumidores de cobrança e estoque em dois times. Três opções: SQS FIFO com message group por cliente, Kinesis Data Streams com partition key, chamadas síncronas diretas entre serviços. Decisão: FIFO com um grupo por cliente, ordenação onde importa, superfície operacional limitada, DLQ por consumidor. Consequências: monitorar o limite de throughput por message group, consumidores idempotentes por id de evento, replay só com runbook autorizado.

A skill adr-writing (recurso moretes://skills/adr-writing) é o que separa um ADR lido de um ADR arquivado, e as regras cabem em seis linhas:

• Uma decisão por registro. Se precisou de "e", divida.
• Pelo menos duas alternativas reais, cada uma com a condição em que ela ganharia. Opção listada só para ser rejeitada é cheiro ruim.
• Consequências incluem os custos: operacional, financeiro e organizacional. Consequência sem negativo é outro cheiro.
• Status começa em proposed. accepted exige aprovador nomeado e data.
• Registre a data do preço e a versão da documentação citada.
• Marque data de revisão: decisão de arquitetura vence.

O terceiro cheiro da skill é decisão justificada por afirmação de fornecedor sem fonte. É por isso que aws_knowledge_search entra antes do decision_record no prompt, e não depois.