investigate: rendering and projecting chant Ops and lifecycles — what are the views?

[lex00]

Synth rendering (graph/estate/carve lenses) keeps getting better and stays the higher priority. This issue begins the thinking on the other two chant surfaces behold barely draws: Ops and lifecycles. It is an investigation, not a build commitment.

What chant exposes today

Ops — declared in source (*.op.ts: phased activities like flociUp → awsApply → httpCheck → flociDown), run on Temporal, driven by op-run / op-signal <gate> / op-status, which behold already shells for the delegated-write surface. An op has two lives: the declared DAG (phases and their order — synth-side, renderable with zero new chant surface) and the run (phase-by-phase status, gates awaiting signals — event-shaped, temporal).

Lifecycles — lifecycle plan (change-set: create/update/delete/adopt per entity), lifecycle diff --live (declared vs observed, the walkthrough's observe position), lifecycle snapshot (+ deep). behold already consumes lifecyclePlan/summarizePlan for the reconcile pending view and lifecycleDiffLive for the overlay — but as data feeding existing views, not as first-class pictures.

The question this issue answers: are these separate views?

Working hypothesis to test: they are two temporal projections of one estate, and only one of them is a new view.

• Lifecycle is the state axis — diff-shaped, "declared vs live", per-entity verdicts. That is what the drift palette and the reconcile pending panel already speak. Likely an overlay + panel refinement on the existing graph, not a separate view: change-set actions as pending badges, diff verdicts as card status, snapshot age as staleness. The join key is the entity id behold already has.
• Ops are the action axis — run-shaped, ordered phases, gates, signals. That is lanes-shaped (/lanes already renders time as a filmstrip), not graph-shaped. Likely a view of its own: the declared op DAG as a small graph (an op is chant source; behold renders chant source), the run as a playhead over it, gates as the pending cards design: behold as the face of the operating loop — gates, ticks, symptoms, the status join (chant#1487) #234 describes — linking back to the estate nodes each phase touches.

If the hypothesis holds, the answer is: lifecycle = deepen the estate view; ops = one new view (op DAG + run state) that cross-links into it.

What the investigation should produce

1. An inventory of exactly what each CLI surface emits (JSON shapes, what carries entity ids, what doesn't — anything without an IR-joinable id needs an ask into chant now, same lesson as design: behold as the face of the operating loop — gates, ticks, symptoms, the status join (chant#1487) #234's symptom record).
2. A decision on the view split (the hypothesis above, confirmed or corrected), with one mock per surface.
3. The smallest spike worth shipping — candidate: render a declared *.op.ts DAG in the existing graph pane, since it needs no run, no Temporal, no new chant surface.

Relationship to #234

#234 is the far end of this: the operating loop (chant#1487) turns ops+lifecycle into gates-as-facts, ticks, and symptom records. Nothing there starts until chant lands those. This issue is the near-term half — what can be drawn from the surfaces chant ships today — and whatever view split it decides becomes the frame #234's cards and ticks land in.

🤖 Filed by Claude Code from the 2026-08-10 session

https://claude.ai/code/session_01UXwApfRA4Pvoou5Ajj8qHV

[lex00]

Frame sharpened by the ConfigHub post (Brian Grant, cub-eks)

The post builds eksctl's task grammar over versioned config records, with guardrails computed from validated config — disruption flags, blocked upgrade orderings, dry-run by default. Comparing it against this stack:

• cub-eks is thick because it must carry the domain semantics itself. chant's guardrails live in the lexicon — a round-trip spec compiler with semantic linting. Types from the provider's own spec, lint judgments that run at build, audit, AND carve (backwards, over what already exists — the WAW042 catch).
• So the ops view here can be thin: a task grammar over lifecycle plan + Ops + gates that queries compiler-resident judgment instead of owning it. The carve stepper is already the house pattern — step track, structured refusals with remedies, dry-run by default, human gates. "Generalize the carve stepper" is a candidate answer to what the ops view is.
• One concrete ask into chant (filed as a chant issue): per-change disruption classification on lifecycle plan's change-set — in-place / rolling / replace is spec knowledge (CFN replacement-per-property), i.e. one more semantic-lint capability, not tool code. behold's reconcile pending panel then renders how much each change hurts, not just what it is.
• The inventory question ("which JSON shapes carry IR-joinable ids") gains a row: does the change-set carry disruption class, and does the op run surface name the entities each phase touches.

Post: https://confighub.com/blog/building-imperative-operational-tools-on-a-declarative-platform-cec24f8efe05

https://claude.ai/code/session_01UXwApfRA4Pvoou5Ajj8qHV

[lex00]

Investigation findings — inventory, view split, spike

Read across chant @ chant-v0.44.7 (HEAD), the 0.38.0 behold installs, and behold main. The three deliverables in order, then the asks. Line refs: chant: = chant repo packages/core/src unless noted, behold: = this repo.

1. Inventory — what each surface emits, and what joins

Lifecycle surfaces

Surface	Shape	IR-joinable id?
lifecycle plan <env> --live --json	flat ChangeSet {env, entries[]} (chant: lifecycle/change-set.ts:88) — all lexicons merged into one array	declared rows yes (name = IR node id, byte-identical); adopt/delete/runtime rows no — name holds the lexicon's live key (a physical id), and the entry has no physicalId field and no lexicon field (both lost in the merge at chant: cli/handlers/lifecycle.ts:1111)
lifecycle diff <env> --live --json	per-lexicon blocks: resources (LiveDiffResult), observed, unobserved, deep, artifacts	mostly yes; orphan[] is bare physical ids; artifact keys are server-side ids (helm's release/<ns>/<name> — behold already name-matches those)
lifecycle snapshot [--deep]	no stdout JSON — writes LifecycleSnapshot to the chant/lifecycle orphan branch (chant: lifecycle/types.ts:26)	resources keys are three merged key spaces (web, Stack::web, rtb-0abc/us-east-1::sg-0abc) — only the first two join. timestamp is there, so staleness is derivable; there is no age field and no --json on lifecycle log
disruption class	nothing landed (chant#1665 open) — but the spec knowledge already sits compiled in every lexicon manifest: createOnly, conditionalCreateOnly, replacementStrategy (chant: lexicon-schema.ts:72-91, materialized in lexicon-aws.json on hundreds of entries) with zero consumers in lint or lifecycle	—

Two plan-specific gotchas worth their own line:

• queried (#1620) never reaches plan rows except unobserved ones: runLifecyclePlan calls buildChangeSet without passing queried through (chant: cli/handlers/lifecycle.ts:1176-1181), while docs/cli/lifecycle.mdx:116 says plan carries it per-entry. Docs and code diverge; the diff path does pass it (:819).
• plan reads snapshots un-stack-qualified (readSnapshot(env, lexicon), :1173) where diff uses snapshotStorageKey(lexicon, stack) (:801).

Version note: everything above except the #1620 queried family, observedArtifacts, --namespace, and deep-diff owner is already in the 0.38.0 behold declares as its floor. The shapes behold mirrors are stable.

Ops surfaces

Surface	Shape	IR-joinable id?
declared *.op.ts	OpConfig (chant: op/types.ts, whole file, unchanged 0.38.0→HEAD): phases: PhaseDefinition[] — an ordered array, not a DAG; steps are activity | gate; the only explicit edges are op→op depends	no surface names estate entities. Builders pass file paths, stack names, URLs (awsApply("dist/aws.json", {stackName})). In graph IR an op is an isolated node with zero edges
declared, as JSON	no CLI emits it. discoverOps() is exported (@intentius/chant/op, present at 0.38.0) but requires importing the project's TS in-process. chant graph --format ir passes the whole OpConfig through attrs verbatim (chant: graph-ir.ts:419-424) — but only for op files under sourceDir, and the convention keeps them outside it (ops/ vs sourceDir: "src" in this repo's example-writes; getting-started keeps them at project root). discoverOps scans from the git root; graph IR scans sourceDir. Scope mismatch	—
op-status (MCP) / chant run status	{workflowId, runId, status, startTime, closeTime, taskQueue, activitiesCompleted, activitiesScheduled} (chant: cli/mcp/op-tools.ts:102-141) — two counters are the entire progress signal. No per-phase status, no gate state; gate state is unqueryable anywhere (no workflow query handler; a blocked gate is only inferable from RUNNING + a stalled counter)	run history joins by activity fn name only (chant: cli/handlers/run-report.ts:63-76, last-wins on collision)
chant run <name> --json (local)	per-phase records: {phase, fn, status, durationMs, outcome?, error?}[] (chant: op/local-executor.ts:19-34) — the shape a playhead wants, but post-hoc and local mode refuses gates	—

Two corrections to this issue's own text, found on the behold side:

• "behold already shells op-run / op-signal / op-status" — not quite. Those are chant's MCP tool names (AGENTS.md points agents at them). behold shells chant run <name> / chant run signal and holds status in-process (behold: src/op-runner.ts:24 — nothing survives a restart; a run started elsewhere is invisible).
• behold's discoverOps (behold: src/ops.ts:71) regexes name:/signalName:/env:/target: out of op source and never reads phases at all. The declared DAG is entirely unread today.

2. View split — hypothesis confirmed, two corrections

Lifecycle = deepen the estate view: confirmed, and it's further along than the hypothesis assumed. Overlay colours already come from chant graph --live --overlay; the per-entity diff already feeds the inspect pane. The gap is exactly one: plan's per-entity entries are computed and then discarded server-side — summarizePlan reduces them to counts at behold: src/server.ts:1627 and nothing in web/ ever sees a LifecyclePlanEntry. The deepening is letting those entries reach cards over the entity-id join that already works for declared rows: pending-action badge, deltas in the inspect pane, disruption chip when chant#1665 lands, snapshot timestamp as staleness. No new view. No new chant surface for the declared subset.

Ops = one new view: confirmed, with a shape correction. An op's phases are a track, not a graph — the ordered array has no intra-op edges, and the only real DAG is op-level depends. So the view is a small op-DAG (depends edges, a handful of nodes) where the selected op expands into a phase track. And the track is the carve stepper's exact shape: ordered steps, gates as blocked steps with a reason, structured refusals, "the result IS the step". The stepper's pure half (completed / blockedReason / stepStatus, behold: web/carve-steps.js:75-123) maps onto phases and gates without modification in kind. "Generalize the carve stepper" is the right answer for the run side.

Second correction: the playhead can't be driven by chant today. op-status gives two counters with no phase attribution. v1 renders the declared track and overlays behold's own OpRunner state; honest per-phase run progress is an ask (below), not an inference to fake.

Cross-links into the estate: not possible today. No op surface names entities — same lesson as #234's symptom record, and the same remedy: put the id in the record now, before the consumer exists. The coarsest honest join is env/stack/template-path → component.

Mock A — lifecycle deepening (plan entries reach the card)

┌ web  K8s::Apps::Deployment ──────────┐
│ replicas: 2                          │
│ ⟳ update · rolling                   │  ← action badge from the plan entry,
└──────────────────────────────────────┘    disruption chip once chant#1665 lands

dial: reconcile — 4 pending (2 in-place · 1 rolling · 1 replace) · snapshot 6m ago

Mock B — ops view (op-DAG + phase track, stepper grammar)

 depends              aws — declared phases
┌───────┐
│ build ●──▶ aws     [Emulator]→[Build]→[Apply]→[⏸ approve-deploy]→[Verify]→[Teardown]
└───────┘    │           ✓        ✓        ✓      ● waiting (24h)
             ▼
           smoke     blocked: needs aws        ← blockedReason, verbatim stepper pattern

3. Smallest spike — declared *.op.ts DAG in the graph pane

• Data: extend behold: src/ops.ts's existing regex to also capture ordered phase("Name", [steps]) with step builder names and gate(...) markers. The files are builder-call-shaped and behold already regexes them; no chant change, no in-process import of project TS, works wherever behold works today.
• Picture: a pure opsToIr(ops): GraphIR on the carveReportToIr precedent (behold: src/carve-lens.ts:345) — one node per phase, gates as their own card kind, edges in phase order, op→op depends edges, registerPack({lexicon: "temporal", ...}) to pin the card fields. Rendered by the existing renderGraph.
• Landing: an ops stop in ZOOM_OPTS + a query-param branch in /api/graph — the cheapest of the three view mechanisms (lens on the existing pane; the ⌘K entry comes free).
• Later: when chant's graph IR collects ops from the git root (ask 4), the regex parser retires and the same opsToIr rides the sanctioned surface. The view code doesn't change.

No Temporal, no run, no new chant surface — the candidate in the issue body holds up.

4. Asks into chant

1. chant#1665 (disruption class) is wiring, not research — replacementStrategy/createOnly/conditionalCreateOnly are already compiled into every lexicon manifest with zero lint/lifecycle consumers. The change-set classifier can read what the codegen already wrote.
2. plan --json should pass queried through — the docs already claim it does; the handler omits it. Bug-shaped.
3. plan entries need lexicon and physicalId — the flat merge drops lexicon attribution, and plan is the only lifecycle surface that never carries a physical id, which is exactly what its adopt/delete/runtime rows are named by.
4. graph IR should collect *.op.ts from the git root the way discoverOps does — the sourceDir/git-root scope mismatch means real projects' ops never reach the IR.
5. chant run --temporal needs a --progress-json with per-phase records (local --json already defines the shape) and queryable gate state ("which gate is the workflow waiting on") — without these the ops view's playhead and pending-gate card stay behold-local approximations.

2 and 3 are small; 1 is the one #1665 already tracks; 4 and 5 make the ops view honest instead of inferred.

[lex00]

Ask ledger from the findings above, now concrete on the chant side:

• Ask 2 (plan queried pass-through) → chant PR #1670
• Ask 3 (plan entries carry lexicon + physicalId) → chant#1674
• Ask 4 (graph IR collects ops from the git root) → chant#1675
• Ask 5 (run --progress-json + queryable gate state) → chant#1676
• Ask 1 stays chant#1665 (confirmed wiring-not-research by the inventory)

Also cleared while in there, from this repo's trigger queue: chant#1644 (status-less Argo conditions) → chant PR #1671, chant#1643 (sweep key gains the kind) → chant PR #1673. When those two ship in a chant release, behold's argo e2e steps 3 and 5 tighten per the trigger queue.

🤖 Claude Code, 2026-08-10 session

https://claude.ai/code/session_01JD1XEfzQByQEP29dMhJgvz

[lex00]

Every ask in the ledger above has now shipped (chant 0.45–0.52; behold moved to 0.52 today), so this graduates from investigation to a buildable group. Scope, picked out for the next lane:

1. The ops view — spike first, no Temporal needed. chant 0.50's op.json IR (chant#1948: dist/ops/<name>/op.json, every step's args/profile/gate-timeout resolved to effective values) replaces the "regex-extend src/ops.ts" plan from the findings — the declared DAG is already inert JSON. A pure opsToIr + an ops lens stop rendering the phase DAG in the graph pane, gates drawn as marks, each step cross-linked to the estate nodes its activities touch.

2. The playhead. chant 0.51 (chant#1676/#2004): run --temporal --progress-json streams one NDJSON StepRecord per settled step — the same shape the local executor's --json already uses, which behold already parses — and the gateState query (pending gate's signal name, description, since-when) is surfaced on chant run status, which behold already shells. Run state paints over the same DAG; a pending gate renders as the pending card #234 describes, its approve action delegated through the existing op-signal surface. behold never applies.

3. The lifecycle half stays an overlay deepening, per the hypothesis (confirmed). First concrete piece: chant#1665/#2000 per-change disruption classification — disruption on update entries (in-place/rolling/replace/destroy) → pending-badge severity in the reconcile panel and drift palette. Small, rides along.

Riders while in the area: #311 (observe's unhandled {stacks} diff shape) and #240 (palette contrast).

Order: 1 ships alone (static input, fixture-testable), 2 needs a live Temporal run to verify (the delegated-write surface already boots ops), 3 is independent. #234 stays the tracking anchor for what lands beyond the gate cards.

🤖 Claude Code — https://claude.ai/code/session_01Rfs1mLVWmwginHnDTg75sG

[lex00]

Items 1 and 3 of the scope above are built (items merged/queued: #315 ops lens on main; #314 disruption classes green behind the 0.52 upgrade PR; the #311/#240 riders merged in #313). Ledger addition from item 1: ask 6 — op.json steps carry env/stack scope but no IR-joinable entity id, so the lens draws the declared track without estate cross-links rather than inventing joins → chant#2022. A test in src/ops-lens.test.ts pins the current arg-key union verbatim and will fail the day chant adds the id, pointing at the join.

Item 2 (the playhead) is in progress on top of #315.

🤖 Claude Code — https://claude.ai/code/session_01Rfs1mLVWmwginHnDTg75sG