Upload 4 files

docs/ARCHITECTURE.md

@@ -177,9 +177,14 @@ The v120 UI makes the core blockage protocol visible in the Active Run panel. Wh
 
 This is intentionally separate from the activity feed. The activity feed remains an event stream, while Agent recovery explains the current agentic recovery strategy. The Run traces dock exposes the unified raw/redacted `agent_trace.jsonl` plus `REPAIR_DECISION.json`, the repair folder, and `BLOCKAGE.json` when present.
 
-## v121 latency/display cleanup
 
-- Reduced perceived latency when re-opening already inspected runs by reusing cached progress/detail payloads immediately and avoiding duplicate polling starts.
-- Added DOM render signatures for run documents, Agent recovery and Gradio endpoint panels to prevent flicker during polling.
-- Preserved heavy hydration in the background for full reports/artifacts while keeping the central panels responsive.
+## v122 stability note
 
+The v122 line intentionally rolls back the experimental v121 client-side caching/polling optimizations after real UI testing exposed flicker and broken build/run behavior. The app keeps the v120 Agent recovery UI and the v118/v119 core blockage protocol, but returns to the proven polling and run-selection model for production stability.
+
+## v123 — Critical Job launch + failure timeline fix
+
+- Fixed a production-critical HF Job startup failure where the large embedded worker script could make Python fail before startup with `argument list too long`.
+- The worker script is now persisted as `runs/<run_id>/_worker.py` in the mounted run bucket before launch, and the Job receives only `WORKER_SCRIPT_PATH`.
+- Kept a small `WORKER_SCRIPT_B64` fallback only for compatibility/manual launch paths; normal app launches no longer put the worker source in env/argv.
+- Added a failure-log fallback so pre-worker Job failures such as `argument list too long` still create an explicit failed timeline event and red failure point.

docs/NEXT_STEPS.md

@@ -81,9 +81,21 @@ The Gradio endpoint picker now mirrors the information we can recover from the v
 
 The UI now exposes Pi diagnosis/recovery state through the Active Run **Agent recovery** card and links to recovery decision/blockage artifacts. This helps users understand when the Factory is waiting for HF logs, rebuilding the same code, patching, requesting hardware, or declaring a technical blocker.
 
-## v121 latency/display cleanup
 
-- Reduced perceived latency when re-opening already inspected runs by reusing cached progress/detail payloads immediately and avoiding duplicate polling starts.
-- Added DOM render signatures for run documents, Agent recovery and Gradio endpoint panels to prevent flicker during polling.
-- Preserved heavy hydration in the background for full reports/artifacts while keeping the central panels responsive.
+## v122 stability note
 
+The v122 line intentionally rolls back the experimental v121 client-side caching/polling optimizations after real UI testing exposed flicker and broken build/run behavior. The app keeps the v120 Agent recovery UI and the v118/v119 core blockage protocol, but returns to the proven polling and run-selection model for production stability.
+
+## v123 — Critical Job launch + failure timeline fix
+
+- Fixed a production-critical HF Job startup failure where the large embedded worker script could make Python fail before startup with `argument list too long`.
+- The worker script is now persisted as `runs/<run_id>/_worker.py` in the mounted run bucket before launch, and the Job receives only `WORKER_SCRIPT_PATH`.
+- Kept a small `WORKER_SCRIPT_B64` fallback only for compatibility/manual launch paths; normal app launches no longer put the worker source in env/argv.
+- Added a failure-log fallback so pre-worker Job failures such as `argument list too long` still create an explicit failed timeline event and red failure point.
+
+## v124 — Timeline and Run Explorer stabilization
+
+- Fixed the compact Overall Progress timeline so dynamically visible repair/failure groups cannot wrap dots onto a second row.
+- Removed smooth timeline auto-scroll that could cause visible flicker during polling.
+- Simplified Run Explorer type/status badges to neutral type labels and short status labels such as Success, Failed, Running and Manual.
+- Added regression checks for timeline single-row behavior and compact Run Explorer labels.

docs/PUBLIC_PREVIEW.md

@@ -71,3 +71,9 @@ If a generated Space fails with HF build/runtime errors, especially empty logs o
 ### v120 note: Agent recovery visibility
 
 The UI now exposes Pi diagnosis/recovery state through the Active Run **Agent recovery** card and links to recovery decision/blockage artifacts. This helps users understand when the Factory is waiting for HF logs, rebuilding the same code, patching, requesting hardware, or declaring a technical blocker.
+
+
+## v122 stability note
+
+The v122 line intentionally rolls back the experimental v121 client-side caching/polling optimizations after real UI testing exposed flicker and broken build/run behavior. The app keeps the v120 Agent recovery UI and the v118/v119 core blockage protocol, but returns to the proven polling and run-selection model for production stability.
+