Files
msd-core/docs/reference/capability-matrix.md
Tom Boucher b54c1c5848 fix(#4709): retire the Gemini CLI reviewer lane (#4716)
* fix(#4709): retire the Gemini CLI reviewer lane

Google stopped serving Gemini CLI for the free/Pro/Ultra tiers on 2026-06-18 —
the same sunset that removed the gemini RUNTIME in #1928 (shipped 1.8.0). GSD
targets solo developers, so those tiers ARE the user path: the lane spawned
`gemini {{model}} -p -`, a binary that no longer answers for the majority of
users, and five locales documented it as a supported choice.

The lane was re-created after #1928 by the reviewer-lane-as-manifest-data work
(6a9babda69, #2798/#2837, ADR-2782). Per the maintainer that re-creation was an
error in that buildout rather than a considered decision, so this corrects a
mistake and needs no ADR-2782 amendment.

Reviewer roster: 12 lanes / 13 flags -> 11 lanes / 12 flags.

TWO sources of truth had to be removed, not one. Deleting
capabilities/gemini/capability.json left the capability registry at 11 lanes
while src/review-lane-descriptor.cts's hand-maintained REVIEWER_LANES array
still carried its own complete gemini entry at 12 — precisely the disagreement
checkReviewerLaneParity exists to catch. Both are gone; both parity checkers
now run clean against the real tree (lane parity ok/0 violations, docs parity
0 violations).

Surfaces stripped of the dead flag:
- capabilities/gemini/ deleted; registry and capability-matrix regenerated
- src/review-lane-descriptor.cts: REVIEWER_LANES entry, docblock count, and the
  three doc comments that used --gemini as a live example
- commands/gsd/{review,plan-review-convergence,autonomous,progress}.md and the
  four matching skills/*/SKILL.md: argument-hint frontmatter and flag bullets
- gsd-core/workflows/help/modes/{full,full.compact}.md: /gsd-help signatures,
  the detected-CLI list, and the reviewer-title list
- gsd-core/workflows/settings-integrations.md: the integrations wizard no longer
  offers "Gemini" as a model option, and the settable-keys list drops it
- gsd-core/workflows/review.md: the `command -v gemini` probe, the --gemini
  flag, the roster frontmatter, the install pointer to the sunset repo, and the
  jq-less / precedence / self-skip lane lists
- gsd-core/workflows/sync-skills.md: "two runtimes (grok, gemini) resolve to
  ANOTHER runtime's skills root" is now one runtime; gemini never aliased
  anything, it fell through canonicalizeRuntimeName to a fail-closed default
- docs/{CONFIGURATION,COMMANDS,CLI-TOOLS}.md, docs/reference/capability-matrix.md,
  docs/how-to/set-up-cross-ai-review.md — including its `npm install -g
  @google/gemini-cli` instruction and the two rows recommending --gemini
- docs/features/{cross-ai-peer-review,opt-in-parallel-reviewer-lanes}.md as the
  generator inputs behind docs/FEATURES.md, plus the three locale FEATURES.md
  signature lines the docs-parity gate covers (the #2781 class: a flag change
  that never reaches the mirrors)

Counts reconciled against measurement rather than arithmetic: 8 timeout keys of
11 lanes, 11 budget keys, 9 model keys, and four hardcoded literals in
tests/reviewer-lane-declarations.test.cjs (NEW_LANE_ONLY_IDS 5->4, LITERAL_ROSTER
12->11, two roster counts 12->11).

BEHAVIOR CHANGE, accepted deliberately: `gsd config-set review.models.gemini`
now errors with "Unknown config key". An existing key already in
.planning/config.json still parses and is simply never read, so no project fails
to load. This is the repo's own documented policy for exactly this case
(docs/CONFIGURATION.md:327 — "a key left over from a removed reviewer validated
silently and was never read. Such a key is now rejected by config-set"), so no
installer migration ships. Note my first measurement of this was WRONG: I tested
config-get, which reads undeclared keys fine, and generalised. Read and write are
different surfaces and gave different answers.

Antigravity is untouched throughout — its --antigravity/--agy flags,
review.models.agy, ~/.gemini/antigravity configHome, ~/.gemini/config global
skills root (#3738), hookEvents "gemini", GEMINI.md instruction file, and every
gemini-* model id it actually runs on.

Refs #4709

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(#4709): changeset for the reviewer-lane retirement

Type Removed: the --gemini flag and its three config keys are user-visible
surface that no longer exists.

Refs #4709

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* fix(#4709): close the 24 test failures and the locale-doc gap the gates found

An adversarial review and a full matrix run between them found substantially
more fallout than inspection had. All of it is this PR's own, and all of it is
fixed rather than waved off.

THE MATRIX RUN FOUND 24 FAILURES ACROSS 6 FILES. Inspection had predicted two.
The dominant class was a test helper that looks up a lane by slug and throws
`no declared lane 'gemini'`:

- tests/feat-2483-review-claude-mds-guard.test.cjs (6) — used gemini as the
  "other declared first-party lane" to contrast against claude's env
  suppression. Now qwen, verified from source as a lane that declares no `env`
  (only claude does), so the contrast still holds.
- tests/review-lane-descriptor.test.cjs (6) — the duplicate-flag and
  duplicate-section fixtures deliberately COLLIDED with a real declared lane to
  prove the parity checker reports a duplicate. `--gemini`/`Gemini` no longer
  collide with anything, so the checker reported
  `descriptor_lane_not_in_registry:acme` instead and the tests proved nothing.
  Now collide with `--codex`/`Codex`, reproduced against the real checker.
- tests/review-reviewer-selection.test.cjs (3) — these distinguish KNOWN-but-
  undetected from UNKNOWN. gemini flipped categories, inverting what they
  proved. The known case now uses qwen; `__nope__` stays the unknown fixture.
- tests/review-default-reviewers-resolution.test.cjs (2), and
  tests/settings-integrations.test.cjs (3) — the wizard now offers three
  reviewer CLIs, not four, so the test and its name say three.
- Two count assertions the earlier sweep missed outright:
  reviewer-lane-declarations.test.cjs:359 (`length, 12`) and
  reviewer-docs-parity.test.cjs:681 (`>= 12`).

THE LOCALE-DOC GAP, and why the parity gate stayed green over it. All four
locale mirrors still documented `--gemini` as a live reviewer flag. The
docs-parity checker asserts the PRESENCE of every current flag and never the
ABSENCE of a retired one, so "0 violations" was never evidence those files were
clean — my earlier reading of it as such was wrong. This is the #2781
locale-drift class in the opposite direction. Fixed across 12 locale files:
COMMANDS.md flag lists and table rows, CONFIGURATION.md `review.models.gemini`
rows and reviewer prose, CLI-TOOLS.md config examples, and
set-up-cross-ai-review.md including its install block and its
which-reviewer-to-choose row, which now recommends Antigravity.

ALSO FOUND, and instructive about my own method: docs/CONFIGURATION.md:297 still
carried a `review.models.gemini` row. My sweep had missed it because my grep
excluded lines matching `gemini-[0-9]` to spare Google's model ids — and that
row's example value is `"gemini-2.5-pro"` on the same line. The exclusion built
to avoid false positives created a false negative.

Remaining comment/example sites: src/review-reviewer-selection.cts:309 and
src/config.cts:598 named the dead flag and key as examples;
gsd-core/references/planning-config.md:269 likewise; and
review-reviewer-selection.cts:22 claimed in the PRESENT tense that gemini is a
lane-only reviewer capability. Line 38 of that same docblock says "Before this
phase the five non-runtime reviewers (gemini, ...)" and is left exactly as is —
that is past-tense history, and rewriting it would falsify the record.

Deliberately still deferred to Phase 4, because it is the RUNTIME axis rather
than the reviewer lane: the locale install-on-your-runtime.md `--gemini --global`
instructions, the USER-GUIDE colon-form notes, and the ARCHITECTURE
runtime-detection flag lists.

Both parity checkers green against the real tree; lint:ci exit 0.

Refs #4709

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(#4709): backfill the changeset PR number

pr: 0 -> 4716, now that the PR exists. Never guessed ahead of the number.

Refs #4709

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: sim <sim@local>
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 03:03:44 -04:00

11 KiB

Capability matrix reference

Generated file — do not edit by hand. This matrix is generated from the capability registry by scripts/gen-capability-matrix.cjs and kept honest by a drift guard (tests/capability-matrix-sync.test.cjs runs --check). Any manual edit is overwritten on the next generation run. To change a capability's declared metadata, edit the corresponding capabilities/<id>/capability.json and run node scripts/gen-capability-matrix.cjs --write.

See also: ADR-1244 — Capability manifest fields — The capability trust model


Column definitions

Column Description
id Canonical capability identifier; unique across first- and third-party capabilities. Reserved prefixes: gsd-, gsd-core-, anthropic-.
role feature — extends what the loop does; runtime — adapts GSD to a specific AI runtime/IDE; reviewer — declares a cross-AI reviewer lane (ADR-2782). A capability may be both a runtime and a reviewer.
tier core — always active; standard — active when the runtime supports it; full — opt-in or runtime-specific.
engines.gsd Semver RANGE expressing host-version compatibility. A hard gate at install and at load. — means the capability declares no range.
extension points The loop points this capability registers hooks into (from the registry's byLoopPoint index). — means it registers none (typical for runtime capabilities, whose job is surface emission).
hook kinds Which of step, contribution, gate the capability's hooks use. — means none.
source first-party — ships with GSD Core; third-party — installed from an external source via gsd capability install.

On versions. This matrix intentionally omits a per-capability version column. First-party capabilities are versioned in lockstep with the GSD Core package (their capability.json version always equals the GSD release version), so a per-row version would simply repeat the package version and churn the committed file on every release. The stable host-compatibility signal — engines.gsd — is shown instead. A third-party capability's exact version is recorded in the per-runtime ledger (.gsd-capabilities.json) at install time.


Native (first-party) capabilities

First-party capabilities are implicitly trusted: they ship as part of the GSD Core package and are stamped with the package version at release (per ADR-1244 D6). They are not subject to the consent or integrity-pin flow applied to third-party capabilities.

Feature capabilities (role: feature) — 22

Feature capabilities extend what the loop does — contributing research, planning, execution, verification, or ship artefacts at the loop extension points.

id role tier engines.gsd extension points hook kinds source
ai-integration feature full >=1.6.0 plan:pre, verify:pre step, contribution, gate first-party
assumption-delta feature full >=1.6.0 plan:pre contribution first-party
audit feature full >=1.6.0 — — first-party
broken-windows feature full >=1.7.0 ship:pre gate first-party
claude-orchestration feature full >=1.7.0 plan:post, execute:wave:pre contribution first-party
code-review feature full >=1.6.0 execute:wave:post, execute:post step first-party
drift feature full >=1.6.0 plan:pre, execute:wave:post gate first-party
external-job feature full >=1.7.0 plan:post, execute:wave:post contribution first-party
gap-analysis feature standard >=1.6.0 plan:post gate first-party
graphify feature full >=1.6.0 — — first-party
intel feature full >=1.6.0 plan:pre step first-party
live-dom-uat feature full >=1.11.0 execute:wave:post step first-party
mempalace feature full >=1.6.0 discuss:pre, discuss:post, plan:pre, plan:post, execute:wave:post, verify:post, ship:post step, contribution first-party
nyquist feature full >=1.6.0 verify:post step first-party
pattern-mapper feature full >=1.6.0 plan:pre step first-party
profile-pipeline feature full >=1.6.0 — — first-party
refactor-trigger feature full >=1.10.0 execute:post step first-party
research feature standard >=1.6.0 plan:pre step first-party
schema-gate feature full >=1.6.0 plan:pre contribution first-party
security feature full >=1.6.0 plan:pre, verify:post, ship:pre step, contribution, gate first-party
tdd feature full >=1.6.0 plan:pre, execute:post contribution, gate first-party
ui feature full >=1.6.0 plan:pre, execute:wave:post, verify:post step, gate first-party

Runtime capabilities (role: runtime) — 19

Runtime capabilities adapt GSD to a specific AI runtime or IDE — emitting skills, agents, hooks configuration, and surface files for that host. They typically register no loop hooks (their primary responsibility is surface emission), so their extension-point and hook-kind cells are —.

id role tier engines.gsd extension points hook kinds source
antigravity runtime core >=1.6.0 — — first-party
augment runtime core >=1.6.0 — — first-party
claude runtime core >=1.6.0 — — first-party
cline runtime core >=1.6.0 — — first-party
codebuddy runtime core >=1.6.0 — — first-party
codex runtime core >=1.6.0 — — first-party
copilot runtime core >=1.6.0 — — first-party
cursor runtime core >=1.6.0 — — first-party
hermes runtime core >=1.6.0 — — first-party
kilo runtime core >=1.6.0 — — first-party
kimi runtime core >=1.6.0 — — first-party
kimi-code runtime core >=1.7.0 — — first-party
opencode runtime core >=1.6.0 — — first-party
pi runtime core >=1.7.0 — — first-party
qwen runtime core >=1.6.0 — — first-party
trae runtime core >=1.6.0 — — first-party
vscode runtime core >=1.7.0 — — first-party
windsurf runtime core >=1.6.0 — — first-party
zcode runtime core >=1.6.0 — — first-party

Reviewer capabilities (role: reviewer) — 4

Reviewer capabilities declare a cross-AI reviewer lane — one external CLI or model endpoint /gsd-review hands a plan to (ADR-2782 D3). They are not install targets: they emit no skills, agents, hooks or surface files, so their extension-point and hook-kind cells are —. A host that is also a reviewer (Claude, Codex, Cursor, OpenCode, Qwen, Antigravity) keeps one manifest and appears under runtime above, carrying its lane alongside its runtime body; only lanes that GSD never installs into appear here.

Because a lane receives the plan text, requirements, research findings and CONTEXT.md decisions, it is a disclosed executable surface and is consent-gated at install like any other — see the trust model.

id role tier engines.gsd extension points hook kinds source
coderabbit reviewer full >=1.8.0 — — first-party
llama-cpp reviewer full >=1.8.0 — — first-party
lm-studio reviewer full >=1.8.0 — — first-party
ollama reviewer full >=1.8.0 — — first-party

Third-party capabilities

This matrix is the first-party catalogue: it is generated from the committed registry and therefore lists only the capabilities that ship with GSD Core. Installed third-party capabilities are NOT written into this committed file. Once a user installs one via gsd capability install <spec> it enters the runtime registry overlay (ADR-1244 D2); the overlay-aware view of what is installed on a given machine is gsd capability list (see the gsd capability command reference), which reports first-party and installed third-party capabilities together using the same column fields described below, with source = third-party.

Column values for third-party rows

Column Value
id As declared in capability.json. Must not use reserved prefixes (gsd-, gsd-core-, anthropic-).
role feature, runtime, or reviewer, as declared.
tier core, standard, or full, as declared.
engines.gsd Range from capability.json; verified at install and at each load.
extension points The loop points the capability registers into, validated against the known 12 identifiers.
hook kinds step, contribution, and/or gate as declared. Disclosed in the consent summary at install.
source third-party

Community registry

Whether GSD operates or advertises a central community registry of third-party capabilities is TBD/TBA (PRD). The matrix mechanic and all manifest fields ship regardless of that decision; URL/git/npm/tarball import does not depend on a central registry.


Manifest field reference

The fields below are defined in capability.json and govern how a capability appears in this matrix. For the full schema, see ADR-1244 D1 and the capability manifest reference.

Field Required Type Purpose
version Yes semver string Capability version. The registry rejects manifests without it.
engines.gsd Recommended semver range Host-version compatibility gate. Enforced at install and load.
compatVersions No object: cap-version → gsd-range Graceful-downgrade table for sources that enumerate versions (git tags, registry, npm).
integrity No sha512-<base64> SHA-512 digest of the fetched bundle. Verified before extraction when present; mismatch aborts.
provenance No { sourceRepo, commit } Source provenance; populated in CI for first-party/curated capabilities.