feat: Integrate Archon Studio into Archon

[seanrobertwright]

Overview

Archon Workflow Studio
is a React-Flow visual workflow builder for Archon (v0.9.0, MIT-licensed). It lets
users build and edit Archon workflow YAML on a canvas — drag-and-drop nodes, an
inspector panel, a live YAML preview, and full editor polish (undo/redo,
multi-select, copy/paste, alignment, auto-arrange). I'd like to contribute it
upstream and am opening this issue first to get your read on the shape before
cutting any PRs.

Why it's valuable

Archon's current builder doesn't support the loop, approval, cancel, and
script node variants. The Studio's data model and canvas cover all four — so
this closes that gap and gives the workflow engine a visual authoring surface that
matches its full node vocabulary.

Integration target — the console experiment, not new packages

To keep blast radius at zero, the Studio lands inside the existing console spike
at packages/web/src/experiments/console/ (mounted under /console/*), as a
builder/ sub-surface. Specifically:

• No new top-level packages. Everything lives under experiments/console/.
• The production /workflows/builder route is untouched.
• It inherits the console spike's isolation guard (enforced by ESLint,
  --max-warnings 0): skill verbs in console/skills/ are the only server
  mutation surface; no production-web imports (@/components, @/hooks,
  @/routes, @/stores, @/contexts); no named @/lib/api (type-only
  @/lib/api.generated only); no React Query (uses the console's store/cache.ts);
  console oklch design tokens, no ad-hoc hex.
• Logging is removed from the port (no console.*, no logger module); errors
  surface through the console's existing HttpError / skill-verb return values,
  never swallowed.

This is an isolated experiment, validated by dogfooding under /console. Nothing
user-facing is replaced, so no migration story is needed — extracting it to a
real package and replacing the production builder would be a future, separate
effort gated on the experiment proving out.

Proposed delivery — 3 sequential PRs

Each PR is independently reviewable and revertable, split by layer. Strict gate:
each merges before the next opens.

1. PR-1 — Data model + node variants. Types, validation pipeline, when:
   builder, $<nodeId>.output reference scanning, and the four node variants
   (loop/approval/cancel/script), reconciled against the console's existing
   primitives/workflow*.ts. Pure data layer + tests. No canvas, no wiring.
2. PR-2 — Visual builder UI. React-Flow canvas, node palette, inspector, YAML
   preview, editor polish. Styled with console tokens, renders against PR-1
   fixtures. Depends on PR-1.
3. PR-3 — Connected mode. Load/save/validate as console skill verbs over
   lib/http.ts, cache wiring via store/cache.ts, builder route mounted in
   ConsoleApp.tsx. Reuses existing GET/PUT /api/workflows/:name +
   POST /api/workflows/validate — no new server endpoints. Depends on PR-1 + PR-2.

Licensing

The Studio repo is MIT-licensed, matching Archon. The ported code becomes part of
Archon under its existing MIT license.

Open questions for maintainers

1. Is packages/web/src/experiments/console/builder/ the right home, or would you
   prefer a separate experiment folder?
2. How much of the Studio's editor polish (smart guides, distribute, theme picker,
   auto-arrange) is worth carrying vs. trimming as YAGNI for a spike?
3. Any concerns with the 3-PR layered split, or a sequencing you'd prefer?

Reference

Following the precedent of the OpenCode integration tracking issue (#1422), and the
console spike's isolation contract (packages/web/src/experiments/console/README.md).

[seanrobertwright]

Decision recorded: editor polish vs YAGNI (open question #2)

Reached with @Wirasm in the PR-2 review (#2015) and writing it here so it's recorded rather than re-litigated.

Open question #2 — "how much editor polish is worth carrying vs trimming as YAGNI for a spike?"

• Theme picker: dropped. Reconciled to the console's oklch design tokens; the Studio's own light/dark/high-contrast picker is not carried.
• Everything else that landed in PR-2 is banked, not trimmed — undo/redo (coalesced), multi-select (shift-click + marquee), copy/paste/cut, alignment, distribute, auto-arrange (dagre), smart guides, grid snap, and the keymap/help overlay. Rationale: it's all pure, DOM-free logic with ~290 bun:test units, behind the console isolation flag — cheap to keep, and cheaper to revert (delete the folder) if it turns out to be gold-plating. Ripping out tested, isolated code now would cost more than it saves.

The rule going forward: core-path-first, polish-later.

• No further editor polish lands until PR-3 (connected mode) proves the core path end-to-end.
• PR-3's acceptance gate is the bar: a non-YAML author can produce a valid, persisted workflow — i.e. the load → edit → validate → save round-trip works through the console skill verbs. We don't gold-plate ahead of that.
• If dogfooding under /console then shows some of the banked polish is unused, it gets cut at that point — the folder-revert isolation makes that a cheap reversal.

Open questions #1 and #3 are effectively settled by the PRs themselves: the home is packages/web/src/experiments/console/builder/ (PR-1 merged, PR-2 approved there), and the 3-PR layered split (data → UI → connected mode) held and reviewed cleanly. PR-2 is approved and ready to merge; PR-3 follows as the core load/save path with no new polish.