How to Use the Logger

A Gravitor Part is a single physical component — an emitter disc, a dielectric sheet, a ground plate. Inventory you keep on a shelf.

Equipment is one of two things: a Build (a Gravitor or Faraday cage you assembled) or Purchased equipment(an HV supply, scale, probe, camera, multimeter). Builds reference the parts they're made from.

A Test is a single experimental run. It points at one Gravitor (the bench article being tested) and any other Equipment in the run (HV supply, scale, etc.), captures voltage, weight changes, environmental conditions, and observations. Media (photos, OBS recordings) hangs off either a Test or a Build.

New parts and new equipment are added by Claude, not a form. From either Gravitor Parts or Equipment, the top-right Add … with Agent button opens a Claude session pre-loaded with the right schema. You paste either a product description or a URL and Claude extracts every field it can, shows a confirmation table, and posts to the backing API once you OK it.

First-time use: in the terminal that opens, type /login and follow the instructions to authenticate Claude. After that, future sessions reuse the auth.

If you give a URL, Claude uses WebFetch on it; the supplier listing usually has every spec you need (brand, model, voltage range, dimensions). For Gravitor parts (emitter / dielectric / ground plate) the agent knows to ask about material, dielectric constant, breakdown field, point geometry, etc.

On the Gravitor Parts page below the inventory list. Pick one emitter, one dielectric, one ground plate, set an applied voltage in kV, and dial in a safety margin (50%–95%). The builder does:

• Bulk breakdown = dielectric.breakdownField (kV/mm) × thickness (mm).
• Safe ceiling = bulk breakdown × your safety margin. Anything at or above this is flagged red.
• Recommendations populate as you change inputs — the required dielectric thickness for the voltage you want, or the safe voltage for the dielectric you picked.

Once the verdict is green, the Build Gravitor into system button creates a new Gravitor with status: planned and the three sub-parts wired up. From there, walk it through the stage stepper (planned → building → completed) on its Equipment detail page.

The 95% upper limit on the safety slider sits right at the edge of material failure. Anything higher than that and bulk breakdown values stop being meaningful — surface defects, corona, edge effects start dominating.

Open any equipment row that has a build lifecycle (Gravitor, Faraday cage, etc.) and the page header shows a Stage card with three pills: Planned → Building → Completed. Click any pill to jump that build to that stage. Side pills below the line ( Active · Retired · Broken · Damaged ) are terminal states.

The moment status enters building (or any non-planning state) the auto-publish fires and a snapshot shows up on emgravity.space/builds/[number] for referees. Subsequent edits and recording stops keep the site in sync.

On any equipment detail page, the OBS controller card (between the Stage stepper and the media gallery) has scene switching, source toggles, a single live preview, and a Record this build button. Clicking it tells OBS to StartRecord and stamps ownership on this equipment row. Click Stop & save when done and the file is remuxed MKV→MP4, attached as Media on this equipment, and auto-published.

If OBS is already recording (e.g. you hit START in OBS itself), the button reads Claim this recordingand takes ownership without starting a duplicate. Pausing requires OBS Settings → Output → Recording → Recording Quality set to anything other than “Same as stream” (the default in Simple mode doesn't support pause).

The build overlay browser source at /obs/overlay/build auto-fills with the active build's title, description, and parts list whenever a recording is live, so the broadcast shows what you're working on.

Gallery shows every photo and OBS recording, grouped into Videos and Images. Each card has Edit (rename the caption, adjust tags) and Delete (removes both the DB row and the file on disk — irreversible). Edits never touch the file itself, only the metadata describing it.

Videos stream via Range requests, so seeking inside a 1+ GB recording is fast even though the file lives on the filesystem. The endpoint serves MP4 with Accept-Ranges: bytes; browsers handle the rest.

Agents opens a picker of registered projects. Click a project and you land on a page with an embedded terminal already running Claude Code in that project's working directory.

Three slugs ship by default: logger-self (open Claude on the logger codebase), add-part (the Gravitor part guided flow), add-equipment (the equipment guided flow). Add more by editing agent-projects.json at the repo root.

Architecture: the terminal is xterm.js in the browser, talking over a WebSocket to a Node sidecar at 127.0.0.1:7777. The sidecar owns the PTYs. Slugs are the only way to specify a working directory (no raw paths from the client), and the sidecar binds to localhost only. The session token is in .env.local as AGENT_SESSION_TOKEN; if unset, both processes use a deterministic dev fallback.

Quick prompts in the left rail are project-specific buttons that paste a prompt into the running session and submit. Defined per slug in agent-projects.json.

Any equipment that enters a publishable status (building / completed / active / retired / broken / damaged) auto-pushes its metadata and media to the public site. Raw Gravitor partsnever publish — they're inventory, not exhibit material.

Deletes mirror too: removing a published build on the logger calls the site's DELETE endpoint and the row goes away on the next page load. Re-publishes use cached blob URLs so a 1 GB recording isn't re-uploaded every time you bump a label.

The site splits the result into two sections — Builds and Purchased equipment — at emgravity.space/builds (gated to signed-in referees).

npm run dev runs Next + the agent sidecar concurrently. Color-tagged output shows next and agent lines. To run them separately: npm run dev:next, npm run dev:agent.

On a fresh npm install, the postinstall hook re-applies the executable bit on node-pty's spawn-helper, which npm otherwise strips during extraction (causing PTY spawn to fail with posix_spawnp failed).