Test-Env Verification

The rule

When the project space has a test environment, a change MUST be verified on it — both backend and frontend — before the task is prepared for production deploy or archived. The verification is done autonomously: the agent discovers the test environment, ships the change to it, exercises it, and records the result, without asking the operator whether to test. Asking "did we test on the test env?" each task is the failure mode this gate exists to remove.

Distinct from prod-readiness-probe

This gate runs alongside prod-readiness-probe but checks a different thing: prod-readiness-probe checks runner symmetry (test↔prod sudoers/PATH/ports) — can prod accept the deploy. This gate checks functional behaviour on the deployed test build — does the change actually work end-to-end on a real environment. Both must pass before prod prep / archive for a behaviour-shipping task in a project that has a test environment.

When it's active

Armed when BOTH hold: (1) the change ships runtime behaviour (code, config, migration — not docs-only or framework-only), and (2) the project space declares a test environment or one is discoverable. Resolution chain: the space registry spaces/<space>/space.yml → test_environments[] (authoritative), then a CI heuristic (a deploy:test job gated on a branch push naming a test host). Neither found ⇒ verdict NO-TEST-ENV — recorded, not a pass. A docs-only / framework-only / infra-inventory task ⇒ verdict SKIP.

Autonomous procedure

1. Resolve the test environment(s) and record the source that resolved it.
2. Ship the change via the project's own deploy:test CI job — integrate onto the branch that triggers it (commonly dev). When the feature branch was cut from main and dev is far ahead, cherry-pick only the task's commits onto a throwaway worktree off origin/dev — never a blind feature→dev merge. Poll CI until green.
3. Exercise backend: health endpoint + at least one behaviour-bearing call touching the changed path. Prefer safe-mode (dry_run, read path) when the test env can mutate real external systems.
4. Exercise frontend: load the affected page/flow and confirm it renders/behaves. If auth is blocked by the test env, fall back to the deployed-bundle check + the component/live-render Playwright run from /dr-qa Layer 4f — do not silently skip.
5. Record everything under ### Layer 4h — Test-Environment Verification.

Verdicts

PASS (backend AND frontend exercised, behaviour confirmed), PASS_WITH_NOTES (verified with a recorded environment limitation), SKIP (no runtime behaviour), NO-TEST-ENV (none registered/discoverable), FAIL (not shipped to test, or broken). A FAIL is a hard block routing back to /dr-do or the deploy step; SKIP / NO-TEST-ENV never block but are recorded verbatim.

/dr-auto mode

Under DATARIM_AUTO_MODE=1 the gate runs without asking — "should I test on the test env?" is pre-resolved to yes. The only operator escalations permitted are the hard-gated boundary actions (a production deploy, or a billable/destructive external action with no safe-mode equivalent); everything else proceeds autonomously and is logged.