[schickling-assistant]

Problem

A program step is agentless with no gates, so the work list gives it gate_kind: watch and missions waiting-on reports it as watching: a running or stuck program never names what it runs and never stalls its run. missions show shows nothing of the step's program.step journal (design §8, R10).

Goal

missions show (text and --json) and missions waiting-on show each program step's inner steps: per key the latest status, timing, failure and the child run or ask it waits on; waiting-on names the innermost open key and reports a program quiet past its stalled-after as no-progress.

Decisions

• One pure fold, fractal_kernel::program_journal::ProgramJournal::fold, over a step's newest entries of the current attempt (newest-first claims page the engine's replay already uses; no new SQL site: claims_for_subject_kind_at and reconcile_fault were moved into _tx functions with their existing large-value markers).
• MissionRunView.programs is filled only on presentation reads (both the run read and the tree), reusing the pinned definition those reads already parse. Views read the newest 200 entries and mark older ones truncated; the text lists the newest 12 keys.
• The innermost open key is the most recently started key without a result.
• Waiting-on still folds nothing at request time: the published work row carries program (innermost open key, its start, its child, last entry, stalled-after) read from the newest 64 entries when the row refolds; every journal entry is a claim on the step, so the row refolds reactively.
• New WaitKind::Program (not a cause); past stalled-after (default 30 minutes, the mission-level default) the step is no-progress, so the run is stalled. A program's ask stays ask, prefixed with its key.
• Client v0 Work gains gate_kind: program and program (schema, README, Rust/Swift templates; generated outputs to be regenerated with cargo run -p fractal-client-codegen).

Verification

On the build host (nix develop -c nice -n 19, own target dir), on an integration of this branch with #6262 and #6297:

• cargo test -p fractal-kernel --lib program_journal: 2 passed (a_journal_shows_each_keys_latest_entry_and_its_innermost_open_key, a_long_error_is_cut).
• cargo test -p fractal-api-core --lib a_program_step_names_its_innermost_open_key: 1 passed. It checks gate_kind: program, kind program with the open key and its child, the reason wording, no-progress and a stalled run past stalled-after, and the missions show projection.
• cargo test -p fractal --lib -- mission_view_shows waiting_on_cli: 5 passed, including the new mission_view_shows_each_program_key_and_the_program_fault.
• cargo run -p fractal-client-codegen (regenerated clients committed) and -- --check: passed.
• python3 scripts/check-sqlite-large-values: passed (the moved subject/kind page read keeps its marker; the three identical sinks keep their IDs in source order).
  Hosted CI at the exact head is the proof.

Complexity

About 600 changed lines including tests, docs and schema.

Concerns

• Two moved SQL statements keep their large-value markers; the guard must confirm the inventory accepts the move.
• An open key older than the newest 64 entries (a very long concurrent section) is not named in waiting-on.

Friction & bottlenecks

Build host memory limit: cold Rust builds are serialized across the program engine slices.

Follow-ups

• Stacked: the run view (client v0 mission detail) PR, and program/stalled / program/host faults once the engine API (M1.1b) lands.

References

docs/st3/program-engine.md §8; stacked on the M1.1a declaration branch.