Add read-only terminal-agent auth for Launchplane context

[cbusillo]

Objective

Give local terminal agents a non-browser, non-mutating way to read redacted Launchplane product/environment context.

Finish Line

Terminal agents can read redacted Launchplane metadata without browser OAuth

Current Status

State: Gap identified while investigating SellYourOutboard Resend diagnostics. Launchplane product/environment and secret status read endpoints exist and are deployed, but local terminal agents currently have no general read-only auth path besides GitHub Actions OIDC or a human browser session. The existing Every Code worker bearer token is intentionally scoped to Every Code routes and cannot read product/environment metadata.
Next action: Design the first local owner agent subject/token shape and map it to read-only product/environment scopes.
Blocked by: #380 agent-consumer authn/authz decisions.
Last verified: 2026-05-07 against Launchplane service docs/code and deployed /v1/products auth behavior.

Scope

• Define a local owner terminal-agent subject distinct from browser humans, GitHub Actions workflows, and the Every Code worker token.
• Grant only redacted read scopes first, such as product/environment context, work graph context, preview readiness, and managed secret binding status.
• Preserve current GitHub OIDC and browser OAuth semantics for existing callers.
• Avoid extending LAUNCHPLANE_EVERY_CODE_WORKER_TOKEN into broad Launchplane access unless the authz model explicitly chooses that route.
• Document how terminal agents should acquire and use the credential without storing it in the repo.

Acceptance Criteria

• A terminal agent can call redacted read endpoints such as GET /v1/products/{product}/environments/{environment} without an interactive browser OAuth session.
• The same credential cannot perform product config writes, prod promotion, destructive cleanup, authz policy mutation, or plaintext secret reveal.
• Unauthorized and missing-token responses are clear and do not leak provider topology or secrets.
• Tests cover allowed local owner read access and denied mutation/secret/plaintext access.
• Docs identify the supported terminal-agent path and explain why browser OAuth/session-cookie handoff is not the steady-state workflow.

Relationships

• Subissue of Make Launchplane a read-only agent context provider #379.
• Blocked by Define agent-consumer authn and scoped authz #380.
• Related to Define agent context redaction freshness and provenance rules #381 and Add secret-backed action contract without plaintext reveal #387 for redaction and secret binding status behavior.

Validation

• Service auth tests for local owner agent read and denied mutation paths.
• CLI or curl smoke against a deployed/staged Launchplane service using a scoped read-only terminal-agent credential.
• Docs freshness check for service-boundary and secrets/operator docs if the auth contract changes.

Decisions

• Do not ask terminal agents to depend on browser OAuth as the normal access path.
• Do not give agents plaintext secrets or general mutation authority for metadata diagnostics.

Open Questions

• Should the first local owner credential be a dedicated scoped token, a constrained worker-token variant, a GitHub App/device-flow token, or a host-bound local auth bridge?
• Should the token be revocable DB-backed state, bootstrap env, or delegated from GitHub/team membership?
• Which exact read actions belong in the first scope: product_environment.read, secret.list, secret.read, work_graph.rank, preview read models, or an aggregate context endpoint only?