Drop the pi-agent-core re-export from @onkernel/loop/pi

[rgarcia]

What changed

packages/loop/src/pi/index.ts re-exported all of @earendil-works/pi-agent-core plus NodeExecutionEnv from its /node entry — about 80 of the ~113 symbols on ./pi were pi's, not loop's (Agent, AgentHarness, InMemorySessionRepo, createBashTool/createReadTool/createEditTool/createWriteTool, session/skill/prompt-template/compaction primitives). That made loop look like a wrapper around pi and silently pinned consumers to the pi version loop resolved. This removes the re-export: pi is imported from pi.

New ./pi surface

Only loop-owned symbols remain: attach() and its types, model resolution (getLoopModel, listLoopModels, parseLoopModelRef, quirks/capabilities/native-surface tables), provider adapters and streaming helpers (createLoopModels, loopModels, GOOGLE_INTERACTIONS_API, OPENAI_COMPUTER_USE_API, stream functions), response-threading helpers, LoopRetryOptions, and the api-key helpers. Type references to pi types in loop-owned signatures are unchanged. A new test (test/pi-export-surface.test.ts) pins the surface by asserting Agent/AgentHarness/InMemorySessionRepo/NodeExecutionEnv/create*Tool are not exported.

Peer dependency

@earendil-works/pi-agent-core@0.83.0 is now declared as a peer dependency in addition to the regular dependency. The regular dep keeps internal resolution working (attach/compile/tool-manager consume it); the peer gives consumers constructing Agent/AgentHarness themselves an npm version-compatibility signal. npm install in the workspace resolves cleanly with both declared.

Docs and internal consumers

• packages/loop/README.md: install line is now npm install @onkernel/loop @onkernel/sdk @earendil-works/pi-agent-core; every example imports Agent/AgentHarness/InMemorySessionRepo/NodeExecutionEnv/tool factories from pi-agent-core directly; the "re-exports pi-agent-core's ... primitives" paragraph now states the opposite.
• Root README.md: the agent example imports Agent from pi-agent-core.
• Examples and tests that imported pi symbols through ./pi now import from @earendil-works/pi-agent-core (and /node). The published-declarations downstream-consumer fixture models the same composition; it needed one explicit paths entry for the /node subpath because the fixture's "*" fallback resolves package roots but not subpath exports.
• The pi extension already imported only createLoopModels from ./pi — unchanged.
• Release workflow and package.json files/exports need no change; nothing there referenced the re-export.

Testing

• npm run typecheck clean (loop and root).
• Full unit suite: 34 files / 428 tests passed (426 at main + the 2 new export-surface tests), including the packed-declarations consumer compile with skipLibCheck: false.
• Verified against the built dist/pi/index.js: 30 runtime exports, all loop-owned.

---

Note

Medium Risk
Breaking change for anyone importing Agent/AgentHarness from @onkernel/loop/pi; migration is straightforward but required on upgrade.

Overview
@onkernel/loop/pi no longer re-exports @earendil-works/pi-agent-core (including NodeExecutionEnv from /node). The entrypoint now exposes only loop-owned bindings—attach, model/catalog helpers, provider streaming, API keys, and related types.

Consumers must install @earendil-works/pi-agent-core@0.83.0 and import Agent, AgentHarness, session/tool factories, and NodeExecutionEnv from that package directly. @earendil-works/pi-agent-core is added as a peer dependency (alongside the existing regular dependency) so npm surfaces version alignment for apps that construct agents themselves.

Docs, examples, tests, and the published-declarations consumer fixture follow the new import pattern. test/pi-export-surface.test.ts and the release ESM smoke test assert that symbols like Agent and NodeExecutionEnv are not present on @onkernel/loop/pi.

^{Reviewed by Cursor Bugbot for commit e1eecd6. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Release smoke still imports NodeExecutionEnv
  • Updated the release smoke test to stop importing and asserting NodeExecutionEnv from @onkernel/loop/pi, matching the current export surface.

Or push these changes by commenting:

@cursor push fa93020cdc

Preview (fa93020cdc)

diff --git a/.github/workflows/release-loop.yml b/.github/workflows/release-loop.yml
--- a/.github/workflows/release-loop.yml
+++ b/.github/workflows/release-loop.yml
@@ -74,9 +74,9 @@
           npm install "$RUNNER_TEMP"/onkernel-loop-*.tgz
           cat > smoke.mjs <<'NODE'
           import { compileLoopToolCatalog, formatBrowserActResult, loop } from "@onkernel/loop";
-          import { attach, getLoopModel, NodeExecutionEnv } from "@onkernel/loop/pi";
+          import { attach, getLoopModel } from "@onkernel/loop/pi";
 
-          for (const [name, value] of Object.entries({ compileLoopToolCatalog, formatBrowserActResult, attach, getLoopModel, NodeExecutionEnv })) {
+          for (const [name, value] of Object.entries({ compileLoopToolCatalog, formatBrowserActResult, attach, getLoopModel })) {
             if (typeof value !== "function") {
               throw new Error(`expected ${name} to be a function, got ${typeof value}`);
             }

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit cc2fd53. Configure here.}