SoL-Pi cannot load, and Action Fusion publishes a parameterless tool, on Pi-compatible hosts with a reduced export surface

[luw2007]

Two independent failures when SoL-Pi is loaded by a Pi-compatible host that is not the official pi binary. I hit both on omp (oh-my-pi) 18.1.19, a Pi fork that re-exports @earendil-works/pi-coding-agent from its own bundle. Both are host-surface assumptions in SoL-Pi rather than host bugs, and both are distinct from #20/#22 (there the fused tool is registered but the model never calls it; here the fused tool is registered and is called).

Environment: omp 18.1.19 (Homebrew, single compiled binary), SoL-Pi 0.1.0 @ d7ecfc0, macOS arm64, Node 24 / Bun. Config: actionFusion: true, observationPack: true, other two false.

1. Install fails: two context APIs are imported as required named bindings

$ omp install git:github.com/NVlabs/SoL-Pi
✘ Failed to install: Plugin sol-pi extension validation failed:
  .../sol-pi/src/sol-pi/index.ts: Failed to load extension:
  Export named 'findCutPoint' not found in module '<host>:@oh-my-pi/pi-coding-agent'.

online-context-compact/extension.ts imports findCutPoint and sessionEntryToContextMessages statically. This host exports everything else SoL-Pi uses (buildSessionContext, estimateTokens, createEdit/Write/BashToolDefinition, getAgentDir, CONFIG_DIR_NAME, pi-tui Container/Text, pi-ai/compat#complete) but not those two — they were reworked out of its public surface.

Impact is larger than the mechanism: the failing import aborts module evaluation, so the package never loads and all four mechanisms are unavailable, even with onlineContextCompact: false. Both symbols are used only inside nativeCompactionFeasible().

Related to #11, but the failure here is a missing export inside an accepted version, not an out-of-range version.

2. Action Fusion publishes a fused tool with no built-in parameters

createActionFusionExtension() rebuilds the fused schema from template.parameters.properties. On Pi that is a TypeBox Type.Object and the read is exact. This host describes tool parameters with its own schema value, where:

• typeof parameters === "function" (the schema is callable, not a plain object),
• parameters.properties is undefined,
• the contract is reachable only via parameters.toJsonSchema() → {"type":"object","properties":{"path":{...},"content":{...}},"required":["path","content"]}.

So {...template.parameters.properties, then_run} collapses to {then_run}, and the published write tool no longer declares path or content. Two observable outcomes, depending on how strictly the host filters arguments against the published schema:

• arguments filtered → resolveToolPath(ctx.cwd, input.path) receives undefined:
  undefined is not an object (evaluating 'filePath.startsWith') — every fused call throws;
• arguments forwarded → the mutation succeeds and then_run is dropped with no marker, the silent shape described in then_run fusion silently does nothing on Pi 0.85.1 (works on pinned 0.84.2) #20.

Verified on the host: before the fix, a write call carrying then_run returned only the plain success text; after the fix the same call returns

[fused.txt#BF2C]
Successfully wrote 5 bytes to fused.txt
[then_run:succeeded]
5 fused.txt

A second, smaller point in the same area: this host's edit tool takes a single multi-file patch string rather than path + edits, so a fused edit has no single target to key the file queue and the pre-command hash check on. Replacing it produces a tool that cannot work regardless of schema handling.

Suggested fix

Both are one-line-of-principle changes that are no-ops on Pi:

1. resolve the two context APIs through the module namespace and fall back locally, so a reduced surface costs a pre-check refinement instead of the whole package;
2. read the built-in properties through a helper that prefers parameters.properties and otherwise rebuilds them from parameters.toJsonSchema() (preserving optionality from required), and skip replacing a mutation tool whose contract has no path.

PR incoming with both, plus a test that covers the rebuild and fails without it. Existing suite stays green (143 tests).

[luw2007]

Two more findings on the same host (omp 18.1.19 / 18.1.20), for completeness:

3. ExtensionContext.getSystemPrompt() returns string[] (one entry per prompt section) instead of a string. tokenEstimate(context.getSystemPrompt()) in online-context-compact throws The "string" argument must be of type string or an instance of Buffer or ArrayBuffer. Received an instance of Array on every before_provider_request once onlineContextCompact is enabled.

4. Online Context Compact cannot complete a plan boundary on that host. It never emits agent_settled; its ExtensionContext.compact() ends the running agent loop by itself (the session is already idle by onComplete); it rejects instead of calling onError when nothing can be compacted (Nothing to compact (session too small)); and it skips session_stop for aborted loops. The abort → agent_settled → compact → continue sequence therefore stops the task at the first plan boundary (stopReason: "aborted", no compaction entry, no continuation). docs/compatibility.md already says a build that never emits agent_settled starts no boundary compaction, so this is the documented behaviour rather than a regression — but with the extension enabled the task is killed rather than left uncompacted.

I have an inline variant on luw2007/SoL-Pi:fix/omp-online-compact (compact from turn_end, resume via sendMessage(..., { triggerTurn: true }) once isIdle(), resume even when the host reports nothing to compact, optional keepRecentTokens config to match the host's retained-tail budget). Verified end to end over --mode rpc on macOS and Linux: boundary → native compaction (24,728 tokens → 963-char summary) → hidden reminder → remaining plan steps → final reply. Not opening it as a PR unless you want host-specific paths upstream; happy to keep it in the fork.