Files

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

19 KiB

Raw Blame History

Referência de Ferramentas CLI do GSD

Referência para o CLI gsd-tools (gsd-core/bin/gsd-tools.cjs). Para comandos slash e fluxos de usuário, consulte a Referência de Comandos. Voltar ao índice de documentação.

Visão Geral

gsd-tools.cjs centraliza a análise de configuração, resolução de modelos, busca de fases, commits git, verificação de resumos, gerenciamento de estado e operações de templates em comandos, fluxos de trabalho e agentes do GSD.


Caminho instalado	`gsd-core/bin/gsd-tools.cjs`
Implementação	20 módulos de domínio em `gsd-core/bin/lib/` (o diretório é autoritativo)
Status	Principal superfície de comandos em tempo de execução para orquestração, fluxos de trabalho e automação.

Uso (CJS):

node gsd-tools.cjs <command> [args] [--raw] [--cwd <path>]

Flags globais (CJS):

Flag	Descrição
`--raw`	Saída legível por máquina (JSON ou texto simples, sem formatação)
`--cwd <path>`	Substitui o diretório de trabalho (para subagentes em sandbox)
`--ws <name>`	Contexto de fluxo de trabalho para caminhos `.planning/workstreams/<name>`

Comandos de Estado

Gerencia .planning/STATE.md — a memória viva do projeto.

# Carrega configuração completa do projeto + estado como JSON
node gsd-tools.cjs state load

# Exibe o frontmatter do STATE.md como JSON
node gsd-tools.cjs state json

# Atualiza um único campo
node gsd-tools.cjs state update <field> <value>

# Obtém o conteúdo do STATE.md ou uma seção específica
node gsd-tools.cjs state get [section]

# Atualiza múltiplos campos em lote
node gsd-tools.cjs state patch --field1 val1 --field2 val2

# Incrementa o contador de planos
node gsd-tools.cjs state advance-plan

# Registra métricas de execução
node gsd-tools.cjs state record-metric --phase N --plan M --duration Xmin [--tasks N] [--files N]

# Recalcula a barra de progresso
node gsd-tools.cjs state update-progress

# Adiciona uma decisão
node gsd-tools.cjs state add-decision --summary "..." [--phase N] [--rationale "..."]
# Ou a partir de arquivos:
node gsd-tools.cjs state add-decision --summary-file path [--rationale-file path]

# Adiciona/resolve bloqueadores
node gsd-tools.cjs state add-blocker --text "..."
node gsd-tools.cjs state resolve-blocker --text "..."

# Registra continuidade da sessão
node gsd-tools.cjs state record-session --stopped-at "..." [--resume-file path]

# Início de fase — atualiza Status/Última atividade do STATE.md para uma nova fase
node gsd-tools.cjs state begin-phase --phase N --name SLUG --plans COUNT

# Sinalização de bloqueador detectável por agentes (usado por discuss-phase / fluxos de UI)
node gsd-tools.cjs state signal-waiting --type TYPE --question "..." --options "A|B" --phase P
node gsd-tools.cjs state signal-resume

Snapshot de Estado

Análise estruturada do STATE.md completo:

node gsd-tools.cjs state-snapshot

Retorna JSON com: posição atual, fase, plano, status, decisões, bloqueadores, métricas, última atividade.

Comandos de Fase

Gerencia fases — diretórios, numeração e sincronização com o roadmap.

# Localiza diretório de fase pelo número
node gsd-tools.cjs find-phase <phase>

# Calcula o próximo número de fase decimal para inserções
node gsd-tools.cjs phase next-decimal <phase>

# Adiciona nova fase ao roadmap + cria diretório
node gsd-tools.cjs phase add <description>

# Insere fase decimal após a existente
node gsd-tools.cjs phase insert <after> <description>

# Remove fase, renumera as subsequentes
node gsd-tools.cjs phase remove <phase> [--force]

# Marca a fase como concluída, atualiza estado + roadmap
node gsd-tools.cjs phase complete <phase>

# Indexa planos com ondas e status
node gsd-tools.cjs phase-plan-index <phase>

# Lista fases com filtragem
node gsd-tools.cjs phases list [--type planned|executed|all] [--phase N] [--include-archived]

Comandos de Roadmap

Analisa e atualiza o ROADMAP.md.

# Extrai a seção de fase do ROADMAP.md
node gsd-tools.cjs roadmap get-phase <phase>

# Análise completa do roadmap com status em disco
node gsd-tools.cjs roadmap analyze

# Atualiza linha da tabela de progresso a partir do disco
node gsd-tools.cjs roadmap update-plan-progress <N>

Comandos de Configuração

Lê e grava em .planning/config.json.

# Inicializa config.json com valores padrão
node gsd-tools.cjs config-ensure-section

# Define um valor de configuração (notação de ponto)
node gsd-tools.cjs config-set <key> <value>

# Obtém um valor de configuração
node gsd-tools.cjs config-get <key>

# Define o perfil de modelo
node gsd-tools.cjs config-set-model-profile <profile>

Resolução de Modelos

# Obtém o modelo para um agente com base no perfil atual
node gsd-tools.cjs resolve-model <agent-name>
# A saída bruta retorna o ID/tier do modelo selecionado.
# A saída JSON também inclui o perfil e, quando o runtime ativo suporta,
# reasoning_effort.

Nomes de agentes: gsd-planner, gsd-executor, gsd-phase-researcher, gsd-project-researcher, gsd-research-synthesizer, gsd-verifier, gsd-plan-checker, gsd-integration-checker, gsd-roadmapper, gsd-debugger, gsd-codebase-mapper, gsd-nyquist-auditor

Comandos de Verificação

Valida planos, fases, referências e commits.

# Verifica arquivo SUMMARY.md
node gsd-tools.cjs verify-summary <path> [--check-count N]

# Verifica estrutura + tarefas do PLAN.md
node gsd-tools.cjs verify plan-structure <file>

# Verifica se todos os planos têm resumos
node gsd-tools.cjs verify phase-completeness <phase>

# Verifica se @-refs + caminhos resolvem
node gsd-tools.cjs verify references <file>

# Verifica hashes de commit em lote
node gsd-tools.cjs verify commits <hash1> [hash2] ...

# Verifica must_haves.artifacts
node gsd-tools.cjs verify artifacts <plan-file>

# Verifica must_haves.key_links
node gsd-tools.cjs verify key-links <plan-file>

Comandos de Validação

Verifica a integridade do projeto.

# Verifica numeração de fases, sincronização disco/roadmap
node gsd-tools.cjs validate consistency

# Verifica integridade de .planning/, com opção de reparo
node gsd-tools.cjs validate health [--repair]

# Verifica utilização da janela de contexto para linha de status / chamadores de hook (v1.40.0)
node gsd-tools.cjs validate context

# Utilização de contexto como superfície JSON tipada (#455)
node gsd-tools.cjs validate context --json

validate context emite um envelope estruturado com utilization, status (ok / warn / critical nos limites de 60% / 70%), e uma string suggestion. Os mesmos dados sustentam /gsd-health --context. Passe --json para receber o IR tipado diretamente (útil em scripts e asserções de teste).

Comandos de Template

Seleção e preenchimento de templates.

# Seleciona o template de resumo com base na granularidade
node gsd-tools.cjs template select <type>

# Preenche o template com variáveis
node gsd-tools.cjs template fill <type> --phase N [--plan M] [--name "..."] [--type execute|tdd] [--wave N] [--fields '{json}']

Tipos de template para fill: summary, plan, verification

Comandos de Frontmatter

Operações CRUD de frontmatter YAML em qualquer arquivo Markdown.

# Extrai frontmatter como JSON
node gsd-tools.cjs frontmatter get <file> [--field key]

# Atualiza único campo
node gsd-tools.cjs frontmatter set <file> --field key --value jsonVal

# Mescla JSON no frontmatter
node gsd-tools.cjs frontmatter merge <file> --data '{json}'

# Valida campos obrigatórios
node gsd-tools.cjs frontmatter validate <file> --schema plan|summary|verification

Comandos de Scaffold

Cria arquivos e diretórios pré-estruturados.

# Cria template CONTEXT.md
node gsd-tools.cjs scaffold context --phase N

# Cria template UAT.md
node gsd-tools.cjs scaffold uat --phase N

# Cria template VERIFICATION.md
node gsd-tools.cjs scaffold verification --phase N

# Cria diretório de fase
node gsd-tools.cjs scaffold phase-dir --phase N --name "phase name"

Comandos Init (Carregamento de Contexto Composto)

Carrega todo o contexto necessário para um fluxo de trabalho específico em uma única chamada. Retorna JSON com informações do projeto, configuração, estado e dados específicos do fluxo de trabalho. init onboard [--fast] [--text] retorna, para /gsd-onboard, sinais de brownfield, candidatos a docs de planning, completude do mapa de código, prontidão do mapa fast, roteamento em modo texto, estado parcial de planning e status do resumo de onboarding.

node gsd-tools.cjs init execute-phase <phase>
node gsd-tools.cjs init plan-phase <phase>
node gsd-tools.cjs init new-project
node gsd-tools.cjs init new-milestone
node gsd-tools.cjs init onboard [--fast] [--text]
node gsd-tools.cjs init quick <description>
node gsd-tools.cjs init resume
node gsd-tools.cjs init verify-work <phase>
node gsd-tools.cjs init phase-op <phase>
node gsd-tools.cjs init todos [area]
node gsd-tools.cjs init milestone-op
node gsd-tools.cjs init map-codebase
node gsd-tools.cjs init progress

# Init com escopo de fluxo de trabalho (flag `--ws`)
node gsd-tools.cjs init execute-phase <phase> --ws <name>
node gsd-tools.cjs init plan-phase <phase> --ws <name>

Tratamento de payloads grandes: Quando a saída excede ~50KB, o CLI grava em um arquivo temporário e retorna @file:/tmp/gsd-init-XXXXX.json. Os fluxos de trabalho verificam o prefixo @file: e leem do disco:

INIT=$(node gsd-tools.cjs init execute-phase "1")
if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi

Comandos de Milestone

# Arquiva milestone
node gsd-tools.cjs milestone complete <version> (--confirm | --dry-run) [--name <name>] [--no-archive-phases] [--force] [--archive-quick]

# Marca requisitos como concluídos
node gsd-tools.cjs requirements mark-complete <ids>
# Aceita: REQ-01,REQ-02 ou REQ-01 REQ-02 ou [REQ-01, REQ-02]

Habilidades de Agente

Emite o bloco de habilidades para um tipo de agente específico.

# Emite bloco XML bruto de habilidades (padrão — seguro para expansão de shell)
node gsd-tools.cjs agent-skills <agent-type>

# Emite superfície JSON tipada (#455) — { agent_type, block, skills_count }
node gsd-tools.cjs agent-skills <agent-type> --json

A flag --json retorna um objeto IR tipado adequado para consumo estruturado e asserções de teste, enquanto o padrão (sem flag) preserva a saída XML bruta que as expansões de shell de fluxo de trabalho necessitam.

Manifesto de Habilidades

Pré-computa e armazena em cache a descoberta de habilidades para carregamento mais rápido de comandos.

# Gera manifesto de habilidades (grava em .claude/skill-manifest.json)
node gsd-tools.cjs skill-manifest

# Gera com caminho de saída personalizado
node gsd-tools.cjs skill-manifest --output <path>

Retorna mapeamento JSON de todas as habilidades GSD disponíveis com seus metadados (nome, descrição, caminho de arquivo, dicas de argumentos). Usado pelo instalador e hooks de início de sessão para evitar varreduras repetidas do sistema de arquivos.

Comandos Utilitários

# Converte texto em slug seguro para URL
node gsd-tools.cjs generate-slug "Some Text Here"
# → some-text-here

# Obtém timestamp
node gsd-tools.cjs current-timestamp [full|date|filename]

# Conta e lista tarefas pendentes
node gsd-tools.cjs list-todos [area]

# Verifica existência de arquivo/diretório
node gsd-tools.cjs verify-path-exists <path>

# Agrega todos os dados de SUMMARY.md
node gsd-tools.cjs history-digest

# Extrai dados estruturados de SUMMARY.md
node gsd-tools.cjs summary-extract <path> [--fields field1,field2]

# Estatísticas do projeto
node gsd-tools.cjs stats [json|table]

# Renderização de progresso (legível por humanos)
node gsd-tools.cjs progress [json|table|bar]

# Progresso como superfície JSON tipada (#455)
node gsd-tools.cjs progress --json

# Conclui uma tarefa
node gsd-tools.cjs todo complete <filename> [--dry-run]

# Auditoria UAT — verifica todas as fases em busca de itens não resolvidos
node gsd-tools.cjs audit-uat

# Fila de auditoria entre artefatos — verifica `.planning/` em busca de itens de auditoria não resolvidos
node gsd-tools.cjs audit-open [--json]

# Migração reversa de um projeto GSD-2 para a estrutura atual (suporta `/gsd-import --from-gsd2`)
node gsd-tools.cjs from-gsd2 [--path <dir>] [--force] [--dry-run]

# Commit git com verificações de configuração
node gsd-tools.cjs commit <message> [--files f1 f2] [--amend] [--no-verify] [--respect-staged]

--no-verify: Ignora hooks de pré-commit. Usado por agentes executores paralelos durante a execução baseada em ondas para evitar contenção de bloqueio de build (ex.: conflitos de cargo lock em projetos Rust). O orquestrador executa os hooks uma vez após cada onda ser concluída. Não use --no-verify durante a execução sequencial — deixe os hooks rodarem normalmente. --files <paths> comportamento de staging: por padrão, --files executa git add -- <path> para cada arquivo nomeado antes de commitar. Isso sobrescreve qualquer staging por hunk configurado via git add -p. Passe --respect-staged para ignorar o passo git add e commitar apenas o que já está no índice dentro do pathspec solicitado. Se nada estiver staged nesse escopo, o comando retorna { committed: false, reason: 'nothing staged' } sem erro. O -- <paths> pathspec final no commit é aplicado em ambos os modos, portanto arquivos staged fora do escopo --files nunca são incluídos (invariante #3061).

# Busca na web (requer chave de API do Brave)
node gsd-tools.cjs websearch <query> [--limit N] [--freshness day|week|month]

Graphify

Constrói, consulta e inspeciona o grafo de conhecimento do projeto em .planning/graphs/. Requer graphify.enabled: true em config.json (consulte a Referência de Configuração).

# Constrói ou reconstrói o grafo de conhecimento
node gsd-tools.cjs graphify build

# Pesquisa um termo no grafo
node gsd-tools.cjs graphify query <term>

# Exibe atualidade e estatísticas do grafo
node gsd-tools.cjs graphify status

# Exibe alterações desde a última construção
node gsd-tools.cjs graphify diff

# Grava um snapshot nomeado do grafo atual
node gsd-tools.cjs graphify snapshot [name]

Ponto de entrada para o usuário: /gsd-graphify (consulte a Referência de Comandos).

Arquitetura de Módulos

Módulo	Arquivo	Exportações
Core	`lib/core.cjs`	`error()`, `output()`, `parseArgs()`, utilitários compartilhados, re-exportações de compatibilidade
State	`lib/state.cjs`	Todos os subcomandos `state`, `state-snapshot`
Phase	`lib/phase.cjs`	CRUD de fase, `find-phase`, `phase-plan-index`, `phases list`
Planning Workspace	`lib/planning-workspace.cjs`	Costura de planejamento: `planningDir`, `planningPaths`, roteamento de fluxo de trabalho ativo, `.planning/.lock`
Roadmap	`lib/roadmap.cjs`	Análise de roadmap, extração de fase, atualizações de progresso
Config	`lib/config.cjs`	Leitura/gravação de configuração, inicialização de seção
Verify	`lib/verify.cjs`	Todos os comandos de verificação e validação
Template	`lib/template.cjs`	Seleção de template e preenchimento de variáveis
Frontmatter	`lib/frontmatter.cjs`	CRUD de frontmatter YAML
Init	`lib/init.cjs`	Carregamento de contexto composto para todos os fluxos de trabalho
Milestone	`lib/milestone.cjs`	Arquivamento de milestone, marcação de requisitos
Commands	`lib/commands.cjs`	Diversos: slug, timestamp, todos, scaffold, stats, websearch
Model Profiles	`lib/model-profiles.cjs`	Tabela de resolução de perfis
UAT	`lib/uat.cjs`	Auditoria UAT/verificação entre fases
Profile Output	`lib/profile-output.cjs`	Formatação de perfil do desenvolvedor
Profile Pipeline	`lib/profile-pipeline.cjs`	Pipeline de análise de sessão
Graphify	`lib/graphify.cjs`	Construção/consulta/status/diff/snapshot do grafo de conhecimento (suporta `/gsd-graphify`)
Learnings	`lib/learnings.cjs`	Extrai aprendizados de artefatos de fases/SUMMARY (suporta `/gsd-extract-learnings`)
Audit	`lib/audit.cjs`	Manipuladores de fila de auditoria de fase/milestone; helper `audit-open`
GSD2 Import	`lib/gsd2-import.cjs`	Importador de migração reversa de projetos GSD-2 (suporta `/gsd-import --from-gsd2`)
Intel	`lib/intel.cjs`	Índice de inteligência de código consultável (suporta `/gsd-map-codebase --query`)

Roteamento CLI do Revisor

review.models.<cli> mapeia um sabor de revisor para um comando shell invocado pelo fluxo de trabalho de revisão de código. Defina via /gsd-config --integrations ou diretamente:

node gsd-tools.cjs config-set review.models.codex    "codex exec --model gpt-5"
node gsd-tools.cjs config-set review.models.agy      "gemini-3.1-pro-preview"
node gsd-tools.cjs config-set review.models.opencode "opencode run --model claude-sonnet-4"
node gsd-tools.cjs config-set review.models.claude   ""   # limpa — retorna ao modelo da sessão

Os slugs são validados contra [a-zA-Z0-9_-]+; slugs vazios ou contendo caminhos são rejeitados. Consulte docs/CONFIGURATION.md para a referência completa do campo.

Tratamento de Segredos

As chaves de API configuradas via /gsd-settings (brave_search, firecrawl, exa_search) são gravadas em texto simples em .planning/config.json, mas são mascaradas (****<last-4>) em toda saída de config-set / config-get, tabela de confirmação e prompt interativo. Consulte gsd-core/bin/lib/secrets.cjs para a implementação do mascaramento. O próprio arquivo config.json é o limite de segurança — proteja-o com permissões do sistema de arquivos e mantenha-o fora do git (.planning/ está no gitignore por padrão).

19 KiB Raw Blame History