# Generator Studio

Generator Studio is the owner-only authoring layer for the public tools in
`workbench.js`. It is deliberately a constrained parametric editor: a canvas
gesture changes an approved parameter, the trusted generator recompiles the
solid, and the normal validation/export path runs again.

That gives the current project a useful CAD workflow without pretending the
existing triangle-mesh engine is a full boundary-representation kernel.

## What works now

- Real Supabase account creation and sign-in against the linked production
  project, including verified-email signup and persistent sessions.
- Fail-closed database-backed member/admin role hydration. An email address
  alone cannot grant hosted admin access.
- A confirmed owner account promoted by a guarded database migration, with the
  admin route guard, account restoration, and Generator Studio unlock verified
  in the browser.
- Least-privilege Data API grants verified against production: the public
  generator registry and Auth settings respond, while anonymous profile and
  role requests are denied.
- All eight Workbench generators in one full-screen editor.
- Direct X/Y/Z dimension handles mapped to generator parameters.
- Draggable enclosure-panel cutouts mapped to their X/Y coordinates.
- Editable Cable Cubby row and column labels that are rebuilt into the exported
  solid as shallow debossed geometry.
- Exact parameter inputs, validation, mesh size, volume, triangle, and material
  readouts.
- Undo/redo, autosaved per-generator drafts, named checkpoints, and restore.
- Local publish: edited parameters and appearance become the Workbench starting
  model on the same browser and origin.
- Public Workbench visitors can change preview color without changing geometry;
  Studio publishes the starting color beside the same generator document.
- STL, 3MF, preset JSON, and full-workspace JSON export.
- Desktop, tablet, and review-only phone layouts.

## Current trust boundary

The production portfolio remains a static bundle, but `studio-config.js` now
points `studio-auth.js` at the live Supabase project
`pznavbmpbigykwthyedu`. The adapter runs in `supabase` mode and never falls back
to a local account after a hosted failure. Supabase owns password handling,
email verification, and session refresh; `profiles` and `user_roles` hydrate
the UI session. The database role is the authority for owner access.

Drafts, named versions, and published Workbench defaults still live in browser
storage until `model-store.js` is migrated. A hosted account therefore follows
the user across devices, but the current model edits do not. “Publish” still
changes Workbench only on the same browser and origin.

The local-prototype authentication implementation remains available for
offline development only when both public project values are deliberately
blank. In that mode, the account vault and role are browser-controlled and are
not a secure multi-user boundary.

## Production identity and publishing

The production project is live at
`https://pznavbmpbigykwthyedu.supabase.co`, and this repository's Supabase CLI
workspace is linked to it. The canonical database change history is the ordered
SQL in `supabase/migrations/`, currently the initial schema, guarded
verified-owner promotion, and Data API privilege hardening. All three migrations
are applied. The hardening migration revokes broad default anonymous and
authenticated table grants, then re-grants only the intended read and
column-level authoring surface; RLS remains an independent authorization
boundary. Future changes must be new migrations rather than dashboard-only
edits. See `SUPABASE_SETUP.md` for the verification details and read-only SQL.

Production smoke checks now return `200` for public `generator_models`, `401`
for anonymous `profiles` and `user_roles`, and `200` for Auth settings.

The approved authentication configuration is:

- Site URL: `https://www.seanwirkus.com/`
- Production callback: `https://www.seanwirkus.com/account.html`
- Local callbacks: `account.html` on both `localhost` and `127.0.0.1`, using
  ports `8765` and `8770`

Remaining production steps are:

1. Keep verified email sign-up enabled and anonymous sign-in disabled.
2. Configure a production email sender before public registration.
3. Replace `model-store.js` persistence with `generator_models` and append-only
   revision content. Revision lifecycle changes go only through audited RPCs.
4. Prove the authorization boundary with automated tests: anonymous published
   reads; inactive/draft denial; member mutation denial; verified owner
   promotion; role revocation; signup-name edge cases; unforgeable audit rows;
   immutable revision content; and concurrent publish serialization.

Never make a user admin from an email comparison in browser code, signup
metadata, local storage, or a “first account wins” rule. Privileged project
credentials never belong in this repository or a browser bundle.

The schema is a single-admin publishing boundary for this portfolio, not yet
the per-project ownership and collaboration model required by the future
downloadable creator app. It intentionally uses soft deletion for generator
models. Decide on account-retention/audit policy before enabling hosted account
deletion, because authored production records currently retain their creator
references.

## Model document direction

Persist parameter documents, not executable JavaScript:

```json
{
  "format": "sean-generator-preset",
  "version": 2,
  "generatorId": "panel",
  "params": {
    "width": 120,
    "height": 70,
    "thickness": 3,
    "cutouts": [
      { "type": "usb-c", "x": -38, "y": -20, "rot": 0 }
    ]
  },
  "appearance": {
    "color": "#60a5fa"
  }
}
```

The trusted registry maps `generatorId` to the builder function. A later
feature graph can add allowlisted operations such as sketch, extrude, hole,
pattern, fillet, and boolean while keeping executable code out of the database.

The public homepage Workbench, the dedicated Workbench page, its 3D bench
props, and Generator Studio all resolve the same registry entry and parameter
document. Studio is the owner-only publishing view; it does not maintain a
second model or a visual approximation of the public generator.

## Path to the downloadable app

The web Generator Studio is the first product slice, not the final CAD kernel.

1. **Parametric Studio:** finish feature identities, canvas handles, hosted
   drafts, revisions, and publishing.
2. **Model kernel:** move rebuilds into a Web Worker and introduce a robust
   solid kernel such as OpenCascade/replicad or Manifold for booleans, fillets,
   topology tracking, and sketches.
3. **Creator product:** add project files, assemblies, import, constraints,
   command search, plugin-safe generator packages, and collaboration.
4. **Desktop:** package the same document model and worker behind Tauri or a
   comparable small desktop shell. Local files become primary; cloud sync stays
   optional.

The browser and desktop versions should share the document schema, generator
registry, validation rules, and export tests. The renderer is a client of that
model—not the source of truth.