# Blocked task resumes after its human-owned blocker

`task-dependency-resume` is an explicit Product E2E journey for an authenticated
existing Cloud target or a target provider with a qualified native agent. It uses
the ordinary task UI and public observation APIs. Its registration is not evidence
of a local or deployed pass.

The browser creates two tasks assigned to the signed-in person. The blocker holds
a random review reference absent from the dependent's prompt. On the dependent,
the person adds the blocker, selects Blocked, and assigns the disposable agent.
Closed properties panes are opened through their visible toolbar control; mounted
inert or accessibility-hidden rows cannot substitute for an interactive pane.
Status choices are bound to the matching labeled glyph inside the open picker.
The saved dependency, blocked status, and empty task/agent run histories must
remain observable for at least ten seconds. This is a finite measured wait,
not an unlimited claim that no execution can ever occur.

The person completes the blocker through the task's status control. Paperclip must
then start exactly one native run automatically. Its durable wake must name the
same resolved blocker, reason `issue_blockers_resolved`, and saved source
`issue.blockers_resolved`; `blocker_done` is the producer's separate mutation
payload. Manual
Run or a follow-up message cannot substitute. The run starts after the saved
blocker completion, uses the configured provider/model/environment, commits its
result through the durable committed native phase, and completes the dependent.
The public API may omit or compact `resultJson`; duplicate finalization metadata
in that optional object is not required. A task document named `dependency-proof`
contains the review reference and blocker identifier. Its current revision must
be authored by this agent and run. Reloading the task must show that same saved
revision and preserve the two tasks' descriptions, dependency, and board-owned
blocker completion audit. No agent work is permitted on the human-owned blocker.

The case requires `company`, `board-user`, `task-write`, and `agent`. It declares
one work run, uses the existing bounded case budget, and shares the original
campaign deadline. The native agent must have nonblank provider and model
identifiers before any observation read or task creation. An incomplete execution
identity returns `unsupported` without task or agent work.
It saves the agent's starting run history and retains those
records while checking only newly appearing runs for this case. Earlier terminal
campaign work stays in the accounting and does not count as new execution.
Owned-task activity reads are complete and uncapped; the separate agent-filtered
activity read fails closed if its 500-row bound is reached. The agent run list
likewise fails closed at the public API's 1000-row cap. Unrelated company history
does not enter these completeness checks.
Agent setup usage is outside task-run accounting; missing
provider prices remain unknown. The owning target provider controls normal
cancellation, termination, retained history, and evidence cleanup. It never
changes a shared source agent, company budget, or execution environment.

The private evidence folder contains `task-dependency-observations.json` and
`observation-read-failures.json`, with allowlisted owned task, run, audit, and
document facts. The normal launcher captures the final owned task screenshot.
Both evidence writes are attempted. A write failure retains an existing journey
error and its outcome; a previously successful journey fails if required evidence
cannot be saved. Diagnostics name only the affected evidence file.
Runtime identity, document authorship, reload visibility, and retained history
use their own observations bound to the same company, task, agent, and run. One
failed control does not mark unrelated controls failed. All eight checks remain
required for acceptance.
There are no direct database writes, private runner hooks, manually dispatched
resumption wakes, retry loops for failed model work, or fixture-authored outputs.
Independent controls reject premature or duplicate execution, a never-resumed
or manually started task, foreign/changed runtime identity, missing completion
audit, wrong output or revision authorship, and missing or shortened observations.