---
name: project-pseudo-os-artifact
description: "APERTO 28/08/2026 — ArkOS, idea di Mauro (riflessione notturna) per uno pseudo-OS costruito con Artifact claude.ai: una scrivania/home con tante app, la prima un pannello di controllo drill-down di tutta l'infrastruttura hardware+logica. Solo concetto, nessun disegno di dettaglio ancora."
metadata:
  node_type: memory
  type: project
---

Stessa sessione del 28/08/2026 di [[project_trigger_push_scalabile]] (riflessione notturna di Mauro sui meccanismi di trigger/push) — a un certo punto Mauro rilancia con l'idea più grande della notte: **costruire uno pseudo-OS usando gli Artifact di claude.ai**.

## Nome: ArkOS (deciso 28/08/2026)

Proposte in gara: ArkOS, ArgOS, AlbatrOS (tutte giochi su "OS" dentro una parola nautica). Scartato AlbatrOS appena scoperta la connotazione letteraria negativa (Coleridge, "The Rime of the Ancient Mariner" — l'albatro come fardello/zavorra, da cui l'idioma inglese "an albatross around one's neck"). ArgOS scartato per ultimo nonostante il doppio senso forte (la nave Argo + Argos il gigante dai cento occhi della mitologia greca, il guardiano che vede sempre — calzava bene sul tema sorveglianza/monitoraggio della sessione) perché troppo mirato al caso d'uso di questa prima app, non all'ecosistema intero. **ArkOS vince** per il richiamo doppio: l'arca di Noè (conservare/portare in salvo tutto il carico attraverso il diluvio — coerente con lo spirito "SecondBrain", preservare non disperdere) e la somiglianza con Arch Linux (nod per chi mastica sistemi, occhio alla pronuncia quasi identica a "Arch" in conversazioni tecniche future). Mauro: "è anche una nave pensandoci… qualcosa che ci porta in mari lontani e inesplorati con tutto il suo carico" — coerente con la metafora Nave/Avamposto già in uso nell'ecosistema.

## Forma scelta (tra due opzioni proposte da Adrian)

Non un unico Artifact con più pannelli/finestre dentro la stessa pagina (troppo stato da tenere sincrono in un solo posto) — Mauro ha scelto la versione più semplice: **una home/scrivania** (Artifact statico, icone/tile) che linka verso **tante (simil) app**, ognuna un Artifact indipendente con il proprio ciclo di aggiornamento dati.

## Prima app decisa: pannello di controllo infrastruttura

La prima "super app" sarà un **pannello di controllo di tutta l'infrastruttura, sia hardware che logica** — non uno specchio statico di `memory/MEMORY.md`, ma pensato fin dall'inizio per supportare **drill-down in profondità** su entrambi i lati:
- lato hardware: le macchine fisiche (Nave, VPS Avamposto, PC ufficio, in futuro Arduino/sensori Zigbee)
- lato logico: servizi (`guacd`, `mcp-query.service`, `gate-ufficio`, cron di backup/pcloud/mirror), stato dei thread/progetti aperti

**Status (28/08/2026)**: fermato deliberatamente al livello di concetto — Mauro ha detto esplicitamente "per ora basta che abbiamo presente il concetto", non ancora specificato il dettaglio di cosa mostrare al primo livello vs cosa nel drill-down. Non iniziare a disegnare schermate/dati specifici senza prima riprendere la conversazione con Mauro.

## Collegamenti tecnici già noti (da non re-inventare quando si riprende)

- Il meccanismo di aggiornamento dati **non è uniforme tra le app**: `mcp-query` (connettore MCP già in produzione) può usare la capacità `mcp` di un Artifact per dati letti live, mentre `gate-ufficio`/sensori domotica (dati locali Nave, nessun connettore) richiedono il pattern "Adrian pull via cron headless + republish periodico" già annotato in `archivio/Adrian/riferimento/artifact-claude-ai.md` e come idea parcheggiata per il cruscotto gate-ufficio (`archivio/Mauro/lavoro/lavoro-python-ecosistema/progetto-gate-ufficio.md`).
- **Deciso (28/08) di NON partire dall'app mcp-query per prima** nonostante sia tecnicamente la più "a costo zero" (dati già vivi, nessun pull da costruire) — Mauro ha scelto di ripartire da zero con calma sul pannello di controllo invece; mcp-query rientrerà eventualmente come app dedicata in un secondo tempo, non come apripista del progetto.
- Questo progetto è il contenitore naturale in cui, in futuro, far confluire anche le due idee già parcheggiate separatamente: il cruscotto Artifact per `gate-ufficio` (fermo a 2/7 job migrati) e la visualizzazione dati sensori domotica una volta installati (vedi [[progetto-domotica-iot]]) — invece di restare due dashboard isolate, diventerebbero due "app" dentro questo stesso pseudo-OS.

## Direzione a tendere: versioni ridotte degli applicativi esistenti come app personali

Mauro (28/08, stessa sessione) vorrebbe a tendere anche versioni ridotte di MyICR/MediaTrack (e altri applicativi) come app ArkOS — non un porting completo, **solo consultazione, a uso personale suo**. Discusso prima il caso MediaTrack specifico: due ostacoli reali sollevati da Adrian — (1) MediaTrack esiste per l'uso offline-first in fiera (AFM/MIPCOM, connessione scarsa/assente), un Artifact vive su claude.ai e richiede rete per caricarsi, quindi non potrebbe mai sostituire lo strumento vero sul campo; (2) `login_required` è oggi un no-op (nessuna auth reale, verificato 11/08) — esporre dati commerciali reali andrebbe affrontato prima di allargare la superficie. **Mauro ha accettato il compromesso**: per uso solo suo (non condiviso con colleghi), il rischio auth si ridimensiona; l'app ArkOS diventerebbe un compagno di consultazione rapida via browser/telefono, non un sostituto dello strumento operativo.

**Costo reale non nascosto**: ogni applicativo portato così richiede o un connettore MCP dedicato (stesso modello di `sandbox/mcp-query/`, già validato e "funziona benissimo") o il pattern pull+republish di `gate-ufficio` — lavoro di infrastruttura per ciascuno, non gratis, da fare un applicativo alla volta via via che serve una vista specifica, non tutto insieme.

**Non ancora deciso**: nessun impegno preso a costruire MediaTrack (o altro) come app ArkOS — resta una direzione di lungo periodo, condizionata anche alla domanda ancora aperta su PyQt6/MyICR (vedi `archivio/Mauro/lavoro/lavoro-python-ecosistema/PowerBricks.md`).

## Prima app reale pubblicata: Banco Circuiti (28/08/2026)

`[CONFERMATO]` — non un'app nuova costruita da zero, ma un Artifact già esistente (simulatore di breadboard interattivo per l'esperimento Arduino, vedi thread Arduino in `memory/MEMORY.md`) riconvertito su richiesta di Mauro: **"diventa una delle prime app ArkOS!"**. Smontata tutta la parte di creazione/editing (tray componenti, disegno fili, editing valori, drag&drop) — resta solo una basetta dimostrativa fissa e non modificabile (batteria/interruttore/resistore/LED) per ricordare visivamente come si legge una breadboard. Aggiunte due sezioni nuove: **Log progressi** (schemi reali completati — Blink LED e Fotoresistore, entrambi 26/08/2026) e **Prossimo da realizzare** (DHT11 temperatura/umidità, con LCD1602 in coda dopo) — aggiornate da Adrian a mano, editando e ripubblicando l'Artifact, nessuna capacità di persistenza runtime coinvolta (stesso principio "non serve engineering in più se sono io a postare gli aggiornamenti", discusso nel thread trigger/push). URL: `https://claude.ai/code/artifact/5f4c4159-d1ac-4bcb-92a2-0b1d78c3d098`.

## Scrivania pubblicata (28/08/2026) — corretta dopo un primo tentativo sbagliato

`https://claude.ai/code/artifact/97f99a5b-ccc5-497d-9abb-6867041ec914`

**Primo tentativo (scartato subito)**: identità editoriale a metafora "rotta/approdi" (rail verticale, tappe con stato, palette carta-nautica, serif Fraunces). Mauro ha corretto immediatamente: si immaginava **un desktop vero, stile Windows/Linux Mint — icone cliccabili**, non una pagina editoriale. Lezione: quando l'utente chiede esplicitamente una metafora nota ("desktop", "scrivania con icone"), va presa alla lettera, non reinterpretata creativamente.

**Terzo giro, stessa sessione — falsa partenza Mac, poi tornati a Windows**: dopo il primo tentativo scuro ("troppo scuro lo sfondo, resterei sul chiaro"), Mauro ha scritto "usiamo lo stile Mac direi per intenderci" — interpretato (sbagliando) come nuova specifica letterale: ricostruito tutto in convenzioni macOS (barra menu in alto, Dock traslucido in basso con hover, icone Dock che aprono al click singolo, icone desktop in colonna in alto a destra). Mauro ha poi chiarito: **voleva restare sulle funzionalità Windows di prima** ("più abituato") — "Mac" era solo un modo di dire veloce, non una richiesta vera; l'unica cosa da cambiare era davvero solo il colore dello sfondo. Vedi [[feedback_metafore_ui_alla_lettera]] per la sfumanza generale ("per intenderci" ≠ nuova specifica).

**Versione pubblicata finale**: struttura Windows/Linux Mint del primo giro (griglia icone in alto a sinistra, doppio click per aprire, taskbar in basso con pulsante "ArkOS"/menu Start, orologio live) con lo sfondo chiaro (gradiente verde acqua/orizzonte, tema fisso non switcha con dark mode del viewer — scelta deliberata da wallpaper). Quattro app: Banco Circuiti (unica attiva, apre l'artifact vero), Sala Macchine/Query builder/Sensori di casa (disabilitate, badge "in arrivo"). Verificato via screenshot Playwright locale prima di ogni pubblicazione (npx playwright, Chromium headless già disponibile sulla Nave — nessuna installazione richiesta) invece di fidarsi del solo codice.

Aggiornare questa pagina (stesso file path o stesso `url`) quando un'app passa da "in arrivo" ad attiva, o se ne aggiunge una nuova icona/Dock item.

## Quarta app: Portolano (28/08/2026)

App nuova, non collegata a "Sala Macchine" (quella è dati live via connettore mcp; questa è statica, disegnata a mano). Su richiesta esplicita di Mauro: "una mappa a blocchi con linee che identificano le connessioni (fisiche e logiche) e da cui cliccandoci si può approfondire" — le macchine (Nave, Avamposto, PC ufficio), i sistemi che ci girano sopra (gate-ufficio, Frank, mcp-query, domotica-iot) e le connessioni (Dropbox+git, WireGuard, Dropbox-relay). Nome: **Portolano** (antico manuale di rotta con le carte dei porti/coste — in tema con la metafora Nave/ArkOS).

Costruita con `artifact-diagramming`+`artifact-design`: tema "blueprint" fisso (non risponde al dark mode del viewer, scelta deliberata, come il wallpaper della scrivania), SVG disegnato a mano con 3 riquadri tratteggiati per macchina, sotto-riquadri pieni per i servizi, frecce etichettate per le connessioni, pannello di dettaglio laterale popolato via click JS su ogni nodo. Bug reale trovato e corretto in corso d'opera: un rettangolo invisibile usato come hitbox del titolo-macchina risultava comunque visibile per via di una regola CSS globale (`.block rect`) che sovrascriveva gli attributi inline `fill="transparent" stroke="none"` — risolto con una classe dedicata `.hit-title` più specifica. Verificato via screenshot Playwright; il test automatico dell'interazione click (secondo passaggio) non è stato completabile per un modulo Node mancante — non ancora verificato in autonomia, solo via screenshot statico.

URL: `https://claude.ai/code/artifact/3f77ebb6-3e7c-4e85-bd71-8d609855a612`. Collegata sulla scrivania come icona attiva (bussola/rombo blu) — contatore aggiornato a "4 di 6 app collegate".

**Validato da Mauro (28/08/2026)**: "per incominciare va bene, il senso è questo" — idea confermata. Direzione futura già indicata, non ancora implementata: mano a mano che le informazioni/nodi aumentano, aggiungere **navigazione con zoom** (stesso pattern già usato in Centrale Flussi) e **drill-down** per approfondire il dettaglio di ogni nodo oltre al pannello laterale attuale — non urgente, da riprendere quando il Portolano inizia a diventare affollato.

**Idea aperta — "portali" per nodo denso (28/08/2026)**: quando un singolo nodo (es. Nave, che già ospita 3 servizi e crescerà) diventa troppo denso per stare comodo dentro la mappa/pannello laterale, invece di continuare a stipare tutto nello stesso canvas si può aprire un **vero salto di pagina** cliccandolo — una sotto-pagina/Artifact dedicato con lista e dettaglio dei suoi servizi, poi tornare al Portolano per la vista d'insieme. Diverso dal semplice pannello laterale attuale: qui si esce dalla mappa invece di espandere sul posto. Da valutare nodo per nodo quando (e se) diventa davvero necessario, non da applicare a tutti e tre indiscriminatamente — si perde la vista "tutto connesso in un colpo d'occhio" entrando nel portale.

**Riflessione su Obsidian Canvas/tldraw/React Flow (28/08/2026)**: Mauro nota che il Portolano si sta muovendo verso le mappe mentali stile Obsidian Canvas. Ricerca web fatta: distinzione utile tra "drawing surface" (tldraw, React Flow — SDK pesanti da importare in un'app React) e "knowledge surface" (Obsidian Canvas — nodi come vere schede con contenuto strutturato, non solo forme), quest'ultima più vicina a quello che stiamo già facendo. **Decisione esplicita di Mauro**: nessuna libreria esterna, nessun SDK — anche perché un Artifact claude.ai non potrebbe comunque caricarne (CSP blocca bundle JS/CDN esterni). Via libera solo a **copiare pattern/architetture** (es. pan/zoom stile Centrale Flussi) reimplementati a mano in JS vanilla, non a importare strumenti. Principio guida per ogni evoluzione futura del Portolano (e di ArkOS in generale).

**Collassa/espandi per macchina — implementato subito (28/08/2026)**, su richiesta di Mauro (anticipa in piccolo la direzione "zoom/drill-down" sopra): cliccando il nome di una macchina (Nave/PC Ufficio/Avamposto) il suo riquadro si chiude a sola intestazione (chevron ▾/▸) e viceversa, stessa cosa per tutte e tre. Layout ricalcolato dinamicamente in JS: Avamposto (sotto Nave) trasla in alto/basso seguendo l'altezza corrente di Nave; le connessioni Dropbox+git/relay JSON (Nave↔Ufficio) si nascondono se una delle due è chiusa; WireGuard (Nave↔Avamposto) resta sempre visibile e si riposiziona seguendo il bordo dinamico; il `viewBox` dell'SVG si restringe in altezza quando qualcosa è collassato, invece di lasciare spazio vuoto. Verificato con un test Playwright automatico dei click (a differenza del tentativo fallito sulla prima versione — qui il modulo Node è stato trovato impostando `NODE_PATH` sulla cache npx, `/home/mauro/.npm/_npx/.../node_modules`).

**Bug reale trovato da Mauro cliccando (28/08/2026)**: l'icona "Banco Circuiti" apriva solo al doppio click via `window.open()` in JS — cliccando non succedeva nulla. Causa probabile: `window.open()` chiamato da script dentro l'iframe sandboxato di claude.ai viene bloccato silenziosamente (nessun errore, nessun popup) — il meccanismo che funziona davvero è quello già nativo nel runtime dell'Artifact, che intercetta i click su `<a href>` veri e li inoltra al frame padre per aprire una nuova scheda. Fix: sostituita l'icona-div con un vero tag `<a href target="_blank" rel="noopener">`, apertura al click singolo, niente più JS per la navigazione. **Regola per ogni app futura di ArkOS**: le icone cliccabili sulla scrivania devono essere link `<a>` reali, mai `window.open()` da un handler JS.

## Collegate due app preesistenti (28/08/2026)

Scoperto rileggendo `action: "list"` che esistevano già due Artifact costruiti in una sessione precedente (27/08), mai collegati alla scrivania: **Sala Macchine** (`https://claude.ai/code/artifact/7144b668-5e92-43eb-80aa-dd11c345afa9` — dashboard con capacità `mcp` verso il connettore mcp-query, nata per validare quella capacità, vedi `artifact-claude-ai.md`) e **Centrale Flussi** (`https://claude.ai/code/artifact/aa1afb6b-50ee-42b7-9792-c841c04ad14d` — diagramma/visualizzazione flussi dati, dominio `flussi-expert`). Rinominate con la convenzione (`ArkOS_Sala Macchine`, `ArkOS_Centrale Flussi`) e collegate come icone attive sulla scrivania, marcate **"provvisoria"** invece di "in arrivo" — su richiesta di Mauro ("collegale anche se provvisorie"), non sono ancora considerate app finite/verificate in questa sessione, solo agganciate. **Nota**: alla ripubblicazione di Sala Macchine il sistema ha segnalato che la sua chiamata al connettore mcp-query non è stata osservata/verificata in questa sessione specifica (era stata validata il 27/08, non ri-testata oggi) — da tenere a mente se qualcosa non torna aprendola.

## Convenzione di naming (28/08/2026)

Gli Artifact claude.ai non si organizzano in cartelle (`action: "list"` restituisce solo un elenco piatto, ordinato per data) — l'unico modo per riconoscerli come parte di ArkOS in mezzo ad altri Artifact è il nome stesso. Deciso con Mauro: prefisso **`ArkOS_`** nel `<title>` di ogni app (non nella scrivania stessa, che resta solo "ArkOS" essendo l'hub) — es. `ArkOS_Banco Circuiti`. Il titolo visibile dentro la pagina (l'intestazione H1) può restare il nome breve ("Banco Circuiti"); il prefisso serve solo per il tab del browser/galleria Artifact. Applicare a ogni nuova app ArkOS da qui in avanti.

## Idea aperta — widget "highlights" sulla scrivania (28/08/2026, solo da pensare)

Mauro ha buttato lì l'idea di widget sul desktop ArkOS (calendario, promemoria, notifiche di Adrian) come prima occhiata veloce — ma con un'ambivalenza esplicita: "non è che mi siano piaciuti mai molto" i widget classici. L'angolo che potrebbe farli funzionare per lui: non un pannello sempre pieno di informazioni già note, ma qualcosa che segue lo stesso principio "silenzio salvo qualcosa che conta" già maturato in [[project_trigger_push_scalabile]] — highlights veri, non un widget decorativo.

Due dipendenze reali prima di poterlo costruire: un widget calendario/promemoria richiederebbe il connettore Microsoft 365 (non autorizzato in questa sessione); un widget con le mie notifiche richiederebbe che qualcosa scriva lì sopra dall'esterno (stesso meccanismo trigger/push ancora da costruire, non solo un aggiornamento manuale mio). **Esplicitamente "da pensare"** — nessuna decisione, nessun lavoro da avviare finché Mauro non torna con un'idea più precisa di cosa vuole vedere.

## Portolano — link "Approfondisci nel SecondBrain" (28/08/2026)

Riflessione con Mauro: il Portolano potrebbe diventare fonte di verità anche per Adrian? No — resta `archivio/`+`MEMORY.md` l'unica fonte (letta sempre a inizio sessione), il Portolano è una vista derivata che aggiorno dopo, non il contrario, altrimenti rischio di avere due posti che raccontano la stessa cosa e possono disallinearsi. Integrare i file `.md` as-is dentro le schede? Scartato: sono prosa pensata per essere letta da Adrian, non schede pulite per una UI — mostrarli grezzi sarebbe una lettura peggiore dei riassunti curati già presenti, e legherebbe la freschezza del Portolano al sync del mirror Drive (ogni 4 ore) invece che al mio controllo esplicito.

**Compromesso implementato**: un link "Approfondisci nel SecondBrain" in coda alla scheda di dettaglio, solo dove esiste un documento dedicato dentro `archivio/` (quindi già nel mirror Drive) — URL reali recuperati via il connettore Google Drive (`search_files`), mai indovinati:
- Nave / PC Ufficio / Avamposto → `CLAUDE.md` (Costituzione)
- gate-ufficio (ufficio/ e nave/) → `progetto-gate-ufficio.md`
- domotica-iot → `progetto-domotica-iot.md`

**Frank e mcp-query restano senza link**: i loro `CLAUDE.md` vivono sotto `PYTHON/`/`sandbox/`, fuori dal mirror (che copre solo `archivio/`) — nessun URL disponibile. Segnalato esplicitamente nella scheda di Frank invece di ometterlo in silenzio.

## Quinta app: Schedulatore (28/08/2026)

Su richiesta di Mauro dopo aver attivato lo scheduling reale dei 2 job migrati (crontab diretto, vedi `progetto-gate-ufficio.md`): una tabella "chi gira, quando" con tutti e 7 i job ricorrenti del PC ufficio, migrati o meno — non solo i 2 già su gate-ufficio. Orari dei 5 job ancora su Frank recuperati **da dati reali**, letti in sola lettura da `PYTHON/Frank/data/frank.db` (tabella `jobs`, colonna `schedule_config`), non inventati: GemmaReport (mer 11:00), OsservatorioReport (mer 11:15), OMDB Batch Enrich (lun-ven 13:30), ImdbUpdate (gio 14:00), Outlook Frank filtro (ogni 15 min).

Design: dashboard scura (non blueprint come il Portolano, palette propria — ambra/verde smeraldo su base blu notte), barra di progresso "2 di 7", tabella con pill di stato colorate (gate-ufficio=verde, Frank=ambra), responsive (si trasforma in schede impilate sotto 640px). Statica come Banco Circuiti — aggiornata a mano da Adrian dopo ogni cambio, nessuna capacità live.

URL: `https://claude.ai/code/artifact/12e38a20-6bd8-4f2a-8966-f86c0e22e5e5`. Collegata sulla scrivania — contatore aggiornato a "5 di 7 app collegate".

## Validazione d'uso reale — accesso da iPad (28/08/2026)

Mauro, in sessione: "usare ArkOS da iPad è fantastico!" — prima conferma esplicita del valore della scelta "solo Artifact claude.ai, niente app nativa": accessibile da qualunque browser/dispositivo senza installare nulla, incluso un iPad. Conferma non richiesta, arrivata mentre si seguiva un recupero dati in corso — buon segnale che l'uso quotidiano reale sta già succedendo, non solo in sessione con Adrian.

## Portolano — quarto box "Sessioni secondarie" (31/08/2026)

Su richiesta di Mauro dopo aver costruito `sentinella-madre` (vedi thread nomenclatura/tassonomia in `memory/MEMORY.md`): documentare le 5 tipologie di istanze secondarie (slave, sentinella, sentinella-madre, sottosentinella, expert) e le istanze attive di ciascuna, dentro il Portolano invece che solo in `MEMORY.md`.

**Implementato**: quarto riquadro collassabile "Sessioni secondarie (Nave)", stesso pattern grafico e stessa logica di layout dinamico di Nave/PC Ufficio/Avamposto (chevron, altezza che si ricalcola, `viewBox` che si adatta) — posizionato sotto Avamposto nella colonna sinistra, nessun connettore disegnato verso Nave (la relazione "gira su Nave" è nel testo del titolo, non in una linea, per non affollare la mappa). 5 blocchi, uno per tipologia, ognuno con conteggio istanze attive nel sotto-titolo (`sentinella` 2 attive, `sentinella-madre` 1 attiva, `expert` 3 attivi, `sottosentinella` 0 — non ancora costruita, `slave` 0 — temporanea per natura) e scheda di dettaglio che elenca le istanze concrete con un ruolo in una riga ciascuna. Link "Approfondisci nel SecondBrain" su 4 dei 5 blocchi verso `claude-cli-headless.md` (URL Drive recuperato via `search_files`, non indovinato, stesso principio della sezione sopra) — `sottosentinella` senza link, non ha ancora una fonte propria essendo non costruita.

URL invariato (stesso Artifact, ripubblicato): `https://claude.ai/code/artifact/3f77ebb6-3e7c-4e85-bd71-8d609855a612`.

**Connessione mailbox aggiunta subito dopo (31/08/2026)**: unica vera lacuna concettuale segnalata da Mauro ("altre cose che potremmo aggiungere?") tra 3 candidati proposti — gli altri due (nodo `guacd`, stato vivo/morto dinamico) scartati per non far diventare il Portolano un secondo posto da tenere sincronizzato con `MEMORY.md`. Linea tratteggiata stile "relay" (stessa classe già usata per Nave↔Ufficio) instradata a lato (x=320) per collegare Nave a "Sessioni secondarie" aggirando il box Avamposto in mezzo — nessun nodo aggiuntivo, solo la connessione mancante tra i due box già esistenti.

## Idea aperta — canvas di card collegate stile Obsidian, per dossier/memo (02/09/2026)

Sessione dedicata al thread `/clear`/compattazione (vedi `gemello-nave/archivio/conoscenza-nave.md`) e alla proposta di un "bibliotecario della memoria" (verifica periodica di `MEMORY.md`/`archivio` contro i trascritti grezzi, non ancora implementata — voce in `memory/MEMORY.md`, sezione Pending architetturale). Primo dossier pubblicato con un template dedicato: **Il Bibliotecario** (`https://claude.ai/code/artifact/a7d477d5-6ae7-45c0-b3d5-6b3236c0fbee`) — palette teal/inchiostro, serif Source Serif 4 + Public Sans + IBM Plex Mono, struttura testata/sezioni/callout/footer.

Mauro (stessa sessione): questi dossier gli somigliano molto nel modo di ragionare — propone di **codificarli** (nomenclatura + layout standard) e farli rientrare in ArkOS, poi affina: pensarlo in modo organico, non un template isolato ma **un sistema di card collegate stile Obsidian Canvas** — i "progetti" che oggi vivono come thread separati (questo del bibliotecario, e il "Cantiere Schedulazioni" — l'Artifact temporaneo `https://claude.ai/code/artifact/f742529b-81d0-4f34-950e-6808ed2bc380` sul redesign di `servizio-schedulazioni`, oggi isolato) diventerebbero card di uno stesso canvas, collegate tra loro.

**Continuità concettuale con il Portolano**: la riflessione Obsidian Canvas vs tldraw/React Flow del 28/08 (vedi sopra) aveva già scartato SDK esterni (bloccati comunque dalla CSP di un Artifact) a favore di "copiare pattern a mano in JS vanilla, mai importare strumenti" — un canvas di card collegate è la stessa direzione applicata a documenti/dossier invece che a nodi di rete (macchine/servizi). Stesso principio di fondo già validato per il Portolano stesso ("resta `archivio/`+`MEMORY.md` l'unica fonte, il canvas è una vista derivata che aggiorno dopo, mai il contrario") si applicherebbe identico qui: i collegamenti tra card rispecchierebbero i `[[wikilink]]` già in uso tra i file di memoria, non un grafo separato da mantenere a mano.

**Deciso di non frammentare**: resta un thread dentro questo stesso progetto ArkOS, non un file/progetto a parte — evita che la stessa idea diverga in due posti.

**Prima bozza pubblicata (02/09/2026)**: `ArkOS_Biblioteca` — `https://claude.ai/code/artifact/0f047fe4-c10b-498e-91b9-cbfabeec9051`. Canvas pan/zoom (trascina, rotellina, pulsanti +/−/reset), sfondo a puntini stile Obsidian Canvas, due card reali (Bibliotecario, Cantiere Schedulazioni) collegate da un edge etichettato ("stesso principio: orologio vs giudizio"), click sul titolo di una card evidenzia lei+collegamenti e attenua il resto. Stesso token system del dossier Bibliotecario (palette teal/inchiostro, Source Serif 4 + Public Sans + IBM Plex Mono). **Non ancora agganciata alla scrivania vera** — resta prototipo isolato.

## Rinominato in "Atlante" — gerarchia canvas-di-canvas (02/09/2026)

Riflessione con Mauro dopo la bozza Biblioteca: quello che oggi è il Portolano potrebbe diventare **un canvas tra altri**, non un'app a sé — sopra più canvas un livello che li contiene, invece di più mappe separate da ricordarsi di controllare. Risolve anche l'idea già aperta dal 28/08 ("portali per nodo denso": quando un nodo diventa troppo affollato, un salto di pagina invece di stiparlo nel pannello laterale) — ogni canvas diventa esso stesso quel salto di pagina.

**Nome scelto: Atlante** (Mauro, 02/09/2026) — scartate "Carteggio" (troppo gergale) e "Planisfero" (corretto ma senza personalità). "Portolano" come nome dell'intero sistema non convinceva Mauro (troppo specifico, è un tipo particolare di libro di rotte) — resta comunque il nome del canvas Infrastruttura qui sotto, il richiamo nautico non si perde, si sposta di livello.

**Struttura decisa**: **Atlante** diventa la sesta app ArkOS (una sola icona sulla scrivania). Dentro, canvas-di-canvas:
- **Infrastruttura** = l'attuale Portolano (Nave/PC Ufficio/Avamposto, sessioni secondarie) — **non ancora migrato**, il Portolano vero (`https://claude.ai/code/artifact/3f77ebb6-3e7c-4e85-bd71-8d609855a612`) resta agganciato e in uso da iPad finché la migrazione non è pronta, non si tocca l'app live per un esperimento.
- **Progetti** = il canvas Biblioteca appena abbozzato (Bibliotecario, Cantiere Schedulazioni).

**Tensione di stile riconosciuta, non ancora risolta**: Infrastruttura ha un tema blueprint fisso (deliberato, non risponde al dark mode); Progetti ha un tema chiaro/scuro adattivo a card. Non forzare un'unica estetica — trattarli come due "quartieri" della stessa macromappa, stessa navigazione (pan/zoom, stesso principio di apertura di un cluster) ma linguaggio visivo distinto per ciascuno, come un atlante vero ha convenzioni diverse per carte fisiche/politiche/nautiche.

## Unificato in un solo Artifact (02/09/2026) — non più tre pezzi separati

Prima costruiti come tre Artifact indipendenti (hub mind-map, canvas Infrastruttura, canvas Progetti, seguendo il pattern generale ArkOS "un'app, un Artifact"). Mauro ha fatto notare che i canvas sono leggeri (statici, nessun dato live, nessun ciclo di aggiornamento indipendente) — la ragione che il 28/08 escludeva "un unico Artifact con più pannelli" per tutta ArkOS (app con stato/dati live divergenti, es. Sala Macchine via connettore mcp) non si applica qui. **Deciso: un solo Artifact per Atlante**, non un'eccezione alla regola generale ArkOS (che resta valida per le altre app con stato/dati live), ma il riconoscimento che Atlante è un caso diverso.

**Pubblicato**: `ArkOS_Atlante` — `https://claude.ai/code/artifact/ad9e4364-6478-4cbc-a0ce-af42e98c5a47` (stesso URL del primo hub mind-map, aggiornato in place). Un solo file HTML, tre viste commutate via `location.hash` (`#`/vuoto = hub, `#infrastruttura`, `#progetti`), topbar condivisa (breadcrumb + controlli zoom, questi ultimi nascosti sulla vista hub). Migrazione del Portolano completata nella stessa pubblicazione: contenuto reale (macchine/servizi/connessioni/pannello dettaglio, dati DATA object) portato dentro la vista Infrastruttura, incapsulato in una shell pan/zoom (drag, rotellina, pulsanti +/−/reset) — non più solo "collassa/espandi + overflow-x", ora naviga come un vero canvas coerente con la vista Progetti. Tema blueprint di Infrastruttura tenuto fisso/distinto (variabili CSS scoped sotto `#view-infra`, non nel `:root` globale) — decisione "quartieri diversi, stessa navigazione" rispettata.

**Correzione di contenuto fatta durante la migrazione**: la scheda `tipo-sentinella` diceva ancora "comunica via mailbox a file, mai SendMessage diretto" — non più vero dal 31/08 (SendMessage è il canale primario per tutte le istanze, mailbox vestigiale). Corretto nel testo migrato — piccola dimostrazione dal vivo del problema che il thread "Bibliotecario" di oggi vuole risolvere sistematicamente (memoria/vista derivata che invecchia rispetto alla fonte).

**Nomenclatura**: hub e i due canvas vivono ora nello stesso file/URL (`ArkOS_Atlante`), quindi non serve più un prefisso `_Infrastruttura`/`_Progetti` separato nel `<title>` — la distinzione resta solo nell'hash di navigazione e nel breadcrumb visibile in pagina.

**Artifact precedenti, ora superati (non cancellati, solo orfani)**: il primo Portolano standalone (`https://claude.ai/code/artifact/3f77ebb6-3e7c-4e85-bd71-8d609855a612`) e la prima Biblioteca standalone (`https://claude.ai/code/artifact/0f047fe4-c10b-498e-91b9-cbfabeec9051`) restano pubblicati ma non più linkati da nessuna parte — da valutare se rimuoverli in un secondo momento (pulizia proattiva), non urgente.

**Interazione hub raffinata (02/09/2026, stessa sessione)**: le foglie di anteprima sotto Infrastruttura erano fittizie (testo statico, mai state vere destinazioni) — rimosse su richiesta di Mauro. Regola adottata per il click su un cluster: **esplode i sottonodi solo se sono destinazioni realmente separate** (ogni card di Progetti ha un dossier proprio — click sul cluster Progetti alterna espandi/comprimi due sottonodi cliccabili, click su un sottonodo apre il canvas già centrato+evidenziato su quella card); se il "dentro" ha senso solo come un'unica mappa esplorabile (Infrastruttura), il click salta dritto al canvas, nessun sottonodo. Regola provvisoria, non un principio definitivo.

**Canvas standardizzati a tutta pagina con chiusura (02/09/2026)**: la topbar con breadcrumb+zoom è stata sostituita da: una topbar minima (solo wordmark "Atlante") visibile solo sull'hub, e un cluster fluttuante in alto a destra — etichetta vista corrente, zoom (−/reset/+), pulsante **✕** — identico per entrambi i canvas, mostrato solo quando un canvas è aperto. Ogni canvas ora occupa l'intero viewport (nessuno spazio riservato a una topbar persistente); il pulsante ✕ riporta all'hub (`location.hash = ''`).

## Progetti (canvas pan/zoom) rimosso — dossier incapsulati direttamente in Atlante (02/09/2026)

Mauro ha chiarito il modello: cliccare un sottonodo del hub deve aprire **direttamente** il canvas-dossier corrispondente, non una tappa intermedia (il canvas Progetti con le due card+edge, costruito prima, faceva proprio da tappa intermedia — rimosso). Bibliotecario e Cantiere Schedulazioni sono stati **incapsulati come contenuto diretto di Atlante**, non più Artifact esterni con `target="_blank"`: due nuove viste (`#bibliotecario`, `#cantiere`), ciascuna con la propria palette scoped (Bibliotecario riusa i token neutri condivisi con l'hub; Cantiere Schedulazioni mantiene la sua identità propria — grigio/blu acciaio, monospace, scoped sotto `#view-cantiere`). Sottonodi del hub aggiornati: `href="#bibliotecario"`/`href="#cantiere"` diretti, niente più `data-focus`/pan-to-card (quel meccanismo, con `focusCard`/`selectCard`/`layoutEdge`, è stato rimosso insieme al canvas Progetti).

**Nuovo standard visivo per i canvas-dossier, deciso da Mauro**: lo schema a blocchi di Cantiere Schedulazioni (blocco = bordo, intestazione con nome+chip di stato tipizzato, corpo, eventuali "pezzi" annidati) diventa il **linguaggio standard** per i futuri canvas di questo tipo — non l'intera identità visiva/palette di Cantiere, solo il "blocco" come unità. La disposizione dei blocchi in pagina resta flessibile, decisa volta per volta in base a cosa va mostrato (colonna singola, due affiancati, nidificati) — non uno schema di griglia fisso. **Bibliotecario riconvertito allo standard (02/09/2026, stessa sessione)**: contenuto ristrutturato da prosa/tabella a blocchi (`[ nome ]` + chip di stato + corpo, pezzi annidati per liste di dettaglio) — 3 blocchi: "Scoperte di oggi" (chip DECISO, due pezzi annidati per /clear e Compattazione), "Il filo del ragionamento" (chip RIF, sette pezzi annidati con etichetta Mauro/Adrian invece di un chip di stato — l'attribuzione di chi parla non è uno stato), "La proposta"+"Valutazione" affiancati in una riga (entrambi chip APERTO). **Palette e tipografia proprie mantenute** (teal/ink condiviso con l'hub, Source Serif 4 per il titolo) — lo standard adottato è solo la struttura del blocco (bordo, intestazione nome+chip, corpo, pezzi annidati), non l'identità visiva di Cantiere Schedulazioni, coerente con quanto chiarito da Mauro ("i canvas contengono sezioni/blocchi, la disposizione varia in base alle necessità"). Introdotto un terzo chip **RIF** (blu neutro, oltre a OK/APERTO) per informazioni di contesto che non sono né una decisione né un problema aperto — vocabolario chip ora a tre voci, riutilizzabile per i prossimi canvas.

**Artifact precedenti, ora superati (non cancellati, solo orfani)**: oltre al primo Portolano standalone e alla prima Biblioteca standalone (vedi sopra), si aggiungono il Bibliotecario standalone (`https://claude.ai/code/artifact/a7d477d5-6ae7-45c0-b3d5-6b3236c0fbee`) e il Cantiere Schedulazioni standalone (`https://claude.ai/code/artifact/f742529b-81d0-4f34-950e-6808ed2bc380`) — quest'ultimo era una lavagna di lavoro pre-esistente (31/08), non costruita in questa sessione. Quattro Artifact orfani in totale — da valutare pulizia in un secondo momento.

**Blocchi collassabili/espandibili (02/09/2026, stessa sessione)**: aggiunto al modello standard su proposta di Mauro — ogni `.block-head` è cliccabile (chevron ▾/▸), collassa/espande il proprio `.block-body`, stesso linguaggio già in uso per le macchine di Infrastruttura (riuso di un pattern esistente, non uno nuovo). Wiring generico (`document.querySelectorAll('.block-head')`), non specifico per canvas — vale automaticamente per ogni blocco futuro che segue lo standard.

## Nomenclatura corretta nel Cantiere Schedulazioni (02/09/2026, affinata due volte nella stessa sessione)

Mauro ha corretto due imprecisioni terminologiche notate rileggendo il canvas: (1) il canale Nave↔Ufficio si chiama **`tunnel-nave-ufficio`** (contratto formale in `archivio/Mauro/lavoro/lavoro-python-ecosistema/tunnel-nave-ufficio.md`, deciso 31/08) — il testo diceva genericamente "gate-ufficio", corretto in entrambi i punti (`servizio-schedulazioni` scrive nel tunnel, non "per gate-ufficio"); (2) **la pipeline è "schedulazioni" (servizio-schedulazioni), non "gate-ufficio"** — primo giro corretto in modo impreciso ("gate-ufficio è la pipeline"), poi Mauro ha affinato ulteriormente: `tunnel-nave-ufficio` e `servizio-router-ufficio` sono **infrastruttura condivisa fra più pipeline**, non parte di un'unica pipeline gate-ufficio. Confermato con un caso già reale, non ipotetico: `flussi-expert` usa già lo stesso tunnel/router per le sue diagnosi read-only su `I:\`, indipendente dalla pipeline di schedulazione — due mittenti distinti sulla stessa infrastruttura oggi, altri potranno aggiungersi senza toccare il tunnel. Canvas aggiornato di conseguenza (sottotitolo, blocco servizio-router-ufficio, nota sulla sentinella) — e, su richiesta di Mauro, `tunnel-nave-ufficio` è diventato un blocco a sé (chip **SOLO LOGICO**: nessun processo/software dedicato, solo il meccanismo to-gate/from-gate + polling, contratto in `tunnel-nave-ufficio.md`), invece di restare solo menzionato dentro gli altri due. Nessun impatto tecnico, solo precisione di linguaggio — ma un modello concettuale corretto qui evita di progettare male le prossime pipeline quando arriveranno.

## Schema architetturale modem/registro/parser (02/09/2026, sviluppato con Mauro nel Cantiere Schedulazioni)

Dalla domanda "il tunnel dovrebbe avere un ricevente agnostico anche sul ritorno?" è emerso un disegno completo, non ovvio, per il redesign di servizio-schedulazioni/servizio-router-ufficio. Tre livelli per lato (non due):

1. **Modem** — solo I/O, scrive/legge i file del tunnel, non sa cosa contengono. Nave: puro I/O riusabile da più mittenti (servizio-schedulazioni, flussi-expert). Ufficio: stesso principio, oggi mescolato con il parser dentro `Gate` (`servizio_router_ufficio.py`) — da separare.
2. **Parser/dispatcher — solo lato ufficio, asimmetria voluta**: un solo ricevitore serve più mittenti diversi, deve interpretare chi parla prima di eseguire. Lato Nave non serve un parser equivalente: chi crea una richiesta interpreta da sé la propria risposta (lo sa già dal proprio registro) — costruire un parser lì sarebbe un componente senza un vero lavoro da fare.
3. **Registro — uno per lato, persistito (mai solo in memoria), non è un buffer**: il buffer è già la cartella condivisa stessa (`to-gate/`/`from-gate/`, multi-file, non un canale seriale a uno slot — chi scrive non aspetta mai una "corsia libera"). Il registro è un libro mastro a parte, due colonne per id: Nave traccia andata(spedizione)+ritorno(ricezione risposta); ufficio traccia andata(ricezione richiesta)+ritorno(invio risposta). Il registro ufficio è un'aggiunta **nuova**, non una sostituzione — dà un segnale che oggi non esiste affatto: una coda accumulata trovata al risveglio è già di per sé l'anomalia (es. PC disconnesso), rilevata sul posto invece che dedotta a posteriori da un timeout lato Nave (esattamente il tipo di ricostruzione fatta a mano per l'incidente di stamattina).

**Pulizia risolta per costruzione, non con un job a parte**: verificato nel codice reale (`servizio_router_ufficio.py`) che oggi nessuno cancella mai nulla — nessun `remove`/`unlink`, solo idempotenza (se la risposta esiste, salta). Fix: ogni modem cancella ciò che ha finito di usare — ufficio cancella la richiesta *dopo* aver scritto la risposta (mai prima, per non perderla se il processo si interrompe a metà); Nave cancella la risposta dopo che il mittente proprietario l'ha registrata.

Canvas aggiornato con tutti e tre i blocchi (servizio-schedulazioni, tunnel-nave-ufficio, servizio-router-ufficio) riscritti secondo questo schema. **Ancora tutto "da scrivere"/"da separare"** — nessun codice toccato, solo design.

**Due affinamenti dello stesso giro**: (1) **principio dell'anello** (Mauro) — un modem apre sempre un anello (andata/ricezione) che deve chiudersi con l'evento simmetrico (ritorno/invio); se non si chiude entro un tempo ragionevole, quello è già l'anomalia, stessa logica su entrambi i lati invece di due meccanismi pensati separatamente. Ha completato anche un caso mancante lato ufficio: non solo "coda accumulata all'arrivo" ma anche "ricezione presa in carico ma mai risposta" (es. job bloccato a metà) — due anelli distinti, non uno solo. (2) **il registro fa da buffer, ma di stato non di payload** — il payload (busta JSON) resta nel file via modem, mai duplicato; l'elenco degli "anelli aperti" nel registro è però esso stesso la coda operativa che business logic e rilevamento anomalie usano davvero. Due livelli di buffer distinti, non in contraddizione con "il registro non deve duplicare il buffer" (quello vale solo per il payload).

## Busta completata: mittente + inviato_alle, due buchi reali trovati con un audit (02/09/2026)

Mauro ha chiesto "abbiamo tutti i pezzi?" — audit onesto del disegno prima di scrivere codice, non solo "sì c'è tutto". Trovati e chiusi nello stesso giro:
- **Limite single-thread lato ufficio**: promesso di aggiungere prima, perso per strada nella conversazione — aggiunto ora al blocco modem ufficio (job lento ritarda richieste non correlate, tempo limitato non indefinito, non un problema con i volumi di oggi).
- **Campo `mittente` mancante nella busta**: il dispatch per-mittente promesso si basava implicitamente sul nome dell'istruzione (`run_job`→schedulazioni, azioni read-only→flussi-expert) — funzionava per caso, non per costruzione. Aggiunto `mittente` esplicito.
- **Campo `inviato_alle` mancante**: quel dato viveva solo nel registro Nave, invisibile al lato ufficio (che avrebbe dovuto affidarsi al `mtime` del file, fragile). Aggiunto esplicito nella busta.

Schema finale della busta: `{id, mittente, inviato_alle, timeout_seconds, istruzione: {nome, params}}` — quattro metadati + un contenuto agnostico. Aggiornati contratto formale e canvas (blocchi tunnel-nave-ufficio, servizio-schedulazioni, servizio-router-ufficio).

## sentinella-madre: relay mailbox non è vestigiale per i servizi meccanici (02/09/2026)

Confermando la catena di notifica di un anello non chiuso (registro → mailbox → sentinella-madre → SendMessage → Adrian), Mauro ha richiamato un principio già previsto ma non scritto formalmente: sentinella-madre fa da **convertitore analogico→digitale** — raccoglie il segnale grezzo di chi non ha `SendMessage` (mailbox) e lo trasforma in notifica vera. Il relay era stato segnato "vestigiale" il 31/08, ma quella nota valeva solo per sentinelle/esperti (istanze Claude Code, ora tutte su SendMessage diretto) — un `servizio-*` meccanico puro come il futuro registro di `servizio-schedulazioni` non ha e non deve avere accesso a SendMessage per principio, per lui la mailbox resta l'unico canale reale, non un residuo storico. Corretto ovunque: `scripts/slave-sentinels/sentinella-madre/CLAUDE.md` (versione 3), `memory/MEMORY.md` (due voci), canvas Atlante (blocchi registro Nave e Infrastruttura/Connessioni).

## Domanda parcheggiata — comunicazione spontanea ufficio→Nave (02/09/2026)

Mauro ha chiesto se PC ufficio avrà mai bisogno di innescare un anello (oggi solo Nave inizia). Caso reale identificato: il registro ufficio può trovare un'anomalia propria senza che ci sia una richiesta Nave pendente a cui agganciarla — oggi non avrebbe modo di dirlo. Due strade abbozzate (ufficio innesca un anello spontaneo tipo `evento-<id>.json`, o Nave chiede periodicamente lo stato riusando lo schema richiesta/risposta esistente) — **deciso di non affrontarla ora**, non urgente. Nota parcheggiata nel canvas (blocco registro ufficio).

## Busta ristrutturata: metadati + contenuto, "action" diventa "istruzione" (02/09/2026)

Su proposta di Mauro: la busta richiesta guadagna `timeout_seconds` (deciso da chi compone la richiesta, non un valore fisso uguale per tutte) e viene riorganizzata in due parti concettualmente distinte invece di un elenco piatto di campi — **metadati** (`id`, `timeout_seconds`, usati da tunnel/registro per instradare/sorvegliare) e **contenuto** (un unico oggetto annidato, completamente agnostico, che il tunnel/modem non apre mai). Il vecchio campo `action` è stato rinominato due volte nello stesso giro — prima "comando", poi **"istruzione"** (nome definitivo) — con `params` annidato dentro, non più allo stesso livello. Schema finale: `{id, timeout_seconds, istruzione: {nome, params}}`. Aggiornati sia il contratto formale (`archivio/Mauro/lavoro/lavoro-python-ecosistema/tunnel-nave-ufficio.md`) sia il canvas (blocchi tunnel-nave-ufficio, registro Nave, parser ufficio).

## Chiusura del disegno — nessun buffer nel sistema (02/09/2026)

Ultimo affinamento terminologico, deciso da Mauro: **buffer** = coda di cose non ancora spedite, in attesa del proprio turno per partire. Con questa definizione precisa, **nel disegno di oggi non c'è nessun buffer, da nessuna parte** — `NaveScheduler` spedisce ogni job subito appena dovuto, nulla aspetta mai il proprio turno per essere inviato. Le righe "andata senza ritorno" nel registro e i file "già spediti, in attesa di ritorno" nella cartella non sono un buffer — sono un **tracciamento di ciò che è in volo**, categoria diversa. Corretto il canvas in entrambi i punti dove avevo usato "buffer" in modo impreciso (registro Nave, nota sul tunnel).

**Disegno finale, riassunto in un colpo d'occhio** (tutto ancora da scrivere, nessun codice toccato):
- Tunnel: due cartelle, nessun processo a sé, multi-file, mai bloccante.
- Modem (uno per lato): solo I/O. Nave riusabile da più mittenti; ufficio da separare dal parser.
- Parser: solo lato ufficio (asimmetria voluta — solo lì serve smistare tra mittenti diversi).
- Registro (uno per lato, persistito): traccia anelli aperti (andata/ritorno), non un buffer.
- Principio guida: anello non chiuso entro un tempo ragionevole = l'anomalia stessa.
- Pulizia: ogni modem cancella ciò che ha finito di usare, non un job a parte.
- `sentinella-gate-ufficio` dismessa solo quando il registro Nave è scritto e funzionante.

## Correzione: il bug del trigger.log non blocca il registro (02/09/2026)

Adrian aveva collegato erroneamente il bug del `trigger.log` (non sembra accodare, mostra solo l'ultima esecuzione) al futuro registro di `servizio-schedulazioni`, scrivendo nel canvas "da verificare prima di riusarlo come base per il registro". Mauro ha corretto: il registro non si baserà su quel log — è coerente con la ragione stessa per cui `sentinella-gate-ufficio` va dismessa (smettere di classificare via parsing di testo). Il registro traccerà id/job/timestamp direttamente al momento del trigger e verificherà l'arrivo di `risposta-<id>.json` (file strutturato in `from-gate/`), non il contenuto di un log. **Il bug del trigger.log resta reale e da sistemare** (utile per debug/storico), ma non è più un prerequisito per costruire il registro — la sequenza per dismettere `sentinella-gate-ufficio` si riduce a un solo passo: registro scritto e funzionante, poi dismissione. Canvas corretto (chip da "APERTO" a "bug minore, non bloccante").

## Test dei limiti dello standard — Infrastruttura convertita a blocchi (02/09/2026)

Su richiesta di Mauro, come test deliberato dei limiti dello standard (Infrastruttura era proprio il caso "già a blocchi" — macchine con servizi annidati — ma rappresentato come mappa spaziale con frecce): convertita interamente. 4 blocchi macchina (Nave, PC Ufficio, Avamposto, Sessioni secondarie) con servizi/tipologie come pezzi annidati, più un quinto blocco "Connessioni" per le relazioni Nave↔Ufficio/Avamposto/Sessioni. Rimossi: SVG blueprint, pan/zoom, pannello dettaglio laterale, collassa/espandi su misura (sostituito dal meccanismo generico già condiviso). Rimossi anche `HAS_ZOOM`/`makeController`/`controllers` e i pulsanti zoom dal cluster fluttuante — nessuna vista li usa più, la Progetti pan/zoom era già stata rimossa in precedenza.

**Limite reale emerso (lo scopo del test)**: lo standard a blocchi rappresenta bene contenuto **gerarchico** (macchina → servizi), ma non ha un modo nativo per un **grafo** (nodi con relazioni arbitrarie tra loro) — le frecce/etichette di connessione (Dropbox+git, WireGuard, tunnel-nave-ufficio "poll 30s", mailbox instradata a lato) sono state salvate solo come testo in un blocco dedicato, perdendo il colpo d'occhio spaziale della mappa originale. Se in futuro serve di nuovo vedere le connessioni in modo visivo, quello resta il candidato naturale per un canvas-mappa (o un sotto-canvas, vedi thread sopra) invece che blocchi.

## Grafica unificata — un solo sistema per tutti i canvas (02/09/2026)

Mauro ha deciso di superare esplicitamente il principio "quartieri diversi, stessa navigazione ma linguaggio visivo distinto" (fissato il 02/09 stesso, poche ore prima): **tutti i canvas devono avere la stessa grafica e funzionalità**, modello Cantiere Schedulazioni. Consolidati i tre set di token/CSS scoped per-vista (`#view-infra`, `#view-bibliotecario`, `#view-cantiere`, ciascuno con la propria palette) in un unico sistema `.view-doc` con token condivisi (`--cvbg`/`--cvbox`/`--cvline`/`--cvtext`/chip ok-open-ref), light+dark già supportati. Infrastruttura ha perso anche lo sfondo a griglia blueprint (era l'ultimo residuo di identità propria). Il hub (mind map) resta fuori da questa unificazione — non è un canvas, è la copertina dell'atlante.

**Titolo ingrandito** su richiesta di Mauro: h1 dei canvas da 16px a 28px, peso 700 (aggiunto il peso 700 di IBM Plex Mono al link Google Fonts, mancava). Rimosso IBM Plex Sans dal caricamento font (non più usato da nessuna vista dopo l'unificazione).

## Agganciato alla scrivania ArkOS (02/09/2026)

Icona "Portolano" sulla scrivania (`https://claude.ai/code/artifact/97f99a5b-ccc5-497d-9abb-6867041ec914`) sostituita con "Atlante" — stesso slot, stessa icona (bussola), link aggiornato a `https://claude.ai/code/artifact/ad9e4364-6478-4cbc-a0ce-af42e98c5a47`. Aggiornati sia il tile sulla scrivania sia la voce nel menu Start. Contatore "5 di 7 app collegate" lasciato invariato (sostituzione 1:1, non una app in più).

Mauro ha chiesto anche di eliminare l'Artifact standalone del vecchio Portolano — **non possibile con gli strumenti disponibili** (nessuna azione di cancellazione per un intero Artifact, solo `delete_asset` per file interni a un Artifact). Resta orfano insieme agli altri tre (Biblioteca, Bibliotecario, Cantiere Schedulazioni standalone) — cancellazione manuale da parte di Mauro via claude.ai se la vuole davvero rimossa dalla galleria.

## Schedulatore e Centrale Flussi migrati in Atlante (02/09/2026)

Stesso trattamento già dato a Portolano/Bibliotecario/Cantiere: contenuto reale portato dentro Atlante come nuovi canvas (`#schedulatore`, `#flussi`), standard a blocchi condiviso, Artifact standalone scollegati.

**Hub esteso a 4 cluster**: aggiunti due nuovi rami sulla mind map (Schedulatore in alto a destra, Flussi in basso a sinistra), simmetrici a Infrastruttura/Progetti — disposizione a bussola attorno al nodo centrale. Nuovi colori cluster: `--cl-sched` (ambra, ripreso dall'accent originale di ArkOS_Schedulatore), `--cl-flussi` (arancio-ruggine, ripreso da ArkOS_Centrale Flussi) — unico punto in cui l'identità cromatica delle vecchie app sopravvive, sull'hub. Entrambi i cluster aprono subito il canvas (nessun sottonodo), stesso trattamento di Infrastruttura — non hanno destinazioni separate al loro interno.

**Schedulatore**: conversione diretta, un solo blocco "Job ricorrenti" con 7 pezzi annidati (uno per job), chip OK=migrato a gate-ufficio / LEGACY=ancora su Frank. Nessuna perdita informativa — la tabella originale era già lineare.

**Flussi**: stesso limite già visto con Infrastruttura, qui più marcato — l'originale (`ArkOS_Centrale Flussi`, 41KB) era un vero diagramma di flusso SVG con pan/zoom, frecce etichettate (tratteggiate=ipotesi, piene=confermato) e pannello dettaglio per nodo. Convertito in 6 blocchi in sequenza (Direzione Sistemi → L1/L2 → sync → rami Weekly/Daily affiancati → fuori pipeline), terzo chip **IPOTESI** aggiunto al vocabolario (oltre OK/LEGACY) per lo status "hyp" dell'originale. **Persa la rappresentazione grafica del grafo** (frecce, routing spaziale, distinzione visiva piena/tratteggiata) — dichiarato esplicitamente nel footer del canvas. Contenuto testuale (10 nodi, tutti i path, dettagli tecnici verificati) preservato integralmente.

**Scrivania aggiornata**: icone Schedulatore e Centrale Flussi rimosse (tile + menu Start), contatore "5 di 7" → "4 di 6 app collegate" (6 app totali contate ora: Banco Circuiti, Sala Macchine, Centrale Flussi, Atlante, Query builder, Sensori — Schedulatore non più un'app a sé). **Sei Artifact ora orfani** in totale (Portolano, Biblioteca, Bibliotecario, Cantiere Schedulazioni, Schedulatore, Centrale Flussi) — pulizia manuale rimandata, non urgente.

## Placeholder Query builder/Sensori di casa spostati in Atlante (02/09/2026)

Su richiesta di Mauro, spostati anche i due placeholder "in arrivo" (mai stati Artifact veri, solo icone disabilitate sulla scrivania) dentro Atlante — hub esteso a 6 nodi: due nuovi rami tratteggiati (nord/sud, `.branch-path.placeholder`), due nodi cerchio-vuoto non cliccabili (`.node-placeholder`, nessun `<a>`, nessun link) con etichetta "in arrivo", stesso stile disabilitato che avevano sulla scrivania (attenuato, tratteggiato) tradotto nel linguaggio dell'hub.

**Scrivania ridotta a 3 icone**: Banco Circuiti, Sala Macchine, Atlante — tutte attive. Contatore corretto a "3 di 3 app collegate" (**nota**: il "4 di 6" lasciato nella migrazione precedente era già sbagliato — errore mio, contavo ancora Centrale Flussi come app a sé anche dopo averne tolto l'icona; corretto qui).

**Non ancora fatto**: verifica visiva reale (solo controllato da codice, mai uno screenshot Playwright).

## Nodo Produzione — seconda card, Gmail personale (04/09/2026)

Aggiunta `sentinella-gmail-personale` (appena costruita e lanciata, vedi
`project_monitoraggio_gmail.md`) come seconda foglia del cluster **Produzione** (prima ne aveva
una sola, `gate-ufficio` → `#cantiere`) — su richiesta di Mauro: è un sistema live, non un
progetto in corso, coerente col motivo per cui quel nodo esiste (distinto da "Progetti"). "1 card"
→ "2 card". Stesso meccanismo delle altre card: `renderMdView` incorpora l'intero dossier
`project_monitoraggio_gmail.md` (frontmatter+corpo, invariato) in un nuovo
`<script id="md-gmail-personale-source">`, nuova vista `#gmail-personale`, wiring completo di
router/hint/breadcrumb. Nessuna riformattazione del contenuto — il dossier era già scritto nella
sintassi che il parser riconosce (blocchi `##`, callout di stato, pezzi `- **tipo** —`).
Ripubblicato in place (stesso URL). **Promemoria per il futuro**: questo file HTML incorpora il
contenuto per copia, non per riferimento — se `project_monitoraggio_gmail.md` cambia ancora
(es. quando la sentinella passa a regime `silenzioso`), la vista Atlante non si aggiorna da sola,
va risincronizzata a mano (stesso rischio di deriva già segnalato in `atlante-convenzioni.md`).

## SMANTELLATO (05/09/2026, notte) — non solo ArkOS, l'idea di costruire dentro gli Artifact

Nella sessione notturna sul "bicchiere pieno"/fondamenta-vs-impalcatura (vedi
[[project_roadmap_condivisa]]), applicando il criterio appena emerso ("una fondazione si vede solo
se qualcosa dipende già da lei") a tutto questo progetto: **la gran parte non ha superato il
test**. Sei Artifact ormai orfani (Portolano, Biblioteca, Bibliotecario, Cantiere Schedulazioni,
Schedulatore, Centrale Flussi standalone), giri multipli di redesign dello stesso concetto senza
che nulla ci si appoggiasse sopra nel frattempo, due app mai costruite (Query builder, Sensori —
solo placeholder). L'unica cosa che aveva davvero superato il test era la validazione d'uso reale
del 28/08 ("usare ArkOS da iPad è fantastico") — ma Mauro ha deciso di andare oltre quella singola
eccezione: **smontare tutto**, mettendo in discussione l'idea stessa di costruire infrastruttura
dentro gli Artifact claude.ai, non solo il perimetro di ArkOS.

**Limite tecnico**: nessun tool disponibile cancella un Artifact intero (solo `delete_asset` per
file interni) — la cancellazione è manuale, solo Mauro dalla sua galleria claude.ai. Non ancora
fatto: preparare l'elenco completo degli URL da smaltire (scrivania ArkOS, Atlante, Banco Circuiti,
Sala Macchine, più i sei orfani sopra). Da questo momento **nessun nuovo lavoro su ArkOS/Atlante**
— progetto chiuso, non solo in pausa.