FAQ & troubleshooting

Password hashing uses the native @node-rs/argon2 binding. Two known sharp edges:

Bundling: the binding must stay external — next.config.ts already sets serverExternalPackages: ['@node-rs/argon2']. Don't remove it.
Unsupported build target (some CI images / exotic platforms): the binding fails to load and Mapford throws a loud error rather than silently downgrading. The documented fallback (SPK-6) is deliberate and manual: install bcryptjs, swap the implementations behind the same hashPassword/verifyPassword signatures in src/auth/password.ts, and rehash-on-login by detecting the $argon2id$ prefix. Don't enable it without deciding to.

Where does my local data live? How do I reset it?

DB_DRIVER=pglite (the default) stores the database as files under ./.data/pg (configurable via PGLITE_DIR). To reset completely:

rm -rf .data/pg
pnpm db:setup && pnpm seed

"Engine not configured" when starting a run

By design. An engine without credentials reports configured: false, preflight shows ✗, and run creation rejects it server-side — there is no silent mock fallback. Fix: set the env vars (DATAFORSEO_LOGIN/DATAFORSEO_PASSWORD for chatgpt, gemini, and the two Google SERP engines ai_overviews and ai_mode; PERPLEXITY_API_KEY for sonar) and restart pnpm dev and pnpm worker. For a keyless walkthrough, use the mock engine (dev/demo only).

My run sits at "queued" forever

Outside demo mode, runs are executed by the worker — is pnpm worker running in another terminal with the same env? In demo mode runs execute instantly in-request, so this only happens in real mode.

How do I reset the demo data?

Demo data (DEMO_MODE=1) is in-memory and reseeds itself on every cold start — on Vercel it resets whenever the instance recycles; locally, restart pnpm dev. Nothing you do in the demo persists, including share links (they may stop working at any time — the app warns when you create one).

I lost the operator password

If you still have the mailbox, use Forgot your password? on the sign-in card. The link works once and expires in an hour, and setting a new password signs out every session that was open. If the account has the second sign-in step turned on, the reset page asks for a code as well — a recovery code works there too. That is deliberate: without it, reaching the mailbox would be enough to get past both steps.

The command line is the backstop, and the only path when the mailbox is gone, when both the authenticator app and the eight recovery codes are gone (add --reset-mfa), or on a deployment with no email key configured:

pnpm user:set-password <email>

It writes a new hash directly and invalidates all existing sessions for that user. Works against whichever database the env points at (local PGLite or Supabase).

Where do access requests land in the demo deploy?

Every "Request a walkthrough" submission is written to the access_requests table and always emitted as a structured log line ACCESS_REQUEST {json}. On the demo deploy the table is in-memory — the log line is the durable copy, retrievable from Vercel Logs. Caveat: Hobby log retention is short (hours-to-days), so check logs regularly during the demo period; this is a documented stopgap until Supabase, where the rows persist and show up at /requests.

Do you guarantee ChatGPT recommends my client?

No — and be suspicious of anyone who does. See How we measure and the technical methodology for what we do claim, and with what error bars.