The handoff prompt a user answers is scraped from prose, because no structured field exists to prefer

[serge-ivo]

What was found

While closing #617, RuntimeTask.handoff_field was removed from the console's type because nothing on either side has ever emitted it. A repo-wide grep (excluding the generated workers/host/src/pages.ts bundle) returned exactly two hits, both in the console:

store/console/src/lib/types.ts:160     handoff_field?: string;
store/console/src/pages/RunDetail.tsx:405  const field = task?.handoff_field || detail.replace(...)... || "your answer";

RunnerTask (packages/browser-runner/src/types.ts:35-55) declares id, type, status, input, title, subtitle, description, output, error, requiresApproval, approval, createdAt, updatedAt, completedAt — no handoff keys — and mirrorRuntimeTask (workers/api/src/routes/instances-runtime.ts:240) stringifies the task whole, so the mirrored payload cannot contain a field the runner did not send.

Why it matters

That || chain is the label on the input box a user is asked to fill during an ask-and-hold handoff. Since the first operand can never win, the prompt has always been either:

• a regex over the handoff message — detail.replace(/^Needs your input\s*[—-]\s*/i, "").split("(")[0].trim(), or
• the literal words "your answer" when that yields nothing.

So the quality of the question depends on the phrasing of a message written for a human to read, and degrades silently to a placeholder. #617 removed the dead operand and left the scrape as the stated implementation, because inventing a producer was out of that issue's scope.

What this issue is for

Decide whether the handoff should carry a structured field:

1. The workflow already KNOWS what it is asking for — request_user_info names the field before the pause. Emitting it onto the task (or the agent.needs_input event's data) is the natural fix.
2. If it should NOT be structured, say so and delete the scrape's ambition: the label becomes "what the agent said it needs", not a field name.

Either way the current state — a fallback chain whose preferred branch is unreachable — should not survive, and #617 has already removed the misleading half.

Verified vs inferred

• Verified: the grep above; RunnerTask's full field list at the cited lines; that mirrorRuntimeTask passes the payload through unmodified; that RunDetail.tsx:405 is the only reader.
• Inferred: that request_user_info is the right place to emit from. Not traced end-to-end — the emitting side was out of scope for Fifteen console types already disagree with the Worker — a date that never renders, a history that is always empty, no error anywhere #617 and has not been read.

Files: store/console/src/pages/RunDetail.tsx, packages/browser-runner/src/types.ts, workers/api/src/lib/apply-loop.ts

[serge-ivo]

Audit — still LIVE. Both console citations have moved; the finding is intact and now stated in the code.

Citation corrections:

• store/console/src/lib/types.ts:160 now reads id?: string;. handoff_field was removed by Fifteen console types already disagree with the Worker — a date that never renders, a history that is always empty, no error anywhere #617 — which the issue body itself says, so this is the expected kind of stale, but a reader chasing the line will land somewhere confusing. The removal is documented at types.ts:208-209, which is where to look now.
• store/console/src/pages/RunDetail.tsx:405 is now the captcha/stuck branch. The scrape is at :407-411, and the code now says outright what this ticket was filed to decide:

	// This opened with `task?.handoff_field ||`, which could never win: nothing in the platform or
	// the runner has ever emitted that field (#617). So what the user is asked for has always come
	// from scraping the handoff MESSAGE, and saying so is the point — the line below is the
	// implementation, not a fallback, until a structured field actually exists to prefer.

Unchanged, re-verified: packages/browser-runner/src/types.ts:35-55 still declares RunnerTask with no handoff keys, and mirrorRuntimeTask still stringifies the task whole. So the label on the input box a user is asked to fill is still a regex over prose, degrading to the literal "your answer".

The decision the issue asks for is untouched: emit a structured field from the point that already knows it (request_user_info), or delete the ambition and label it "what the agent said it needs". Note the issue's own caveat still stands — the emitting side was not traced end-to-end, so whoever picks this up should read request_user_info before assuming it is the right producer.

Leaving open, labels unchanged.

[serge-ivo]

Closed by commit 32b8f57.

What was done: now reads needsInputEv.data?.field and needsInputEv.data?.why as the primary source for the handoff prompt label, with the message-regex scrape kept as a fallback for events from older runners. The structured data was already being emitted by apply-loop.ts:250 (data = { field, why } from decision.needsInput) — the console just wasn't reading it.

Tests added:

• apply-loop.test.ts: verifies the loop emits { field, why } on the agent.needs_input event
• runStatus.test.ts: verifies the console reads needsInputData?.field and needsInputData?.why, and that the message-scrape fallback is still present