Spaces:
Running on CPU Upgrade
Running on CPU Upgrade
| # Release Candidate Validation — v189.7 | |
| This archive is based on `agentic-space-factory-v188-7.zip` and hotfixes partial progress plus Space log diagnostics before deployment for the v188 sequence. | |
| ## Validation date | |
| 2026-06-06 | |
| ## Automated checks | |
| - Pytest suite: expected full pass from the archive root. | |
| - JavaScript syntax: | |
| - `web/static/app.js` | |
| - `web/static/runs.js` | |
| - `web/static/progress.js` | |
| - `web/static/api.js` | |
| - `web/static/components.js` | |
| - Python compile check: | |
| - `app.py` | |
| - `src/*.py` | |
| ## Critical v188 regression checks | |
| - `full_inference_candidate_health_passed` and `health_only` are partial validation states, not green full-success states. | |
| - `/health` validation from `gradio_client` maps to `health_passed=true` in the inference gate and eval record. | |
| - Generation smoke tests prefer `INFERENCE_CONTRACT.json` payloads, then Gradio schema introspection, then generic fallbacks. | |
| - Smoke test payloads include required text/image arguments such as `negative_prompt` when discovered in the schema. | |
| - Smoke failures classify validator request errors separately from generated-app runtime errors. | |
| - Eval records use schema `1.2` and expose `process_completed`, `verdict`, `outcome`, `validation`, `failure_owner`, and `failure_reason`. | |
| - Backend eval archive publication is observable through `eval_publish_status.json` and is not confused with run-local `eval_record.json` creation. | |
| - Active Run hides cancel actions for terminal/partial states and renders partial validation, eval publish, report, recovery and hardware fallback consistently. | |
| - The default ASF app/eval version is centralized in `src/version.py` and defaults to `v189.7`. | |
| - Space log collection writes `logs/space_logs_index.json`, `logs/space_runtime_snapshot.json`, and `logs/space_log_diagnostics.json`. | |
| - Runtime/build logs are marked unavailable with a clear reason when neither SDK nor REST log collection works. | |
| - Backend progress payloads keep partial terminal states visually partial/warn, not success. | |
| - Space log diagnostics only extract `first_error` from real available runtime/build logs, never from `[ASF_LOG_UNAVAILABLE]` placeholders. | |
| ## Live-run scenario covered | |
| The v188 sequence was driven by the live run: | |
| ```text | |
| universal-20260606-181620-5f6004b8 | |
| ``` | |
| Expected honest verdict for that class of run: | |
| ```text | |
| Completed with partial validation. | |
| Space created and repaired. | |
| /health passed. | |
| Generation smoke failed only if the real generation call still fails after schema-aware payload construction. | |
| Eval archive publication must be separately observable. | |
| ``` | |
| ## Manual validation recommendation | |
| After deploying this archive, run the same Z-Image style scenario again and check: | |
| - Active Run top badge says partial only when generation remains unverified. | |
| - The smoke payload file includes `negative_prompt`. | |
| - `health_passed` is true when `/health` passes. | |
| - The eval archive bucket receives a dated record, or `eval_publish_status.json` explains why it did not. | |
| ## v189.7 validation | |
| Validate that `timeline_model` is present on run view payloads and correctly distinguishes full-inference success from partial validation. Eval archive sidebar restoration from v188.9 must remain intact alongside the per-run Eval archive card. | |
| ## v189.7 semantic progress validation | |
| - Active Run progress uses `timeline_model.progress` when available. | |
| - The progress bar represents process completion; the badge/result represents the verdict. | |
| - A 100% partial validation renders as warning/amber, not success/green. | |
| - Legacy payloads without `timeline_model` continue to render through the previous fallback. | |
| ## v189.7 mobile timeline validation | |
| - Active Run renders the canonical `timeline_model` as phase steps plus `timelinePhaseDetails`. | |
| - Mobile layouts switch the canonical timeline to a vertical single-column list. | |
| - Phase details expose the active phase summary, details, and “Needs attention” warnings without changing worker/runtime behavior. | |
| - Legacy timeline fallback remains available when no canonical model is present. | |
| ## v189.7 timeline state validation | |
| - Terminal full-inference success runs must not leave early phases such as Start in `running` because of historical `started` events. | |
| - Resolved log collection warnings must not keep Deploy in warning when the final logs index reports full quality. | |
| - The active phase should focus the most useful terminal proof, especially Live test for full-inference success, while non-blocking warnings remain grouped separately. | |
| ## v189.7 runtime sanitation validation | |
| - README python_version is quoted and normalized to a safe value. | |
| - torch is added when app.py imports torch. | |
| - failed timeline phases prefer confirmed eval publication and final build blockers. | |