sistec-llm-wiki: la wiki aziendale per l'AI

La wiki-LLM è un pattern di condivisione della conoscenza reso celebre da Andrej Karpathy (gist ufficiale). L'idea centrale è che l'AI non ha bisogno di un'infrastruttura custom per accedere alla conoscenza aziendale: le servono solo file di testo in una cartella che tutti possono sincronizzare.

Il pattern si contrappone al modello shared-ai (collector / lease Graph-ETag / Orchestrator) che richiede un'infrastruttura distribuita custom da progettare, costruire e verificare. La wiki-LLM è l'alternativa zero infrastruttura: si appoggia a OneDrive/NAS per la sincronizzazione e all'AI stessa per l'indicizzazione e il recupero.

Esiste già una demo funzionante in sistec-llm-wiki. La struttura della cartella dimostra il pattern in azione:

// struttura della demo (reale)
sistec-llm-wiki/
├── raw/                          // fonti immutabili: chiunque può aggiungerne, nessuno le modifica
│   ├── assets/                   // immagini e allegati
│   └── 2026-06-17-kickoff-progetto-atlas.md
├── wiki/                         // pagine generate e mantenute dall'LLM
│   ├── overview.md               // sintesi globale: stato e contesto in evoluzione
│   ├── concetti/
│   ├── decisioni/
│   ├── fonti/                    // un riassunto 1:1 per ogni fonte in raw/
│   ├── organizzazioni/
│   ├── persone/
│   └── progetti/
├── CLAUDE.md                     // LO SCHEMA: convenzioni + operazioni (ingest/query/lint)
├── index.md                      // catalogo di tutto il wiki, aggiornato a ogni ingest
└── log.md                        // registro cronologico append-only

Il flusso è lineare, e tutta la configurazione sta in un unico file: il CLAUDE.md della cartella, che definisce ruoli, convenzioni (frontmatter, wikilink, nomi file) e le tre operazioni — ingest, query, lint. Chi lancia Claude Code o opencode lì dentro parte già configurato: niente skill, niente codice.

1. Deposito. Chiunque mette una fonte in raw/ — verbali, specifiche, decisioni, appunti. Nessun formato imposto: markdown, PDF, txt, immagini in raw/assets/.
2. Ingest. Su richiesta dell'operatore, l'AI esegue l'operazione definita in CLAUDE.md: legge la fonte, scrive il riassunto in wiki/fonti/, aggiorna le pagine sintetiche toccate (persone, progetti, decisioni, concetti, organizzazioni), aggiorna index.md e appende a log.md.
3. Retrieval. Alla domanda di un operatore, l'AI parte da index.md, entra nelle pagine rilevanti, segue i wikilink e risponde con provenienza citata.

L'architettura della wiki-LLM si basa su tre componenti: sync, ingest, retrieval. Nessuno dei tre richiede infrastruttura custom.

3.1 Sync — la dorsale

La sincronizzazione è affidata a Teams/SharePoint. In Sistec la cartella esiste già: la libreria documenti del team SistecAM-AIStack, sincronizzata via client OneDrive sul PC di ogni dipendente autorizzato. Il percorso locale dipende dall'account, ad esempio:

C:\Users\Sistec 32\Sistec srl\Sistec AM-AI Stack - sistec-wiki

Quando un documento nuovo viene aggiunto a raw/ da un dipendente, la sync lo propaga a tutti i sottoscrittori. Niente da progettare: funziona già, è la stessa infrastruttura Teams già in uso in azienda.

3.2 Ingest — l'estrazione della conoscenza

L'ingest è eseguito da un agente AI (Claude Code o opencode) secondo l'operazione definita nel CLAUDE.md della wiki. Quando l'operatore aggiunge una fonte in raw/ e chiede di processarla, l'agente:

1. Legge la fonte per intero (testo più eventuali immagini in raw/assets/).
2. Discute con l'operatore i takeaway chiave prima di scrivere — l'umano resta nel loop.
3. Scrive il riassunto in wiki/fonti/AAAA-MM-GG-titolo.md.
4. Aggiorna le pagine sintetiche toccate — progetti, persone, organizzazioni, decisioni, concetti — creando quelle mancanti, con frontmatter YAML e wikilink incrociati. Una fonte può toccare 5-15 pagine. Le pagine esistenti vengono estese, non sovrascritte.
5. Segnala le contraddizioni con un blocco ⚠️, senza mai cancellare l'informazione precedente.
6. Aggiorna index.md (e overview.md se il quadro generale cambia) e appende una riga a log.md.

3.3 Retrieval — il consumo della conoscenza

Il retrieval avviene in due modalità:

3.4 Attivazione automatica su ogni progetto

Perché Claude Code consulti la wiki senza doverlo ricordare ad ogni sessione, basta un rimando nel CLAUDE.md a livello utente (C:\Users\<utente>\.claude\CLAUDE.md). Questo file viene caricato in aggiunta al CLAUDE.md di progetto in qualunque repository su cui l'operatore lavora — bastano un paio di righe, una sola volta per PC:

In "C:\Users\Sistec 32\Sistec srl\Sistec AM-AI Stack - sistec-wiki" è presente una LLM wiki aziendale.
Consultala seguendo le regole in "C:\Users\Sistec 32\Sistec srl\Sistec AM-AI Stack - sistec-wiki\CLAUDE.md"
per ottenere informazioni sui progetti a cui stai lavorando.

La demo sistec-llm-wiki dimostra che il pattern funziona — e che non c'è niente da costruire. Il CLAUDE.md della wiki è già la configurazione completa: convenzioni (frontmatter YAML, wikilink, nomi file) e le tre operazioni — ingest, query, lint — specificate passo per passo. Niente skill, niente regole path-scoped, niente hook o wrapper: l'operatore chiede in linguaggio naturale («processa il verbale che ho messo in raw/», «chi ha lavorato ad Atlas?») e l'agente esegue l'operazione corrispondente. La proposta si articola in tre fasi.

Fase 1 — Condivisione e collaudo (1 settimana)

La demo è locale. La fase 1 la rende condivisa e ne collauda lo schema.

1. Sync. Cartella già attiva: libreria Teams/SharePoint SistecAM-AIStack, sincronizzata via OneDrive su ogni PC autorizzato. Niente da progettare: funziona già.
2. Attivazione per-utente. Ogni operatore aggiunge il rimando alla wiki nel proprio CLAUDE.md a livello utente (§3.4), così l'agente la consulta in ogni progetto senza configurazione per-repo.
3. Pilota. 2-3 operatori la usano davvero: depositano fonti in raw/, chiedono l'ingest, interrogano la wiki. Le domande che falliscono rivelano i buchi.
4. Affinamento dello schema. Ogni attrito emerso nel collaudo si risolve aggiornando il CLAUDE.md: convenzioni più chiare, struttura per tipo più precisa, operazioni più robuste.

Fase 2 — Ingest da Microsoft 365 (2 settimane)

La conoscenza aziendale vive già in Teams, OneNote e OneDrive. La fase 2 la porta nella wiki con un MCP server e una nuova operazione nel CLAUDE.md — non una skill (vedi §8 per il dettaglio completo).

1. Server MCP. Configurare @softeria/ms-365-mcp-server in .mcp.json nella cartella della wiki. Autenticazione OAuth2 gestita dal server, token locali.
2. Operazione sync-m365. Aggiungere al CLAUDE.md una quarta operazione che orchestra i tool MCP: estrae messaggi Teams, pagine OneNote e file OneDrive e li deposita in raw/.
3. Filtri. Definire quali team, canali e notebook sono rilevanti — il grosso del lavoro è evitare il rumore.

Fase 3 — Adozione e governo (continua)

La wiki vive se viene usata e curata. Serve un modello di governo leggero.

1. Canonicalizzatore dedicato. Una persona (o un ruolo a rotazione) revisiona periodicamente i documenti in raw/ e la qualità dell'ingest: le entità sono corrette? Le relazioni sono aggiornate? Le fonti sono citate? L'AI fa il grosso, ma un occhio umano mantiene la qualità. L'operazione lint del CLAUDE.md è lo strumento: produce il report di salute su cui il canonicalizzatore decide.
2. Retro-ingest dei progetti esistenti. I repository git dei progetti Sistec (commessa 5309 FAEL, ecc.) hanno già openspec/changes/archive/ con proposte e design, e .claude/claude-archive/ con i riepiloghi di sessione (skill archive) — entrambi contengono decisioni già scritte. Un'operazione una tantum di retro-ingest popola wiki/ con questa conoscenza.
3. Metriche d'uso. Il log.md append-only è già la fonte: ogni voce ha prefisso parsabile (## [AAAA-MM-GG] tipo | descrizione), quindi contare ingest e query al giorno è un grep. Il valore della wiki cresce con la sua dimensione e il suo uso.

Nel documento index si parla di due canali di condivisione — e di una terza gamba: graphify per la mappa del codice. La wiki-LLM è il secondo canale. I due canali sono indipendenti — vivono in posti diversi, si condividono in modi diversi — e convergono solo sull'operatore, che installa le skill dal marketplace e cerca le informazioni nella wiki. Accanto a loro, graphify mappa ogni singolo repository di codice in un knowledge graph per-progetto (graphify-out/): non un terzo canale di condivisione, ma l'indice del progetto su cui l'agente lavora.

5.1 Sul disco dell'operatore

Fig 2 è astratta — ecco dove finiscono davvero le cose sul PC. Skill e wiki vivono a livello utente, una volta per PC, visibili da ogni progetto. La cartella del progetto resta pulita: solo codice — più la mappa graphify (graphify-out/), che vive nella root del repo insieme al codice che descrive. Nessuna skill, nessuna wiki dentro.

5.2 Memoria automatica nativa: perché resta disattivata

Claude Code ha una memoria automatica nativa per-progetto (~/.claude/projects/<repo>/memory/): Claude stesso decide cosa annotarsi tra una sessione e l'altra — comandi di build, insight di debug, note di architettura — senza intervento dell'operatore. Con marketplace + wiki-LLM copriamo già lo stesso spazio in modo migliore, e la teniamo disattivata di default su ogni PC.

1. Machine-local, non condivisa. La memoria nativa vive nel profilo locale dell'operatore, non sincronizzata tra PC. Due operatori sullo stesso progetto accumulano note diverse e non allineate — drift silenzioso che nessuno rilegge finché non produce una risposta sbagliata.
2. Non curata. Claude scrive da solo, senza revisione umana. La wiki-LLM invece ha un canonicalizzatore (§4 Fase 3) e l'operazione lint: qualità e provenienza sono verificate, non presunte.
3. Ridondante rispetto ai canali già previsti. Comportamenti e convenzioni → skill self-contained (.claude/skills/, marketplace) e rules path-scoped (.claude/rules/). Fatti e decisioni → wiki-LLM. Struttura e relazioni del codice → graphify per-progetto. Non resta nulla che la memoria automatica dovrebbe coprire lei sola.

6.1 «Chi ha lavorato a questo modulo?»

Un operatore ereditato un modulo senza documentazione chiede: «Chi ha lavorato a gestione-mescole?». L'AI consulta wiki/progetti/gestione-mescole.md, segue i link alle persone e risponde: «Marco Manfrin e Davide Conti, vedi le decisioni in wiki/decisioni/.» Con provenienza citata.

6.2 «Perché è stata scelta questa architettura?»

«Perché il modulo auth usa JWT rotation invece di sessioni?» L'AI trova la decisione in wiki/decisioni/auth-jwt-rotation.md, scritta dopo un'analisi dei requisiti, e cita la fonte in raw/ (il verbale della riunione del 15 marzo 2026).

6.3 «Quali progetti usano il pattern Strangler Fig?»

L'AI naviga il grafo da wiki/concetti/strangler-fig-pattern.md, segue le relazioni usato-da verso i progetti, e rispone: «Progetto Atlas e Gestione Mescole. Vedi wiki/progetti/progetto-atlas.md per i dettagli.»

6.4 Ingest dopo una riunione

Dopo un incontro tecnico, un partecipante scrive appunti in raw/2026-07-22-verbale-riunione.md e chiede all'agente di processarli. L'AI esegue l'operazione di ingest del CLAUDE.md: discute i takeaway, scrive il riassunto in wiki/fonti/, aggiorna le pagine di decisioni, persone e concetti toccate. I colleghi possono subito interrogare la wiki sulle decisioni prese.

6.5 Retro-ingest da openspec e claude-archive

I repository dei progetti Sistec hanno openspec/changes/archive/ con decine di proposte e design documentati, e .claude/claude-archive/ con i riepiloghi di sessione della skill archive. Una tantum, l'operatore li copia in raw/ e chiede un ingest massivo: l'AI legge gli archive, estrae decisioni e architetture, e popola wiki/ con la conoscenza già prodotta. La wiki parte già piena.

Finora la wiki-LLM si basa su file depositati manualmente in raw/. Ma la conoscenza aziendale esiste già — nei messaggi Teams, nei notebook OneNote, nei documenti OneDrive. Con un MCP server per Microsoft 365, Claude Code può accedervi direttamente e portarli nell'ingest.

Il server di riferimento è @softeria/ms-365-mcp-server (github), 200+ tool su Graph API. Si configura in .mcp.json:

{
  "mcpServers": {
    "ms365": {
      "command": "npx",
      "args": ["-y", "@softeria/ms-365-mcp-server", "--org-mode"]
    }
  }
}

8.1 Tool per sorgente

Teams richiede --org-mode (account aziendale). OneNote e OneDrive funzionano anche in modalità personale. Il server supporta preset per caricare solo i tool necessari e risparmiare contesto:

# Solo Teams (--org-mode + --preset teams)
npx @softeria/ms-365-mcp-server --org-mode --preset teams

# Solo OneNote
npx @softeria/ms-365-mcp-server --preset onenote

# Solo OneDrive
npx @softeria/ms-365-mcp-server --preset onedrive

8.2 Flusso di ingest M365 → wiki

L'operazione sync-m365 — una sezione in più nel CLAUDE.md della wiki, accanto a ingest, query e lint — orchestra i tool MCP in sequenza e deposita il risultato in raw/:

L'operazione segue questa sequenza:

1. Teams — canali. Per ogni team di progetto (Progetto Atlas, FAEL, ecc.), elenca i canali, poi per ogni canale legge i messaggi dell'ultima settimana. Scrive in raw/teams/<team>-<canale>-YYYY-MM.md.
2. Teams — chat. Elenca le chat recenti, filtra quelle con attività tecnica (contiene codice, menzioni di repo, decisioni), scrive in raw/teams/chat-<persona>-YYYY-MM.md.
3. OneNote. Per ogni notebook condiviso (es. Riunioni Sistec, Specifiche), elenca sezioni e pagine, estrae il contenuto delle pagine nuove o aggiornate. Scrive in raw/onenote/<notebook>-<sezione>-<pagina>.md.
4. OneDrive. Per ogni cartella condivisa di progetto, elenca i file nuovi, scarica .docx/.pdf, converte in markdown. Scrive in raw/onedrive/<progetto>-<file>.md.
5. Segnala completamento. Restituisce all'operatore un riepilogo: quanti messaggi, pagine e file processati, pronti per l'ingest standard.

// CLAUDE.md della wiki — sotto «Operazioni», dopo ingest/query/lint

### 4. Sync M365 (acquisizione da Teams, OneNote, OneDrive)

Quando l'umano chiede di sincronizzare da Microsoft 365
(eventualmente con un filtro, es. «solo il team Atlas»):

1. Lista i team con list-joined-teams; applica il filtro se presente.
2. Per ogni team: elenca canali, poi messaggi degli ultimi 7 giorni.
   - Salta i messaggi già processati (confronta timestamp con ultimo sync nel log).
   - Scrivi in raw/teams/<team>-<canale>.md.
3. Per OneNote: elenca notebook, sezioni, pagine nuove.
   - Scrivi in raw/onenote/<notebook>-<pagina>.md.
4. Per OneDrive: elenca file nuovi in cartelle condivise.
   - Scarica .docx, converti in markdown, scrivi in raw/onedrive/<file>.md.
5. Appendi una riga a log.md (tipo: sync-m365).
6. Riepiloga: «Processati X messaggi, Y pagine, Z file. Procedo con l'ingest?»

8.3 Retrieval live via MCP

L'ingest porta nella wiki solo la conoscenza stabile — ciò che è stato selezionato e canonicalizzato. Per domande su contenuto transitorio (es. «cosa si è detto ieri su Teams riguardo al modulo auth?»), Claude può chiamare i tool MCP direttamente in tempo reale, senza aspettare l'ingest. La wiki resta per la conoscenza consolidata; Teams/OneNote per il flusso vivo.

8.4 Nella roadmap

L'integrazione M365 è la Fase 2 della roadmap: si configura il server MCP in .mcp.json e si aggiunge l'operazione sync-m365 al CLAUDE.md. Il grosso del lavoro è definire i filtri (quali team/canali/notebook sono rilevanti) per evitare rumore. Una volta a regime, la sincronizzazione si chiede in linguaggio naturale («sincronizza il team Atlas») e prepara i nuovi contenuti per l'ingest standard.

8.5 Sicurezza con account Anthropic condiviso

In Sistec le licenze Claude sono condivise: più persone usano lo stesso account Anthropic. Questo ha implicazioni profonde su dove e come vengono conservati i token di accesso ai servizi Microsoft 365, a seconda della superficie di Claude utilizzata.

Il problema non si pone con Claude Code o con i local MCP server configurati in Cowork via Settings > Developer Tools > MCP: in entrambi i casi i token risiedono nel credential store del PC locale. I colleghi su altri computer non hanno accesso.

Nel contesto della wiki-LLM, lo scenario pianificato usa @softeria/ms-365-mcp-server come MCP server locale (npx via stdio), non come connector Cowork built-in. Questo è il modello sicuro con account condiviso: il token OAuth di Microsoft resta nel credential store di ogni operatore, configurato per il proprio account M365 aziendale. I colleghi vedono solo i propri dati.

Per approfondimento: la documentazione ufficiale Anthropic conferma che i token dei connector sono memorizzati nei server Anthropic ("Anthropic stores encrypted access tokens and refresh tokens" — Authentication for connectors), e il modello di autorizzazione prevede che ogni utente su piani Team/Enterprise autorizzi individualmente i propri servizi ("each person still needs to authenticate individually before they can use it" — Use connectors). Su un account condiviso (Pro/Max) questa separazione non esiste.

• Adozione Claude & Claude Code in Sistec — il documento principale: ciclo agentico, contesto, prompt, skill, CLAUDE.md, condivisione
• LLM-wiki di Karpathy — il gist ufficiale che definisce il pattern
• Documentazione ufficiale Claude Code — la directory .claude
• @softeria/ms-365-mcp-server — MCP server per Microsoft 365 via Graph API
• Authentication for connectors — documentazione ufficiale Anthropic su OAuth e token dei connector
• Use connectors — guida ufficiale Anthropic su autorizzazione connector per Team/Enterprise
• sistec-llm-wiki — demo funzionante del pattern in Sistec
• openspec — pattern spec-first per la documentazione delle decisioni nei progetti
• graphify (sito · github) — la mappa del singolo progetto di codice: knowledge graph per-progetto in graphify-out/