Piattaforma
Una console full-stack per una delivery software AI seria
Log, database, rete ed errori — visibili accanto alla chat, così esegui il debug dell'app con prove e metti i risultati direttamente nel tuo prossimo prompt.
La console full-stack è la superficie diagnostica dentro il Builder di Ciao: log, stato del database, richieste di rete ed errori, visibili accanto alla conversazione. A differenza degli app builder AI che ti lasciano a indovinare quando qualcosa si rompe, la console mostra cosa è realmente successo attraverso lo stack — così il prossimo prompt porta prove, non speculazioni, e le correzioni atterrano sulla causa reale.
Pubblicato 2026-07-03 · Ultimo aggiornamento 2026-07-03
Fare il debug di un'app che non hai scritto tu stesso
Quando un'app che hai costruito con l'AI si comporta male, la posizione peggiore in cui trovarti è indovinare. Il bug è nell'interfaccia, nella query, nella chiamata API, o nei dati stessi? Senza visibilità, una correzione di una riga diventa un pomeriggio di prompting speculativo — provare riformulazioni contro una scatola nera e sperare che una funzioni.
La console full-stack ti dà la visibilità che gli ingegneri si aspettano, dentro il Builder: log server e browser, tabelle e righe del database, richieste e risposte di rete, ed errori con il loro contesto — tutto accanto alla conversazione. Vedi cosa è realmente successo, poi metti la prova nel prossimo prompt.
Questa non è una superficie di nicchia per power user. L'intera promessa di costruire software da linguaggio semplice crolla la prima volta che qualcosa si rompe e la piattaforma non può mostrarti perché. La visibilità è ciò che mantiene onesta la promessa.
Come funziona la console
Tutto avviene accanto alla conversazione — il punto è mantenere prove e azione nello stesso posto.
1. Aprila accanto alla chat
Nessuno strumento separato, nessun cambio di contesto. La console si trova accanto alla conversazione e all'anteprima live.
2. Leggi i log
Output server e browser dall'app in esecuzione, così "non ha funzionato" diventa una riga specifica in un momento specifico.
3. Ispeziona il database
Guarda le tabelle e le righe Supabase reali dietro l'app. Conferma se il record è stato scritto, e con quali valori.
4. Guarda la rete
Richieste, risposte, codici di stato e tempistiche — particolarmente prezioso quando entrano in gioco integrazioni e API esterne.
5. Vedi gli errori nel contesto
I fallimenti appaiono con l'attività circostante che li ha prodotti, non come messaggi nudi privati della loro storia.
6. Trasforma la prova nella correzione
Riferisciti a ciò che hai trovato nel prossimo prompt. Per problemi live in produzione, Doctor — l'AI SRE in sola lettura — sonda l'app, il DNS e la CDN, diagnostica la causa radice e abbozza la correzione.
Perché è importante
Fare prompt con prove batte fare prompt con sensazioni. "Il POST a /api/orders restituisce 400 e la riga non appare mai nella tabella ordini" produce una correzione giusta in un round; "la cosa dell'ordine è rotta" produce la riscrittura di qualcosa che non era mai il problema. La console è ciò che rende possibile il primo tipo di prompt per tutti, non solo per gli ingegneri.
Questa è gran parte di ciò che separa l'ingegneria assistita da AI dalla chat speranzosa: il sistema mostra il suo stato, l'umano ragiona su di esso, e la correzione è ancorata a ciò che lo stack ha effettivamente fatto. Nel tempo questo produce una codebase più silenziosa — meno riscritture speculative, diff più piccoli, e un team che si fida dell'app perché può sempre vederci dentro.
Cambia anche chi può supportare un'applicazione. Un'agenzia o un team operativo può rispondere a "cosa è successo a quell'ordine?" con dati invece che con un'escalation, perché la domanda è ispezionabile nello stesso posto dove vive l'app.
Chi usa la console full-stack
La console serve chiunque abbia mai dovuto rispondere alla domanda "cosa è realmente successo?"
- Founder tecnici — Diagnosticano le proprie app in minuti invece di fare escalation per ogni intoppo o rifare prompt alla cieca.
- Agenzie — Supportano le app dei clienti professionalmente — riproducono il problema, leggono le prove, rilasciano la correzione revisionata.
- Sviluppatori — Verificano il comportamento del backend scritto dall'AI — query, scritture, chiamate API — prima di affidargli dati di produzione.
- Team operativi — Confermano che i flussi di dati tra l'app e i sistemi esistenti fanno ciò che l'integrazione prometteva.
Note di sicurezza e governance
La visibilità è potente, quindi arriva con controlli:
- ✓ L'accesso al workspace, inclusa la console, segue il controllo degli accessi basato sui ruoli.
- ✓ Le correzioni guidate dalle prove della console passano comunque attraverso la revisione Guardrails e i gate QA prima della pubblicazione.
- ✓ Security conferma le vulnerabilità sull'app live prima di segnalarle — risultati, non rumore.
- ✓ Doctor opera in sola lettura: sonda, diagnostica e abbozza correzioni, ma le modifiche vengono rilasciate attraverso il ciclo governato.
- ✓ Prompt, merge e deploy intorno a ogni correzione atterrano nel registro di controllo append-only.
Cosa mostra la console
Quattro superfici coprono la maggior parte delle indagini dall'inizio alla fine:
| Superficie | Cosa vedi | Cosa risponde |
|---|---|---|
| Log | Output server e browser dall'app in esecuzione | Cosa è stato eseguito, e cosa ha riportato |
| Database | Tabelle, righe e valori Supabase | I dati sono realmente cambiati, e come |
| Rete | Richieste, risposte, codici di stato, tempistiche | Cosa si sono detti l'app e i sistemi esterni |
| Errori | Fallimenti con contesto circostante | Dove si è rotto, e cosa lo ha preceduto |
Domande frequenti
Ho bisogno di strumenti esterni per fare il debug di un'app costruita su Ciao?
Per il lavoro quotidiano, no — log, database, rete ed errori sono ispezionabili dall'interno del Builder. Poiché l'app è React, TypeScript e Supabase standard di tua proprietà, i tuoi ingegneri possono anche collegare qualsiasi strumento esterno preferiscano.
Posso guardare il database reale?
Sì. La console mostra le tabelle e le righe Supabase dietro la tua app, così puoi confermare cosa ha realmente scritto un flusso. È spesso il modo più veloce per distinguere un bug dell'interfaccia da un bug dei dati.
Come si relaziona la console a Doctor?
La console è te che guardi lo stack; Doctor è un AI SRE in sola lettura che guarda per te — sondando l'app live, il DNS e la CDN, diagnosticando la causa radice e abbozzando la correzione. Funzionano meglio insieme: Doctor per gli incidenti di produzione, la console per l'indagine durante la build.
Chi nel team può vedere la console?
L'accesso segue il controllo degli accessi basato sui ruoli sul workspace, quindi decidi tu chi può ispezionare log e dati. I piani enterprise aggiungono SSO tramite SAML e OIDC e MFA opzionale sopra.
Usare la console aggira la governance quando rilascio una correzione?
No. La console informa la correzione; la correzione si unisce comunque sotto Guardrails con revisione umana registrata, supera gli smoke gate QA prima della pubblicazione, ed è registrata nel registro di controllo append-only.