# GENESIS — Project guide

Interface updated October 15, 2026. Live verification below was recorded October 14, 2026.

## From one answer to an experiment.

GENESIS turns a programming goal into a population of competing Python programs. It executes them against frozen tests, selects verified survivors, and uses their code and development feedback to generate another generation.

The important output is more than source code: it is the record of what ran, under which constraints, against which inputs, and with what results. Evolution can improve a solution, but improvement is measured rather than assumed.

**What a judge should see**

A real program, a parent-child relationship, an enforced constraint, an execution receipt, and a final independent check. An archived run is always identified as recorded.

## A clear boundary between creation and judgment.

The browser presents experiments. FastAPI owns orchestration, tests, scoring, and persistence. AI creates candidate source. CreateOS executes that source in isolated microVMs; it does not decide the score.

```text
Next.js workspace -> FastAPI evolution engine
FastAPI -> AI provider (creation + custom evaluation)
FastAPI -> CreateOS (source + inputs -> execution receipts)
FastAPI -> PostgreSQL (snapshots + source + lineage + evidence)
Expected outputs and scoring remain outside the sandbox.
```

Expected answers remain in the backend. The sandbox receives candidate source and input only. The engine compares actual stdout with expected JSON and saves the result after each test.

Stripe Projects provisioning and public hosting are deferred. The current application runs locally with PostgreSQL; it does not claim a completed Stripe deployment.

## Generate. Execute. Evaluate. Evolve.

1. Freeze the challenge and tests. Preset benchmarks use deterministic reference oracles and a stored seed. Custom challenges use a supplied suite or an AI evaluator followed by a blind verifier. Tests are validated and hashed before candidate generation.
2. Create genuinely different programs. The creator receives the goal, constraints, a generation strategy, parent code, and development feedback. Duplicate source hashes are retried up to three times. All programs use the Python standard library and JSON stdin/stdout.
3. Execute and select. Each candidate runs in its own CreateOS sandbox. The engine records every case, computes development and holdout grades separately, and marks a candidate verified only if both groups pass completely. Source that exceeds the byte limit is rejected before execution, without a score.
4. Build the next generation. Elitism copies and retests the best verified parent. Mutation works from one parent. Crossover uses two verified parents when available. If there are no verified parents, the engine creates new candidates.
5. Adapt strategies, then audit. Strategy trials rank actual holdout results while reserving the last candidate slot for exploration. Changing constraints resets these trials and preserves their history. A preset winner receives a fresh seeded final audit after selection; audit results never feed back into evolution.

**Changing the environment**

Constraint updates increment the revision and apply at the next generation. The engine snapshots that generation’s limits. Once the final generation begins, new limits require a new experiment. Survivors are retested, and current dashboard metrics exclude candidates from older revisions.

## Correctness first. Performance second.

Preset sorting, stable deduplication, and interval merging use six development cases and three holdout cases. Cases include boundary conditions and seeded random inputs. Custom suites allow 4–24 development and 2–12 holdout cases, with no shared inputs between groups.

**DEVELOPMENT FITNESS / 100**

`90 × passed / total + speed bonus`

Speed bonus = 10 / (1 + median execution ms / timeout ms), awarded only when every development test passes.

A pass requires valid finite JSON equal to the expected result, a successful exit, no timeout, and bounded output. A high development score alone does not make a survivor: every holdout case must also pass. Interrupted evaluation and source-limit rejection have no fitness score.

The creator receives development failures, not holdout expected answers. Because strategy adaptation uses holdout results, holdout is not a permanently untouched benchmark. The fresh final audit is the separate post-selection check for presets.

**Read measurements honestly**

CreateOS execution time includes interpreter startup and runner overhead. It is not a calibrated CPU benchmark. AI evaluator agreement reduces mistakes but does not prove arbitrary program correctness. Check exact receipts before claiming an improvement.

## Generated code executes outside the app.

- CreateOS provides a microVM boundary with closed ingress and a host-enforced non-routable outbound allowlist.
- Candidate Python runs with isolated interpreter mode, UID/GID 65534, a clean environment, and read-only uploaded source.
- The runner imposes wall time, CPU, memory, process, file size, open-file, and output limits. API keys and the lab token never enter the candidate environment.
- Tests, expected answers, and grading remain outside the microVM. Candidate stdout is treated as data.
- Each sandbox is destroyed after evaluation. Failed cleanup preserves its ID for retry; auto-pause is not deletion.

The private lab token is kept in React memory. Reloading or opening another tab requires unlocking again. Local setup saves provider credentials in an owner-only, ignored environment file; public hosting requires HTTPS and hosting secrets.

Goals, parent source, and development feedback go to the selected AI provider. Source and inputs go to CreateOS. Avoid putting secrets or personal data in challenges.

## Working in GENESIS.

| Surface | What to do / show |
| --- | --- |
| Prompt & examples | Describe a Python task or choose an example. The homepage carries your draft into the workspace without starting execution. Unlock the workspace, review settings, then submit explicitly. Editing a preset goal switches it to a custom challenge. |
| Preview | Start with a recorded execution, edit JSON input, and explicitly run the selected Python source in a fresh sandbox. Data, JSON, and Console show actual results. HTML strings can be viewed as inert static markup; React builds are not supported. Each fresh run consumes provider quota and saves its own receipt without affecting evolution. |
| Verification | Inspect selected-candidate tests, source and suite fingerprints, preset expected answers, receipt consistency, final audit, and project-wide cleanup. Configured runtime protections are distinct from verified evidence. Unperformed vulnerability and application-login checks remain unchecked. |
| Run settings | Choose a preset or custom goal. Set candidates, generations, time, source-byte, and memory limits. During an active run, limits can be queued for the next generation until the final generation begins. |
| Evolution | Follow the real program lineage. Select a node to open Code. Edges identify parents; operation labels distinguish creation, elite retest, mutation, and crossover. Expand the graph for presentations; Escape returns to the workspace. |
| Code & Evidence | Select a candidate in the sidebar. Code shows source; Diff compares its first parent. Evidence expands exact inputs, expected answers, actual output, exit status, and timing. Sandbox shows allocation and cleanup receipts. |
| Activity | Read saved agent and test events, fitness trajectory, and current-revision strategy trials. Small-sample strategy performance is experimental, not a general self-improvement guarantee. |
| Report & Export | Compare candidates in the current revision, inspect constraint history and the suite hash, check final audit and sandbox cleanup, and export the full run. |
| Projects sidebar | New project clears the current view and starts a blank prompt. Choose a saved project explicitly; it is recorded evidence, not a replay. An active run resumes after unlock only when there is no incoming prompt. |

Drafts and the access token stay in tab memory. Reloading clears them. Unlocking alone never starts execution.

### Preview boundaries

Recorded examples create no sandbox. A fresh preview permits 16 KiB of finite JSON input and uses one CreateOS allocation. Up to 20 preview receipts are retained per project. Cancelled, failed, and interrupted runs retain their receipts and any sandbox IDs. Use the sidebar cleanup retry if destruction is not confirmed. Refreshing the tab clears unsent input; switching Code/Preview within the same candidate retains it. Changing candidate resets the input.

A custom input has a reference check only when it matches a frozen case. Preview receipts are separate from grading. Static HTML uses an inert iframe with no script, form, parent-page access, or external-resource permissions. Passing finite tests is not a security certification.

## Start the lab with your own credentials.

Requirements: Python 3.11+, uv, Node 22+, npm, and Docker Desktop. Run these commands from the repository root. The backend uses one worker and supports one active experiment.

```sh
uv sync --directory backend
npm ci --prefix frontend
python3 scripts/secure_setup.py
```

Open http://127.0.0.1:8765, enter the provider keys, AI model ID, and HTTPS API base URL. Save the displayed lab token privately and stop the setup server after saving. Never paste keys into chat or commit them.

```sh
python3 scripts/start_lab.py
```

Open http://localhost:3000, choose Open workspace, and unlock the workspace. The launcher starts PostgreSQL and both services. Its Ctrl+C stops the app processes while retaining the database volume. For the container stack, after setup and password generation, use docker compose up --build. With Docker, change saved credentials through secure setup and restart the backend.

### Custom challenge contract

Programs read one JSON value and print one JSON value. A supplied suite needs 4–24 development and 2–12 holdout cases; each case has input, expected, and an optional label. The optional input_type declares array, object, string, number, boolean, null, or any. Development and holdout inputs must differ.

```json
{
  "input_type": "array",
  "cases": [
    {"input": [], "expected": 0},
    {"input": [1], "expected": 1},
    {"input": [-2], "expected": -2},
    {"input": [2, -1, 3], "expected": 4}
  ],
  "holdout": [
    {"input": [-5, -1], "expected": -1},
    {"input": [3, -4, 5], "expected": 5}
  ]
}
```

This small suite illustrates maximum-subarray input. Add broader trusted cases before making a correctness claim. When no suite is supplied, evaluator and blind-verifier agreement is required before tests freeze.

## Let the evidence tell the story.

Before presenting, confirm credentials, provider quota, sandbox capacity, and submission eligibility. Keep a completed real preset run ready in the archive. Live provider latency can exceed the presentation window.

1. 0:00–0:25 Define the experiment “We generate competing programs, execute them independently, and evolve verified survivors.” Show the goal and constraints; choose population 3 and two generations.
2. 0:25–1:15 Show the programs and execution Show distinct algorithms in the chamber. Open a candidate’s evidence receipt and explain how stdout is checked against an external expected answer.
3. 1:15–1:45 Introduce a constraint During a live run, lower the byte or time limit for the next generation. In a recorded demo, expand constraint history and explicitly explain the saved change.
4. 1:45–2:30 Follow a parent into its child Select a mutation or crossover node, inspect its parent diff, and explain elite retesting. A rejected candidate is evidence that constraints were enforced.
5. 2:30–3:00 Close with the proof Show current-revision comparison, fresh final audit, and destroyed sandboxes. Export the run. State the pending Stripe deployment and any unverified flow clearly.

**If a live run is unavailable**

Use the completed archive and say “This is a recorded real experiment.” It contains real programs and executions, but opening it does not start a new run. Do not present saved evidence as fresh activity.

## What is proven, and what is still pending.

Live verification recorded on October 14, 2026:

- A real sorting run completed two generations with six candidates: five executed and verified; the crossover candidate exceeded the revised byte limit and was rejected without scoring.
- 45 candidate tests and nine fresh final-audit tests ran in CreateOS. The final audit passed. All six experiment sandboxes were destroyed.
- A live constraint update changed 1500 ms / 12,000 bytes / 128 MiB to 1000 ms / 650 bytes / 64 MiB. PostgreSQL retained both generation snapshots.
- Sandbox checks verified unprivileged execution, secret-free candidate environments, output and timeout limits, protected source, and non-routable egress.
- 80 backend tests cover contracts, fitness, lineage, revisions, authentication, cleanup, and error handling. Frontend type checks, production build, and dependency audit pass.

### AI + CreateOS + PostgreSQL

Real sorting evolution and retained execution evidence.

### Revised custom flow + accepted crossover

A real custom maximum-subarray run (`6e462139-114a-436e-bc63-2ce9ca0828df`) completed with six candidates, 78 execution receipts, an executed verified crossover and six destroyed sandboxes. The repeatable verifier checked reference answers, grading, lineage, hashes and cleanup. Earlier quota-blocked runs remain in history.

### Stripe Projects + public hosting

Account access is unresolved. The official event listing says to start from an empty directory; pre-event code requires organizer approval.

### Repeatable release check

From the repository root, inspect the recorded real experiment without creating sandboxes:

```sh
uv run --directory backend python ../scripts/verify_release.py --experiment e678e548-76e0-4fe7-a2e7-e640be5965e4
```

The checker validates source and suite hashes, reference answers, recorded stdout and pass status, fitness, lineage, strategy measurements, final audit, and cleanup. It checks internal consistency; exported receipts alone do not independently authenticate the provider.

To repeat verification using six new sandboxes, explicit live mode runs the real maximum-subarray custom challenge and requires a verified crossover:

```sh
uv run --directory backend python ../scripts/verify_release.py --run
```

Live mode consumes actual AI requests and up to six sandbox allocations. It preserves incomplete evidence and attempts to stop on cancellation or deadline failure. Failure never becomes a success claim.

The [official event listing](https://luma.com/6stm74wk) says builders start from an empty directory and submit through Stripe Projects. The schedule is October 17, 12:00–19:00 Pacific, or October 18, 00:30–07:30 India time. Registration requires approval. Treat this prebuilt repository as preparation until organizers authorize its use.

The local workspace supports administrator-created users and project ownership. Generation jobs use a persistent lease with one backend worker. Restarted work requires explicit recovery; billed Python work is never silently replayed. Automatic worker failover is excluded. Quota/capacity failures preserve evidence and report failure; there is no simulated fallback.

## The experiment is the durable record.

Workspace APIs require a workspace token/session. Application APIs require app-scoped sessions; login and health are public. The browser uses a same-origin proxy; default local API access is http://localhost:8000. Health is public and returns no credentials.

| Method / path | Purpose |
| --- | --- |
| GET /health | Service liveness. |
| GET /api/status | Provider configuration and database status; configured is not a live health guarantee. |
| GET /api/experiments | Experiment summaries. |
| GET /api/experiments/{id} | Complete saved experiment and evidence. |
| POST /api/experiments | Start a validated challenge; rejects a second active experiment. |
| PATCH /api/experiments/{id}/constraints | Queue limits for the next generation of an active run. |
| POST /api/experiments/{id}/stop | Cancel evaluation while preserving evidence and attempting cleanup. |
| POST /api/experiments/{id}/cleanup | Retry undeleted sandbox cleanup after a run ends. |
| GET /api/experiments/{id}/candidates/{candidate}/verification | Recompute saved evidence checks; report configured safeguards and limits. |
| POST /api/experiments/{id}/candidates/{candidate}/previews | Start a background preview with {input: JSON}; save receipt separately from grading. |
| POST /api/experiments/{id}/previews/{preview}/stop | Cancel a preview while preserving its receipt and attempting cleanup. |
| POST /api/credentials | Loopback-only runtime credentials; hosting uses environment secrets. |

Exports include the challenge, seed, frozen suite and hash, generation revisions, candidate source and hash, parent IDs, operations, development/holdout grades, stdout/stderr, exit status, timing, lifecycle receipts, events, strategy trials, and any final audit. Exports contain user-provided goals and inputs; review them before sharing.

### Repository map

| Path | Responsibility |
| --- | --- |
| frontend/app | Workspace, guide, styling, and backend proxy. |
| frontend/components | Run report and shared data types. |
| backend/genesis/engine.py | Generation loop, selection, scoring, audit, cleanup. |
| backend/genesis/providers.py | AI contracts and trusted CreateOS runner. |
| backend/genesis/benchmarks.py | Seeded test inputs and preset reference oracles. |
| backend/genesis/models.py | Challenge, test, and constraint validation. |
| backend/genesis/store.py | Persistent snapshots and restart recovery. |
| backend/genesis/api.py | Authenticated HTTP interface and request limits. |
| scripts | Private setup, local launcher, and repeatable evidence / live release verification. |
| docs | Architecture, deployment, verification, eligibility, and demo notes. |

### Verify a change

```sh
cd backend && uv run pytest -q
cd ../frontend
npm test
npm run typecheck
npm run build
npm audit --omit=dev
```

Unit tests use provider doubles; they do not inject demo data into the dashboard. Live receipts and automated tests establish different kinds of evidence.


# Website projects

Select **Website** on the home page or in a new workspace project. Try **Developer portfolio**, unlock the workspace with the local access token, and choose **Build website**. Saved provider credentials are used by the backend. No CreateOS allocation or Stripe account is needed for websites.

The default build makes one candidate in each of two passes. The AI first returns a public plan and an HTML section checklist. Each pass generates a complete `index.html` with inline CSS and JavaScript. A separate Chromium worker renders the actual source, captures desktop and phone screenshots, checks horizontal overflow at 1280, 390, and 320 CSS pixels, checks semantic landmarks, the frozen content checklist, internal anchors, mobile menu behavior, JavaScript exceptions, and axe WCAG A/AA rules. The next pass receives the selected source and observed browser findings. Passing checks do not prove the design is attractive or that every interaction works.

**AI progress** displays timestamped public plans, actions, generation summaries, observed checks, and selection decisions. It does not expose private model reasoning, simulate thoughts, or invent a live stream. Events are saved as work happens; the workspace refreshes them approximately every 1.5 seconds. An AI request can take up to 90 seconds, during which the current action remains visible.

Use Preview to interact with navigation and local controls, switch desktop/phone width, or inspect actual saved screenshots. Code shows the complete source and a parent diff. Checks shows real browser findings and runtime boundaries. Versions retains every generated source, including versions needing changes. Download saves a standalone `index.html`; Evidence exports the project JSON. Screenshots are stored separately in the persistent artifact volume and fetched through authenticated routes.

Enter a change in **Make it yours** to build from the selected version. The same number of candidates and passes runs again. Earlier versions remain available. Ten user revision requests are allowed per project. Stop retains source and completed evidence. Interrupted work is marked interrupted on service restart; it is not automatically resumed.

## Boundaries

This is a self-contained frontend builder, not a React/npm project generator or a backend generator. Websites can implement local UI behavior, such as filters, accordions, tabs, and menus. Forms must not claim delivery without an integration. The generated site has no server, database, authentication, or payment service. Those require separate implementation. Python projects retain the independent CreateOS execution workflow.

Interactive previews run in a sandboxed iframe with `allow-scripts` only, no same-origin privileges, no provider credentials, and restrictive content security policies. Network requests, forms, nested frames, popups, and top-level navigation are restricted. The workspace's frame policy restricts external frame navigation. Downloaded source is an export; review it before deploying with additional permissions.

The browser worker is a dedicated unprivileged Docker container with a read-only root filesystem, temporary storage, process/memory/CPU limits, dropped capabilities, no host mounts, no credentials, and an internal Docker network without an Internet route. Chromium currently runs without its additional OS sandbox; the container is the execution boundary. This private local setup is not a hardened public multi-tenant service. Do not expose the worker port publicly. A timed-out worker job can finish its cleanup after a cancelled backend request; the worker rejects concurrent jobs.

Browser checks cover specific layouts, a menu toggle, and automated accessibility rules. They do not constitute a full accessibility audit, comprehensive security scan, complete functional test, or proof of design quality. The content checklist is AI-derived, not an independent oracle. Screenshots capture the generated page at the recorded viewport; they are not fabricated mockups.

## Run and verify

Use `docker compose up --build -d --wait` for the complete local stack. It preserves PostgreSQL and screenshots in named volumes. The development launcher also starts the database and browser services. Do not use `docker compose down -v` unless you intend to delete saved data.

Run backend tests with `uv run --directory backend pytest -q`. Run frontend checks from `frontend` with `npm test`, `npm run typecheck`, and `npm run build`. Run real browser tests using `docker compose run --rm --no-deps browser node --test tests/*.test.mjs`. CI installs Chromium and runs the same browser tests. Fixtures are test inputs only; the product uses actual AI and browser execution.

API additions (all require the workspace bearer token):

- `POST /api/experiments` with `kind: "website"`, `benchmark: "custom"`, a goal, population 1–3, and generations 1–3.
- `POST /api/experiments/{id}/revisions` with `{message, candidate_id}`.
- `GET /api/experiments/{id}/candidates/{candidate}/screenshots/{desktop|mobile}` returns a private PNG after checking saved source integrity and artifact path containment.
- `GET /api/experiments/{id}/candidates/{candidate}/verification` returns source integrity and the browser report for websites; Python verification keeps its existing contract.

`BROWSER_CHECK_URL` locates the worker. `WEBSITE_ARTIFACT_DIR` locates private saved screenshots. Compose configures both automatically. Keep the artifact volume when moving the database. The Python release verifier checks Python evolution only; it does not grade websites.


# Full-stack task-board workflow

Choose **Full-stack** in the prompt composer. This mode generates a task-board frontend against a supplied, trusted backend. Arbitrary generated server code is outside this release's scope.

## Build and use

1. Sign in through **Workspace access**. The local setup token remains available for owner bootstrap. The first administrator account receives existing local-owner projects; other users have separate project histories.
2. Select Full-stack and describe the board's audience and design. Start with one candidate and one pass. Set an AI call limit and token reservation limit before starting.
3. The AI creates a public plan, then HTML/CSS/JavaScript. It receives a fixed task API contract, with required accessible test controls. The backend supplies login, sessions, task validation, SQL persistence and role checks.
4. Preview starts with a short-lived app owner session. Create tasks, search, filter and change status. These operations persist records in PostgreSQL; they are not local placeholder interactions.
5. In **Backend**, create an app viewer or editor with a temporary password. Sign out inside the app to test that account. Owner/editor can write; viewer can read. Workspace accounts and app accounts use separate scopes.
6. **Checks** reports observed browser behavior and accessibility/layout results. App verification uses temporary real accounts and SQL records in an expiring scope. It does not modify your board. Failed checks remain failed. A browser-verified version does not receive a Python fitness score.
7. Request a revision. Saved versions stay available. **Compare** shows actual saved screenshots, public summaries, changed check states and source changes.
8. **Download** produces an independently runnable project ZIP. **Evidence** exports the workspace record. The project ZIP contains the selected frontend, trusted backend, setup instructions and container configuration. It includes no real accounts, records, sessions, keys or `.env`.

## Preview boundary

The generated document remains in an opaque-origin iframe with scripts permitted and direct network access blocked. A trusted client exposes only `/me`, `/login`, `/logout`, `/tasks` and task update/delete calls. The parent validates frame identity, a fresh nonce, unique request IDs, exact paths/methods and bounded bodies before forwarding requests.

The parent holds an **app-scoped** session in memory. Generated code never receives the workspace token, provider keys or the app bearer token. Login replies are stripped of their token before being returned to the frame. Server checks remain authoritative: guessed record IDs and direct API calls cannot bypass project/role checks.

Sessions expire after 12 hours for sign-in, or 30 minutes for delegated preview access. Only token digests are stored; passwords use salted scrypt hashes. User administration is owner-controlled; there is no open registration, password reset or email verification flow in this local release.

## Jobs, usage and recovery

Generation jobs are recorded in SQL and executed FIFO under one renewable database lease. The queue allows 20 pending jobs globally and five per owner. Run one backend worker. A second worker is refused while a live lease exists. An expired lease/restart marks saved work interrupted; billed work is never silently replayed.

The workspace supports **Resume saved build** for web projects. Existing source without browser evidence is rechecked without another AI generation call. If a saved revision is available, recovery completes with the retained versions; request a new revision for more passes. A failure before source creation can repeat planning/generation only after explicit resume. Python sandbox runs require explicit cleanup and a new experiment.

Each AI call reserves a conservative UTF-8 input estimate plus a capped output allowance before sending. Reservation totals and call counts persist across restarts and revisions; unknown/failed requests remain reserved. Provider-reported input/output token counts are stored separately. These are usage controls, not precise currency billing. Currency cost is shown as unavailable when pricing is not configured. A bounded schema retry consumes another reservation.

Workspace requests allow 600 reads/minute and 60 writes/minute per account. App requests allow 300/minute per account. Login limits apply to both email/IP pairs and aggregate IPs. Task fields are validated; apps have a 500-task operating limit. Review expected concurrency and proxy configuration before public hosting.

## Runtime limits

Browser checks use a non-root, read-only container with no host mounts/provider credentials, dropped capabilities, no-new-privileges, memory/process/CPU bounds and no Internet route. Generated page network requests and WebSockets are blocked. Task verification receives only expiring test credentials.

The additional Chromium OS sandbox could not start on the current Docker Desktop host (“No usable sandbox”). Container isolation remains the execution boundary. Deploy untrusted multi-tenant workloads only on a host/runtime that supports the required sandbox; do not weaken host protections to bypass this limitation. Automated layout/accessibility/API checks do not prove complete application security.

## Backups

With builds and application writes idle, run `python3 scripts/backup_verify.py`. It writes owner-only PostgreSQL and artifact backups under ignored `work/backups/`, restores them into a uniquely named scratch database and temporary directory, verifies row fingerprints/artifact hashes, then removes only those scratch resources. It never restores over live data. Keep private backups on durable storage before relying on them for disaster recovery.

See [user-test-guide.md](user-test-guide.md), [feedback-form.md](feedback-form.md), [presentation-kit.md](presentation-kit.md), and [eligibility.md](eligibility.md).


## Browse and run a generated project

Open **Code** to browse the actual downloadable files and folders, inspect pinned direct packages, and read the local startup guide. For a task-board app, install Python 3.11 or newer, download and unzip the project, then double-click `Start.command` (macOS) or `Start.bat` (Windows). The launcher installs dependencies in a private environment, runs `pip check`, prompts privately for the first account, and opens the browser after checking server readiness. Existing local users and tasks are retained on later starts. Initial setup needs Internet access. On Linux use `python3 start.py`.

Website-only downloads contain `index.html` and a README. Open `index.html` directly in a browser; no package installation is needed.


## Reproduce a repair and recover saved work

Open Compare on a direct parent/child pair with a recorded failing-to-passing check. Recheck both versions to run their saved sources against one frozen browser checklist with no new AI requests. The separate receipt shows source and checker fingerprints, observations and any regressions. A failed or incomplete attempt remains visible. If a later build fails checks, the previously fully checked version remains the default preview.

Interrupted web operations show a recovery outline before resuming. It explains whether recovery runs browser checks only or may request new AI generation within the existing allowance. Source mismatches block recovery. Python allocations are not silently replayed.

Record actual supervised tester sessions at http://localhost:3000/feedback. The facilitator guide defines the saved-project protocol, and exported observations distinguish participants from self-tests. No participant feedback is claimed by preparing the form.