A 10k-char build task is delivered intact, the child works on it for 8 minutes, then the original scrolls out of the window and the obligations reminder flips to "[TASK TRUNCATED — return an error]" — the child obeys, mid-task, and parks the issue (company#210, 06:05Z)

[eumemic]

Observation (company#210 build child sess_6CR07Y14W30FXKYN9BBZYE2PVF, dev-implement, 05:58–06:08Z 2026-09-04; prod at db1ebfa4, which is 49 commits past #2258)

• seq 1: task delivered intact, 10,070 chars, metadata.request.request_id = sha:ba02642d…#0.
• seq 15–596: the child clones, reads CLAUDE.md, greps, runs the test suite, reads lane locks — ~35 tool calls of real implementation work over 8 minutes. The refuse marker never appears in this stretch (abridged pointer renders; original_present=True).
• seq 609: read_window_end event_count_read=51 — the window has slid; seq 1 is no longer in the post-windowing slate.
• seq 614: the model's next output is error(request_id=…, message="Task payload was truncated (10,070 characters exceeded the 8,192-character limit). Per the instruction, I did not act on or infer the missing task.").
• Reconciler: implement_error → needs:human/build on feat(connector): stdio MCP transport + subprocess supervisor (#200, PR2/3) #210 with that text as the "reason" (second time this issue has parked on the identical unactionable message; the first was 08-15, before fix(obligations): abridge oversized task in reminder instead of ordering a refusal (#2221) #2258).

Mechanism (src/aios/harness/obligations.py:148-181, step_context.py:634-665, live master)

_request_content renders the oversized task three ways: verbatim if ≤ 8192; abridged + pointer if original_present; the [TASK TRUNCATED — return an error; do not act on or infer the missing task] marker if not. original_present is request_id ∈ _present_request_ids(events), computed from the post-windowing slate. #2258 fixed the case where the original is in the window. It left the other branch with #2080's refuse instruction — which is correct on step 1 of a session whose request was never persisted, but is false on step N of a session that has been executing the task for eight minutes: the task is not "missing", it is in the child's own prior turns, tool results, and workspace. The marker is the last user-role content the model reads, so it wins.

Net: any task over 8,192 chars is guaranteed to fail once the session runs long enough for the original to scroll out — i.e. exactly the substantial tasks. Shorter tasks never hit the branch. This is why the same issues keep parking on this message weeks after #2258.

Remedy

Once a request has been acted on (the session has produced ≥1 assistant turn after the request), the "original is gone" case should render the same neutral abridged pointer as _reminder_content does — "task abridged in this reminder; you have been working on it since seq N; continue from your own context" — never the refuse instruction. The refuse marker is only correct when the original is absent and nothing in the session has ever seen it (first step, pre-#1413 frame). Concretely: thread acted_on = any assistant turn after the request event (or simply session step_count > 1) alongside original_present; refuse only when not original_present and not acted_on.

Tests: (a) oversized task, original in window → abridged pointer (existing); (b) oversized, original scrolled, ≥1 assistant turn since → neutral pointer, no refuse text; (c) oversized, original absent, zero turns → refuse marker (existing #2080 property preserved). Mutation: drop the acted_on term and (b) must fail.

Cost so far

company#210 parked twice on this (08-15, 09-04); aios#2221's ledger listed ~29–81 issues org-wide parked on the same string before #2258; every one of those with a >8k task will re-park the same way after ~50 events. The reconciler's "resend the complete task within the limit" reason is unactionable by anyone (the task was never too long for delivery).

[eumemic]

Build parked for a human (needs:human/build) [b2170b67]

The dev-pipeline reconciler parked this issue needs:human/build — the build path could not proceed. A human gate needs the reason ON the issue (not only in the workflow run output), so here it is:

the agent was archived or deleted before responding to the request

(This is a hard human gate: the reconciler will not re-pick a needs:human/* item. Address the reason above, then re-dispatch — a fresh refusal re-comments; the same refusal on a crash-replay does not double-post.)