Launch smoke test — what to click, what to look for

A runbook for an agent (or human) tasked with clicking through the whole drobek surface before a deploy. The agent that runs this is not the agent that built it — assume zero context. The goal: catch broken links, stale copy, layout regressions, and end-to-end flow breakage on the live build.

How to use this doc. Work top to bottom. For each row, perform the action, check the expectation, and report PASS / FAIL with a one-line note + screenshot path. At the end, post the consolidated report (see §10) — not a stream of comments.

1. Setup

task up                  # docker compose dev stack
task ps                  # confirm web (3011), mcp (3012), postgres, redis are Up

Open the marketing surface at http://127.0.0.1:3011/. The product surface is reached by clicking Start free → sign-up → onboarding wizard.

If task up is not available, fall back to pnpm --filter @drobek/web dev and pnpm --filter @drobek/mcp dev in two terminals.

Browser: Chromium-based, both light and dark themes. The theme toggle sits in the top-right of the marketing nav.

2. Public marketing surface — every route must return 200 and render

For each row: navigate, wait for full hydration, confirm the page does not flash an error boundary, confirm the listed copy fragment is present, take a screenshot.

Negative routes (must 404)

3. Navigation + footer

On /:

• [ ] Top nav has links: Features, Pricing, Docs, Blog, Changelog, Status. Every link navigates to the matching /path and shows the active state.
• [ ] Theme toggle flips light/dark, persists across reload (check localStorage drobek-theme).
• [ ] Sign in and Start free buttons both go to /login.
• [ ] Footer shows: Product (Features / Pricing / Changelog), Resources (Docs / Blog / Status), Company (About / FAQ / Terms / Privacy / Cookies / DPA). NO hello@drobek.app mailto. Footer city = Brno. "Built by Tomáš Grasl" links to https://www.tomasgrasl.cz/ in a new tab.

4. Favicon

• [ ] GET /favicon.svg → 200, image/svg+xml
• [ ] GET /apple-touch-icon.svg → 200
• [ ] Browser tab shows the drobek mark (gradient circles), not a generic earth/document icon.

5. Cookie banner

First visit (incognito or clear drobek-cookies-v1):

• [ ] Banner appears at the bottom on every public page (it does not block first paint).
• [ ] Accept all → banner closes, localStorage.drobek-cookies-v1 set with all three categories true.
• [ ] Reject non-essential → banner closes, only strict: true stored.
• [ ] Customize → modal with three toggles; _Strictly necessary_ is locked on, others editable; Save preferences closes modal and persists.

6. Sign-up + onboarding flow

This is the core funnel. Run it on a fresh email each time.

1. From /, click Start free → /login.
2. Click Sign up (or use magic-link, depending on which is wired). Provide a fresh email + password.
3. Verify the magic-link email arrives in Mailpit (http://127.0.0.1:1080 if running locally) and click the link.
4. You should land on /onboarding/org. Pick a slug → submit.
5. /onboarding/repo — skip (it is optional).
6. /onboarding/agent — submit. Token is shown exactly once; copy it.
7. /onboarding/client — verify the page shows:

- the MCP URL, - JSON snippet for Claude Desktop, - "Add to Claude Code" copy button.

1. Reload /onboarding/client — token is replaced with a prefix-only placeholder and a callout pointing at Settings → Agents.
2. Click Finish → land in the workspace at /o/<slug>.

Expected post-conditions:

• [ ] users.onboarding_step is done (verify by reloading any product route — no redirect).
• [ ] Workspace sidebar shows the org, an empty Plans / Tasks / Knowledge list.

7. MCP end-to-end (the verification engine is the hardest path)

Configure a real MCP client (Claude Desktop or mcp-cli) with the URL + token from §6, then exercise the loop:

1. Call add_task with { title: "Smoke test task", description: "from runbook" }.
2. Reload /o/<slug>/tasks → the task appears with status proposed.
3. Approve it from the UI → status moves to ready.
4. Open a PR on the connected repo that references the task id (e.g. branch name drobek/T-XXX-smoke). Or simulate via the GitHub webhook test fixture in apps/mcp/src/routes/webhooks-github.integration.test.ts.
5. Merge the PR with a green CI check.
6. Watch the task transition: claimed → in_progress → done. The verification engine should close it without any manual "mark done" step.

Bonus:

• [ ] Try claim_task from a second agent on the same task — second call returns task.already_claimed.
• [ ] Let a lease expire (10 minutes) — task returns to the queue.

8. Status page — make it lie, then make it tell the truth

• [ ] On a healthy stack, /status shows "All systems operational" with four green rows.
• [ ] Stop the MCP container (docker compose stop mcp) → reload /status → MCP row is red with a detail like connect ECONNREFUSED. Page itself stays 200.
• [ ] Stop redis → Redis row red. Restart everything → all green on next reload.

9. GDPR self-service (DSR)

From Settings → Account:

• [ ] Export downloads a JSON containing the signed-in user's row and every org row they own.
• [ ] Delete shows a 7-day grace warning. Cancel → account remains. Confirm → on next sign-in the account is gone, with a clear "account deleted" message.

10. Reporting format

At the end of the run, post a single comment in this shape (no chat thread):

LAUNCH SMOKE — <date>, <commit sha>
Pass: <count>/<total>

FAIL § 2.4 /about — footer still shows "Built in Prague" on mobile (≤ 640px). screenshot: ./reports/2024-xx-xx/about-mobile.png
FAIL § 7.5 mcp e2e — claim_task returns 500 with NULL org_id when called via agent created in §6. server log attached.
NOTE § 5 cookie banner — text wraps badly at 320px width but functional. low priority.

Done.

Rules:

• One line per finding.
• Reference the section number (§ 2.4) so the fix maintainer can locate it.
• Attach screenshots / log excerpts as file paths under ./reports/<date>/, not inline.
• Do not file issues; the maintainer triages from this report.

What this runbook deliberately does not cover

• Admin portal (/admin/*). Audit those changes separately when admin work lands.
• Production deploy (Hostinger VPS, nginx). The deploy runbook lives in docs/runbooks/.
• Localised marketing pages other than the legal docs — translations are header-only at v1.
• Performance / Lighthouse scoring. Run that in a separate pass once smoke is green.

If you find a route that exists in the codebase but is not in this doc, add it under §2 and re-run that section. The doc is meant to grow with the surface.