Workflow authoring + test/verify in Loom: hosting gxwf and/or Planemo

_Filed by Claude (AI assistant) on behalf of @jmchilton — drafted in a design session, not authored personally by them._

## The gap

Loom today is excellent at **running** an analysis: it routes steps local/Galaxy, invokes Galaxy via MCP, tracks invocations in `loom-invocation` blocks, and verifies *runtime* artifacts (dataset state, BAM/VCF/FASTQ checks, Galaxy job state). What it has **no** story for is **authoring and verifying a Galaxy workflow** — static `gxformat2` validation, and workflow test execution with real assertions.

Those two jobs map onto two hardened, deterministic CLIs the Galaxy ecosystem already owns:

- **`gxwf`** (`@galaxy-tool-util/cli`) — design-time: `gxformat2` schema validation, tool/ID/`+galaxyN` checks, `input_connections` cross-checks, conditional-selector validation, tool discovery, conversion.
- **`planemo`** — runtime: executes a workflow's tests against a Galaxy and emits structured pass/fail. This is the test-runner/verifier (tens of thousands of lines of hardened run-and-verify logic).

This is the same discipline Loom already practices — *deterministic tools produce the evidence; the harness calls them and never claims "done" without it.* We'd be extending that discipline from analysis-runs to workflow-authoring. The two CLIs are **first-class runtime capabilities**, in the same spirit as the Galaxy MCP server Loom already manages — not things the model reasons its way around.

## Why now

The [Foundry](https://github.com/galaxyproject/foundry) casts Galaxy workflow-construction skills (and, in progress, whole source→Galaxy pipelines) that Loom can consume through the existing `skills_fetch` path. Nearly every one of those skills bottoms out in `gxwf` (authoring/validation) or `planemo` (test/verify) — by design, because the Foundry deliberately leaves deterministic work to deterministic tools. So consuming that whole class of skills depends on Loom being able to run these CLIs.

This also stands on its own, independent of Foundry: "Loom can author and test workflows, not just run them."

## Non-goals (important)

- **Not** replacing or reimplementing Planemo's test execution / verification with anything model-driven, MCP-driven, or ad-hoc. Planemo is the deterministic verifier; Loom **calls** it. Same for `gxwf` validation — it is the authority, not a hint.
- **Not** asking the model to decide whether workflow outputs "look okay." The whole point is to route that judgment to Planemo.

## The two capabilities

These are two distinct capabilities. Whether they're one effort or two — or whether both are even wanted — is open (see open questions); this issue does not assume they belong together.

### `gxwf` (static workflow authoring / validation)

Static, no Galaxy server required, Node CLI (`npx --package @galaxy-tool-util/cli gxwf`, or installed). Used for: validate a draft (`gxwf draft-validate --concrete`), the per-step loop oracle (`gxwf draft-next-step`), terminal validation, tool search, format conversion.

**The crux question: where does `gxwf` run?**

- **(a) Local bash** — agent shells out. Simplest, but unavailable where there's no bash (native Windows remote-only; web Remote mode blocks bash) and subject to exec-guard `ask` prompts. Confines workflow authoring to desktop/local shells.
- **(b) Managed brain capability** — the brain bundles/provisions `gxwf` and exposes it as registered tool(s) (the way `galaxy-mcp` is registered), independent of the `bash` tool. Works regardless of bash availability (potentially even remote/web), gives clean gating + `activity.jsonl` audit, no per-call permission prompts. Cost: `gxwf`/Node must be present in the brain's runtime across platforms.
- **(c) Server-side / service** — `gxwf` runs off-box. Heaviest; noted only as the far end of the spectrum.

This answer determines remote / web / Windows viability **and** where the loop oracle (`gxwf draft-next-step`) lives, so it shapes everything downstream.

### `planemo` (workflow test execution / verification)

Needs a Galaxy to run workflow tests against, and runs long.

**Hosting questions:**
- **Which Galaxy does it target?** A Planemo-managed ephemeral/containerized Galaxy, or the user's connected server (via the existing profile / `/connect` model)? Different infra and isolation trade-offs.
- **How does it run under the exec-guard?** Planemo test runs are long-lived — they likely want Loom's existing **background-execute-and-notify** pattern (the same shape used for Galaxy invocation polling, surfaced in the Activity tab), not a blocking in-turn call.
- **Where does it install / live?** (`uv tool install planemo` / `uvx --from …`), and how is the version pinned.

What shells this can run in is part of the capability-gating question (below).

### Capability detection + graceful degradation

`gxwf-available` and `planemo-available` become capability flags — exactly like the existing `isLocalShellAvailable` / Galaxy-connected gating — that decide whether workflow-authoring/testing flows can run in a given shell, and let the init-gate refuse cleanly with a remediation message when they can't.

## Open questions

- Do these two capabilities belong in one effort, or should they be pursued independently (or not at all)?
- `gxwf` hosting: (a) local bash, (b) managed brain capability, (c) server-side? (determines remote/web/Windows reach + loop-oracle location)
- Planemo target Galaxy: managed-ephemeral vs. the user's connected server?
- Do long-running Planemo runs reuse the existing background-poll-and-notify machinery, or need a new one?
- Config surface: where do these capabilities live in `~/.loom/config.json` and how are versions pinned?
- Per-shell availability matrix (desktop / CLI / web-desktop / web-remote / Windows-remote) — what's in scope?

## Relationship to other work

- Enables Loom to consume Foundry's authoring/pipeline casts via the existing `skills_fetch` path.
- Companion to the Foundry-side "lower a pipeline into a Loom plan" work: galaxyproject/foundry#306 (that work assumes these CLIs exist at runtime).