Prod-Readiness Probe

Overview

Prod-Readiness Probe is a blocking gate for deploy-class tasks — work that touches a deployment surface (systemd unit files, sudoers, CI cutover jobs, .env-deploy templates). It runs at two pipeline stages: /dr-qa Layer 4g (before the pipeline may propose merge) and /dr-archive Step 0.4 (before the task may be archived).

Why it exists

A deploy or cutover change can pass every test on the test runner and still fail on the first production command — the classic case is a production host whose sudoers lacks the NOPASSWD rules the test runner already has. The pipeline used to recommend merging and archiving such a change without ever checking whether the production runner was symmetric to the test runner. This gate forces that check: the framework predicts the production impact and verifies readiness before it recommends merge, and refuses to archive a task whose production rollout is incomplete or unverified.

What it checks

• sudoers symmetry — every NOPASSWD command shape the deploy needs exists on prod exactly as on test.
• PATH parity — the deploy/service user's PATH on prod matches test.
• Listening ports — the service's ports are free (or bound by the expected unit) on prod.
• Systemd units — required units exist and are enabled / running.
• Runtime versions — node / redis / other runtimes meet the declared floor.

Verdict vocabulary

SKIP (not deploy-class), PASS (symmetry verified), FAIL (asymmetry found — forbid merge / archive), BLOCKED (probe could not run and no operator confirmation — forbid merge / archive). BLOCKED never auto-resolves to PASS on an unreachable host; silence is not success.

Hybrid execution

When a project authors an optional datarim/deploy-readiness.yml contract (validated by a dedicated shell validator), the probe runs a deterministic three-way comparison — test runner actual vs prod runner actual vs declared. When the contract is absent, the probe falls back to an agent-driven checklist investigation over the same items. The framework core stays stack-agnostic; only the project-specific data lives in the optional contract.

Production is hard-gated

Every probe action is read-only — sudo -l, systemctl status, ss, redis-cli info server, node --version. The probe is a sensor, never an actuator: it performs no writes, no restarts, no sudoers edits. When it finds a gap it predicts the impact and reports it; remediation is an explicit operator action.

Loaded by

/dr-qa Layer 4g and /dr-archive Step 0.4, on deploy-class tasks only.