behold triggers CI pipelines as the (prod) apply executor + correlates runs to their stacks — one layer

[lex00]

Idea (deferred — captured from a design conversation)

Today behold's apply (M3) runs chant run --components itself (fine for local mode against Floci). But outside local mode, the CI pipelines are what do the apply — GitLab CI runs the generated per-component pipeline. So behold's role in prod is to trigger the pipeline and observe the resulting deployment, presenting the CI pipeline and the AWS deployment as one layer (the epic's thesis: the component DAG read two ways).

The shape (three distinct things, not two)

1. CI projection (static — what a pipeline would do) — stage / needs: / run-command per component. Already built (M1.2: CI projection facet per component #58): a per-component facet on the DAG. One layer. ✓
2. CI run status (a pipeline executing now) — jobs running/passed/failed. Should color the same DAG exactly like live AWS status does (M1.1: live AWS status per component, on Floci #57), because jobs = components by name (the existing join key). Still one layer.
3. CI run timeline (temporal detail — retries, logs, durations) — belongs in a separate run surface (like M3's structured-progress panel / the lanes view), not smeared on the spatial DAG.

The unifying principle: apply is executor-agnostic (a target concern, M2)

• Local target → behold runs chant run --components itself (M3, done).
• Prod target → behold triggers the CI pipeline; the pipeline's job events stream back as the same structured progress (jobs↔components by name); the same live-status join colors the same DAG.
• behold stays the control plane (trigger + correlate pipeline→stacks) — it never applies to prod directly.

Concrete first slice (local, provable today)

behold triggers a GitLab pipeline via gitlab-ci-local against Floci (already the "Bring up GitLab CI" path in the M5 substrate strip), parses the run's job status, and colors the component DAG by live job status — so you can graph the pipeline and watch it run, correlated to the stacks it deploys. Then generalize the dial's "apply" to dispatch by target (local chant run vs trigger-CI).

Prereqs / relates to

• The target lens (M2) already models targets as an array — the natural place for "who applies".
• The CI projection facet (M1.2: CI projection facet per component #58) and the component-name join key (M1.0: render loomster's component DAG in behold #56/M1.1: live AWS status per component, on Floci #57) are the foundation.
• Needs a live CI-run status source (job → component correlation) and a trigger path per forge (GitLab/Forgejo/GitHub).

Deferred for now — the local, single-target flow is solid; this is the multi-target / CI-driven-apply evolution.

[lex00]

Decomposed into three sized slices, grounded in what exists today:

What exists: the CI facet is generation-time only — chant build --components --generate <forge> parsed by ciPipeline (src/chant.ts), served at /api/ci, joined to the DAG by job.component in the SPA. Zero forge-API code anywhere. The execution seam is OpRunner (single busy-guard, streamed now-line, apply-shaped progress over SSE) plus runCommandStream for non-chant commands; the correlation key is job.component/jobName, and the DAG's waves already are the pipeline's stages.

The slices:

1. CI executor 1/3: the local pipeline run is a first-class action, not a substrate bring-up #163 — local pipeline runs (gitlab-ci-local / forgejo) become first-class OpRunner actions with per-job component progress. Small; proves the whole shape with no tokens.
2. CI executor 2/3: trigger GitHub Actions and follow the run onto the component DAG #164 — trigger GitHub Actions via gh workflow run and follow with gh run watch, painting run status onto the component DAG. Both estates target GitHub; auth stays the operator's own gh login, so behold keeps holding no credentials.
3. CI executor 3/3: the forge pipeline as the designated prod apply executor #165 — the design-gated piece: a .behold.json executor contract routing the Deploy gesture through the forge for designated envs, with gates deferring to the forge's own protection rules and status read back through components status --live.

Keeping this open as the umbrella until the three land.