Trustyu Forge
O kit reutilizável está em main, com runtime assinado, Template 0.8, controles, evidência, segurança e learning gate consumíveis.
Benchmark técnico v1.7 · corte quantitativo 17 jul 2026 · readiness 19 jul 2026
Mercado × Forge 2.0 × 2.1
× Forge 3.0.
Esta é a camada de engenharia por trás da narrativa executiva. Dezessete capacidades foram comparadas com fontes primárias e normativas. O estado publicado usa o menor nível sustentável do sistema, não o melhor resultado isolado de um componente.
349testes do runtime 0.8 verdes
84,61%cobertura de linha auditada
11 / 2dmudanças aceitas na janela
2 / 5EVD-01 · agent-generated coberto
2 / 9VER-01 · controles aplicáveis
Shadowclaim operacional não permitido
Primeiro piloto fresh-start da base 3.0. O código começa somente após os gates de produto G0–G2; a FORGE não é mais o bloqueador técnico.
Operational e Attested continuam reservados para eventos reais, janela longitudinal, custo completo e assurance independente.
Leitura histórica
Da fundação documental ao
sistema verificável.
A evolução não foi uma troca de nome. Cada marco aumentou a capacidade de transformar intenção em execução confiável. O estudo canônico congelou comparações quantitativas a partir da 2.0; a fase inicial é preservada como origem histórica, sem fabricar uma coluna 1.0 que nunca teve baseline formal comparável.
Origem · Forge 1.x · abr–jun 2026
Método e fundação
Templates P1–P6, ADRs, princípios de arquitetura, squad e primeiros produtos reais formaram a base do que viria a ser o framework.
Registro histórico qualitativo · não pontuado no benchmark congelado.
Forge 2.0 · 21 jun 2026
Squad AI-first
Skills, worktrees, spec-loop, review-remediate, hooks, MCP, segurança e FinOps tornaram o processo repetível.
Baseline formal usado nesta matriz.
Forge 2.1 · transição 11 jul 2026
Contexto e controles
Context budget, catálogo de controles, eval baseline, readiness/SLO e ativação da squad por risco e fase.
Estado intermediário analítico; não foi release pública separada.
Forge 3.0 · release 11 jul 2026
Engineering Harness
Policy, sandbox, verifier, evidence, observer e closed-loop learning conectam regra escrita a controle comprovável.
Framework-only DONE em 19 jul · qualificação operacional continua.
Qualificação atual: a reconciliação dos 24 itens confirmou o framework-only como DONE e a FORGE 3.0 como GO técnico para novos produtos. O runtime forge-v0.8.0 está publicado no source SHA
eae88cfe39c49e829b4ec4b624887403ff15bbb4, com Template 0.8 e rollback 0.7. Uma referência sintética reproduziu Evidence Pack 6/6 e conformance Verified offline; ela prova o mecanismo, não um produto, adotante ou operação. Por isso os qualifiers Operational e Attested continuam condicionados a cobertura, janela longitudinal, telemetria real, custos completos e adoção independente.17 capacidades
O mercado, o que existia
e o que existe agora.
A unidade de análise é a capacidade de engenharia — não arquivos, regras, PRs ou linhas de código. Os vereditos cruzam intenção, policy, execução, verificação/evidência e feedback/operação. A pesquisa v1.7 fortaleceu a base de fontes; não alterou nenhum dos 17 vereditos.
Maturidade
—ausente
Ddocumentado
Ccontrolado
Vverificado
Aatestado
Ooperando
| Eixo | Consenso de mercado 2025–2026 | Forge 2.0 | Forge 2.1 | Forge 3.0 atual | Veredito |
|---|---|---|---|---|---|
| Context engineering | Mapa curto, conhecimento versionado, progressive disclosure e freshness mecânica. | CADRs, skills e instruções fortes, porém extensas. |
VBudgets, fragmentos, history e capability register. |
VCanon-check e progressive disclosure mecânicos. |
ForteResta drift semântico entre âncoras e estado vivo. |
| ADR e estado vivo | Decisão persistente/supersedida; estado operacional atual separado. | DDecisões versionadas, status com drift residual. |
CGovernança e catálogo de estado vivo. |
C0039/0040 reconciliadas e submetidas à ratificação. |
AlinhadoFreshness semântica ainda exige revisão humana. |
| Controles executáveis | Owner, aplicabilidade, evidência, enforcement, exceção e prazo. | DRegras distribuídas entre ADRs e CI. |
CCatálogo e profiles determinísticos. |
V14 controles, facts do diff e evidência explícita. |
AcimaFalta provar cobertura em toda mudança real aplicável. |
| Spec-driven development | Spec como fonte, out-of-scope, contratos antes do código e trace até o aceite. | CLoop SPEC→PR e Contract-First. |
CFeature spec e gate padronizados. |
VTrace e verificadores independentes. |
ForteMedir defeitos e rework evitados, não uso do template. |
| Isolamento de escrita | Uma tarefa/workspace/branch; leitura paralela; single-writer por artefato. | CWorktree por feature e protocolo D5/D6. |
CAssentos e roster explícitos. |
VGuards de overlap, ownership e teardown. |
ForteRegistrar teardown em toda tarefa real. |
| Sandbox e least privilege | FS, rede, secrets e tools por tarefa; deny-by-default; credencial curta; HITL. | DGuardrails e isolamento por worktree. |
CPerfis de risco e capabilities. |
CHub #683 e CRM #1621 passaram provenance sem passar o agregado; #688 falhou. |
ParcialFaltam gate global aprovado, approvals/capabilities e cobertura longitudinal. |
| Tool/MCP governance | Ferramentas mínimas, schemas claros, scopes, allowlist e auditabilidade. | CMCP canônico e inventário por repo. |
CAtivação por contexto e fase. |
VCapability routing e contratos validados. |
AlinhadoProvar tool profile por tarefa e controlar custo de contexto. |
| Evals de IA | Modelo + harness + ambiente; trials isolados; graders calibrados; custo e latência. | DEval-harness em parte das skills. |
CBaseline de mudança de IA e gates. |
V12/12 corpus técnico com source/profile/SHA binding. |
ForteAmpliar para 20–50 falhas reais e medir custo por task. |
| Evidência e attestation | Executor não se autoatesta; source/SHA/profile binding; artifact verificável. | DEvidência heterogênea em CI e PR. |
CEvidence contracts e provenance definida. |
CSchemas/verifiers assinados em 0.8; fixture sintética 6/6 Verified; Observer EVD=2/5 e VER=2/9. |
ParcialFaltam pack real, cobertura ≥95%, gate global aprovado e janela longitudinal. |
| Supply chain | Lock/pin imutável, SBOM, provenance, trusted builder e verificação. | CLocks, scans e actions pinadas parcialmente. |
CBaseline e evidence collectors. |
VRelease 0.8 assinada, 9 assets; Template pinado com rollback 0.7. |
ForteNão declarar nível SLSA sem todos os requisitos provados. |
| Readiness, SLO e rollback | SLI/SLO, error budget, rollback testado, runbook e stop condition. | DReadiness majoritariamente manual. |
CSLO, scorecard e gates definidos. |
CObserver assinado: 11 mudanças em 2 dias; janela aberta. |
ParcialExige ≥20 mudanças, 30 dias, estabilidade e drills do piloto. |
| Closed-loop learning | Review ou incidente vira teste, eval, controle ou melhoria durável. | CReview-remediate e histórico versionado. |
CLearning records e ownership. |
VFeedback produz controls, evals e regressões testadas. |
AlinhadoMedir recorrência evitada e eficácia, não quantidade de registros. |
| FinOps e unit economics | Custo por unidade de valor/outcome, atenção humana e denial-of-wallet. | CSkip de deploy e custo por produto. |
CBudgets por branch, agente e gate. |
CM15: Actions −47,20%/dia; minutos por mudança +28,27%. |
Acima em governançaMeta perdida por 2,80 p.p.; eficiência unitária regrediu; modelos e tempo humano ausentes. |
| Papéis seniores e human control | Senior define intenção, risco e taste; autonomia proporcional e approvals claros. | DPersonas e papéis de squad. |
CAtivação por risco/fase e gates humanos. |
COwner e decisão explícitos; aprovador técnico único. |
Alinhado com ressalvaFounder/CTO é hoje o único aprovador técnico real. |
| Observabilidade agentic | Spans de modelo/tool, outcome, tokens, custo, policy e privacy. | DTelemetria fragmentada por produto. |
CSchema de receipts e métricas do harness. |
CSubset OTel GenAI privacy-safe assinado no runtime 0.8. |
AtrásFalta telemetria real de produto ligada a tokens/custo/outcome/receipt. |
| Issue provenance/closeout | Autoria, decisão, implementação, validação e residual reconstruíveis. | DCloseouts inconsistentes e registros sem prova. |
DProblema reconhecido, ainda sem gate comum. |
CADR-0051 e closeout gate no canônico. |
Acima no contratoParcial na frota; propagação ocorrerá por toque normal. |
| Adoção externa e assurance | Usuário independente, pacote/licença, suporte, upgrade/rollback e evidence pack. | —Sem produto de framework externo. |
DEstratégia de extração documentada. |
DConformance/EEP assinados em 0.8; nenhum adopter externo. |
AtrásNenhum adotante externo independente até o corte. |
Onde a Forge 3.0 é forte
- Context engineering, catálogo executável e spec-driven development integrados.
- Isolamento de tarefa, evals, supply chain e verificação source-bound.
- FinOps de CI/agentes e closeout de issue mais rigorosos no desenho.
O que impede o próximo nível
- Gate global aprovado e coverage high-risk/≥95%; hoje EVD=2/5 e VER=2/9.
- ≥20 mudanças, 30 dias, 2,80 p.p. residuais de FinOps e custo de modelos/atenção humana por outcome.
- Adoção real do perfil OTel GenAI, assurance e primeiro adotante externo.
Pesquisa source-bound
O mercado foi pesquisado,
não apenas citado.
O gate público foi executado contra snapshots revisados de fontes oficiais, primárias e normativas. Cada aquisição gerou um receipt ligado à URL, snapshot, hash de conteúdo, política, retenção e custo medido. Conteúdo externo foi tratado como dado não confiável e não foi persistido.
20 / 20fontes aprovadas e receipts
11grupos independentes
3 / 3estudos multi-source
9 / 9claims mapeados e revisados
0chamadas de modelo e tokens
0conteúdo bruto persistido
R1 · Engineering Harness confiável
Confiabilidade é propriedade do sistema
Workflow, ciclo do workspace, isolamento, mudanças pequenas, feedback e decisões duráveis precisam ser explícitos. Um prompt melhor não substitui o harness.
R2 · Entrega segura e auditável
Controles se complementam
Teste reproduzível, least privilege, sandbox, provenance e verificação independente são gates distintos. Nenhum deles, sozinho, prova o sistema.
R3 · Evals, observabilidade e FinOps
Qualidade e custo precisam de outcome
Evals exigem critérios e traces; custo exige uma unidade de valor. Gasto não-zero deve vir de interfaces oficiais, nunca de estimativa tratada como fatura.
Registro público reproduzível
O mirror sanitizado publica catálogo, research pack, 20 manifests e 20 receipts. Foram recebidos 423.265 bytes em 21 chamadas HTTP e 37.675 ms somados, sem chamada de modelo e sem reter o conteúdo recuperado.
Billing oficial: os mecanismos de OpenAI, Anthropic e Google foram documentados, mas continuam
documented-not-configured. Esta execução framework-only não chamou modelos, portanto o custo direto de modelo medido foi US$ 0. Custo futuro de produto permanece desconhecido até existir export autorizado e reconciliação por projeto/SKU.Fail-closed: páginas que retornaram 403, acionaram DLP/prompt-injection ou mudaram de hash não foram forçadas nem contadas. Foram substituídas por snapshots oficiais imutáveis. O resultado prova o mecanismo de intake e pesquisa neste corte; não prova operação, attestation, adoção de produto ou liderança mundial.
Como ler
Evidência antes de
adjetivo.
“Consenso de mercado” é a interseção de práticas públicas e padrões — não uma certificação nem uma média estatística. Estados desconhecidos, indisponíveis e zero são tratados como valores diferentes.
Hierarquia de evidência
- E1: evento real atestado, ligado à fonte, SHA, policy e verificador.
- E2: teste, CI, artifact assinado ou contrato reproduzível.
- E3: implementação presente no SHA auditado.
- E4: decisão aceita e ligada à implementação.
- E5: declaração sem prova independente.
Regra de qualificação
Nenhum estado A ou O é sustentado apenas por implementação ou documentação. Artifact válido ou provenance isolada não tornam o sistema conforme; operação exige SLO, custo, rollback, ownership e amostra sustentada.
OpenAIHarness engineering, agent legibility, invariantes e feedback loops.
OpenAI SymphonyOrquestração sobre um harness confiável e board como control plane.
AnthropicTasks, trials, graders, outcomes e eval-driven development.
Stanford HAIAI Index 2026: capacidade, adoção, avaliação e governança.
AI Agent IndexTransparência, autonomia e safety de 30 agentes; pesquisa com autores do MIT e outras instituições.
NIST AI RMFGovernar, mapear, medir e gerenciar risco ao longo do ciclo.
OWASPExcessive agency, tool abuse, least privilege e denial of wallet.
DORA 2025IA amplifica o sistema organizacional — forças e fraquezas.
SLSA 1.2Provenance, identidade do builder e verificação de artifacts.
NIST SSDFPráticas outcome-based para desenvolvimento seguro.
OpenTelemetrySemântica interoperável para modelo, tool, tokens, latência e custo.
FinOpsCusto por unidade de valor e evolução para custo por outcome.
Release 0.8: prova pública sanitizada
Tag, source SHA, data, nomes e digests dos 9 assets, chave pública e resultado da verificação de assinatura — sem tornar código ou pacotes proprietários públicos.
Fronteira pública: o relatório canônico completo vive no repositório privado de documentação da Trustyu; esta página e o evidence pack v1.7 são o espelho público sanitizado do corte aprovado. As organizações citadas são fontes de pesquisa e práticas — não há alegação de parceria, certificação ou endosso.