OSA Cloud Workspace treats GitHub as the source of truth for code and Google Cloud as the source of truth for runtime and infrastructure. The Workspace sits above both as the operator experience. Its job is to make evidence easier to inspect and actions easier to control, not to invent status.
The canonical evidence chain is SOURCE SHA → BUILD ID → IMAGE DIGEST → READY REVISION → LIVE URL. Each stage answers a different question: which code was selected, which build produced the artifact, which immutable image is deployed, which revision is ready and which endpoint currently serves traffic.
A successful build without a ready serving revision is not a successful deployment. A historical live badge is not evidence that the same revision is healthy now.
| Status | Meaning |
|---|---|
| CONNECTED | The backend has evidence from the integration. |
| LIVE | Runtime or deployment is positively confirmed. |
| FAILED | A failure is positively confirmed. |
| UNKNOWN | There is not enough evidence to claim a state. |
| NIEPOŁĄCZONE | The integration is not configured. |
This avoids a common control-plane failure mode: turning an API timeout, stale cache or missing credential into a reassuring green state.
The documented Workspace covers agents, automations, project portfolio, developer tools, test lab, deployment, infrastructure and costs. Project entries can combine repository, branch, SHA, deployment evidence and live target so the operator can trace the path from source to serving revision.
The same principle applies to agent control: a UI button should call a governed backend action and then surface the resulting evidence instead of optimistically assuming that the action succeeded.
Administrative actions use Google Identity. The backend checks verified email, configured admin identity and token audience. Cloud Run uses Application Default Credentials with a user-managed service account rather than a service-account key committed to the repository.
The read-only baseline starts with viewer roles and permissions grow only when a concrete operation requires them.
The control plane helps an operator see and trigger work. Runtime governance decides whether an agent action is authorized, which capabilities exist, where execution occurs and what proof must be produced. Keeping those layers separate prevents the UI from becoming the sole security boundary.