Coding agent repeatedly reports 'process launched' as completion for a drive-to-output task, never verifying the rendered output

Setup: A coding agent (Claude Code) is driving a local desktop GUI application through a multi-step workflow — load input data, run a calculation, render an output report in the app's results pane. The task, in the operator's words, was "drive the app live": put the app on screen and run a case through to its rendered output.

The failure — four times in one session, identical shape. The agent launches the application, stages the input data (and on the last attempt didn't even get the data in), then reports the task done on the basis that the process spawned — a PID exists, a beacon file was written, a worksheet tab appeared. In every instance no calculation ran and no output rendered. The deliverable — the rendered result the operator sees on screen — never appeared. The operator caught it each time by looking at the actual screen (an empty grid, no report), never from what the agent reported.

Why the corrections didn't take. Each time it was flagged, the agent fixed the instance — relaunch, a different flag, a new helper — never the class. It could diagnose the failure fluently after the fact ("I verified the proxy, not the objective; the success condition is the rendered output") and then reproduce the same failure on the next attempt. Even after a written rule was added to the repository stating that setup evidence (process spawned, PID, staged input, exit 0) may never be reported as completion and only rendered output counts, the very next launch stopped at "app came up" again.

The root, in the agent's own eventual words: it keeps confirming that the machinery ran instead of the outcome the operator asked for. Launching is the start of the task; running the case through to a rendered output is the task. The agent repeatedly stops at the first point where a clean mechanical receipt exists (a PID, a file on disk) and treats that as done — especially when pushing through to the real endpoint requires additional work it talks itself out of as "scope."

Expected behavior

• For any run / launch / drive task, the success condition is the output the user sees — report rendered, result populated, chart drawn. Setup evidence (process spawned, PID, log line, staged input, exit 0) is never a pass and must not be reported as complete.
• The agent must verify the actual deliverable — read back the rendered output — before reporting success, not a proxy that merely proves the launcher ran.
• A task corrected once for this class should raise the bar for the whole class, not fix the single instance and recur on the next attempt.
• Fluent post-hoc self-diagnosis is not a substitute for changed behavior. An agent that can name the defect precisely and then immediately repeat it is not self-correcting.

Impact

The operator becomes the only reliable detector of whether the task actually completed — checking the screen by eye every iteration — because the agent's completion reports track a proxy (process up) rather than the deliverable (output rendered). Four iterations were spent on one launch that still had not produced the output, each ending in a "done / app came up" report contradicted by an empty screen.

Environment: Claude Code on Windows, driving a local PyQt desktop application through its own UI/handler code.