🤖 verify — drive the web app end-to-end against a local build

How to observe a web/chat change in a real browser, fast (no fixtures in the repo; everything is provisioned over the real protocol).

Build + run

go build -o /tmp/lchat .
LCHAT_ADMIN_TOKEN=verifytok LCHAT_DB=/tmp/verify.db ADDR=127.0.0.1:18711 /tmp/lchat &

Provision a member + thread from Node (no UI clicking)

web/static/crypto.js runs under Node. (Node ≥20 already HAS globalThis.crypto and it's a getter-only property — assigning webcrypto to it throws TypeError: Cannot set property crypto. Just import crypto.js by ABSOLUTE path and use it.)

1. randomSecret() → deriveInvite(T) → {id, claimHash, claimSecret}.
2. POST /api/admin/key-invites (Bearer admin) {label, id, wrapped:"", claim_hash}.
3. POST /api/key-invite/{id}/claim {claim_secret} → {token}.
4. POST /api/pubkey {token, public_key} — generateUserKeypair() returns {publicKey, privateKey} (base64url), not {pub, priv}.
5. GET /api/roster?token= → {roster: [...]} — find yourself by public_key.
6. generateKey() → {key, b64}; wrapThreadKey(b64, myPub); POST /api/threads {token, kind:"group", name_blob: encrypt(key,{name}), members:[{user_id, wrapped}]} — a group of one is valid and mounts the real chat engine (a self thread mounts a mini-app instead).

⚠️ The thread-id field names differ by direction, and getting one wrong fails SILENTLY as an empty result, not an error:

• POST /api/threads returns {thread_id} (not id).
• GET /api/messages?token=…&thread=… takes thread (not thread_id); a wrong/absent one 403s {"error":"not a thread member"}, so a naive (r.messages || []).length reads as 0 messages and looks like your feature failed to post. Assert on the count of messages only after checking the response isn't an error — or read the DB (sqlite3 /tmp/verify.db "select thread_id, count(*) from messages group by thread_id;"), which never lies.

Drive it in Chromium (Playwright)

Seed the session before page scripts run, then assert on the live DOM:

await ctx.addInitScript(([sess, tid]) => {
  localStorage.setItem("lchat_session", JSON.stringify(sess)); // {token,name,userPub,userPriv}
  localStorage.setItem("lchat_active", tid);
}, [session, threadId]);

• Live selectors: .chatapp-root .composer .composer-input, .chatapp-root .send-btn, .chatapp-root .composer input[type=file], .chatapp-feed .msg, .composer-preview .preview-chip. (The id-based #feed/#text skeleton is the retired classic chat — always empty.)
• The composer is a ProseMirror contenteditable, not a <textarea> — so .fill() doesn't work (the locator never resolves and you get a 30s timeout). Click it and type: await page.locator(".composer .composer-input").click(); await page.keyboard.type("/gif cats"); await page.keyboard.press("Enter");
• Panels are dismissed, not removed: after panel.close() the .cmd-panel element survives as an empty container — assert isVisible() === false (or that its body is gone), never count() === 0.
• Reset the DB between runs. State persists, so a second run of a "first-launch asks for X" test finds X already set and the form never appears.
• External APIs: ctx.route("**://*.giphy.com/**", …) to fulfil a fake page + bytes — lets the whole tap-to-post path run with no real key, and the route handler can record the api_key each call used (which is how you prove which key a search read).
• Slow/failing uploads: page.route("**/api/upload*", …) with a delay or a 500 — perfect for in-flight-upload races.
• alert() paths: register page.on("dialog", …) or the page wedges.
• Test users render as "Someone" unless they publish encrypted labels — harmless.
• A known Playwright install lives at ~/.npm/_npx/e41f203b7505f1fb/node_modules/playwright/index.mjs (browsers in ~/Library/Caches/ms-playwright); npx playwright works too.

Worked example (provision + 14-assertion drive): the scripts from the send-waits-for-upload verification — re-create from this recipe.

⚠️ Fixtures must never be a fresh space's first boot

The FIRST member to boot a fresh instance mints its shared instance key (#785). A throwaway harness member doing that — then vanishing — orphans the key: real members who join later stay keyless forever (invites break, names don't decrypt). So when a canary will be handed to a person afterwards, let THEM claim first; or reset the instance DB before handover; or check GET /api/instance-key shows your fixture isn't the sole holder you're about to destroy.