Support script/scriptPath (or similar) for saved workflows to allow a readable, editable file instead of an embedded string

[Omzig]

Context

Saved workflows are stored as JSON (e.g. ~/.pi/workflows/saved/<name>.json) with a script field holding the entire workflow as an escaped string. This works, but it means the actual runnable source is not human-readable/editable as plain JavaScript without extracting it first (e.g. JSON.parse(...).script), and any hand-edits to a plain .js copy have no effect unless manually re-synced back into the JSON's script field.

Request

Would it be possible to support an alternate/additional field, e.g. scriptPath, on a saved workflow that points to an external .js file containing the script body, as an alternative to inlining the whole script as an escaped string in script?

Possible shape:

{
  "name": "issue_to_pr",
  "description": "...",
  "scriptPath": "issue_to_pr.script.js", // relative to the saved workflow's directory, or absolute
  "parameters": { ... }
}

Behavior notes / open questions for you to decide:

• If both script and scriptPath are present, one should take precedence (probably script, treating scriptPath as an authoring convenience only).
• scriptPath resolution should probably be restricted to within the workflow's own saved directory (project or user) to avoid arbitrary filesystem reads from a JSON config.
• This does not need to change the executed workflow's own capabilities (no imports/filesystem access from inside the running script) — this is purely about how the outer saved-workflow loader locates the script source before executing it, so it doesn't need to conflict with the sandboxing invariants documented for workflow authoring.
• /workflows save <name> / /workflows edit <name> could optionally offer to write to a companion .js file instead of (or in addition to) inlining the script, when this mode is used.

Motivation

Makes it much easier for end users (and agents editing on their behalf) to read, diff, and hand-edit a saved workflow's logic as plain .js with normal syntax highlighting/tooling, without needing to round-trip through JSON string escaping, and without accidentally editing a stale/disconnected copy (today, an extracted .js "reference copy" has no live relationship to the JSON that's actually executed).

Environment

Observed with the currently installed version under @quintinshaw/pi-dynamic-workflows in a local ~/.pi/workflows/saved/ setup. Happy to provide the installed package/skill version info if useful (see references/versions.md in the bundled workflow-authoring skill).

[QuintinShaw]

Thanks — this is a real authoring pain. Saved workflows today only store an inline script string in the JSON, so a hand-edited .js copy is disconnected from what actually runs.

A scriptPath next to the metadata JSON is the right shape. I'd keep these constraints:

• Resolve relative to that workflow's saved directory (project or user). Refuse paths that escape it.
• If both script and scriptPath are present, script wins.
• Loader-only: this does not give running scripts filesystem access.
• /workflows save / edit writing a companion .js can come after the load path works.

Not promising a particular release yet, but this is on the list. Happy to take a PR if you want to sketch the loader first.