feat(adapters): OpenMono adapter contract

[IgorGanapolsky]

What

Adds adapters/openmono/ — the ThumbGate-side contract for
OpenMono (1.8k stars, AGPL-3.0), a
terminal-native local-LLM coding agent.

Why this is an integration, not a competitive play

OpenMono's users are our ICP, and they already have a genuine enforcement chokepoint:

• Docker sandbox with the workspace mount as an explicit blast radius
• "Nothing bypasses the pipeline" — the hard part, already solved
• Doom-loop detection at a fixed 3× repeated tool sequence
• Per-sub-agent turn budgets (Explore 15 / Plan 10 / Coder 30 / Verify 20)
• Read-only tools parallelized, writes restricted to authorized agents

Pitching them "you need guardrails" would have been false. The real gap is that every
one of those controls is static and per-run — run 1 and run 500 are identical. Nothing
learns from Monday's incident before Tuesday's run.

That is exactly the self-improving-firewall position: capture failure → lesson →
prevention rule → block on the next matching call.

Two couplings specific to their design are encoded in openmono.json:

1. loopDetection.adaptive — learn which sequences preceded wasted runs in this repo
   instead of a fixed 3× threshold, while leaving legitimate retry loops alone.
2. Turn budgets as measured per-repo distributions rather than a guess that must hold
   everywhere.

Deliberately NOT in package.json files

These two paths are not added to the npm files array, on purpose:

• The runtime binding does not exist yet — proposed upstream as
  StartupHakk/OpenMonoAgent.ai#129,
  awaiting confirmation of the hook surface. Shipping unbound config in the runtime
  package would be theater.
• It would push the bundle 467 → 469 and collide with the ratchet bump in open PR feat(security): free Agent Security Central posture report #3491.

When upstream confirms, the binding + files entries + a single deliberate ratchet bump
land together.

Verification

npm pack --dry-run  →  files: 466   (unchanged; adapters are enumerated individually)
pre-commit: version sync ✓, all guards passed

Licensing

ThumbGate stays permissive; OpenMono is AGPL-3.0. The adapter lives here and talks over
their existing interface, so neither side takes on a new obligation.

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
thumbgate	Ready	Preview	Aug 18, 2026 1:36pm

[gitar-bot]

Gitar is working

_Gitar

[greptile-apps]

Greptile Summary

Adds an OpenMono adapter definition and installation guidance. The documented npx thumbgate init --adapter=openmono flow was run in a clean environment and completed successfully without creating the promised OpenMono PreToolUse hook, leaving users without the stated enforcement.

Confidence Score: 4/5

Not safe to merge as documented because the advertised OpenMono installation flow silently leaves enforcement uninstalled.

The exact documented command was executed in an isolated project and produced no OpenMono hook configuration; a supported Claude control run created its PreToolUse hook. The CLI's agent-only dispatch explains the different outcomes.

Files Needing Attention: adapters/openmono/INSTALL.md needs an accurate installation contract, while bin/cli.js and the hook wiring implementation need an OpenMono path if the documented command is to remain supported.

T-Rex Logs

What T-Rex did

• T-Rex produced a proof for a posted P1 finding and linked it to the review comment.
• T-Rex created an isolated OpenMono init reproducer source to exercise the P1 finding.
• The environment and init evidence shows an empty HOME and project before OpenMono initialization, and the init completes without an OpenMono hook file while a PreToolUse hook is registered.
• Contract validation confirmed the isolated OpenMono run returned exit code 0 but had no OpenMono configuration or hook file, and it observed the wired PreToolUse hook and a gate-check settings file being created.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   OpenMono installation command reports success without registering the claimed hook

   • Bug
     • adapters/openmono/INSTALL.md:44-48 tells users to run npx thumbgate init --adapter=openmono and says that it registers the PreToolUse hook against OpenMono. In an empty HOME/project, the exact command completed with exit code 0 but created only generic ThumbGate/MCP/ChatGPT artifacts; the isolated scan found no OpenMono configuration or hook file.
   • Cause
     • The generic parser accepts --adapter=openmono (bin/cli.js:274-292), but init validates and dispatches only args.agent (bin/cli.js:1016-1024, 1188-1212). OpenMono is absent from SUPPORTED_AGENTS (bin/cli.js:766-775) and from the auto-hook dispatcher (scripts/auto-wire-hooks.js:77-95, 704-733). Thus the adapter flag has no effect and success reflects generic scaffolding only.
   • Fix
     • Either implement an explicit OpenMono adapter path that validates the OpenMono hook surface and writes/verifies the correct OpenMono configuration, or change adapters/openmono/INSTALL.md:44-53 to say the integration is proposed/not yet installable and reject --adapter=openmono until supported. Add an isolated CLI test asserting the command either creates the expected OpenMono PreToolUse configuration or fails non-zero.

   _{Ran code and verified through T-Rex}

_{Reviews (1): Last reviewed commit: "feat(adapters): add OpenMono adapter con..." | Re-trigger Greptile}