Proposal: configurable generic stdio ACP provider driver #8333

T3 Code already has the two hard parts for this use case: a reusable ACP session runtime and a ProviderDriver / provider-instance seam. A downstream that wants to expose another standards-compatible ACP process currently still has to add a first-party driver and a BUILT_IN_DRIVERS registration.

Would you be open to a small, product-neutral generic ACP driver?

Proposed boundary:

• register one built-in acp driver;
• configure each provider instance with a command, arguments, optional working directory, and presentation metadata;
• reuse the existing ACP initialize/session/prompt/resume/cancel, approval, event, and model/config-option mapping;
• allow an optional process-start authentication hook or environment resolver, while keeping credential values out of persisted provider settings, threads, and event logs;
• preserve the existing server-authoritative session lifecycle and provider-instance behavior.

The first slice would remain stdio-only. Remote HTTP/WebSocket transport, marketplace/catalog behavior, product identity, and vendor-specific protocol extensions would stay out of scope.

The observable contract would be: a configured ACP command can create and resume a session, stream the existing canonical updates, handle approval/cancel, and fail as an unavailable provider instance when the process cannot start. No new session UI should be necessary.

If this direction fits the project, I can prepare a focused PR limited to the generic driver/config schema, its built-in registration, and one public-boundary round-trip test. Is there a preferred shape for the optional authentication resolver, or should the first contribution leave authentication entirely to the configured command wrapper?