From 4d097cd5c663aecc078a7912aa7bed11d9dc1245 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Francisco=20Ign=C3=A1cio=20Fontoura=20Solla?= Date: Thu, 30 Jul 2026 12:22:06 -0300 Subject: [PATCH] chore: delete legacy skills --- .cursor/rules/projects/emendas-mandato.mdc | 2 +- .cursor/rules/projects/financas-campanha.mdc | 2 +- .cursor/skills/capture-review-debts/SKILL.md | 50 ++++++++++---------- .cursor/skills/engineering-audit/SKILL.md | 32 +++++++++---- .cursor/skills/model-selection/SKILL.md | 8 ++-- .cursor/skills/rebase-on-main/SKILL.md | 13 +++-- docs/IMPROVE-CODE-QUALITY-PLAN.md | 2 +- 7 files changed, 60 insertions(+), 49 deletions(-) diff --git a/.cursor/rules/projects/emendas-mandato.mdc b/.cursor/rules/projects/emendas-mandato.mdc index 4c65fc26..932a00b9 100644 --- a/.cursor/rules/projects/emendas-mandato.mdc +++ b/.cursor/rules/projects/emendas-mandato.mdc @@ -23,7 +23,7 @@ Sem contabilidade de contrapartida eleitoral; sem registro da negociação polí ## Threads abertas 1. **Agendar a entrevista real** com a pessoa do gabinete que mantém a planilha de emendas. Roteiro pronto: [`roteiro-entrevista-emendas-responsavel-real.md`](../../../docs/research/roteiro-entrevista-emendas-responsavel-real.md). Preparação obrigatória ANTES: levantar as emendas reais do mandato (Portal da Transparência por autor + Painel SIOP + painel TCU, impresso), reler §§2/9/10 do relatório, levar a linha do tempo do ciclo (janela de saneamento 22–31/08; alteração 22–31/10; justificativas até 20/01), checar se o mandato usa o app do FNS, combinar enquadramento com o coordenador-geral SEM contaminar (não contar as respostas dele). -2. **Pós-entrevista:** preencher Interview Evidence + Snapshot em `docs/CUSTOMER.md`, veredito por aposta no §9 do relatório (14 apostas), e decidir abrir/adiar/matar as verticais. Condições de vida/morte já fixadas no §9 do relatório. Se abrir: registrar itens via skill `roadmap-items` a partir do OST draft (OE1–OE10) e passar o desenho do registro (3 andares + anti-goals) pela revisão do advogado antes de qualquer schema. +2. **Pós-entrevista:** preencher Interview Evidence + Snapshot em `docs/CUSTOMER.md`, veredito por aposta no §9 do relatório (14 apostas), e decidir abrir/adiar/matar as verticais. Condições de vida/morte já fixadas no §9 do relatório. Se abrir: registrar itens via skill `plan-issue` a partir do OST draft (OE1–OE10) e passar o desenho do registro (3 andares + anti-goals) pela revisão do advogado antes de qualquer schema. 3. Itens do compêndio marcados **[VERIFICar]** (ex.: defasagens exatas de SIGA/TransfereGov, data da API REST do TransfereGov) — confirmar com a pessoa real/documentação quando a trilha abrir. 4. **Sinergia com o ciclo 2 (finanças):** a entrevista real de finanças é 2026-07-29; se a trilha financeira abrir, o "compromisso com contrapartida = entrega física" de lá e o registro de compromisso territorial daqui (OE1) tocam o mesmo objeto — não criar dois registros de compromisso. diff --git a/.cursor/rules/projects/financas-campanha.mdc b/.cursor/rules/projects/financas-campanha.mdc index e38ec391..252069e4 100644 --- a/.cursor/rules/projects/financas-campanha.mdc +++ b/.cursor/rules/projects/financas-campanha.mdc @@ -32,7 +32,7 @@ Res. TSE 23.607/2019 + **23.752/2026**; Conta+JE substitui SPCE (cruzamento em t ## Threads abertas 1. **Entrevista real com a gestora financeira — 2026-07-29 (amanhã).** Roteiro pronto em `docs/research/roteiro-entrevista-gestora-financeira-real.md`. Preparação obrigatória do entrevistador ANTES da sessão: ler a prestação de contas 2022 do candidato no DivulgaCandContas (levar impressa), reler §§2–3 e 9–10 do relatório, levar a linha do tempo financeira 2026, checar se o critério do PT (PJe 0601252-72.2026.6.00.0000) já está público. -2. **Pós-entrevista:** preencher Interview Evidence + Snapshot em `docs/CUSTOMER.md`, veredito por aposta no §9 do relatório, e decidir abrir/adiar/matar a trilha. Se abrir, registrar itens via skill `roadmap-items` a partir do OST draft (OF1–OF8) e passar a spec do "registro seguro" pela revisão do advogado da campanha; os P0 podem entrar independentemente da trilha. +2. **Pós-entrevista:** preencher Interview Evidence + Snapshot em `docs/CUSTOMER.md`, veredito por aposta no §9 do relatório, e decidir abrir/adiar/matar a trilha. Se abrir, registrar itens via skill `plan-issue` a partir do OST draft (OF1–OF8) e passar a spec do "registro seguro" pela revisão do advogado da campanha; os P0 podem entrar independentemente da trilha. 3. Itens do compêndio marcados **[VERIFICAR]** (ex.: data exata da distribuição das cotas de gênero/raça em 2026) — confirmar com contador/advogado reais. ## Links diff --git a/.cursor/skills/capture-review-debts/SKILL.md b/.cursor/skills/capture-review-debts/SKILL.md index a11c31dc..c834c85c 100644 --- a/.cursor/skills/capture-review-debts/SKILL.md +++ b/.cursor/skills/capture-review-debts/SKILL.md @@ -1,27 +1,25 @@ --- name: capture-review-debts -description: Use when the user asks to register leftover /simplify or /impeccable findings on the Teqo roadmap, harvest session review debts, triage post-simplify or post-critique follow-ups, or says "registra os débitos", "o que ficou do simplify", "coloca no roadmap o que o critique apontou", "harvest debts". +description: Use when the user asks to register leftover /simplify or /impeccable findings as trackable GitHub Issues, harvest session review debts, triage post-simplify or post-critique follow-ups, or says "registra os débitos", "o que ficou do simplify", "coloca como issue o que o critique apontou", "harvest debts". --- -# Capturar débitos de /simplify e /impeccable no roadmap +# Capturar débitos de /simplify e /impeccable em Issues -Após um ciclo de entrega, `/simplify` e `/impeccable` deixam achados **maiores que o cleanup da sessão**. Esta skill **triageia** esses achados a partir do contexto da sessão, decide o que vira roadmap (e o que não), **mescla** o que for do mesmo lote, e só então registra via **`roadmap-item`**. Não implementa código. +Após um ciclo de entrega, `/simplify` e `/impeccable` deixam achados **maiores que o cleanup da sessão**. Esta skill **triageia** esses achados a partir do contexto da sessão, decide o que vira Issue rastreável (e o que não), **mescla** o que for do mesmo lote, e só então registra via **`pnpm agent:register`** (lotes `kind:chore|defect`, com plano curto em `docs/plans/` quando score ≥3) ou **`pnpm agent:file-miss`** (`kind:agent-miss`, défice comportamental do fluxo de agentes). Não implementa código. -**REQUIRED SUB-SKILL:** Use `roadmap-item` para qualquer inclusão/absorção no `docs/roadmap.md` + `docs/plans/`. Nunca edite roadmap/planos ad hoc neste fluxo. +**Regra inviolável — nunca editar Issue `in-progress`.** Nem para absorver um débito do mesmo pai: registra como **Issue nova** com `depends: []` no frontmatter — assim ela destrava sozinha na fila quando o pai flipar `done` — ou defer com gatilho. Editar a Issue que um agente está executando é esquecimento/conflito garantido. -Precedente canônico: um plano `escala-dry-pos-*` (engenharia pós-simplify) e/ou um plano UX pós-critique (ex.: FD+ vs FD2) — tipos **separados**, fases internas mescladas. - -**Qualidade de decisão:** [decision-quality.md](../roadmap-item/decision-quality.md) — caro vs barato, defer+gatilho, depth/YAGNI. Score sozinho não basta: classifique o **tipo de decisão** na triage. Sem tour de fases. +**Qualidade de decisão:** [decision-quality.md](../plan-issue/decision-quality.md) — caro vs barato, defer+gatilho, depth/YAGNI. Score sozinho não basta: classifique o **tipo de decisão** na triage. Sem tour de fases. ## Checklist ``` - [ ] 1. Colher candidatos da sessão (simplify + impeccable) -- [ ] 2. Deduplicar contra código, roadmap e planos +- [ ] 2. Deduplicar contra código, Issues (gh issue list) e planos - [ ] 3. Pontuar importância e classificar destino - [ ] 4. Mesclar relacionados (mesmo lote / mesma superfície) - [ ] 5. Apresentar tabela de triage e obter confirmação -- [ ] 6. Registrar só o aprovado via roadmap-item (1 invocação por item/plano) +- [ ] 6. Registrar só o aprovado (agent:register / agent:file-miss; plano curto quando score ≥3) ``` ## Passo 1 — Colher candidatos @@ -52,7 +50,7 @@ Contra o repositório **antes** de pontuar: | Check | Ação se verdadeiro | | ------------------------------------------------------ | --------------------------------------------------------------- | | Já no diff / código da sessão | → balde **já_resolvido** (não reabrir) | -| Já em `docs/plans/*.md` ou roadmap (grep termos/paths) | → **absorver** no plano existente ou **descartar** como coberto | +| Já em `docs/plans/*.md` ou numa Issue (grep + `gh issue list`) | → **absorver** no plano existente ou **descartar** como coberto | | Pré-existente em `main`, fora do escopo da entrega | → **descartar** deste lote (bug separado só se o usuário pedir) | | Intentional em `DESIGN.md` / decisão travada | → **descartar** (ex.: field-mode mobile documentado) | @@ -93,21 +91,21 @@ Preferir **defer+gatilho** a **registrar** para DRY prematuro — alinha a YAGNI **Separação de tipos (não misturar num único plano):** - **Engenharia / escala / DRY** → família `escala-dry-pos-.md`, IDs tipo `A7`, `C11`, `FD+`, `RS+`, `O0+` (fill-in ou próximo ID da trilha). -- **UX / produto pós-critique** → plano tipo `*-ux-pos-critique.md` ou fases num FD2 existente (`Impeccable: B|C|D` no `roadmap-item`). +- **UX / produto pós-critique** → plano tipo `*-ux-pos-critique.md` ou fases num FD2 existente (`Impeccable: B|C|D` no registro via `plan-issue`). - Nunca fundir N+1 SQL com "glossário de engajado" no mesmo item (precedente FD+ ≠ FD2). - Nunca fundir **expensive_lock** com **cheap_polish** no mesmo lote sem fases ordenadas (lock primeiro). -**Impeccable no registro:** ao chamar `roadmap-item`, a classificação A–D dele vale — débitos só-backend são **A**; UX pós-critique são **B** (encaixe) ou **C** se fluxo novo. +**Impeccable no registro:** a classificação A–D de `plan-issue` vale — débitos só-backend são **A**; UX pós-critique são **B** (encaixe) ou **C** se fluxo novo. ## Passo 4 — Mesclar Dentro do **mesmo tipo** (engenharia **ou** UX): -- Mesclar se compartilham **superfície** (mesma rota/loader/shell) **ou** **pai** (mesmo item do roadmap que acabou de ser entregue). +- Mesclar se compartilham **superfície** (mesma rota/loader/shell) **ou** **pai** (mesma Issue que acabou de ser entregue). - Um plano, várias **fases** ordenadas por ROI (expensive_lock / perf/access antes de DRY cosmético; P2 produto antes de P3 motion). -- Declarar **appetite** do lote (ex. `~1 dia eng fill-in`) para o `roadmap-item` não virar epic sem teto. +- Declarar **appetite** do lote (ex. `~1 dia eng fill-in`) para a Issue não virar epic sem teto. - Não mesclar across pais não relacionados (débito do C3 com débito do reset de senha → dois itens). -- Se sobrar um único achado score ≥3, ainda assim um plano curto é melhor que linha órfã no roadmap sem plano. +- Se sobrar um único achado score ≥3, ainda assim um plano curto é melhor que Issue órfã sem plano. Alvo de merge: **1 plano engenharia + no máximo 1 plano UX** por sessão de entrega, salvo pais distintos. @@ -126,31 +124,31 @@ Mostre ao usuário **antes** de editar docs: Inclua baldes **já_resolvido**, **descartar** e **defer** com uma linha de racional/gatilho cada (transparência > silêncio). -**Pare e confirme.** Só avance ao Passo 6 com aprovação explícita (ou ajuste pedido). Sem confirmação = não toca `docs/roadmap.md` / `docs/plans/`. +**Pare e confirme.** Só avance ao Passo 6 com aprovação explícita (ou ajuste pedido). Sem confirmação = não cria Issue nem toca `docs/plans/`. -## Passo 6 — Registrar via `roadmap-item` +## Passo 6 — Registrar via `agent:register` / `agent:file-miss` Para cada lote com destino **registrar** ou **absorver**: -1. Invoque **`roadmap-item`** com o escopo do lote (não um item por achado micro). Inclua **appetite** e **rabbit holes** do lote. -2. Se **absorver**: peça à skill para editar o plano existente (nova fase/seção), não criar ID paralelo — mesmo precedente "Gap vs 2022". -3. Se **registrar**: slug `escala-dry-pos-` ou `-ux-pos-critique`; posicione como fill-in (paralelo) salvo dependência dura de trilha. Appetite curto obrigatório — débito sem teto vira epic. -4. Se **defer**: não chame `roadmap-item` só por isso; anote o gatilho no plano-pai (Adiado com gatilho / Explicitamente fora) ou na mensagem de triage confirmada. +1. Lotes de engenharia/UX: `pnpm agent:register -- --id --title "" --prio

--kind chore --plan docs/plans/.md` — **um lote mesclado, não um item por achado micro**. Inclua appetite e rabbit holes do lote no plano curto. +2. Défice comportamental do fluxo de agentes (algo que o agente errou e a convenção não pegou): `pnpm agent:file-miss` (`kind:agent-miss`) — alimenta o harvest do `engineering-audit`. +3. Se **absorver** num plano existente: edite o plano (nova fase/seção) — mesmo precedente "Gap vs 2022". **Se a Issue dona do plano estiver `in-progress`, NÃO a edite** — registra como Issue nova com `--depends ` (destrava sozinha quando o pai flipar `done`). +4. Se **defer**: anote o gatilho no plano-pai (Adiado com gatilho / Explicitamente fora) ou na mensagem de triage confirmada — não crie Issue só por isso. 5. No plano, seções obrigatórias além do template: - **Já resolvido no simplify/critique (não reabrir)** - **Explicitamente fora** (skips dos revisores + descartes + defers com gatilho deste triage) -6. Classe Impeccable A–D conforme `roadmap-item` Passo 4; self-score de decisão ≥4/5 antes de gravar. +6. Self-score de decisão ≥4/5 antes de gravar; classe Impeccable A–D conforme o lote (só-backend = A; UX pós-critique = B/C). -Não implemente as fases aqui. Apontar `implement-roadmap-item` só se o usuário pedir em seguida. +Não implemente as fases aqui. Execução é via `work-issue` (claim → merge em stage), só se o usuário pedir em seguida. -**Próximo no fluxo de entrega:** após a triage confirmada (ou no-op sem débitos), o passo natural é `ship-to-main` (commit all → push → merge main → apagar worktree). Para fechar rebase + debts + ship numa tacada (com auto-confirm desta triage), use `close-delivery`. +**Próximo no fluxo de entrega:** após a triage confirmada (ou no-op sem débitos), o fechamento da sessão segue o Passo 6 da skill `work-issue` (fast gate → PR `--base stage` com `Closes #N` → acompanhar CI até o merge). ## Anti-padrões (baseline) | Desculpa | Realidade | | ---------------------------------------- | --------------------------------------------------------------------- | -| "Virou um item por achado" | Mesclar no lote; roadmap poluído é pior que débito omitido de score 2 | -| "Edito o roadmap na mão, é só um bullet" | Sempre `roadmap-item` (grafo, janela, plano, cortes) | +| "Virou um item por achado" | Mesclar no lote; backlog poluído é pior que débito omitido de score 2 | +| "Registro ad hoc, é só um bullet" | Sempre `agent:register` com frontmatter completo (id/depends/priority/model) | | "Rename PascalCase / pureza merece ID" | Score ≤2 → descartar, a menos que desbloqueie reuso real já pedido | | "Junto DRY e UX num FD+" | Quebra o precedente FD+/FD2; tipos separados | | "DRY com 1 call site vira escala-dry" | defer_trigger + gatilho; não registrar epic YAGNI | diff --git a/.cursor/skills/engineering-audit/SKILL.md b/.cursor/skills/engineering-audit/SKILL.md index 673470da..52a68855 100644 --- a/.cursor/skills/engineering-audit/SKILL.md +++ b/.cursor/skills/engineering-audit/SKILL.md @@ -5,14 +5,17 @@ description: Runs a Pass-style engineering audit of the Teqo codebase — code s # Engineering Audit (Pass N) -Read-only audit that sweeps the Teqo codebase for code smells, drift from documented patterns, and consolidation opportunities, then produces a findings ledger and a remediation plan. **No fixes in the audit run** — deliverables are updated docs, presented for sign-off before writing. +**Audit solitário (não paralelizável):** quando esta skill roda, o desenvolvimento paralelo **pausa** — nenhum outro agente trabalhando no repo. O agente do audit também **executa as remediações P0/P1 na mesma sessão** para trazer o projeto aos trilhos (não só registra); P2/P3 seguem o fluxo normal de ledger. + +Read-only audit that sweeps the Teqo codebase for code smells, drift from documented patterns, and consolidation opportunities, then produces a findings ledger and a remediation plan. **No fixes in the audit run** — deliverables are updated docs, presented for sign-off before writing — exceto as remediações P0/P1 declaradas acima. Method: the engineering skills this repo follows (improve-code-quality, clean-code, refactoring-patterns, software-design-philosophy, pragmatic-programmer, working-with-legacy-code, remove-technical-debt), specialized to Teqo's standards and history. The pass number is the next one after the last in `docs/IMPROVE-CODE-QUALITY-PLAN.md`. ## Checklist ``` -- [ ] 0. Load the canon and the history (before judging anything) +- [ ] 0. Load the canon and the history (before judging anything) — incl. `docs/AGENT-OPS.md` (paradigma vigente) +- [ ] 0b. Harvest `kind:agent-miss` → candidatos a guardrail (alimenta o Passo 4b) - [ ] 1. Hotspot map (churn × size × mechanical gates) — aim the sweep - [ ] 2. Smell sweep (Fowler families + Teqo-specific), parallelized per area - [ ] 3. Consolidation hunt (equivalence classes; name the duplicated KNOWLEDGE) @@ -37,12 +40,23 @@ Read, in this order: 2. `.cursor/rules/codebase-map.mdc` — dependency direction, where things live, the list system, invariants. 3. `docs/ARCHITECTURE.md` — layers, bounded contexts, decision log. 4. `AGENTS.md` — operational rules + "Recently resolved" history (Pass 1, Pass 2, every post-Pass-2 delivery's /simplify findings). -5. `docs/IMPROVE-CODE-QUALITY-PLAN.md` — what the earlier passes already swept. Don't re-register what they fixed; verify fixes held. -6. `docs/TECH-DEBT.md` — open ledger. New findings de-dup against it; verify each open row still exists, close stale ones. -7. `docs/TESTING.md` — safety-net map: what is pinned, where the gaps are. -8. `docs/plans/escala-dry-pos-*.md` — per-delivery debt registrations. -9. Consolidation precedents (the quality bar for step 3): `runStaffEntityMutation` (`src/utilities/campaignEntityActions.ts` — dedup by POLICY, not generic plumbing), `runCampaignFormAction`/`runCampaignRedirectFormAction` (`src/utilities/campaignFormActionError.ts`), `CampaignTable` columns-as-data (`src/components/campaign/shared/CampaignTable.tsx`), `RelationChipCell` (B37: one engine, two thin domain wrappers), `useCampaignCellAutosave` + `campaignJsonMutationRoute` (B32+: wrapper > helper — a helper is a line someone can forget), `relationMembershipDelta.ts` (algorithm once, cap as data, three one-line wrappers). -10. **Rejected-with-reason** (never re-propose): set-with-floor generic form (B37); `CampaignCellEditOverlay` Popover branch for comboboxes (dialog can't be an ARIA 1.2 combobox popup); `maxItems` on dobradinhas "for parity" (invents a rule); catalog-out-of-browser vs payload-minimal chips (B34+ — fixes oppose each other; chosen: payload-minimal); `src/domains/` + ports-and-adapters (Pass 2 D1 NO-GO). +5. `docs/AGENT-OPS.md` — paradigma de agentes paralelos vigente (claim→PR→stage→promote humano, skills plan-issue/work-issue/project-status). O audit avalia o repo **contra** esse fluxo, não contra o fluxo legacy de roadmap.md. +6. `docs/IMPROVE-CODE-QUALITY-PLAN.md` — what the earlier passes already swept. Don't re-register what they fixed; verify fixes held. +7. `docs/TECH-DEBT.md` — open ledger. New findings de-dup against it; verify each open row still exists, close stale ones. +8. `docs/TESTING.md` — safety-net map: what is pinned, where the gaps are. +9. `docs/plans/escala-dry-pos-*.md` — per-delivery debt registrations. +10. Consolidation precedents (the quality bar for step 3): `runStaffEntityMutation` (`src/utilities/campaignEntityActions.ts` — dedup by POLICY, not generic plumbing), `runCampaignFormAction`/`runCampaignRedirectFormAction` (`src/utilities/campaignFormActionError.ts`), `CampaignTable` columns-as-data (`src/components/campaign/shared/CampaignTable.tsx`), `RelationChipCell` (B37: one engine, two thin domain wrappers), `useCampaignCellAutosave` + `campaignJsonMutationRoute` (B32+: wrapper > helper — a helper is a line someone can forget), `relationMembershipDelta.ts` (algorithm once, cap as data, three one-line wrappers). +11. **Rejected-with-reason** (never re-propose): set-with-floor generic form (B37); `CampaignCellEditOverlay` Popover branch for comboboxes (dialog can't be an ARIA 1.2 combobox popup); `maxItems` on dobradinhas "for parity" (invents a rule); catalog-out-of-browser vs payload-minimal chips (B34+ — fixes oppose each other; chosen: payload-minimal); `src/domains/` + ports-and-adapters (Pass 2 D1 NO-GO). + +## Step 0b — Harvest `kind:agent-miss` → guardrails + +Antes da varredura, colha os défices comportamentais registrados pelo fluxo: + +```bash +gh issue list --label kind:agent-miss --state open +``` + +Cada Issue colhida alimenta o **Passo 4b (recurrence prevention)**: toda miss vira candidata a guardrail determinístico (tipo / ESLint / convention spec / CI / pin comportamental). O ledger desses guardrails vive em **`docs/GUARDRAILS.md`** (criar o arquivo na primeira execução): uma linha por guardrail — miss de origem (link da Issue), classe 1–6, mecanismo, status. Quando o guardrail mergeia, **feche as Issues colhidas** (`done`) com comentário apontando o guardrail. Miss que não admite guardrail determinístico vira convenção explícita marcada "judgment-only" — não fingir que doc é guarda. ## Step 1 — Hotspot map @@ -138,7 +152,7 @@ Rules: 1. `docs/IMPROVE-CODE-QUALITY-PLAN.md` — new Pass section (context, audit headlines with numbers, workstreams, decisions), matching earlier-pass format. 2. `docs/TECH-DEBT.md` — new rows in the same tables/columns, marked `open — Pass N`; stale rows closed with evidence. -3. `docs/plans/entrega-engenharia-pN.md` (pt-BR, like the other plans) — workstreams ordered P0→P1→P2; each item: goal, evidence, target shape, migration path (Branch by Abstraction / Parallel Change for wide merges), pins to write first, full gate, rollback. Items too big for one delivery → roadmap per the `roadmap-item` convention. Every workstream item declares its **Guarda determinística** (class 1–6, step 4b), and the plan carries a **guard map** section: new guards shipped / existing guards hardened / judgment-only residue with the convention that stands in. +3. `docs/plans/entrega-engenharia-pN.md` (pt-BR, like the other plans) — workstreams ordered P0→P1→P2; each item: goal, evidence, target shape, migration path (Branch by Abstraction / Parallel Change for wide merges), pins to write first, full gate, rollback. Items too big for one delivery → Issue rastreável via `plan-issue`. Every workstream item declares its **Guarda determinística** (class 1–6, step 4b), and the plan carries a **guard map** section: new guards shipped / existing guards hardened / judgment-only residue with the convention that stands in. 4. Present ALL THREE for sign-off before writing. Then write and stop. ## Execution rules for the eventual implementation (record in the plan) diff --git a/.cursor/skills/model-selection/SKILL.md b/.cursor/skills/model-selection/SKILL.md index f1fb14e5..d786550c 100644 --- a/.cursor/skills/model-selection/SKILL.md +++ b/.cursor/skills/model-selection/SKILL.md @@ -22,7 +22,7 @@ Dois eixos independentes, decididos nesta ordem: **(1) classe da tarefa → mode | 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 roadmap), Prettier, merges, rebase, chores | Grok 4.5 (pool) | Kimi K2.7 | **Low** | +| 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** | @@ -52,9 +52,9 @@ Dois eixos independentes, decididos nesta ordem: **(1) classe da tarefa → mode ## Gates por fluxo (onde a decisão de modelo entra no loop) - **`/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. -- **`ship-to-main` / `close-delivery`:** têm Passo 0 com gate declaratório — param o fluxo se a sessão estiver em metered premium. São classe docs/chores; nunca justificam K3/Pro/GLM. -- **`implement-roadmap-item`:** 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. -- **`suggest-next-roadmap-items`:** leitura + ranqueamento — classe docs/análise; pool model (Grok 4.5) ou metered barato bastam. A recomendação de modelo que ele emite por item é para a **worktree de implementação**, não para a sessão de sugestão. +- **`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) diff --git a/.cursor/skills/rebase-on-main/SKILL.md b/.cursor/skills/rebase-on-main/SKILL.md index 2f15ab6d..76d38414 100644 --- a/.cursor/skills/rebase-on-main/SKILL.md +++ b/.cursor/skills/rebase-on-main/SKILL.md @@ -91,7 +91,7 @@ Siga o protocolo de commit do usuário (status/diff/log → mensagem → `git ad - Mensagem: 1–2 frases no estilo do `git log` da branch; foque no porquê (evitar “wip:” genérico salvo se o log local já usa isso). - Se o pre-commit hook **falhar**: corrija e faça um **novo** commit (não `--amend`, salvo as regras do usuário). Se ficar claro que o dirty não era commitável, e o commit desta invocação ainda é o tip local não-pushed que **você** criou agora: `git reset --soft HEAD~1`, então mude para **stash** e siga. - Depois do commit limpo → Passo 2 → rebase → conflitos do rebase → Passo 5. -- Esse commit fica na branch (entra no `ship-to-main` depois). Não faça push aqui. +- Esse commit fica na branch (o push acontece no fechamento da sessão — Passo 6 de `work-issue`). Não faça push aqui. ### Caminho B — stash + rebase + stash pop @@ -132,7 +132,7 @@ git rebase origin/main **Não** use `git pull --rebase` no main checkout para “atualizar a feature” — o rebase é da **feature atual** sobre `origin/main`. -**Não** force-push aqui. Se a branch já tinha sido pushed e o rebase reescreveu commits, o push (com `--force-with-lease` se necessário) fica para `ship-to-main` ou pedido explícito do usuário. +**Não** force-push aqui. Se a branch já tinha sido pushed e o rebase reescreveu commits, o push (com `--force-with-lease` se necessário) fica para o fechamento em `work-issue` ou pedido explícito do usuário. ## Passo 4 — Resolver conflitos @@ -183,14 +183,14 @@ Opcional e leve (se o rebase tocou schema/types): `pnpm exec tsc --noEmit` nos a 3. Quantos commits rebased / se no-op 4. Conflitos resolvidos — rebase e/ou stash pop (paths + uma linha de racional cada) **ou** “nenhum” 5. Se abortou: por quê + o que precisa de decisão -6. Próximo passo natural: `capture-review-debts` (se ainda não rodou), `ship-to-main`, ou o atalho `close-delivery` (rebase+debts+ship) +6. Próximo passo natural: `capture-review-debts` (se ainda não rodou) e o fechamento da sessão no Passo 6 de `work-issue` (PR `--base stage` + CI até o merge) ## Anti-padrões | Nunca | Em vez disso | | ----------------------------------------------- | ----------------------------------------------------------------------------- | | Perguntar commit vs stash com árvore suja | Decida pela tabela do Passo 1b e execute | -| `git push --force` sem pedido | Deixe force-with-lease para `ship-to-main` / pedido explícito | +| `git push --force` sem pedido | Deixe force-with-lease para o fechamento `work-issue` / pedido explícito | | Commitar `.env` / secrets para “limpar” a árvore | Stash (regra 1); nunca stageie secret | | Stash sem `-u` deixando untracked no caminho | `git stash push -u -m "rebase-on-main:"` | | Resolver conflito sem ler os dois lados | Abra o arquivo + `git show :1/:2/:3:` se precisar | @@ -203,7 +203,6 @@ Opcional e leve (se o rebase tocou schema/types): `pnpm exec tsc --noEmit` nos a ## Posição no fluxo ``` -suggest-next → implement-roadmap-item → /simplify+/impeccable - → rebase-on-main → capture-review-debts → ship-to-main - # ou atalho: close-delivery +plan-issue → work-issue (claim → execução → /simplify+/impeccable + → rebase-on-main → capture-review-debts → PR --base stage → merge) ``` diff --git a/docs/IMPROVE-CODE-QUALITY-PLAN.md b/docs/IMPROVE-CODE-QUALITY-PLAN.md index bf163fd0..360c9230 100644 --- a/docs/IMPROVE-CODE-QUALITY-PLAN.md +++ b/docs/IMPROVE-CODE-QUALITY-PLAN.md @@ -161,4 +161,4 @@ Statuses: pending · in-progress · awaiting-evidence · done · deferred: \