Resume host inference from terminal Job events with bounded continuation

[yyjeqhc]

Dependency

Build this after the detached execution ownership substrate in #88 is proven. #88 intentionally excludes web/model callbacks; this issue consumes durable terminal Job state rather than changing Job execution semantics.

Problem

Long-running work can outlive the initiating MCP request or model turn. Today the safe continuation path is explicit Job observation/reconciliation. Once detached Jobs can survive Runner restart, the next step is to let a supported host resume reasoning when a specific logical Job reaches a terminal state, without requiring the original model turn to poll indefinitely.

The continuation mechanism must not become a generic callback/plugin framework and must never become authoritative for Job outcome.

Core invariants

• Job/Execution terminal state remains authoritative effect truth. A continuation may consume it but cannot change it.
• Delivery is deduplicated and idempotency-safe. Duplicate terminal events, reconnects, or lost responses must not trigger duplicate reasoning blindly.
• A failed or unavailable model/host continuation does not change a completed Job into failed/unknown.
• Continuation input is bounded and evidence-oriented; do not inject full transcripts, unbounded logs, secrets, or arbitrary process state.
• No blind retry after an indeterminate host response. Reconcile the continuation record first.

Direction

Introduce a narrow durable continuation intent bound to an existing logical Job and conversation/session identity.

Conceptually:

model turn
  -> starts/observes Job
  -> registers one bounded terminal continuation intent
  -> returns

Job
  -> running
  -> Runner may disconnect/restart
  -> reconciles
  -> terminal state committed

continuation dispatcher
  -> observes terminal Job event
  -> claims exact continuation intent once
  -> builds bounded terminal evidence
  -> invokes a supported host continuation adapter
  -> records delivered / failed / indeterminate state

Do not let arbitrary tools register arbitrary callbacks. The first contract should be specifically: resume reasoning when this exact Job becomes terminal.

Durable continuation record

Persist only what is required to reconcile delivery, for example:

• continuation id;
• exact job_id / execution identity;
• owner/caller/session/conversation binding needed by the host adapter;
• created/claimed/delivered timestamps;
• terminal event/version used to trigger it;
• bounded delivery state and attempt metadata;
• host adapter kind/capability revision if needed.

Do not persist raw credentials or entire model prompts/transcripts merely to support continuation.

Bounded resume context

The resumed inference should receive a compact envelope such as:

• Job identity and terminal state;
• duration and truncation facts;
• bounded stdout/stderr tail only when appropriate;
• structured validation/evidence references when available;
• Artifact/ResourceLink references instead of inlining large payloads;
• explicit uncertainty/recovery information for lost or outcome_unknown states.

Delivery semantics

Define explicit states such as pending, claimed, delivered, failed, and delivery_unknown rather than conflating transport failure with model failure.

A duplicate terminal event must converge on the same continuation record. A dispatcher restart must recover pending/claimed work without producing an unbounded retry loop.

If the host cannot resume the conversation, retain terminal Job truth and expose a bounded observable continuation failure for later manual recovery.

MCP Apps integration

The generalized card work should be able to display the same Job while continuation is pending/delivered, but cards are presentation only. Card rendering or user viewing a card must not be required for delivery.

Acceptance criteria

• One long-running Job can outlive its initiating request and trigger exactly one logical continuation after terminal completion.
• Duplicate/replayed terminal Job events do not create duplicate continuation intents or duplicate model turns.
• Server/dispatcher restart between Job completion and delivery preserves the same continuation identity.
• Host invocation failure leaves Job terminal state unchanged and is separately observable.
• Indeterminate host delivery is represented explicitly and is not blindly retried.
• Resume context is bounded and excludes secrets/unbounded logs/full transcripts.
• A terminal Job recovered after Runner restart can still trigger the same continuation.
• Unsupported hosts degrade to ordinary manual Job observation without changing Job behavior.

Non-goals

• arbitrary webhooks;
• generic Hooks/plugin/callback framework;
• scheduling unrelated future prompts;
• automatic multi-agent orchestration;
• allowing model continuation to decide whether the underlying Job succeeded;
• machine-reboot survival beyond whatever Add detached Job ownership handoff for Runner-restart survival #88/the Job substrate guarantees.