Added huggingface_hub[oauth]>=1.0.0 to the runtime requirements so FastAPI OAuth via attach_huggingface_oauth(...) can initialize inside the Docker Space.
Keeps the V35 Docker/FastAPI custom UI startup model unchanged: one uvicorn server, custom UI at /, /custom alias.
Changelog
V35 — Docker FastAPI root custom UI startup
Switches the public product Space to sdk: docker.
Adds a Dockerfile running exactly one uvicorn process: uvicorn app:app --host 0.0.0.0 --port 7860.
Attaches Hugging Face OAuth directly to FastAPI with attach_huggingface_oauth.
Removes the Gradio-mounted debug app from the normal startup path.
Updates login/logout links to /oauth/huggingface/login and /oauth/huggingface/logout.
Keeps the custom dashboard at / and /custom.
V34 — Space startup fix
Removed the explicit uvicorn.run(app, host="0.0.0.0", port=7860) launcher from app.py.
Kept the custom FastAPI/ASGI app object exposed at module level so Spaces can run it without binding port 7860 twice.
Added a regression test to prevent reintroducing a second server start.
v32 — Mockup-aligned custom dashboard
Reworked the custom Build page to match the validated dashboard mockup.
Restored the Run Explorer as a first-class right-side panel on the main Build view.
Moved live progress into the main cockpit with compact progress metadata and a vertical timeline.
Added right-rail Run details, quick links, report preview, and “How it works” panels.
Kept the full Runs page for deeper run inspection while making recent runs visible from the home dashboard.
Preserved the V31 functional feedback, OAuth, bucket gating, and polling behavior.
Changelog
V33 — Root custom dashboard
Serve the custom dashboard directly at / and /custom.
Move the legacy Gradio controls behind /_gradio for OAuth/debug only.
Remove the product-facing Gradio iframe/preview experience.
Keep OAuth-backed API routes and custom dashboard behavior intact.
Add uvicorn as an explicit runtime dependency.
v31 — Functional feedback verification
Added stronger Custom UI feedback states so bucket checks, build launch, validation launch, and polling always show visible status.
Added client-side validation for required build fields and JSON validation payloads before launching Jobs.
Improved API error parsing so browser messages show clean backend errors instead of raw JSON blobs.
Added backend bucket preflight checks for /api/build and /api/validate to prevent Jobs from launching against a missing user bucket.
Added terminal-status handling so polling stops cleanly on manual_hardware_required, technical_blocker, full_inference_candidate_health_passed, and other final states.
Added last-polled visibility and non-blocking retry feedback for live progress.
v30 — Custom UI robustness cleanup
Fixed the custom UI flex layout to avoid horizontal overflow on laptop-width screens.
Removed duplicate auth-panel CSS and cleaned responsive behavior.
Made the Run Explorer horizontally scrollable on medium screens and card-like on mobile.
Restyled JSON textareas as monospace code inputs.
Made the ZeroGPU-first checkbox user-controllable.
Added build gating: users must check or create their private run bucket before launching a build from the custom UI.
Removed leftover mockup-only readiness behavior and replaced it with a real bucket status pill.
v25 — Custom UI OAuth bridge
Wired the /custom frontend to real OAuth-backed API endpoints.
Added custom UI actions for bucket check/create, build launch, validate launch, run progress polling, and run explorer.
Added /api/me, /api/bucket/status, /api/bucket/create, /api/build, /api/validate, /api/runs/{run_id}, and /api/runs/{run_id}/progress.
Added bucket run listing support for the Run Explorer.
Kept the Gradio UI as a fallback while the custom frontend is validated.
v24 — Custom UI shell + progress API skeleton
Added a custom product UI shell served at /custom with dedicated HTML/CSS/JS assets.
Added a live job progress visualization model based on events.jsonl.
Added /api/app-info, /api/progress/from-events, and a placeholder /api/runs endpoint for the upcoming custom frontend auth bridge.
Added a Custom UI preview tab while preserving the functional Gradio workflows as the source of truth.
Added tests for the custom shell assets and progress mapping.
V23 — Hardware-at-creation strategy
Requests Space hardware as early as possible via create_repo(..., space_hardware=...).
Falls back through ZeroGPU → preferred hardware → fixed GPU fallback before creating a default CPU Space.
Stops treating OAuth hardware errors as transient retries; if automatic hardware is not authorized, the run is marked manual_hardware_required and the user can validate after manual hardware selection.
V21 — Per-user bucket onboarding
Added Run storage controls to check or create the signed-in user's private run bucket from the UI.
Jobs now preflight the per-user bucket before launch and show a clear error if it is missing or inaccessible.
The app no longer requires users to leave the workflow to manually create space-factory-runs before first use.
v20 — Per-user Bucket isolation
Reverted to the V17 product UI baseline.
Replaced the hardcoded shared bucket source with a per-user bucket policy.
Jobs now mount <signed-in-username>/<bucket-name> dynamically.
Refresh/readback and artifacts links now use the signed-in user's bucket.
Added a Run Bucket name field to Build and Validate workflows.
Updated docs to require each user to create their own private space-factory-runs bucket.
v28 — Custom UI live polish
Added Run Explorer status filters and a manual refresh action.
Persisted the active run in browser localStorage so progress resumes after refresh.
Added a non-blocking polling warning when live progress cannot be refreshed.
Quick link buttons are available in both public workflows:
Build from model card
Validate existing Space
Kept the product workflow unchanged: ZeroGPU-first, fixed GPU fallback, manual hardware fallback, and existing-Space validation.
v16-product-links
Added quick links after launching jobs:
open HF Job in a new tab
open target Space in a new tab
open Space settings in a new tab
open run artifacts in the configured Bucket
Added the same link panel to both Build and Validate workflows.
v15-product-verified
Removed legacy phase launchers from product code.
Kept only the public workflows:
Build from model card
Validate existing Space
Cleaned documentation to match the public-preview product workflow.
Removed duplicate UI component in the build events tab.
Rechecked previously observed failure modes:
Gradio Client auth parameter compatibility
endpoint discovery instead of hardcoded /predict
generic README metadata sanitation
ZeroGPU-first with fixed-GPU/manual fallback
separate validation/smoke-test workflow
v14-product
Public product UI without experimental tabs.
Universal model-card builder and existing-Space validator.
V22 — dependency compatibility and build repair
Removed the obsolete generated-Space constraint huggingface_hub<1.0.0.
Generated Spaces now normalize Hub requirements to a modern compatible range (huggingface_hub>=0.34.0,<2.0.0, or >=1.5.0,<2.0.0 when Transformers 5.x is detected).
Added one automatic Pi repair pass when the generated Space fails build/runtime validation.
The repair pass collects Space build/runtime logs, asks Pi for a minimal patch, reuploads the workspace, and retries validation once.
Repair artifacts are stored under runs/<run_id>/repair/ and logs under logs/pi_repair_output.txt.
v27 — Custom run actions workflow
Adds selected-run actions in the custom Run Explorer.
Adds a manual hardware action panel in live progress.
Lets users prepare the Validate existing Space form directly from a selected run.
Keeps the Gradio fallback UI and backend workflow unchanged.
v26-custom-run-explorer
Expanded the custom UI Run Explorer from a simple list into a usable run-detail view.
Added per-run detail rendering for status, model, target Space, hardware, validation result, artifacts, and report preview.
Enhanced /api/runs/{run_id} and /api/runs/{run_id}/progress to expose inference_gate, generation_smoke, hardware_strategy, technical_blockers, file indexes, and normalized run summaries.
Added frontend rendering for validation metrics sourced from live progress and smoke-test artifacts.
Kept the Gradio fallback UI and core backend workflows unchanged.
v37 — Premium simplified custom UI
Simplified the Custom UI navigation to the two real product workflows: Run build and Test Space.
Kept the Run Explorer visible on the build dashboard instead of exposing it as a redundant tab.
Reworked the dashboard layout to feel closer to the validated premium mockup while reducing confusion.
Replaced ambiguous timeline dots with explicit step states: completed / active / pending / failed.
Fixed run artifact links to consistently target the run folder: runs/<run_id> inside the connected bucket.
Reduced persistent banners: success/info messages now auto-clear and the OAuth OK state is reflected in the header instead of a permanent banner.
Preserved the Docker/FastAPI Custom UI architecture, OAuth flow, per-user buckets, build Jobs, validation Jobs, and live polling.
V38 — Build/run separation and faster Run Explorer
Added an explicit Prepare new build action to separate the fresh build form from selected past runs.
Added a build mode notice explaining that selecting a run only changes progress/details and never mutates the build form.
Run Explorer filters and search now operate locally from a cached run list for a much snappier interaction.
Refresh now explicitly reloads the connected bucket; ordinary filter/search changes no longer re-query the bucket.
Selecting a run highlights it, switches the detail/progress context, and keeps the build form independent.
V42 — Product tabs and run recovery hardening
Renamed the custom UI top-level workflow tabs to the intended product model: New Build, Live Progress, and Space Test.
Kept the build form isolated from selected historical runs; selecting a run only updates Live Progress and details.
Hardened run discovery from the connected bucket by combining ls and targeted glob patterns so partial/in-progress runs are recovered more reliably.
Persisted launch.json, summary.json, and a minimal state.json immediately after a Job launch, so running Jobs appear in the Run Explorer before the worker writes final artifacts.
Progress polling now falls back to launch metadata when state.json/events.jsonl are not ready yet.
Job links are preserved or reconstructed from launch metadata for active and historical runs.
