// engenharia Os seis estágios, e em que pé está cada um
O AOA não é um prompt grande. É um pipeline com seis estágios, cada um
com entrada, saída e critério de parada. Abaixo, o que roda hoje — e o
que ainda é parcial, dito com todas as letras.
| estágio | o que faz | como | estado |
|---|
| S1 Decompõe | Quebra a intenção em subtarefas com dependências declaradas | grafo dirigido + ordenação topológica (Kahn) | em produção |
| S2 Atribui | Casa cada subtarefa com o especialista do ofício | mapa tipo → especialista, com o Gerente como padrão | em produção |
| S3 Roteia | Escolhe a faixa de capacidade por nota de benchmark | limiar por tipo de tarefa, calibrado na bancada | em produção |
| S4 Revisa | Gate de qualidade com escalação automática | máx. 2 ciclos por faixa, depois sobe de faixa | em produção |
| S5 Publica | Monta o resultado e põe no ar com backup prévio | validação de sintaxe antes do deploy | em produção |
| S6 Aprende | Registra veredito por tarefa e recalibra os limiares | log de aprendizado + recalibração da bancada | parcial |
Como a complexidade é estimada
Antes de rotear, o AOA precisa de um número. Ele sai de um peso-base pelo
tipo da subtarefa, somado a acréscimos quando o pedido é mais exigente.
Nada de "o modelo decide" — é aritmética auditável. Mas a simplicidade é
aparente: calcular o score é a ponta visível de um loop que se recalibra
a cada veredito.
peso-base por tipo publicar 15
revisão 20
pesquisa 25
copy 30
imagem 40
design 45
SEO 50
vídeo 50
GEO 55
código 65
acréscimos - +10objetivo com mais de 200 caracteres
- +10mais de uma modalidade na mesma tarefa
- +15domínio técnico declarado
- +10exigência de qualidade acima de 85
O resultado é limitado a 100. Uma subtarefa de código num domínio
técnico com exigência alta chega a 90 e cai na faixa Titan; a mesma
tarefa de publicar fica em 15 e não sai da Cronos.
Por que não é tão simples. Esses acréscimos não são constantes
arbitrárias — são parâmetros calibrados pelo estágio S6 (aprendizado). Cada vez que
um nó passa pelo gate de qualidade e recebe APPROVE ou REJECT,
o sistema registra: score calculado, faixa que executou, veredito final. Quando um
acréscimo sistematicamente superestima ou subestima a complexidade real, o peso é
ajustado. O loop fecha: a complexidade estimada de hoje é filha dos vereditos de ontem.
Os limiares que decidem a faixa
Abaixo do número, a faixa dá conta. Os valores não são chutados: saem da
bancada de benchmark, medidos por tipo de tarefa, e mudam quando a
medição muda.
| tipo de tarefa | Cronos até | Cronos+ até | Análise até | acima disso |
|---|
| Copy e redação | 40 | 60 | 80 | Titan |
| Código e build | 45 | 65 | 85 | Titan |
| SEO técnico | 50 | 70 | 85 | Titan |
| GEO e citabilidade | 45 | 65 | 85 | Titan |
Repare que código exige menos para escalar que copy: uma função errada
quebra, um parágrafo mediano só decepciona. O limiar carrega esse
julgamento, e é por isso que ele é por tipo e não global.
Os limiares não são paredes fixas — são fronteiras móveis.
O estágio S6 recalibra: se uma faixa começa a tomar REJECT em nós
que antes passavam, o limiar sobe — a faixa perde território. Se toma
APPROVE consistente em nós próximos ao teto, o limiar desce — a
faixa ganha território. Nenhuma recalibração pode empurrar um nó para uma faixa
cujo custo estimado estoure o teto da classe. A trava de custo é o lastro que
impede o loop de aprendizado de convergir para "sempre usar a faixa mais cara".
