7.5 Stage Baseline — 7 November 2026
This register reconciles source code, dated operational records and the P0/P1 work boundary. The initial baseline was compiled without a new cloud inspection; subsequent read-only checks and authorized application/acceptance are recorded separately below. Statements about a pending apply belong to their dated phase, not the final Access status. An implementation in Git, an applied resource and a successful runtime test are different evidence. The 9 November register tracks the following foundation work.
Sources read¶
| Source | Revision / date | Scope |
|---|---|---|
| Infrastructure main | 7b1ba1980a37, checked 7 November |
Common CI/access catalogs; Access delivery and telemetry IAM. P1 generalization is a subsequent change |
| Documentation baseline | 9cf18641d927, checked 7 November |
Architecture and contracts; several activation notes stop at 4–5 November |
| Access main | f106cccf6b13, checked 7 November |
Application manifests, migration hook and digest correction |
| Console main | 88c98a16c95a, checked 7 November |
Existing BFF/session/IAP verification and server-side forwarding |
| Common main | 464dc944b102 |
Shared verification utilities; does not constitute a deployed service |
| Access register | Entries 5–6 November | Infrastructure group grants and two stage approver memberships |
| SQL verification | 6 November, before application tables | Access private connection, runtime/migrator separation and cross-database denials |
| Application CI acceptance | 6 November | Common and Access checks; this earlier record by itself does not certify publication or deployment |
The implementation conversation and local operational receipts record later 6 November activity: successful Access rollout after the digest correction, closure of its first-creation IAM window, and a temporary telemetry probe. The probe receipt records completion at 2026-11-06T16:37:39Z and cleanup. It is not by itself proof that every metric or alert arrived. These later facts must not be erased by an older README saying “first rollout pending”; equally, they do not certify the current live revision or every SQL operation. Attach sanitized release/plan/test evidence to the next implementation acceptance record instead of publishing full state, plans, credentials or application data.
Readiness by area¶
| Area | Evidence at the baseline | Next verification / owner |
|---|---|---|
| Bootstrap, stage projects/network/SQL | Applied in the preceding work; IDs and naming preserved | Jacopo: focused refresh/plan, preserve state and resources |
| Team groups | infra-admins grants applied; Jacopo/Lorenzo added to stage approvers on 6 November |
Both: directory restrictions and effective group-only access; no assumption that observer membership changed |
| CI | Developer Connect, Common/Access checks and bounded build profiles in main | Jacopo: preserve profile/identity separation while generalizing delivery |
| Access delivery | Initial stage rollout reported successful; Access-specific resources and scripts in main | Jacopo: compatibility regression, no resource recreation, current cloud evidence before apply |
| SQL | Access baseline positively/negatively tested before application migration | Both: test actual application object grants separately; new systems remain opt-in |
| Console and edge | BFF exists in source; general ALB/IAP setup not present in inspected infra main | P2: delivery profile, audience, routing, groups and access/bypass tests |
| Telemetry | IAM changes in main; real trace work and probe receipt recorded | Jacopo: close OTLP metric issue, demonstrate metric and alarm receipt |
| Async components | Catalog/identity foundations exist; full event resource and rollout procedure not certified | P3: endpoint/audience/IAM, retries, DLQ and minimum multicomponent coordination |
| Production | Design only for this work | Later: scoped approval, successful-stage evidence gate, readiness and explicit activation |
Decisions and bounded open questions¶
- Initial work boundary: P0/P1. Complete the common foundation through P0–P3 before splitting the remaining product systems between Jacopo and Lorenzo. A second system's complete implementation is not a prerequisite to validating a reusable profile.
- Development: local Docker; no cloud development deployment. Production: no activation from this work.
- Cloud identities: IAM and dedicated service accounts are already chosen. Internal requests go directly to their destination; Access distributes authorization information rather than forwarding every request.
- Staff ingress: use Console's existing BFF.
/api/<system>/on its host goes toconsole-server; Access token exchange verifies Console's actual IAP audience. Dev ORM has its own protected backend. - Still open: whether product web/native clients should use IAP in any environment, and how to isolate client traffic from staff/internal methods on a shared runtime. This blocks client exposure, not P1 catalog/build work. First test Console → private Access.
- Application responsibilities: session behavior, RPC/replica permissions, idempotency and migration semantics remain application code. Infrastructure grants alone do not implement or test them.
- Farm onboarding: gradual, initially about five existing collaborators, no fixed provider requirement. Plan capacity/costs at least for one hundred and retain larger growth scenarios; P0/P1 do not certify that capacity or ingest real data.
Evidence required to close P1¶
Record the infrastructure commit, contract version and tests; compare Access's old/new contract, manifest inputs and Terraform addresses; reject unknown profiles and unsafe identity mapping; prove another supported profile with an identified fixture. A subsequent real plan must show no unexpected deletion, replacement or permission expansion before apply. Document the first-registration procedure separately from ordinary code releases and keep the manual approvals intact.
Use the common delivery contract for ownership and the corresponding infrastructure change's test report for actual results. This register does not mark a test passed merely because it appears in the plan.
Subsequent P1 read-only verification — 7 November¶
The P1 verification subsequently reread the existing Access runtime as Ready and its previous rollout as SUCCEEDED. The new verifier accepted the actual rendered manifest using the isolated SDK Python and its bundled parser. These checks preserve the distinction from the earlier source-only baseline above: no new application revision was deployed.
The reviewed bootstrap plan reported 34 state-address moves and two intended resource deltas: the release trigger program/contract and the release identity's scoped artifact-read binding. The stage plan reported nine state-address moves and no resource changes. Neither plan was applied in this verification. Attach the final sanitized plan/test references in the infrastructure acceptance record; subsequent code changes require review of their own delta. The cross-root onboarding checker validates declarations, not live SQL or IAM behavior.
Shared metrics correction — 7 November¶
The subsequent authorized Access rollout succeeded, including predeploy and backend, but its telemetry check exposed two independent failures. Application metric export returned gRPC InvalidArgument; the shared Resource lacked a process instance identity required by Google's OTLP metric mapping. The SQL proxy instead reported PermissionDenied for monitoring.timeSeries.create in the database project: its built-in metric destination differs from application telemetry in Platform. Successful SQL connectivity and health traces did not close either metric check.
The correction is shared infrastructure/library behavior, not an Access-only exporter: generate one process-unique Resource in Common, reuse it for traces and metrics, and declare an opt-in SQL proxy metric capability for eligible identities. The observability standard specifies the destination, identity, manifest and evidence rules.
Final authorized acceptance — 7 November, 18:43 UTC¶
The common delivery was applied and an authorized Access rollout completed before the telemetry correction. The correction was subsequently merged in infra #23, Common #13, Access #29 and Docs #87. Its stage apply added four resources, changed/deleted none, and was followed by an empty plan.
The final approved release access-5433d22600fc2df87c627ab67b726087f717265e635c733f succeeded. Migration completed before backend deployment; revision access-backend-mw6qnqlk became ready. A temporary authenticated private probe completed 360 requests across /ready and /health, all HTTP 200. Fresh application traces and request-duration metric points arrived in Platform, and three built-in backend SQL-proxy metric types arrived in the DB project. The shared instance identity matched across application traces and metrics. No exporter error was observed through 18:41:36 UTC; the probe Job, service account and grant were removed and verified.
The sanitized local acceptance receipt records those observations and source revisions. This proves the tested private health/readiness and telemetry path, not external login, alarms, all business operations or short-lived migrator metric export. Cloud Run retained minimum instances zero; request-based CPU does not guarantee periodic export while idle. A first probe attempt returned 403 during IAM propagation; the identical-permission retry succeeded. Future releases still need their own time-bounded evidence; this result is not a live dashboard.