docs(skills): model-selection Composer / Grok / Kimi K3 only

Collapse the canonical table; bipartition for complex issues; drop
K2.7/Haiku/GLM/Gemini from the happy path.

.cursor/skills/agent-pool/SKILL.md

@@ -41,12 +41,13 @@ Os wrappers disparam `gh workflow run agent-pool.yml -f action=…`; acompanhe c
 
 ## Smoke remoto (aceite — rodar na primeira ativação)
 
-1. 2 Issues `kind:chore` triviais, `ready`, sem `model:` → `start --max-slots 2` → 2 agents `pool-i<N>-…` em cursor.com/agents e as 2 Issues `in-progress` com comentário de claim. Zero duplicata.
+1. 2 Issues `kind:chore` triviais, `ready`, sem `model:` → `start --max-slots 2` → 2 agents `pool-i<N>-…` em cursor.com/agents e as 2 Issues `in-progress` com comentário de claim. Zero duplicata. Modelo efetivo = `composer-2.5`.
 2. 1 Issue `blocked` e 1 `needs:consent` plantadas na fila → permanecem intactas.
 3. 1 Issue com `model: cursor-grok-4.5-high` → run criado com esse modelo (doctor lista os ids válidos).
-4. Workers abrem PRs `--base stage`; merge → slot reposto automaticamente no tick seguinte (≤10 min).
-5. Fila drenada → `POOL_ENABLED=false` sozinho. `stop` → próximo tick sem spawns.
-6. Tudo com o laptop desligado (start pelo browser/celular).
+4. (Opcional) par bipartido: Issue plan (`cursor-grok-4.5-high`) + Issue exec (`kimi-k3-low`, `depends` no plan) — o tick só spawna a exec quando o plan estiver `done`.
+5. Workers abrem PRs na base canônica do pool; merge → slot reposto automaticamente no tick seguinte (≤10 min).
+6. Fila drenada → `POOL_ENABLED=false` sozinho. `stop` → próximo tick sem spawns.
+7. Tudo com o laptop desligado (start pelo browser/celular).
 
 ## Se algo quebrar
 

.cursor/skills/model-selection/SKILL.md

@@ -3,67 +3,66 @@ name: model-selection
 description: >-
   Escolhe o modelo (e o nível de raciocínio/effort) com melhor custo/valor
   para cada classe de tarefa do Teqo, e despacha subagentes já no modelo certo
-  via o parâmetro `model` da tool Task. Usar no início de trabalho de
-  implementação, ao despachar subagentes, antes de passes de /simplify ou
-  auditoria, ou quando o usuário perguntar "qual modelo usar", "modelo mais
-  barato para X", "troca o modelo", "vale a pena effort high".
+  via o parâmetro `model` da tool Task. Caminho feliz único: Composer 2.5 ↔
+  Grok 4.5 (effort) ↔ Kimi K3 Low (exec bipartida). Usar no início de
+  implementação, ao despachar subagentes, antes de /simplify, ou quando o
+  usuário perguntar "qual modelo usar".
 ---
 
-# Seleção de modelo × effort por classe de tarefa
+# Seleção de modelo × effort
 
-Dois eixos independentes, decididos nesta ordem: **(1) classe da tarefa → modelo**, **(2) custo de uma falha → effort**. Preço e contexto compram capacidade; effort compra deliberação (tokens de thinking, cobrados como output). Esforço escala com **quanto custa errar**, não com o tamanho da tarefa.
+Dois eixos, nesta ordem: **(1) classe da tarefa → modelo**, **(2) custo de uma falha → effort**. Preço e contexto compram capacidade; effort compra deliberação.
 
-## Tabela canônica (atualizada 2026-07-29 — revalidar preços em cursor.com/docs/models-and-pricing antes de citar valores)
+## Tabela canônica (2026-07-31)
 
-| Classe de tarefa                                                                                      | Modelo (1ª escolha) | Fallback metered | Effort   |
-| ----------------------------------------------------------------------------------------------------- | ------------------- | ---------------- | -------- |
-| Feature delivery do roadmap (itens B/E/C, multi-arquivo, gates completos)                             | Composer 2.5 (pool) | Gemini 3.1 Pro   | Medium   |
-| Passes de /simplify, auditoria de plano, review debts (bugs sutis: closures, races, drift de strings) | Kimi K3 (1M ctx)    | Gemini 3.1 Pro   | **High** |
-| Migrations, access control / RBAC, Consent, segurança (blast radius alto, história congelada)         | Kimi K3             | Gemini 3.1 Pro   | **High** |
-| Fixes pequenos e localizados (um arquivo, sintoma conhecido, repair de teste)                         | Kimi K2.7           | Haiku 4.5        | Medium   |
-| Ciclos de discovery / research (compêndios, personas, relatórios longos em pt-BR — write-heavy)       | GLM 5.2             | Gemini 3.6 Flash | Medium   |
-| Docs/bookkeeping (planos, TECH-DEBT, débitos no backlog de Issues), Prettier, merges, rebase, chores | Grok 4.5 (pool)     | Kimi K2.7        | **Low**  |
-| Perf/infra (medição de bundle, waterfall, análise de queries)                                         | Gemini 3.1 Pro      | Composer 2.5     | Medium   |
-| Depuração travada ("horas sem progresso", bug intermitente com hipóteses esgotadas)                   | Kimi K3             | GPT-5.6 Luna     | **Max**  |
+| Prioridade | Modelo | Quando |
+| ---------- | ------ | ------ |
+| 1 (default) | **Composer 2.5** (`composer-2.5`, sem `-fast`) | Features, chores simples, fixes localizados, docs leves — sempre que couber |
+| 2 | **Grok 4.5** (`cursor-grok-4.5-*`) | Effort por complexidade (abaixo) |
+| 3 | **Kimi K3 Low** (`kimi-k3-low`) | Só na **fase de execução** de issues bipartidas (refactor grande / simplify / migrations+RBAC de blast radius alto), depois de um plano fechado |
+
+**Removidos** desta skill (não usar como 1ª escolha nem fallback documentado): Kimi K2.7, Haiku, GLM, Gemini, Luna. Se a API Cloud rejeitar um slug, o pool já faz fallback para `composer-2.5` no código — não documentar outros modelos aqui.
+
+### Effort (Grok 4.5)
+
+| Effort | Uso |
+| ------ | --- |
+| Low | Bookkeeping, Prettier, merges, rebase, chores mecânicos |
+| Medium | Discovery / análise moderada |
+| **High** | **Default para issues complexas** (multi-domínio, design não óbvio) |
+
+Slug Task de referência: `cursor-grok-4.5-high` (High). Para Low/Medium na sessão principal, use o seletor de modelo/effort do produto — o pool resolve o id da Issue via `resolvePoolModel`.
+
+## Issues muito complexas (bipartir)
+
+Quando o blast radius é alto (refactor amplo, simplify repo-wide, migration+RBAC), `plan-issue` **registra duas Issues encadeadas**:
+
+1. `{id}-plan` — `model: cursor-grok-4.5-high` — entregável = plano em `docs/plans/…` + critérios de aceite da execução
+2. `{id}` ou `{id}-exec` — `model: kimi-k3-low`, `depends: [{id}-plan]` — executa o plano
+
+Não despachar Kimi K3 Low sem plano fechado na Issue de plan.
 
 ## Regras
 
-1. **Pool primeiro.** Composer 2.5 e Grok 4.5 saem do pool "Cursor Models" (uso incluído generoso) — ~70% do trabalho deste repo é rotina e não deveria tocar o pool metered ("Other Models", cobrado a preço de API).
-2. **Kimi K3 é cirúrgico, não default.** Custa 3× o K2.7 no input e ~4× no output. Reservar para as três classes onde uma falha perdida vira bug de produção ou migration congelada errada. O 1M de contexto sem sobretaxa é o diferencial para auditorias repo-wide.
-3. **Effort default = Medium.** Subir para High só nas classes marcadas; Low em docs/formatação/merges; Max é exceção de depuração, nunca rotina. Em tarefa fácil, effort alto só reescreve o óbvio com tokens mais caros.
-4. **Nunca economizar em:** migrations (história congelada, aplicam em produção no build), access control (`overrideAccess: false`), Consent/LGPD, e passes de /simplify — o histórico do repo mostra que é neles que os P0/P1 sutis aparecem.
-5. **Metered barato ≠ grátis:** K2.7 ($0.95/$4) e Haiku 4.5 ($1/$5) consomem o pool "Other Models"; se a tarefa cabe num pool model, pool vence sempre.
+1. **Composer 2.5 é o default.** Se a tarefa cabe nele, não suba de modelo.
+2. **Grok High para complexidade**, não para volume mecânico.
+3. **Kimi K3 Low só na exec bipartida** (ou quando a Issue já declara `kimi-k3-low` após um plan).
+4. **Nunca economizar em:** migrations (história congelada), access control (`overrideAccess: false`), Consent/LGPD — se for uma Issue só disso e complexa, bipartir (plan Grok High → exec K3).
+5. **Usuário pediu modelo específico:** a escolha dele vence; avise uma vez se houver desperdício claro.
 
-## Como aplicar o modelo
+## Como aplicar
 
-- **Subagentes (automático):** a tool `Task` aceita `model`. Despache já no slug certo — não rode o subagente no modelo herdado e sugira troca depois:
-  - `composer-2.5` / `composer-2.5-fast` — features e rotina
-  - `cursor-grok-4.5-high` — docs, chores, exploração
-  - `gemini-3.1-pro` — fallback metered forte / perf
-  - `gemini-3.6-flash-high` — discovery write-heavy (fallback)
-  - `glm-5.2-high` — discovery/research
-  - `kimi-k2.7-code` — fixes pequenos
-  - `kimi-k3-low` — auditorias/simplify/migrations (única variante K3 disponível para subagentes; o raciocínio extra vem do modelo, não do effort knob aqui)
-  - `claude-4.5-haiku-thinking` / `gpt-5.6-luna-medium` — fallbacks de fix pequeno
-  - `inherit` só quando a classe do subagente é a mesma da sessão.
-- **Sessão principal (sugestão):** o agente não troca o próprio modelo. Ao classificar a tarefa no início do trabalho, se o modelo atual não for o da tabela, diga em uma linha: _"Esta tarefa é classe X — o melhor custo/valor é **Y** (effort Z); considere trocar no seletor de modelo."_ Não repita o aviso na mesma sessão.
-- **Usuário pediu modelo específico:** a escolha dele vence a tabela; use-a só para avisar uma vez se houver desperdício claro (ex.: K3 numa formatação Prettier).
+- **Subagentes (`Task.model`):** só estes slugs nesta skill:
+  - `composer-2.5`
+  - `cursor-grok-4.5-high`
+  - `kimi-k3-low`
+  - `inherit` só quando a classe do subagente é a mesma da sessão
+- **Sessão principal:** o agente não troca o próprio modelo. Se o atual não for o da tabela, diga em uma linha e siga.
+- **Pool:** `POOL_DEFAULT_MODEL_SLUG` = `composer-2.5`; `resolvePoolModel` cai para Composer se o slug da Issue for desconhecido.
 
-## Gates por fluxo (onde a decisão de modelo entra no loop)
+## Gates por fluxo
 
-- **`/simplify` (comando built-in, não editável):** seus três subagentes de review **herdam o modelo da sessão pai** — não há como despachá-los em outro modelo. Portanto a decisão acontece **antes** de invocar `/simplify`: se a sessão não estiver em Kimi K3 (effort High) ou Gemini 3.1 Pro, avise uma vez e sugira a troca — _"passes de /simplify são onde este repo acha os P0/P1 sutis; considere rodar em K3 High."_ Se o usuário optar por seguir no modelo barato, aceite — é escolha informada, não erro.
-- **`work-issue`:** a propriedade `model:` da Issue é **verificada, não recalculada** (regra assimétrica: sessão mais fraca → informa e segue; mais forte → informa e pausa). A classe pode mudar **por fase** — fases de schema/migration são High-effort (K3), fases de documentação da sessão são Low (pool model). Sessões longas: vale sugerir troca entre a fase de engenharia e a fase final de docs.
-- **`plan-issue`:** a sugestão de modelo × effort por item (esta tabela) vira a propriedade `model:` da Issue registrada via `agent:register --model`.
-- **`project-status`:** leitura + apresentação — classe docs/análise; pool model (Grok 4.5) ou metered barato bastam. O `model:` que ele exibe por item é para a **worktree de implementação**, não para a sessão de status.
-- **Discovery cycles (`docs/research/`):** write-heavy pt-BR — GLM 5.2 ou Gemini 3.6 Flash, Medium.
-
-## Quando o effort faz diferença (critério de decisão)
-
-Suba um degrau de effort quando **duas ou mais** forem verdade:
-
-- a falha é silenciosa (sem teste que a pegue — ex.: drift de string em `safeMessages`, race otimista);
-- a verificação exige rastrear um valor por 3+ frames/requests/renders;
-- o diff toca migration, access, ou hook com `req`/transação;
-- a tarefa é "provar ausência" (auditoria, knip, ciclos) e não "produzir presença".
-
-Desça um degrau quando a saída é mecânica (formatar, renomear, registrar débito, resolver merge trivial) ou quando já existe gate que pega o erro (tsc/lint/teste pinado cobre exatamente o risco).
+- **`/simplify`:** herda o modelo da sessão. Preferir sessão em Kimi K3 Low **só** quando houver Issue de exec bipartida; caso contrário Composer ou Grok High conforme complexidade.
+- **`work-issue`:** verifica `model:` da Issue (assimétrico: sessão mais fraca → informa e segue; mais forte → informa e pausa). Ausente → aplica esta tabela.
+- **`plan-issue`:** sugere via esta tabela; em issues muito complexas, registra o par plan/exec.
+- **`agent-pool` smoke:** Composer default; Grok High / Kimi K3 Low em Issues de teste bipartidas.

.cursor/skills/plan-issue/SKILL.md

@@ -58,7 +58,13 @@ Ordem topológica intra-lote (o plano do dependente cita o ID do dependido, que
 
 ## Passo 4 — Sugestão de modelo × effort
 
-Aplique a skill `model-selection` (tabela canônica) por item e registre a sugestão no cabeçalho do plano (`Model:`) e no resumo do gate. Referência rápida: `kimi-k3-low` para migration/RBAC/escala-dry; `composer-2.5` para feature UI; `cursor-grok-4.5-high` para docs/chore. O valor vai ao frontmatter `model:` da Issue — é **propriedade da Issue**, verificada (não recalculada) na execução por `work-issue`.
+Aplique a skill `model-selection` (tabela canônica) por item e registre a sugestão no cabeçalho do plano (`Model:`) e no resumo do gate. Caminho feliz único:
+
+- `composer-2.5` — default (features, chores simples, fixes localizados, docs leves)
+- `cursor-grok-4.5-high` — issues complexas / discovery (effort High); Low/Medium via seletor para bookkeeping
+- `kimi-k3-low` — **só** fase de execução de issues bipartidas (refactor / simplify / migration+RBAC de blast radius alto)
+
+**Issues muito complexas:** registre **duas** Issues encadeadas — `{id}-plan` (`model: cursor-grok-4.5-high`, entregável = plano + critérios de aceite) e `{id}`/`{id}-exec` (`model: kimi-k3-low`, `depends: [{id}-plan]`). O valor vai ao frontmatter `model:` — propriedade da Issue, verificada (não recalculada) por `work-issue`.
 
 ## Passo 5 — GATE de confirmação (obrigatório)
 

.cursor/skills/plan-issue/plan-template.md

@@ -12,7 +12,7 @@ Status: rascunho
 Atualizado em: <YYYY-MM-DD>
 Issue: #<N> (preencher após `pnpm agent:register`; enquanto não registrado: "—")
 Priority: <P0 | P1 | P2 | P3>
-Model: <slug sugerido por model-selection, ex.: composer-2.5>
+Model: <slug sugerido por model-selection: composer-2.5 | cursor-grok-4.5-high | kimi-k3-low>
 Impeccable: <A | B | C | D> — <uma linha: N/A sem UI | encaixe em tela X | UI nova em rota Y | ref Nome.png>
 Appetite: <ex.: ~1–2 dias eng; migration + 1 action + encaixe em lista existente>
 Responsável: —

.cursor/skills/work-issue/SKILL.md

@@ -92,13 +92,14 @@ Se `open_resource` não estiver disponível (fora da Agents Window), diga o cami
 
 ## Passo 2 — Verificação de modelo (best effort, não programática)
 
-Leia a propriedade `model:` do brief e compare com o modelo da sessão atual pela tabela de capacidade de `model-selection`. Regra **assimétrica** (decisão travada 2026-07-30):
+Leia a propriedade `model:` do brief e compare com o modelo da sessão atual pela tabela de capacidade de `model-selection` (Composer 2.5 ↔ Grok 4.5 ↔ Kimi K3 Low). Regra **assimétrica** (decisão travada 2026-07-30):
 
 - Sessão **mais fraca** que o especificado → assume-se escolha consciente do humano: **informa em uma linha e continua, sem pausar**.
 - Sessão **mais forte** que o especificado → possível erro do humano: **informa e pausa** ("a Issue pede X, você está em Y — seguir mesmo assim?").
 - Propriedade **ausente** → aplique `model-selection` uma vez e registre a escolha na Issue (`gh issue edit <N>` no body, frontmatter `model:`).
+- Issue `{id}-exec` / `kimi-k3-low` sem a dep de plan `done` → **pare** (não execute sem plano fechado).
 
-Subagentes despachados via `Task` saem **no modelo da propriedade** quando couber (`Task.model`).
+Subagentes despachados via `Task` saem **no modelo da propriedade** quando couber (`Task.model` ∈ `composer-2.5` | `cursor-grok-4.5-high` | `kimi-k3-low`).
 
 ## Passo 3 — Freshness audit (enxuto)