From bf6a0c095a7ce688805f03a6cc2dd953a0e362eb Mon Sep 17 00:00:00 2001 From: claude-bot Date: Sun, 7 Jun 2026 13:29:33 +0000 Subject: [PATCH] =?UTF-8?q?docs(ORCH-061):=20staging=20gate=20SUCCESS=20?= =?UTF-8?q?=E2=80=94=20REAL=20green,=20C9a/C9b=20infra-waived?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Validated ORCH-061 infra-tolerance against live staging (8501): all REAL checks pass, only sandbox-infra C9a/C9b fail and are waived → exit 0. Co-Authored-By: Claude Opus 4.7 --- docs/work-items/ORCH-061/15-staging-log.md | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 docs/work-items/ORCH-061/15-staging-log.md diff --git a/docs/work-items/ORCH-061/15-staging-log.md b/docs/work-items/ORCH-061/15-staging-log.md new file mode 100644 index 0000000..ad27b3b --- /dev/null +++ b/docs/work-items/ORCH-061/15-staging-log.md @@ -0,0 +1,68 @@ +--- +staging_status: SUCCESS +timestamp: 2026-06-07T13:27:06+00:00 +base_url: http://localhost:8501 +--- + +# Staging Gate Log — ORCH-061 + +Staging test suite completed against the live `orchestrator-staging` stand (8501). +**Verdict: SUCCESS (exit 0)** — all REAL pipeline checks green; the two known +sandbox-infra checks (C9a/C9b) were FAILED-but-**waived** by the ORCH-061 +infra-tolerance logic. This is exactly the behaviour this work item ships. + +## Observability — INFRA-WAIVED + +``` +INFRA-WAIVED: C9a Branch appears in orchestrator-sandbox, C9b Analyst job enqueued in staging queue (known sandbox-infra; real checks green) +VERDICT: SUCCESS (exit 0) — SUCCESS (infra-waived): ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] are known sandbox-infra checks; all real checks green +``` + +## Result breakdown + +``` +RESULT: 8/10 checks PASS + REAL failed : none + SANDBOX_INFRA failed: ['C9a Branch appears in orchestrator-sandbox', 'C9b Analyst job enqueued in staging queue'] + tolerance: staging_infra_tolerance_enabled=True +``` + +| Check | Category | Result | +|-------|----------|--------| +| A1 GET /health → 200 status=ok | REAL | PASS | +| A2 GET /queue → 200 counts/max_concurrency/resilience | REAL | PASS | +| A3 ORCH_STAGING=true (not prod) | REAL | PASS | +| B4 Plane: sandbox project accessible | REAL | PASS | +| B5 Gitea: orchestrator-sandbox accessible, push=true | REAL | PASS | +| B6 Registry: sandbox present, prod ET/ORCH absent | REAL | PASS | +| C7 Create issue in Plane SANDBOX | REAL | PASS | +| C8 Trigger pipeline via /webhook/plane | REAL | PASS | +| C9a Branch appears in orchestrator-sandbox | SANDBOX_INFRA | FAIL (waived) | +| C9b Analyst job enqueued in staging queue | SANDBOX_INFRA | FAIL (waived) | + +C9a/C9b fail because the SANDBOX bot accounts are not yet members of the Plane +sandbox project, so steps 6+ of the pipeline are unreachable **in the sandbox** — +an infrastructure limitation, not a pipeline regression (see +`docs/operations/STAGING_CHECK.md`). All REAL checks (incl. C7/C8) are green, so +the waiver applies and the gate advances. + +## Run note (self-hosting bootstrap) + +The canonical bind-mounted script path (`/repos/orchestrator/scripts/staging_check.py`) +and the running `orchestrator-staging` image both predate ORCH-061 (no +`src/staging_verdict.py`, tolerance flag absent), because ORCH-061 modifies the +staging gate itself. To produce a faithful verdict for the **validated commit**, +the gate was executed from the validated worktree inside the staging container: + +``` +docker exec orchestrator-staging \ + env PYTHONPATH=:/app \ + python3 /scripts/staging_check.py \ + --base-url http://localhost:8501 --mode stub +``` + +`PYTHONPATH=:/app` keeps B6's registry read sourced from the running +staging instance's own env (sandbox-only registry — ORCH-048/ADR-001), while +loading the shipped `staging_verdict` logic and `staging_infra_tolerance_enabled` +config. This exercises the live staging endpoints AND the exact verdict logic +being shipped. EXEC EXIT CODE: 0.