Octo para arquitetura e planejamento · braço arquiteto

Primeiro o plano. Depois o código.

Arquitetura virou área de conhecimento própria no SWEBOK v4. No Octo, o braço arquiteto planeja antes de qualquer linha de código: localiza a área afetada, mede impacto e risco, levanta as perguntas, levanta as ameaças e propõe o plano com branch, arquivos, migration, reversão, testes e estimativa com folga. A decisão de arquitetura e a aprovação do plano são do líder técnico.

Pedir um diagnóstico Ver o que faz

BraçoArquitetoatua nesta etapa

Modelagem de ameaças4 perguntasOWASP

Fontes5listadas no fim da página

O que o Octo faz no planejamento.

Quatro entregas possíveis. O plano só vale depois que o líder técnico o aprova.

Plano da atividade

Branch, arquivos que mudam, migration com a reversão, testes que provam a entrega e a ordem de execução, para o líder técnico ler antes de qualquer edição.

Entrega: plano para aprovação

Ameaças pelas quatro perguntas

Em que estamos trabalhando, o que pode dar errado, o que vamos fazer a respeito e se fizemos um trabalho bom o bastante: as perguntas da OWASP, respondidas no desenho.

Entrega: lista de ameaças com a resposta proposta

Impacto e estimativa

O que mais o pedido toca no sistema, o risco de cada ponto e a estimativa com folga, medida depois contra o tempo gasto.

Entrega: impacto, risco e estimativa

Reaproveitar antes de escrever

Aponta o componente já existente e bem protegido que resolve a função, em vez de duplicá-la, para a equipe escolher.

Entrega: opções com o que cada uma implica

Oito braços, um plano.

O mesmo ciclo do Octo, aplicado a esta etapa. Cada braço tem um papel estreito; quem comanda e aprova é o líder técnico da sua empresa.

Descoberta
Localiza a área

Onde o pedido mexe no sistema e o que depende dela.
Dados
Mede o banco

Tabelas, relações e volume que a mudança alcança, antes de propor migration.
Segurança
Levanta as ameaças

O que pode dar errado no desenho, pelas quatro perguntas.
Arquitetura
Propõe o plano

Branch, arquivos, migration, reversão, testes e estimativa com folga.
Desenvolvimento
Espera a aprovação

O braço de desenvolvimento só começa depois do plano aprovado.
Revisão
Prepara a conferência

O plano já diz como o revisor vai provar cada requisito.
Publicação
Prevê a publicação

Ordem de migration e caminho de reversão entram no plano.
Documentação
Registra a decisão

A decisão de arquitetura vai para as decisões do projeto, com data.

O Octo propõe; quem decide a arquitetura, aprova o plano e aceita o risco de afrouxar um requisito de segurança é o líder técnico.

Quem faz o quê no planejamento.

O que o arquiteto entrega e o que continua sendo decisão da sua equipe.

Etapa	Braço do Octo	Fica com o líder técnico
Desenho e plano	Arquiteto	Decisão de arquitetura e aprovação do plano
Modelagem de ameaças	Arquiteto e segurança	Aceite do risco quando um requisito for afrouxado
Componente de terceiros	Arquiteto	Escolha do componente
Estimativa	Arquiteto	Prazo combinado com quem pediu

Do pedido à rotina.

Três degraus. Cada um só faz sentido depois que o anterior mostrou resultado na sua equipe.

Proposta, não promessa

1 Hoje

Plano antes do código

Cada atividade passa a ter um plano escrito que o líder técnico aprova.

Branch, arquivos e testes
Migration com reversão
Estimativa com folga

Ganho: a surpresa aparece no papel, não em produção

2 Próximo

Ameaças no desenho

A modelagem de ameaças entra em todo plano que toca acesso ou dados.

Quatro perguntas respondidas
Risco aceito por escrito

Ganho: a segurança começa no desenho

3 Depois

Estimativa calibrada

O estimado é medido contra o gasto a cada entrega.

Histórico de estimativas
Folga ajustada com o líder técnico

Ganho: a segunda estimativa é melhor que a primeira

Confirmado em fonte.

Cada ponto abaixo tem fonte publicada pela organização responsável pela norma, pela especificação ou pela ferramenta, ou em lei federal. As fontes estão na seção seguinte.

pontos com fonte publicada, cada um com a referência indicada ao lado.

ConfirmadoArquitetura no SWEBOK: O SWEBOK v4 acrescentou três áreas de conhecimento: arquitetura de software, operações de engenharia de software e segurança de software.Fonte: IEEE Computer Society, SWEBOK
ConfirmadoAs quatro perguntas: A modelagem de ameaças da OWASP se organiza em quatro perguntas: em que estamos trabalhando, o que pode dar errado, o que vamos fazer a respeito e se fizemos um trabalho bom o bastante.Fonte: OWASP, Threat Modeling Cheat Sheet
ConfirmadoCedo, no desenho: A modelagem de ameaças é feita idealmente cedo no ciclo de vida, por exemplo na fase de desenho.Fonte: OWASP, Threat Modeling Cheat Sheet
ConfirmadoModelagem de risco: A tarefa PW.1.1 do NIST SSDF pede formas de modelagem de risco, como modelagem de ameaças, de ataques ou mapeamento da superfície de ataque, para avaliar o risco de segurança do software.Fonte: NIST, SP 800-218 (SSDF 1.1), PW.1.1
ConfirmadoJustificar o afrouxamento: A prática PW.1 pede justificar os casos em que a análise de risco indicar que requisitos de segurança devem ser afrouxados ou dispensados.Fonte: NIST, SP 800-218 (SSDF 1.1), PW.1
ConfirmadoInsecure Design: O OWASP Top 10 de 2025 mantém o desenho inseguro como categoria: A06:2025, Insecure Design.Fonte: OWASP, Top 10 2025
ConfirmadoModo plano: No modo plano do Claude Code, a ferramenta lê arquivos, roda comandos para explorar e escreve um plano, mas não edita o código. A própria documentação registra exceção em sessões que permitem ignorar permissões.Fonte: Claude Code, modos de permissão
ConfirmadoReaproveitar: A prática PW.4 do SSDF pede reaproveitar software existente e bem protegido, quando possível, em vez de duplicar a funcionalidade.Fonte: NIST, SP 800-218 (SSDF 1.1), PW.4

O que o Octo faz e o que fica com vocês.

O Octo prepara tudo, mas não assina. O documento que vale continua com quem responde por ele.

O Octo prepara

Mapeia, planeja, programa na branch da atividade, revisa com evidência e prepara a publicação: planos, código, revisões, relatórios de segurança e o dossiê do sistema.

Entrega: material pronto para conferir

A sua equipe confere

Quem comanda é o líder técnico ou o desenvolvedor sênior da empresa: aprova o plano, revisa o PR e faz o merge. Nada vai para produção sem a aprovação de quem comanda.

Etapa: aprovação por quem comanda

Quem assina e responde

O Octo não assina e não responde pelo sistema. Quem aceita o risco e responde pelo sistema em produção é o líder técnico; laudo ou parecer de segurança é assinado por profissional da empresa.

Responsável: líder técnico da empresa

Fontes.

SWEBOK da IEEE Computer Society, OWASP, NIST e documentação do Claude Code. Consultadas em 31/10/2026.

IEEE Computer Society: SWEBOK v4.0aAs 18 áreas de conhecimento da engenharia de software
OWASP: Threat Modeling Cheat SheetAs quatro perguntas e o momento da modelagem
NIST: SP 800-218, SSDF 1.1 (fevereiro de 2022)PW.1, PW.1.1 e PW.4
OWASP: Top 10, edição 2025Os dez riscos de aplicação web
Claude Code: modos de permissãoModo plano e a sua exceção

Cada atividade com um plano aprovado.

O diagnóstico começa pelo próximo pedido da sua equipe, sem alterar nada. Você recebe o plano proposto e decide com ele na mão.

Pedir um diagnóstico