# Run Product Activations as Independent Lifecycle Branches

## Decision

Starter, Essential V2, and BYOC are independent product activation branches.
They may share session infrastructure and baseline services, but none of the
three products waits for another product to activate.

![CP9 product activation dependency graph](./20260724-independent-product-activation.svg)

The product dependencies are:

- Starter: shared global base services start `serverless-service`, which starts
  `serverless-global-service`; Starter regional substrate/workload activation
  waits for those two Starter control-plane services.
- Essential V2: after the Premium/NextGen baseline is ready, the activation
  branch asks tidb-management-service to create and own the shared pool.
- BYOC: a ready remote Dev full baseline and the configured customer-account
  prerequisites enable the resumable BYOC activation engine. The baseline
  resources it consumes directly are Premium metadb, dataplane-manager, and
  Kong.

There are no Starter-to-Essential-V2, Starter-to-BYOC, or
Essential-V2-to-BYOC dependency edges.

## Lifecycle implementation

After the Session Tiltfile is running, the v3 lifecycle starts four peers in
one parallel phase:

- `session_ready`
- `starter_activation`
- `essential_v2_activation`
- `byoc_activation`

Each product step is disabled when its corresponding session configuration is
not enabled. Enabled steps reuse the same idempotent/resumable activation code
as their day-2 command:

| Product | Eager entry | Lazy/day-2 entry | Shared implementation |
|---|---|---|---|
| Starter | `starter.enabled: true` then `cp9 up` | `cp9 starter activate` | Starter substrate/workload activation and live readiness |
| Essential V2 | `essential_v2.enabled: true` then `cp9 up` | `cp9 essential-v2 activate` | `bootstrap-essential-v2-shared-pool.sh` and UI-plan enablement |
| BYOC | `byoc.enabled: true` then `cp9 up` | `cp9 byoc activate` | resumable BYOC activation journal |

The lifecycle state records every branch separately, so a failed branch can be
retried without replaying successful activations. `session_ready` observes
baseline/UI readiness; it does not serialize the product branches.

Lazy activation does not require the corresponding product to have been
enabled when the Session Tiltfile was generated. Each day-2 command discovers
the live baseline, applies or resumes its own product resources, and re-derives
readiness from live state.

Essential V2 is not a Tilt local resource. Its lifecycle branch waits only for
its direct baseline resources and can run alongside the other product
activation branches, so the long-running pool workflow does not serialize
unrelated Tilt resources such as `serverless-service`.

## Consequences

- Enabling Essential V2 cannot delay deployment of Starter's global services.
- Starter activation can prepare its remote EKS substrate while the local
  baseline converges, then waits only for its direct Starter prerequisites.
- BYOC activation can progress independently once its direct baseline and
  customer-account prerequisites exist.
- `cp9 up` still waits for all enabled lifecycle branches to finish before it
  returns its final result. Parallel execution removes false product ordering;
  it does not hide activation failures.
- Day-2 activation remains the recovery path because eager and day-2 flows use
  the same implementation.