Expand suggest-next-roadmap-items to list all parallel candidates.

Drop the 2–4 batch cap so every Pronto/Quase that clears the principal is listed by priority, with sibling collisions annotated instead of omitted.

.cursor/skills/suggest-next-roadmap-items/SKILL.md

@@ -3,23 +3,24 @@ name: suggest-next-roadmap-items
 description: >-
   Lê docs/roadmap.md (e planos/notebook/calendário necessários), filtra o que
   já foi entregue e o que ainda está bloqueado por dependência, e indica o
-  próximo item a implementar no Teqo mais o lote que pode correr em paralelo
-  com ele. Usar quando o usuário perguntar "o que fazer agora", "próximo item
-  do roadmap", "o que priorizar", "sugere o próximo", "what's next", "qual
-  item implementar", "o que dá para tocar em paralelo", ou pedir
-  recomendações de priorização a partir do roadmap.
+  próximo item a implementar no Teqo mais a lista completa — sem teto de
+  quantidade — dos itens que podem correr em paralelo com ele (priorizados).
+  Usar quando o usuário perguntar "o que fazer agora", "próximo item do
+  roadmap", "o que priorizar", "sugere o próximo", "what's next", "qual item
+  implementar", "o que dá para tocar em paralelo", ou pedir recomendações de
+  priorização a partir do roadmap.
 ---
 
 # Sugerir próximos itens do roadmap
 
-Esta skill **só recomenda** — não implementa, não edita o roadmap e não cria planos. O deliverable é **uma recomendação principal + um lote paralelo**: os outros itens que podem ser tocados ao mesmo tempo, cada um em sua própria branch/worktree, sem brigar com o principal nem entre si. Não são alternativas ao principal; são trabalho simultâneo. Depois disso, o fluxo natural é `implement-roadmap-item` por ID (um por sessão/worktree), ou `roadmap-item` se a sugestão revelar um gap de registro.
+Esta skill **só recomenda** — não implementa, não edita o roadmap e não cria planos. O deliverable é **uma recomendação principal + a lista completa dos itens paralelizados com ela** (sem limite de quantidade), ordenados por prioridade: cada um pode ser tocado ao mesmo tempo que o principal, em sua própria branch/worktree, sem brigar com o principal. Não são alternativas ao principal; são trabalho simultâneo possível. Colisões **entre** itens do lote (irmão×irmão) ficam anotadas — o leitor escolhe um subconjunto livre de conflito. Depois disso, o fluxo natural é `implement-roadmap-item` por ID (um por sessão/worktree), ou `roadmap-item` se a sugestão revelar um gap de registro.
 
 **Divisão com as skills irmãs:**
 
 | Skill                        | Papel                                                  |
 | ---------------------------- | ------------------------------------------------------ |
 | `compile-roadmap`            | Enxugar roadmap: resumir feito, destacar abertos       |
-| `suggest-next-roadmap-items` | **Escolher o próximo + o lote paralelo** entre o que o roadmap já lista |
+| `suggest-next-roadmap-items` | **Escolher o próximo + todos os paralelos** entre o que o roadmap já lista |
 | `roadmap-item`               | Registrar ideia nova / criar plano                     |
 | `implement-roadmap-item`     | Auditar plano + implementar o ID escolhido             |
 | `rebase-on-main`             | Após simplify: fetch + rebase em main + conflitos      |
@@ -34,9 +35,9 @@ Esta skill **só recomenda** — não implementa, não edita o roadmap e não cr
 - [ ] 2. Extrair pool de itens ainda abertos (sem ✓ / sem "entregue")
 - [ ] 3. Verificar dependências duras e bloqueios externos
 - [ ] 4. Pontuar candidatos (calendário × valor × prontidão × risco)
-- [ ] 5. Ler planos só dos top candidatos (progressive disclosure)
-- [ ] 6. Checar colisões e montar o lote paralelo
-- [ ] 7. Entregar principal + lote paralelo + próximo passo; parar
+- [ ] 5. Ler planos: principal em profundidade; demais paralelos só cabeçalho se preciso
+- [ ] 6. Checar colisões vs principal e listar TODOS os paralelos (priorizados, sem teto)
+- [ ] 7. Entregar principal + lista paralela completa + próximo passo; parar
 ```
 
 ## Passo 1 — Ler as fontes canônicas
@@ -48,7 +49,7 @@ Leia **nesta ordem** (não pule o roadmap):
 3. **Data de hoje** (contexto da sessão) vs âncoras do calendário eleitoral — define a janela vigente (1–4).
 4. **Contexto da conversa** — se o usuário já pediu foco (ex.: "só mapa", "só DRY", "nada de fill-in"), aplique como filtro explícito.
 
-**Não** leia todos os `docs/plans/*.md` de uma vez. Planos entram só no Passo 5, para os candidatos que sobrarem no top.
+**Não** leia todos os `docs/plans/*.md` de uma vez. Planos entram só no Passo 5.
 
 ## Passo 2 — Montar o pool de abertos
 
@@ -101,32 +102,35 @@ Atribua a cada **Pronto** / **Quase** uma nota 1–5 (soma ponderada mental; nã
 
 1. Não sugerir como #1 um fill-in DRY se houver feature **Pronta** da janela vigente que desbloqueie operação (ex. atuais: E8, C12, E9; B8 F2; D2).
 2. Preferir **uma fatia** de um programa (um ID: E8, C12, …) a "fazer o programa de inteligência inteiro" — diga qual plano (`docs/plans/<slug>.md`), e respeite a ordem do grafo (E8 antes de E9/E10/E12; C12 antes de E11/E14/E15).
-3. Se várias cadeias DRY competem (C10, C11, E6, E7, A7, B5, O0+, …), escolha no máximo **1–2** no total (principal + lote), priorizando as Fases que o próprio roadmap marca como "mais valiosas" em Cortes seguros.
+3. Cadeias DRY (`escala-dry-pos-*` / `*+`) entram no lote paralelo se passarem nos testes do Passo 6, mas **ficam no fim da ordenação** (depois de features/quick wins de campo) — não competem com o #1.
 4. Itens _(proposto — validar com produto)_ (ex.: C5) só entram se o usuário pedir exploração de produto; senão liste em "Depois / validar".
 5. Trabalho externo (lote jurídico) **nunca** substitui um candidato de engenharia — reporte em seção própria.
 6. O #1 é o de maior valor/urgência de calendário, **nunca** o "mais isolado". Isolamento decide quem entra no lote paralelo (Passo 6), não quem é o principal.
 
-## Passo 5 — Aprofundar só o top
+## Passo 5 — Aprofundar o principal (e skim nos paralelos)
 
-Pegue os **4–6** melhores do Passo 4 (o #1 mais os pré-candidatos ao lote). Para cada um:
+1. **Principal:** abra o plano linkado (`docs/plans/...`) — leia cabeçalho, Status, Dependências, Não escopo, e o tamanho das fases (1 parágrafo basta). Para itens do programa de inteligência, a tabela do programa já traz classe Impeccable/appetite/depende-de — só abra o plano do candidato final se precisar de detalhe além da tabela.
+2. **Demais candidatos ao lote:** não leia o plano inteiro. Use o roadmap + notebook + (se houver dúvida de superfície) só o cabeçalho do plano (Status / appetite / dependências). Progressive disclosure: plano completo só quando a colisão for ambígua.
+3. Se houver design-ref na tabela do roadmap para o principal, cite o nome do par em `docs/design-refs/latest/` (não precisa abrir o HTML).
+4. Classifique superficialmente Impeccable A/B/C/D no principal — uma letra + meia frase. Nos paralelos, a letra basta quando conhecida (tabela do programa / cabeçalho); senão omita.
 
-1. Abra o plano linkado (`docs/plans/...`) — leia cabeçalho, Status, Dependências, Não escopo, e o tamanho das fases (1 parágrafo basta). Para itens do programa de inteligência, a tabela do programa já traz classe Impeccable/appetite/depende-de — só abra o plano do candidato final.
-2. Se houver design-ref na tabela do roadmap, cite o nome do par em `docs/design-refs/latest/` (não precisa abrir o HTML).
-3. Classifique superficialmente Impeccable A/B/C/D (mesma tabela de `implement-roadmap-item`) — uma letra + meia frase.
+Se dois candidatos forem quase equivalentes para o #1, prefira o de menor risco de migration / o que o calendário pune mais se atrasar.
 
-Se dois candidatos forem quase equivalentes, prefira o de menor risco de migration / o que o calendário pune mais se atrasar.
+## Passo 6 — Checar colisões e listar TODOS os paralelos
 
-## Passo 6 — Checar colisões e montar o lote paralelo
+Premissa: cada item roda na **sua própria branch/worktree** e fecha com `close-delivery` (rebase em `main` antes do merge). Logo, paralelizável não é "cabe no mesmo dia" — é "pode viver em worktree separada e reencontrar `main` sem conflito que exija reescrita **com o principal**".
 
-Premissa: cada item roda na **sua própria branch/worktree** e fecha com `close-delivery` (rebase em `main` antes do merge). Logo, paralelizável não é "cabe no mesmo dia" — é "os dois podem viver em worktrees separadas e reencontrar `main` sem conflito que exija reescrita".
+Um candidato entra na lista paralela quando passa **nos três testes contra o principal**:
 
-Um candidato entra no lote quando passa **nos três testes**:
+1. **Independência vs principal** — não depende (nem suave) do principal, e o principal não depende dele. Dependência suave em ambos os sentidos → fora da lista, vai para "Serializar depois".
+2. **Superfície disjunta do principal** — não disputa nenhuma superfície serializadora com o principal (tabela abaixo).
+3. **Fechamento independente** — pode ser mesclado sozinho e entregar valor sem esperar o principal (nada de "só faz sentido junto").
 
-1. **Independência** — não depende (nem suave) do principal nem de outro item do lote, e o principal não depende dele. Dependência suave em ambos os sentidos → fora do lote, vira "depois de X".
-2. **Superfície disjunta** — não disputa nenhuma superfície serializadora com o principal nem com outro item já no lote (tabela abaixo).
-3. **Fechamento independente** — pode ser mesclado sozinho e entregar valor sem esperar o irmão (nada de "só faz sentido junto").
+**Sem teto de quantidade.** Percorra **todos** os Pronto/Quase (exceto o principal) em ordem de score e inclua cada um que passar nos três testes. Não corte em 2–4 nem em 5.
 
-**Superfícies serializadoras do Teqo (no máximo 1 item por lote em cada linha):**
+**Colisões irmão×irmão:** itens na lista **podem** colidir entre si (mesma migration, mesma rota, mesma seam). Isso **não** os remove da lista — anote na coluna/nota `Colide com` (IDs dos irmãos + superfície). O leitor monta um subconjunto livre de conflito. Opcionalmente, ao final, sugira **um** clique máximo sem colisão mútua ("subconjunto sem atrito") usando greedy por score — isso é ajuda, não substitui a lista completa.
+
+**Superfícies serializadoras do Teqo (no máximo 1 item ativo por linha em qualquer worktree simultânea):**
 
 | Superfície                                                                                    | Por que serializa                                                                                            |
 | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ |
@@ -138,9 +142,9 @@ Um candidato entra no lote quando passa **nos três testes**:
 
 **Não** serializam (append trivial, resolve no rebase): `docs/roadmap.md`, `docs/plans/`, `campaignIntelligenceConcepts.ts` (E18), `nav.ts`, novos arquivos em domínios distintos. Só avise a ordem de merge.
 
-Monte assim: fixe o principal, percorra os pré-candidatos do Passo 5 em ordem de score e inclua os que passam nos três testes. **Lote de 2–4 itens** (3–5 no total com o principal). Se um candidato falha só pelo teste 2 contra o principal, liste-o como "serializar depois de \<ID\>" em vez de descartar. Prefira lotes de trilhas distintas (campo × dados × site público) — menos atrito de rebase e menos troca de contexto.
+Se um candidato falha só pelo teste 2 contra o principal, liste-o em "Serializar depois de \<principal\>" em vez de descartar do radar.
 
-Se **nada** for paralelizável, diga isso explicitamente e nomeie o que destrava paralelismo (normalmente: o principal ser o único com migration).
+Se **nada** for paralelizável com o principal, diga isso explicitamente e nomeie o que destrava paralelismo (normalmente: o principal ser o único com migration / única superfície quente).
 
 ## Passo 7 — Entregar e parar
 
@@ -162,16 +166,17 @@ Formato obrigatório da resposta (conciso; sem reescrever o roadmap):
 - Impeccable: A|B|C|D
 - Próximo passo: skill `implement-roadmap-item` neste ID
 
-## Em paralelo com ele (2–4)
+## Em paralelo com ele (todos, por prioridade)
 
-Cada um em sua própria worktree; nenhum depende do principal nem dos outros.
+Cada um em sua própria worktree; nenhum depende do principal. Ordenados por score (maior primeiro). **Sem limite de linhas.**
 
-| #   | ID  | Por que agora | Por que não colide | Plano |
-| --- | --- | ------------- | ------------------ | ----- |
-| 2   | …   | …             | …                  | …     |
+| #   | ID  | Por que agora | Por que não colide com o principal | Colide com (irmãos) | Plano |
+| --- | --- | ------------- | ---------------------------------- | ------------------- | ----- |
+| 2   | …   | …             | …                                  | — / ID (superfície) | …     |
 
-- Migration no lote: só \<ID\> (os demais são sem schema) — ou "nenhum".
-- Serializar depois: \<ID\> — colide com \<ID\> em \<superfície\>.
+- Migration no lote: liste os IDs com migration (no máximo um por worktree simultânea).
+- Serializar depois do principal: \<ID\> — colide em \<superfície\>.
+- Subconjunto sem atrito (opcional, greedy): #2, #4, #7… — um clique máximo sem colisão mútua.
 - Ordem de merge sugerida: … (só se importar)
 
 ## Deixados de fora (amostra)
@@ -187,10 +192,10 @@ Quer que eu rode `implement-roadmap-item` em algum destes?
 
 - Implementar código, abrir PR, ou marcar item como entregue
 - Editar `docs/roadmap.md` / `docs/plans/` (se achar inconsistência material, **reporte** e ofereça `roadmap-item` / correção via `implement-roadmap-item` Passo 7)
-- Inventar IDs ou itens que não estão no roadmap — inclusive para encher o lote paralelo
-- Mais de 5 itens no total (principal + lote)
+- Inventar IDs ou itens que não estão no roadmap
+- **Omitir** um Pronto/Quase que passa nos três testes contra o principal só para "encurtar" a resposta — a lista paralela é completa; concisão vem das células curtas, não do corte
 - Apresentar o lote como "alternativas ao principal" ou como um plano de execução sequencial
-- Colocar no lote item que colide em superfície serializadora (Passo 6) — ele vai para "serializar depois"
+- Colocar na lista paralela item que colide com o **principal** (Passo 6) — ele vai para "Serializar depois"
 - Auditoria afirmação-a-afirmação do plano (isso é `implement-roadmap-item`)
 
 Se o usuário já disser "faz o X" / "implementa o segundo", pare esta skill e invoque `implement-roadmap-item` no ID escolhido (um por sessão/worktree).