Objective
Deliver the six requested user outcomes in OpenChrome: faster verified tasks, reliable account/authentication reuse, efficient parallel work and memory, no pre-opened empty Chrome requirement, no unsolicited headed interference, and accurate headless observation with controlled human takeover.
Scope decision
Keep the host responsible for goals and LLM strategy. Reuse the existing CLI/MCP runtime and contracts. An optional browser observation client may consume the same authorized API; mandatory desktop apps/extensions and unrelated integrations are outside this implementation. Existing product direction #1359 remains relevant. Coordinate session manifest work with #1578.
Work breakdown
Outcome gates
Integrated acceptance
On Windows, keep another application foreground while four independent authenticated tasks execute. No managed Chrome exists before browser demand, and background policy causes no unsolicited visible window/focus changes. Expire one task's session: only that task/account pauses, the observer identifies its exact target/reason, the user gains exclusive control, and validated account/access permit resumption. Independent work continues. Reconnect one client and retrieve the same status/results. Verify results from fixture server state/downloaded files, then confirm owned-resource reclamation under the declared idle policy.
Evidence and closure
Baseline source: afaf391; published comparison: openchrome-mcp 1.12.9 (npm gitHead 25dd4f8). Pin every candidate by SHA/package integrity. Unit, real-Chrome fixture, external-account and installed-release results are separate. Unknown telemetry or absent test credentials is pending/inconclusive, never success. Record commands, environment, repetitions, sample-validity policy and independent outcome oracles in durable CI/issue-accessible evidence. Do not close this parent on source-only checks or self-reported agent success.
Execution order
F01 first; F02/F03 establish contracts; F04/F05/F07 enable F06; F08/F09 improve bounded execution; F10/F11/F12 validate scaling and multi-client behavior. Start F13 installed-package smoke early and complete it after all dependent gates pass.
Objective
Deliver the six requested user outcomes in OpenChrome: faster verified tasks, reliable account/authentication reuse, efficient parallel work and memory, no pre-opened empty Chrome requirement, no unsolicited headed interference, and accurate headless observation with controlled human takeover.
Scope decision
Keep the host responsible for goals and LLM strategy. Reuse the existing CLI/MCP runtime and contracts. An optional browser observation client may consume the same authorized API; mandatory desktop apps/extensions and unrelated integrations are outside this implementation. Existing product direction #1359 remains relevant. Coordinate session manifest work with #1578.
Work breakdown
Outcome gates
Integrated acceptance
On Windows, keep another application foreground while four independent authenticated tasks execute. No managed Chrome exists before browser demand, and background policy causes no unsolicited visible window/focus changes. Expire one task's session: only that task/account pauses, the observer identifies its exact target/reason, the user gains exclusive control, and validated account/access permit resumption. Independent work continues. Reconnect one client and retrieve the same status/results. Verify results from fixture server state/downloaded files, then confirm owned-resource reclamation under the declared idle policy.
Evidence and closure
Baseline source: afaf391; published comparison: openchrome-mcp 1.12.9 (npm gitHead 25dd4f8). Pin every candidate by SHA/package integrity. Unit, real-Chrome fixture, external-account and installed-release results are separate. Unknown telemetry or absent test credentials is pending/inconclusive, never success. Record commands, environment, repetitions, sample-validity policy and independent outcome oracles in durable CI/issue-accessible evidence. Do not close this parent on source-only checks or self-reported agent success.
Execution order
F01 first; F02/F03 establish contracts; F04/F05/F07 enable F06; F08/F09 improve bounded execution; F10/F11/F12 validate scaling and multi-client behavior. Start F13 installed-package smoke early and complete it after all dependent gates pass.