sa-daily-toolkit

Um arquiteto de soluções troca de contexto o dia inteiro. De manhã é uma revisão de segurança de um time, à tarde é um sizing para outro, no fim do dia alguém pede uma comparação de três serviços para fechar uma RFC. Cada um desses pedidos gera um artefato — e, sem um padrão, cada artefato nasce diferente: um ADR vira uma thread de chat, um threat model vira quatro slides, uma matriz de decisão vira uma planilha que ninguém mais abre.

O custo disso não aparece no dia em que o artefato é escrito — aparece seis meses depois, quando alguém precisa entender por que aquela decisão foi tomada e não encontra nada além de um resumo de reunião. Depois de anos operando plataformas em que decisões antigas voltam como incidente, aprendi que rastreabilidade é o único produto durável do trabalho de arquitetura. O diagrama envelhece; o registro de por que ele tem aquela forma, não.

Este repositório é a minha resposta: um kit pequeno e opinativo, com um template por tipo de artefato, para que o custo cognitivo de produzir algo bom seja baixo o bastante para eu produzir toda vez, e não só quando sobra tempo.

Não há backend nem conta AWS envolvida. O toolkit é uma aplicação Next.js 16 (App Router) com React 19, TypeScript 5 e Tailwind CSS 4, que vive inteira em frontend/. Cada skill é uma página: você preenche os campos, a página monta o artefato e você leva o resultado para o repositório do projeto real — o toolkit gera, mas não guarda. Essa escolha é deliberada: o lugar de um ADR é ao lado do código que ele explica, não dentro de uma ferramenta que pode sumir.

docs/ guarda a arquitetura do próprio projeto, seus ADRs e diagramas — o kit usa em si mesmo o que recomenda. .github/workflows/ tem quatro pipelines: CI (typecheck e build), Frontend, Vercel (deploy) e Security (varredura de dependências e segredos). A produção roda na Vercel com DNS pela Cloudflare; OPERATIONS.md descreve o GitFlow, os segredos da Vercel e o pipeline de segurança, e SETUP.md mostra como ligar Vercel e Cloudflare do zero.

O custo de manutenção é o que me fez escolher esse desenho: uma app estática numa plataforma gerenciada não tem servidor para atualizar, banco para fazer backup nem chave para rotacionar. O que precisa de cuidado é só o que sempre precisa — dependências e o próprio conteúdo dos templates.

ADR: só para decisão cujo custo de desfazer é maior que o custo de escrever. Escolher uma lib de datas não merece ADR; escolher entre uma e várias AWS Organizations, sim. O template MADR força a listar as opções que perderam — é isso que um leitor futuro procura, não a vencedora.

Well-Architected: a checklist entra antes do go-live, com dono por item. Item sem dono é item marcado e não feito.

Threat modeling com LLM: o prompt produz uma lista longa de ameaças em minutos, e é aí que mora o risco — a lista parece completa e não é. Eu trato a saída como rascunho: corto o que não se aplica ao perímetro real, adiciono o que o modelo não vê (o processo de onboarding, o acesso do fornecedor, a chave estática que ninguém rotaciona) e só então o documento existe. O modelo enumera; a responsabilidade continua sendo minha.

Matriz de decisão: o passo que importa é atribuir os pesos antes de pontuar as opções. Peso definido depois da nota vira justificativa retroativa da opção que você já queria — e a matriz, que existia para expor o viés, passa a escondê-lo.

Sizing: a calculadora devolve um número de partida, não um veredito. Ela não conhece o padrão de tráfego, o pico sazonal nem a reserva que a área de finanças já comprou. Use o número para abrir a conversa com quem opera, não para encerrá-la.