compat(agent): track Pi ACP lifecycle, distribution and native upstream support

Why

Free4Chat now depends on Pi session continuation and bounded cross-session Task execution for an important Remote Task workflow.

The current production distribution is:

pi-acp@0.0.33
https://github.com/svkozak/pi-acp

It is the canonical Pi entry in the ACP Registry, but it is still a community-maintained bridge:

Free4Chat
→ ACP
→ pi-acp
→ pi --mode rpc
→ Pi session/runtime

Production-shaped Free4Chat dogfood exposed a real lifecycle mismatch in 0.0.33: session/load / session/new uses closeAllExcept(), so loading another retained session while one prompt is active can terminate the unrelated Pi worker and leave the original ACP prompt permanently unsettled.

This is tracked and independently verified fixed by:

• https://github.com/svkozak/pi-acp/pull/131
• downstream verification: https://github.com/svkozak/pi-acp/pull/131#issuecomment-5746829435
• Free4Chat #421

Do not solve this by weakening Free4Chat Task semantics.

Current policy

Plan A — canonical Registry package

Preferred near-term path:

svkozak/pi-acp#131 merges
→ official pi-acp release is published
→ certify THAT exact published package
→ pin it in Free4Chat
→ re-run real Task A + Task B continuation/concurrency dogfood

Until then:

• no Free4Chat serialization workaround;
• no lane-policy change;
• no local process-pool rewrite;
• no permanent distribution fork;
• Pi stays at the currently documented capability level, with the upstream blocker stated truthfully.

Plan B — maintained compatible fork, only if release train stalls

A currently active independent fork exists:

https://github.com/regadas/pi-acp

Relevant facts as of 2026-09-20:

• independent fork retaining the original Git history / MIT attribution;
• current ACP SDK generation (@agentclientprotocol/sdk ^1.4.0);
• explicit per-loaded-session Pi subprocess ownership;
• no closeAllExcept single-live-process policy;
• session list/load/resume/close/delete;
• additional lifecycle, cancellation, replay-failure cleanup and async-turn hardening;
• active September 2026 development.

But it is NOT currently the ACP Registry Pi entry and is NOT published as the canonical pi-acp package.

Therefore it is a fallback/reference implementation, not an automatic production replacement.

Trigger for evaluation:

If #131 remains unmerged/unreleased long enough to block a Free4Chat release or real product usage, run the full Free4Chat Harness certification suite against a fixed immutable regadas/pi-acp revision before considering any temporary distribution pin.

Do not switch merely because it has more features.

Long-term preferred path — first-party native Pi ACP

The clean architectural end state is a first-party Pi transport:

Free4Chat
→ ACP
→ pi --mode acp
→ AgentSession / AgentSessionRuntime

rather than:

Free4Chat
→ ACP bridge
→ Pi RPC
→ Pi runtime

Upstream discussion:

https://github.com/earendil-works/pi/discussions/4444

That discussion already contains a concrete proposal for native --mode acp and explicitly identifies structural bridge problems such as:

• dual session identity;
• permission mediation;
• client filesystem / terminal ownership;
• MCP passthrough;
• adapter ↔ Pi RPC version skew.

As of 2026-09-20, there is still no public maintainer decision in that discussion.

Free4Chat now has additional real downstream evidence that strengthens the case: external lifecycle translation has caused an actual retained-session correctness failure in production-shaped use, not merely an IDE convenience gap.

If Pi ships first-party native ACP and it can satisfy Free4Chat's certification invariants, prefer it over an external bridge.

Certification invariants

Any Pi ACP implementation considered for production must be verified with real Pi, not source inspection only:

• existing native Pi session discovery;
• exact session/load continuation with preserved context;
• no silent session/new fallback on load failure;
• two different retained sessions can make progress concurrently if advertised/enabled;
• same native session is always serialized;
• loading/new session B never destroys active session A;
• exact stream routing / no cross-talk;
• cancel A never cancels B;
• child failure settles only the affected session/turn;
• permission requests, if exposed, are session/turn scoped;
• shutdown/delete cleanup is bounded;
• local CPU/RAM/process cost is measured;
• no capability is enabled solely because ACP advertises it.

Relationship to existing issues

• #421 owns Remote Task product acceptance and remains open until the Pi blocker is cleared and integrated production dogfood passes.
• #427 owns Free4Chat's provider-neutral Harness semantic seam.
• This issue owns Pi ACP dependency/distribution strategy and upstream-native tracking.

Close when

Close this issue when one of these becomes the stable production answer and has passed Free4Chat certification:

1. an official svkozak/pi-acp release containing #131 (or equivalent lifecycle semantics), or
2. a first-party Pi native ACP implementation,

and the obsolete fallback branches above can be removed from active tracking.

No repository file or test entry point is named. Start by reviewing the linked pi-acp pull request, Free4Chat issues #421 and #427, and the upstream Pi discussion, then trace the certification invariants and existing production distribution. Done means an official release or first-party native ACP implementation has passed Free4Chat certification and obsolete fallback tracking can be removed.