Task · SKT-0005.10

Model real deployment readiness in Compose and status APIs

Description

Separate process-running, HTTP-ready, blueprint-loaded, lane-configured, first-attempt, and delivery-success states. Current Compose has no healthcheck and status entries exist only after push events, so running can look healthy while dry-run, skipped, not-yet-attempted, or failing.

Acceptance Criteria

Definition of Done

Implementation Plan

  1. Define failing tests for readiness states spanning active blueprints, writable persisted state, lane configuration/attempt/success/error/staleness, and fresh startup.\n\n2. Implement a dedicated readiness model and local endpoint while keeping shared handler/store wiring root-owned.\n\n3. Add Compose healthcheck and focused Compose/e2e coverage so up –wait cannot pass on PID state.\n\n4. Verify focused packages and Compose behavior, integrate with SKT-0005.09, obtain root CodeRabbit review, then run the full gate, inventory proof, and a deployment check.

Formatting correction to the preceding single-line rendering:

  1. Define failing tests for readiness states spanning active blueprints, writable persisted state, lane configuration/attempt/success/error/staleness, and fresh startup.
  2. Implement a dedicated readiness model and local endpoint while keeping shared handler/store wiring root-owned.
  3. Add Compose healthcheck and focused Compose/e2e coverage so up –wait cannot pass on PID state.
  4. Verify focused packages and Compose behavior, integrate with SKT-0005.09, obtain root CodeRabbit review, then run the full gate, inventory proof, and a deployment check.

Implementation Notes

Continuation authorized with a fresh CodeRabbit budget and live reference-stack/standing-host verification. Root owns all external writes and will record only de-identified evidence in this public tracker.

Baseline live proof before readiness implementation: a clean standing-host deployment of the pinned exact-head RC passed the focused dry-run gate (852 output lines, zero hard-error lines), then started one focused blueprint in live mode. The existing container reports only process Up state and /control/status is empty until first push, confirming the task premise. After one full metric interval plus delivery allowance, status showed four successful sink types and zero failures; cloud queries in the named context returned the declared native histogram, two substrate node series, application logs, and traces. This proves transport/landing only, not telemetry realism.

Wave A implementation complete pending standing-host verification. Readiness now gates on active blueprints, an atomic persisted-state write probe, configured lane attempts/current outcomes/staleness, and live delivery; Compose calls the binary healthcheck and allows one full 60-second emission interval plus delivery time. Container tests proved dry-run 503, unwritable-state 503 after successful delivery, and fresh 503 to live 200 across every intended lane. Three root CodeRabbit reviews were used; all Critical and Warning findings were fixed. Full make gate and dry-run inventory completed successfully.

Standing-host exact-head RC verification passed. The prior RC had process Up state, no healthcheck, and readiness 404. Compose up –wait on b6c4ea5 reached healthy only after /control/readiness reported one active blueprint, writable persisted state, and successful current attempts for loki, otlp, otlpmetrics, and promrw. A post-mutation restart repeated the transition; all lanes returned live_ready true with zero current errors, and a bounded cloud query returned fresh declared otlp-native metric samples after the deployment start.

Final Summary

Implemented delivery-aware readiness across the binary, status APIs, UI, runner, and Compose healthcheck. Verified fresh, dry-run, unwritable-state, and fake-sink container cases; focused tests, CodeRabbit, make gate, dry-run inventory, exact-head CI/image publish, Compose up –wait, restart, live sink success, and fresh landed metrics all passed.

References

View the source file on GitHub