Skip to main content

Phase 4 — ChangeOps Gates

Phase 4 introduces ChangeOps release gating so changes can be evaluated before rollout. Gates combine diff novelty, coverage, eval metrics, and budget signals to return allow/deny/follow-up outcomes, persist decisions as artifacts, and emit telemetry for audit / observability.

Highlights​

  • Deterministic gate engine – fleetforge-changeops crate evaluates diffs, coverage, eval metrics, and budgets with deterministic thresholds, returning allow, follow_up, or deny effects plus recommended follow-up actions.
  • Storage + artifacts – new change_gates / change_gate_followups tables capture request snapshots, scorecards, and follow-up acknowledgements. Gate payloads are emitted as JSON artifacts for downstream tooling.
  • API / CLI surface – gRPC adds CheckChangeGate, RecordGateFollowup, and ListChangeGates. fleetforge-ctl gates check|followup|list wraps these endpoints so pipelines and operators can drive gating flows.
  • Telemetry + audit – decisions and follow-ups are appended to the audit chain and logged via structured tracing (target=fleetforge.changeops) for OTEL export and UI surfacing.

Acceptance Criteria​

  • Gating evaluation can block, allow, or require follow-up before deploy.
  • Gate decisions persist in Postgres + object storage and emit OTEL events.
  • CLI (ff gates check|followup|list) returns JSON decisions/follow-ups for pipeline integration.
  • Follow-ups recorded through the API appear alongside decisions for UI/CLI.
  • Docs describe the ChangeOps flow and migrations (sqlx migrate run).

Notes​

  • New migration: sqlx migrate run applies 0014_changeops_gates.sql.
  • Gate engine thresholds default to high-novelty > 0.8 follow-up and eval slack of 5%. Tune via future config hooks.
  • Artifacts are tagged kind=change_gate_decision for reuse in tooling.
  • Telemetry spans use the change_gate namespace for easy filtering.