review: drop Antigravity capture wiring (keep migration detection)

[kridaydave]

Split out of PR #39 (kridaydave:fix/good-first-issues) to address review concern #1.

We made a deliberate, documented call in detect.ts and the FAQ: we intentionally do not wire Antigravity capture yet, because Google has not published the finalized hook format, and shipping a capture path that silently never fires would break the transparency/reliability promise in PHILOSOPHY.md ("no half-working features dressed up to look finished"). fromAntigravity guesses the payload shape and AntigravityCliProvider guesses agy -p - (which, per Google's own docs, a non-interactive agy also needs --headless/--approve or it hangs).

Most importantly, adding antigravity to ALLOWED_ADAPTERS/HOOK_ADAPTERS to satisfy the parity test was the part that should not land: that invariant exists to prove every registered adapter is real and fully wired end-to-end (install + detect + a real fixture), so including it made the test pass without the thing it tests being true.

This removes:

• src/adapters/antigravity.ts and src/providers/antigravity-cli.ts
• the antigravity entries in ALLOWED_ADAPTERS, HOOK_ADAPTERS, PARKED_PROVIDERS
• the adapter/provider registration tests

The Antigravity migration detection in detect.ts stays (it only switches the Gemini setup path to inject-only, it does not register capture hooks).

The other three concerns (bounded concurrency #2, the captureDisabled cache fix #3, config-parse dedup #4) land in their own PRs, also split from #39.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[Shreyan1]

Thanks Kriday, splitting the #39 review into four PRs was exactly the right move and I appreciate how fast you turned this around. The Antigravity removal itself is spot on: adapter, provider, ALLOWED_ADAPTERS, HOOK_ADAPTERS, PARKED_PROVIDERS all gone cleanly, and the migration detection correctly kept. Merged with current main the suite is green (1052).

What's holding it up is scope and freshness, not the removal:

• This branch is 7 commits behind main and carries the whole #39 async refactor (28 files), so the actual "drop Antigravity" change is buried under bootstrap/storage/migrate/menu/Windows edits. A reviewer should be able to open the diff and see just the removal. Could you rebase onto current origin/main and bring over only the Antigravity removal? It should be about 6 files.
• Two CI failures, both of which clear on rebase: the version-bump gate (this is user-facing, so bump package.json + VERSION in src/cli.ts), and CodeQL flags a HIGH at storage.ts (see inline) that is not on current main, you are reintroducing it by carrying the old #39 trimIfNeeded.

Concretely: git fetch origin main, branch fresh off it, cherry-pick just the removal. Everything else here belongs in #42/#43. I left a couple of inline notes, plus a shared process note (same root cause across all four) in a separate comment below.

[Shreyan1]

CodeQL flags this as a HIGH TOCTOU: you stat here, then readFileSync on the next line, and the file can change in between. Heads up, current main does not have this, it comes from the #39 rewrite this branch carries (main still wraps the statSync in its own try/return). Rebasing on main drops the alert. If you do want to keep this shape, read through a single fd (open then fstatSync then read), which is the exact pattern readFileBytesSafe already uses further down this file.

[Shreyan1]

Example of the scope issue: this renderMenu rewrite has nothing to do with dropping Antigravity, it is only in the diff because the branch carries all of #39. Not wrong, just not reviewable in a PR titled "drop Antigravity". It should ride in whatever PR actually owns the async refactor.

[Shreyan1]

One note that applies to all four (#41, #42, #43, #44), since it is the same root cause each time, and a bit about what I hit running them locally.

First, credit where it is due: every one of the four fixes is technically correct. You read the review precisely. The problems are git hygiene and test coverage, not the engineering.

What actually happened when I pulled and ran these:

• I could not review any of them as "one concern." Each branch is ~7 commits behind main and carries the entire Good first issues: async capture pipeline, Windows fixes, and Antigravity adapter #39 async refactor (28 to 33 files), so the real change is buried. To see what each PR actually does I had to diff against the Good first issues: async capture pipeline, Windows fixes, and Antigravity adapter #39 base and merge current main in. A reviewer should be able to open the diff and see the fix.
• "Green on the branch" is misleading here. Run on the branch alone, review: bound process concurrency in git capture and bootstrap scans #42 and review: fix captureDisabled module-global cache poisoning #43 look fine (1034 passing). But CI tests the PR merged into current main, and only then do the real failures show up: 3 red tests from the adapter-wiring parity gate, because review: bound process concurrency in git capture and bootstrap scans #42/review: fix captureDisabled module-global cache poisoning #43 still carry antigravity in HOOK_ADAPTERS (they are not based on review: drop Antigravity capture wiring (keep migration detection) #41). I only saw this by reproducing the merge locally. Please test against a merge with origin/main, not just your branch.
• All four reintroduce a CodeQL HIGH (storage.ts TOCTOU) that is not on current main, purely because they carry the old Good first issues: async capture pipeline, Windows fixes, and Antigravity adapter #39 trimIfNeeded.
• Now that I have Ollama enabled locally, I ran the extraction path for real (llama3.2:1b responds fine, so the pipeline itself is healthy) and confirmed the review: dedup config parsing, revert claude/gemini -p - change, bump version #44 config bug is not academic: an ollama_url carrying an embedded credential or fragment with a # gets silently truncated, so extraction would hit the wrong host.
• These trip the exact two CI gates that were added in response to the last review (the parity test and the version-bump check), and only review: dedup config parsing, revert claude/gemini -p - change, bump version #44 bumps the version, so the four-PR version story does not add up (they cannot all be 0.9.1).

If you are driving these with a Codex agent, five instructions fix all of it at once:

1. Always git fetch origin main and branch/rebase off current main, never a stale checkout. Rebase before every push.
2. For a split, each PR's diff against main touches only that concern's files. Give the agent the explicit file allowlist. Dependent fixes branch off the parent branch, not main, so review: bound process concurrency in git capture and bootstrap scans #42/review: fix captureDisabled module-global cache poisoning #43/review: dedup config parsing, revert claude/gemini -p - change, bump version #44 stack on review: drop Antigravity capture wiring (keep migration detection) #41.
3. Every change ships with a test that fails without it; every bug fix ships with a regression test that reproduces the bug.
4. Every user-facing PR bumps package.json + VERSION (src/cli.ts). Standing rule, not a one-off.
5. Before pushing: npm run build && npm run lint && npm test against a merge with origin/main, and do not reintroduce CodeQL findings.

Cleanest path from here: rebase all four on current main, stack #42/#43/#44 on #41, slim each to its real diff, add the two missing tests (concurrency primitive + cache regression), and fix the config-# bug in #44. The engineering is solid, this is all about landing it cleanly. Thanks again for turning the split around so fast.