Control Console

The Control Console (apps/control-console) is a browser-based operator UI for everything documented on Integration Governance & Identity and Security — a pure API client, never a second way to reach the same data. It calls the engine through the same CarcManagementClient/CarcAdminClient the SDK exposes (see SDK Guide); no Console action bypasses the authorization rules those clients' server-side routes already enforce.

Signing in

There is no OIDC/SSO yet (see Security's "Intended production direction"). Sign in by pasting a credential issued through the admin API (POST /admin/management-principals/:id/credentials) into the login page. The Console probes it via whoami() to determine:

• Plane: a platform_admin principal lands on the admin views below; every other principal_type lands on the tenant-facing views.
• Session display: the current principal, tenant, role, and environment are always shown in the header so it's never ambiguous which identity is acting.

The credential is held only in React state for the lifetime of the tab — never localStorage, sessionStorage, or a cookie — and is cleared on sign-out or when the tab closes. This is a disclosed, temporary trade-off, not a design goal; see Security for the documented OIDC/BFF extension point.

An integration-runtime credential (IntegrationCredentialBinding reference) cannot authenticate into the Console at all — whoami() only recognizes management-plane credentials, and the runtime execution gateway's own credential universe has no whoami equivalent.

Platform administration views

Reachable only by a signed-in platform_admin:

• Principal Registry / Principal Detail — create, activate, suspend, disable a ManagementPrincipal; manage its tenant memberships (role changes, suspension, revocation) and its credentials (issue, rotate, revoke) from the same detail page.
• Organization Verification Queue — submit, approve, reject, suspend.
• Bootstrap Status — GET /admin/bootstrap-status surfaced with a clear critical/safe/risky reading, so it's obvious at a glance whether bootstrap-admin access is still enabled after the durable admin exists (it should not be — see the staging deployment doc's bootstrap sequence).

Integration Governance views

• Integration Registry / Integration Detail — every lifecycle action (submit, approve sandbox, request certification, approve production, activate, suspend, revoke) as an explicit button, gated by the integration's current status — never a generic on/off toggle. Suspend, revoke, and any administrative override require a typed reason before the action fires; the reason is sent straight through as the server-side audit event's own reason field.
• Environment Detail — environment lifecycle, agent bindings (create, assign capabilities, approve, activate, suspend, revoke), and links to Certifications and Credential Operations for that environment.
• Certification Panel — request a certification, run the platform conformance suite against a named agent (per-check pass/fail shown), then record pass or fail as a separate, explicit action from running the suite itself.
• Credential Operations — bind a credential (the raw value is write-only in the request and never echoed back in any response, including this one); once bound, rotate or revoke it. There is nothing to "reveal" here — unlike a PrincipalCredential, an IntegrationCredentialBinding never returns its raw secret at all, only the opaque credential_reference.
• Audit Timeline — a unified operational view aggregating IntegrationAuditEvent (including runtime authorization outcomes) and PrincipalAuditEvent, filterable by tenant, integration, environment, principal, actor, action, outcome, correlation ID, and time range. This aggregation happens only in the browser at render time — the two underlying audit stores are never merged server-side (see Security).

Tenant-facing views

Reachable by any non-admin principal, scoped to their own tenant only:

• Integrations — create a draft, submit it for review.
• Integration Detail — edit allowed metadata, view environments, approved capabilities, and certification status (all read-only beyond metadata), and request a credential rotation for a bound environment.

Credential issuance UX

Every one-time secret (a newly issued or rotated PrincipalCredential) is shown exactly once, behind an explicit acknowledgement checkbox, with a copy-to-clipboard action and a clear warning that it cannot be retrieved again. The value is cleared from the Console's own application state as soon as you navigate away from that view — there is no "show it again" path, mirroring the engine's own one-time-response guarantee.

Lifecycle status display

Every one of the roughly fifteen lifecycle status enums this milestone introduced (ManagementPrincipalStatus, TenantMembershipStatus, PrincipalCredentialStatus, OrganizationVerificationStatus, IntegrationStatus, IntegrationEnvironmentStatus, IntegrationAgentBindingStatus, IntegrationCertificationStatus, IntegrationCredentialBindingStatus, and more) renders through one shared badge component with a fixed status-to-tone mapping — draft, submitted, sandbox-approved, certification-pending, production-approved, active, suspended, revoked, and expired are always visually distinct from one another, never collapsed into a generic enabled/disabled toggle.

Deploying the Console

See docs/deployment/staging-integration-governance.md for the full private staging deployment (a separate, authenticated-ingress Cloud Run service; the API origin is baked into both the compiled JS bundle and the Console's own Content-Security-Policy at image build time).