Configurazione runtime e operazioni

La governance distingue configurazione, segreti, release ed effetti. Cloudflare è l'autorità unica per le variabili runtime operator-managed e per il materiale segreto dei Worker.

Al job scope GitHub Actions riceve soltanto le credenziali Cloudflare necessarie al deployment; il solo step smoke API può ricevere la coppia Public Site Access esistente dello stesso ambiente come input di test cifrato e GET-only.

I file Wrangler canonici dichiarano la configurazione repository-side deployable dei Worker. Non esiste una seconda projection di release.

wrangler.jsonc è l'unica configurazione repository-side deployable dell'API Worker.

apps/mcp/wrangler.jsonc è l'unica configurazione repository-side deployable dell'Editorial MCP Worker.

Classe	Esempi	Autorità e percorso
Configurazione runtime non-secret operator-managed	`EMAIL_CAMPAIGN_PROVIDER_MODE`, sender Mailjet, catalogo alias, list ID e provider reference	modifica diretta dell'operatore su Cloudflare, readback sanificato, nessuna Issue/PR/release/transizione Project
Materiale segreto	`MAILJET_API_KEY`, `MAILJET_API_SECRET`, `FEEDBACK_CAPABILITY_SECRET`	secret storage Cloudflare, rotazione diretta, valore mai registrato; la protezione è un controllo di confidenzialità e non un gate di workflow
Credenziale di test smoke-only	coppia Public Site Access esistente	copia cifrata nel GitHub Environment corrispondente, disponibile solo allo step smoke API; non è runtime Worker e non crea identity o capability
Configurazione Worker repository-owned	codice, compatibility, identity Worker, binding e configurazione deployable dichiarata nei Wrangler canonici	Issue/PR/CI e native Wrangler deploy da `wrangler.jsonc` o `apps/mcp/wrangler.jsonc`
Operazione ad effetto	migration D1, Worker deploy, Access policy, Queue topology, publish, prepare, schedule, deliver	intento esplicito, target e ordine bounded, idempotenza o single-flight dove applicabile, readback autorevole e nessun blind retry

Alias, list ID e provider reference non sono credenziali. Le viste API più ampie possono continuare a minimizzarne la rappresentazione per least disclosure; questa scelta di output non li riclassifica come secret e non introduce un gate.

Worker deployment e configurazione canonica

Il normale deploy usa direttamente Wrangler dai file canonici:

wrangler deploy --env <environment> --keep-vars

--keep-vars preserva le variabili remote omesse dalla configurazione Wrangler canonica.

I valori operator-managed che non appartengono al repository non devono essere duplicati in GitHub Environment, workflow o file repository soltanto per effettuare una release.

Una variabile o un binding dichiarato esplicitamente nel Wrangler environment selezionato è invece configurazione repository-owned deployable e viene gestito dal normale deploy.

Release script, workflow, file generati o projection temporanee non devono ricostruire, filtrare, whitelistare o sostituire parzialmente la configurazione deployable dei Worker.

Un binding valido aggiunto alla configurazione Wrangler canonica deve quindi fluire attraverso Development e Production senza richiedere una modifica parallela a un release projection layer.

Il normale percorso non usa:

wrangler versions upload;
custom Worker version-ID activation;
temporary Worker configuration projections;
binding whitelist release-specific;
previous-version upload state;
upload reuse state.

Separazione fra configurazione e autorità

La configurazione non autorizza un effetto.

La presenza di mode, sender, target, provider reference, binding o secret non autorizza automaticamente:

publication;
Campaign Draft preparation;
content upload;
scheduling;
delivery;
migration;
Worker deployment;
Queue mutation;
Access mutation;
provider mutation.

Ogni operazione ad effetto mantiene il proprio intento esplicito e il proprio confine operativo.

La validità di una capability viene verificata quando la capability è usata o da uno smoke che la esercita realmente. Configurazione assente o invalida fallisce localmente senza chiamare il provider quando il contratto della capability lo consente.

Il mode live-disabled è ritirato: non era un'autorizzazione affidabile ed è un valore invalido.

mock, dry-run e live descrivono soltanto il provider o il comportamento runtime da usare; non autorizzano preparazione, scheduling o delivery.

Gli attempt immutabili, le chiavi idempotenti, i lease single-flight e la riconciliazione degli esiti ambigui restano obbligatori dove previsti dal contratto dell'operazione.

Release ordinaria

Una normale release Worker reversibile non richiede una Issue operativa di rollout duplicata.

Fra's explicit Production intent plus the already-reviewed delivery scope is sufficient for the routine bounded release path. Non devono essere introdotte micro-autorizzazioni intermedie soltanto per ripetere scope già revisionato.

Development consuma un candidate main con CI verde e può essere rieseguito tramite workflow_dispatch senza parametri sul current main.

Production richiede workflow_dispatch esplicito e senza parametri su main. Il workflow congela autonomamente il candidate e richiede:

candidate appartenente alla history di main;
CI verde sullo stesso commit;
release Development verde sullo stesso commit;
Environment Production disponibile.

Semantic-version tag, previous Production release topology, Worker-version upload state, upload reuse e Development Queue-topology history non sono normali release gate.

La normale sequenza è:

D1
→ API deploy
→ API smoke
→ MCP deploy
→ MCP smoke
→ terminal result

Una normale recovery di un bug Production segue lo stesso percorso quando non aggiunge scope o rischio operativo distinto.

D1

Le migration repository sono append-only.

CI protegge le migration già pubblicate da:

modifica;
rename;
rimozione;
riordino.

Il normale apply remoto usa Wrangler nativo:

wrangler d1 migrations apply

Se il comando termina con successo, il release continua.

Se l'apply fallisce, viene eseguita una sola riconciliazione autorevole del migration ledger:

apply failure
→ authoritative ledger readback
   → converged: continue
   → pending or unknown: stop

Non viene eseguito un secondo apply automatico.

Non esistono nel normale percorso un migration release manifest separato, una release-plan reconstruction o una precedente Production release necessaria per decidere quali migration applicare.

Migration o data operation straordinarie, distruttive o con rischio materialmente distinto restano fuori dalla normale release.

Operazioni ad alto impatto

Una Issue operativa separata resta richiesta quando Production recovery o delivery aggiunge operazioni o rischio materialmente distinti, inclusi:

extraordinary D1 o data migration;
Access o security-policy change;
Queue topology o configuration change;
destructive action;
external-provider mutation oltre la normale Worker release;
ambiguous state che richiede recovery revisionata separatamente.

Questa separazione non trasforma ogni modifica di binding o configurazione Worker in un'operazione ad alto impatto: la normale configurazione deployable dichiarata nei Wrangler canonici appartiene al normale Worker release.

Runtime configuration e secret rotation

Le normali modifiche alla configurazione runtime operator-managed e le rotazioni dei secret sono operazioni dirette contro l'autorità Cloudflare.

Richiedono:

target esatto;
trattamento confidenziale per i secret;
readback autorevole;
nessuna esposizione del valore nei log o nel repository.

Non richiedono soltanto per governance:

Issue;
pull request;
Worker release;
Project transition;
secondo go/no-go.

Secret storage e redaction sono controlli di confidenzialità, non workflow gate.

Email configuration

Configurare Mailjet non autorizza Campaign Draft preparation, content upload, scheduling o delivery.

Email mode, sender, target aliases e provider/list references sono configurazione runtime non-secret operator-managed.

MAILJET_API_KEY e MAILJET_API_SECRET sono credenziali protette.

Il normale Worker release non confronta né autorizza la configurazione Mailjet. La readiness viene verificata al point-of-use o attraverso il preflight/smoke specifico della capability.

MCP deployment e client catalog

Il deployment dell'Editorial MCP Worker prova lo stato del server MCP.

Il tool catalog visibile a ChatGPT, Codex o a un plugin client è stato separato dal deployment del Worker e può essere cached.

Un server MCP correttamente deployato non implica automaticamente che un client abbia già aggiornato il proprio catalogo. Il refresh del client è un'operazione bounded separata e non deve essere incorporata nel normale Worker deployment.

Delta esterno delle Project Instructions

Dopo il merge, il delta minimo da applicare alle Project Instructions è il seguente. Questo testo è una proposta verificabile; il repository non modifica la configurazione esterna del Project.

Native GitHub Issue state is authoritative for Issue state and completion.
Project Status is a planning and selection projection only: it must remain
coherent with Issue-native state, but it never redefines an Issue and never acts
as a CI, build, deployment or Production authorization gate. Labels classify
work only and never encode workflow state.

Normal operator-owned runtime configuration changes and secret rotations are
direct provider operations. They require no Issue, pull request, release,
Project transition or second go/no-go. Protect and redact credential values and
perform authoritative readback.

Repository-root wrangler.jsonc is the sole repository-side deployable
configuration for the API Worker. apps/mcp/wrangler.jsonc is the sole
repository-side deployable configuration for the Editorial MCP Worker. Normal
Development and Production deployment uses native Wrangler directly from those
canonical files and must not reconstruct or partially project deployable
configuration through release-specific abstractions.

A normal reversible Worker release does not require a duplicate dedicated
operational rollout Issue merely to authorize deployment. Fra's explicit
Production intent plus the already-reviewed delivery scope is sufficient for
the routine bounded release path; do not introduce intermediate
micro-authorizations.

Development consumes a successful same-repository main CI candidate and may be
explicitly rerun through parameter-free manual intent on current main.
Production requires explicit parameter-free workflow_dispatch on main; the
workflow freezes the candidate internally and requires successful main CI plus
a successful Development release for the same commit.

Normal D1 migration uses append-only repository migrations and native Wrangler
apply. If apply fails, perform one authoritative migration-ledger
reconciliation and never blindly retry.

A confirmed Production bug does not require a separate rollout Issue when
recovery is only the normal reversible Worker release path.

A separate operational rollout Issue remains required when Production recovery
adds materially distinct operations or risk, including an extraordinary D1 or
data migration, an Access or security-policy change, a Queue topology or
configuration change, a destructive action, an external-provider mutation
beyond the ordinary release, or ambiguous state that requires separately
reviewed recovery.

Configuring Mailjet never authorizes campaign preparation, scheduling or
delivery. Each provider side effect requires the operator's explicit named
intent and remains separate from runtime configuration.

Secret redaction, frozen-candidate CI evidence, migration compatibility, staged
smoke, idempotency, single-flight protection and ambiguous-outcome
reconciliation remain mandatory.

MCP server deployment and client-visible tool-catalog refresh are distinct
states. A successful MCP Worker deployment does not itself prove that a
ChatGPT, Codex or plugin client has refreshed a cached tool catalog.