pi ACP Adapter

The adapter uses JSON-RPC over stdio and discloses that it spawns a local pi process, reads or writes project files, executes commands, and stores a session mapping at a documented path. Tests also show that tool calls, file locations, and realized post-operation diffs are surfaced to the client. Extension select/confirm requests use one-time allow or reject choices, and release-workflow permissions are narrow. Deductions apply because pi's local filesystem and command capabilities have no adapter-level least-privilege boundary or general per-action confirmation mechanism; handling policies for secrets, logs, prompt content, and model-provider transmission are incomplete; dependencies use ranges and the recommended npx path always fetches the latest release; and there is no automatic rollback for file or command effects. Author, repository, license, and npm provenance configuration provide attribution, but publisher identity remains unverified by the stated enterprise registry.

Component tests cover event ordering, retries, cancellation, prompt queuing, invalid commands, extension-UI fallback, and diffs derived from realized file contents, showing deliberate handling of ordinary interaction paths. Dependencies, a minimum pi version, and the PATH requirement are documented, while unsupported or retry states are generally made visible. Deductions apply for concrete inconsistencies: README requires Node.js 22+ while package.json declares >=20, and README says there is no separate thought stream while a test expects agent_thought_chunk. The supplied material also does not show broader failure messaging for process startup, protocol mismatch, or provider authentication failures.

The audience and primary scenario are clear: using pi through ACP clients, principally Zed, with registry, npx, global, and source installation paths. Capability boundaries are unusually explicit, covering absent filesystem and terminal delegation, stored-but-unwired MCP parameters, unsupported commands, and variable client compatibility, justifying full marks for that criterion. Command syntax, an environment toggle, and invalid-mode handling are demonstrated, but normal-prompt permission triggers and cross-client behavior are not comprehensively specified. Zed-centered development and contradictory Node requirements also reduce environment-fit confidence.

The README is well organized across status, features, prerequisites, installation, configuration, commands, authentication, development, layout, and limitations; installation examples cover multiple deployment paths, so information architecture and install notes are thorough. The limitations are concrete, and MIT metadata agrees with the complete LICENSE, justifying full marks there. Deductions apply because configuration examples alternate between pi and pi-acp server keys, there is no FAQ or systematic troubleshooting section, and release automation plus version 0.0.33 do not substitute for a maintained changelog. An author, issue tracker, repository, and release path identify maintenance channels, but no maintenance policy, support commitment, or team responsibility is stated.

The evidence describes editor-usable output: streamed messages and thoughts, tool status, terminal metadata, file locations, inferred lines, realized before/after diffs, resumable sessions, and cancellation. A dedicated bridge between pi and ACP clients supplies clear marginal value, while two runtime npm dependencies and a no-global-install option keep setup comparatively light; output usability and marginal value are therefore fully supported. Cost-benefit is reduced because the always-latest npx route, separate pi installation, model-service cost, and risks of unrestricted local execution are not quantified or systematically discussed.

Many concrete README claims are corroborated across package metadata, workflows, and component tests, including event translation, diffs, locations, permission requests, retries, queuing, and cancellation. Qualifiers such as MVP, best-effort, and varying compatibility generally separate limitations from firm claims. Deductions apply because the supplied evidence omits the core src implementation and lockfile, preventing complete implementation-level traceability; static test text does not establish that tests were executed; and several documentation claims conflict with tests or package metadata, so corroboration and claim separation are not exhaustive.