Epic: v1.7 ACP builder and reviewer integration #1114

Goal

Add a maintained Agent Client Protocol (ACP) transport so compatible builders and reviewers can be integrated through a shared client and small agent descriptors. Keep Code Mower's validated delivery/review results, provider identities, contributor exclusion, leases, recovery, and qualification as the controlling contracts.

Part of the v1.7 Operator roadmap #1096. Coordinate with #1085 / PR #1101 before changing shared provider or Operator interfaces. ACP is an optional lane transport and can proceed alongside the Operator foundations after the shared contract is stable. Existing qualified native CLI and hosted API paths remain available.

Four implementation PRs

• v1.7 ACP: shared Python client and capability negotiation #1115 - PR 1: shared Python ACP client and capability negotiation.
• v1.7 ACP: validated results and sanitized Board telemetry #1116 - PR 2: validated results and sanitized Board/usage events.
• v1.7 ACP: Factory Droid and Qwen compatibility pilots #1117 - PR 3: Factory Droid and Qwen builder/reviewer compatibility pilots.
• v1.7 ACP: pinned registry onboarding and doctor checks #1118 - PR 4: pinned registry onboarding and selected-profile doctor checks.

Dependencies and parallelism

• PR 1 establishes the ACP-to-Code-Mower transport interface after alignment with v1.7.0 contract: freeze Operator authority, state, recovery, and privacy #1085.
• PR 2 consumes PR 1 and establishes validated results and privacy-safe events.
• PR 3 requires PRs 1 and 2; Factory Droid and Qwen pilot runs can execute concurrently in separate workspaces.
• PR 4 requires PR 1 for compatibility probes and PR 2 for role/result checks. Registry parsing and documentation can be prepared alongside PR 2, with explicit ownership of CLI/doctor/provider catalog files; final qualification uses PR 3 evidence.
• v1.7.0 providers: qualify Codex and Claude service-mode supervisors #1092 and v1.7.0 Devin: package deterministic CLI and hosted transports #1093 keep their Codex/Claude and Devin scopes. Do not replace their reliable native transports merely because a wrapper exists.
• Add ACP's enabled/disabled posture to v1.7.0 release: qualify the supervised single-tenant Operator #1095 qualification when included in the v1.7 package. Optional agents without credentials produce scoped skip/owner-action states, not fabricated successful qualification.
• Plan exactly four implementation PRs. If a unit grows, narrow it before adding another issue or release dependency.

Integration boundary

Use stable ACP v1 over stdio and the maintained Python SDK. Negotiate capabilities and keep version-specific code isolated; draft v2 and remote ACP transports are deferred.

Product, selected model, adapter version, transport, execution substrate, role, and qualification are distinct. For example: product Factory Droid; transport ACP; execution Docker sandbox; role informational reviewer. Do not collapse every agent into provider=acp or silently reuse another provider's labels/qualification.

The first compatible agents are Factory Droid and Qwen Code. Poolside, Cortex Code, MiniMax Code, and Kimi are follow-on descriptor/qualification candidates using the same client. ACP's listed Muse Spark Code is unofficial and does not establish support in Meta's official Muse CLI; retain the existing Muse transport pending verification.

Acceptance

• One maintained optional ACP transport supports fixture-tested builder and reviewer calls.
• Factory Droid and Qwen produce valid revision-bound results in supervised, bounded pilots; reviewers remain informational.
• ACP end-of-turn is never interpreted as delivery success or a PASS verdict without Code Mower validation.
• Fresh review context, contributor exclusion, exact commit identity, existing gate semantics, and lease/reconciliation rules are preserved.
• Sanitized tool lifecycle/wait/cancel/completion events are useful in Board.
• Unavailable cost/token/model data is explicitly unknown, not zero or inferred from context-window size.
• Registry onboarding locks agent/adapter versions and tested capability profiles; drift prompts compatibility checks.
• Default installs and generated workflows for existing providers continue to pass.
• Canonical provider, install/update, Board, and troubleshooting guidance describes the supported path and limitations.

Privacy and execution

ACP carries messages, reasoning, diffs, paths, tool arguments, and raw output. Keep those out of public status and cloud telemetry. Use allowlisted categories/counts/timestamps and existing accepted metadata shapes. ACP permission callbacks are policy plumbing, not an operating-system sandbox: execution isolation, network access, credentials, and write authority remain controlled by Code Mower and the selected runner.

Live pilot credentials and paid calls require established owner authorization and an explicit campaign-wide cap. No automatic paid retries, automatic registry installation, or automatic promotion is introduced.

References

• ACP introduction
• ACP architecture
• ACP registry
• Python SDK
• Existing research note: docs/acp-bridge-spike.md (replace stale research-only guidance as the implementation lands).

Delivery

One issue per PR and one writer per branch. Prefer diffs of 300 lines or fewer where practical; keep larger protocol/test work tightly scoped and explain it in the PR. Record the named builder, actual agent/model/transport provenance, focused tests, and a canonical documentation update for every behavior change. Obtain an independent eligible Code Mower review against the current commit, resolve all P0/P1/P2 findings, and pass normal CI plus code-mower/gate. Record safe activity in Board and upload only approved metadata through the existing dry-run-first cloud flow. A new transport or passing protocol probe grants no review or merge authority.