Promoting an ACP-speaking vendor CLI to a first-class harness has meant
touching 6+ registration points (capabilities, valid set, module map,
aliases, labels, install spec, readiness, setup steps, a per-harness
spawn-env builder, the live e2e matrix exclusion) plus a near-identical
thin inner module. Recent PRs each re-derived this by hand and one shipped
without its spawn-env builder, silently dropping the session cwd and the
spec sandbox.
Add omnigent/acp_cli_harnesses.py: one AcpCliHarness row per vendor CLI
(label, binary, ACP argv, aliases, install and login metadata). Every
registration derives from the row:
- harness_plugins: validity, module routing (all rows run the shared
omnigent/inner/acp_harness.py wrap), aliases, labels, capabilities
(the generic acp profile), install specs and install keys
- onboarding: one-click install allowlist (npm rows) and vendor-login
setup steps derive; readiness rides the existing install-key gate
- runtime/workflow: one shared _build_acp_cli_spawn_env forwarding the
session cwd and serialized os_env, shell-quoting the resolved binary
- runner dispatch: one membership check covers every current and future
row
- tests: readiness spelling lists and the live-matrix exclusion extend
from the catalog; tests/test_acp_cli_harnesses.py drives a fake row
through the builder and dispatch and asserts full registration per
real row
The catalog ships empty; the first rows land with the Grok Build (#3075)
and Qoder (#3560) PRs, each reduced to one dict entry plus docs.
Co-authored-by: Isaac
Signed-off-by: Dhruv Gupta <dhruv.gupta@databricks.com>
Dhruv Gupta
14eb2a515d