worker: distinguish prompt time targets from enforced inactivity bounds

[sumitake]

Problem and observed evidence

Four retained codegen requests in a 2026-09-22 session omitted the supported top-level deadline_ms. Three included short prose time targets. The installed 7.0.7 client substituted 86,400,000 ms. Terminal aggregates retained approximately 86,398,000 ms after the cleanup reserve.

Request	Prose target	Observed runtime	Outcome
9110d234-2528-40a1-afc4-d986e53e8512	8 minutes	2,228,339 ms	Native execution completed
0cd8f122-e0ac-45b0-b08c-afde0d6384ab	15 minutes	767,752 ms	Caller stopped after prolonged reading; no patch
217a0f42-2d1e-4422-a29c-ac8bd3fad0e7	Expected <=10 minutes	620,719 ms	Caller stopped; no patch
5dddfbce-0379-4414-8636-03578cc9620c	No numeric target found in the inspected request	1,042,991 ms	Caller stopped; two partial files retained

The three stopped requests returned nested execution_status=provider_error, returncode=143, and cleanup_confirmed=true. These are caller-stop observations, not proof of a provider-native timeout or outage. The 15-minute request was stopped before its prose target; do not describe all three as deadline overruns.

Root cause

The caller treated prose as a bounded-work contract without binding a machine-readable inactivity allowance. Current guidance asks for a bounded prompt and says the runtime owns its timeout, but does not make this omission and its 24-hour consequence clear.

Current source, verified at plugin main 8e2437d12ba48f1d4751fa878b8a5d90572cca76:

• runtime_client.py, lines 1144 onward: omitted deadline becomes MAX_TIMEOUT_MS.
• worker source specification: bounded prompt guidance without a concrete execution-bound example.

For admitted-progress actions, deadline_ms is an inactivity lease, not a maximum total duration. Supplying 600000 alone would not guarantee a ten-minute finish while valid structured progress continues. Repeated reading can be legitimate progress even when no patch exists.

Smallest proposed fix

1. Amend the shared invocation guidance and worker example to explicitly choose and send an appropriate supported deadline_ms for a bounded delegation; document the default when omitted.
2. Name the two concepts accurately: expected task duration versus enforced inactivity allowance. Do not advertise a hard total budget that the request does not enforce.
3. Explain the existing caller cancellation path for an intentionally stopped unit, with one owner of cancellation and cleanup. Keep partial output and patch inspection, and record caller cancellation separately from inferred provider failure.
4. Ask the worker to checkpoint a coherent partial change or report a concrete blocker within the requested scope. This is guidance, not a fake runtime guarantee.

Acceptance

• A caller example with a chosen inactivity bound sends that exact field; it does not silently use the 24-hour default.
• A fake provider with no admitted progress expires under the existing lease and cleanup contract.
• A fake provider making admitted progress can exceed the expected duration; the caller output describes this honestly.
• Cancellation retains partial evidence and never implies a completed patch or a provider outage.

Preserve the liveness correction in #187 and the terminal-content separation shipped for #195. Do not add a blanket absolute lifetime cap, second watchdog, service, queue, retries, automatic failover, semantic progress classifier, or a new budget framework. Issue filing does not authorize implementation or release.

Second-task evidence (read-only snapshot, 2026-09-22)

The separately requested task “Install Bitwarden CLI” also omitted deadline_ms in both inspected codegen requests:

• 5cc1b4d9-17cc-4d1a-be1a-25ec8720900a completed after 970,510 ms (about 16 minutes).
• 09a4b304-e457-45ce-99bc-93742f70c043 had no terminal response at the audit snapshot. Native records showed work continuing roughly 25 minutes after start, with writes and tests. This is ongoing work, not a diagnosed hang or failure; the audit did not stop or message it.

These additional requests did not specify a numeric prompt target in the inspected text. They reinforce the implicit default and visibility concern, not a claim that an explicit deadline was violated.

Final observation later in the same audit: request 09a4b304-e457-45ce-99bc-93742f70c043 returned native execution_status=ok after 1,705,591 ms (about 28.4 minutes), with return code 0 and cleanup confirmed. Its earlier empty response was an in-progress state, not a failure. The audit did not interrupt it.

[sumitake]

Fresh recurrence on 2026-09-22 after the first audit: codegen request 9dc2bf94-c380-4878-b3af-f03e1ab9bf2d again supplied “Target 15 minutes” in prose and omitted top-level deadline_ms. The primary observed no source changes in the worker checkout at about 14 minutes and explicitly terminated the exact worker after the target elapsed.

The retained terminal result reports execution_status=provider_error, return code 143, cleanup_confirmed=true, and latency 909,365 ms. This was a caller stop, not evidence of a provider outage or an enforced runtime timeout. The transcript positively checked that the worker and identified child were gone afterward.

The record does not establish a stdin deadlock or explain the underlying lack of a patch; native source-reading activity alone is not a completed deliverable. Keep the proposed distinction between prose target, inactivity bound, and explicit caller cancellation. Do not “fix” this with a blanket absolute timeout that would kill legitimately progressing work. Retain caller cancellation context alongside the existing terminal diagnostics so future audits cannot mistake return code 143 for a provider-origin failure.