Sviluppo locale git-free

Modifichi i file del progetto sul tuo PC → li vedi in anteprima sul sito (solo per te) → quando è pronto, un publish governato li rende live. Niente clone git, niente branch, niente push: scarichi una base firmata del progetto e mandi solo il delta (i file che tocchi) come overlay.

• Node.js installato (nel PATH).
• Essere membro del progetto — login email→PIN su https://<progetto>.oasi.io/auth/login?surface=studio.
• Una base pubblicata per il progetto (la fa il team piattaforma: pnpm tsx scripts/publish-canonical-base.ts --project=<slug>).

AEstensione VS Code (consigliato)

1. Installa l'estensione (PowerShell):
   powershell

   $v="$env:TEMP\oasi-owner-loop.vsix"; irm https://dev.oasi.io/oasi-owner-loop.vsix -OutFile $v; code --install-extension $v

   Poi ricarica VS Code (Ctrl+Shift+P → Developer: Reload Window).
2. Attiva il transport git-free — Ctrl+Shift+P → Preferences: Open User Settings (JSON):
   json

   "oasi.ownerLoop.transport.<slug>": "overlay",
   "oasi.ownerLoop.developerId": "<tuo-id>"

   <slug> = lo slug del progetto, es. termotecnica; <tuo-id> = es. nome-cognome.
3. Avvia — Ctrl+Shift+P → OASI Owner Loop: Avvia live-preview (o il tasto ▷ nel pannello OASI Owner Loop).
   • Crea e apre una cartella di lavoro dedicata ~/.oasi/dev-light/<slug>/workspace — modifichi lì (non il vecchio clone git). ⚠️ Se hai impostato OASI_HOME, sostituisci ~/.oasi con quella radice. ⚠️ L'impostazione VS Code oasi.homeDir vale SOLO dentro l'estensione: uno script di shell non puo' leggerla. Se usi i comandi qui sotto e hai impostato solo quella, esporta anche OASI_HOME con lo stesso valore, o guarderanno due cartelle diverse.
   • Nel canale di output OASI Owner Loop compare un URL di autorizzazione: aprilo nel browser (loggato) — una volta sola (poi il token è in cache).
   • Scarica la base e si mette in watch: ad ogni salvataggio manda l'overlay → anteprima.

BClient da terminale (senza VS Code)

Certificazione + primo avvio (PowerShell):

irm https://dev.oasi.io/setup-dev-light.ps1 | iex

Watch continuo (edit → anteprima ad ogni salvataggio):

# $R segue le STESSE forme che accettano i client: ~/… , C:\… , \\server\share.
# Un valore relativo o ~utente viene ignorato, come fa il client: cosi' il comando qui
# sotto e il daemon guardano la stessa cartella, sempre.
# ⚠️ Prima si NORMALIZZA, poi si verifica: controllare il valore grezzo fa fallire il
# riconoscimento su '  C:\Oasi' (spazi iniziali) e il comando cerca il client nel posto
# storico mentre installer e client usano l'altro. Gli spazi finali si tolgono solo se il
# percorso non e' verbatim (\\?\), dove Windows li considera significativi.
$H = if ($env:OASI_HOME) { $env:OASI_HOME -replace '^\s+','' } else { '' }
if ($H -and -not $H.StartsWith('\\?\')) { $H = $H.TrimEnd() }
$R = if ($H -match '^(~[\\/]|[A-Za-z]:[\\/]|\\\\[^\\/]+[\\/][^\\/]+)') { $H -replace '^~', $HOME } else { Join-Path $HOME '.oasi' }
node "$R\dev-light\oasi-overlay-preview.mjs" --slug=<slug> --dev=<tuo-id> --repo="$R\dev-light\<slug>\workspace"

Il client scarica la base (git-free), chiede il login una-tantum, e resta in watch.

CCon il wrapper, anche su un Mac

⚠️ Non ancora attivabile (11/10/2026). Il wrapper per Mac si installa, ma il modulo di osservazione dev-light (il programma firmato che si accorge dei salvataggi) esiste oggi solo per Windows. Finché il team non pubblica quello per Mac, il comando qui sotto serve a verificare la macchina (--prova) e a prepararla; le workspace non arrivano.

Se il progetto usa il wrapper (l'agente installato sul computer osserva la cartella di lavoro e invia da solo ogni salvataggio), su un Mac con Apple Silicon basta un comando, nel Terminale e senza sudo:

curl -fsSL https://device.oasi.io/releases/dev-light-mac.sh | sh -s -- \
  --setup=<link dato dal team> --progetti=<slug>[,<slug>]

Installa e abbina il wrapper, aspetta che il server consegni le workspace in ~/.oasi/dev-light/<slug>/workspace e prepara gli strumenti per Claude (partner-kit/setup.sh). Serve Node 20 o più recente. Il link di setup è monouso e lo dà il team, che accende anche dev-light per quel Mac su ciascun progetto: lo script non può farlo da sé, e te lo dice se una workspace non è ancora arrivata. Con --prova dice cosa farebbe senza installare. Per un Mac con processore Intel non esiste ancora un pacchetto.

Più di un computer: una postazione alla volta

Puoi abbinare un secondo computer allo stesso progetto: la sua workspace nasce dall'ultima versione pubblicata. Le modifiche non pubblicate restano sul disco dove le hai fatte, e i due computer condividono la stessa anteprima (vince l'ultimo salvataggio, senza fusione). Quindi: pubblica prima di cambiare postazione e non lavorare sui due insieme.

Il setup non dichiara più successo per conto proprio. Fino al 4 settembre 2026 installava le dipendenze e stampava «fatto» qualunque cosa fosse andata storta: è così che dieci difetti simultanei — sei dei quali silenziosi — sono arrivati fino a uno sviluppatore, che ci ha perso una giornata. L'ultima parola ora è del verificatore.

node partner-kit/doctor.mjs           # referto leggibile
node partner-kit/doctor.mjs --json    # per una macchina

Lancialo quando qualcosa non torna, e sempre dopo aver aggiornato il kit. I tre esiti sono distinti apposta:

• 0 — provato: ogni server è dichiarato, parte, ed è attivo in una sessione.
• 2 — installato, ma attivazione non ancora provata. È il caso normale prima che Claude Code sia stato avviato: un server MCP nasce con la sessione, quindi finché non l'apri non esiste niente da misurare.
• 1 — almeno un guasto vero. Ogni riga ❌ porta il proprio rimedio.

«Non provato» non è «sano». Un controllo che non ha potuto misurare vale ignoto, mai verde — ed è per questo che l'uscita 2 è tenuta separata dallo 0 invece di essere arrotondata a successo.

Se hai aggiornato il kit: riavvia Claude Code

Un server MCP è un processo figlio avviato una volta sola: sostituire il file sul disco non lo raggiunge. Ogni server ora registra l'impronta del file da cui è partito e la confronta con quello su disco a ogni chiamata; se differiscono risponde STALE_PROCESS e ti dice di riavviare, invece di lavorare in silenzio con codice superato.

1. Modifica un file dello screen o un fragment nella cartella di lavoro (~/.oasi/dev-light/<slug>/workspace).
2. Al salvataggio parte l'overlay push → vedrai pushed overlay … @ <draft>.
3. Il worker ricompone base + il tuo overlay in un draft governato.

• Da VS Code: OASI Owner Loop: Apri la mia preview.
• Manuale (loggato): apri
  url

  https://<slug>.oasi.io/api/preview/<slug>/mint?channel=<slug>/<tuo-id>/live

  → imposta il cookie di preview e reindirizza al sito con la tua sandbox. Naviga alla schermata che hai modificato.

Il menu in anteprima: sbloccato, oppure «come un cliente»

In anteprima il menu mostra tutte le voci, anche quelle che richiedono una capability che il tuo account non ha: serve a provare gli strumenti nuovi della bozza prima di pubblicarli. Nel riquadro in basso a sinistra lo leggi come «menu tutto sbloccato». Accanto c'è «vedi come un cliente»: il menu usa le capability reali del tuo account, e le voci con requiredCapabilities non soddisfatte spariscono come in produzione. «Sblocca tutto» torna indietro. È solo presentazione: nessun permesso cambia.

L'anteprima è non-promotable: pubblicare è un passo distinto, con approvazione umana. Il draft viene ricostruito in modo deterministico, firmato (ricevuta KMS), riconciliato nel git canonico dalla piattaforma e deployato automaticamente. Tu non tocchi git; la piattaforma registra lo storico (ogni publish è un commit tracciato, reversibile con un publish successivo).

Il codice server (pack, handler) si vede in sandbox sui progetti accesi dalla piattaforma (termotecnica dal 28/09): dopo un salvataggio, le rotte dei pack le esegue il codice della tua bozza, in un processo confinato — solo lo schema del tuo progetto, Stripe solo con chiavi di test, niente posta né tabelle di piattaforma. Non serve pubblicare per vedere l'effetto di una modifica a un handler.

Su termotecnica è attivo, self-service. Quando un draft è pronto:

1. Apri le tue anteprime (basta essere membro del progetto):
   url

   https://<slug>.oasi.io/p/<slug>/dev-light

2. Trova il tuo draft (l'id è quello mostrato dal client dopo pushed overlay → draft <id>).
3. Richiedi adozione. Da lì in poi è il titolare a mandarla online: la piattaforma ricostruisce, firma, riconcilia e deploya. Ciò che resta nel tuo progetto (schermate, testi, stile, state machine, campi, enum, data-model.yaml, intenti) va in linea così; ciò che può raggiungere la piattaforma — codice server, migrazioni, frammenti Svelte, project.yaml, query-bridge.yaml, policy, automazioni — passa anche dalla revisione del team OASI (nel cockpit: «in revisione», non è un errore).
4. Se il titolare del progetto sei TU (ruolo admin o owner su quel progetto) non devi chiedere l'adozione a nessuno: hai un banco tuo, sul piano progetto:
   url

   https://<slug>.oasi.io/p/<slug>/studio/preview-publish

5. Non confondere i due indirizzi: /studio/preview-publish — senza il /p/<slug> iniziale — è il banco degli operatori di piattaforma OASI, e resta chiuso a chiunque altro. Il banco sul piano progetto è stato aperto il 2026-07-28, proprio perché il titolare di termotecnica era stato visto non riuscire a pubblicare il proprio progetto.
6. Un solo account può approvare. Su un progetto a sovranità applicata (termotecnica lo è) per chiedere la pubblicazione basta il ruolo admin, ma approvarla è legato all'identità del proprietario registrato, non al ruolo. Con due account sullo stesso progetto — entrambi admin, uno solo proprietario — col secondo arrivi al banco e vieni respinto all'approvazione, senza che nulla ti dica che è colpa dell'account. Se l'approvazione nega, controlla con quale email sei entrato.
7. Pubblicazione ferma per un conflitto di base? La risolve il tuo Claude, senza chiedere file al team (se il progetto ha il kit, cioè partner-kit/mcp/ nella workspace): conflitti_ultima_pubblicazione → per ogni file leggi_file_base con base: pin e base: attuale → fusione a tre col tuo file → workspace nuova sulla base attuale → bozza nuova. Non ripubblicare la bozza vecchia.
8. La chiave device di Claude Code va in .oasi-mcp-secrets.json, mai in .mcp.json: .mcp.json è un file del progetto, la bozza lo porta con sé e la pubblicazione lo scriverebbe nel repository (dal 2026-09-16 una pubblicazione con la chiave in chiaro viene rifiutata). Il .gitignore non protegge la corsia dev-light: il client non lo legge. Se la tua chiave è mai finita in una bozza, revocala e abbinane una nuova (Studio Panel → Ispezione).
9. Migrazioni SQL: chi le applica dipende dalla corsia delle migrazioni del titolare, per progetto e spenta per difetto (partner-kit/context/CORSIA-MIGRAZIONI-TITOLARE.md). Se il pannello di pubblicazione elenca le migrazioni della bozza, la corsia è accesa. Prima di salvare una migrazione, il tuo Claude chiede verifica_migrazioni: è lo stesso verdetto del pannello. Dove la corsia è accesa passa anche una colonna nuova su una tabella esistente (ALTER TABLE … ADD COLUMN, una per istruzione, DEFAULT letterale, CHECK dentro l'ADD COLUMN, niente DO), che poi non torna indietro da sola.

Le pagine Svelte dopo l'approvazione

Nei progetti accesi nella corsia delle pagine (termotecnica dall'11/10) le pagine Svelte vanno in linea da sole, circa due minuti dopo una pubblicazione approvata, senza aspettare un rilascio fatto dal team. Il pannello dev-light dice dove sono: in linea, in arrivo, non compilano (con l'errore del compilatore: è nei sorgenti, correggi e ripubblica) oppure problema della piattaforma (non dipende da te, il team è avvisato). Negli altri progetti resta «una pagina aspetta la ricompilazione», che fa il team. Fa eccezione il codice di artifacts/layout/ (.ts, .css), che aspetta sempre un rilascio.

La piattaforma osserva gia' il tuo progetto e ne registra i guasti: email ai clienti che non partono, rotte che rispondono male, utenti che restano bloccati su una schermata mentre il server risponde correttamente. Fino a poco fa quei segnali non li poteva leggere nessuno tranne chi gestisce la piattaforma. Ora li puoi leggere anche tu, sul tuo progetto.