[Feature]: browser trace

[hanxuanliang]

Feature Description

like: https://github.com/browserbase/skills/blob/main/skills/browser-trace/SKILL.md .

Do we need to add a new trace command, or can the full tracing capability be implemented entirely within the skill layer?

Use Case

opencli browser trace start my-run
// 用户/agent 正常 opencli browser 操作
opencli browser trace stop my-run
opencli browser trace bisect my-run

Proposed Solution

No response

Alternatives Considered

No response

[Benjamin-eecs]

The browserbase pattern attaches a second CDP client externally via browse cdp <port> because that skill doesn't own the main automation. OpenCLI's extension already holds a chrome.debugger session and could just expand its subscriptions to cover Network / Console / Runtime / Page, no second client needed. PR #834's capture work is the natural foundation.

Native sketch:

1. opencli browser trace start <run-id>: daemon puts workspace into trace mode. Extension forwards CDP events to daemon. Daemon writes .o11y/<run-id>/cdp/raw.ndjson and runs a snapshot loop calling existing page.screenshot + page.snapshot.
2. opencli browser trace stop <run-id>: finalize manifest.
3. opencli browser trace bisect|query <run-id>: pure post-processing, port browserbase's bisect-cdp.mjs / query.mjs directly.

This avoids needing to expose Chrome's CDP port to external processes (#867 for non-Electron, #988 for multi-instance routing), and composes with workspace + #1235 multi-profile. Tradeoff: core feature touching extension + daemon, not a pure skill.

@hanxuanliang are you scoping this, and which direction were you thinking?

@jackwener which direction fits: external second-client as a skill (needs CDP port exposed externally, #867 for non-Electron + #988 for multi-instance), or extension-as-tracer in core (builds on #834)?