# ADR: Starter Full uses cp9-owned remote EKS and AWS-hosted o11y stub

Status: Proposed

Date: 2026-06-08

Related design:
[`20260608-design-cp9-starter-full-persona.md`](./20260608-design-cp9-starter-full-persona.md)

## Context

Premium full on AWS keeps cp9 control-plane services in local k3d. Customer
dataplane EKS is created later as a service-code side effect of normal OpenAPI
flows.

Starter/Essential v1 is different. The regional control plane is also the shared
dataplane. A full product proof needs regional shared pools, keyspace/gateway
runtime, o11y-driven decisions, endpoint creation, and host mysql `select 1`.

That makes the original Premium invariant too narrow for `starter-full`.

## Decision

`starter-full` will use:

- local k3d for global CP;
- cp9-owned ephemeral remote EKS for regional CP/DP;
- cp9-owned lifecycle for that remote EKS, including `cp9 destroy` cleanup
  evidence;
- a staging-faithful regional stack rather than a minimal service graph;
- cp9-owned generated or stubbed secrets/config by default;
- an AWS-hosted o11y stub reachable by both local k3d and remote EKS;
- deterministic scripted o11y responses for the first autoscale-critical proof;
- narrow upstream config hooks when service repos need safe config override
  points.

Shared staging EKS is not the runtime substrate. Staging manifests and historical
architecture docs are source material only.

## Alternatives Considered

### Local k3d regional CP/DP

This preserves the smallest cp9 substrate model, but the Starter/Essential v1
regional stack is materially heavier than Premium's local control-plane graph
and includes the shared dataplane itself. It also makes the result less faithful
to the product's regional EKS shape.

### Shared staging regional EKS

This is closest to existing production-like topology and fastest to start, but
it weakens cp9 dogfood isolation. It also makes cleanup and failure attribution
depend on a shared environment.

### Local o11y stub exposed outward

This keeps stubs local, but remote EKS would depend on a developer-machine
inbound path or tunnel. That is fragile for a long-running full product proof.

### Workload-generated autoscale metrics first

This is realistic, but it makes the first persona depend on the metric pipeline
that is explicitly stubbed in this design. Scripted o11y responses better prove
the regional decision path before adding live metric confidence trains.

## Consequences

Positive:

- The first `starter-full` proof can exercise the actual two-layer
  Starter/Essential v1 shape.
- cp9 keeps owner/session cleanup responsibility even with remote EKS.
- Autoscale proof is deterministic and debuggable.
- Local and remote services use one o11y evidence source.

Costs:

- `cp9 up` now owns an EKS substrate for this persona, unlike Premium.
- Destroy must handle remote EKS plus regional service cleanup.
- The staging-faithful graph is larger and will expose more secrets/config
  requirements.
- Some upstream repositories may need explicit config hooks.

Guardrails:

- Remote EKS must be session-scoped and owner/session attributable.
- Shared staging EKS and real staging secrets are not default runtime inputs.
- Upstream hooks must be narrow, configuration-only, and tested.
- The first proof must include both Starter and Essential v1 trains.