Confini e flussi

Autorità e sistemi di record

flowchart TB
    github["GitHub Issues e Project<br/>scope, ordine ed evidenza"]
    repo["Repository e Brain<br/>architettura, codice e documentazione"]
    d1["Cloudflare D1<br/>stato editoriale e operativo runtime"]
    workers["Cloudflare Workers<br/>esecuzione applicativa"]
    provider["Provider esterni<br/>capability specializzate"]
    github -->|"autorizza lavoro"| repo
    repo -->|"distribuisce contratti"| workers
    workers -->|"legge e scrive stato"| d1
    workers -->|"richieste limitate"| provider
    provider -.->|"evidenza sanitizzata"| workers

GitHub non sostituisce D1, D1 non sostituisce il repository e un provider non sostituisce l'autorità applicativa. I custom field del Project sono una proiezione di pianificazione; scope e acceptance criteria restano nell'Issue.

Flusso dati applicazione, D1 e provider

flowchart LR
    admin["Admin autenticato"] --> api["API Worker"]
    api --> d1["D1"]
    d1 -->|"Topic e Knowledge Asset accettati"| api
    api --> queue["Cloudflare Queues"]
    queue --> ai["Provider AI"]
    ai -->|"candidate JSON"| api
    api -->|"draft valido"| d1
    api --> mailjet["Mailjet"]
    mailjet -->|"evidenza provider sanitizzata"| api
    api --> github["GitHub App"]
    github --> actions["GitHub Actions"]
    actions --> workers["Worker versionati"]

Il diagramma non implica una catena automatica. AI, pubblicazione, Campaign Draft, scheduling, delivery e deployment richiedono transizioni e autorità separate.

Matrice sintetica

Sistema	Possiede	Non possiede
GitHub Issues/Project	lavoro operativo ed evidenza	contenuto editoriale runtime
Repository/Brain	architettura, codice, ADR e documentazione	stato operativo live
D1	contenuto e workflow runtime	configurazione provider
Workers	esecuzione e policy applicativa	consenso destinatari
Access	autenticazione Admin	permessi applicativi
GitHub App/Actions	capability e run repository-scoped	scelta libera di ref o workflow
Mailjet	contatti, consenso e delivery destinatari	Issue Content canonico
Provider AI	output candidato	approvazione o pubblicazione
Pages	hosting statico del portale	runtime applicativo

Regola di evidenza

Architecture Coffee conserva soltanto evidenza necessaria e sanitizzata: identificatori operativi bounded, stati, tempi, commit e codici di errore allowlisted. Non conserva in Issues o documentazione token, assertion, prompt grezzi, payload provider, indirizzi destinatario o dati di console privati.