Skip to content

PR 4: remove deprecated provider packages from workspace #25

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rgarcia merged 2 commits into from
Jun 12, 2026
Merged

PR 4: remove deprecated provider packages from workspace #25

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
7ae2b09
PR 4: remove deprecated provider packages from workspace
rgarcia Jun 12, 2026
bdffee6
PR 4 review fixes: prune lockfile, update docs
rgarcia Jun 12, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 8 additions & 12 deletions .agents/skills/update-docs/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,24 +41,20 @@ For every doc update:
Start with these source-of-truth checks:

- Package topology: `package.json`, `tsconfig.json`, and `packages/*/package.json`.
- Design invariants: provider package roots stay generic, provider `/pi` subpaths isolate `pi-agent-core` bindings, provider packages expose relatively consistent APIs, `@onkernel/cua-translator` owns canonical actions, and `@onkernel/cua-cli` gets provider-specific behavior through translator/provider packages while owning orchestration.
- Translator flow: `packages/cua-translator/src/types.ts`, `translator.ts`, `cua-extras.ts`, `browser-session.ts`, and `computer-use.ts`.
- Provider root surfaces: each provider's `src/index.ts`, `model.ts`, `official.ts`, `batch.ts`, `computer.ts` or `extra.ts`, `cua-extras.ts`, and `system-prompt.ts`.
- Provider `/pi` bindings: each provider's `src/pi/index.ts` plus `*-tool.ts`; for Anthropic also check `payload-hook.ts` and `stream-wrapper.ts`.
- CLI runtime flow: `packages/cua-cli/src/agent.ts`, `cli.ts`, `config.ts`, `skills.ts`, `sessions.ts`, `named-sessions.ts`, `output/jsonl.ts`, `action/`, and `tui/`.
- Supported models and routing: `packages/cua-cli/src/models.ts`, `cli.ts`, provider package READMEs, and the top-level `README.md`.
- Design invariants: `@onkernel/cua-ai` owns provider-specific policy (catalog, tool schemas, payload transforms); `@onkernel/cua-agent` is provider-neutral runtime glue around `pi-agent-core` (no provider names in `packages/agent/src`); every provider difference reaches the agent as data through `CuaRuntimeSpec`; `@onkernel/cua-cli` composes both for orchestration.
- Model layer: `packages/ai/src/index.ts`, `getCuaModel`/`listCuaModels`/`parseCuaModelRef`, `resolveCuaRuntimeSpec`, provider adapters, and `api-keys.ts`.
- Execution layer: `packages/agent/src/index.ts`, `CuaAgent` and `CuaAgentHarness` wiring, and the canonical CUA tool executors against `@onkernel/sdk`.
- CLI runtime flow: `packages/cua-cli/src/cli.ts`, `cli-harness.ts`, `harness.ts`, `harness-browser.ts`, `harness-models.ts`, `harness-sessions.ts`, `harness-named-sessions.ts`, `harness-skills.ts`, `print.ts`, `output/harness-jsonl.ts`, `action/`, and `tui/`.
- TUI test infrastructure: `packages/ptywright/package.json`, `src/index.ts`, `src/session.ts`, `src/terminal.ts`, and `README.md`.
- External drift: provider computer-use docs, provider SDK versions, `@earendil-works/pi-*` versions, and `@onkernel/sdk` versions in package manifests.
- External drift: provider computer-use docs, `@earendil-works/pi-*` versions, and `@onkernel/sdk` versions in package manifests.

Questions `architecture.md` should answer after each update:

- What owns the canonical action vocabulary?
- Which packages are generic provider glue, and which entry points are `pi-agent-core` specific?
- Do provider packages expose consistent root and `/pi` APIs for the CLI to compose?
- What owns the canonical action vocabulary and the model catalog?
- Where is the cua-ai vs cua-agent ownership boundary, and how do provider differences reach the agent without provider conditionals in `packages/agent/src`?
- Where does Kernel SDK browser execution happen?
- What does the CLI compose at runtime?
- What does the CLI compose at runtime via `buildCuaHarness`?
- Which package is dev/test infrastructure only?
- Are root single-invocation flows clearly separate from the CLI's `pi-agent-core` loop?

## Validation

Expand Down
182 changes: 39 additions & 143 deletions README.md
View file
Open in desktop

Large diffs are not rendered by default.

19 changes: 9 additions & 10 deletions docs/DESIGN.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -62,13 +62,12 @@ CUA model refs should be provider-qualified, for example
persisted config, and transcripts unambiguous. The SDK should not export a
default CUA model.

## Follow-up Direction

The current additive packages are intended to become the public SDK surface.
The expected follow-up work is:

- migrate `@onkernel/cua-cli` to consume `@onkernel/cua-ai` and
`@onkernel/cua-agent`
- remove the old provider-specific packages
- remove the old translator package once the new internal translator fully
covers the needed behavior
## Current Surface

`@onkernel/cua-ai`, `@onkernel/cua-agent`, and `@onkernel/cua-cli` are the
public SDK surface. `@onkernel/cua-cli` consumes both `@onkernel/cua-ai` (for
the CUA model catalog and API-key helpers) and `@onkernel/cua-agent` (for the
`CuaAgentHarness` and the re-exported pi-agent-core primitives). The legacy
provider-specific packages and the public translator package have been removed
from the workspace; provider quirks now live inside `@onkernel/cua-ai`'s
internal providers and `@onkernel/cua-agent`'s tool translator.
Loading
Loading