[discuss] Plugin system for user-land selection transforms

[mertbekci]

Split out from #81 — parking lot for discussion, no implementation planned yet.

Idea

Allow users to write small scripts that register custom transforms in the right-click selection menu. Examples someone might write:

• extract JWT payload — decode the selected JWT and replace with the payload JSON
• unescape unicode — convert \\u00e7 → ç
• pretty-print XML — indent the selected XML
• URL → cURL one-liner — build a curl command from a URL
• Lorem ipsum N words — generate placeholder text

Open design questions

• Sandbox. Use the existing pre/post-request VM2 sandbox (Pre-request & Post-response scripts #20)? Or a separate, more constrained one? Selection transforms are pure string functions; full vm is overkill.
• Distribution. Where do plugins live — a single .scrapeman/plugins/ folder per workspace? A user-level ~/.config/scrapeman/plugins/? Both?
• API surface. Minimum: (input: string) => string. Extended: access to current request context, environment variables, network calls?
• Discovery. Bundled "official" plugins (encode/decode etc.)? A registry?
• Trust model. Plugin code runs in the renderer process — escape from the VM is renderer-level access, which is meaningful. Run in a worker? Disable network for plugins by default?
• Name conflicts. Plugin names clashing with built-ins. First-write-wins? Built-ins take priority?

Why parking-lot

Plugin systems are a tarpit — the API surface decision today shapes years of upgrade pain. Nothing about Scrapeman's current scope demands them. Bundle the common transforms (#B-issue) first, watch what users actually want, then come back to this.

Acceptance criteria

This issue stays open until either:

• A user submits a transform that genuinely doesn't fit as a built-in, or
• A second user requests something close to plugin functionality (script-based transforms, custom UI hooks, headless integrations)

Whichever comes first triggers a real design RFC.

Parent: #81