7.6 Common Stage Foundation — 9 November 2026

This is the operational boundary for preparing a common base before Jacopo and Lorenzo divide implementation of the next systems. Access has a working private stage path; Farm completed its first gated rollout and private Platform-to-Farm acceptance on 10 November. Acceptance of the entire common foundation is not complete. Console is not online and is not a prerequisite for the initial API handoff. Development remains local Docker. Production and product-client exposure are not activated by this work. The documented reciprocal PR review and separate stage release approval remain in place.

What the evidence supports

Area	Implemented or prepared	Applied / tested boundary
P0/P1 common delivery	Catalogs, trusted source-free release engine, cross-root contract checks, distinct identities and approval gates	Applied and exercised with Access on 7 November; migration-before-backend and private readiness succeeded
Shared telemetry	Process-unique Common Resource; app telemetry to Platform/Farm and opt-in proxy metrics to DB	Access traces, app metric and backend proxy metrics received on 7 November and again for the new revision on 9 November; temporary probes removed. Farm HTTP and SQL-proxy metrics plus one correlated application trace were received on 10 November; the second requested trace was not observed. See the Farm checkpoint, new kit-driven acceptance and earlier baseline
P2 Console CI	rust-slint-app code builds server/WASM with pinned Design/Common/Docs; Console is a stateless catalog system in Platform	Console/Design repository links and private builder resources applied. Local Console: 108 tests passed; Docker health/readiness/assets returned 200, API without IAP returned 401. Builder image publication, profile activation and Console cloud build/runtime acceptance remain separate steps
Operator command and kit	stage_release.py composes publisher, candidate and release preparation; operator_kit.py delivers selected contracts and matching tools; stage_recovery.py provides assisted inspection/retry	Ordinary Access release, direct reads, telemetry and publisher restart passed. The isolated SQL-free fixture passed a real failed-job retry with unchanged approved artifacts, private probes and cleanup. Lorenzo's ordinary first use checks his effective actions; a dedicated session is not a prerequisite. stage_release.py never approves implicitly; the dedicated approval command requires an explicit operator action and its preventive checks
P3 SQL component profiles	Explicit runtime / read_only enrollment, v3 baseline/verification runner, preserved Access v2 checksum and identities	Local PostgreSQL 17 positive/negative tests passed. Farm v3 baseline and enrollment applied; both identities passed private login/membership checks before and after migration, with the other six databases denied. Runtime DDL and migration-ledger access are denied
Independent Farm delivery	Same publisher, service-with-migration engine and operator kit; backend and migrator only	First approved rollout succeeded on 10 November, migration before backend. SQL checks, first-creation IAM closure, five S2S cases and cleanup passed; metrics and one correlated trace received. Migrator no-op succeeded under the stage operator identity, not a new Cloud Deploy rollout
P2 staff edge	Opt-in Net frontend and same-project app NEG/backend, IAP, TLS and explicit staff groups	Module/mock checks only; staff_edge = null leaves it disabled. Select an authorized group before activation; creating a new group is not required. No load balancer, public DNS or Console endpoint is implied
P3 event invocation	Module and stage integration for topics, authenticated push and scheduled Service/Job calls	Module validation and 23 mock tests passed; the stage suite passed 90 tests. event_catalog = {} leaves events inactive. No live consumer acceptance; application retry/idempotency and writable-component migration coordination remain unimplemented or unproved

The database topology remains six system databases (access, releases, news, ai_gateway, farm, moochat) plus retained legacy platform, on one sql-stage instance. Console owns no database. Reserving a database or identity is not activating its application or granting access to another system.

Earlier infrastructure checkpoint

The authorized plans from infra commit f485c7f36c14, merged through PR #24, were applied successfully. Bootstrap added 9 resources, updated 4 and destroyed none: seven builder resources, two Console/Design repository links and four trigger updates. Stage added 3 resources, updated/destroyed none: the Console service account, its application telemetry grant and scoped invocation of Access. Subsequent writer-identity plans reported no changes in either root.

At that checkpoint Developer Connect linked Access, Common, Docs, Design and Console. Farm was added on 10 November as described below. The affected triggers remain disabled for automatic events and require approval; applying Terraform started no application build or rollout. Access remained ready on access-backend-mw6qnqlk. No load balancer, group or new application workload was created. The builder registry/trigger exists, but its verified image digest still precedes Console profile activation. Edge and event enrollment remain disabled.

The local sanitized approved-plan and post-apply summaries record the commit, changes, successful applies and empty follow-up plans. The completed 7 November runtime/telemetry acceptance remains separate; preserving a ready revision is not a fresh business-operation or telemetry test. Keep full state, raw plans and credentials out of documentation.

The event integration uses separate Platform/Farm providers and exports event_contracts. Scheduler/IAP administration is granted to the Terraform stage apply identity only on an application project that explicitly declares schedules or staff backends. The empty defaults add no such grants; there is no folder-wide or production/development grant. Application invocation and staff access use their own scoped identities/groups, not these administration roles.

IAP accepts a configured authorized staff group; stage-access is not a technical requirement. For the initial Jacopo/Lorenzo stage Console access, temporarily reusing infra-admins@moonitoring.com is proposed. This is not approval or application of a new IAP grant, and it does not extend to production. No group was created. A dedicated access group becomes useful when testers need Console access without infrastructure administration: do not add them to infra-admins merely to reach Console. Review group membership and the service-scoped IAP grant before enabling the edge.

Operator IAM follow-up — applied 9 November

The earlier readback identified reliance on Jacopo's direct CI-project Owner access and missing group grants. The authorized correction in infra PR #25, commit b32ed7d8323e, was applied: six additions, no updates or destruction. It added the operator custom role and group binding, two Access service-account actAs bindings, rendered-artifact read access and the Cloud Build approver binding. The subsequent bootstrap writer plan reported no changes.

Responsibility	Installed boundary	Remaining verification
infra-admins: request publication/release	CI-project applicationOperator permits build creation/read and evidence access; actAs targets the Access publisher/release identities. Rendered-artifact reads are limited to the delivery/ prefix. Existing candidate-bucket and builder grants remain	Exercise the intended procedure as a group-only operator; do not infer success from Jacopo's Owner role
stage-release-admins: approve Cloud Build	roles/cloudbuild.builds.approver now applies independently of the disabled Terraform triggers	Test an actual intended approval under the group membership; enabling automatic triggers is unnecessary
stage-release-admins: approve Cloud Deploy	The existing scoped stage rollout approval is unchanged	Preserve this separate gate; Cloud Build approval does not authorize the rollout

The post-apply readback passed 11 checks: exact custom-role permissions, group bindings, the two service-account grants, the artifact-prefix condition and the five regional trigger identities/gates. All five inspected triggers in CI europe-west8 remain disabled for automatic events and require approval. This correction created no group or application workload and started no build, approval or deployment.

Permission scope matters: Cloud Build creation and approval operate at CI-project scope, not at a stage-named trigger boundary. cloudbuild.builds.create also permits trigger changes; the operator is a trusted infrastructure administrator, not a restricted release requester. The new actAs bindings target the declared service accounts, while any other inherited grants still matter. Before adding production builds, define and test the production approval boundary separately from stage approvals; the infrastructure administrator group remains shared as designed. Terraform currently rejects enable_prod_triggers alongside this operator IAM or configured stage approver groups. This guards the configured Terraform triggers, not every possible administrative API action; separate group names alone are insufficient isolation.

The readback inspected installed allow policies using Jacopo's account. It did not prove effective group-only access for Lorenzo, group propagation, nested membership, deny/PAB behavior or a complete operator-CLI run. This is a limit of that historical evidence, not a requirement to schedule a dedicated Lorenzo acceptance session. The team reports the same intended permissions and service visibility; record each operator's effective actions during normal first use, without equating visibility with every release permission. Preserve the stage Cloud Deploy gate and avoid broadening runtime/deployer permissions to resolve an operator issue.

Operator handoff and assisted recovery — applied 9 November

The portable operator_kit.py and stage_recovery.py helper are implemented and locally tested. Infra PR #26 supplied the handoff/recovery implementation, and PR #27 completed its compatibility checks. Current infra commit d5904b2e6824 passed 82 local Python tests. The kit validates selected contracts and matching tools without cloud access; its apply reference remains an infrastructure-owner attestation. Recovery inspects the intended target and declared workloads, then permits a checked retry of the exact failed Cloud Deploy job. It does not approve, ignore jobs, create a release or roll back a target.

The verified Terraform plans were applied successfully: two bootstrap additions and four stage additions, all IAM, without updates or destruction. Follow-up writer plans at d5904b2e6824 reported no changes in either root. These grants permit pipeline-scoped release/rollout/JobRun reads and retryJob, plus reads of existing declared Services, Jobs and their Executions. They do not grant runtime writes, new schema privileges, project-wide Operations access or production access. Readable workload configuration can contain literal environment values; secrets must remain referenced rather than embedded.

The real Access kit was produced from selected applied outputs at that infra commit, copied to an operator delivery directory and verified. Its artifact name is moonitoring-operator-kit-access-2026-11-09; manifest SHA-256 is 3017050e6ea3f06ccdcf9412a3287e340fbc4dd1e2b1d00ce2ec7a51a0be4de7. This verifies packaging and contract/tool consistency, not all live permissions. Distribute the kit and expected hash through the agreed company-controlled handoff; documentation does not publish its local workstation path.

Using jtedeschi@moonitoring.com without impersonation, Service read, Job read, Execution list and Execution read all succeeded after the apply. The observed Access revision remained access-backend-mw6qnqlk, with the previous successful migration execution access-migrate-24zpq; those observations are not a new release. They establish the tested direct reads for Jacopo, not complete group-only operation or Lorenzo's access.

Kit-driven Access acceptance — 9 November

Access PR #30, merged at 99f7c780e6a9, adds explicit Operation/Execution identifiers in migration diagnostics so an interrupted call can be reconciled. Its 14 offline delivery checks and 98 Rust tests passed. Local Compose built six images; eight components were running, three jobs exited with code 0, the backend's /ready and /health checks passed, and the local migration ledger contained 20 applied migrations. The test stack was cleaned up. The following cloud acceptance is separate from those local tests.

The new kit-driven stage rollout succeeded. Publisher build 31b73c94-d3d6-49d7-913d-8c15ba992019 and release-preparation build dfc9b103-8920-4a1e-a107-cd78bcfbf3e6 completed after their approvals. A new operator process found the original publisher ID without creating another build. Cloud Deploy release access-0b88f714f6c8e3f668343ac04ccdeedb7f83f582a3b9f04d, rollout access-stage-0001, reached SUCCEEDED.

Migration Execution access-migrate-k57km completed at 17:47:36.428290 UTC, before backend deployment started at 17:47:39.931236143 UTC on 9 November. There were no pending migrations; the stage SQL grants were reapplied. New revision access-backend-mw9jv7nr was verified Ready with the expected image/runtime identity and 100% traffic. No new schema changes were applied. Inspect the completed rollout in Google Cloud.

The private probe completed 360 requests, all HTTP 200: 180 /ready and 180 /health, succeeding on its first attempt. Fresh telemetry was read back: 40 span records from instance c8bbcd0b-c4a0-4be3-a238-391da4c250bd, including the probe's exact ready trace 6bcb02bfeb682b0c1457f3e30a870e11; application request-duration metrics were matched to that same instance. SQL proxy connection metrics arrived in the DB project. These are received evidence records, not a claim of one exported trace per request. Cloud Run's initial health request was logged as unsampled; it is not counted as an exported trace. No exporter warning was found in the diagnostic window.

The probe's Job, service account and temporary invocation grant were removed after its terminal success was verified. The operator kit passed verification again at the end, unchanged. This accepts the observed ordinary Access release and its telemetry; it does not certify business endpoints, cross-project networking, load capacity or every operator/profile.

Recovery inspection read the real rollout while pending approval, in progress and successful. Attempts to retry the pending and successful rollout were rejected before a retry intent or cloud request was created. These are live guard checks, not a successful retry of a failed rollout.

A second release of the same Access commit, access-c3563d26c1112ea1a51d61fa57570f81d386bc0658462e90, also reached SUCCEEDED, producing revision access-backend-mw9le435. Migration access-migrate-7459c completed at 18:29:11.605840 UTC, before backend deployment at 18:29:22.935710743 UTC, again with no pending migrations. A controlled attempt to cancel only a still-queued predeploy build stopped after an initial read returned HTTP 404: no cancellation or Cloud Deploy retry was sent. Subsequent reads confirmed successful predeploy and deployment. This was another ordinary release, not a successful retry or a two-candidate ordering test.

The second revision's initial probe failed on its first HTTP request with 403; its cause was not established. One controlled repetition of the probe, without changing Access or widening roles, completed 360/360 HTTP 200 at 18:43:23 UTC. Readback found 17 fresh span records and application metrics for instance fc261ce8-3ff5-47f2-a5c1-b2b251313c26, plus SQL proxy metrics. Its temporary Job, service account and invocation grant were removed. This was a probe retry, not a Cloud Deploy retry, and is recorded separately from the first revision's successful first-attempt probe. Retain the unresolved 403 diagnostic alongside the successful result; do not infer its cause from the repetition succeeding.

The retry remains assisted: its reconciliation input records a named verifier, time and concrete evidence for the previous Operation/Execution or a failure before work started. An empty active-Execution list cannot establish that a lost :run request was never accepted. An authorized administrator resolves any remaining ambiguity before retry; elapsed time is insufficient. See Stage Release and Recovery. The isolated positive retry below adds evidence for a deployment-permission failure; it does not certify every recovery case.

Isolated SQL-free recovery — verified 9 November

Temporary SQL-free Service access-recovery uses a separate standard-library-only fixture package in Access PR #31, commit e17266a3e3ccc7b506de6e816cfca107e67a6d0c. It has its own recovery publisher/delivery pipeline, runtime sa-access-recovery, release identities, scoped roles and candidate storage. Infra PR #28 introduced the fixture; PR #29, commit 8d6187a10d9d9e9d326e1436e106ab70bf5a6a3d, fixes a general SQL-free delivery issue: Google omits an empty standard strategy, so Terraform now emits an explicit strategy only when predeploy actions exist. Twenty-four module tests passed, including the migration-hook regression. No special fault hook or recovery bypass was added to the common engine.

After a Ready baseline, the test removed only run.services.update from fixture-only custom role stageRecoveryBackendUpdate, using its current etag. The next deploy failed with the expected permission denial while the existing revision remained Ready and answered the private probe. The role was restored through a verified Terraform apply. Concrete failed JobRun/Build evidence was reconciled before the real stage_recovery.py helper retried the exact stable/deploy job of rollout recovery-stage-0001, release recovery-c756b17b22796cfca9843872537eb418f513c4a54d1f2121.

The new JobRun 27278d48-972e-4ce8-886e-535a860ad164 and Build ec43aa43-12ab-4471-a0fe-27f132c50695 succeeded at 21:35:28 UTC. Source commit, candidate, bundle, image digest, release, rollout, phase and job remained unchanged; the original failed JobRun 9eb6550d-ca9d-4bd5-9bdf-9e99f5dd4b23 remains in history. Revision access-recovery-mw9rv6ga was verified Ready with the expected image/identity and 100% traffic. Repeating the retry command was rejected without another cloud mutation. The ordinary Access revision access-backend-mw9le435 remained unchanged.

Private probes verified ten HTTP 200 responses with the exact fixture body in each phase: baseline, failed deployment and recovered deployment. The failed phase still served baseline revision access-recovery-mw9r8l0e; the recovered phase served the new revision. An initial baseline probe received 403 before its controlled repetition succeeded; its cause was not established. These probe results are distinct from the successful Cloud Deploy retry. The probe verified the actual Execution network, falling back from API v2 to the same Execution's v1 annotations with matching UID/Job generation when v2 omitted vpcAccess.

This tests a deployment-permission failure, not a SQL failure, schema rollback, production recovery, independent-repository onboarding, candidate concurrency or Platform→Farm networking. The same-project probe uses ALL_TRAFFIC; it does not validate the proposed cross-project private-ranges-only route. See the fixture procedure.

Cleanup completed: the role was restored, the fixture Service and all three probe Jobs/temporary invocation grants were removed, and exists = false and nominal grants were reconciled with Terraform. The first-creation IAM window is closed. Final bootstrap and stage plans at infra 8d6187a10d9d reported zero changes. Protected pipeline/target/buckets, registry image and catalog identities remain for audit, with no running fixture and automatic triggers disabled. Their deletion protections remain enabled. No Cloud SQL instance was added; retained artifacts do not imply zero cost. The sanitized acceptance receipt was finalized at 21:39:37 UTC.

Order for completing the common base

The current priorities supersede the earlier dependency on Console/staff and all asynchronous profiles. The initial base consists of these four steps:

Step	Work and acceptance	Current boundary
1. Standard	Align descriptive component fields, catalog examples, executable validators and profile limits. Detail each system during development and before deployment, rather than completing all future sheets now	Documentation aligned; kit/recovery code merged and locally tested; six IAM additions applied with no drift. Profile-specific live checks remain separate
2. Independent Access release	Package selected applied contracts and matching tooling; exercise publication, preparation, approvals, interruption/retry and two-candidate ordering	Ordinary Access release, publisher restart and telemetry passed. Isolated SQL-free positive retry, duplicate-retry rejection and cleanup passed; candidate ordering remains separate. Operator-specific actions are checked during normal first use, without waiting for a dedicated Lorenzo session
3. Generic onboarding and access	Use the existing Farm skeleton's backend + migrator, enroll its SQL identities, then test a probe in Platform; prove first creation, cross-project network/IAM, declared grants and denied operations	Farm first rollout, SQL identity checks, five S2S cases, first-creation IAM closure and cleanup succeeded. Metrics and one correlated trace received; migrator no-op verified with the documented operator limitation. The full Farm product and additional writers are not prerequisites
4. Minimum operations	Receive an alert, verify cost/connection limits, restore a representative isolated copy and exercise compatible application recovery	Separate acceptance remains required; retry alone does not prove recovery to previous behavior

Use Stage Release and Recovery for the procedure. The first handoff uses the existing one backend + separate migrator per system profile. Runtime writes data, never schema. A new system with that profile needs its own registration and checks, not the extension for additional writers.

Separate profile acceptance

Read-only, Pub/Sub push, Scheduler and SQL-free Jobs are accepted when needed. Controlled fixtures can prove a profile before ordinary use; one probe Job does not certify scheduled application jobs. Extra writable consumers/relays on the same schema need a delivery-code extension as well as tests: runtime SQL without a separate migrator, a verified compatible-schema prerequisite, component ordering and recovery. Normal writes still require application transactions and idempotency; rollouts are not atomic.

Console/staff ingress remains a separate integration. When it is scheduled, finish its builder publication and profile activation, confirm hostname/DNS/group/costs, then jointly test IAP, sessions, BFF calls and bypass denial. This does not postpone the initial Access/API procedure. Production and client-facing exposure retain their own prerequisites.

Farm onboarding — first rollout, 10 November

The real backend and migrator from Farm PR #1 were integrated with the stage adaptations in Farm #9. The publisher used fc5d06efe41c186ed991be0ba4d1b5b698ab3b5a; later Farm feature PRs remain separate. The runtime reuses moonitoring-farm-stage, database farm and sa-farm-api / sa-farm-migrate. There is no new project, database or custom Farm delivery engine. Relay and other writable components remain excluded.

Checkpoint	Verified outcome
Infra registration and network	#30 and #31 merged and applied; Farm repository authorized in Developer Connect; private run.app DNS read back on the Shared VPC
SQL baseline	Farm v3 applied in one transaction; stable NOLOGIN owner/runtime roles and explicit ACL/defaults verified. Prior fixture metadata preserved; Access catalog unchanged (141 relations). Temporary SQL administrator, secret, identity, Jobs and binding removed and independently checked absent
Enrollment and delivery	#32, ac4f408, applied: 35 bootstrap and 10 stage changes, no deletions or Access changes. Both Farm IAM identities passed private SQL login/membership checks and six foreign-database denials each; verification Jobs removed
Publisher and kit	Build 9f1de53b-cfff-4ae3-b4e6-43bd108f8607 succeeded; the initial kit adopted its verified images without rebuilding. Kit manifest SHA-256 c33b5217b6000885ee0eb366578af38497f09077a1aeb5ee3e72302bd5cccbdf
First rollout	Release preparation 4ecdde99-a093-470a-a479-a24e3692895d and approved rollout farm-stage-0001 succeeded. Migrator farm-migrate-lbjrc finished at 00:35:59 UTC; revision farm-backend-mw9ygxlx became Ready at 00:36:43 UTC with 100% traffic. Access stayed on access-backend-mw9le435

View the Farm rollout. The backend uses sa-farm-api, internal/load-balancer ingress and PRIVATE_RANGES_ONLY on stage-farm; maximum instances is two. The migrator used its separate identity, ran both missing migrations, completed explicit grant handling and shut down the SQL proxy. Its OCI index and executed manifest digests were checked separately. Separate post-migration verification passed with both IAM identities: runtime DDL and ledger access are denied and all six foreign databases are denied to each identity. Verification Jobs were removed at 00:40:32 UTC. These checks do not certify business operations.

The baseline preserved legacy stage_check structure, ownership, ACL and dependencies. Fixture row contents were not read or certified. Its metadata fingerprint stayed 45b28d0ed110207c329154862d3388ab0c9ba42988e5544208f3709c10b6bd32; the Access catalog fingerprint stayed 406b8cf1c56caa6ecc28ba4e89e9b60cfe1ee86dadb7208e09a7759cd7aa3631. See the SQL evidence and its scope.

First-creation IAM closure in Infra #33, b1a5398, is applied: ten IAM resources added and the temporary creation role and its binding removed. A new steady-state kit is prepared for subsequent runs, with manifest SHA-256 d35255663ef1ae3223a4a2889c166a166b8f2388ca7d105668c6cc78b9508602. The initial kit and its run inputs remain unchanged. Final bootstrap and stage plans on clean infra commit 1de380050a11de392d88e7b29ba5c0b509d9cf6d reported no changes after closure.

A single repeat execution, farm-migrate-bjp6j, succeeded at 00:42:57 UTC and reported no pending migrations, with no migration IDs applied. Job UID, generation/template and backend revision stayed unchanged. It was started with sa-tf-apply-stage, without adding permissions; nominal deployer impersonation was unavailable. This verifies migrator no-op behavior, not a further Cloud Deploy release or effective permissions of the deployer after IAM closure. Ledger rows were not read directly; keep the log-based evidence boundary.

A temporary Platform Job using sa-access-recovery called Farm through PRIVATE_RANGES_ONLY, private DNS resolving to 199.36.153.8/30 and the Shared VPC. The executed task's network settings were verified. Each case called both /health and /ready:

Case	Observed status on both paths
Valid token before the temporary invoker grant	403
Valid token, correct audience and grant	200; response status and Farm request logs correlated
No token while the grant exists	403
Wrong token audience while the grant exists	401
Valid token after grant revocation	403

All five cases passed. The five probe Jobs and the temporary service-level grant were absent after cleanup at 00:43:26 UTC. No permanent S2S grant was added. Farm HTTP metrics for both paths and private IAM SQL-proxy metrics were received. One exact application trace for the probe's /health request was read back and correlated with the runtime instance; the requested /ready trace was not observed in the bounded readback. Do not report two out of two traces or treat absence of export-error logs as proof of ingestion. The readback's aggregate verified=false records that unmet two-trace check; the observed trace and metric samples independently demonstrate ingestion for the reported signals. The probe is temporary; the Farm backend is a real service, not a disposable SQL-free fixture. Catalog gRPC remains closed until an explicit audience and caller policy are configured (the audience was decided on 2026-11-12: the callee's fixed Cloud Run URL, see gRPC Between Services). These tests do not certify business authorization, staff/client entry points, IAP, load balancing, production or the complete Farm product.

The automatic trigger events remain disabled. Publication, release preparation and rollout approvals remain separate. After onboarding, ordinary code releases reuse the catalog and kit without Terraform changes unless resources or permissions change. Sanitized local evidence is under work/farm-live-20261110/: publisher/publication.json, kit-initial/receipt.json, sql/baseline-cleanup-verification.json, sql/verify-before-release/summary.json, sql/verify-after-release/summary.json, release-initial/last-status.json, release-initial/migration-verification.json and runtime/readback-20261110T003658Z.json, release-initial/migration-idempotency-verification.json, s2s-probe/receipt.json and telemetry/readback-20261110T004150454627Z.json. These are local receipts, not attachments published by this page; retain their package with the operator.

Evidence required for closure

Record the infra/app commits, kit and contract hashes, operator identity, image digests, build/release/rollout or Execution IDs, timestamps, expected/observed results and sanitized logs. Distinguish an applied grant from successful use through the intended group. A run as Jacopo with direct Owner access cannot alone certify Lorenzo's access; keep that evidence boundary without making a duplicate run by Lorenzo a delivery prerequisite.

For the private path, retain run.app and its token audience while resolving it through private DNS and Private Google Access. The Farm recipient revisions must be attached to the intended Shared VPC. The old ALL_TRAFFIC Access probe does not prove the new private-ranges-only cross-project path. See Google's Shared VPC requirements.

Keep existing run inputs immutable when first-creation handling changes exists: issue a new kit for later runs and use the separate retry procedure for the old rollout. Keep a shared release register: one executing rollout per component/environment, reconcile uncertain executions, and reject superseded pending candidates. The dedicated approval command checks snapshot/provenance and the target inventory before POST; the retry path retains its own checks. Neither provides atomic distributed ordering or prevents another IAM-authorized channel such as the console.

This register keeps the 7–9 November receipts as dated evidence. New code or documentation is not a new successful apply, runtime test or delivery acceptance. Link sanitized new receipts when those checks finish; do not publish Terraform state, raw plans, tokens or application data.

Current procedure clarification — 10 November

Release autonomy applies after Jacopo and Lorenzo complete onboarding together. Developers own application Dockerfiles, scripts, tests, manifests and migrations; central Cloud Build recipes and privileged tooling remain infra-owned. The version 1 recovery path is a compatible fix/revert on current main, preserving applied migrations, followed by the normal release gates. Cloud Deploy rollback to an earlier release is outside that path.

SeaORM already rejects a database containing an applied migration unknown to the migrator. Access main 17ad6646 has Lorenzo's three explicit regression cases; Farm main c544d043 has four, with eight migrations and the updated grants. All seven PostgreSQL 17 cases pass. Farm also passes fmt, Clippy, 57 workspace tests (one pre-existing ignored doctest) and 14 delivery-hook tests. The implementation from Lorenzo's Farm PR #15 is retained; the concurrent duplicate PR #16 was closed without merging. Local Compose also passed: six original application images built, nine services running, backend health/readiness successful, migration and Pub/Sub setup exit code zero, and eight migration versions recorded. Its application/build sources are byte-identical to the adopted main; only the regression test and README changed during validation. Test containers/resources were removed and the isolated Docker daemon stopped. This does not certify cloud worker delivery. These are code tests, not a new stage deployment. Farm online stays at fc5d06e with the two migrations in the acceptance above.

The new stage_approval.py inspect/approve command is an explicit manual approval with the approver's own account, not automatic approval by init or advance. See the runbook for the recent-snapshot and same-target inventory checks and their non-atomic/console limitations. Existing retry protections remain separate. New helper tests do not require another disruptive cloud failure or certify concurrent independent approval channels.

Infra tooling at eb2cd10 passed 98 operator tests, including 15 approval-helper tests. Infra PR #35 is merged at de07d918, with no Terraform apply. An updated Farm kit was exported and verified offline with unchanged applied delivery/runtime/operator contracts; its manifest SHA-256 is e5dc2d5ee5c115c27e58722c861cb9e584dc309126e60f85dc867dc7ab8ff318. At 09:40 UTC on 10 November, the published helper's read-only inspect verified the existing successful Farm rollout and returned selected_rollout_is_not_waiting_for_approval, with no cloud mutations. That verifies live inventory/provenance reading, not a new approval POST; the first such approval will be recorded at its ordinary use.

Guardrails that are not application implementation

IAM authenticates cloud invocations; each destination still enforces operations, data scope and user context. Read-only SQL can read every row in its allowlisted tables and is not tenant authorization. A SQL baseline evidence reference is a reviewed attestation, not cryptographic proof or automatic verification of migrations.

The edge output prescribes restricted Cloud Run ingress, IAM invocation and correct IAP assertion checks; it does not inspect the deployed revision. Its load-balancer/IP/Armor costs persist independently of minimum Cloud Run instances zero. Event resources and delivery profiles similarly do not prove application idempotency, safe schema changes, alarms or recovery.

Sources and procedures: common architecture contract, infra onboarding, SQL runner, staff edge.