fffiloni commited on
Commit
40a663d
·
verified ·
1 Parent(s): f6435ca

Upload 5 files

Browse files
Files changed (1) hide show
  1. README.md +71 -486
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
- ## Pass 191.8 — Prompt Pi / Repair Brief Alignment
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 redun­dancy, 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
- The archive does not store raw generated code, prompts, tokens, private bucket IDs, target Spaces in clear text, raw logs, or outputs by default.
214
 
215
- # Agentic Space Factory
216
 
217
- - **v170** fixes run deletion so the backend recursively removes all concrete Bucket objects for the run prefix.
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
- # Agentic Space Factory
223
 
224
- Agentic Space Factory turns a Hugging Face model card into a **private, testable Gradio Space** using a Hugging Face Job, Pi, a coding model through Hugging Face Inference Providers, and a private Storage Bucket for run state, traces, reports, generated files, and validation artifacts.
 
 
 
 
 
 
 
 
 
 
 
225
 
226
- It is a Hugging Face-native productization of the agentic ZeroGPU Spaces workflow:
227
 
228
  ```text
229
- model card → agentic build job → private Space → hardware if available → live validation → traces/report/artifacts
 
 
 
 
 
 
230
  ```
231
 
232
- ## What the app does
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
- ### Right column
 
 
 
271
 
272
- - **Runs Explorer** — navigation-only list of build and validation runs with filters, search, status badges, and inline delete.
273
- - **Run Stats** — aggregate metrics across indexed runs: totals, success/pass rates, validation latency median/p95, and issue counts.
274
 
 
275
 
 
 
 
 
 
 
276
 
277
- ### Agent recovery visibility
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
- ## Main workflow
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
- ## Result statuses
359
 
360
- - `full_inference_success`: a live generation smoke test returned the expected output type.
361
- - `manual_hardware_required`: the Space was generated, but hardware must be selected manually before validation.
362
- - `full_inference_candidate_health_passed`: the Space boots and contains inference signals, but generation was not fully smoke-tested.
363
- - `health_only`: the Space boots, but no real inference path was validated.
364
- - `technical_blocker`: concrete blockers such as multi-GPU requirements, missing licenses, custom CUDA, or unclear usage.
365
- - `failed`: the build, runtime, or validation job failed.
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 Docker Space starts the app with one uvicorn process from the Dockerfile. Do not add an extra `uvicorn.run(...)` launcher inside `app.py`.
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
- - 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`.
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
- ## v124 Timeline and Run Explorer stabilization
426
 
427
- - Fixed the compact Overall Progress timeline so dynamically visible repair/failure groups cannot wrap dots onto a second row.
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
- ## v127 Billing usefulness + UI event/timeline audit
433
 
434
- - 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.
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
- ### Active Run source documents
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
- ### v191.12Test Suite Expansion
 
 
 
 
 
540
 
541
- The final pass in the v191 hardening series adds cross-pass regression coverage for dependency normalization, contract-aware generation smoke skips, OAuth expiry/redaction, repair/auth outcomes, Space Test context, model build-risk cards, native-kernel strategy, and soft auth-aware launch warnings.
542
 
543
- It also corrects a display-only Space Test endpoint fallback so boot-only technical blockers do not show `/generate` after the parent policy has established that no generation endpoint exists by contract.
 
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. -->