Start fresh deployments with no selected blueprints

Description

A fresh synthkit installation must not emit the bundled example catalog without an explicit operator selection. Bundled blueprints remain available examples, while the runtime starts in a usable setup state until exact blueprint names or the explicit all-catalog selector are configured.

Acceptance Criteria

• #1 Empty or unset BLUEPRINT_NAMES selects no blueprints; exact names select only those blueprints; BLUEPRINT_NAMES=* explicitly selects the complete available catalog; unknown requested names still fail with available-name diagnostics.
• #2 An intentionally empty selection starts the control plane without emitting synthetic telemetry and logs a prominent actionable warning, while an attempted selection whose blueprints all fail still fails startup.
• #3 Readiness and Docker health distinguish setup-required from degraded: the fresh control plane remains usable and healthy, but is never reported live-delivery-ready until an active blueprint has delivered successfully.
• #4 The operator UI presents a clear fresh-start empty state stating that no synthetic telemetry is emitted and shows how to select a bundled blueprint and restart.
• #5 Environment defaults, Compose, README, quickstart, configuration/reference documentation, troubleshooting/runbook material, and operational skills consistently document no-selection, exact-name, and explicit-all behavior plus upgrade guidance.
• #6 Focused Go and UI tests cover selection, setup startup/readiness, strict failure behavior, and empty-state guidance; the final repository gate and an explicit-name dry-run inventory pass.

Definition of Done

• #1 make gate (build vet test race rw-proto-check spdx-check forbidden-words)
• #2 make blueprint-schema (only if a blueprint field or construct/workload config struct changed)
• #3 Docker Compose setup mode is exercised with no blueprint selection and its control-plane health behavior is verified.
• #4 DRY_RUN=true BLUEPRINT_NAMES=‘*’ go run ./cmd/synthkit -once -dump — complete-catalog inventory diffed against signals/

Implementation Plan

Solo topology: root owns the selection contract, runtime/readiness integration, UI, documentation and skills, tracker, review, commits, pushes, release/deployment verification, and final evidence. No auxiliary lanes: the seams are tightly coupled and the active harness contract does not authorize delegation.\n\n1. RED/GREEN selection semantics through public config/source interfaces: empty selects none, * explicitly selects all, exact lists stay strict, and missing requested names still fail with available names. Preserve the distinction between intentional empty and attempted-but-failed loading.\n2. RED/GREEN setup-mode startup and readiness: permit intentional zero without building/ticking synthetic lanes, log one actionable warning, keep failed selected loads fatal, and expose a non-degraded setup-required state that passes container health while remaining not live-delivery-ready.\n3. RED/GREEN operator UI: replace the generic empty inventory message with an explicit no-emission fresh-start state and exact select/restart guidance; render setup-required readiness separately from degraded.\n4. Align .env/Compose defaults, README, quickstart, getting-started, blueprint/config/CLI/control-plane/runbook/troubleshooting/FAQ/upgrade guidance, and repository operational skills. Use BLUEPRINT_NAMES=* as the migration escape hatch and keep focused examples explicit.\n5. Run focused Go/UI/Compose checks, review the final diff adversarially for accidental emission, unhealthy setup containers, and silent upgrade behavior, run CodeRabbit because runtime/UI logic changes, then run make gate, explicit-name dry-run inventory, and a Docker Compose no-selection health exercise.\n6. Commit and push only owned paths, preserve docs.toml, wait for exact-head CI and release publication if triggered, then migrate and verify the standing deployment without changing its explicit otlp-native selection.

Rendered plan (format correction; supersedes the escaped rendering above):

1. RED/GREEN selection semantics through public config/source interfaces: empty selects none, * explicitly selects all, exact lists stay strict, and missing requested names still fail with available names. Preserve intentional-empty versus attempted-but-failed loading.
2. RED/GREEN setup-mode startup and readiness: permit intentional zero without synthetic lanes, log one actionable warning, keep failed selected loads fatal, and expose setup-required as container-healthy but never live-delivery-ready.
3. RED/GREEN operator UI: show explicit no-emission fresh-start and exact select/restart guidance; distinguish setup-required from degraded.
4. Align env/Compose defaults, product docs, migration guidance, and operational skills.
5. Run focused checks, adversarial diff review, CodeRabbit, make gate, explicit-name inventory, and Docker no-selection health verification.
6. Commit/push owned paths, preserve docs.toml, verify exact-head CI/release, then upgrade the standing deployment while preserving its explicit otlp-native selection.

Implementation Notes

Local verification complete before push:

• CodeRabbit review completed with 4 issues; all 4 were verified and fixed (tracker full-catalog command, getting-started selection wording, self-observability clarification, retained-log verification).
• make gate passed: build, vet, full Go tests, race, RW2 proto drift, SPDX, and forbidden-words.
• make gate-ui passed: 22 files and 166 tests plus TypeScript/Vite production build.
• make docs-check and make skills-check passed.
• Empty one-shot emitted the actionable warning and zero inventory; exact otlp-native loaded 1 blueprint and 664 metric names; explicit * loaded 26 blueprints and 2,653 metric names.
• Isolated Docker Compose project was healthy with setup_required=true, ready=true, live_ready=false, zero loaded/active, writable state, and zero inventory. Rendered Overview and Health pages showed Setup required and the no-emission guidance. Browser testing found readiness lanes serializing as null; a red regression test was added, the API was corrected to emit [], and the actual page then rendered successfully.
• make blueprint-schema was not run because no blueprint field or construct/workload config struct changed.

Final publication and standing-deployment verification:

• Exact-head CI run 32410309065 passed every required job for 25853ca678bb1d05a484fd262e6ec14c6faec0fe, including E2E.
• Prerelease v1.3.0-rc.20 targets that exact commit; the multi-architecture image manifest is sha256:8a8e82cb6ee244f05b99b58320f44660f2345830a88f8a6e7daa06258127c7d0.
• The standing deployment was upgraded with its explicit otlp-native selection preserved. Source is clean at the exact commit; the credential file is mode 0600; persisted state is owned by runtime uid/gid 65532:65532 with mode 0700.
• Final control-plane verification returned ready=true, live_ready=true, setup_required=false, one loaded/active blueprint, writable persisted state, and successful Loki, OTLP, native OTLP metrics, and PromRW lanes with zero failures.
• Authenticated UI redirect followed to HTTP 200 and rendered Overview/Health as healthy/ready. Recent retained logs contained no export, authentication, authorization, or permission failure patterns.
• Authenticated Grafana Explore verification found fresh declared metrics, logs, and traces plus current self-observability metrics, startup/heartbeat logs, and tick/cycle/flush traces.

Final Summary

Fresh installations now start in a healthy setup-required state with no selected blueprints and no synthetic emission; exact names and explicit * selection retain strict behavior. The runtime, readiness contract, UI guidance, environment defaults, docs, runbooks, and operational skills were aligned and covered by focused Go/UI/Compose tests, full local gates, CodeRabbit, exact-head CI including E2E, RC publication, and a successful standing-deployment upgrade with live Grafana landing verification.