First access to console

This tutorial gets you from the public console URL to a signed-in operator session. It does not cover creating the Pocket ID client or issuing upstream service credentials; those are operator setup steps.

Before you start

• A browser with access to https://console.tcp.systems/.
• A Pocket ID account that can complete sign-in for the console OIDC client.
• The access scope you need: ops:read for operator reads, admin for actions that change state (CONSOLE-BFF-CONTRACT.md:107-111; src/hooks.server.ts:30-37,49-61).

1. Open the console

curl -sSI https://console.tcp.systems/

Observed 2026-11-05 from this workspace (exit code 0): the root URL returned 302 with location: /login and cache-control: private, no-store. A redirect to /login means the console is answering and you do not yet have a valid session.

2. Start sign-in

Open https://console.tcp.systems/login in a browser. The console creates a short-lived login transaction, generates PKCE state and nonce values, and redirects to Pocket ID (src/lib/server/session.ts:115-126). The transaction is stored in a host-only cookie; the browser does not receive access tokens.

If the deployment is missing required OIDC configuration, the login flow fails closed instead of starting a partial session (src/lib/server/session.ts:97-101; docs/CONSOLE-BFF-CONTRACT.md:72-78).

3. Complete Pocket ID sign-in

Complete the Pocket ID flow for the configured issuer. On success, Pocket ID returns to the console callback. The console checks the transaction state, exchanges the code server-side, verifies the ID token, resolves scopes, and sets the signed __Host-console_session cookie before redirecting to /console/ (src/lib/server/session.ts:128-168).

If no console scope is granted, the callback returns 403 {"error":"insufficient_scope"} (src/lib/server/session.ts:159-163).

4. Confirm the session

After the redirect, use the console session route or a signed-in page:

curl -sS https://console.tcp.systems/auth

This request needs a browser session cookie. In a normal browser session, the route reports console session state without calling upstream services (src/routes/auth/+page.server.ts, route listed in docs/CONSOLE-SPLIT.md:19).

5. Check health separately

curl -sS https://console.tcp.systems/readyz
curl -sS https://console.tcp.systems/healthz

Observed 2026-11-05 from this workspace (exit code 0): /healthz returned 200. /readyz returned 503 with {"ready":false,"service":"tcp-console","oidc":true,"origin_bound":false,"probe_ms":1}. Read that as a dated snapshot: the process answered, but this environment reported that no upstream origin was bound at probe time.

What this proves

• The console URL is reachable and redirects unauthenticated visitors to login.
• The login flow uses server-side OIDC exchange and an opaque session cookie.
• Health and readiness are separate checks; a healthy process can still be not ready for upstream-backed work.

Next: Use console for common tasks for day-to-day operator work, or Console runbook if sign-in or readiness fails.