Le suite generate richiedono prove di target, non solo scaffold
Un generatore di suite applicative puo sembrare maturo quando produce molte repository e un verificatore verde, ma la domanda piu fragile e spesso piu concreta e un'altra: quali target runtime esistono davvero, quali sono esclusi per progetto, e quale evidenza lo dimostra? Questa sintesi workspace-grounded studia AB Framework, un generatore di sei repository per server, mobile, web, admin, contratti e deploy. La ricerca combina ispezione di manifest, template, blueprint, verifier, guide archiviate AlexandrAI e documentazione ufficiale su Expo, Docker Compose, Next.js, Node, JSON Schema, NIST SSDF, Twelve-Factor, OWASP API4 e SLSA. Il risultato principale e una Target-Surface Evidence Chain: comando nativo positivo, assenza verificata di target web/Docker mobile, separazione Compose per server/web/admin/PostgreSQL, configurazione client visibile, contratti HTTP e gate eseguibile. Nel checkout ispezionato il verifier passa; la superficie mobile contiene due comandi nativi, sei controlli negativi contro web/Docker mobile, quattro servizi Compose non-mobile e tre moduli di build immagine non-mobile. La conclusione e proporzionata: il framework prova integrita scaffold-level dei target, non prontezza di rilascio mobile o correttezza produttiva.
Introduzione
Le suite applicative generate sono facili da valutare male. Una cartella con sei repository, Dockerfile, manifest, script e test puo sembrare sufficiente; tuttavia il rischio spesso nasce nei target runtime impliciti. Un client mobile puo essere dichiarato nativo mentre un template aggiunge un target web. Un deploy Compose puo essere letto come descrizione dell'intera applicazione anche se contiene solo servizi container. Un contratto HTTP puo essere trattato come codice condiviso se il confine non e esplicito.
AB Framework offre un caso compatto. Il README descrive un generatore per server, mobile, web, admin, contracts e deploy; il manifest registra invarianti su comunicazione HTTP, Docker, PostgreSQL, port policy, review e separazione repository [[cite:readme,frameworkManifest]]. Il grafo AlexandrAI ha gia coperto due aspetti generali: scaffold verification e write-set accountability [[cite:alexScaffold,alexWriteSet]]. Questa ricerca non ripete quei contributi. Si concentra su una sola domanda: come si prova che il target mobile resta Android/iOS e non viene assorbito da web, Docker o Compose?
La domanda e piu sottile di quanto sembri. Expo documenta comandi nativi Android e iOS, ma Expo come ecosistema puo anche includere il web; Docker Compose documenta applicazioni multi-container, ma un'app mobile nativa non e un servizio container; Next.js rende pratici BFF e route handler per web/admin, ma questi non sostituiscono il client mobile nativo [[cite:expoCli,dockerCompose,nextBff,nextRouteHandlers]].
Il contributo e una Target-Surface Evidence Chain. Una suite generata dovrebbe pubblicare non solo quali cartelle produce, ma anche quali target possiede, quali target esclude, dove lo esclude nel template, quale contratto lo collega, e quale verifica fallirebbe se il confine fosse rotto.
Metodo
Lo studio e una sintesi concettuale radicata nel workspace. Sono stati letti README, framework manifest, harness documentation, repo blueprint, verifier, template mobile, template deploy, contratto HTTP e guide AlexandrAI correlate. Sono stati inoltre consultati documenti ufficiali o standard per Expo, Docker Compose, Next.js, Node test runner, JSON Schema, NIST SSDF, Twelve-Factor config, OWASP API4 e SLSA provenance.
La ricerca nel grafo ha usato query su scaffold, write set, target mobile, Expo web target, Compose mobile e surface drift. Il risultato ha confermato un rischio di duplicazione: esiste gia un paper AB Framework su scaffold verification e uno su write-set accountability [[cite:alexScaffold,alexWriteSet]]. Per questo il paper restringe l'unita di analisi al target surface del mobile nativo e alla relazione tra mobile, deploy, web/admin e contratti.
Il passo empirico locale e piccolo ma riproducibile. Un conteggio sui template e sul verifier ha trovato due comandi mobile nativi positivi, sei controlli negativi contro mobile web o Docker, quattro servizi Compose non-mobile, tre moduli di build immagine non-mobile, e tre controlli del verifier contro wiring mobile in deploy [[cite:localCounts]]. Il framework verifier e stato eseguito e ha restituito un esito positivo [[cite:localVerifierRun]].
La formula di analisi e volutamente qualitativa: target evidence = target positivi + assenze verificate + wiring di deploy + contratto di configurazione + gate eseguibile . Una parte mancante non invalida ogni valore del generatore, ma abbassa il claim che si puo pubblicare.
Oggetto Di Studio
Il framework separa le responsabilita in sei repository generate. Il server e il runtime API, il mobile e l'app Expo React Native, il web e la superficie pubblica Next.js, l'admin e la console operator con BFF, contracts contiene file HTTP condivisi, e deploy contiene Compose, env e script operativi [[cite:readme,frameworkManifest]].
Il confine mobile e definito in quattro punti locali. Il package template ha comandi iOS e Android e non contiene dipendenze web; app.json non dichiara un target web; il manifest mobile dichiara Android e iOS come soli target runtime; il template AGENTS dice agli agenti di non aggiungere Expo web, Docker o static export [[cite:mobilePkg,mobileAppJson,mobileManifest,mobileAgents]].
Il confine deploy conferma la stessa scelta dal lato opposto. Il deploy manifest dipende da server, web e admin, non mobile; il README afferma che i build mobile Android/iOS sono di competenza della toolchain nativa Expo; i file Compose contengono postgres, server, web e admin; build-images itera solo server, web e admin [[cite:deployManifest,deployReadme,deployCompose,buildImages]].
Risultati
Risultato 1: il target mobile e provato da evidenza positiva e negativa. Due comandi nativi positivi, iOS e Android, non bastano da soli. La prova diventa piu forte perche il verifier controlla anche assenze: nessuno script web/Docker mobile, nessuna dipendenza react-native-web, nessun Dockerfile mobile, nessun target web in app.json e nessun servizio mobile nei Compose [[cite:verifyScript,mobilePkg,mobileAppJson,localCounts]].
Risultato 2: deploy non e sinonimo di applicazione intera. Docker Compose e un modello per servizi containerizzati; nel framework il deploy contiene postgres, server, web e admin. Il mobile resta fuori dal grafo Compose e fuori dal ciclo build-images [[cite:dockerCompose,deployCompose,buildImages]]. Questa assenza non dice che il mobile non debba essere rilasciato; dice che il suo rilascio non passa da quel target container.
Risultato 3: la configurazione mobile e client-visibile. Il contratto HTTP nomina EXPO_PUBLIC_API_BASE_URL come variabile mobile; Expo documenta che le variabili EXPO_PUBLIC sono incluse nel client e non devono contenere segreti [[cite:contractsHttp,expoEnv]]. Quindi il target surface non e solo build target: include anche quale configurazione puo attraversare il confine client.
Risultato 4: il confine web/admin resta separato dal mobile. Next.js descrive Route Handlers e backend-for-frontend come superfici HTTP lato server per applicazioni web [[cite:nextBff,nextRouteHandlers]]. Nel framework questi pattern appartengono a web/admin, mentre il mobile comunica con il server via HTTP e non importa runtime da web o admin [[cite:mobileAgents,contractsHttp]].
Risultato 5: il gate e proporzionato. Node test runner e NIST SSDF supportano l'idea di gate eseguibili e pratiche verificabili, ma il documento harness locale limita esplicitamente il fast gate: non installa ogni dipendenza e non esegue ogni verify completo di ogni repo generata [[cite:nodeTest,nistSsdf,harnessDoc]]. Il claim corretto e scaffold target integrity, non produzione pronta.
Target-Surface Chain
La Target-Surface Evidence Chain ha sette stadi. Ogni stadio abbassa l'ambiguita di una suite generata: cosa esiste, cosa e vietato, dove gira, come si configura, quale contratto lo connette, quale test lo controlla e quale limite resta.
Il modello si collega a JSON Schema, SLSA e NIST SSDF senza fingere conformita formale. JSON Schema rappresenta il valore di manifest machine-checkable; SLSA provenance mostra il valore di soggetti, materiali e passi registrati per artifact build; SSDF mostra il valore di pratiche di sviluppo esplicite [[cite:jsonSchema,slsaProvenance,nistSsdf]]. Il paper trasferisce questa disciplina a un livello piu basso e locale: il target surface di una suite generata.
La conseguenza pratica e una regola di linguaggio: non dire 'il framework genera una app mobile completa' quando l'evidenza dice 'il framework genera una repo Expo con target Android/iOS, configurazione client esplicita e controlli contro target web/Docker mobile'. La seconda frase e meno vendibile, ma e auditabile.
Discussione
Il punto forte del framework e che la scelta native-only non vive solo in una riga di documentazione. E ripetuta nel blueprint, nel manifest mobile, nel template AGENTS, nel deploy README, nel deploy manifest, nei Compose file, nello script build-images e nel verifier [[cite:repoBlueprint,mobileManifest,mobileAgents,deployReadme,deployManifest,verifyScript]]. Questa ridondanza e utile perche i target driftano quando una sola fonte viene aggiornata e le altre no.
Il punto debole e ugualmente chiaro. Un fast verifier che genera un probe e controlla struttura, JSON, script, assenze e test specifici e un gate eccellente per scaffold integrity. Non e una prova di build nativa su device, firma release, privacy manifest, store policy, performance mobile o accessibilita reale. Il documento harness lo dice: i verify completi delle repo generate restano gate separati [[cite:harnessDoc,localVerifierRun]].
La distinzione protegge anche il deploy. Compose ha un ruolo preciso: definire servizi container e farli girare insieme [[cite:dockerCompose]]. Se un lettore vede Compose e conclude che l'intera applicazione e coperta, il mobile sparisce come responsabilita. La catena target-surface impedisce questa falsa completezza: mobile e parte della suite, ma non parte del target Compose.
Questa disciplina e particolarmente importante per agenti che modificano scaffold. Una guida mobile puo dire di non aggiungere web o Docker; una guida framework puo dire di usare placeholder e verificare il framework [[cite:alexMobileGuide,alexFrameworkGuide]]. Ma una prova pubblicabile richiede un gate che fallisca quando l'agente aggiunge il target sbagliato.
Limiti
Primo, lo studio riguarda un checkout e un generatore. Non misura applicazioni generate reali dopo settimane di feature work. La catena proposta deve essere rieseguita dopo ogni cambiamento di template, manifest, script deploy o verifier.
Secondo, il paper non costruisce un'app iOS o Android, non esegue emulatori, non invia build store e non valida provisioning. Questi sono stadi successivi. La prova qui e su scaffold target-surface, non su release engineering mobile.
Terzo, le fonti esterne possono cambiare. Expo, Docker e Next.js sono ecosistemi attivi. Per questo il paper non fissa una verita universale su quei tool; usa la documentazione corrente per interpretare il checkout e richiede che il verifier locale resti la fonte di prova operativa.
Conclusione
Una suite generata non dovrebbe pubblicare solo l'elenco delle repository prodotte. Dovrebbe pubblicare una prova di target: cosa e nativo, cosa e container, cosa e BFF, cosa e contratto, cosa e configurazione client, cosa e esplicitamente assente, e quale gate si rompe se quei confini driftano.
Nel caso AB Framework, la conclusione corretta e forte ma limitata: il checkout ispezionato prova che il mobile scaffold e Android/iOS-only a livello di template e verifier, mentre deploy Compose resta confinato a server, web, admin e PostgreSQL. Il passo successivo e trasformare questa catena in un report generato accanto a ogni suite creata, cosi il target surface non resta implicito nella fiducia verso lo scaffold.