Demos

Demos

Every demo in demo/ ran live, against the real web, with artifacts committed. Together they are the proof-of-work behind the README's claims.

The journey — a real agent session end to end (demo/JOURNEY.md)

One run (2026-09-30) of what every agent is asked to do on the web — log into a site, then research something — driven through MCP only: no Playwright, no Chromium, no curl.

• Act 1 — Authenticate: the-internet.herokuapp.com/login — type #username/#password, click submit, real form POST, session cookie stored by WKWebView, /secure + flash verified via /evaluate, screenshot committed.
• Act 2 — Research loop: DuckDuckGo HTML endpoint → 5 results extracted with titles + URLs → first result dead ("Deployment Paused") → agent moves on → dev.to guide opened, read, extracted.
• Demonstrated: real form login with session state, dead-link resilience, content extraction for LLMs, visual verification, zero Chromium anywhere.
• Found along the way: Apple shipping a Safari MCP server (2026) — the same thesis, macOS-shaped. See FAQ and Philosophy.

WordPress — install, publish, comment; and the honest parity number (demo/wordpress/)

• Full install journey (language → database → admin user → dashboard), publish a post, submit a comment — with per-step screenshots, run twice: once on navette, once on Playwright, same journeys.
• Runtime parity with Playwright: 20.7 s → 8.7 s, honestly — same steps, measured.
• The WordPress state files (wp-state.json, wp-admin-state.json) double as storageState-equivalent examples.
• The CI cold-runner race (ci-race workflow): navette vs Playwright on fresh GitHub Actions runners — the documented saga of cold-boot behavior (38 s CI boots are the repo's known constant), the v1.9.0 release asset freezing on cold CI before the listener binds (issue #9, the fix: CI builds from source), and the one-shot wry event-loop navigation race (issue #10, the fix: never issue two navigations back to back + retry after redirects). Every failure mode got forensics committed.

dev.to — the API stops, navette continues (demo/devto/)

• Live login (visible window, human 2FA), 38 notifications read from a page the API stops serving, and a v1.9.0 comment published through the real UI (screenshot committed).
• This demo seeded the dev.to Site Recipes and the reply-bot workflow (integrations/n8n-nodes-navette/examples/devto-replybot-workflow.json).

daily.dev — publish on a site with no API (demo/dailydev/)

• The full working recipe for v1.8.0: log in once, then post link-posts with and without commentary through the real UI (screenshots: linkpost-preview.png, linkpost-with-commentary.png).
• The recipe is now the Site Recipes memory; the cross-post workflow (demo/crosspost/workflow.json) wires dev.to → daily.dev in n8n — a real post published for real (dedup by profile + settle window; the anti-duplicate fix is part of the workflow).

leboncoin — human-moments design in the wild (demo/leboncoin/)

• Authenticated pro-space navigation behind a login wall: human logs in once (session_show), the state is saved, then searches run automated (search screenshot + extracted stats JSON committed). The demo that validated the "never a captcha — show the window" design against a hostile-to-bots site.

signed-webhook — sealed counterparty events (demo/signed-webhook/)

• Fraud analysis as a diff over an HMAC-chained mock webhook stream (closes issue #5) — the "agent verifies integrity, not just content" pattern, self-contained server.py.

The pattern across all of them

1. One-time human login (visible window) → state saved to the keychain.
2. Automated passes: navigate → wait → extract (targeted evaluate, JSON out) → act → screenshot to verify.
3. Artifacts committed: screenshots, extracted JSON, state files, workflows — every claim auditable.