Oompa needs to become a full-time daily driver on macOS and support native execution on macOS, Linux and Windows. This is the owner's explicit product target as of 2026-09-11.
The published v0.8.0 artifact is admitted, but that does not establish runtime readiness. Current source still requires protected hosted capacity activation before daemon rollout. Managed Claude operations are admitted only on Linux; an existing personal Claude binding has a distinct macOS path. Native Windows installation and several local-authority backends are absent. Current CI covers macOS and Ubuntu, not Windows.
Delivery must establish:
- Canonical
oompa.app and app.oompa.app operation, current hosted source/configuration, and the required capacity and intended-target proofs. Retire the earlier .dev bindings without redirects after qualification.
- macOS managed Claude isolation and exact pinned-runtime acceptance, preserving the existing personal-binding contract.
- Native Windows installation, private file/credential custody, authenticated local transport, process identity and recovery, and protected terminal I/O.
- Actual native OS validation, including installation/update/recovery and both provider workflows. CI fixtures and a successful build do not substitute for authenticated live qualification.
- Owner-machine acceptance covering session creation/adoption, streaming, approvals, interruption, restart/recovery, attachments, and local/remote continuity. Existing routing and live-usage plans retain their separate outstanding acceptance requirements.
Keep exact writer ownership, durable intent before dispatch, conservative unknown states, no speculative replay, private credential custody, preserved history, and existing hosted capacity/data guards. Do not remove a platform refusal until its replacement implementation and relevant evidence have been independently reviewed. macOS direct-child ownership must not be described as Linux namespace containment.
The first implementation boundary is a credential-free, native controller ownership proof for macOS, with a closed protocol designed to admit Linux and Windows backends. It remains disconnected from provider execution until its native and recovery contracts pass. Windows support requires native evidence; a Linux VM or WSL is not the acceptance target.
Oompa needs to become a full-time daily driver on macOS and support native execution on macOS, Linux and Windows. This is the owner's explicit product target as of 2026-09-11.
The published v0.8.0 artifact is admitted, but that does not establish runtime readiness. Current source still requires protected hosted capacity activation before daemon rollout. Managed Claude operations are admitted only on Linux; an existing personal Claude binding has a distinct macOS path. Native Windows installation and several local-authority backends are absent. Current CI covers macOS and Ubuntu, not Windows.
Delivery must establish:
oompa.appandapp.oompa.appoperation, current hosted source/configuration, and the required capacity and intended-target proofs. Retire the earlier.devbindings without redirects after qualification.Keep exact writer ownership, durable intent before dispatch, conservative unknown states, no speculative replay, private credential custody, preserved history, and existing hosted capacity/data guards. Do not remove a platform refusal until its replacement implementation and relevant evidence have been independently reviewed. macOS direct-child ownership must not be described as Linux namespace containment.
The first implementation boundary is a credential-free, native controller ownership proof for macOS, with a closed protocol designed to admit Linux and Windows backends. It remains disconnected from provider execution until its native and recovery contracts pass. Windows support requires native evidence; a Linux VM or WSL is not the acceptance target.