Cloudflare Pages

A cosa serve

Cloudflare Pages ospita il sito MkDocs statico del portale italiano. Il progetto dedicato architecture-coffee-docs serve il dominio canonico https://docs.architecturecoffee.it e l'endpoint provider https://architecture-coffee-docs.pages.dev.

Componenti che lo usano

Solo la documentazione generata da docs/portal, mkdocs.yml e dal comando strict build. Il progetto usa il repository frappacchio/architecture-coffee, il branch di produzione main e l'output site/. API Worker, Frontend applicativo, D1, Queue e provider non sono dipendenze runtime del portale.

Dati e artefatti scambiati

Pages riceve un checkout del repository, installa dipendenze bloccate, esegue il comando strict build e pubblica l'output statico site/. Restituisce asset HTTPS ed evidenza di build e deployment. Il portale non riceve stato editoriale live, binding applicativi o credenziali applicative.

Autenticazione e autorizzazione

L'integrazione GitHub di Workers & Pages è limitata al repository previsto e la build appartiene al progetto Pages dedicato. Una modifica di configurazione, un deployment o un retry operativo, un cambio dominio o la rimozione del portale richiedono un Issue operativo separato e l'autorizzazione di Fra. Cloudflare Access non protegge il portale pubblico.

Cosa possiede il provider

Cloudflare possiede il progetto Pages, build e deployment provider, endpoint *.pages.dev, HTTPS e associazione del custom domain documentale.

Cosa possiede Architecture Coffee

Il repository possiede Markdown italiano, navigazione, dipendenze, validazione, Mermaid locale e comando build. GitHub CI resta l'autorità di validazione; Pages non modifica contenuto o governance.

Operazioni automatiche, manuali e protette

La CI GitHub costruisce e valida ma non distribuisce. Pages possiede la pubblicazione del sito attraverso la propria integrazione con il repository; un check verde o un commit disponibile non autorizzano azioni manuali sul provider. Configurazione, deployment o retry operativo, dominio e rimozione restano mutazioni protette con evidenza Issue-native.

Fallimenti e comportamento fail-closed

Build non strict, leak, permessi eccessivi, binding applicativo, domain conflict o revisione diversa da quella congelata bloccano la pubblicazione. Un deploy parziale non autorizza retry o modifica dei Worker applicativi.

Verifiche operative

npm run docs:build;
site/ ignorato e derivato;
navigazione, link, search e Mermaid;
assenza di segreti e chiamate API applicative;
SHA esatto del deployment;
HTTPS, dominio canonico, endpoint *.pages.dev e 404;
corrispondenza tra revisione repository e contenuto live.