Upload 6 files

docs/RELEASE_VALIDATION.md

@@ -1,4 +1,4 @@
-# Release Candidate Validation — v189.7
+# Release Candidate Validation — v189.9
 
 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.
 
@@ -29,7 +29,7 @@ This archive is based on `agentic-space-factory-v188-7.zip` and hotfixes partial
 - 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`.
+- The default ASF app/eval version is centralized in `src/version.py` and defaults to `v189.9`.
 - 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.
@@ -62,19 +62,19 @@ After deploying this archive, run the same Z-Image style scenario again and chec
 - `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
+## v189.9 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
+## v189.9 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
+## v189.9 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.
@@ -82,15 +82,22 @@ Validate that `timeline_model` is present on run view payloads and correctly dis
 - Legacy timeline fallback remains available when no canonical model is present.
 
 
-## v189.7 timeline state validation
+## v189.9 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
+## v189.9 visual polish 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.
+
+
+## v189.9 visual polish validation
+
+- Recovery phase details are compact and point to Agent recovery for detailed diagnosis.
+- Run notes replaces duplicated Pi-model-warning banners and does not show opaque +N counters.
+- Runtime guardrails from v189.7/v189.8 remain unchanged.