docs: correct shadow run status from evidence
ci / backend (push) Failing after 0s
ci / static (push) Failing after 5s
ci / backend (pull_request) Failing after 1s
ci / static (pull_request) Failing after 9s
Build & Test with Secrets / build (pull_request) Failing after 1s
ci / frontend (push) Successful in 3m42s
Build & Test with Secrets / security-scan (pull_request) Failing after 8s
Build & Test with Secrets / frontend (pull_request) Successful in 3m46s
ci / frontend (pull_request) Successful in 3m56s
ci / publish (push) Has been skipped
Build & Test with Secrets / notification (pull_request) Failing after 1s
ci / publish (pull_request) Has been skipped

This commit is contained in:
2026-08-06 14:11:22 +09:00
parent b0c6718ce9
commit c3242e3c67
2 changed files with 32 additions and 1 deletions
@@ -0,0 +1,31 @@
# PHASE-1-SHADOW-RUN status correction
## WBS traceability
- WBS: `PHASE-1-SHADOW-RUN`
- Requirement: `REQ-PLAT-001` / Gate 5a
- Source: `docs/CURRENT/WBS_EXECUTION_PROCEDURES.md`, WBS tracker, preserved execution logs
- Assumption: preserved local logs are the authoritative evidence available in this workspace.
- Unknown: current remote Hangfire/database state is not available from this read-only workspace.
- Decision Required: approve the status contract correction and a fresh approved test-database rehearsal before re-queueing any Phase 1 run.
## Observed evidence
- `logs/phase-1-execution.log`: enqueue attempts report failure and a critical queue failure.
- `logs/host-startup-20260804-173000.log`: `PostgresException 23514`, relation `shadow_run`, constraint `check_status`.
- Same log: `POST /api/shadow-runs responded 500`.
- `evidence/gate-5-signoff/PRODUCTION_READY_DECLARATION.md`: explicitly records that Job 893 was never actually started.
## Correct status
`PHASE-1-SHADOW-RUN` is `BLOCKED`, not `RUNNING`.
The prior RUNNING claim is not retained as execution evidence. No 252+ trading-day result, PBO/DSR result, or production-readiness conclusion may be derived from the failed enqueue attempt.
## Safe resolution sequence
1. Reconcile the active `shadow_run.check_status` constraint with the application status contract.
2. Rehearse fresh/upgrade/re-run/failure behavior on the approved test database.
3. Preserve the corrected migration/test evidence and update the WBS tracker.
4. Obtain explicit approval before re-queueing Phase 1.
5. Record a new Run ID/Job ID and only then set the WBS status to `RUNNING`.