System · Cloud Control Plane

OSA Cloud Workspace: source-to-runtime evidence in one control plane

A build saying “success” is not the same as a verified deployment. Cloud Workspace models the chain from repository SHA through build and image to a concrete runtime revision and target.

CLAIM ≠ PROOF. No evidence = UNKNOWN.
GitHub repository → branch / commit SHA → Cloud Build → Artifact Registry → image digest → runtime revision → live target → verification evidence

The control-plane semantics distinguish CONNECTED, LIVE, FAILED, UNKNOWN and NIEPOŁĄCZONE rather than inventing a green state when an API cannot confirm it.

The repository defines separate desktop cockpit and mobile bottom-navigation flows around agents, automations, projects, dev tools, tests, deploy, infrastructure and cost visibility. Operator messages are Polish-first.

Source code remains the GitHub source of truth; cloud APIs represent runtime and infrastructure state; Workspace is the operator control plane joining those sources.

The repository documents a Google Cloud implementation and validation semantics. Infrastructure can change after a commit, so this page does not use an old repository badge as proof that a particular runtime is still live now.

Current runtime status must come from current runtime evidence. Historical build/deploy evidence remains useful, but it should not be silently promoted to “live today.”

The Workspace contract distinguishes CONNECTED, LIVE, FAILED, UNKNOWN and NIEPOŁĄCZONE. Missing API evidence is not converted into a green badge. This keeps the operator UI aligned with the underlying infrastructure state.

CLAIM ↓ EVIDENCE ↓ ACTION

The canonical deployment evidence chain binds the source commit to the resulting build, artifact and serving revision.

SOURCE SHA → BUILD ID → IMAGE DIGEST → READY REVISION → LIVE URL

GitHub remains the source of truth for code while Google Cloud is the source of truth for runtime and infrastructure. The Workspace is the operator/control layer over those sources rather than a replacement for them.

Administrative actions use Google Identity. The backend validates the ID token audience, verified email and configured admin address. Cloud Run uses Application Default Credentials with a user-managed service account instead of storing a service-account key in the repository.

The read-only baseline starts with viewer roles and grows only when a specific operation requires additional authority.

The documented control center covers agents, automations, projects, dev tools, test lab, deploy, infrastructure and costs. Project portfolio entries are designed to expose repository, branch, SHA, deployment evidence and live target together so an operator can trace what code is actually running.