Add the visual WebMCP Workbench

[TueJon]

Summary

• add an optional, development-only Shadow DOM Workbench that agents launch without changing the target project
• compare approved manifest tools with live imperative and declarative registrations
• provide schema-driven arguments, valid and invalid example presets, structured results, bounded session history, and confirmation for every non-read-only call
• distinguish Native from Simulated evidence explicitly so portable previews never count as browser verification
• support responsive desktop, tablet, and phone layouts, keyboard use, reduced motion, dark mode, strict CSP, and Trusted Types
• provision a pinned Playwright runtime outside the target project when needed and clean up the temporary browser session on exit

Verification

• npm run check — 40/40 passing
• node tests/workbench-browser.mjs chromium firefox — desktop, tablet, 360px, dark/light, reduced-motion, simulated transport, native-shaped transport, lifecycle, contrast, focus, overflow, strict CSP, and Trusted Types passing
• headed launcher smoke under Xvfb passing
• WebKit downloaded, but no runtime result is claimed because VD-FW lacks its required GTK/GStreamer host libraries

Safety

The Workbench is never wired into a production entry or bundle. Simulated calls are visibly labeled and cannot change a manifest tool to verified.

[TueJon]

P1 — skills/webmcpify/templates/webmcp-workbench.js:108 — normalizeExpected() accepts every manifest entry with an id, while the launcher passes the complete manifest.tools array. As a result, discovered (not yet approved) and terminal rejected tools are displayed as “Expected”/“Observed + expected”; if one is still registered, the Workbench also enables it and permits execution. That crosses the repository's manifest gate: rejected tools are explicitly excluded from every later phase, and this mode promises approved/integrated tools as Expected evidence. A manifest containing {id: "denied", status: "rejected"} is enough to reproduce the false Expected row.

Closure checklist:

• Filter launcher-provided manifest tools to entries that passed the gate; exclude at least discovered and rejected.
• Apply the same status boundary when the template receives a manifest object directly, while preserving the documented explicit expectedTools subset API.
• Add coverage proving rejected/discovered entries never appear as Expected or executable, including when a same-name live registration exists.

[TueJon]

Der blockierende Befund ist in ac46760 vollständig geschlossen.

• Der Launcher übergibt jetzt das Manifestobjekt, statt ungefiltert alle manifest.tools als explizite Expected-Teilmenge zu markieren.
• Manifestobjekte akzeptieren nur approved, integrated, verified und failed; discovered, rejected, skipped sowie statuslose Einträge sind weder Expected noch über die Workbench ausführbar.
• Die dokumentierte explizite expectedTools-Teilmenge bleibt caller-owned und kompatibel.
• Regressionen decken die Statusgrenze sowie einen gleichnamigen live registrierten, abgelehnten Tool-Eintrag ab: sichtbar als ausgeschlossen, ohne Expected-Vertrag und mit deaktivierter Ausführung.

Verifikation: npm test 41/41; Chromium und Firefox auf Desktop, Tablet und Phone; Manifest-Gate in beiden Engines; zusätzlich Chromium Native-Transport sowie Strict CSP/Trusted Types grün.

[TueJon]

No blocking findings. The prior manifest-gate checklist is closed: launcher manifests now use the status-aware path, non-approved entries cannot become Expected evidence, and same-name excluded live registrations are visibly gated and cannot execute; the explicit expectedTools subset API remains intact.

Verified with npm run check (41 tests), the Chromium and Firefox browser suites, and the green current-head CI check. WebKit could not launch locally because its host libraries are unavailable.