Adoptability assessment — install-vs-adapt-vs-pattern over the surveyed tools (ID-92 research input)

Adoptability assessment — kunchenguid tooling family

• Task: ID-92 — Workflow efficiency hardening
• Subtask: {92.1} RESEARCH supporting input (companion to external-repo-survey.md + RESEARCH.md, same dir)
• Authored: 08/06/2026 — four parallel adoptability agents over the local clones (/private/tmp/claude-501/<repo>) + WebFetch of live upstream openclaw/acpx + direct read of KH worktree config; treehouse synthesised by the orchestrator.
• Why this doc exists. The original survey framed every repo as “workflow ideas worth stealing” — a mechanism lens. The product-owner correction: the bias should be toward using a battle-tested third-party tool over rebuilding it, even at the cost of stripping our own workflow complexity. This doc re-reads each tool through an explicit adoptability lens and answers a question the survey did not: can we just install and use this?

The three tiers

• (i) ADOPT AS-IS — install the packaged tool and use it with at most trivial config. Slots into our workflow without rebuilding anything.
• (ii) ADOPT WITH PROCESS TWEAKS — the packaged tool is usable, but adoption requires changes to our process/config/wiring (a config file, a rewired skill, a hook, an install step). The tweaks are named precisely.
• (iii) PATTERN ONLY — the tool cannot be adopted (wrong runtime model, requires being the orchestrator/shell/daemon, redundant with an existing KH tool, or too immature) — only the mechanism is borrowable. The structural blocker is named.

Adoption-bias rule applied throughout: tier (iii) is assigned ONLY on a genuine structural blocker, never to protect the existing workflow. Where a tool duplicates something we built, the default question is “should we strip ours and adopt theirs?”, not “how do we keep ours?”.

Headline: nothing is pure (i); two tools are light (ii) and worth banking; the survey under-weighted them

No surveyed tool is pure tier (i) — each needs at least a one-line convention or config change to make agents actually use it. But the gap between “light (ii)” and “pattern (iii)” is decision-relevant, and the survey collapsed it. The two lightest, highest-value adopts — gh-axi and chrome-devtools-axi — were treated by the survey purely as pattern sources. They are install-and-repoint-a-skill, and both won benchmarks against the exact raw-tool path KH uses today.

Summary table

Tool	Tier	One-line verdict	Adopt cost	Strips / de-dups
gh-axi	(ii)	Drop-in gh wrapper; install + repoint GitHub-touching skills	Low	ad-hoc gh … --json | jq munging + bespoke gh-error prose
chrome-devtools-axi	(ii)	Faster driver over the same chrome-devtools-mcp KH already uses; repoint the browser skill	Low	multi-call raw-MCP nav→snapshot→click choreography
axi — bench harness	(ii)	Vendor + reconfig as a controlled A/B instrument we lack	Medium	nothing (adds interventional testing the retro lanes can’t do)
treehouse	(ii) cmux path / (iii) harness path	Largely redundant with our worktree.symlinkDirectories; real gap is build-cache + cmux/manual paths	Medium	manual “check git status before removing” gotcha; .next rebuild tax
no-mistakes	(ii)	Battle-tested local pre-PR gate, but only for the human-PR path, scoped to avoid colliding with our checker/CI	High (daemon+SQLite+bare-repo)	manual chained code-review→commit-push-pr→diagnose-ci ritual (human path only)
acpx	(ii) narrow / (iii) if no need	Adopt ONLY for heterogeneous-agent dispatch (drive codex/gemini/cursor); alpha — pin + wrapper	Medium, risky	nothing today; net-new capability
axi — SDK (axi-sdk-js)	(iii)	Build-your-own-CLI framework; no KH CLI to build with it now	—	—
lavish-axi	(iii)	Redundant with Plannotator (its README calls itself “a cousin of Plannotator”)	—	—
gsh	(iii)	Must BE the interactive shell; the Claude Code harness already owns that role; early-stage	—	—
acp-mock	(iii)	KH dispatch is not ACP-based; nothing for the double to stand in front of	—	—

---

Tier (ii) — the real adopt candidates

gh-axi — ADOPT (light)

• Install: npm gh-axi@0.1.19 (public), npm install -g gh-axi → gh-axi bin. Prereqs Node ≥20 (KH on Node 26 ✓) + authed gh (KH has gh 2.73 ✓). One thin dep tree (@toon-format/toon + axi-sdk-js). Shells out to system gh via execFile — a wrapper, not a reimplementation. No daemon.
• Why adopt: the survey’s winning benchmark condition (100% success @ $0.050 vs raw gh 86%). KH agents call gh directly today; gh-axi is a strict improvement layer (TOON output, minimal schemas, pre-computed CI aggregates like checks: 3/3 passed, error translation with remediation, -R owner/repo auto-detect from git so worktree sub-agents resolve the repo for free).
• Tweaks required:
  1. npm install -g gh-axi on dev machines + the CI image used by agent lanes (pin the version — young, single-maintainer).
  2. One CLAUDE.md directive: “Use gh-axi for GitHub operations; fall back to raw gh only for subcommands it doesn’t wrap (api is the escape hatch).”
  3. Repoint GitHub-touching skills: diagnose-ci-failures, gitnexus-pr-review/plannotator-review, commit-commands:commit-push-pr. Audit each against gh-axi’s command table.
  4. Do NOT run gh-axi setup hooks — it writes a SessionStart hook into ~/.claude/settings.json, bypassing our settings governance. Route any ambient-context want through update-config instead.
• Strips: scattered gh … --json <fields> | jq munging and bespoke gh-error-handling prose across skills/CLAUDE.md.
• Caveat: re-validate cost/success on a KH task sample (benchmark was Sonnet 4.6 on openclaw tasks) — the bench harness below is the instrument.

chrome-devtools-axi — ADOPT (light)

• Install: npm chrome-devtools-axi (public). Zero-install via npx -y chrome-devtools-axi <cmd> or npm i -g. It spawns chrome-devtools-mcp@latest itself. Node ≥20.
• Runtime: a persistent detached HTTP bridge daemon on 127.0.0.1:9224 (PID in ~/.chrome-devtools-axi/), keeping one chrome-devtools-mcp child + headless Chrome warm across CLI calls. That persistence is the point (no Chrome cold-start per command).
• Why adopt: KH’s browser-testing-with-devtools skill drives the raw chrome-devtools-mcp — which is precisely the survey’s losing benchmark condition (6–7.6 turns). chrome-devtools-axi won at 100% @ $0.074, 4.5 turns: TOON output, generation-stamped @gN: refs that fail loud with STALE_REF (vs silent no-ops), combined nav+snapshot+suggest ops, truncation with --full, and a run stdin script-batching mode.
• Tweaks required:
  1. npm i -g chrome-devtools-mcp on dev/cmux hosts so the bridge spawns node <path> (~1–2s) instead of a 30s+ npx bootstrap that can race readiness.
  2. Amend browser-testing-with-devtools (via update-skill) to default agents to chrome-devtools-axi, reserving raw MCP for gaps. Skip setup hooks (same settings-governance reason as gh-axi).
  3. Sandbox note (B2-relevant): the bridge binds a localhost port + spawns a detached child — same class as the documented next build sandbox failure, so its launch Bash command will likely need dangerouslyDisableSandbox: true. If parallelised across worktrees, gate with per-worktree CHROME_DEVTOOLS_AXI_PORT.
• Redundancy: NOT redundant — it is a faster driver over the same MCP we already have; our current skill uses the slow path. Orthogonal to Playwright (deterministic E2E specs).
• Caveat: pins chrome-devtools-mcp@latest — pin via CHROME_DEVTOOLS_AXI_MCP_PATH to avoid upstream drift; treat returned page content as untrusted (no injection guards).

axi bench harness (bench-github / bench-browser) — ADOPT as an instrument (medium)

• Distribution: NOT published — lives inside the axi meta-repo (axi-bench@0.1.0, run via tsx src/cli.ts). Light deps (yaml + tsx). Needs claude and/or codex CLI on PATH (KH has claude).
• What it is: a conditions-matrix (CLAUDE.md variants) × tasks × repeats × LLM-judge × JSONL-token-accounting A/B harness. Runs controlled interventional experiments — the epistemics our evaluate-workflow/evaluate-findings retro lanes lack (those analyse already-archived corpora, observational/post-hoc).
• Why adopt: this is the rigorous instrument to A/B a guard/skill change before standardising it (the survey’s own doctrine #7). It directly answers OQ-3/OQ-4 and lets us validate gh-axi-vs-raw-gh on KH-shaped tasks.
• Tweaks required: vendor bench-github/ into scripts/bench/; replace the hardcoded REPO_URL (openclaw); rewrite config/tasks.yaml + config/conditions.yaml for KH; confirm judge model IDs; widen --setting-sources/--allowedTools in runner.ts if testing KH-with-skills (default runs a bare agent, bypassing the harness).
• Scope note: this is the RESEARCH §6 candidate #8 (“conditions-matrix bench harness”) — previously routed to backlog. The adoptability pass upgrades its standing: it is the empirical backbone for the whole “measure before standardising” position. Recommend promoting from backlog-candidate to a tracked instrument.

no-mistakes — ADOPT only on the human-PR path (high cost, scoped)

• Install: single Go binary (curl|sh, go install, make). Per-repo no-mistakes init.
• Footprint KH would own: a launchd/systemd daemon, Unix-socket IPC, a SQLite DB, a per-repo bare git repo with a post-receive hook, disposable per-run worktrees, baked-in (opt-out) telemetry. Not “trivial config.”
• The collision (decisive): its 9-step pipeline overlaps KH machinery hard — review ≈ code-review/security-review; test ≈ Stop-hook Vitest + CI’s 4-shard matrix; ci polls + auto-fixes GitHub Actions, directly overlapping our PR-blocking ci.yml + diagnose-ci-failures; pr/push ≈ commit-commands. Run whole over the agent pipeline → double-spend (two reviews, two test runs, two CI babysitters) + authority ambiguity with task-checker.
• Where it IS a clean adopt: the human contributor pre-PR path, where KH has only the Stop-hook + manual skills. git push no-mistakes collapses review+test+document+clean-PR into one gated push. Scope it: commands.lint: bun lint, commands.test: bun run test, --skip=ci (let our ci.yml remain authoritative). The lavish-axi/acp-mock repos use it exactly this way as their own contributor gate.
• Hard limit: the step order is non-configurable — you adapt by skipping, not extending. A KH-specific gate (supabase migration-safety, taxonomy-sync) cannot be inserted as a pipeline step.
• Recommendation: PRODUCT-level decision, not a quick win. Real but heavy; the daemon+bare-repo is standing infra we’d own.

acpx — ADOPT narrowly, for heterogeneous-agent dispatch only (alpha-gated)

• Live state (WebFetch openclaw/acpx): acpx@0.9.0 on npm (the local clone is a stale 0.6.1 fork). Self-declared ALPHA, verbatim: “the CLI/runtime interfaces are likely to change… anything you build downstream might break until it stabilizes.” Node ≥22.12.
• The overlap (decisive): acpx is itself a dispatch/orchestration layer that overlaps what KH already operates. Its flows runtime’s core thesis — “the worker is not the workflow engine” — is exactly our existing SDLC-lane philosophy (Planner/Executor/Checker/Curator invariants, deterministic gates, cmux session-driver, the Workflow tool). Re-platforming our mature, ledger-integrated, invariant-governed orchestration onto an alpha TS runtime = high churn, redundant.
• The one non-redundant capability: driving non-Claude coding agents (codex/gemini/cursor + ~12) over a structured protocol — something neither cmux session-driver nor the Agent tool does today.
• If adopted: pin an exact version (never @latest in committed wiring), wrap behind a single thin KH adapter module so the alpha surface is one replaceable seam, scope to one heterogeneous-dispatch lane with --cwd <worktree>, pass MCP servers through. Do NOT wire into CI; do NOT migrate any SDLC lane off cmux/Workflow.
• Maturity gate: WATCH. Collapses to (iii) PATTERN ONLY if KH never needs to drive codex/gemini/cursor. Re-evaluate when upstream drops the alpha notice.

---

Treehouse — deep dive (the config investigation)

The product owner flagged treehouse as a likely adopt-as-is given our worktree pain. The honest answer is more interesting than yes/no, because KH already has a harness-native mechanism that solves most of what treehouse solves.

What treehouse is

A Go CLI (go install / curl|sh / nix / brew-able) managing a pool of pre-warmed, reusable git worktrees under ~/.treehouse/. No daemon. On treehouse get: fetch origin, find a pool worktree that is not in-use (live-process scan via gopsutil) AND not dirty, hard-reset it to the further-ahead of local/origin default branch (detached HEAD), run post_create hook, drop the human into a subshell. On exit: terminate lingering processes, reset, return to pool with node_modules/build cache intact. Config: repo-level treehouse.toml (max_trees only — hooks ignored for supply-chain safety) + user-level ~/.config/treehouse/config.toml (where [hooks] post_create/pre_destroy live).

What KH already has (the crux)

.claude/settings.local.json carries:

"worktree": { "symlinkDirectories": ["node_modules", ".venv", ".bin"] }

This is the Claude Code harness’s native worktree feature: when the Agent tool creates a worktree (isolation:"worktree"), it symlinks node_modules/.venv/.bin from the main tree into the worktree. The “lose all installed deps each time” problem treehouse exists to solve is already mitigated for harness-created worktrees — deps are symlinked, not reinstalled.

Why treehouse is two different verdicts

Agent-tool isolation:"worktree" path → (iii) PATTERN ONLY + largely redundant. Two structural blockers: (a) the harness owns worktree creation — there is no seam to delegate provisioning to treehouse get; and (b) worktree.symlinkDirectories already gives the deps-cache benefit. treehouse adds little here and cannot be injected anyway.

cmux session-driver + manual using-git-worktrees paths → (ii), but the lighter win is config, not the binary. These paths use bash git worktree add (+ .worktreeinclude) and do not inherit worktree.symlinkDirectories (a harness Agent-tool feature). They re-pay setup. treehouse’s physical-dir reuse would keep them warm — but so would extending our existing config.

The genuine gaps treehouse highlights (and the cheaper fix for each)

1. Build-cache (.next) reuse. symlinkDirectories covers node_modules/.venv/.bin but NOT .next — so the Turbopack rebuild tax persists on every path. Fix: evaluate adding .next (or a shared build-cache dir) to symlinkDirectories / .worktreeinclude. Cheaper than adopting treehouse.
2. cmux/manual paths don’t get symlinkDirectories. Fix: make session-driver-cmux’s provisioning honour the same symlink set (it already honours .worktreeinclude — add the dirs there), OR for cmux specifically, shell treehouse get as the provisioner (the real (ii) adopt).
3. using-git-worktrees skill is stale. It runs npm install (KH is Bun) and npm test, and is unaware of symlinkDirectories/.worktreeinclude. This is itself a quick-win fix (via update-skill): npm install→conditional bun install, npm test→bun run test, add the symlink awareness.
4. In-use detection / lingering-process termination. treehouse’s process-scan reclamation automates our manual “ALWAYS check git status before removing worktree” gotcha and kills the orphaned-dev-server class. session-driver-cmux’s stop-worker.sh already does a dirty-tree check before removal — so we have the safety half; the process-termination half is the genuine treehouse delta.

Treehouse verdict

• Don’t adopt the binary for the Agent-tool path — redundant with symlinkDirectories + harness-owned.
• The immediate quick win is config + a skill fix, not a new Go dependency: (a) fix the using-git-worktrees npm→bun staleness; (b) evaluate adding build-cache dirs to symlinkDirectories/.worktreeinclude; (c) make cmux provisioning honour the symlink set.
• treehouse-the-binary as a (ii) adopt is justified only for the cmux session-driver lane (rewire provisioning to treehouse get + a post_create hook running conditional bun install) — a deliberate, scoped change, not a quick win. Record for PRODUCT.
• Config changes if we DID adopt: install binary; ~/.config/treehouse/config.toml with max_trees + [hooks] post_create = ["<conditional bun install>"]; repo treehouse.toml with max_trees. Note: detached-HEAD pool model conflicts with our branch-per-worker model — an agent would git reset --hard origin/<branch> on acquire (our existing gotcha), with gitignored caches surviving the reset.

---

Impact on the ID-92 quick-wins

The prose quick-wins (A2ii, B1, B2, B5, C1, C2) are workflow-convention edits that do not depend on any external-tool adoption — they should proceed as planned. The adoptability pass changes the picture in three specific ways:

1. Treehouse is NOT a prose edit. It splits into (a) an immediate quick-win skill fix (using-git-worktrees npm→bun + symlink awareness), (b) a config evaluation (build-cache dirs in symlinkDirectories), and (c) a deferred PRODUCT decision (binary adopt for the cmux lane).
2. Two strong new adopt candidates surfaced (gh-axi, chrome-devtools-axi) that were not in the original quick-win list because they came out of this lens, not the survey’s. Both are light (ii): install + repoint one skill each. They are bankable now if the product owner wants them in scope.
3. The bench harness upgrades from RESEARCH §6 backlog-candidate to the empirical instrument that backs the whole “measure before standardising” position (OQ-3/OQ-4).

Newly-surfaced adoption subtask candidates (for ledger/PRODUCT)

Candidate	Tier	Bank now?	Notes
gh-axi adopt (install + CLAUDE.md directive + repoint 3 skills)	(ii) light	Eligible now	Re-validate on KH task sample
chrome-devtools-axi adopt (install mcp + repoint browser skill)	(ii) light	Eligible now	Sandbox-bypass note (B2 overlap)
using-git-worktrees npm→bun + symlink-awareness fix	n/a (defect)	Yes — quick win	Pure skill fix via update-skill
build-cache dirs in symlinkDirectories/.worktreeinclude	config	Evaluate	settings + cmux provisioning
bench harness vendor (scripts/bench/)	(ii) instrument	PRODUCT	Promote from §6 backlog candidate
treehouse binary for cmux lane	(ii)	PRODUCT	Scoped, deliberate
no-mistakes on human-PR path	(ii) heavy	PRODUCT	Daemon footprint; scope off ci
acpx for heterogeneous dispatch	(ii) narrow	PRODUCT/WATCH	Alpha; pin + wrapper; only if needed

Product-owner review (08/06/2026 — via the lavish-axi trial)

The product owner reviewed this assessment through the lavish-axi trial surface (Subtask 92.14) and signed off the dispositions, annotating no further action required now on the pattern-only / watch items:

• acpx — no further action beyond → PRODUCT / WATCH (heterogeneous-agent dispatch only; alpha-gated).
• gsh — no further action; pattern-only.
• axi — SDK — no further action; pattern-only.

The → PRODUCT deferrals (axi bench-harness, treehouse-binary, no-mistakes) carry to PRODUCT.md unchanged. gh-axi + chrome-devtools-axi are adopted (92.12 / 92.13). lavish-axi itself moves from (iii)-redundant to adopt — the PO is enabling its playbook-aware hooks (lavish-axi setup hooks, run async by the PO to avoid mid-session prompt-cache disruption; a deliberate PO-owned exception to the “agents never run AXI setup hooks” rule). A follow-up test of sub-agent / orchestration use of lavish is tracked as Subtask 92.15 (deferred).

Open decisions for PRODUCT

1. Adopt gh-axi + chrome-devtools-axi now, or defer to a deliberate evaluation? Both are light (ii) and beat the raw-tool path KH uses today. The adoption-bias rule argues for now; the counter is install-surface + version-pinning discipline across dev + CI images.
2. Bench harness — promote to a tracked instrument? It is the only thing that can A/B a guard before we standardise it; without it, A1/A2 guard tuning stays intuition-led (the survey’s explicit anti-pattern).
3. Treehouse — config-fix now, binary-adopt later? Recommended: yes to the using-git-worktrees fix + build-cache evaluation now; binary adopt for cmux is a separate PRODUCT slice.
4. no-mistakes / acpx — watch or adopt? Both are real but carry footprint/maturity liabilities; recommend recording with a precise scope (human-PR path / heterogeneous-dispatch only) rather than banking.
5. Settings-governance guard. gh-axi, chrome-devtools-axi, and the axi SDK all ship a setup hooks that writes SessionStart hooks into ~/.claude/settings.json directly. Standing rule for any AXI-family adopt: never run their setup hooks — route ambient context through update-config so our settings governance stays authoritative.