FM-932 — Images pipeline page and recipe editor

[Andreas-Froyland]

Epic: #121 · Depends on: FM-930

Context

#109's remaining scope is the web editor slice; recipes/versions/builds/promotion exist in API and CLI.

Goal

An Images page using the pipeline layout (recipes → versions → templates → environments, with lineage highlighting), a structured Proxmox editor paired with a raw .pkr.json editor that preserves unknown fields, build start with live log, and manual promotion showing its evidence.

Architecture reference

docs/planning/web-console.md (Lab/Images); mockup lab-b-pipeline.html; FM-700/701.

Dependencies

FM-930

Research required

CodeMirror 6 JSON mode (license).

Acceptance criteria

• Structured edits round-trip through raw JSON without dropping unknown fields
• Stale template pins highlighted
• Closes M7 epic: Packer recipes, image builds, and version promotion #109's web editor slice

Non-goals

• Automatic rebuilds

Tests

Round-trip tests, component tests, e2e build/promote against the stub API.

[Andreas-Froyland]

Implementation approach (Claude)

UI-only, over the existing images and Lab APIs (FM-700/701, FM-930). No backend changes.

• /images, the pipeline layout (mockup lab-b-pipeline.html): four columns of recipes → image versions → Lab templates → environments.
  • Selecting any item highlights its lineage in both directions: recipe ↔ versions ↔ templates pinning them ↔ leases of those templates.
  • Joins use the ids the API returns: RecipeVersionDto.recipeId, LabTemplateDto.imageVersionId, and lease templateVersionId resolved to its template.
• Stale pins: a template pinning a version that is not its recipe's promoted version (superseded or never promoted) is flagged in the templates column and on the version.
• Recipe editor: metadata plus a structured Proxmox form paired with a raw .pkr.json editor.
  • The structured form reads and writes exactly the flat keys fleet-core's StructuredRecipe::from_raw reads (first proxmox-iso/proxmox-clone builder: node, vm_storage_pool/storage_pool, iso_file, iso_storage_pool, clone_vm/clone_vm_id, cores, memory, disk_size, bridge, ciuser, sshkeys), so the draft and the published version's server-side structured view agree.
  • Edits patch the parsed JSON in place, so unknown fields, other builders, provisioners, and variables survive a structured edit. Clearing a field removes the key.
  • The raw text is kept verbatim unless a structured field changes.
  • Non-JSON (.pkr.hcl) templates, or JSON with integers beyond JS's safe range, get raw-only editing, with the reason stated.
  • The builder's node, storage pool, and builder type feed the draft's metadata fields.
• Raw editor: CodeMirror 6 (codemirror + @codemirror/lang-json, MIT). It is loaded lazily, so it only affects the Images route bundle. The license check runs in CI.
• Versions:
  • Publish (idempotent by digest).
  • Build with optional secret variables (name → secret reference only; values never pass through the UI). The build is followed live through the durable operation: validate → build progress, then the result's Packer says lines and the artifact id.
  • Controller gap: the executor does not stream Packer's log, so "live log" means the operation's progress and final machine-readable output.
• Manual promotion shows its evidence: the build operation (state, artifact id, output). Promote is confirmed first. The gate is the controller's; the UI shows the refusal as-is.
• Tests:
  • Structured ⇄ raw round-trip tests (unknown fields, other builders, clone_vm vs clone_vm_id, removal).
  • Lineage and stale-pin unit tests.
  • Component tests.
  • e2e edit → publish → build → promote against the stubbed API client.