Una funzionalità di SystemDox
Il registro di ogni decisione presa dai tuoi agenti IA
I tuoi agenti IA redigono ADR, spec e piani. SystemDox Pages pubblica l'albero docs di un repository git come sito: pubblico sul tuo dominio, o interno con accesso verificato all'edge. Ogni record di decisione mostra il suo stato; ogni pagina indica il commit dell'ultima modifica.
Tracciare
Ogni decisione ha uno stato e un commit
I segnali che servono a chi legge sono sulla pagina. Lo stato viene letto dall'intestazione del documento, il commit da git, entrambi in fase di build. Sul sito niente è mantenuto a mano.
Badge di Status
L'intestazione dei metadati di un documento diventa un elenco e lo Status un badge: Proposed, Accepted, Superseded. Chi legge vede subito se una decisione è ancora valida. Il file sorgente non viene toccato: è una resa applicata in fase di build.
Footer di provenienza
Ogni pagina indica il commit dell'ultima modifica del documento, con data e oggetto, e il commit da cui è stato costruito il sito. Sono stampati per chiunque legga e rimandano a GitHub per chi ha accesso al repository: sai sempre quale versione stai leggendo.
Ricostruito a ogni merge
Il tuo repository resta l’unica fonte. Ogni build ne fa il checkout al commit che pubblica e lo registra, così il sito è al massimo un merge indietro e non diventa mai un secondo posto in cui scrivere.
Consultare
Pubblicato in una forma che tutta l'organizzazione può usare
Il repository è dove lavorano gli ingegneri. Il sito è dove leggono tutti gli altri. SystemDox Pages tiene il primo come fonte di verità e costruisce il secondo a partire da esso.
Ricerca
Ricerca full-text su tutto il sito, costruita al momento della pubblicazione e servita come file statici. Una decisione si trova per le parole che contiene, non perché sai in quale cartella sta.
Navigazione che segue il repository
La navigazione del sito rispecchia le cartelle dell'albero docs. Sposti un file nel repository e il sito lo segue al merge successivo. Non c'è una seconda struttura da mantenere.
Diagrammi renderizzati
I diagrammi mermaid nel tuo Markdown vengono renderizzati sulla pagina: uno schema di architettura si legge come immagine e resta un file di testo nel repository.
Pubblicare
Pubblico o interno, lo decide lo stack
Un sito è di un solo tipo per tutta la vita del suo stack. Non c'è un interruttore né uno stack misto: una decisione privata non ha alcuna strada verso una pagina pubblica.
Siti pubblici
L'albero docs di un repository pubblico diventa un sito pubblico sul tuo dominio, servito come pagine statiche da uno stack che contiene solo contenuti pubblici. Nessun gate da configurare, perché non c'è nulla di privato a portata.
Siti interni
L'albero docs di un repository privato diventa un sito che solo le tue persone possono aprire. Ogni richiesta viene verificata all'edge con un login, prima di qualsiasi cache. Uno stack nasce interno e resta interno.
Il repository resta la fonte
SystemDox Pages pubblica da git e non scrive mai nel repository. Gli autori continuano a lavorare con pull request, review e merge. Se smetti di usarla, i tuoi file sono dove erano, nel repository, in markdown. Nessun passaggio di esportazione.
In produzione oggi
docs.puglieseweb.com è un sito pubblico pubblicato con SystemDox Pages: un albero di documentazione tecnica di oltre cinquecento pagine, ricostruito a ogni merge. La documentazione interna di puglieseweb, con decisioni, architettura, runbook e standard, gira su un sito interno con accesso verificato all'edge. La stessa funzionalità pubblica entrambi; lo stack decide chi può leggere.
Apri docs.puglieseweb.comSi acquista anche da sola
SystemDox Pages è una funzionalità di SystemDox e puoi acquistarla senza il resto. Porta un repository git con un albero docs e un dominio. Lo pubblichiamo come sito pubblico o interno, ricostruito a ogni merge. Capture, Build e la Knowledge Base possono arrivare dopo, o mai.
Vedi i prezziSystemDox Pages è un prodotto separato?
No. SystemDox Pages è una funzionalità di SystemDox. Si acquista anche da sola, quindi puoi pubblicare la documentazione di un repository senza usare Capture, Build o la Knowledge Base, ma resta una funzionalità di un unico prodotto, con prezzo su richiesta.
Come so quale versione di una pagina sto leggendo?
Ogni pagina stampa un footer di provenienza: il commit dell'ultima modifica del documento, con data e oggetto, e il commit da cui è stato costruito il sito, ciascuno collegato a GitHub per chi ha accesso al repository. Sono letti dal repository in fase di build, quindi una pagina non può dichiararsi più recente di quanto sia. Il sito viene ricostruito a ogni merge.
Cosa succede alla mia documentazione se smetto?
Nulla. I tuoi file restano nel repository in markdown, esattamente come li hai scritti, con git come storia. Il sito è una build del repository, mai un secondo posto in cui scrivere: se smetti, la tua documentazione è esattamente dove era già.
Pronto a trasformare la tua documentazione?
Inizia a catturare decisioni architetturali, note riunione e design tecnici con la tua voce.