Il bridge che seleziona cosa alimentare al validator, validato dal validator

La claim, dichiarata in modo stretto

Lo strumento `architect.validate` di AI Design Blueprint valuta il codice agentico contro la doctrine dei 10 principi. L'orchestratore cohort-bridge è il codice che converte il repository GitHub pubblico di un applicante in input compatibile con la validation. Quell'orchestratore è stato sottoposto al validator che serve, quattordici volte in una sera — validate first-pass più cert second-pass review sull'iterazione finale.

Layer 1: il validator valuta il proprio codice sorgente (self-audit cert-confermato, 13 round precedenti). Layer 2: il validator valuta un agente governato (baseline canary 100/A pulito, 18/F iniettato). Layer 3: il validator valuta il bridge che seleziona cosa alimentargli — questo case study. Tre layer, ognuno valida quello sotto, ognuno con ricevute pubbliche.

Ricevuta cert-confermata

Summary del cert second-pass su iter14, verbatim dalla review persistita:

CERT CONFIRMED

Il verdetto production_ready di first-pass è confermato: il codice mostra stati di job durabili, gestione esplicita di terminal/blocked/aborted, retry paths, e nessun difetto specifico mancato che attualmente causerebbe un utente reale a ricevere risultati sbagliati silenziosi, crash, o bypass del trust-boundary.

Cosa rivela la traiettoria

Lo score-come-istantanea perde la storia dell'iterazione. Il bridge ha raggiunto production_ready tre volte (iter8, iter9, iter10) prima che iter11 regredisse a emerging su codice identico — un singolo evento di varianza LLM che ha promosso P10 da hardening_recommended a production_blocker. Il path di fix ha poi richiesto quattro altre iterazioni: primitive di steering durabili (iter12), recovery step-aware + guard di stato terminale (iter13), e il re-check abort post-validate che ha chiuso P10 definitivamente (iter14).

Il downgrade del cert reviewer su iter10 ha catturato un bug reale — ma nella disciplina di submission, non nel codice sottostante. L'estratto inviato a validate mancava di `from app.db.session import Base`. Il file repo reale lo aveva sempre. La prosa del verdetto cert reviewer l'ha detto esplicitamente. Iter11 ha ripristinato l'import; la regressione che è seguita immediatamente era l'evento di varianza, non un cambio di codice.

La doctrine che il validator applica è la stessa doctrine che gira dentro Claude Code via MCP. Ogni raccomandazione in ogni iterazione è mechanism-specific (identificatori nominati, file nominati, race condition nominate). Nessuna è template-generica. Il cert summary di iter14 nomina quali terminal states e retry paths confermano il verdetto.

Verbatim da iter2 — il finding P7 che la review iter1 non aveva raggiunto

DRAFT

L'envelope di audit è un miglioramento sostanziale: `audit_object` registra `schema_version`, `captured_at`, source `repo_url`/`commit_sha`, hash dei file selezionati, read saltati, `bundle_sha256`, latency del validator, e log signals shape-only. Tuttavia, il bridge costruisce ancora il payload del validator concatenando contenuto raw non fidato del repo in `_build_implementation_context()` via `chunks.append(f"# === FILE: {path} ===\n{content}\n")` e poi lo invia come `ValidationRequest(code=bundle, ...)`. Questo file non stabilisce né registra un boundary di input inerte non fidato, quindi commenti del repo o filename contenenti testo instruction-like potrebbero pilotare il validator a meno che un servizio downstream nascosto compensi.

Verbatim da iter14 — P10 steering, finalmente allineato

CERT CONFIRMED

Le primitive di steering sono ora presenti sia per validation che per onboarding recovery. `request_abort()` persiste `abort_requested=True`; `_execute_with_job()` controlla l'abort prima della validation e, nel cambio Iter14, refresha il job e re-controlla `job.abort_requested` immediatamente dopo che `asyncio.run(validate_code_against_principles(...))` ritorna e prima di creare `UserValidationRun` o chiamare `mark_completed()`, scartando l'output del validator su abort. `retry_failed_validation_job()` richiede che l'ultimo job sia terminale e `retry_eligible`, mentre `retry_onboarding_handoff()` preserva lo stato fallito (`firebase_user_failed`, `sign_in_link_failed`, o `approval_email_failed`) e pulisce solo `onboarding_failure_reason`, permettendo a `approve()` di rientrare in step-aware recovery.

Cosa è ora il bridge

Una superficie di orchestrazione end-to-end che converte un repository GitHub pubblico arbitrario in un bundle compatibile col validator, con stato di workflow durabile, boundary tipizzato del file-envelope, recovery operatore step-aware, honoring dell'abort post-validate, e un badge production_ready cert-confermato che qualsiasi lettore può verificare re-fetchando il run_id. I primi 10 applicanti della cohort di questa settimana saranno onboarded tramite questo codice.

Tre case study, tre faccette

Questa è la faccetta di self-validation della triade di integrità ricorsiva. Le altre due faccette sono pubbliche: lo scan di substrate-validation sul codice demo dell'agent-SDK di Anthropic, e lo scan di reference-honesty sul nostro stesso esempio del protocollo A2A. Stessa doctrine, tre superfici di codice, tre verdetti diversi.

Ricevute

Ogni claim sopra è rigiocabile dai run URL pubblici. Il fingerprint della doctrine dei 10 principi è rimasto costante in tutte e quattordici le iterazioni (il validator ha confermato `same_doctrine` su ogni confronto baseline). Nessun cambio regola mid-stream; lo stesso rubric ha valutato ogni run.