NEXT_STEPS.md

Next Steps

The current application is stable enough for a controlled production/public-preview deployment. The remaining work is mostly product hardening, observability, and cost transparency rather than core workflow repair.

Recommended before broad launch

1. Production smoke checklist

   • Run one build that reaches full_inference_success automatically.
   • Run one build that reaches manual_hardware_required, then validate after manual hardware selection.
   • Verify raw/redacted trace links, report link, smoke link, Space link, Settings link, Job link, and full Artifacts folder link.
   • Verify billing copy and links with a non-Pro and Pro account if possible.
   • Verify the pre-scan default Tongyi-MAI/Z-Image-Turbo returns a positive verdict and still launches successfully.

2. Cost guardrails

   • Add optional per-launch confirmation when fixed GPU fallback is enabled.
   • Add clearer copy that Jobs and Inference Providers may consume paid compute.
   • Consider a local user-configurable max validation attempts / max build duration.

3. Trace safety review

   • Add regression examples for token-like strings in raw traces and expected redacted output.
   • Keep redacted traces clearly labeled as best-effort.

4. Repair workflow

   • Add a user-triggered repair run that reads Space build/runtime logs, asks Pi for a minimal patch, uploads the patch, and re-runs validation.
   • Keep repair runs separate from initial build runs in the Run Explorer.

5. Validation presets

   • Add presets per pipeline/task: text-to-image, text-generation, image-to-image, ASR, TTS, embeddings, etc.
   • Prefill endpoint args/kwargs from discovered Gradio schema when confidence is high.

6. Run retention controls

   • Add bulk cleanup for old failed validation runs.
   • Add optional retention copy in the Run Stats panel.

7. Pre-scan quality

   • Keep adding known-good and known-risk model-card fixtures.
   • Use scan results to recommend implementation mode and validation presets.
   • Add clearer detection for custom Diffusers pipelines that are valid but require special generated code.

Nice-to-have UI improvements

• Add a compact preview for generated output artifacts when the smoke test returns an image/audio/video/file.
• Consider optional filters for build runs versus validation runs in the compact Run Explorer if histories become large.
• Add a “failed only” quick filter from Run Stats.
• Add keyboard shortcuts for refresh and tab switching.

Current product workflow

Build from model card
→ private generated Space
→ best-effort ZeroGPU/fixed GPU assignment
→ live health/API checks
→ measured inference latency when live smoke succeeds
→ ZeroGPU duration recommendation when applicable
→ manual hardware selection if required
→ Space Test validation
→ full_inference_success when output type and latency are validated

v113 follow-up notes

The UI now treats the model pre-scan as the build gate, not the manual Space name. If the user leaves the target Space name empty, the backend generates a safe slug from the run ID. Future work could expose the generated name in the launch confirmation before the Job starts, but it should not block the launch.

The Gradio endpoint picker now mirrors the information we can recover from the validation Job's gradio_client schema: endpoint name, inputs, outputs, and parameter hints. The action is intentionally named Set API name because it copies the selected endpoint into the validation form rather than launching the validation immediately.

v114 follow-up notes

• The event feed now uses inline SVG icons. A future polish pass can add a full event details drawer, but the compact feed should remain readable and avoid emoji/text marker fallbacks.

Repair workflow follow-ups

• Add richer recovery analytics from REPAIR_DECISION.json, same-code rebuild outcomes, and Gradio client traces.
• Surface INCIDENT_BRIEF.md, REPAIR_DECISION.json, REPAIR_PLAN.md, and REPAIR_SUMMARY.md previews directly in the UI when recovery was attempted.
• Consider allowing a second recovery action only when the first action clearly changed the evidence category and the new decision is strongly justified.

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.

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.

v127 — Billing usefulness + UI event/timeline audit

• Reworked the Billing & compute card into an actionable compute checklist: payment readiness, Pi Inference Providers, build Job cost, generated Space hardware and high-tier GPU guardrails.
• Kept exact spend/quotas delegated to the Hugging Face Billing dashboard instead of inventing usage totals.
• Audited JS event bindings for one-shot/delegated listeners across navigation, run rows and timeline scroll.
• Reduced timeline auto-scroll churn: identical timeline renders no longer force keep-visible scrolling after user interaction.
• Confirmed run selection keeps the immediate cached/optimistic render path before network hydration.