context-guard-cli 2.1.0__tar.gz → 2.2.0__tar.gz

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/.github/workflows/ci.yml

@@ -2,9 +2,9 @@ name: CI
 
 on:
   push:
-    branches: [main, v2, v2.1]
+    branches: [main, v2, v2.1, v2.2]
   pull_request:
-    branches: [main, v2, v2.1]
+    branches: [main, v2, v2.1, v2.2]
 
 jobs:
   test:

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/CHANGELOG.md

@@ -6,6 +6,57 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 
 ---
 
+## [2.2.0] - 2026-08-02
+
+Triggered by real dogfooding: Antigravity never raised the context-guard
+protocol in a fresh project, because `cg setup` only installed its
+enforcement hook, nothing discoverable.
+
+### Added
+
+- A discovery skill for Antigravity, installed by `cg setup` at
+  `~/.gemini/antigravity-cli/skills/context-guard/SKILL.md` alongside the existing
+  deny hook. Antigravity loads skills by progressive disclosure — only the
+  name and description sit in context until the model picks it — which is
+  what makes this affordable without repeating 2.0's bug 6.0.4
+  (`~/.gemini/GEMINI.md` contamination of every project on the machine,
+  which stays permanently out of scope). The skill carries the three-phase
+  DAG, the operative `cg` commands, and marks `cg approve` human-only.
+- `cg setup --project <dir>` now installs the Antigravity workspace rule
+  directly, instead of that artifact only ever being written by `cg new`.
+- A shared ownership-marker check: a skill or rule file not written by
+  context-guard is never overwritten — reported as `SKIP|SKILL_EXISTS|<path>`
+  and left alone, whether hit through `cg setup` or `cg new`.
+
+### Fixed
+
+- Antigravity detection now checks for `agy` — the CLI's actual binary name
+  — and `~/.gemini/antigravity-cli`, its state directory. The prior check
+  named `antigravity`, which resolves on PATH to an unrelated program.
+- `cg setup --project` was overwriting an `.agents/rules/context-guard.md`
+  a team had edited; `cg new` never did. Both paths now honor the same
+  ownership marker.
+
+### Changed
+
+- README.md, README.es.md and TUTORIAL.es.md Install sections lead with
+  `uv tool install context-guard-cli` / `pipx install`, isolated installs
+  that land `cg` on PATH globally — what a once-per-machine `cg setup`
+  assumes. `pip install` remains documented as a fallback. Explicit warning
+  added against `uv pip install context-guard-cli`, which installs into
+  whichever project venv is active rather than the machine, silently
+  defeating a global `cg setup`.
+- `docs/adapters/VERIFY.md`: step 2 no longer checks Antigravity discovery
+  via `agy inspect`, which does not exist as a subcommand — replaced with
+  the actual verification, behavioral: a new session, a multi-step task,
+  and whether the agent invokes `cg` unprompted. Step 5 no longer names
+  `--with-antigravity-hook`, a flag removed in 2.1; the deny hook installs
+  by default now, declined with `--no-hooks`.
+- VERIFY.md is complete for all three hosts — Claude Code, OpenCode and
+  Antigravity — closing the gap the README used to admit openly. The line
+  stating the OpenCode and Antigravity adapters had not been run against a
+  live host is removed; both have been.
+
 ## [2.1.0] - 2026-08-01
 
 ### Added

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: context-guard-cli
-Version: 2.1.0
+Version: 2.2.0
 Summary: The transactional memory layer for AI coding agents — your context survives crashes, compaction, and session loss
 License-Expression: MIT
 License-File: LICENSE
@@ -82,10 +82,19 @@ illustrative shorthand.
 Two lines, once per machine:
 
 ```bash
-pip install context-guard-cli
+uv tool install context-guard-cli
 cg setup
 ```
 
+No `uv`? `pipx install context-guard-cli` works the same way. Both install
+into an isolated environment and put `cg` on PATH globally — the whole point,
+since `cg setup` configures your machine once, not once per project.
+`pip install context-guard-cli` also works, as a fallback for a plain Python
+install with no `uv`/`pipx` available. **Do not use `uv pip install
+context-guard-cli`**: that installs into whichever venv is currently active —
+a single project's, if you happen to be inside one — not onto the machine,
+which silently defeats the point of a global `cg setup`.
+
 `cg setup` detects Claude Code, OpenCode and Antigravity, installs the slash
 commands, and puts `cg approve` behind each one's permission prompt — see
 [Adapters](#adapters-and-permission-configuration). It prints every file it
@@ -106,6 +115,22 @@ cd context-guard && uv venv && uv pip install -e ".[dev]"
 git config core.hooksPath .githooks   # activates the pre-commit gate below
 ```
 
+## Upgrading
+
+```bash
+uv tool upgrade context-guard-cli && cg setup
+```
+
+The second command is not optional. `cg setup` copies commands, skills and
+permission snippets into your host configs; upgrading the package does not
+touch those copies, so a new version's adapter fixes only reach a machine
+once `cg setup` runs again. It is idempotent — safe to run any time.
+
+Phase files already materialised in a project (`.context-guard/phases/`)
+are never overwritten, by design: a project keeps the phases it was started
+with, including your edits. Delete a phase file and run `cg new` to pull the
+current version.
+
 ## How it works
 
 ```
@@ -256,9 +281,7 @@ at `phases/{plan,execute,verify}.md` rather than duplicating them. How to put
 `cg approve` behind each harness's permission prompt is documented in
 [docs/adapters/](docs/adapters/), one `PERMISSIONS.md` per host, alongside the
 manual smoke-test checklist in [docs/adapters/VERIFY.md](docs/adapters/VERIFY.md).
-`cg setup` installs the right one for each detected host. The OpenCode and Antigravity
-adapters are ported from state-guard and covered by static tests only — they
-have not been run against a live host of either.
+`cg setup` installs the right one for each detected host.
 
 ## How this compares
 

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/README.es.md

@@ -66,10 +66,20 @@ nada acá es un resumen ilustrativo.
 Dos líneas, una vez por máquina:
 
 ```bash
-pip install context-guard-cli
+uv tool install context-guard-cli
 cg setup
 ```
 
+¿No tenés `uv`? `pipx install context-guard-cli` hace lo mismo. Ambos
+instalan en un entorno aislado y dejan `cg` en el PATH global — que es el
+punto, porque `cg setup` configura tu máquina una vez, no una vez por
+proyecto. `pip install context-guard-cli` también funciona, como alternativa
+para una instalación de Python simple sin `uv`/`pipx` disponible. **No uses
+`uv pip install context-guard-cli`**: eso instala en el venv que esté activo
+en ese momento — el de un proyecto puntual, si estás parado adentro de
+uno — no en la máquina, lo que anula en silencio el sentido de un `cg setup`
+global.
+
 `cg setup` detecta Claude Code, OpenCode y Antigravity, instala los slash
 commands, y deja `cg approve` detrás del permission prompt de cada uno — ver
 [Adapters](#adapters-y-configuración-de-permisos). Imprime cada archivo que
@@ -91,6 +101,23 @@ cd context-guard && uv venv && uv pip install -e ".[dev]"
 git config core.hooksPath .githooks   # activa el gate de pre-commit de más abajo
 ```
 
+## Actualizar
+
+```bash
+uv tool upgrade context-guard-cli && cg setup
+```
+
+El segundo comando no es opcional. `cg setup` copia los comandos, skills y
+snippets de permisos dentro de la configuración de tus hosts; actualizar el
+paquete no toca esas copias, así que las correcciones de adapters de una
+versión nueva recién llegan a la máquina cuando se vuelve a correr
+`cg setup`. Es idempotente — se puede correr las veces que quieras.
+
+Las fases ya materializadas en un proyecto (`.context-guard/phases/`) nunca
+se sobrescriben, por diseño: cada proyecto conserva las fases con las que
+empezó, incluidas tus ediciones. Borrá el archivo de fase y corré `cg new`
+para traer la versión actual.
+
 ## Cómo funciona
 
 ```

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/README.md

@@ -69,10 +69,19 @@ illustrative shorthand.
 Two lines, once per machine:
 
 ```bash
-pip install context-guard-cli
+uv tool install context-guard-cli
 cg setup
 ```
 
+No `uv`? `pipx install context-guard-cli` works the same way. Both install
+into an isolated environment and put `cg` on PATH globally — the whole point,
+since `cg setup` configures your machine once, not once per project.
+`pip install context-guard-cli` also works, as a fallback for a plain Python
+install with no `uv`/`pipx` available. **Do not use `uv pip install
+context-guard-cli`**: that installs into whichever venv is currently active —
+a single project's, if you happen to be inside one — not onto the machine,
+which silently defeats the point of a global `cg setup`.
+
 `cg setup` detects Claude Code, OpenCode and Antigravity, installs the slash
 commands, and puts `cg approve` behind each one's permission prompt — see
 [Adapters](#adapters-and-permission-configuration). It prints every file it
@@ -93,6 +102,22 @@ cd context-guard && uv venv && uv pip install -e ".[dev]"
 git config core.hooksPath .githooks   # activates the pre-commit gate below
 ```
 
+## Upgrading
+
+```bash
+uv tool upgrade context-guard-cli && cg setup
+```
+
+The second command is not optional. `cg setup` copies commands, skills and
+permission snippets into your host configs; upgrading the package does not
+touch those copies, so a new version's adapter fixes only reach a machine
+once `cg setup` runs again. It is idempotent — safe to run any time.
+
+Phase files already materialised in a project (`.context-guard/phases/`)
+are never overwritten, by design: a project keeps the phases it was started
+with, including your edits. Delete a phase file and run `cg new` to pull the
+current version.
+
 ## How it works
 
 ```
@@ -243,9 +268,7 @@ at `phases/{plan,execute,verify}.md` rather than duplicating them. How to put
 `cg approve` behind each harness's permission prompt is documented in
 [docs/adapters/](docs/adapters/), one `PERMISSIONS.md` per host, alongside the
 manual smoke-test checklist in [docs/adapters/VERIFY.md](docs/adapters/VERIFY.md).
-`cg setup` installs the right one for each detected host. The OpenCode and Antigravity
-adapters are ported from state-guard and covered by static tests only — they
-have not been run against a live host of either.
+`cg setup` installs the right one for each detected host.
 
 ## How this compares
 

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/TUTORIAL.es.md

@@ -37,7 +37,7 @@ Una aclaración honesta, porque este proyecto se toma en serio la honestidad: co
 Abrí la terminal y corré:
 
 ```bash
-pip install context-guard-cli
+uv tool install context-guard-cli
 cg setup
 ```
 
@@ -48,8 +48,14 @@ aprobación (paso 4). Al terminar imprime la lista exacta de archivos que
 tocó — nada oculto. Podés correrlo las veces que quieras: si ya está
 instalado, no duplica nada.
 
-*(Si usás `uv`, que es más rápido: `uv tool install context-guard-cli` y
-después `cg setup`.)*
+¿No tenés `uv`? `pipx install context-guard-cli` hace lo mismo. Si ninguno de
+los dos está disponible, `pip install context-guard-cli` también funciona,
+como alternativa.
+
+> **Ojo con esta:** `uv pip install context-guard-cli` *no* es lo mismo que
+> `uv tool install`. Instala la herramienta adentro del entorno virtual de
+> tu proyecto actual, no en tu máquina — y `cg setup` necesita que `cg` esté
+> disponible en cualquier terminal, no solo dentro de ese proyecto.
 
 Verificá que quedó todo:
 
@@ -64,9 +70,40 @@ herramienta; todo lo que hagas con context-guard empieza con `cg`.
 un cambio en un proyecto nuevo, `cg new` escribe ahí lo que falte. No
 necesitás descargar este repositorio ni copiar archivos a mano.
 
-> **Si algo falla:** el error más común es que `pip` instaló pero la terminal
-> no encuentra `cg`. Cerrá y reabrí la terminal. Si persiste, probá
-> `python3 -m pip install --user context-guard-cli` y de nuevo cerrar/reabrir.
+> **¿Dónde quedó instalado?** `uv tool install` y `pipx` ponen `cg` en un
+> directorio propio (`~/.local/bin` en Linux/macOS típicamente) y lo agregan
+> al PATH por vos. `pip install` sin `--user` lo deja donde viva tu Python
+> del sistema; con `--user`, en `~/.local/bin` también. Si el paso de
+> verificación de arriba no encuentra `cg`, es casi siempre esto: el
+> directorio existe pero tu terminal no lo tiene en el PATH todavía.
+
+> **Si algo falla:** el error más común es que la instalación terminó bien
+> pero la terminal no encuentra `cg`. Cerrá y reabrí la terminal. Si
+> persiste, probá `python3 -m pip install --user context-guard-cli` y de
+> nuevo cerrar/reabrir.
+
+---
+
+## 3.1. Cómo actualizar
+
+Cuando salga una versión nueva, dos comandos en uno:
+
+```bash
+uv tool upgrade context-guard-cli && cg setup
+```
+
+*(Con pipx: `pipx upgrade context-guard-cli && cg setup`.)*
+
+**Por qué son dos y no uno:** el primero actualiza el programa; el segundo
+vuelve a copiar los comandos y la configuración dentro de tu asistente. Si
+hacés solo el primero, tu asistente sigue usando las instrucciones viejas y
+las mejoras de la versión nueva no aparecen. Correr `cg setup` de más nunca
+rompe nada.
+
+**Tus proyectos viejos siguen como estaban.** Las guías de fase que se
+copiaron dentro de cada proyecto no se pisan al actualizar — a propósito,
+para no borrar cambios que hayas hecho. Los proyectos nuevos arrancan con
+las guías actualizadas.
 
 ---
 
@@ -172,7 +209,8 @@ Diagnostica y libera lo que quedó colgado de procesos muertos. Nunca resuelvas
 | Ver el avance | `cg status` | — |
 | Retomar tras un corte | `/cg-continue` | Continúa donde quedó |
 | Destrabar | `cg doctor --fix` | — |
+| Actualizar | `uv tool upgrade context-guard-cli && cg setup` | — |
 
-Instalación (una vez): `pip install context-guard-cli` y luego `cg setup` una vez por máquina.
+Instalación (una vez): `uv tool install context-guard-cli` y luego `cg setup` una vez por máquina.
 
 Documentación completa, en inglés y español, en el [repositorio](https://github.com/fdomerlo/context-guard).

context_guard_cli-2.2.0/context_guard/_data/hosts/antigravity/skills/context-guard/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: context-guard
+description: >-
+  Use when the user asks for a multi-step coding task, when they ask to
+  resume work after a lost, crashed or compacted session, or in any project
+  that already contains a `.context-guard/` directory. Drives the `cg` CLI so
+  a phase-governed change keeps its plan, its progress and its verification
+  on disk instead of in the conversation.
+---
+
+<!-- context-guard:begin -->
+# context-guard
+
+`cg` (long form: `context-guard`) is a transactional state manager. A change
+moves through fixed phases and nothing advances without passing that phase's
+gate, so a session that dies mid-task resumes instead of restarting.
+
+## The pipeline
+
+```
+PLAN --approve--> EXECUTE --tasks done--> VERIFY --approve--> ARCHIVE
+```
+
+| Phase   | Produces                               | Gate to leave it              |
+|---------|----------------------------------------|-------------------------------|
+| PLAN    | `objective.md`, `tasks.md`             | human approval, then `commit` |
+| EXECUTE | code changes, `tasks.md` checked off   | every task checked off        |
+| VERIFY  | `review-report.md`, `verify-report.md` | human approval, then archive  |
+
+`cg commit` rejects any transition outside that order.
+
+## On entering a phase, read that phase's file
+
+The full instructions live in `.context-guard/phases/plan.md`,
+`.context-guard/phases/execute.md` and `.context-guard/phases/verify.md` —
+not in this skill. Load the file for the phase you are entering and follow
+it exactly.
+
+## Commands
+
+- `cg new <name>` — scaffold a change, open PLAN, write the phase files.
+- `cg status` — what phase the change is in and what is still pending. Run
+  this first when resuming, before reading any code.
+- `cg next-task` — the next unchecked task, during EXECUTE.
+- `cg commit --next-phase <PHASE>` — advance, once the gate passes.
+- `cg list`, `cg validate`, `cg checkpoint`, `cg rollback` — inspect, check,
+  snapshot, undo.
+
+Every command takes `--change <name>`. Pass it whenever more than one change
+is active: `cg` errors rather than guessing which one you meant.
+
+## `cg approve` is human-only
+
+Never run `cg approve` yourself, and never run it "on behalf of" the user.
+When `cg commit` exits 6 (`APPROVAL_REQUIRED`), stop, show the human the
+artifacts the gate covers, and ask them to run the approval themselves.
+Editing `.context-guard/**/manifest.json` by hand is the same violation by
+another route: it forges the state the gate reads.
+<!-- context-guard:end -->

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/context_guard/guard/setup.py

@@ -214,6 +214,18 @@ def _install_opencode(root, with_mcp, global_scope):
     return touched
 
 
+# The path was confirmed against Antigravity CLI 1.1.9 via the /skills panel,
+# which lists ~/.gemini/antigravity-cli/skills/ as the user's global location;
+# builtin/ is the subtree with checksum, a sibling of this one, not its parent.
+# ANTIGRAVITY_GLOBAL_ROOT remains as is: hooks.json does reside in .gemini/config/.
+ANTIGRAVITY_GLOBAL_ROOT = (".gemini", "config")
+ANTIGRAVITY_SKILL_REL = (".gemini", "antigravity-cli", "skills", "context-guard", "SKILL.md")
+
+# Both artifacts we write into a user's tree as whole files carry this marker,
+# so a later run can tell its own output from a file of the same name the user
+# wrote themselves.
+OWNERSHIP_MARKER = "<!-- context-guard:begin -->"
+
 HOOKS_MANUAL_FIX = ("left untouched; add the deny hook manually "
                     "(see docs/adapters/antigravity/PERMISSIONS.md)")
 
@@ -248,36 +260,85 @@ def _hooks_shape_problem(cfg):
     return None
 
 
-def _install_antigravity(root, global_scope, no_hooks=False):
-    """Global scope installs the deny hook; project scope installs the rule.
+def _embedded_antigravity_file(relpath):
+    for name, text in iter_host_files("antigravity"):
+        if name == relpath:
+            return text
+    return None
+
 
-    The split follows what each artifact is for. The hook lives in user
-    config by definition, so it has no meaning in a project install; the
-    workspace rule travels with the repository, and for the global case
-    `cg new` materialises it per project instead.
+def _write_owned(path, text):
+    """Write one of our marked files, unless something else already owns it.
 
-    Returns `(touched, failure)`. Unlike the other hosts this one merges into
-    a file it did not create and cannot fully predict, so it needs a way to
-    decline without taking the whole run down with it.
+    Returns `(written, skip)`. A file carrying OWNERSHIP_MARKER is one of ours
+    and is refreshed, which is what lets a `cg` upgrade actually reach the
+    artifacts an earlier version installed. Anything else is left exactly as
+    it is: `context-guard` is a plausible name for a skill or a rule the user
+    wrote themselves, and this code cannot reconstruct what it would destroy.
+
+    Not a failure. A name collision means the user has a file here on purpose;
+    it says so and moves on, rather than deciding the machine is broken.
+    """
+    if os.path.exists(path):
+        with open(path, "r", encoding="utf-8") as f:
+            if OWNERSHIP_MARKER not in f.read():
+                return False, f"SKIP|SKILL_EXISTS|{path}|not written by context-guard, left as is"
+    _write_text(path, text)
+    return True, None
+
+
+def _install_antigravity(root, global_scope, no_hooks=False):
+    """Global scope installs the discovery skill and the deny hook; project
+    scope installs the workspace rule.
+
+    The split follows what each artifact is for. The hook lives in user config
+    by definition, so it has no meaning in a project install; the workspace
+    rule travels with the repository. Until 2.2 the global case installed the
+    hook alone — enforcement with nothing to discover it by — and the only
+    bootstrap artifact was written by `cg new`, which nobody runs before they
+    know `cg` exists. The skill closes that loop: Antigravity loads it by
+    progressive disclosure, so it costs nothing until the model picks it.
+
+    Returns `(touched, failure, skips)`. Unlike the other hosts this one
+    writes into files it did not create and cannot fully predict, so it needs
+    both a way to fail without taking the whole run down and a way to decline
+    a single artifact without failing at all.
     """
     if not global_scope:
-        for relpath, text in iter_host_files("antigravity"):
-            if relpath != "rules/context-guard.md":
-                continue
-            _write_text(os.path.join(root, ".agents", "rules", "context-guard.md"), text)
-            return [".agents/rules/context-guard.md"], None
-        return [], None
+        text = _embedded_antigravity_file("rules/context-guard.md")
+        if text is None:
+            return [], None, []
+        rule_rel = os.path.join(".agents", "rules", "context-guard.md")
+        written, skip = _write_owned(os.path.join(root, rule_rel), text)
+        return ([rule_rel.replace(os.sep, "/")] if written else [],
+                None,
+                [skip] if skip else [])
 
+    touched = []
+    skips = []
+
+    skill_text = _embedded_antigravity_file("skills/context-guard/SKILL.md")
+    if skill_text is not None:
+        skill_rel = os.path.join(*ANTIGRAVITY_SKILL_REL)
+        written, skip = _write_owned(os.path.join(root, skill_rel), skill_text)
+        if written:
+            touched.append(skill_rel.replace(os.sep, "/"))
+        if skip:
+            skips.append(skip)
+
+    # `--no-hooks` declines the enforcement, not the discovery. A user who
+    # does not want the deny hook still wants their agent to know the tool
+    # is there.
     if no_hooks:
-        return [], None
+        return touched, None, skips
 
-    hooks_rel = os.path.join(".gemini", "config", "hooks.json")
+    hooks_rel = os.path.join(*ANTIGRAVITY_GLOBAL_ROOT, "hooks.json")
     hooks_path = os.path.join(root, hooks_rel)
 
     try:
         cfg = _read_json(hooks_path)
     except ConfigCorruptError:
-        return [], f"FAIL|HOOKS_UNPARSEABLE|{hooks_path}|{HOOKS_MANUAL_FIX}"
+        return touched, f"FAIL|HOOKS_UNPARSEABLE|{hooks_path}|{HOOKS_MANUAL_FIX}", skips
     if cfg is None:
         cfg = {}
 
@@ -286,7 +347,9 @@ def _install_antigravity(root, global_scope, no_hooks=False):
         # Reported and left alone rather than normalised. Rewriting a config
         # into the shape this code prefers would discard whatever the user's
         # own tooling put there, and we cannot know what that was for.
-        return [], f"FAIL|HOOKS_UNRECOGNISED|{hooks_path}|{HOOKS_MANUAL_FIX} ({problem})"
+        return (touched,
+                f"FAIL|HOOKS_UNRECOGNISED|{hooks_path}|{HOOKS_MANUAL_FIX} ({problem})",
+                skips)
 
     snippet = json.loads(read_snippet("antigravity", "hooks"))
     new_hook = snippet["hooks"]["PreToolUse"][0]
@@ -301,7 +364,8 @@ def _install_antigravity(root, global_scope, no_hooks=False):
     if not already:
         pre_tool_use.append(new_hook)
     _write_json(hooks_path, cfg)
-    return [f"{hooks_rel.replace(os.sep, '/')} {HOOKS_NOTE}"], None
+    touched.append(f"{hooks_rel.replace(os.sep, '/')} {HOOKS_NOTE}")
+    return touched, None, skips
 
 
 # ---------------------------------------------------------------------------
@@ -323,7 +387,17 @@ def _detected(host, home):
         return (os.path.isdir(os.path.join(home, ".config", "opencode"))
                 or _on_path("opencode"))
     if host == "antigravity":
-        return os.path.isdir(os.path.join(home, ".gemini")) or _on_path("antigravity")
+        # `agy` is the real CLI binary — confirmed on a live install
+        # (PLAN-2.2 F2.1): `antigravity` also resolves on PATH there, but to
+        # an unrelated program, so it is kept rather than trusted alone.
+        # `~/.gemini/antigravity-cli` is the CLI's own state directory (log/,
+        # brain/, settings.json all live under it there), a stronger signal
+        # than the bare `~/.gemini` parent that anything gemini-related
+        # could have created — kept alongside it, not instead of it.
+        return (os.path.isdir(os.path.join(home, ".gemini"))
+                or os.path.isdir(os.path.join(home, ".gemini", "antigravity-cli"))
+                or _on_path("antigravity")
+                or _on_path("agy"))
     return False
 
 
@@ -362,6 +436,7 @@ def run_setup(host="all", with_mcp=False, project=None, no_hooks=False):
     lines = [f"Installing context-guard adapters into {root} ..."]
     touched = []
     failures = []
+    skips = []
 
     for name in selected:
         if name == "claude":
@@ -375,18 +450,21 @@ def run_setup(host="all", with_mcp=False, project=None, no_hooks=False):
             # cannot be configured reports and steps aside: letting it abort
             # the run would let one unrelated file on disk decide that the
             # tool does not work on this machine.
-            host_touched, failure = _install_antigravity(root, global_scope, no_hooks)
+            host_touched, failure, host_skips = _install_antigravity(
+                root, global_scope, no_hooks)
             touched += host_touched
+            skips += host_skips
             if failure:
                 failures.append(failure)
                 lines.append("  -> Antigravity: hooks.json left untouched, see below")
             elif not global_scope:
-                lines.append("  -> Antigravity: rule installed")
+                lines.append("  -> Antigravity: workspace rule installed")
             elif no_hooks:
-                lines.append("  -> Antigravity: deny hook skipped (--no-hooks)")
+                lines.append("  -> Antigravity: skill installed, deny hook "
+                             "skipped (--no-hooks)")
             else:
-                lines.append("  -> Antigravity: deny hook merged into "
-                             "~/.gemini/config/hooks.json")
+                lines.append("  -> Antigravity: skill installed, deny hook merged "
+                             "into ~/.gemini/config/hooks.json")
 
     for name in HOST_DIRS:
         if name in selected:
@@ -410,6 +488,15 @@ def run_setup(host="all", with_mcp=False, project=None, no_hooks=False):
     else:
         lines.append("  (none)")
 
+    # Listed apart from both the touched files and the failures: nothing was
+    # written, and nothing is wrong. Kept visible anyway, because the user is
+    # otherwise left with a host that installed "successfully" and still has
+    # no entry point.
+    if skips:
+        lines.append("")
+        lines.append("Skipped (a file of ours already exists, written by someone else):")
+        lines.extend(f"  {skip}" for skip in skips)
+
     if failures:
         lines.append("")
         lines.append("Failed:")

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/docs/adapters/VERIFY.md

@@ -25,12 +25,15 @@ Confirm the files land where the tests say they should:
 respectively, plus the merged permission config
 (`.claude/settings.json`, `opencode.json`).
 
-### 2. The command / rule is visible to the host
+### 2. The entry point is discovered, not just installed
 
 - **Claude Code**: `/` menu lists `cg-new` and `cg-continue`.
 - **OpenCode**: `/help` lists `cg-new` and `cg-continue`.
-- **Antigravity**: `/skills` (or the equivalent surface) shows the rule
-  loaded, confirmed with `agy inspect` if available.
+- **Antigravity**: there is no `agy inspect` or equivalent command to check
+  instead. Open a **new** session — rules and skills load at session start,
+  so an already-open one will not see anything just written — give it a
+  multi-step coding task, and watch whether it invokes `cg` on its own,
+  unprompted. That behavior, not any command's output, is the verification.
 
 ### 3. `/cg-new demo` drives `cg`, not improvisation
 
@@ -54,9 +57,9 @@ intercepts it before it runs:
 
 - **Claude Code**: the `ask` permission prompt appears.
 - **OpenCode**: the `ask` permission prompt appears.
-- **Antigravity**: either the `--with-antigravity-hook` deny fires, or (if
-  not installed) the CLI's default `request-review` mode prompts before the
-  command runs.
+- **Antigravity**: the deny hook `cg setup --host antigravity` installs by
+  default fires. If that machine was set up with `--no-hooks`, the CLI's
+  default `request-review` mode prompts before the command runs instead.
 
 ### 6. Headless, where the host has one
 
@@ -73,8 +76,6 @@ version, host version, and date — this checklist decays the moment either
 side changes its config schema, so a pass from six months ago is not a pass
 today.
 
-- [ ] Claude Code — verified by: __________ on: __________
-- [ ] OpenCode — verified by: __________ on: __________
-- [ ] Antigravity — verified by: __________ on: __________ (may remain
-      pending per PLAN.md F6 acceptance criterion 4; record it as such
-      rather than leaving it silently unchecked)
+- [x] Claude Code — verified by: fdomerlo on: 2026-08-02
+- [x] OpenCode — verified by: fdomerlo on: 2026-08-02
+- [x] Antigravity — verified by: fdomerlo on: 2026-08-02

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "context-guard-cli"
-version = "2.1.0"
+version = "2.2.0"
 description = "The transactional memory layer for AI coding agents — your context survives crashes, compaction, and session loss"
 readme = "README.md"
 requires-python = ">=3.10"

{context_guard_cli-2.1.0 → context_guard_cli-2.2.0}/tests/test_adapters.py

@@ -410,8 +410,9 @@ class TestVerifyChecklist(unittest.TestCase):
         self.assertIn("cg approve", self.text)
 
     def test_has_a_recordable_checklist(self):
-        self.assertIn("- [ ]", self.text)
-
-    def test_allows_antigravity_to_remain_pending(self):
-        self.assertIn("pending", self.text.lower())
+        """Markdown checkbox syntax, checked or not — this stopped pinning
+        "still unchecked" once PLAN-2.2 F3 actually completed all three
+        rows; the property worth keeping is that the format is recordable
+        at all."""
+        self.assertRegex(self.text, r"- \[[ x]\]")