r2-write-mint-via-workflow: federated dispatch job, operator grant cells, pin PR

[briansrls]

What this does

Makes the R2 object-write mint executable from a dispatched workflow job under the run's own federated GCP identity, so the operator's part is (a) creating one empty secret and converging the IAM cells from their own gcloud session and (b) clicking Run workflow. The authoritative roster of those cells is gunbc.cloudflare.r2_mint_secret_access, not this body — see the Update section at the end for the current ceremony.

A — the token source is selected, not spelled

gunbc.auth.access_token_source has carried three realizers of the access ensure for some time, and no entry point in the tree could reach more than one of them, because every entry chose its arm by construction: read_supplied_access_token() then OperatorSuppliedToken, spelled at eight call sites. An arm chosen at the call site is a binding, not a selection — so a workflow run and a workstation run of the same entry were two different programs, and only one of them existed. That is why the only executed precedent (#10947, the read mint) was an operator pasting a 1-hour ya29 token into a session.

• The realizer of the OperatorSuppliedToken arm (read_supplied_access_token and friends) moves to the module that owns the arm. It was authored in gunbc.auth.gcp_secret_access, whose own annotation said it "realizes the OperatorSuppliedToken arm, which gunbc.auth.access_token_source already carries" — a realizer one module away from the coproduct it inhabits, which is what made the selection unauthorable. Importers are rewired; no name changes.
• New: select_access_token_source() — one fold. WIF_ACCESS_TOKEN present ⇒ WorkloadIdentityToken; otherwise GUNBC_GCP_ACCESS_TOKEN_FILE ⇒ OperatorSuppliedToken; otherwise a refusal naming both. The workload arm wins on presence, not success: if the variable is present and empty the run refuses through that arm rather than reaching for an operator file. A fallback there would be the absorbing fallback §5 names — a broken federation silently answered by whatever else happened to be on the runner. GcloudPrintToken is deliberately unreachable from the fold: it is an interactive authentication, and an unattended run must not block on a prompt it cannot answer.
• gunbc.cloudflare.r2_token_mint_run now resolves one identity per run and uses it for the bootstrap read and its own Secret Manager writes.
• gunbc.auth.secret_ref_credential gains fetch_secret_ref_credential_with_token; fetch_secret_ref_credential is now a wrapper over it. This exists to avoid a meaning fork (§3): the mint needs the token after the read, and the previous shape would have forced a workload-federated token through an arm spelled OperatorSuppliedToken — one spelling carrying two materially different identities, with the receipts naming the wrong one.

B — two dispatch-only modes on the workflow that already exists

The brief asked for one workflow_dispatch job. This adds two modes to fleet-converge instead, and that is a deliberate, better-on-the-merits departure: fleet-converge is already dispatch-only, already pinned to a self-hosted arm64 runner, already carries the google-github-actions/auth@v2 step that federates to fleet-cloud-convergence@gunbai-secrets.iam.gserviceaccount.com with id-token: write, and already downloads CI-verified release bins rather than building gunbc on the runner — strictly better evidence than a build. A new job would be a standing claim on a paid runner plus a new emission to enrol; a mode is neither. No hand-written YAML: .github/workflows/fleet-converge.yml is regenerated from gunbc.fleet_converge_workflow, which is already in the generated-artifact roster, so drift is already gated.

The operator signed off on a dispatch-only addition for this purpose on 2026-09-12.

• r2_mint_preflight → gunbc.cloudflare.r2_permission_group_observe observe_account_permission_groups_wet
• r2_object_write_mint → gunbc.cloudflare.r2_token_mint_run run_object_write

E — reachability is observed, and that is why the preflight is separate

AccountTokens.Create is non-idempotent and returns its value exactly once. Observing runner reachability by attempting the mint would mean learning that the runner cannot reach Secret Manager only after a live credential exists on the account with nobody holding it. The preflight reads the pinned bootstrap version from secretmanager.googleapis.com and lists the account's permission groups at api.cloudflare.com — both hosts the mint depends on, no mutation — so it can be dispatched freely and repeatedly.

It is also the vehicle for the discriminating red: dispatched before the grant it refuses typed and located (THE BOOTSTRAP TOKEN COULD NOT BE READ: ...) with nothing spent.

(The earlier curl 35 TLS failure was from a session container to *.r2.cloudflarestorage.com and concerns fetch_absent, a different host and a different operation. Not conflated here.)

While making the preflight an entry, observe_account_permission_groups gained a typed standing (PermissionGroupListing). An earlier draft decided success by testing the returned String for a "NO "/"THE " prefix — a postcondition keyed to a phrase, green the moment someone improves the wording. The refusal is an arm now; the String entry is kept as its rendering.

C — the grants, as cells

New gunbc.cloudflare.r2_mint_secret_access, following gunbc.spark.secret_access_ensure: each cell is derived from the effect that needs it, not from a role someone thought would be enough.

secret	role	why
cloudflare-account-api-token-bootstrap	roles/secretmanager.secretAccessor	r2_mint_bootstrap reads the pinned v1
cloudflare-r2-origin-write-token	roles/secretmanager.secretVersionAdder	add_initial_version writes the minted value
cloudflare-r2-origin-write-token	roles/secretmanager.secretAccessor	add_initial_version reads that exact version back to compare bytes — the only part of the write Secret Manager guarantees, so it is a requirement of the write, not a convenience

Operator runs, from their own gcloud session (these authenticate as the human, per no_principal_can_both_grant_and_read — the control plane that may call setIamPolicy is deliberately not the workload):

gunbc run --source-root dag --source-root src/v2 \
  --entry dag/gunbc/cloudflare/r2_mint_secret_access.dag \
  --function r2_mint_bootstrap_read_access_converge
# then r2_mint_write_version_add_access_converge, then r2_mint_write_readback_access_converge

Which identity, and why not a dedicated one. gunbc.auth.github_gcp_federation says a federating domain supplies its own SA, which argues for a least-privilege SA of the mint's own. This reuses fleet-cloud-convergence@ anyway, for a structural reason rather than convenience: gunbc.auth.gcp_secret_access resolves the granted member from fleet_cloud_principal_standing() and refuses when it cannot name its subject, so the member of every cell this ensure can write is the convergence principal. A dedicated SA is not a different row, it is a different ensure — member would have to become a parameter, and a second federated principal would need provisioning and pool-binding by an operator ceremony strictly larger than the one this lane exists to shrink. The least privilege available today is therefore per-secret: one secret and one role per cell, nothing project-wide. Next rung is the dedicated SA, triggered by grant member becoming a parameter.

No user-managed service-account key, no token in GitHub secrets, no token as a workflow input. The only credential either step carries is the short-lived access token the WIF step mints for that run, read in-process rather than interpolated into a command line (the argv exposure gunbc.credential_argv_exposure measures).

OPEN — the container create is not expressible as a cell, and it is a decision, not an oversight

store_minted_token calls create_secret_for_attempt → gcp.SecretManager.CreateSecret before add_initial_version. secretmanager.secrets.create is a project-level permission; SecretAccessGrant is one secret + one role + one condition, and a per-secret cell cannot be written for a secret that does not exist. The read mint never hit this because the operator's own identity carried project admin.

Both resolutions have a real cost and the choice is not mine:

• A — operator pre-creates the empty cloudflare-r2-origin-write-token, and create_secret_for_attempt is fixed to treat ALREADY_EXISTS as converged. Keeps least privilege. Needs the actuator change first: today an existing container makes CreateSecret answer 409 → SecretCreationRefused after AccountTokens.Create has already minted a token whose value is returned once — a token-loss hazard, not merely a failed run.
• B — project-level roles/secretmanager.admin on fleet-cloud-convergence@. No code change, but gives the workflow identity create/delete over every secret in gunbai-secrets.

Escalated to royal-eagle-761 with A recommended. Do not dispatch r2_object_write_mint until this is settled — r2_mint_preflight is safe to dispatch now and is the evidence that matters first.

Evidence

• Every touched closure compiles with 0 blocking errors (gunbc compile --target dag, per entry): the mint, the grant module, ci_spec, fleet_converge_workflow, secret_access_ensure, org_actions_converge, both printer runs, the fabric-m0 probe, secret_access_admission, r2_permission_group_observe.
• .github/workflows/fleet-converge.yml regenerated from its authority (generated_artifact_gate main_wet_one); the diff is +40/−1, exactly the two modes and their four steps.
• Discriminating red (pending dispatch): r2_mint_preflight before the grants must refuse THE BOOTSTRAP TOKEN COULD NOT BE READ: ... with no AccountTokens.Create issued.
• Positive control (pending): the executed mint after the grants.
• Regression control (pending the follow-up pin PR): THE ORIGIN ALREADY PINS THIS CREDENTIAL, which mint_origin_token_and_store already refuses on.

The mint was not executed from this session.

Landing

Under the public-dag/ landing freeze until fierce-lark-661's release notice. Pushed for green; not asking for a merge.

🤖 Generated with Claude Code

https://claude.ai/code/session_015R9M9cY4iaqsqeaSDpT7g1

---

Update (2026-09-13) — the OPEN item is resolved, and it turned into a failure-mode row

Operator ruling: option A, with a sharpening that moves where the fix goes. Option B (project-level roles/secretmanager.admin) is refused on the estate's own design — gunbc.auth.gcp_secret_access exists precisely so no workflow identity holds project-wide create/delete.

The sharpening matters: under the federated identity the actuator must not call CreateSecret at all. Mapping a 409 after the Create to "container present" would have left the irreversible effect ahead of the check, which is the bug, not a fix for it.

What changed

• R2MintPreconditions gains R2MintCustodyContainerAbsent { intervention }, decided by a readonly GetSecret of the custody container inside the same ladder as every other precondition — so it is decided before cloudflare.AccountTokens.Create, not after it. classify_r2_mint stays pure and takes the observed container standing as a parameter.
• store_minted_token is AddVersion-only. The CreateSecret call is gone.
• gunbc.secret_provision_actuator gains ObservedSecretContainer (a sole_constructor seal minted only where the GET's returned resource named the requested project and secret — the same whole-resource comparison, since a suffix match once accepted another project's identically-named secret) and version_add_capability_for_observed_container, which derives the existing CreatedSecretForAttempt once a real snapshot exists. The observation seal deliberately carries no snapshot: the container is confirmed long before any credential exists, so a producer shaped like create_secret_for_attempt could only be called by inventing one — and an invented snapshot inside a seal is worse than no seal.
• The container-absent refusal carries completion_evidence: DischargedAt(observe_r2_mint_custody_container) — unlike its two neighbours in r2_origin, this ceremony has a real discharge site: the GET that raises it is also the check that answers it.
• A fourth grant cell, and it is the one an author would most easily omit: the container GET needs secretmanager.secrets.get, which secretAccessor does not carry (accessor is about a version's payload). roles/secretmanager.viewer on the write secret is now its own cell, and the witness asserts get.role != back.role so collapsing the two goes red.

Reordering, stated plainly: the access token is now resolved before the precondition ladder, because the container precondition is an observation and needs the run's identity to be decidable at all. The cost is that a run with no credential reports that first rather than the account/custody gap; the benefit is that the one check whose absence could burn a non-idempotent Create is inside the ladder.

The operator ceremony is now four steps, and the order matters (a cell cannot be bound to a secret that is not there):

gcloud secrets create cloudflare-r2-origin-write-token --project gunbai-secrets --replication-policy automatic

gunbc run --source-root dag --source-root src/v2 \
  --entry dag/gunbc/cloudflare/r2_mint_secret_access.dag --function r2_mint_bootstrap_read_access_converge
# then r2_mint_write_container_read_access_converge
# then r2_mint_write_version_add_access_converge
# then r2_mint_write_readback_access_converge

secret	role	effect that needs it
cloudflare-account-api-token-bootstrap	secretAccessor	r2_mint_bootstrap reads the pinned v1
cloudflare-r2-origin-write-token	viewer	the precondition GetSecret, before the Create
cloudflare-r2-origin-write-token	secretVersionAdder	add_initial_version writes the minted value
cloudflare-r2-origin-write-token	secretAccessor	the exact-version readback that write is only trusted on

Filed as a class, per the ruling — not left in this PR body: gunbc.recurring_failure_mode.a_precondition_check_sits_downstream_of_the_irreversible_effect. It is the dual of gunbc#10739's "fabrication downstream of the check" (there the check is correctly positioned and something false flows past it; here nothing is fabricated, the refusal is honest, and it arrives too late), so it is a sibling row rather than a receipt on that one. The discriminating fact is why it survived its one execution: #10947 ran green because the operator's identity held project-wide secrets.create, and a green execution under the most privileged available identity is the weakest evidence an ordering claim can have — privilege is exactly the condition under which a check's position stops mattering. Ceiling is structurally guaranteed: readonly on the service declarations and secret_manager_effect_required_permissions are both modelled, so "a readonly effect, or one whose permissions are unestablished, reachable after a non-idempotent mutation" is derivable rather than reviewable.

The escalation is retracted.

Review 64860 (dashboard-only, REQUEST_CHANGES) — all three addressed

1. r2_mint_gcp_access_token / permission_group_observe_access_token were the same fold twice. Correct, and it was this PR's own thesis unapplied one level up. The composition now lives once, at the least common ancestor: gunbc.auth.access_token_source resolve_access_token(), returning the existing AccessTokenResolution rather than a new coproduct, since an unavailable source is a refused ensure from where a caller stands. Both wrapper types are deleted.
2. r2_mint_preflight_receipt_path re-spelled twice. Correct — the diff argued the point against itself. ci_spec and fleet_converge_workflow now import the symbol, matching the existing host_reset_return_receipt_path / spark_apply_receipt_path form.
3. No consumer for the grant module. Correct. dag/test/claim/r2_mint_secret_access_witness_test.dag is enrolled, following the cited spark_secret_access_ensure_witness_test precedent — it asserts the targets join to the r2_origin declarations rather than being re-spelled, the role of each cell against the effect that needs it, and that no cell is conditioned. The converge entries themselves stay operator-invoked with no CI route, exactly as spark_secret_access_converge is: the control plane that may call setIamPolicy is deliberately not the workload.

---

Twin check against enforcement_gate_positioned_after_the_effect_it_guards — sibling, kept separate

Checked before landing, at royal-eagle-761's request, against that row's own recognition rule. Verdict: genuinely a sibling, not a twin. The new row now cites it in its distinguishing facts so a reader can tell them apart, and the landed row is left untouched.

• The landed row: a refusal is computed before the effect and the path fails to branch on it. The verdict is in hand, correct, and only ever read at serialization time — so the run changes the world and then accurately reports that it should not have.
• This row: no verdict exists at the moment of the irreversible effect, because the operation that would produce it is sequenced after. Every branch is present and correct at its own site; r2_token_mint_run did refuse honestly when CreateSecret failed — it refused about a token that had already been minted.
• Opposite remedies: branch on a value you already have, versus hoist an observation you never took and delete a write.

The test that makes this load-bearing rather than taxonomic is the landed row's own next-rung trigger. That trigger is an effect-ordering reader refusing any path that reaches a declared irreversible operation without first branching on the guard naming it. Run it against this defect and it passes clean: no guard named cloudflare.AccountTokens.Create, and the CreateSecret refusal that did exist named CreateSecret. A capability that fully closes that class leaves this one untouched — so merging the rows would retire this one behind a wall that cannot see it.

The axis the two share is already named in the landed row's boundary against declared_refusal_unreachable_from_its_own_constructor ("there the arm is never reached; here it is reached, and reached too late"). This is the third point on it: the arm is reached, on time relative to its own operation, and that operation is itself the thing sequenced too late.

---

Review 64955 (dashboard-only, REQUEST_CHANGES) — fixed

The finding is right, and it landed in the worst possible file to get wrong: r2_mint_secret_access said "two secrets, three cells" and "the three converges" above four grant functions and four converge entries. The count went stale the moment I added the viewer cell — the cell the same file calls the one an author would most easily omit.

The fix is not 3 → 4. §4c says an annotation "must not restate what the declaration structurally says," and a count is exactly that restatement — it is the part that rots, and it rots worst in the one module whose purpose is to replace an operator's memory of which bindings are required. So the counts are removed, not corrected: the prose now says "one secret and one role per cell" and "every converge entry in this module, one per cell," and points at the declarations and at test.claim.r2_mint_secret_access_witness_test, which asserts each cell against the effect that needs it. The annotation keeps a short receipt of the stale-count incident as rationale, since that is the irreducible part §4c does admit.

Two stale counts in this PR body are corrected the same way. The operator-facing ceremony is the four-step block in the Update section above, and the module is authoritative over both.

— sent from smart-otter-889

---

Landing sequence, admission standing, and the follow-up

The src/v1 edit is admitted as a consumed ledger entry, not an escape hatch. gunbc.v1_maintenance_standing classes a diff over admission rosters as MaintenanceRefusal::NewEscapeHatchOrAdmissionRow, and that class dominates purpose admission — so this PR's fifteen rows were refused at disposition until the standing was asked to rule on the class itself. It has: a NAMESPACE_TRANSITION_ADMISSIONS row is a consumed ledger entry, provided (1) its deletion follow-up is authored before the carrying PR is enqueued and (2) it lands so the rows are gone from main. The distinguishing property is transience with a consumption trigger — a row adjudicates one measured delta by exact identity and is consumed by the merge; it does not exempt. Adjudicated by fierce-lark-661; the receipt row lands in gunbc.v1_maintenance_standing via eager-raven-113's tree, and this body cites that adjudication until the row is on main.

Condition (1) is satisfied: #11259 (draft) deletes all fifteen rows and is open now, before enqueue. It must land immediately after this PR.

PURPOSE admission for the src/v1 edit (gunbc.v1_maintenance_standing v1_seed_standing): the only src/v1 change here is fifteen rows in the namespace-wave admission roster — the gate that admits .dag namespace motion into the required lane — so it serves the v2 self-host program by letting a substrate relocation land, and adds no capability to v1 for its own sake.

Why the relocation was not simply dropped. Reaching the WorkloadIdentityToken arm without moving symbols is feasible — the selection fold can live in gcp_secret_access with zero rows — and it was explicitly rejected: dodging the roster to avoid writing rows is DESIGN §5's workaround, the author-side absorbing fallback that routes around the substrate rather than root-causing it. The layer defect it would have preserved (a run's credential selection owned by the grant-ensure module) is the thing this PR exists to remove.

Ordering against gunbc#11240. That PR deleted the same two consumed gunbc#11156 rows this branch had also deleted. It landed first (6e70be2514), and this branch has since merged main: this PR's copy of that deletion and its dissolution receipt are dropped — one receipt per consumption event, and #11240 carries it — leaving only the fifteen relocation rows and their own DISSOLVE-ON.

---

Consumed-row credit. This branch retires the gunbc#11193 admission row it inherited from #11347. gunbc#11356 is the canonical owner of that deletion — this is the same deletion, taken here because the namespace-wave roster charges a consumed row to whoever touches it next, and identical deletions merge cleanly when #11356 lands.

[gunbai-bot]

Re review 64903 (dashboard-only, REQUEST_CHANGES, /api/reviews/64903/artifacts/stdout.log).

The finding was right, and it was already fixed at the head that landed two minutes after that review started. 64903 ran against 22e1972c41; the fix for it went in with 1bb574cddc as part of the response to review 64860, which raised the same item. On the current head the string appears exactly once in the tree:

dag/gunbc/cloudflare/r2_permission_group_observe.dag:279:data r2_mint_preflight_receipt_path: String = "target/r2-mint-preflight-permission-groups.txt"

ci_spec and fleet_converge_workflow import and consume that symbol.

The prior debt named in the same finding is now fixed too, in dbc510b4b5. The review was explicit that app_control_plane_receipt_path is "prior debt of the same class, not a licence" — correct on both halves, and since the fork lives in the two files this PR already edits, leaving it would have meant shipping a consolidated instance sitting beside an identical unconsolidated one, which is the worst of the three states to leave a reader in. Collapsed:

• app_control_plane_receipt_path — was 3 spellings (app_control_plane_converge.dag:84, ci_spec.dag:1738, fleet_converge_workflow.dag:1183), now 1.
• org_actions_validation_receipt_path — was 2 (org_actions_converge.dag:46, fleet_converge_workflow.dag:1201), now 1. Not named in the review; same class, same file, found while fixing the first.

Evidence that this changed nothing a consumer sees: .github/workflows/fleet-converge.yml regenerated from its authority after the change is byte-identical (75783 bytes, empty diff). That is the property a pure §3 consolidation should have — the fact was already one fact, it just had three names.

— sent from smart-otter-889

[gunbai-bot]

Re review 65039 (APPROVE, dashboard-only, /api/reviews/65039/artifacts/stdout.log) — the non-blocking observation is correct and I am deliberately not fixing it here.

The observation: dag/test/claim/r2_mint_secret_access_witness_test.dag:33 re-spells the convergence SA email that gunbc.gcp.gcp_estate_observation fleet_cloud_convergence_sa_email already owns. That is the same §3 class I fixed twice in this PR (the preflight receipt path, then the two pre-existing ones), so I am not going to pretend it is a different thing — it is one more literal where a modeled value exists, and it should be joined to the declaration.

Why it is not in this PR anyway: the trade is bad right now. This branch has produced eight CI starts and zero receipts, because every review fix superseded the run in flight through the concurrency group. Run 34733017987 is currently in flight on this head, which is also the head this approval is bound to. Pushing a two-line change to a witness fixture input would cancel that run and stale the approval, and I would be back to having no CI evidence at all — for a literal that, as the review notes, no assertion depends on being current.

So: it lands as a follow-up, not as a ninth supersede. Recorded here rather than left in a review artifact so it does not get lost.

One thing worth stating precisely, since it affects how the follow-up should be written: the email at that line is the member argument to secret_access_desired_cells, not an assertion about the estate. The right repair is to import fleet_cloud_convergence_sa_email and build the member from it the way grant_member does — which makes the test say something true about the principal that will actually be bound. Substituting an obviously-synthetic fixture member would also remove the fork but would weaken what the test claims. The current state is the worst of the three: it reads like a join and is a copy.

— sent from smart-otter-889

[gunbai-bot]

Migration recipe from #11345 (directory-is-membership cut of NAMESPACE_TRANSITION_ADMISSIONS).

If this PR still appends const rows:

1. One file per row at dag/gunbc/namespace/transition_admission/<stem>.dag. Stem is the relocation identity in stem form, not the owner PR number.
2. TransitionAdmission { label, subject, disposition } with decl_ref for enclosing and expected_candidates.
3. Drop the Rust hunk. Do not reintroduce a list.

#11220 already merged; this note is for any remaining const hunk on this branch.