Spaces:
Running on CPU Upgrade
Running on CPU Upgrade
Upload 5 files
Browse files
README.md
CHANGED
|
@@ -1,5 +1,9 @@
|
|
| 1 |
---
|
| 2 |
title: Agentic Space Factory
|
|
|
|
|
|
|
|
|
|
|
|
|
| 3 |
sdk: docker
|
| 4 |
hf_oauth: true
|
| 5 |
hf_oauth_expiration_minutes: 1440
|
|
@@ -13,531 +17,112 @@ hf_oauth_scopes:
|
|
| 13 |
- read-billing
|
| 14 |
---
|
| 15 |
|
| 16 |
-
#
|
| 17 |
-
|
| 18 |
-
Pi generation, diagnosis, and structured repair prompts now share the same ASF/gist dependency contract. Platform-owned packages such as Gradio, Gradio Client, Hugging Face Hub, Spaces, and hf_xet must stay current and worker-owned. Model-specific pins remain allowed only with evidence from the model card or concrete build logs. Prompts also reinforce the gist-compatible guidance to avoid torch/torchaudio pins, leave torchvision unpinned when it must resolve against the managed torch runtime, vendor non-pip-installable model code, and treat live Space build logs as authoritative instead of local dependency experiments. This pass is prompt-only and does not change launch, repair-loop, validation, or UI gating behavior.
|
| 19 |
-
|
| 20 |
-
|
| 21 |
-
|
| 22 |
-
## Pass 191.6 — Repair Outcome Classification
|
| 23 |
-
|
| 24 |
-
Repair now writes cumulative `repair_outcome.json` and `repair/REPAIR_OUTCOME.json` artifacts. These preserve whether a repair was triggered, which action was selected, whether a patch was applied, whether upload succeeded, and whether post-repair validation passed, failed, or became inconclusive due to OAuth expiry. This pass is classification-only: it does not add new repair loops or change Space Test behavior.
|
| 25 |
-
|
| 26 |
-
|
| 27 |
-
## Pass 191.4 UI token lifetime badge
|
| 28 |
-
|
| 29 |
-
The custom UI now displays a safe HF OAuth lifetime badge and warns before long builds when the session expiry is unknown or close to expiring. Raw tokens are never displayed.
|
| 30 |
-
|
| 31 |
-
## v191.3 — OAuth Expiration Hardening
|
| 32 |
-
|
| 33 |
-
- Extends `hf_oauth_expiration_minutes` from 480 to 1440 minutes to reduce mid-run OAuth expiry during long build/repair cycles.
|
| 34 |
-
- Adds redacted token expiry metadata to `token_context.json` when the runtime token is a decodable OAuth/JWT token.
|
| 35 |
-
- Writes `auth_status.json` and phase-scoped `auth_probes/*.json` before auth-sensitive phases, with `auth_refresh_required` used instead of generic failure when a token is expired or too close to expiry.
|
| 36 |
-
- Keeps opaque or non-decodable tokens supported by marking expiry as `unknown` rather than blocking the run.
|
| 37 |
-
|
| 38 |
-
|
| 39 |
-
## v191.2 — Contract-aware Generation Smoke
|
| 40 |
-
|
| 41 |
-
- Respects `INFERENCE_CONTRACT.json` / `TECHNICAL_BLOCKERS.json` when Pi declares `full_inference_implemented=false`, avoiding misleading fallback calls to `/generate` for boot-only blocker Spaces.
|
| 42 |
-
- Writes a terminal `tests/generation_smoke.json` with `status="skipped"`, `skip_reason="contract_declared_no_full_inference"`, and a blocker-specific `next_action` instead of a generic schema-adjusted retry hint.
|
| 43 |
-
- Adds `technical_blocker_boot_only` as a first-class blocked terminal subtype while preserving the existing technical-blocker UI semantics and manual-hardware gating.
|
| 44 |
-
|
| 45 |
-
## v191.1 — Platform Dependency Policy
|
| 46 |
-
|
| 47 |
-
- Normalizes platform-owned Gradio/HF runtime dependencies before upload and repair re-upload, preventing stale generated pins from conflicting with the current Spaces runtime.
|
| 48 |
-
- Adds `requirements_policy.json` and richer `requirements_sanitize` events to explain removed pins, injected platform lines, and preserved model-specific pins.
|
| 49 |
-
- Strengthens Pi and Repair briefs so Gradio is updated by patching app.py, not by downgrading the Gradio stack; model-specific pins remain allowed when justified by the model card or concrete build logs.
|
| 50 |
-
|
| 51 |
-
## v190.33 Linked validation terminal summary consistency
|
| 52 |
-
|
| 53 |
-
- v190.33 rewrites linked Space Test validation `summary.json` at the end of success and failure paths, so validation runs no longer remain listed as `running` after `state.json` has terminalized.
|
| 54 |
-
- Validation list/detail views continue to canonicalize from state and diagnostic artefacts, but the lightweight bucket summary is now terminal-consistent for manual audits and Runs Explorer cards.
|
| 55 |
-
|
| 56 |
-
## v190.32 Robust linked validation schema parsing
|
| 57 |
-
|
| 58 |
-
- v190.32 hardens linked Space Test payload resolution when Gradio endpoint schemas contain heterogeneous parameter lists such as bare strings mixed with dict objects. The validation worker now normalizes schema parameters before reading metadata, preventing payload-resolution crashes like `'str' object has no attribute 'get'`.
|
| 59 |
-
- Replay mode now fails fast with a clear launch error if a successful parent automatic-smoke payload cannot be resolved, instead of silently downgrading to endpoint-discovery-first while still presenting itself as replay.
|
| 60 |
-
|
| 61 |
-
## v190.32 Eval archive run-scoped reset and layout stability
|
| 62 |
-
|
| 63 |
-
- v190.32 makes the Active Run eval archive card strictly run-scoped: launching, deleting, or switching Build Runs clears stale eval archive state before the selected run snapshot arrives.
|
| 64 |
-
- The eval archive key/value layout now uses a stable single-column grid with safe wrapping so long bucket names and record paths never collapse into letter-by-letter columns.
|
| 65 |
-
|
| 66 |
-
|
| 67 |
-
## v190.32 Runs Explorer linked validation parent metadata
|
| 68 |
-
|
| 69 |
-
- v190.32 makes Build Run cards display manual linked validation state directly from parent metadata (`manual_validation_status.json` / `linked_validations.json`), so the summary is visible even when linked Validation Runs are not listed as standalone rows. Automatic smoke status remains separate from manual linked validation status.
|
| 70 |
-
|
| 71 |
-
## v190.32 Replay uses parent smoke artefact as source of truth
|
| 72 |
-
|
| 73 |
-
- v190.32 makes linked Space Test replay mode load the parent Build Run's successful automatic smoke artefacts before attempting any schema reconstruction. The validation worker writes `replay_source.json`, `resolved_validation_request.json`, and diagnostics so a replay cannot fail opaquely at the Payload stage.
|
| 74 |
-
|
| 75 |
-
## v190.32 Linked validation hardening
|
| 76 |
-
|
| 77 |
-
- v190.32 hardens linked Space Test success/failure paths: parent Build Run updates read API/output metadata from the smoke result, failed manual attempts cannot downgrade an already validated parent, and latency/ZeroGPU recommendations expose their linked-test hardware provenance.
|
| 78 |
-
- Runs Explorer and Run Stats now treat automatic and effective statuses explicitly so manually validated partial builds remain discoverable in both Partial and Validated views.
|
| 79 |
-
- Space Test is contextualized from the selected Build Run even before pressing Prefill, while remaining linked-only for launches.
|
| 80 |
-
|
| 81 |
-
|
| 82 |
-
## v190.16 Cascade delete linked Space Tests
|
| 83 |
-
|
| 84 |
-
- Build Run deletion now removes linked Space Test validation runs from the run bucket as part of the same cleanup.
|
| 85 |
-
- Linked validation deletion keeps the parent Build Run but refreshes its manual validation metadata.
|
| 86 |
-
- Runs Explorer remains Build-first and clears parent/child rows from cache immediately after deletion.
|
| 87 |
-
|
| 88 |
-
## v190.16 Build-first explorer compatibility
|
| 89 |
-
|
| 90 |
-
- v190.16 keeps Runs Explorer simple: Build Runs are the primary objects, linked Space Tests are summarized on their parent, and legacy/incomplete Build Runs remain visible without requiring validation metadata.
|
| 91 |
-
- It hardens the run cache against null or partial records and keeps validation runs out of the primary explorer by default.
|
| 92 |
-
|
| 93 |
-
## v190.16 smoke retry and live validation telemetry
|
| 94 |
-
|
| 95 |
-
- v190.16 keeps Space Test prefill disabled until a build has reached a final Space state that can be tested manually.
|
| 96 |
-
- v190.16 retries generation smoke once when Gradio reports schema-choice type mismatches, and writes terminal summary.json plus live_status.json for cleaner audits.
|
| 97 |
-
- The canonical run snapshot now includes a `live_validation` telemetry model so the Live test phase can show Space build/runtime, health, Gradio endpoint discovery and generation smoke state instead of a generic running message.
|
| 98 |
-
- Active polling runs at a faster visible cadence for smoother event updates.
|
| 99 |
-
|
| 100 |
-
## v190.10 live convergence validation
|
| 101 |
-
|
| 102 |
-
- Active Run polling, Runs Explorer cards, Run Stats, and Eval Archive must converge to the same terminal snapshot without a browser refresh.
|
| 103 |
-
- Intermediate fallback/live wait failures are diagnostics only; they must not mark the run failed unless the canonical timeline is terminal.
|
| 104 |
-
|
| 105 |
-
## v190.6 — Space Test terminal-state lock
|
| 106 |
-
|
| 107 |
-
- v190.6 prevents terminal Space Test validations from oscillating back to Running/Pending when slower index or poll responses arrive later.
|
| 108 |
-
- The Space Test panel now keeps the terminal detail visible while refreshing, and the Runs Explorer uses the locked terminal status for the same validation id.
|
| 109 |
-
|
| 110 |
-
## v190.5 — Active Run timeline hotfix
|
| 111 |
-
|
| 112 |
-
- v190.5 fixes the Active Run canonical timeline after the v190.0 fit-to-width pass: desktop/tablet rendering is horizontal again, active steps pulse correctly, and `pi_run` started/running keeps Agent in progress instead of complete.
|
| 113 |
-
|
| 114 |
-
## v190.1 — Space Test validation UI
|
| 115 |
-
|
| 116 |
-
- v190.1 gives Space Test its own validation timeline, fixes validation runs stuck as Running in Run Explorer, and humanizes Gradio endpoint schema rendering so `[object Object]` never appears.
|
| 117 |
-
|
| 118 |
-
## v190.0 — Active Run layout consolidation
|
| 119 |
-
|
| 120 |
-
- v190.0 is a UI-only consolidation pass: it reduces Active Run redundancy, fits the canonical timeline into the center column, keeps Recovery details compact when Agent recovery is present, and improves recovery text wrapping.
|
| 121 |
-
|
| 122 |
-
## v189.9 — Timeline polish and Run notes clarity
|
| 123 |
-
|
| 124 |
-
- v189.9 keeps the v189.8 runtime guardrails and visual polish, then tightens the remaining UI details: Recovery phase details stay compact when Agent recovery is present, Run notes is the single place for non-blocking warnings, and opaque +N note counters are removed.
|
| 125 |
-
|
| 126 |
-
## v189.8 — Failed run UI polish
|
| 127 |
-
|
| 128 |
-
Timeline state hotfix lineage: this release keeps the v189.6 timeline cleanup and adds runtime guardrails.
|
| 129 |
-
|
| 130 |
-
- Adds `run_timeline_model.v1`, a canonical projection of run artifacts/events into product phases.
|
| 131 |
-
- Separates process completion from final verdict so a completed run can be success, partial, failed, blocked, or manual-action-required.
|
| 132 |
-
- Defines stable phases for Start, Model, Agent, Hardware, Deploy, Live test, Recovery, Archive, and Done.
|
| 133 |
-
- Preserves validated v188.9 runtime behavior while preparing the UI for a cleaner timeline/progress redesign.
|
| 134 |
-
- Keeps the global Eval archive storage panel separate from the per-run Eval archive publication panel.
|
| 135 |
-
- v189.4 adds Mobile timeline polish: a compact active phase detail panel, vertical canonical timeline on narrow screens, and readable Needs attention summaries.
|
| 136 |
-
- v189.8 keeps the v189.7 runtime guardrails and polishes failed-run UI: one Run notes banner, compact Recovery details, final build blocker focus, and contextual latency messaging.
|
| 137 |
-
|
| 138 |
-
|
| 139 |
-
## v181 — Backend-published private eval archive
|
| 140 |
-
|
| 141 |
-
- Keeps the operator eval bucket private and mounted only on the ASF Space, not on per-user Jobs.
|
| 142 |
-
- User Jobs now write only `runs/<run_id>/eval_record.json` and `events_compact.jsonl` into the signed-in user's run bucket.
|
| 143 |
-
- The ASF backend copies validated, anonymized records from user run buckets into the private operator archive mounted at `/evals`.
|
| 144 |
-
- This lets all users contribute anonymized eval records without giving their Jobs direct write access to `fffiloni/agentic-space-factory-evals`.
|
| 145 |
-
|
| 146 |
-
## v175 — Anonymous cross-run evaluation archive
|
| 147 |
-
|
| 148 |
-
- Introduced the optional operator-owned evaluation archive; v181 changes publication to backend-copy instead of Job-mounted writes.
|
| 149 |
-
- Workers write local `eval_record.json` plus a compact event timeline with hashed run/user/Space identifiers, structured hardware/Pi/recovery/validation metrics, and no raw generated code, prompts, tokens, or private bucket paths.
|
| 150 |
-
- Controlled by `ASF_EVAL_ENABLED`, `ASF_EVAL_BUCKET_SOURCE`, `ASF_EVAL_BUCKET_PATH`, `ASF_EVAL_BUCKET_MOUNT`, and `ASF_EVAL_SALT`.
|
| 151 |
-
- The Run storage card now indicates whether anonymous project evaluation is enabled for the instance.
|
| 152 |
-
|
| 153 |
-
## v174 — Bucket run-prefix mount and robust worker bootstrap writes
|
| 154 |
-
|
| 155 |
-
- Mounts only the `runs/` bucket prefix into Jobs at `/output/runs`, while the worker still writes to `/output/runs/<run_id>/...`.
|
| 156 |
-
- Keeps API-side writes on canonical `hf://buckets/<namespace>/<bucket>/runs/<run_id>/...` object URIs, with `HfFileSystem` attempts followed by a `sync_bucket` fallback for fresh prefixes.
|
| 157 |
-
- Removes the v172 parent-prefix `makedirs()` workaround, because Bucket prefixes are virtual object paths rather than git-style folders.
|
| 158 |
-
- Requires `huggingface_hub[oauth]>=1.11.0` so Buckets, Jobs volumes and sync helpers are available in fresh installs.
|
| 159 |
-
|
| 160 |
-
## v172 — Fresh bucket writes and pre-scan polish
|
| 161 |
-
|
| 162 |
-
- Keeps the Hugging Face Space metadata at the very top of `README.md`, so the app cannot boot with a configuration error after archive edits.
|
| 163 |
-
- Makes Bucket writes resilient for fresh run prefixes by creating parent prefixes before writing `_worker.py`, launch metadata, state, summaries, and events.
|
| 164 |
-
- Refreshes the Model pre-scan card into a calmer status panel with compact metadata chips and less oversized green treatment.
|
| 165 |
-
|
| 166 |
-
## v170 — Real bucket recursive run deletion
|
| 167 |
-
|
| 168 |
-
- DELETE `/api/runs/{run_id}` now removes concrete bucket objects under `runs/<run_id>/` using recursive discovery instead of relying only on virtual-folder deletion.
|
| 169 |
-
- The API returns a cleanup report with deleted and remaining object counts.
|
| 170 |
-
- Frontend cache invalidation remains as a protection layer, but deletion is now a real backend bucket cleanup.
|
| 171 |
-
|
| 172 |
-
|
| 173 |
-
## Anonymous eval archive activation
|
| 174 |
-
|
| 175 |
-
Recommended setup for a private cross-user archive:
|
| 176 |
-
|
| 177 |
-
```text
|
| 178 |
-
Bucket source: fffiloni/agentic-space-factory-evals
|
| 179 |
-
Bucket path: evals
|
| 180 |
-
Space mount: /evals
|
| 181 |
-
Mode: read-write
|
| 182 |
-
```
|
| 183 |
-
|
| 184 |
-
Then sign in as the bucket owner and click **Enable eval archive** in the Run Storage card. ASF writes:
|
| 185 |
-
|
| 186 |
-
```text
|
| 187 |
-
/evals/.asf_eval_config.json
|
| 188 |
-
```
|
| 189 |
-
|
| 190 |
-
The archive bucket stays private. User Jobs do **not** mount it. Instead:
|
| 191 |
-
|
| 192 |
-
```text
|
| 193 |
-
User Job
|
| 194 |
-
→ writes runs/<run_id>/eval_record.json in the user's private run bucket
|
| 195 |
-
|
| 196 |
-
ASF backend
|
| 197 |
-
→ reads that anonymized record
|
| 198 |
-
→ publishes it to /evals/YYYY/MM/DD/<anonymous_run_id>/eval_record.json
|
| 199 |
-
```
|
| 200 |
-
|
| 201 |
-
Environment variables remain supported as an admin override:
|
| 202 |
-
|
| 203 |
-
```env
|
| 204 |
-
ASF_EVAL_ENABLED=true
|
| 205 |
-
ASF_EVAL_BUCKET_SOURCE=fffiloni/agentic-space-factory-evals
|
| 206 |
-
ASF_EVAL_BUCKET_PATH=evals
|
| 207 |
-
ASF_EVAL_BUCKET_MOUNT=/evals
|
| 208 |
-
ASF_EVAL_SALT=<long-random-secret>
|
| 209 |
-
ASF_EVAL_INCLUDE_REDACTED_TAILS=false
|
| 210 |
-
ASF_EVAL_INCLUDE_MODEL_ID=false
|
| 211 |
-
```
|
| 212 |
|
| 213 |
-
|
| 214 |
|
| 215 |
-
|
| 216 |
|
| 217 |
-
|
| 218 |
-
- **v168** refreshes Pi assistant model choices and surfaces requested/effective provider model routing in Active Run.
|
| 219 |
-
- **v165** fixes fresh-install recovery failures, README metadata preservation, timeline failure anchoring, premium pre-scan/progress polish, and broader Pi assistant model choices.
|
| 220 |
-
- **v161** fixes duplicate delete modal triggers and stuck `Deleting…` states with single-flight delete guards.
|
| 221 |
|
| 222 |
-
#
|
| 223 |
|
| 224 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 225 |
|
| 226 |
-
|
| 227 |
|
| 228 |
```text
|
| 229 |
-
model card
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 230 |
```
|
| 231 |
|
| 232 |
-
|
| 233 |
-
|
| 234 |
-
- Creates private generated Spaces under the signed-in user's namespace.
|
| 235 |
-
- Launches long-running build and validation work as Hugging Face Jobs.
|
| 236 |
-
- Uses Pi with a coding model served through Hugging Face Inference Providers.
|
| 237 |
-
- Injects the configured GitHub gist as Pi's operational instruction source.
|
| 238 |
-
- Stores each run in a per-user private Storage Bucket.
|
| 239 |
-
- Attempts ZeroGPU first when requested, then optional fixed-GPU fallback.
|
| 240 |
-
- Supports manual hardware selection when automatic assignment is unavailable. Automatic fallback avoids high/restricted tiers such as A100/H200; use Space Settings manually if an account or organization has access.
|
| 241 |
-
- Distinguishes bootability from real inference.
|
| 242 |
-
- Measures live inference latency when a generation smoke test succeeds.
|
| 243 |
-
- Uses measured latency to recommend `@spaces.GPU(duration=...)` when the generated Space uses ZeroGPU.
|
| 244 |
-
|
| 245 |
-
## Current UI
|
| 246 |
-
|
| 247 |
-
The product root `/` is a custom Docker/FastAPI dashboard. `/custom` is kept as an alias.
|
| 248 |
-
|
| 249 |
-
The UI is organized into three main areas:
|
| 250 |
-
|
| 251 |
-
## v122 stability note
|
| 252 |
-
|
| 253 |
-
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.
|
| 254 |
-
|
| 255 |
-
### Left column
|
| 256 |
-
|
| 257 |
-
- **Run storage** — check or create the signed-in user's private Bucket.
|
| 258 |
-
- **New Build** — starts from `Tongyi-MAI/Z-Image-Turbo` by default, fast pre-scans the model card, then launches a private Space build only after an acceptable scan verdict.
|
| 259 |
-
- **Billing & compute** — show payment readiness, link to HF Billing, and centralize the compute-cost note for Jobs, Inference Providers, and safe hardware fallbacks.
|
| 260 |
-
|
| 261 |
-
### Center workspace
|
| 262 |
-
|
| 263 |
-
Two tabs share the main detail area:
|
| 264 |
-
|
| 265 |
-
- **Active Run** — build progress, run actions, Space/Settings/Job/Artifacts links, manual hardware guidance, inference latency, a vector-icon latest-events feed, and curated trace documents.
|
| 266 |
-
- **Space Test** — validation run details, actionnable Gradio endpoint picker, endpoint params, validation status, latency, point-based progress, and validation actions.
|
| 267 |
-
|
| 268 |
-
Selecting a build run opens `Active Run`. Selecting a validation run opens `Space Test`. The Runs Explorer is intentionally compact: each row prioritizes the model or Space, status, relative freshness, and a secondary context line while keeping the raw run ID available in the row.
|
| 269 |
|
| 270 |
-
|
|
|
|
|
|
|
|
|
|
| 271 |
|
| 272 |
-
|
| 273 |
-
- **Run Stats** — aggregate metrics across indexed runs: totals, success/pass rates, validation latency median/p95, and issue counts.
|
| 274 |
|
|
|
|
| 275 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 276 |
|
| 277 |
-
|
| 278 |
-
|
| 279 |
-
When a build or runtime blockage appears, the Active Run panel shows an **Agent recovery** card. It summarizes Pi's diagnosis decision, the selected recovery action (`wait_for_logs`, `factory_rebuild_same_code`, `patch_code`, manual hardware, or blocker), key evidence, and the next step. This makes the blockage protocol visible without turning the UI into a raw log viewer.
|
| 280 |
-
|
| 281 |
-
The Run traces dock also links to the unified `agent_trace.jsonl`, the diagnosis `REPAIR_DECISION.json`, repair artifacts, and blockage details when they exist.
|
| 282 |
-
|
| 283 |
-
## Model pre-scan
|
| 284 |
-
|
| 285 |
-
New builds are gated by a fast model-card pre-scan. The scan is metadata-only and does not download model weights. It checks:
|
| 286 |
-
|
| 287 |
-
- model-card guidance and runnable usage examples;
|
| 288 |
-
- Diffusers signals such as `library_name`, `model_index.json`, pipeline class, and `from_pretrained(...)` examples;
|
| 289 |
-
- safetensors versus unsafe or legacy weight formats;
|
| 290 |
-
- gated/private access and unsupported task signals;
|
| 291 |
-
- custom-code indicators such as `auto_map`, custom pipeline files, or `trust_remote_code` hints.
|
| 292 |
-
|
| 293 |
-
Verdicts are intentionally product-facing: `safe` and `caution` allow launch, `risky` requires explicit acknowledgement, and `unsupported` blocks launch. `Tongyi-MAI/Z-Image-Turbo` is treated as the known-good default example because it has a clear Diffusers model card and works in the app's default test flow.
|
| 294 |
-
|
| 295 |
-
## Run storage
|
| 296 |
-
|
| 297 |
-
Each signed-in user writes to their own private Storage Bucket. The default bucket is:
|
| 298 |
-
|
| 299 |
-
```text
|
| 300 |
-
https://huggingface.co/buckets/<your-username>/space-factory-runs
|
| 301 |
-
```
|
| 302 |
-
|
| 303 |
-
For local dev or deployment, configure only the bucket name; the namespace is derived from the signed-in OAuth user:
|
| 304 |
-
|
| 305 |
-
```bash
|
| 306 |
-
SPACE_FACTORY_BUCKET_NAME=space-factory-runs
|
| 307 |
-
SPACE_FACTORY_BUCKET_MOUNT=/output
|
| 308 |
-
```
|
| 309 |
-
|
| 310 |
-
Typical run layout:
|
| 311 |
|
| 312 |
```text
|
| 313 |
-
runs/<run_id>/launch.json
|
| 314 |
runs/<run_id>/state.json
|
| 315 |
runs/<run_id>/summary.json
|
| 316 |
runs/<run_id>/events.jsonl
|
| 317 |
runs/<run_id>/report.md
|
|
|
|
|
|
|
| 318 |
runs/<run_id>/generated/
|
| 319 |
runs/<run_id>/tests/
|
| 320 |
runs/<run_id>/artifacts/
|
| 321 |
-
runs/<run_id>/traces/raw/
|
| 322 |
-
runs/<run_id>/traces/raw/agent_trace.jsonl
|
| 323 |
-
runs/<run_id>/traces/redacted/
|
| 324 |
-
runs/<run_id>/traces/redacted/agent_trace.jsonl
|
| 325 |
runs/<run_id>/logs/
|
|
|
|
| 326 |
```
|
| 327 |
|
| 328 |
-
##
|
| 329 |
-
|
| 330 |
-
### 1. Build from model card
|
| 331 |
-
|
| 332 |
-
Paste a Hugging Face model ID or model-card URL. The app launches an HF Job that:
|
| 333 |
-
|
| 334 |
-
- fetches model metadata and repo information;
|
| 335 |
-
- writes a strict `GOAL.md` for Pi;
|
| 336 |
-
- asks Pi to follow the configured GitHub gist before coding;
|
| 337 |
-
- generates a Gradio app;
|
| 338 |
-
- creates and uploads a private Space;
|
| 339 |
-
- attempts ZeroGPU/fixed-GPU assignment when requested;
|
| 340 |
-
- runs health/API checks and a live generation smoke test when possible;
|
| 341 |
-
- writes events, report, traces, and structured artifacts to the user's Bucket.
|
| 342 |
-
|
| 343 |
-
### 2. Validate Space
|
| 344 |
-
|
| 345 |
-
Validation is a separate HF Job. Use it after a build succeeds or after manually selecting hardware in Space Settings.
|
| 346 |
-
|
| 347 |
-
The validation job:
|
| 348 |
-
|
| 349 |
-
- waits for the target Space;
|
| 350 |
-
- discovers Gradio endpoints when possible;
|
| 351 |
-
- calls the selected endpoint;
|
| 352 |
-
- checks the returned output type;
|
| 353 |
-
- stores returned artifacts;
|
| 354 |
-
- measures latency;
|
| 355 |
-
- recommends a conservative ZeroGPU duration when relevant;
|
| 356 |
-
- writes validation state, events, report data, and smoke-test artifacts.
|
| 357 |
|
| 358 |
-
|
| 359 |
|
| 360 |
-
|
| 361 |
-
|
| 362 |
-
|
| 363 |
-
|
| 364 |
-
|
| 365 |
-
|
| 366 |
-
|
| 367 |
-
## Guarantees
|
| 368 |
-
|
| 369 |
-
- Generated Spaces are private by default.
|
| 370 |
-
- Nothing is published automatically.
|
| 371 |
-
- Runs are persisted in the configured per-user Storage Bucket.
|
| 372 |
-
- The app distinguishes health checks from full inference validation.
|
| 373 |
-
- Hardware assignment is best-effort and can fall back to manual user action.
|
| 374 |
-
- Raw and redacted Pi traces are kept separate.
|
| 375 |
-
|
| 376 |
-
### Unified agent trace
|
| 377 |
-
|
| 378 |
-
Pi can be invoked more than once during a run: the initial build, a blockage diagnosis pass, and an optional structured repair patch. The Factory now writes a canonical run-level agent journal to `traces/raw/agent_trace.jsonl` and `traces/redacted/agent_trace.jsonl` so those phases read as one auditable agentic loop instead of separate conversations. Specialized stdout logs remain available under `logs/`, but the Active Run `Pi RAW` / `Pi redacted` buttons prefer the unified trace when it exists.
|
| 379 |
-
|
| 380 |
-
|
| 381 |
-
## Non-goals and limits
|
| 382 |
-
|
| 383 |
-
The app does not guarantee that every model card becomes a working Space. Some models require multi-GPU execution, Docker, unavailable CUDA extensions, external services, accepted licenses, very large hardware, or manual fixes.
|
| 384 |
-
|
| 385 |
-
The app does not mirror live spend/quota totals from Hugging Face Billing. Users should consult the HF Billing dashboard for exact usage.
|
| 386 |
-
|
| 387 |
-
## Local development
|
| 388 |
-
|
| 389 |
-
Install dependencies and run tests:
|
| 390 |
-
|
| 391 |
-
```bash
|
| 392 |
-
pip install -r requirements.txt
|
| 393 |
-
pytest
|
| 394 |
```
|
| 395 |
|
| 396 |
-
The
|
| 397 |
-
|
| 398 |
-
## Documentation
|
| 399 |
-
|
| 400 |
-
See:
|
| 401 |
-
|
| 402 |
-
- `docs/ARCHITECTURE.md`
|
| 403 |
-
- `docs/PUBLIC_PREVIEW.md`
|
| 404 |
-
- `docs/SECURITY.md`
|
| 405 |
-
- `docs/NEXT_STEPS.md`
|
| 406 |
-
|
| 407 |
-
|
| 408 |
-
Default example model: `Tongyi-MAI/Z-Image-Turbo`. It is treated as a known-good Diffusers text-to-image model for the fast pre-scan calibration and public-preview smoke tests.
|
| 409 |
-
|
| 410 |
-
### Pi diagnosis and structured recovery
|
| 411 |
-
|
| 412 |
-
When the generated Space fails live validation, the factory now enters a diagnosis-first blockage protocol instead of asking Pi to patch immediately. The worker collects HF build/runtime logs, Space status and validation errors, writes `repair/INCIDENT_BRIEF.md`, then asks Pi/Qwen Coder to choose one bounded action in `repair/REPAIR_DECISION.json`: wait for delayed logs, inspect again, force a same-code factory rebuild, patch code, request manual hardware, or declare a technical blocker.
|
| 413 |
-
|
| 414 |
-
A code repair is allowed only when Pi selects `patch_code` and the Factory accepts the decision. Empty/no-reason HF failures are routed through wait/rebuild/blocker paths rather than speculative code edits. Patch repair still writes `REPAIR_BRIEF.md`, `REPAIR_PLAN.md`, and `REPAIR_SUMMARY.md`, uploads once, then revalidates the live Space with the normal API checks.
|
| 415 |
-
|
| 416 |
-
Repair mode is intentionally strict: it must preserve the original model and real-inference contract, avoid fake/static outputs, keep a cheap health endpoint, and report blockers instead of hiding runtime errors.
|
| 417 |
-
|
| 418 |
-
## v123 — Critical Job launch + failure timeline fix
|
| 419 |
|
| 420 |
-
|
| 421 |
-
- 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`.
|
| 422 |
-
- 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.
|
| 423 |
-
- 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.
|
| 424 |
|
| 425 |
-
|
| 426 |
|
| 427 |
-
-
|
| 428 |
-
- Removed smooth timeline auto-scroll that could cause visible flicker during polling.
|
| 429 |
-
- Simplified Run Explorer type/status badges to neutral type labels and short status labels such as Success, Failed, Running and Manual.
|
| 430 |
-
- Added regression checks for timeline single-row behavior and compact Run Explorer labels.
|
| 431 |
|
| 432 |
-
##
|
| 433 |
|
| 434 |
-
|
| 435 |
-
- Kept exact spend/quotas delegated to the Hugging Face Billing dashboard instead of inventing usage totals.
|
| 436 |
-
- Audited JS event bindings for one-shot/delegated listeners across navigation, run rows and timeline scroll.
|
| 437 |
-
- Reduced timeline auto-scroll churn: identical timeline renders no longer force keep-visible scrolling after user interaction.
|
| 438 |
-
- Confirmed run selection keeps the immediate cached/optimistic render path before network hydration.
|
| 439 |
|
|
|
|
| 440 |
|
|
|
|
| 441 |
|
| 442 |
-
|
| 443 |
-
|
| 444 |
-
Run traces now renders as a horizontal document dock: compact source-file icons for Pi traces, repair decisions, reports, smoke results, and blockers. Agent recovery remains the human-readable recovery summary; the dock is the raw source-file vault.
|
| 445 |
-
|
| 446 |
-
|
| 447 |
-
## v164 timeline
|
| 448 |
-
|
| 449 |
-
The Active Run timeline uses compact product milestones backed by exact worker steps. Grouped milestones expose clockwise partial progress rings and substep counts, while recovery details remain in Agent recovery and source files remain in Run traces.
|
| 450 |
-
|
| 451 |
-
### v167 note: run artifact manifest
|
| 452 |
-
|
| 453 |
-
The worker writes `runs/<run_id>/artifact_manifest.json` as the source of truth for run artifacts. This lets the API expose Run traces from what the worker actually wrote, including failed runs where the Space was created but later entered build/runtime error.
|
| 454 |
-
|
| 455 |
-
## v171 notes
|
| 456 |
-
|
| 457 |
-
Run deletion now supports an explicit opt-in option to delete the associated generated Space for build runs. Validation run deletion remains run-artifact-only by default. The Run Storage card also summarizes bucket setup errors so fresh installs remain visually clean.
|
| 458 |
-
|
| 459 |
-
|
| 460 |
-
## v187 note
|
| 461 |
-
|
| 462 |
-
Signed-out users can see the public eval archive status for this ASF instance, while management actions remain restricted to the instance owner/admins.
|
| 463 |
-
|
| 464 |
-
## v189.4 notes
|
| 465 |
-
|
| 466 |
-
The run view model now exposes `timeline_model`, which summarizes progress, verdict, phase status, and non-blocking warnings without replacing the existing UI yet. Eval archive sidebar restoration from v188.9 remains carried forward.
|
| 467 |
-
|
| 468 |
-
|
| 469 |
-
### v189.4 Semantic progress bar
|
| 470 |
-
|
| 471 |
-
The Active Run progress header now separates pipeline completion from product verdict. A run can be 100% complete while still being partial, failed, or requiring manual action.
|
| 472 |
-
|
| 473 |
-
## v190.9 — Space Test canonical validation persistence
|
| 474 |
-
|
| 475 |
-
- v190.9 makes terminal Space Test validation status survive page reloads. Failed, success, partial, and manual validation outcomes override stale `running` launch metadata in the Runs Explorer, delete modal, and progress polling.
|
| 476 |
-
|
| 477 |
-
## v190.32 Eval archive effective outcomes
|
| 478 |
-
|
| 479 |
-
- Eval archive records now distinguish automatic verdicts from effective verdicts after linked Space Test validation.
|
| 480 |
-
- Archived records include anonymized linked-validation, endpoint-discovery and smoke-retry metrics while preserving privacy constraints.
|
| 481 |
-
- Instance owners can flush all archived eval records from the mounted eval bucket without deleting the eval archive configuration.
|
| 482 |
-
|
| 483 |
-
## v190.32 Linked validation replay reliability
|
| 484 |
-
|
| 485 |
-
- Linked Space Test validations now normalize replay/complete/recover payloads against the current Gradio schema before predict().
|
| 486 |
-
- Validation runs write explicit preflight, resolved request, schema coercion, and failure diagnosis artifacts for debugging.
|
| 487 |
-
- Replay from a full-inference-success Build Run should reuse the validated endpoint/payload and coerce Gradio dropdown/radio choices as needed.
|
| 488 |
-
|
| 489 |
-
|
| 490 |
-
## v190.32 validation hardening
|
| 491 |
-
|
| 492 |
-
Linked Space Test validations now write engine/preflight/failure diagnostics before and after Gradio endpoint discovery so payload-resolution failures cannot appear as opaque smoke failures.
|
| 493 |
-
|
| 494 |
-
|
| 495 |
-
## Pass 191.5 — Model Scan Risk Card
|
| 496 |
-
|
| 497 |
-
The metadata-only pre-scan now includes a visibility-only `build_risk` assessment. It highlights signals such as video generation, custom code, torchrun/NCCL, flash-attn/native kernels, ffmpeg, many shards, high VRAM mentions and non-standard install instructions. The UI shows the recommended HF OAuth session remaining for the model class, but this pass does not block launch.
|
| 498 |
-
|
| 499 |
-
### Pass 191.7 — Space Test Contextualization
|
| 500 |
-
|
| 501 |
-
Linked Space Test now uses the parent Build Run verdict to choose the right context:
|
| 502 |
-
|
| 503 |
-
- `technical_blocker_boot_only` disables generation validation and explains that no `/generate` endpoint exists by contract.
|
| 504 |
-
- `auth_refresh_required` keeps recovery validation available after the user refreshes HF sign-in.
|
| 505 |
-
- The UI no longer suggests schema-adjusted retries for boot-only blockers.
|
| 506 |
-
|
| 507 |
-
|
| 508 |
-
|
| 509 |
-
## Pass 191.9 — Pi Feasibility & Implementation Planning
|
| 510 |
-
|
| 511 |
-
Pi is now asked to produce advisory planning artifacts before or alongside implementation:
|
| 512 |
-
|
| 513 |
-
- `pi_feasibility_brief.json`
|
| 514 |
-
- `pi_implementation_plan.json`
|
| 515 |
-
|
| 516 |
-
The worker mirrors these files under `planning/` and writes `planning/worker_plan_review.json`. This pass is intentionally non-blocking: missing or partial planning artifacts do not fail runs, and deterministic worker gates remain authoritative.
|
| 517 |
-
|
| 518 |
-
|
| 519 |
-
## Pass 191.10 — Native Kernel / HF Kernels Strategy
|
| 520 |
-
|
| 521 |
-
The model pre-scan now includes a visibility-only `kernel_strategy` assessment. It detects native-kernel signals such as flash-attn, xFormers, Triton, fused ops, CUDA/C++ extension sources, Transformers AttentionInterface and HF Kernels / Kernel Hub mentions.
|
| 522 |
-
|
| 523 |
-
This pass does not make native-kernel risk a terminal blocker by itself. Instead it gives Pi and the UI a safer mitigation path: prefer PyTorch SDPA, compatible prebuilt wheels, HF Kernels / Kernel Hub, Transformers AttentionInterface, or Diffusers attention processors before attempting fragile source builds in Spaces.
|
| 524 |
-
|
| 525 |
-
The default generated scaffold no longer injects `kernels` into every Space. Pi may add `kernels` only when a matching supported operation and runtime are plausible, and must document the chosen backend in `PI_SUMMARY.md` / `INFERENCE_CONTRACT.json`.
|
| 526 |
-
|
| 527 |
-
### v191.11 — Auth-aware High-risk Launch Gate
|
| 528 |
-
|
| 529 |
-
The custom UI now cross-checks the Model Scan build-risk recommendation with the
|
| 530 |
-
current HF OAuth lifetime before launch. This is intentionally a **soft gate** for
|
| 531 |
-
valid sessions: high and very-high-risk models show a strong refresh sign-in warning
|
| 532 |
-
when the remaining session is shorter than the recommended build window, while
|
| 533 |
-
expired OAuth sessions are blocked before launch.
|
| 534 |
-
|
| 535 |
-
This pass does not change backend worker launch policy, repair loops, Space Test, or
|
| 536 |
-
validation semantics.
|
| 537 |
-
|
| 538 |
|
| 539 |
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 540 |
|
| 541 |
-
|
| 542 |
|
| 543 |
-
|
|
|
|
| 1 |
---
|
| 2 |
title: Agentic Space Factory
|
| 3 |
+
emoji: 🏭
|
| 4 |
+
colorFrom: indigo
|
| 5 |
+
colorTo: blue
|
| 6 |
+
short_description: Build, inspect, validate Gradio Spaces from model cards.
|
| 7 |
sdk: docker
|
| 8 |
hf_oauth: true
|
| 9 |
hf_oauth_expiration_minutes: 1440
|
|
|
|
| 17 |
- read-billing
|
| 18 |
---
|
| 19 |
|
| 20 |
+
# Agentic Space Factory
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 21 |
|
| 22 |
+
Agentic Space Factory turns Hugging Face model cards into private, testable Gradio Spaces through an agentic build loop running on Hugging Face.
|
| 23 |
|
| 24 |
+
The app is an operator interface for model-to-Space generation. A user enters a model URL, reviews a compact pre-scan, launches a build, watches progress, opens the generated Space, validates the live API, and inspects the full run archive.
|
| 25 |
|
| 26 |
+
The project builds on the idea that a deployed Space can be the coding assistant's lab: generated code is not enough; the live Space must boot, expose an API, run inference, and return a valid artifact.
|
|
|
|
|
|
|
|
|
|
| 27 |
|
| 28 |
+
## What the Factory does
|
| 29 |
|
| 30 |
+
- Reads a Hugging Face model card or model URL.
|
| 31 |
+
- Runs a compact pre-scan before launch.
|
| 32 |
+
- Creates a private target Space under the signed-in user's namespace.
|
| 33 |
+
- Launches the build inside a Hugging Face Job.
|
| 34 |
+
- Prepares a grounded workspace for Pi, the coding assistant.
|
| 35 |
+
- Uploads the generated Space implementation.
|
| 36 |
+
- Applies platform dependency guardrails.
|
| 37 |
+
- Assigns hardware on a best-effort basis, including ZeroGPU when applicable.
|
| 38 |
+
- Validates the deployed Space through live Gradio API calls.
|
| 39 |
+
- Captures reports, logs, traces, generated files, tests, and output artifacts.
|
| 40 |
+
- Classifies outcomes honestly: full success, partial validation, technical blocker, manual hardware required, auth refresh required, or failure.
|
| 41 |
+
- Optionally publishes privacy-safe anonymous eval records.
|
| 42 |
|
| 43 |
+
## User journey
|
| 44 |
|
| 45 |
```text
|
| 46 |
+
Paste model card
|
| 47 |
+
→ run compact pre-scan
|
| 48 |
+
→ launch build
|
| 49 |
+
→ watch Active Run timeline
|
| 50 |
+
→ inspect generated Space and artifacts
|
| 51 |
+
→ validate through Space Test
|
| 52 |
+
→ review Run Explorer and Run Stats
|
| 53 |
```
|
| 54 |
|
| 55 |
+
The interface is organized around:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 56 |
|
| 57 |
+
- **New Build** — model URL, pre-scan, launch readiness, and billing/compute hints.
|
| 58 |
+
- **Center workspace** — `Active Run` for build details and `Space Test` for linked validation runs.
|
| 59 |
+
- **Runs Explorer** — compact history of build runs.
|
| 60 |
+
- **Run Stats** — aggregate status and outcome overview.
|
| 61 |
|
| 62 |
+
## Hugging Face-native architecture
|
|
|
|
| 63 |
|
| 64 |
+
The Factory uses Hugging Face primitives end to end:
|
| 65 |
|
| 66 |
+
- **Spaces** for the orchestrator UI and generated demos.
|
| 67 |
+
- **Jobs** for long-running build, validation, and repair work.
|
| 68 |
+
- **Storage Buckets** for run archives.
|
| 69 |
+
- **Inference Providers** for assistant/model access.
|
| 70 |
+
- **ZeroGPU** for serverless GPU demos when a model fits the Gradio/ZeroGPU execution model.
|
| 71 |
+
- **Gradio** for live API validation.
|
| 72 |
|
| 73 |
+
Typical run artifacts are written under:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 74 |
|
| 75 |
```text
|
|
|
|
| 76 |
runs/<run_id>/state.json
|
| 77 |
runs/<run_id>/summary.json
|
| 78 |
runs/<run_id>/events.jsonl
|
| 79 |
runs/<run_id>/report.md
|
| 80 |
+
runs/<run_id>/analysis_inputs/
|
| 81 |
+
runs/<run_id>/planning/
|
| 82 |
runs/<run_id>/generated/
|
| 83 |
runs/<run_id>/tests/
|
| 84 |
runs/<run_id>/artifacts/
|
|
|
|
|
|
|
|
|
|
|
|
|
| 85 |
runs/<run_id>/logs/
|
| 86 |
+
runs/<run_id>/traces/redacted/
|
| 87 |
```
|
| 88 |
|
| 89 |
+
## Model-card grounding
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 90 |
|
| 91 |
+
At build time, the worker prepares `analysis_inputs/` for Pi:
|
| 92 |
|
| 93 |
+
```text
|
| 94 |
+
model_card.md
|
| 95 |
+
model_card_source.json
|
| 96 |
+
model_repo_tree.json
|
| 97 |
+
prescan_summary.json
|
| 98 |
+
source_policy.md
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 99 |
```
|
| 100 |
|
| 101 |
+
The rule is simple: the model card is canonical, the repo tree is structural evidence, and generated Hugging Face snippets are hints only. Pi is asked to cite model-card evidence before implementing the Space.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 102 |
|
| 103 |
+
## Validation contract
|
|
|
|
|
|
|
|
|
|
| 104 |
|
| 105 |
+
Generated Spaces are expected to describe what they implemented through an inference contract. The worker uses that contract to decide whether to run a generation smoke test, skip it as a declared technical blocker, or ask for manual validation.
|
| 106 |
|
| 107 |
+
For successful full-inference builds, the live Gradio API is the source of truth. The validator checks health, discovers endpoints, calls the generation endpoint, verifies returned artifacts, and records latency. For ZeroGPU-compatible apps, measured inference latency can inform `@spaces.GPU(duration=...)` recommendations.
|
|
|
|
|
|
|
|
|
|
| 108 |
|
| 109 |
+
## Privacy and safety
|
| 110 |
|
| 111 |
+
Generated Spaces are private by default. Run Buckets are per-user. Pi session traces are archived only in redacted form; RAW Pi traces are not published to Buckets or exposed in the UI. Redacted traces are best-effort and should still be reviewed before public sharing.
|
|
|
|
|
|
|
|
|
|
|
|
|
| 112 |
|
| 113 |
+
Anonymous eval records contain aggregate signals only. They must not include raw model cards, generated code, prompts, tokens, private bucket paths, validation payloads, endpoint schemas, or target Space IDs.
|
| 114 |
|
| 115 |
+
## Documentation
|
| 116 |
|
| 117 |
+
Public-facing documentation is in `docs/`:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 118 |
|
| 119 |
+
- `ARCHITECTURE.md` — system overview.
|
| 120 |
+
- `PUBLIC_PREVIEW.md` — public-preview guidance and user journey.
|
| 121 |
+
- `SECURITY.md` — token, bucket, trace, and eval privacy notes.
|
| 122 |
+
- `RECOVERY_ALGORITHM.md` — repair behavior and safety boundaries.
|
| 123 |
+
- `RELEASE_VALIDATION.md` — release checklist.
|
| 124 |
+
- `NEXT_STEPS.md` — product roadmap.
|
| 125 |
|
| 126 |
+
Detailed version history is kept in the changelog files at the repository root.
|
| 127 |
|
| 128 |
+
<!-- Internal regression markers for historical tests; public version history remains in CHANGELOG files: v189.9, v190.10, v190.33, v191.11, Timeline polish and Run notes clarity, Run notes, Agent recovery, Anonymous eval archive activation, agent_trace.jsonl. -->
|