Trustyu Forge
Contratos, SDD, Graph/Loop, cobertura, API/eventos, receipts, supply chain e rollback estão distribuídos no runtime e no Template.
Benchmark técnico v1.9 · corte source-bound 13 ago 2026
Estado atual
da Forge 3.1.
Esta é a camada de engenharia por trás da narrativa executiva. Dezessete capacidades são avaliadas pelo menor nível sustentável do sistema, com evidência ligada a release, repositório e SHA. O corte histórico 2.0–3.0 permanece abaixo, sem ser reescrito.
0.18runtime assinado e verificável
0.16Template default em shadow
21 / 21campanha do profile estruturado
34 / 60contratos CRM executados
49 / 49superfícies Hub classificadas
NãoFleet Enforced / GA declarada
OpenAI Responses readonly em Loop comprovou broker, envelopes de tokens, negativos causais, rollback, reentrada e teardown.
Observer independente, conformidade CRM/Hub, gates de release e janela operacional ainda bloqueiam Fleet Enforced.
Contrato público do corte: manifesto machine-readable, em que cada fonte declara se o leitor consegue abri-la: as referências de repositório privado vêm marcadas como
restricted, porque o GitHub responde 404 a quem não tem acesso e isso é indistinguível de inexistente. O profile shadow-operational é uma superfície suportada e restrita; não promove automaticamente runtime, produtos ou frota para Operational, Attested ou Fleet Enforced.Contrato de leitura
Seis estados.
Nenhum atalho.
O status acompanha a proveniência. Um mecanismo demonstrado não qualifica automaticamente o Template; um default do Template não qualifica um produto; uma observação de piloto não vira propriedade universal.
Corte atual · 17 capacidades
Forge 3.1 agora.
Evidence e residual.
Esta matriz não pontua presença de arquivos. Ela usa a menor maturidade demonstrada entre contrato, execução, verificação independente e adoção. V significa verificado no escopo citado; não significa Fleet Enforced.
Maturidade
Ddocumentado
Ccontrolado
Vverificado
Aatestado · não declarado
Ooperando · não declarado
| Eixo | Forge 3.1 · 13 ago | Evidência atual | Residual para o estado terminal |
|---|---|---|---|
| Context engineering | VContexto mecanizado | Canon-check, progressive disclosure, profiles e rastreabilidade source-bound. | Reconciliar freshness entre programa, issues e estado vivo. |
| ADR e estado vivo | CContrato controlado | ADRs 0060, 0062 e 0063 aceitas; topologia shadow especificada. | ADR-0063 foi aceita em 12/08: o critério de G6 existe, mas a janela de ≥30 dias ainda não começou. |
| Controles executáveis | VRuntime verificável | runtime 0.18 valida manifests, receipts, bindings, Graph/Loop e envelopes causais. | Enforcement permanece desligado até a qualificação da frota. |
| Spec-driven development | VTrace proporcional | docs#418 incorporou SPEC → mudança → teste → evidência aos gates. | Closeout de origem concluído; produtos e profile operacional ainda precisam satisfazer os gates terminais. |
| Isolamento de escrita | VSingle-writer | Worktree, lock D5, overlap guards, ownership e teardown executáveis. | Efetividade depende da adesão contínua em cada consumidor. |
| Sandbox e least privilege | CProfile restrito | Deny-by-default, broker pré-dispatch, rede e transporte pinados; suíte adversarial de 29 testes cobre os quatro vetores do proxy CONNECT-only. | Imagem OCI não publicada; o E2E vigente roda em SHA anterior ao merge da fronteira e precisa ser repetido. Observer independente pendente. |
| Tool/MCP governance | CReadonly qualificado | Grant, allowlist, broker e tool loop foram provados para OpenAI Responses readonly. | Built-ins hospedados, MCP amplo, nested agents e Claude ficam fora do profile 3.1 suportado. |
| Evals de IA | VTrace-native | hub#765 fechou qualidade trace-native e integridade de contexto. | hub#791: execução, limites e checkpoint ainda insuficientes. |
| Evidência e attestation | CAssinada, não atestada | Assets, provenance, receipts e verificadores externos ao produtor no runtime 0.18; publicação da imagem por digest com SBOM e provenance entregue. | Observer OCI e ARR sucessor ainda faltam; Attested não é declarado. |
| Supply chain | VPin e rollback | SHA256SUMS, Ed25519, provenance e pins imutáveis no Template 0.16.1, com rollback aprovado para 0.15. | O release deixou de depender de credencial humana: passou a ser publicado pela identidade de máquina trustyu-forge-bot, com token efêmero. Resta observar durabilidade em janela longitudinal. |
| Readiness, SLO e rollback | CShadow-operational | Campanha 21/21, negativos causais, rollback, reentrada e teardown do profile suportado. | A ADR-0063 aceita fixa os critérios; janela, SLI/error budget, game-day e promoção humana continuam obrigatórios. |
| Closed-loop learning | VRegressões duráveis | Findings viraram invariantes, schemas, negativos e testes do runtime 0.18. | Medir recorrência evitada e eficácia, não volume de registros. |
| FinOps e unit economics | CTokens limitados | Envelopes causais e hard stops de token por turno; a consolidação de CI da frota destravou ~3.200 min/mês ao remover jobs faturados por arredondamento (medição M16). | Hard stop monetário ausente e confirmação pós-onda ainda não medida — economia projetada não é economia observada. |
| Papéis seniores e human control | CAutoridade explícita | Profiles, Graph/Loop, promoções e approvals não são decididos pelo modelo; separar identidade de agente e de humano destravou o primeiro positivo do gate de revisão. | Medido: o reviewer automatizado não revisou 57,3% de 699 PRs em 30 dias; cobertura real do gate = 37,3%. Check fica verde sem revisar. infra#521 · #522 · #523 |
| Observabilidade agentic | CMetadata-only | Uso, sequência, digests e receipts sem persistir prompt, output ou tenant. | ai-env#139: observação independente permanece pendente. |
| Issue provenance/closeout | CReconstruível | Feature specs, PRs, source SHAs, artifacts e residuals formam uma cadeia auditável. | O EPIC 3.1 permanece aberto até G1–G6: verdade de release e metade de review já provadas, mas o gate segue em shadow nos quatro repositórios. |
| Adoção e assurance | CFrota em shadow | Template 0.16.1, CRM 1.141.0 e Hub 0.72.1 mantêm o runtime 0.18 em shadow. | CRM 34/60 · Hub API parcial; Fleet Enforced inelegível. |
Definition of Done terminal
O ponto final
da 3.1.
Os nove fluxos técnicos do programa — excluindo Articles, conduzido separadamente — chegaram ao estado de mecanismo ou shadow. Isso não encerra a release. Para honrar o nome GA — Fleet Enforced, seis gates de qualificação continuam obrigatórios.
- G1Verdade de release fail-closedParcial · provado
Release provado ponta a ponta e publicado pela identidade de máquina; a metade de review destravou em 13/08 com o primeiro positivo do gate — Approve humano habilitado depois de separar a identidade do agente da do autor. O gate segue em shadow nos quatro repositórios e a promoção a
infra#486 · #508 · #521 · #522requiredcontinua bloqueada. - G2Boundary OCI e observer independenteEm curso
Fronteira mergeada, suíte adversarial do proxy CONNECT-only entregue (29 testes, quatro vetores) e publicação por digest com SBOM/provenance pronta. Faltam a imagem publicada, o receipt/ARR sucessor e o observer externo — e o E2E protegido vigente roda em SHA anterior ao merge, por isso precisa ser repetido.
ai-env#139 · PR #140 · #147 · #157 - G3Hard stops do profile suportadoPendente
Tokens, deadline e custo verificados fora do produtor; modos fora do profile negados.
ai-env#72 · ai-env#81 - G4CRM com contrato integral34 / 60
60/60: fixtures autorizadas e boundary de dois tenants em PostgreSQL efêmero, sem dados reais.
crm#1840 - G5Hub com API/eventos e Graph/Loop suficientesParcial
OAS lint/diff/conformance, frame schemas, denominadores e execução/limites/checkpoint observados.
hub#764 · hub#791 - G6Qualificação operacional e promoção humanaPendente
E2E protegido, campanha, rollback/game-day, janela mínima de 30 dias, SLI/error budget e decisão registrada. A ADR-0063 foi aceita em 12/08, então o critério existe; a janela ainda não começou porque depende do candidato congelado.
ADR-0063 · EPIC #366
Não bloquear a 3.1 com escopo novo: paridade completa Claude, built-ins hospedados, MCP amplo, nested agents, adotante externo independente e nível Attested são candidatos explícitos à 3.2. Na 3.1, essas superfícies devem permanecer fora do profile suportado e falhar fechadas.
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.
Decisão histórica: framework-only DONE em 19 jul; sem qualificação operacional.
Decisão histórica do corte: a reconciliação dos 24 itens registrou framework-only como DONE e FORGE 3.0 como GO técnico em 19 de julho de 2026. O runtime forge-v0.8.0 foi 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 estado atual, produto, adotante ou operação. Operational e Attested não são declarados.17 capacidades
O mercado e o que existia
até o corte 3.0.
A unidade de análise é a capacidade de engenharia — não arquivos, regras, PRs ou linhas de código. Este quadro v1.7 permanece congelado para preservar a comparação 2.0–3.0. Ele não representa o estado atual; o corte 3.1 está na matriz anterior.
Maturidade
—ausente
Ddocumentado
Ccontrolado
Vverificado
Aatestado
Ooperando
| Eixo | Consenso de mercado 2025–2026 | Forge 2.0 | Forge 2.1 | Corte Forge 3.0 · 17 jul | Veredito histórico |
|---|---|---|---|---|---|
| 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. |
CManifesto SHA256SUMS do runtime 0.8 com assinatura Ed25519; 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. |
VManifesto SHA256SUMS 0.8 com assinatura Ed25519 e 9 assets inventariados; 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 no runtime 0.8, coberto pelo manifesto SHA256SUMS assinado. |
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 inventariados pelo manifesto SHA256SUMS assinado 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 e source SHA identificam o corte; nomes e digests dos 9 assets ficam no SHA256SUMS, cuja assinatura Ed25519 pode ser verificada com a chave pública. A assinatura não cobre a Git tag.
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.