---
staging_status: FAILED
timestamp: 2026-06-05T21:30:45Z
base_url: http://localhost:8501
mode: stub
result: 9/10 checks PASS
exit_code: 1
---

# Staging Gate Log — ORCH-047

Staging test suite **FAILED**: 9/10 checks passed, exit code 1.

## Verdict

The live staging service on `:8501` is healthy and the full E2E pipeline ran
correctly against the **sandbox** project (issue created → webhook accepted →
branch created in `orchestrator-sandbox` → analyst job enqueued → cleanup OK).

The single failing check is **B6 — Registry isolation**: the project registry as
seen by the test harness still contains the production projects
(`enduro-trails`, `ORCH`) and does **not** isolate to the sandbox project only.
This violates the staging isolation requirement (CLAUDE.md: "staging — только
sandbox-проект"). Because the staging gate returned a non-zero exit code, the
machine verdict is `FAILED` and the task is rolled back to `development`.

### Notes for follow-up (development)

- B6 imports `src.projects.known_plane_project_ids()` and asserts the registry
  contains the sandbox id (`8c5a3025-…`) while the prod ids
  (`7a79f0a9-…` ET, `8da6aa25-…` ORCH) are absent. It observed
  `sandbox=NO, prod-ET=YES(BAD!), prod-ORCH=YES(BAD!)`.
- This is a staging-environment / registry-isolation signal, not a verdict on the
  ORCH-047 code change itself (which targets the `check_tests_passed` gate).
  Investigate whether the staging container's isolated project registry env is
  loaded, or whether the harness's in-process registry import is reading the host
  (`/repos/orchestrator`) prod env instead of the container's env.
- Deployer did **not** modify any production infrastructure, registry, `.env`,
  or `docker-compose.yml` to alter this result (per deployer mandate).

## Full test output

```
============================================================
  ORCH-33 Staging Check Suite
  base_url : http://localhost:8501
  mode     : stub
  utc_time : 2026-06-05T21:30:45.071676+00:00
============================================================

[Block A] SMOKE
  ✓ PASS  A1 GET /health → 200 status=ok  [HTTP 200, body={'status': 'ok', 'service': 'orchestrator'}]
  ✓ PASS  A2 GET /queue → 200 with counts/max_concurrency/resilience  [HTTP 200, keys=['counts', 'max_concurrency', 'poll_interval', 'resilience', 'recent']]
  ✓ PASS  A3 ORCH_STAGING=true (not prod)  [ORCH_STAGING=true]

[Block B] ACCESS
  ✓ PASS  B4 Plane: sandbox project accessible  [HTTP 200, found 5 project(s), sandbox=YES]
  ✓ PASS  B5 Gitea: orchestrator-sandbox accessible, push=true  [HTTP 200, permissions={'admin': True, 'push': True, 'pull': True}]
  ✗ FAIL  B6 Registry: sandbox present, prod ET/ORCH absent  [sandbox=NO, prod-ET=YES(BAD!), prod-ORCH=YES(BAD!)]

[Block C] E2E  (mode=stub)
  ·      C7: Creating issue in SANDBOX project...
  ✓ PASS  C7 Create issue in Plane SANDBOX  [HTTP 201, issue_id=5040c202-592f-45d0-9463-ca1e9944e6ba]
  ·      C8: Triggering pipeline via POST /webhook/plane ...
  ·        Using HMAC signature (secret len=40)
  ✓ PASS  C8 Trigger pipeline via /webhook/plane  [HTTP 200, resp={'status': 'accepted'}]
  ·      C9a: Polling for branch in orchestrator-sandbox (up to 60s)...
  ✓ PASS  C9a Branch appears in orchestrator-sandbox  [branch=feature/SANDBOX-010-staging-check-e2e-20260605t213]
  ·      C9b: Checking staging job queue for analyst job (up to 30s)...
  ·        (Plane comment check skipped: bot-tokens not added to SANDBOX project)
  ✓ PASS  C9b Analyst job enqueued in staging queue  [job_id=6, status=queued, agent=analyst]

[CLEANUP]
  ✓ PASS  CLEANUP: deleted branch 'feature/SANDBOX-010-staging-check-e2e-20260605t213' (HTTP 204)
  ✓ PASS  CLEANUP: deleted Plane issue 5040c202-592f-45d0-9463-ca1e9944e6ba (HTTP 204)
  ·      CLEANUP DB: no task row found for plane_id=5040c202-592f-45d0-9463-ca1e9944e6ba
  ·      CLEANUP DB dedup: no such table: events_dedup

============================================================
  RESULT: 9/10 checks PASS
============================================================
EXIT_CODE=1
```
