oxe-cc 0.6.2 → 0.6.4

package/oxe/templates/LESSONS.template.md

@@ -1,43 +1,43 @@
----
-oxe_doc: lessons
-updated: YYYY-MM-DD
----
-
-# Lições Aprendidas OXE
-
-<!-- Consumido automaticamente por /oxe-spec, /oxe-plan, /oxe-execute, /oxe-verify -->
-<!-- Cada entrada é PRESCRITIVA: diz o que fazer diferente, não apenas o que aconteceu -->
-
-| Ciclo | Data | Tipo | Lição (resumo) | Aplicar em | Status |
-|-------|------|------|----------------|------------|--------|
-| C-01 | YYYY-MM-DD | plan | Tarefas de integração requerem Complexidade L mínimo | /oxe-plan | ativo |
-
----
-
-### C-01 — YYYY-MM-DD
-
-**Fonte:** VERIFY.md (gaps) + FORENSICS.md (causa raiz)
-
----
-
-**L-01** · Tipo: `plan`
-**Lição:** Tarefas que integram APIs de terceiros devem ter `Complexidade: L` mínimo e `Verificar` com mock como fallback quando API estiver indisponível.
-**Raiz do problema:** T4 foi marcada `M` mas envolveu 3 serviços externos — estorou 2 ondas.
-**Aplicar em:** `/oxe-plan` — ao planejar tarefas com `INTEGRATIONS.md` externos, elevar complexidade automaticamente.
-**Status:** ativo
-
----
-
-**L-02** · Tipo: `spec`
-**Lição:** Critérios A* que envolvem "performance" devem incluir métrica mensurável (ex.: "< 200ms p95 em carga de 100 req/s") desde a Fase 3.
-**Raiz do problema:** A3 dizia "resposta rápida" — verify não conseguiu evidência objetiva.
-**Aplicar em:** `/oxe-spec` Fase 3 — ao criar critérios de performance, pedir métrica específica antes de aprovar o requisito.
-**Status:** ativo
-
----
-
-**L-03** · Tipo: `process`
-**Lição:** Quando o plano tem 3+ domínios distintos, sempre usar `/oxe-plan --agents`. Solo em 3+ domínios gera tarefas com contexto insuficiente.
-**Raiz do problema:** plano solo com auth + API + UI causou tarefas que misturavam contexto de 2 domínios.
-**Aplicar em:** `/oxe-plan` — gate de sugestão de `--agents` já existe; reforçar como obrigatório para 3+.
-**Status:** ativo
+---
+oxe_doc: lessons
+updated: YYYY-MM-DD
+---
+
+# Lições Aprendidas OXE
+
+<!-- Consumido automaticamente por /oxe-spec, /oxe-plan, /oxe-execute, /oxe-verify -->
+<!-- Cada entrada é PRESCRITIVA: diz o que fazer diferente, não apenas o que aconteceu -->
+
+| Ciclo | Data | Tipo | Lição (resumo) | Aplicar em | Status |
+|-------|------|------|----------------|------------|--------|
+| C-01 | YYYY-MM-DD | plan | Tarefas de integração requerem Complexidade L mínimo | /oxe-plan | ativo |
+
+---
+
+### C-01 — YYYY-MM-DD
+
+**Fonte:** VERIFY.md (gaps) + FORENSICS.md (causa raiz)
+
+---
+
+**L-01** · Tipo: `plan`
+**Lição:** Tarefas que integram APIs de terceiros devem ter `Complexidade: L` mínimo e `Verificar` com mock como fallback quando API estiver indisponível.
+**Raiz do problema:** T4 foi marcada `M` mas envolveu 3 serviços externos — estorou 2 ondas.
+**Aplicar em:** `/oxe-plan` — ao planejar tarefas com `INTEGRATIONS.md` externos, elevar complexidade automaticamente.
+**Status:** ativo
+
+---
+
+**L-02** · Tipo: `spec`
+**Lição:** Critérios A* que envolvem "performance" devem incluir métrica mensurável (ex.: "< 200ms p95 em carga de 100 req/s") desde a Fase 3.
+**Raiz do problema:** A3 dizia "resposta rápida" — verify não conseguiu evidência objetiva.
+**Aplicar em:** `/oxe-spec` Fase 3 — ao criar critérios de performance, pedir métrica específica antes de aprovar o requisito.
+**Status:** ativo
+
+---
+
+**L-03** · Tipo: `process`
+**Lição:** Quando o plano tem 3+ domínios distintos, sempre usar `/oxe-plan --agents`. Solo em 3+ domínios gera tarefas com contexto insuficiente.
+**Raiz do problema:** plano solo com auth + API + UI causou tarefas que misturavam contexto de 2 domínios.
+**Aplicar em:** `/oxe-plan` — gate de sugestão de `--agents` já existe; reforçar como obrigatório para 3+.
+**Status:** ativo

package/oxe/templates/SECURITY.template.md

@@ -1,72 +1,72 @@
----
-oxe_doc: security
-status: draft
-updated: YYYY-MM-DD
-stack_ref: .oxe/codebase/STACK.md
-plan_ref: .oxe/PLAN.md
----
-
-# Auditoria de Segurança OXE
-
-## Stack e escopo
-
-**Stack identificado:** [linguagem, framework, DB, auth]
-**Categorias OWASP avaliadas:** A01, A02, A03, ...
-**Categorias descartadas:** A04 (motivo), A08 (motivo), ...
-
----
-
-## Achados
-
-### P0 — Crítico (requer ação imediata)
-
-| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
-|----|-----------|--------------|-------------------|--------------|--------|
-| S-01 | A07 — Auth | `src/auth/login.ts:42` | Senha comparada sem hash | Usar bcrypt/argon2 | T_new |
-
-### P1 — Alto (antes do próximo deploy)
-
-| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
-|----|-----------|--------------|-------------------|--------------|--------|
-| S-02 | A05 — Config | `.env.example:8` | JWT_SECRET sem rotação documentada | Documentar política de rotação | T3 |
-
-### P2 — Médio (ação recomendada, compensação aceitável)
-
-| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
-|----|-----------|--------------|-------------------|--------------|--------|
-| S-03 | A09 — Logging | `src/api/handler.ts:15` | Erro logado com stack trace completo em produção | Filtrar dados sensíveis em prod | T_new |
-
----
-
-## Resultado por categoria
-
-| Categoria OWASP | Status | Achados |
-|-----------------|--------|---------|
-| A01 — Broken Access Control | ✅ Sem achados | — |
-| A02 — Cryptographic Failures | ⚠️ P1 | S-02 |
-| A03 — Injection | ✅ Sem achados | — |
-| A05 — Security Misconfiguration | ⚠️ P1 | S-02 |
-| A07 — Authentication Failures | ❌ P0 | S-01 |
-| A09 — Logging & Monitoring | ⚠️ P2 | S-03 |
-
----
-
-## Sugestões de tarefas novas
-
-```
-T_new-S01: Implementar hash de senha com bcrypt (custo ≥ 12)
-  Verificar: login falha com senha errada; hash visível no DB.
-  Aceite vinculado: [A* de segurança se existir na SPEC]
-
-T_new-S03: Filtrar stack traces em logs de produção
-  Verificar: log em NODE_ENV=production não expõe stacktrace.
-  Aceite vinculado: —
-```
-
----
-
-## Próximo passo
-
-- **P0 presente:** ação obrigatória antes de qualquer deploy — criar tarefas e adicionar ao PLAN via `/oxe-plan --replan`.
-- **Apenas P1/P2:** priorizar P1 na próxima onda; P2 pode ir para backlog v2.
-- **Sem achados:** registrar como "auditoria limpa em YYYY-MM-DD" e prosseguir.
+---
+oxe_doc: security
+status: draft
+updated: YYYY-MM-DD
+stack_ref: .oxe/codebase/STACK.md
+plan_ref: .oxe/PLAN.md
+---
+
+# Auditoria de Segurança OXE
+
+## Stack e escopo
+
+**Stack identificado:** [linguagem, framework, DB, auth]
+**Categorias OWASP avaliadas:** A01, A02, A03, ...
+**Categorias descartadas:** A04 (motivo), A08 (motivo), ...
+
+---
+
+## Achados
+
+### P0 — Crítico (requer ação imediata)
+
+| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
+|----|-----------|--------------|-------------------|--------------|--------|
+| S-01 | A07 — Auth | `src/auth/login.ts:42` | Senha comparada sem hash | Usar bcrypt/argon2 | T_new |
+
+### P1 — Alto (antes do próximo deploy)
+
+| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
+|----|-----------|--------------|-------------------|--------------|--------|
+| S-02 | A05 — Config | `.env.example:8` | JWT_SECRET sem rotação documentada | Documentar política de rotação | T3 |
+
+### P2 — Médio (ação recomendada, compensação aceitável)
+
+| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
+|----|-----------|--------------|-------------------|--------------|--------|
+| S-03 | A09 — Logging | `src/api/handler.ts:15` | Erro logado com stack trace completo em produção | Filtrar dados sensíveis em prod | T_new |
+
+---
+
+## Resultado por categoria
+
+| Categoria OWASP | Status | Achados |
+|-----------------|--------|---------|
+| A01 — Broken Access Control | ✅ Sem achados | — |
+| A02 — Cryptographic Failures | ⚠️ P1 | S-02 |
+| A03 — Injection | ✅ Sem achados | — |
+| A05 — Security Misconfiguration | ⚠️ P1 | S-02 |
+| A07 — Authentication Failures | ❌ P0 | S-01 |
+| A09 — Logging & Monitoring | ⚠️ P2 | S-03 |
+
+---
+
+## Sugestões de tarefas novas
+
+```
+T_new-S01: Implementar hash de senha com bcrypt (custo ≥ 12)
+  Verificar: login falha com senha errada; hash visível no DB.
+  Aceite vinculado: [A* de segurança se existir na SPEC]
+
+T_new-S03: Filtrar stack traces em logs de produção
+  Verificar: log em NODE_ENV=production não expõe stacktrace.
+  Aceite vinculado: —
+```
+
+---
+
+## Próximo passo
+
+- **P0 presente:** ação obrigatória antes de qualquer deploy — criar tarefas e adicionar ao PLAN via `/oxe-plan --replan`.
+- **Apenas P1/P2:** priorizar P1 na próxima onda; P2 pode ir para backlog v2.
+- **Sem achados:** registrar como "auditoria limpa em YYYY-MM-DD" e prosseguir.

package/oxe/templates/STATE.md

@@ -13,6 +13,7 @@
 
 - **Data:** (**YYYY-MM-DD** — preenchido por **`/oxe-compact`**: refresh incremental dos mapas em `.oxe/codebase/` + `CODEBASE-DELTA.md` + `RESUME.md`)
 - **Notas:** (opcional; ex.: "só STRUCTURE e TESTING")
+- **last_retro:** (YYYY-MM-DD — preenchido por **`/oxe-retro`** ao concluir retrospectiva; lido por `oxe-cc doctor` para rastrear ciclos sem lições)
 
 ## Contexto do plano / quick (opcional)
 
@@ -22,13 +23,30 @@
 
 ## Blueprint de agentes (sessão) (opcional — `/oxe-plan-agent`)
 
-Espelho do **`.oxe/plan-agents.json`** ativo (schema 2). Atualizar em **`/oxe-plan-agent`**, **`/oxe-execute`**, **`/oxe-verify`**, **`/oxe-quick`** quando o lifecycle mudar.
+Espelho do **`.oxe/plan-agents.json`** ativo (schema ≥ 2). Atualizar em **`/oxe-plan-agent`**, **`/oxe-execute`**, **`/oxe-verify`**, **`/oxe-quick`** quando o lifecycle mudar.
 
 - **run_id:** (igual a `runId` no JSON; — se não houver blueprint)
 - **lifecycle_status:** `pending_execute` | `executing` | `closed` | `invalidated` | —
 - **Última onda (execute):** (número ou —)
 - **Notas:** (ex.: invalidado por quick; mensagens em `.oxe/plan-agent-messages/`)
 
+## Quick agents (sessão) (opcional — `/oxe-quick` com PDDA)
+
+Preenchido por **`/oxe-quick`** quando Plan-Driven Dynamic Agents lean estiver ativo.
+
+- **quick_id:** (ex.: `quick-2026-04-05-a1b2c3` — gerado por `/oxe-quick`)
+- **quick_agents_status:** `active` | `done` | `invalidated` | —
+- **Notas:** (ex.: invalidado ao iniciar novo quick ou promover a spec/plan)
+
+## Loop (sessão) (opcional — `/oxe-loop`)
+
+Preenchido por **`/oxe-loop`** durante retry iterativo de onda.
+
+- **loop_onda:** (número da onda em retry, ex.: `2`)
+- **loop_iteracao:** (tentativa atual / máximo, ex.: `2/3`)
+- **loop_status:** `retrying` | `passed` | `escalated` | —
+- **Notas:** (ex.: escalado para `/oxe-forensics` após 3 tentativas)
+
 ## Checklist da onda OXE (opcional — workflow execute)
 
 _(O agente pode preencher após cada onda.)_

package/oxe/templates/config.template.json

@@ -3,12 +3,14 @@
   "profile": "balanced",
   "discuss_before_plan": false,
   "verification_depth": "standard",
+  "security_in_verify": false,
   "after_verify_suggest_pr": true,
   "after_verify_draft_commit": true,
   "after_verify_suggest_uat": false,
   "default_verify_command": "",
   "scan_max_age_days": 0,
   "compact_max_age_days": 0,
+  "lessons_max_age_days": 0,
   "scale_adaptive": true,
   "scan_focus_globs": [],
   "scan_ignore_globs": [],

package/oxe/templates/plan-agents.template.json

@@ -11,6 +11,7 @@
     {
       "id": "agent-example",
       "role": "Papel legível (ex.: Database)",
+      "persona": "executor",
       "scope": [
         "Primeiro bullet do âmbito",
         "Segundo bullet"

package/oxe/workflows/loop.md

@@ -1,57 +1,57 @@
-# OXE — Workflow: loop (execução iterativa até verificação passar)
-
-<objective>
-Executar uma **onda do PLAN.md** em ciclo iterativo até que a verificação inline passe ou o limite de tentativas seja atingido. Complementa o **Modo B** (por onda) do **`execute.md`** com retries automáticos e diagnóstico inline de falhas.
-
-Quando verify falha, não interrompe — diagnostica (2-3 hipóteses), corrige, tenta de novo. Escala para **`/oxe-forensics`** apenas quando esgota as tentativas.
-</objective>
-
-<context>
-- **Pré-requisito:** `.oxe/PLAN.md` existente com pelo menos 1 onda; `STATE.md` com fase ≥ `plan_ready`.
-- **Máximo de iterações:** padrão = 3; configurável via argumento `max:<N>` (ex.: `/oxe-loop onda 2 max:5`). Nunca exceder 10.
-- **Artefato:** não cria novos arquivos — atualiza `STATE.md` com campos `loop_*` e registra cada iteração como bloco inline no chat.
-- **Escalação:** se esgotou tentativas e ainda falhou → registrar estado em STATE.md + sugerir `/oxe-forensics` com contexto das hipóteses já tentadas.
-- **Não substitui** `/oxe-verify` global (4 camadas): o loop faz verificação **inline por onda** (comando `**Verificar:**` de cada Tn); o verify completo deve ser chamado ao final de todas as ondas.
-</context>
-
-<loop_state>
-## Campos em STATE.md durante o loop
-
-```yaml
-loop_onda: 2              # número da onda sendo executada
-loop_iteracao: 2/3        # tentativa atual / máximo
-loop_status: retrying     # retrying | passed | escalated
-loop_hipoteses: ["H1: ...", "H2: ..."]  # hipóteses da última falha
-```
-
-Limpar campos `loop_*` ao concluir com `passed` (ou manter `escalated` se escalou para forensics).
-</loop_state>
-
-<process>
-1. Ler `.oxe/STATE.md` e `.oxe/PLAN.md`. Identificar a onda alvo (argumento do usuário ou próxima onda pendente em STATE).
-2. Registrar em STATE.md: `loop_onda: N`, `loop_iteracao: 1/<max>`, `loop_status: retrying`.
-3. **Iteração:**
-   a. Listar tarefas da onda N com seus comandos `**Verificar:**`.
-   b. Implementar todas as tarefas da onda (seguindo `execute.md` `<modo_solo>`).
-   c. Executar os comandos `Verificar` de cada `Tn`.
-   d. **Se todos passaram:** registrar `loop_status: passed`; limpar campos `loop_*`; atualizar STATE.md com onda concluída; informar usuário e sugerir próxima onda ou `/oxe-verify`.
-   e. **Se algum falhou:**
-      - Listar 2-3 hipóteses de causa (baseado no erro/output da verificação).
-      - Registrar `loop_hipoteses` em STATE.md.
-      - Incrementar iteração: `loop_iteracao: K+1/<max>`.
-      - Se `K+1 > max`: ir para passo 4 (escalação).
-      - Senão: aplicar fix para a hipótese mais provável → voltar a `c`.
-4. **Escalação (tentativas esgotadas):**
-   - Registrar `loop_status: escalated` em STATE.md.
-   - Exibir no chat: tentativas realizadas, hipóteses testadas, evidência de cada falha.
-   - Sugerir `/oxe-forensics` com contexto: "onda N falhou após <max> tentativas — hipóteses testadas: H1, H2, H3".
-</process>
-
-<success_criteria>
-- [ ] STATE.md tem campos `loop_*` atualizados a cada iteração.
-- [ ] Cada falha gera 2-3 hipóteses registradas antes de tentar fix.
-- [ ] Ao passar: campos `loop_*` limpos; onda marcada como concluída em STATE.md.
-- [ ] Ao esgotar: `loop_status: escalated` + sugestão de `/oxe-forensics` com contexto completo.
-- [ ] Nunca excede `max` iterações configurado.
-- [ ] Não altera `.oxe/PLAN.md` (só implementa o que já está planejado).
-</success_criteria>
+# OXE — Workflow: loop (execução iterativa até verificação passar)
+
+<objective>
+Executar uma **onda do PLAN.md** em ciclo iterativo até que a verificação inline passe ou o limite de tentativas seja atingido. Complementa o **Modo B** (por onda) do **`execute.md`** com retries automáticos e diagnóstico inline de falhas.
+
+Quando verify falha, não interrompe — diagnostica (2-3 hipóteses), corrige, tenta de novo. Escala para **`/oxe-forensics`** apenas quando esgota as tentativas.
+</objective>
+
+<context>
+- **Pré-requisito:** `.oxe/PLAN.md` existente com pelo menos 1 onda; `STATE.md` com fase ≥ `plan_ready`.
+- **Máximo de iterações:** padrão = 3; configurável via argumento `max:<N>` (ex.: `/oxe-loop onda 2 max:5`). Nunca exceder 10.
+- **Artefato:** não cria novos arquivos — atualiza `STATE.md` com campos `loop_*` e registra cada iteração como bloco inline no chat.
+- **Escalação:** se esgotou tentativas e ainda falhou → registrar estado em STATE.md + sugerir `/oxe-forensics` com contexto das hipóteses já tentadas.
+- **Não substitui** `/oxe-verify` global (4 camadas): o loop faz verificação **inline por onda** (comando `**Verificar:**` de cada Tn); o verify completo deve ser chamado ao final de todas as ondas.
+</context>
+
+<loop_state>
+## Campos em STATE.md durante o loop
+
+```yaml
+loop_onda: 2              # número da onda sendo executada
+loop_iteracao: 2/3        # tentativa atual / máximo
+loop_status: retrying     # retrying | passed | escalated
+loop_hipoteses: ["H1: ...", "H2: ..."]  # hipóteses da última falha
+```
+
+Limpar campos `loop_*` ao concluir com `passed` (ou manter `escalated` se escalou para forensics).
+</loop_state>
+
+<process>
+1. Ler `.oxe/STATE.md` e `.oxe/PLAN.md`. Identificar a onda alvo (argumento do usuário ou próxima onda pendente em STATE).
+2. Registrar em STATE.md: `loop_onda: N`, `loop_iteracao: 1/<max>`, `loop_status: retrying`.
+3. **Iteração:**
+   a. Listar tarefas da onda N com seus comandos `**Verificar:**`.
+   b. Implementar todas as tarefas da onda (seguindo `execute.md` `<modo_solo>`).
+   c. Executar os comandos `Verificar` de cada `Tn`.
+   d. **Se todos passaram:** registrar `loop_status: passed`; limpar campos `loop_*`; atualizar STATE.md com onda concluída; informar usuário e sugerir próxima onda ou `/oxe-verify`.
+   e. **Se algum falhou:**
+      - Listar 2-3 hipóteses de causa (baseado no erro/output da verificação).
+      - Registrar `loop_hipoteses` em STATE.md.
+      - Incrementar iteração: `loop_iteracao: K+1/<max>`.
+      - Se `K+1 > max`: ir para passo 4 (escalação).
+      - Senão: aplicar fix para a hipótese mais provável → voltar a `c`.
+4. **Escalação (tentativas esgotadas):**
+   - Registrar `loop_status: escalated` em STATE.md.
+   - Exibir no chat: tentativas realizadas, hipóteses testadas, evidência de cada falha.
+   - Sugerir `/oxe-forensics` com contexto: "onda N falhou após <max> tentativas — hipóteses testadas: H1, H2, H3".
+</process>
+
+<success_criteria>
+- [ ] STATE.md tem campos `loop_*` atualizados a cada iteração.
+- [ ] Cada falha gera 2-3 hipóteses registradas antes de tentar fix.
+- [ ] Ao passar: campos `loop_*` limpos; onda marcada como concluída em STATE.md.
+- [ ] Ao esgotar: `loop_status: escalated` + sugestão de `/oxe-forensics` com contexto completo.
+- [ ] Nunca excede `max` iterações configurado.
+- [ ] Não altera `.oxe/PLAN.md` (só implementa o que já está planejado).
+</success_criteria>

package/oxe/workflows/next.md

@@ -13,7 +13,10 @@ Inspecionar `.oxe/STATE.md` e a existência de `SPEC.md`, `PLAN.md`, `QUICK.md`,
 <process>
 1. Se `.oxe/` ou `STATE.md` não existir → **único** passo: **scan** (ou `oxe-cc init-oxe` seguido de scan).
 2. Se não houver `.oxe/codebase/*.md` completos (sete mapas) e o trabalho **não** for só um quick isolado → **scan**.
-3. Se fase `quick_active` ou existir `QUICK.md` **sem** `PLAN.md` → se o `QUICK.md` tiver **mais de 10 passos**, ou o utilizador/descrição indicar **contrato público**, **segurança**, **dados pessoais**, ou **>8 ficheiros** tocados ou previstos → **spec** (promoção obrigatória, um único passo); senão → **execute** (há passos curtos a implementar) desde que o QUICK não declare **Promover para spec/plan?** `sim`.
+3. Se fase `quick_active` ou existir `QUICK.md` **sem** `PLAN.md`:
+   - Se `QUICK.md` contiver linha `Promover para spec/plan?: sim` → **spec** (promoção declarada pelo autor; ignorar demais heurísticas).
+   - Se o `QUICK.md` tiver **mais de 10 passos**, ou o utilizador/descrição indicar **contrato público**, **segurança**, **dados pessoais**, ou **>8 ficheiros** tocados ou previstos → **spec** (promoção obrigatória).
+   - Senão → **execute** (há passos curtos a implementar).
 4. Se não houver `SPEC.md` e não for quick intencional declarado → **spec** (passo único).
 5. Se houver SPEC mas não PLAN → se `.oxe/config.json` tiver `discuss_before_plan: true` e faltar **`.oxe/DISCUSS.md`** com decisões → **discuss**; senão → **plan**.
 6. Se PLAN existe, **VERIFY.md** ainda **não** existe ou está claramente antes da implementação atual → **execute** (onda atual).

package/oxe/workflows/obs.md

@@ -49,6 +49,16 @@ API deve retornar mensagens de erro em português do Brasil.
 **IDs:** sequenciais `OBS-001`, `OBS-002`, … (continuar do último ID existente no arquivo).
 
 **Impacto:** classificar automaticamente com base no conteúdo:
+
+| Texto menciona | Impacto atribuído |
+|----------------|------------------|
+| Requisitos, critérios A*, escopo, SPEC | `spec` |
+| Tarefas Tn, ondas, verificação, PLAN | `plan` |
+| Implementação, arquivos de código, comportamento técnico | `execute` |
+| Dois ou mais dos acima, ou restrição global | `all` |
+
+Se ambíguo, usar `all` (princípio de maior abrangência).
+
 - `spec` — afeta requisitos, critérios de aceite ou escopo
 - `plan` — afeta tarefas, ondas, dependências ou verificação
 - `execute` — afeta a implementação da tarefa atual ou próxima