Follow-up to #45 (design discussion there): the case budgets land with fixed per-case values, which is wrong for intentionally long-running cases — but the fix is a frozen-surface change and an escalation-ladder design that only makes sense shipped atomically:
context.progress (WIT contract addition) — a keepalive + progress report for long-running cases. Growth rides the sanctioned channel (new method on the runner-implemented context resource), but the component-model versioning mechanics need a findings-style investigation first: a suite compiled against test-context@0.2.0 does not link against a runner exporting @0.1.0; the additive story likely needs @since gates, and support across wit-bindgen 0.60 / jco 1.26 / wac 0.10 / wasmtime 47 must be pinned empirically before leaning on it. Fan-out: host runner, provider, runner-cli, the jco context.js shim.- Reset semantics:
progress resets --case-timeout only. It must NOT extend --case-execution-budget — a spinning case calling progress() in a tight loop shouldn't buy itself more CPU. (Open question from the discussion: whether a legitimately multi-minute compute case needs a per-case budget override instead; decide when a real case exists.)
--hard-timeout — the absolute wall cap that makes a keepalive safe (without it, a wedge that "progresses" in a loop runs forever). Only meaningful once (1) exists; the name is reserved.- Runner display: progress messages are not diagnostics (different semantics: liveness claim vs debug output); human mode probably wants a live-updating line, JSONL probably wants nothing (or a sparse event — schema decision).
Deliberately not done in #45: the current corpus is compute-bound (execution is its progress signal, served by the execution budget), so nothing in-flight needs this. Also rejected in review: treating diagnostic() activity as an implicit keepalive — chatty-but-stuck defeats it and it muddies the sideband's semantics.
Follow-up to #45 (design discussion there): the case budgets land with fixed per-case values, which is wrong for intentionally long-running cases — but the fix is a frozen-surface change and an escalation-ladder design that only makes sense shipped atomically:
context.progress(WIT contract addition) — a keepalive + progress report for long-running cases. Growth rides the sanctioned channel (new method on the runner-implementedcontextresource), but the component-model versioning mechanics need a findings-style investigation first: a suite compiled againsttest-context@0.2.0does not link against a runner exporting@0.1.0; the additive story likely needs@sincegates, and support across wit-bindgen 0.60 / jco 1.26 / wac 0.10 / wasmtime 47 must be pinned empirically before leaning on it. Fan-out: host runner, provider, runner-cli, the jcocontext.jsshim.progressresets--case-timeoutonly. It must NOT extend--case-execution-budget— a spinning case callingprogress()in a tight loop shouldn't buy itself more CPU. (Open question from the discussion: whether a legitimately multi-minute compute case needs a per-case budget override instead; decide when a real case exists.)--hard-timeout— the absolute wall cap that makes a keepalive safe (without it, a wedge that "progresses" in a loop runs forever). Only meaningful once (1) exists; the name is reserved.Deliberately not done in #45: the current corpus is compute-bound (execution is its progress signal, served by the execution budget), so nothing in-flight needs this. Also rejected in review: treating
diagnostic()activity as an implicit keepalive — chatty-but-stuck defeats it and it muddies the sideband's semantics.