Plan the startup order of a self-hosted container stack (conditions, profiles, optional and disabled services, error precedence, cycles)

# Plan the startup order of a self-hosted container stack Our home server runs a compose-style stack (`compose.json` is the JSON form of the compose file). `plan.py` should work out, without starting anything, in which **step** each service would start, and refuse broken stacks with a precise error. The draft ignores most rules. Rewrite `plan(compose, targets=None, profiles=())` in `plan.py` (Python 3 stdlib only), keeping `PlanError(code, detail)` with its `.code` and `.detail` attributes. ## Model 1. `compose["services"]` maps service names to dicts. `depends_on` is absent, a list of names, or a dict `{dep: options}` where options may be `{}`/`null` and may contain `condition` (default `service_started`) and `required` (default `true`). The list form means `service_started`, required. 2. A service is **disabled** if `deploy.replicas` is `0`. 3. **Active set.** If `targets` is `None`: start from every non-disabled service with no `profiles` (missing or empty) or with at least one profile in `profiles`. If `targets` is a list: start from exactly those (error `unknown_target`, detail = name, for the first target in list order that is not a service; then `disabled`, detail = name, for the first disabled target). Then add dependencies transitively: any dependency that exists and is not disabled is added **regardless of its profiles**. 4. **Dependency errors**, checked over active services in name order, and for each over its dependencies in name order; raise the first one found, detail = `(service, dependency)` as a tuple: - stage A: dependency not a service -> `missing_dependency`; dependency disabled -> `disabled_dependency`. Both only when the dependency is required; non-required missing/disabled dependencies are dropped silently and are not checked in stages B, C or later. All stage A checks run before any stage B check. - stage B: condition not one of `service_started`, `service_healthy`, `service_completed_successfully` -> `bad_condition`. All of stage B runs before stage C. - stage C: `service_healthy` on a dependency with no `healthcheck` or with `healthcheck.disable` true -> `no_healthcheck`; `service_completed_successfully` on a dependency whose `restart` is `always` or `unless-stopped` -> `never_completes`. 5. **Cycles** (checked after stage C): if the remaining dependency graph of active services has cycles, raise `cycle` with detail = sorted list of **every** service that is on some cycle (any member of a strongly connected group of 2+ services, or a service depending on itself). Services that merely depend on a cycle are not listed. 6. **Steps.** A service with no remaining dependencies starts at step 0. Otherwise its step is the maximum over its dependencies of: dependency's step + 1 for `service_started`, + 2 for `service_healthy` or `service_completed_successfully`. 7. **Result.** Return a list of waves: `waves[k]` is the sorted list of active services starting at step k, for k = 0 .. max step (steps nobody uses give `[]`). 8. **Scale.** A generated chain-and-fan stack with 3,000 services and dependency depth 2,000 must be planned in under 5 seconds on our shared test box (no `RecursionError`). On `compose.json` with defaults the answer is `[["db", "redis"], [], ["migrate"], [], ["app"], ["proxy"]]`. ## Scoring Hidden check groups (partial credit = fraction passed; all must pass): `basic_waves` (1, 6, 7), `profiles_and_targets` (3), `optional_and_disabled` (2, 3, 4A), `error_precedence` (4, exact code and detail; a detail sequence may be a tuple or a list), `conditions` (4B-C, 6), `cycles` (5, exact detail), `fixture_answer`, `randomized_agreement` (200 random small stacks: same waves, or same error code and detail), `scale` (8).