# CP9 Dogfood First Run

This guide is the compact first-run path for humans and agents who need to
bring up a cp9 dogfood environment, run a reviewed product train, inspect
access, and close out without guessing hidden commands.

## Pick The Scenario

| Scenario | Start from | Use when |
| --- | --- | --- |
| Dev full | `cp9.dev-full.remote-ec2-k3d.example.yaml` | Standard Remote Dev full dogfood runtime, including Premium/Essential v2 product surfaces and the built-in UI. |
| Dedicated OpenAPI train | Dev full runtime plus `skills/dedicated` | Dedicated is validated inside the Dev full session boundary. |
| Starter/Essential v1 train | `cp9.dev-full.remote-ec2-k3d.example.yaml` plus lazy `cp9 starter activate/status`, or `starter.enabled: true` for eager activation, then `skills/starter` | Starter remains a capability inside the Remote Dev full session boundary. |

Use the release tag, branch, or commit named by the task. Record `bin/cp9
version` in closeout. Do not silently switch AWS account or region; if the task
names a deprecated, unsupported, or ambiguous region, stop and ask.

## No-Mutation Preflight

`setup`, `doctor`, and `up dry-run=true` are the risk gate. A red preflight
means fix configuration, credentials, account, role, region, source paths, host
access, or release selection. It does not authorize product-code mutation.
For Starter, the dry-run also reports the six-role node plan, the independent
TiDB serving-node and selected-lane Pod targets, network/storage capacity, and
a timestamped expected-cost window before apply.

Run:

```bash
bin/cp9 setup config=cp9.yaml
bin/cp9 doctor config=cp9.yaml
bin/cp9 up dry-run=true config=cp9.yaml
```

For reports and handoffs, rerun the failing preflight as JSON and cite the
machine-readable blocker:

```bash
bin/cp9 '{sys.output.format=json}' doctor config=cp9.yaml
```

Use `checks[].failure_class`, `checks[].field`, and
`checks[].remediation` as the handoff contract. Do not run `cp9 up` while a
required doctor check is red unless a human explicitly accepts that risk.

## Run And Observe

After preflight is clean:

```bash
bin/cp9 up config=cp9.yaml
bin/cp9 '{sys.output.format=json}' status config=cp9.yaml
bin/cp9 logs config=cp9.yaml service=<service> limit=200 since=10m
```

`cp9 status` is the primary progress and debug surface. It reports lifecycle,
host execution facts including kubeconfig/context, the Tilt endpoint and browser
URL, Remote Dev full UI URL and non-secret login guidance, image source mode,
product route, historical proof-summary projection when present, cleanup state,
and artifact paths. Use those fields before hand-stitching terminal logs.

`cp9 logs` supports bounded collection with `service`, `trace-id`, `since`,
`level`, and `limit`. It does not provide a live-follow mode; for live streaming,
use the Tilt endpoint or the session kubeconfig/context reported by `cp9
status`.

## Product Train Evidence

Run the reviewed OpenAPI or SQL train for the requested product surface. Each
train must write its own artifact directory and summary JSON. Closeout cites
direct evidence instead of a generated proof runner:

- `bin/cp9 version` and source SHAs when available;
- `cp9 status` JSON;
- train summary JSON and request/response artifacts;
- SQL output such as host `mysql` `select 1` when required;
- `cp9 destroy` output and any cleanup artifacts it produced.

If setup, doctor, up, the product train, or destroy fails, preserve partial
artifacts and report the exact failed stage.

## Access Handoff

Use `cp9 status` to inspect the current session's connection and login facts.
`cp9 share` and `cp9 share frontend` are retired. Status is read-only: it does
not authorize security-group ingress, seed Account users, change CORS, or alter
EKS access.

Share only the minimum paths and non-secret instructions the recipient needs.
Kubeconfigs and login passwords remain credential material and must travel
through an approved private channel; status deliberately prints neither their
contents nor passwords. A displayed Starter kubeconfig is not an authorization
guarantee; use the reported AWS profile and preserve the status warning when the
current role lacks EKS access.

## Closeout

Run one session-level destroy:

```bash
bin/cp9 destroy config=cp9.yaml
```

If destroy delegates cloud cleanup and exits complete, record the delegation
fields it prints and do not wait for a direct-zero artifact unless explicitly
asked. If destroy performs direct cleanup, cite the direct summary path, final
verdict, stale-tag warnings, and survivor count.

For imported Dedicated or Starter trains, aggregate the train artifacts first
and then close out through the Dev full session destroy.