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 conferirOcto × Engenharia de software · a área de origem do Octo
Desenvolvimento de sistemas, do requisito ao deploy.
Foi aqui que o Octo nasceu. Os oito braços (descoberta, dados, segurança, arquiteto, dev, revisor, deploy e escriba) trabalham dentro do seu setor de desenvolvimento, comandados por um desenvolvedor sênior ou pelo líder técnico da sua empresa. Cada braço tem um papel estreito; quem comanda aprova o plano, faz o merge e responde pelo sistema. Nada vai para produção sem a aprovação de quem comanda.
Oito braços; a cabeça é o líder técnico da sua empresa
Etapas9uma página por etapa do desenvolvimento
Confirmados79pontos com fonte publicada
Fontes59referências no fim de cada página
01
O Octo trabalhando na engenharia de software.
Uma atividade do pedido à aprovação, numa empresa fictícia. Os braços medem, planejam e executam; quem comanda confere e aprova. Cada aba é uma frente da área e leva à página dela.
Octo · atividade #412 · Ponte Clara Sistemas (empresa fictícia)
Página da frenteSegurança →Banco de dados →Front-end →
02
Oito braços, um setor de desenvolvimento.
Cada braço é um especialista com papel estreito e ferramentas limitadas ao papel. Quem comanda é um desenvolvedor sênior ou o líder técnico da sua empresa: aprova o plano, faz o merge, aceita o risco e responde pelo sistema.
-
Braço 1
Descoberta
Mapeia o sistema: stack e versões, estrutura, ponto de entrada, fluxo da requisição, rotas, crons, integrações e deploy.
-
Braço 2
Dados
Estuda o banco: tabelas, relações, chaves estrangeiras reais, dinheiro, data e exclusão lógica, antes de qualquer consulta ou alteração.
-
Braço 3
Segurança
Revisa login, senha, sessão, perfis, rotas sem checagem, arquivos expostos e credenciais no código.
-
Braço 4
Arquiteto
Planeja antes de codar: impacto, risco, perguntas, plano com branch, migration e reversão, e estimativa com folga.
-
Braço 5
Dev
Executa o plano aprovado na branch da atividade, com commits pequenos e teste pelo caminho real.
-
Braço 6
Revisor
Confere a entrega requisito por requisito, com o menor privilégio, e devolve a evidência.
-
Braço 7
Deploy
Confere a branch, simula o merge, ordena as migrations e confere o que o servidor está entregando.
-
Braço 8
Escriba
Mantém o dossiê do sistema, o estado e as decisões do projeto.
Nada vai para produção sem a aprovação de quem comanda. O Octo prepara, executa e confere; a decisão continua com a sua equipe.
03
Uma página por etapa.
Do requisito ao deploy: qual braço atua em cada etapa, o que ele entrega, o que fica com o líder técnico e o que está confirmado em fonte publicada.
Requisitos e descoberta
Descoberta do sistema existente, requisitos item a item, critério de pronto e requisitos de segurança desde a concepção.
Abrir a página →Arquitetura e planejamento
Plano antes do código, modelagem de ameaças pelas quatro perguntas, risco, reversão e estimativa com folga.
Abrir a página →Front-end, UX e acessibilidade
WCAG 2.2 (ISO/IEC 40500:2025), alvo de 24 por 24 pixels, contraste de 4,5 para 1, a Lei Brasileira de Inclusão e o teste em desktop e celular.
Abrir a página →Back-end e APIs
OpenAPI 3.2.1, autorização no nível do objeto (OWASP API1:2023), consulta parametrizada e versão sinalizada na quebra de contrato.
Abrir a página →Banco de dados
Tabelas, relações e chaves estrangeiras reais, numeric para dinheiro, migration com reversão e o que não vai para o log.
Abrir a página →Testes e revisão de código
Revisão requisito por requisito, teste pelo caminho real com o menor privilégio, revisor só com leitura e evidência em vez de "passou".
Abrir a página →Segurança de aplicação
OWASP Top 10 2025, ASVS 5.0.0 e NIST SSDF 1.1: acesso, senha, segredos e incidente, com laudo assinado por profissional da empresa.
Abrir a página →Integração e entrega contínua
As cinco métricas do DORA, entrega contínua, merge simulado, ordem das migrations e conferência pelo conteúdo servido.
Abrir a página →Documentação
Dossiê do sistema, decisões com data, CLAUDE.md como orientação e hook como regra, commits com motivo e documentação a partir da OpenAPI.
Abrir a página →
04
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.
A base comum da área: a disciplina, como o SWEBOK a descreve, e a ferramenta sob o Octo, como a documentação do Claude Code a descreve. Cada etapa tem as suas fontes na própria página.
- ConfirmadoA disciplina
- O SWEBOK define o conteúdo da disciplina engenharia de software e busca um entendimento comum dela no mundo.Fonte: IEEE Computer Society, SWEBOK
- Confirmado18 áreas de conhecimento
- O SWEBOK v4.0, da IEEE Computer Society, tem 18 áreas de conhecimento, entre elas requisitos, arquitetura, desenho, construção, testes, operações, manutenção, gerência de configuração, qualidade e segurança. A revisão de 25/09/2025 passou a se chamar v4.0a.Fonte: IEEE Computer Society, SWEBOK
- ConfirmadoFerramenta agêntica
- O Claude Code, a ferramenta sob o Octo, é uma ferramenta agêntica: lê o código, edita arquivos, roda comandos e se integra às ferramentas de desenvolvimento.Fonte: Claude Code, visão geral
- ConfirmadoSubagentes
- Cada subagente roda em contexto próprio, com instruções, acesso a ferramentas e permissões independentes. É a base técnica dos oito braços.Fonte: Claude Code, subagentes
- ConfirmadoFerramentas limitadas
- As ferramentas de um subagente podem ser restringidas por lista de permitidas ou de negadas.Fonte: Claude Code, subagentes
- ConfirmadoHooks
- Hooks são comandos que rodam sempre em pontos fixos, sem depender da decisão do modelo.Fonte: Claude Code, hooks
- ConfirmadoModo de permissão
- No modo Manual, editar arquivo e rodar comando de shell que não seja só de leitura pedem aprovação; a leitura não. O modo é definido na instalação de cada empresa.Fonte: Claude Code, permissões
- ConfirmadoContexto e regra
- O CLAUDE.md e a memória são contexto, não configuração imposta; para bloquear uma ação, independentemente do que a ferramenta decida, usa-se um hook.Fonte: Claude Code, memória
- ConfirmadoRegras de negação
- As regras de negação valem em todos os modos de permissão.Fonte: Claude Code, boas práticas
05
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.
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 comandaQuem 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
06
Fontes.
SWEBOK da IEEE Computer Society 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
- Claude Code: visão geralO que a ferramenta faz
- Claude Code: subagentesContexto, ferramentas e permissões próprias
- Claude Code: hooksComandos em pontos fixos
- Claude Code: permissõesO que pede aprovação no modo Manual
- Claude Code: memóriaCLAUDE.md como contexto
- Claude Code: boas práticasRegras de negação em todos os modos
Qual etapa trava o seu time de desenvolvimento?
O diagnóstico começa lendo o sistema que você já tem, sem alterar nada. Você recebe o mapa do que o Octo pode assumir e decide com ele na mão.