From e85a088f85f7c9ce55217f797896c7ccb2cd46c1 Mon Sep 17 00:00:00 2001 From: mos-dt-0 Date: Fri, 31 Jul 2026 20:08:34 -0500 Subject: [PATCH] =?UTF-8?q?docs(remediation):=20bank=20D-21=20=E2=80=94=20?= =?UTF-8?q?a=20FAIL=20that=20means=20nothing=20is=20a=20green=20that=20mea?= =?UTF-8?q?ns=20nothing,=20sign-flipped?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ci-postgres reports FAIL under an overall-success pipeline on #2170 and #2175 while all eight functional steps pass. Most likely a service-pod teardown artifact; the test step's pg_isready fail-fast guard passed, so the database was available during the run. Low severity, but the pattern matters: a red that is routinely present and routinely correct to ignore trains operators and agents to discount reds, and the discounting generalises. Six instances of a meaningless green are already banked; a meaningless FAIL is the same erosion with the sign flipped. Recorded rather than normalised — the first time it is waved through without a note is when it becomes background noise. RM-55: treat a non-terminal-success sub-step under an overall-success pipeline as a reportable anomaly, and make the CI contract state which steps may fail without failing the pipeline. An implicit allowance is indistinguishable from a bug. Co-Authored-By: Claude Opus 5 (1M context) --- docs/remediation/TASKS.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/docs/remediation/TASKS.md b/docs/remediation/TASKS.md index 6d737813..305e3eba 100644 --- a/docs/remediation/TASKS.md +++ b/docs/remediation/TASKS.md @@ -93,6 +93,33 @@ and must not be cited as merge evidence. Rely on reviewer clearance + real CI. Three independent live instances in a single session — format gate, agent context reset, queue guard — is the class confirmed, not anecdote. +### D-21 — a service step reports FAIL under an overall-success pipeline (normalised red) + +Observed on pipelines **#2170** and **#2175** (not on #2158, #2167, or the manual #2171): the +`ci-postgres` **service** step reports **FAIL** (`pods "wp-svc-…-ci-postgres" not found`) while the +pipeline's overall status is **success** and all eight functional steps are `OK`. + +Most likely mechanism: the service pod is reachable during the run and has been reaped by the time its +terminal state is collected. Supporting evidence that the database really was available — the `test` +step runs `pnpm --filter @mosaicstack/db run db:migrate` behind a `pg_isready` loop written to fail fast +if Postgres never comes up, and that step passed. + +**Severity is low; the pattern is not.** A red that is _routinely_ present and _routinely_ correct to +ignore trains every operator and every agent to discount reds — and the discounting generalises to reds +that matter. This mission already has six instances of a green that meant nothing (D-5, D-6, D-10); +**a FAIL that means nothing is the same defect with the sign flipped.** Both erode the signal that gates +exist to carry. + +Not chased further because it is CI-infrastructure behaviour rather than repository code, and both +merges it touched had every functional step green with the overall status successful. **Recorded rather +than normalised**, which is the whole point: the first time this is waved through without a note is the +moment it becomes background noise. + +**Requirement on RM-55 (conformance harness):** treat a non-terminal-success sub-step under an +overall-success pipeline as a **reportable anomaly**, not a cosmetic artifact — and make the CI contract +state explicitly which steps are permitted to fail without failing the pipeline. An implicit allowance +is indistinguishable from a bug. + ### D-20 — the orchestrator's own documentation overclaimed, and a reviewer disproved it empirically `rev-974` blocked PR #1027 a second time. **The defect was not in the code — it was in this file**, at