[9-71]

Summary

This PR integrates the Studio frontend clients and unified launcher on top of the previously merged Studio core, runtime, and FastAPI service work (#310, #312, #313, #316).

It connects React, the zero-build console, and Gradio Jobs UI to the same HTTP task service while preserving the existing synchronous inference workflow.

Changes

1. HTTP-backed Studio clients

• React console (/console/): Improves asynchronous job state synchronization, polling, log pagination, error recovery, and artifact handling.
• Zero-build console (/): Updates job monitoring, delayed-response handling, and terminal log draining without requiring a frontend build.
• Gradio Jobs UI: Uses the shared REST service for job submission, status, logs, cancellation, and artifacts. Preserves the selected download artifact across background synchronization.

All three clients consume the existing /api/v1/jobs API rather than managing task lifecycles independently.

2. Unified launcher

Extends start_studio.py to provide a single local entry point for the API service and Gradio UI.

• Reuses an existing compatible local service when available.
• Otherwise starts and owns a service subprocess.
• Supports cooperative shutdown and process-tree cleanup.
• Preserves ownership boundaries: externally managed services are never terminated by the launcher.
• Validates trusted local configuration and retains compatibility with existing F1_* settings.

3. UI module organization and compatibility

Moves Studio-specific Gradio implementations from f1/ui/ into studio/ui/, retaining compatibility imports for existing consumers.

The original synchronous Gradio inference path remains available.

4. Tests, CI, and documentation

• Adds React frontend regression tests.
• Adds Python client, Gradio, launcher, and process lifecycle tests.
• Introduces the Studio Frontend GitHub Actions workflow.
• Extends existing Studio CI coverage.
• Documents client entry points, launcher behavior, configuration, and verification in docs/studio/frontend.md.
• Clarifies combined-launcher dependencies and manual acceptance scope in the frontend and service documentation.

Broader cross-PR documentation consolidation is reserved for the separate Documentation PR.

Architecture

The ownership boundary remains:

UI clients → REST API → Studio JobsManager / Runtime

This PR does not introduce another lifecycle owner, replace the existing execution engine, or redesign the REST contract.

Verification

Automated CI — PASS

The implementation and test revision 2c8d722c passed both Studio CI workflows, with 5/5 jobs successful:

Workflow	Coverage	Result
Studio Core	Ubuntu + Windows; pytest, doctest, Ruff, format, codespell	PASS
Studio Frontend	Ubuntu + Windows Python tests; React tests, lint, build	PASS

The subsequent documentation-only commit 00e679f8 passed local git diff --check, targeted codespell, and isolated MkDocs strict checks for the two modified pages. It did not trigger new Studio CI runs because the workflows use path filters.

The Linux cooperative-shutdown test was investigated with timestamped diagnostics. Its test-only cooperative grace period was adjusted from 1 to 5 seconds, without changing production Runtime behavior, fallback timing, or lifecycle assertions.

Manual acceptance — PASS (Windows)

Verified using real UI and HTTP interactions:

• Prediction, cancellation, failure handling, and terminal-state synchronization across clients.
• Slow API responses, stale-response handling, and reconnect behavior.
• Multi-page log polling and terminal log-tail completion.
• Nested artifact downloads and file integrity.
• Gradio 64 MiB non-image artifact download, including selection preservation across five natural background synchronization cycles and SHA256 verification.
• Existing synchronous inference, launcher shutdown/restart, and external API reuse.

Manual acceptance evidence is scoped to the verified Windows candidate and environment; it does not establish broader platform or training support.

Review guidance

The largest file-level changes include a relocation from f1/ui/ to studio/ui/. These are primarily module-organization changes; reviewers may find it easier to examine the compatibility wrappers separately from the behavioral changes.

Suggested review order:

1. start_studio.py — launcher and service ownership.
2. studio/ui/ and f1/ui/ — Gradio implementation and compatibility.
3. web/ and frontend/ — HTTP client behavior.
4. tests/studio/, web/scripts/, and CI workflows — regression coverage.
5. docs/studio/frontend.md and docs/studio/service.md — client setup, launcher behavior, and acceptance scope.

How to run

Install the Studio service and UI dependencies from a source checkout (Python 3.10+):

pip install -e ".[studio]" gradio pandas

Start the combined local service and Gradio UI:

python start_studio.py

Alternatively, start the API and zero-build console:

python main_engine.py

Frontend checks:

cd web
npm ci
npm test
npm run lint
npm run build

Python checks:

python -m pytest tests/studio tests/f1/ui -q

See docs/studio/frontend.md for more details.

Scope and limitations

This PR focuses on local, single-service Studio usage. Public hosting, authentication, and multi-user isolation are out of scope.

GPU/AMP, DDP, and broader platform validation remain separate acceptance gates.

[9-71]

PR #317 is ready for review.

CI triage for 00e679f8:

• Studio Core, Studio Compatibility, and both Python frontend/launcher jobs passed.
• All eight failures in the general CI workflow have matching baseline failures on upstream main.
• The browser-clients job failed during npm ci with ECONNRESET, before any frontend tests ran. The same checks passed on the fork.

I don't have permission to rerun upstream Actions. Could a maintainer rerun the failed browser-clients job when convenient?

The remaining platform/training limitations are documented separately. No PR-specific regression has been identified in the completed checks.

Thanks for reviewing!

[isLinXu]

LGTM