You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I drive desktop-app UIs through the preview_* MCP tools for automated verification (agent-written UI proofs: drive, assert, screenshot). The existing diagnostics are genuinely good, and this request is additive: preview_snapshot already accumulates consoleEntries (console API, uncaught exceptions, log entries) and networkEntries (>=400 and failed requests) since tab attach. Four gaps keep biting in real sessions:
"Console clean" is the cheapest, highest-value assert an agent can make, but today it costs a full snapshot (screenshot, AX tree, visible text) to read two small arrays. A dedicated preview_logs tool returning just the accumulated console + network + error buffers, with severity/status filters and a since-cursor, would make the assert cheap enough to run after every action. It would also reduce pressure on the snapshot-size problem in [Bug]: preview_snapshot can exhaust agent context with unbounded metadata #7410, since callers polling for logs would no longer need full snapshots.
Why it matters: screenshots mislead at small scale. In one session a ~2px visual marker was invisible in a full-frame capture and led to a wrong conclusion that a DOM state read disproved in seconds, while a console listener caught a quiet 404 that both the screenshot and the state assert missed. The lesson we took: assert behavior from logs and state, screenshot only the visual question. The logs half of that needs to be cheap.
Successful requests are invisible. networkEntries capture only status >= 400 and loadingFailed, so an agent can prove "nothing failed" but not "the model/texture/font actually loaded from the URL I expect". Positive load assertions need 2xx visibility. The implementation already tracks successful requests internally to correlate request/response and discards them on loadingFinished, so this looks like keeping (url, status, mimeType, timing) instead of dropping it, ideally behind a flag. Response bodies could stay opt-in via Network.getResponseBody with a hard size cap.
Why it matters: a missing asset often degrades to a fallback that looks deliberate in a screenshot. The absence of a failure is not the presence of the right success.
Exceptions arrive without stacks. Runtime.exceptionThrown is flattened to its text; the stack trace is what turns "something threw" into a fixable finding without a manual repro session.
Buffer eviction is invisible. The 200-entry bounded ring is the right idea, but when entry 201 evicts entry 1 the caller cannot distinguish "console was clean" from "the errors scrolled out". A droppedCount (and ideally a configurable cap) would make a clean read trustworthy on long drives. Same for the buffers being cleared on debugger detach: a cursor or attach-timestamp in the response would let callers state what window their evidence covers.
Why upstream rather than a local patch: the server source inside app.asar is perfectly readable and the capture code is close to all of this already, but a local patch is wiped silently by both the in-app updater and package refreshes, so out-of-tree maintenance isn't realistic. Happy to test builds.
Environment: t3code-bin 0.0.33 (Arch, packaged from the AppImage), server entry apps/server/dist/bin.mjs.
I drive desktop-app UIs through the preview_* MCP tools for automated verification (agent-written UI proofs: drive, assert, screenshot). The existing diagnostics are genuinely good, and this request is additive: preview_snapshot already accumulates consoleEntries (console API, uncaught exceptions, log entries) and networkEntries (>=400 and failed requests) since tab attach. Four gaps keep biting in real sessions:
Why it matters: screenshots mislead at small scale. In one session a ~2px visual marker was invisible in a full-frame capture and led to a wrong conclusion that a DOM state read disproved in seconds, while a console listener caught a quiet 404 that both the screenshot and the state assert missed. The lesson we took: assert behavior from logs and state, screenshot only the visual question. The logs half of that needs to be cheap.
Why it matters: a missing asset often degrades to a fallback that looks deliberate in a screenshot. The absence of a failure is not the presence of the right success.
Exceptions arrive without stacks. Runtime.exceptionThrown is flattened to its text; the stack trace is what turns "something threw" into a fixable finding without a manual repro session.
Buffer eviction is invisible. The 200-entry bounded ring is the right idea, but when entry 201 evicts entry 1 the caller cannot distinguish "console was clean" from "the errors scrolled out". A droppedCount (and ideally a configurable cap) would make a clean read trustworthy on long drives. Same for the buffers being cleared on debugger detach: a cursor or attach-timestamp in the response would let callers state what window their evidence covers.
Why upstream rather than a local patch: the server source inside app.asar is perfectly readable and the capture code is close to all of this already, but a local patch is wiped silently by both the in-app updater and package refreshes, so out-of-tree maintenance isn't realistic. Happy to test builds.
Environment: t3code-bin 0.0.33 (Arch, packaged from the AppImage), server entry apps/server/dist/bin.mjs.