feat(page): print the eval-js value bare and use exception_detail for failures

[giordano-lucas]

Two changes to notte page, both about surfacing what actually happened.

1. eval-js output

Before, a successful eval printed two lines:

Successfully executed action: evaluate_js
Result:  Hacker News

so the value could not be piped without post-processing — and when the evaluated value was legitimately empty the Result: line was skipped entirely (it was gated on Markdown != ""), leaving only a success banner.

Now the value prints alone on stdout and the status line goes to stderr:

title=$(notte page eval-js "document.title")
notte page eval-js "JSON.stringify([...document.links].map(a => a.href))" | jq length

Interactive use is unchanged (stderr still shows in the terminal), and -o json still prints the full execution result. Help text documents the contract.

2. exception_detail across every page command

The API serializes a failure twice: exception is a bare string rendered in whatever ErrorConfig mode the server ran in — and the API runs set_error_mode("user"), so it is usually the generic "Sorry, this action cannot be executed at the moment." — while exception_detail (nottelabs/notte#907, already in the generated client) carries the concrete error type, the per-audience messages and the retry/notify flags.

A new shared executionFailureError helper prefers the structured field, so a failed action now reports e.g.

ActionExecutionError: Failed to execute action: evaluate_js on https://x. Reason: ReferenceError: foo is not defined

instead of the generic sentence. It falls back to the legacy exception string, then message, for API builds that predate the field. Wired into both failure sites: printExecuteResponse (used by click, fill, goto, scroll, press, wait, … — every page action) and eval-js.

Tests

internal/cmd/execution_failure_test.go: prefers structured detail over the generic string, falls back to user_message when dev_message is absent, legacy-string path, message-only path, and the nothing-to-go-on path. Full go test ./internal/... and go vet ./... pass.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

The PR makes page eval-js emit only its evaluated value on stdout while moving status text to stderr, and centralizes failed page-action formatting around exception_detail.

• Adds structured execution-failure fallback handling and focused unit coverage.
• Applies the helper to generic page actions and eval-js.
• Documents the new pipeline-oriented eval-js output contract.

Confidence Score: 4/5

The developer-message path should be sanitized before merging because failed page actions can otherwise print unbounded or control-bearing service text directly to the terminal.

The new action-level error helper bypasses the existing message sanitizer and is now reachable from both generic page actions and eval-js failures.

Files Needing Attention: internal/cmd/output_helpers.go, internal/cmd/page.go

Important Files Changed

Filename	Overview
internal/cmd/output_helpers.go	Adds shared structured failure formatting, but forwards DevMessage without the sanitization used by the established API error path.
internal/cmd/page.go	Routes page failures through the new helper and separates eval-js result and status streams.
internal/cmd/execution_failure_test.go	Covers structured-detail preference and fallback ordering, though it does not exercise output sanitization.

Prompt To Fix All With AI

### Issue 1
internal/cmd/output_helpers.go:240-254
**Developer errors bypass sanitization**

If `DevMessage` contains control characters or excessive text, `executionFailureError` forwards it as an ordinary error without the sanitization applied by the API error path, causing failed page actions to emit raw terminal sequences or unbounded output on stderr.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "feat(page): print the eval-js value bare..." | Re-trigger Greptile}