[RFC]: Feasibility study — WASM/Pyodide sandbox for skill execution (sub-issue of #17)

[rosspeili]

Summary

Sub-issue of #17. Evaluate RFC Option 2 (WASM/Pyodide) against the current Skillware registry and contributor model. Output is a go/no-go recommendation with skill-by-skill compatibility matrix — not an implementation commitment.

Motivation

#17 proposes Pyodide to block os/subprocess for untrusted skills. Before investing, we need to know whether real skills (pymupdf, requests, google-genai, anthropic, local JSON corpora) can run in WASM at all. Contributor friction and agent-loop latency are major drawbacks listed in #17.

Detailed Design

Study tasks:

1. Inventory registry skills and classify dependencies:

   • Pure Python stdlib
   • Native extensions (pymupdf/fitz, etc.)
   • Network clients (requests, SDKs)
   • Filesystem-heavy (PDF paths, maintenance JSON)

2. Prototype one simple skill (e.g. optimization/prompt_rewriter) in Pyodide if feasible; document blockers for others

3. Compare to 17d (subprocess) and 17b (trust flags) on:

   • Dev experience (contributor writes normal skill.py?)
   • Cold start / per-call latency
   • Packaging (wheel size, runtime download)

4. Deliverable: docs/security/wasm-feasibility.md with recommendation:

   • Defer (likely for pymupdf/network-heavy registry)
   • Partial (sandbox tier for stdlib-only community skills)
   • Reject for v1.0 default path

Post summary on parent #17; link doc from trust-model doc (17a).

Drawbacks

• Spike time may conclude WASM is incompatible with most current skills — still valuable to record
• Pyodide version drift and maintenance burden
• False sense of security if only some imports are blocked but host bridge exists