# GENESIS presentation kit

No video is produced by this kit. Repository visibility remains private.

## Positioning

GENESIS turns AI-generated code into an inspectable improvement loop: build, execute, observe, revise, and compare. A judge can see both the output and the evidence behind it.

The supported modes are self-contained websites, a real task-board app with a trusted backend, and Python algorithm evolution in CreateOS. This release does not claim to generate arbitrary secure backends or outperform other tools across tasks.

## Three-minute live walkthrough

| Time | Show | Explain |
|---|---|---|
| 0:00–0:25 | A short Full-stack task-board brief | “Code generation is easy to show; working behavior and evidence are harder to trust.” |
| 0:25–0:55 | Public plan and build actions | The activity feed shows actions and observations, never private reasoning. Label an archived build as recorded. |
| 0:55–1:25 | Create, search and complete a real task | The preview calls a SQL-backed API through a narrow bridge. Data persists outside the generated document. |
| 1:25–1:55 | Checks and Backend | Actual browser interactions, saved screenshots, scoped sessions and viewer write denial. Read failed/unchecked checks honestly. |
| 1:55–2:20 | Compare two saved versions | Show a real before/after screenshot and a changed check. Do not invent improvement percentages. |
| 2:20–2:45 | Python lineage and one execution receipt | CreateOS isolation, verified parents, mutation/crossover, actual stdout and cleanup. State which archived run was verified. |
| 2:45–3:00 | Download and next step | Runnable code export, preserved evidence, local deployment readiness. Stripe/event eligibility require the separate organizer path. |

## A useful build brief

“Build a polished task board for a small creative team. Include real login, persistent task creation, search, status filters, status changes and sign out. Use warm white, charcoal and violet, clear empty states and responsive navigation.”

Revision: “Improve the mobile navigation and make status filters easier to scan. Preserve every working task interaction and required test control.”

## Questions to prepare for

- **What is generated?** Website/app HTML, CSS and JavaScript; Python candidate source. The task-board backend is a supported trusted blueprint.
- **What is verified?** Specific browser/API behavior and Python test executions, linked to saved source hashes. Human review is still needed.
- **How is data protected?** Project ownership, scoped hashed sessions, server-side roles, validation and rate limits. The app preview never receives workspace/provider secrets.
- **What happens on failure?** Saved evidence remains. Web builds can recheck saved source; Python sandbox work requires explicit cleanup/restart.
- **What is the business model?** A possible usage-based developer product; billing is deferred. Do not present projected revenue as measured demand.
- **What did users say?** A guide and blank form are ready. No real-user feedback has been collected yet.

## Before presenting

Start local services; verify current provider quota; select known saved versions; download evidence; check mobile layout and export; hide local keys and account management forms; read [eligibility.md](eligibility.md). Keep a recorded run as an explicitly labeled fallback. Do not announce eligibility, a public launch or completed payments without evidence.

## Presenter controls

- Open the saved Focusboard project and use **Expand workspace** for a larger preview. Escape or the exit control returns to the normal workspace. Expanding does not regenerate source or start a sandbox.
- The sidebar shows Plan, Build, Verify and Improve from saved state. **Full activity** preserves the complete history, including earlier failures.
- Click **Saved tasks** or **Viewer write protection** in the verification summary to open the matching observed check. A source fingerprint opens Code. These are specific recorded checks, not a security certificate.
- Open **Compare**. Full-stack projects start with mobile captures, so the saved change in task order is immediately visible. Use the desktop/mobile controls to switch. The two image panels support keyboard scrolling.
- Compare separates repaired failures, newly verified checks and regressions. The current task-board revision adds a deletion check; that check was previously unchecked, so it is not described as a repaired test failure.
- **CreateOS proof** loads an owned, completed Python run and its saved verification checks. Use **Open Python execution evidence** for exact receipts. The view is labelled recorded and allocates no sandboxes. Website/app browser checks remain distinct from CreateOS Python execution.

A small layout fixture exercised these controls offline with real saved source/captures and synthetic app access. It checked evidence links, comparison states, fullscreen/Escape, saved execution counters and 320–1440px layouts without real credentials or external requests. This supplements the automated tests; a manual review in the actual workspace browser remains outstanding.


## Recommended verified-repair walkthrough: Launchboard

Open the saved Launchboard project and its retained version 3. Its original browser checklist passes. In Compare, choose version 2 as Before and version 3 as After. The reproduced-repair card shows the actual failed-to-passed task-status interaction. The pair was rerun with one frozen task-board plan and checker; the revised source passed that checklist with no observed regressions. Original reports remain unchanged. Earlier failed verification attempts remain inspectable.

Explain: “A status change failed. We requested a targeted correction, GENESIS saved the revised source, and the same check now passes. The evidence and the runnable project are available together.” This is a requested AI revision, not a claim that every custom defect is repaired automatically.

Optionally inspect version 4: its mobile sign-in check failed, so the default preview retained the fully checked version 3. Show the review banner and then return to the retained version. This demonstrates a real caught regression without hiding the attempted source.

The task interactions in Preview can be live. Comparison screenshots and existing repair receipts are recorded evidence. Recheck both versions is an optional live browser-only operation with no new AI requests; it still takes time and uses the local worker. Do not start a new AI build merely to replay this saved evidence during a presentation.

The targeted revision used three AI requests in this project (one plan and two candidate generations). Browser rechecks left its AI usage unchanged. Successful automated checks establish the exercised conditions, not complete security, accessibility or correctness.

The user study kit is prepared at `/feedback`. No participant findings have been collected or claimed by this implementation.