oxe-cc 0.5.0 → 0.6.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.cursor/commands/oxe-loop.md +11 -0
- package/.cursor/commands/oxe-project.md +11 -0
- package/.cursor/commands/oxe-retro.md +11 -0
- package/.cursor/commands/oxe-security.md +11 -0
- package/.cursor/commands/oxe.md +9 -0
- package/.github/prompts/oxe-loop.prompt.md +12 -0
- package/.github/prompts/oxe-project.prompt.md +12 -0
- package/.github/prompts/oxe-retro.prompt.md +12 -0
- package/.github/prompts/oxe-security.prompt.md +12 -0
- package/.github/prompts/oxe.prompt.md +12 -0
- package/README.md +323 -307
- package/bin/banner.txt +1 -1
- package/bin/oxe-cc.js +1 -1
- package/commands/oxe/loop.md +17 -0
- package/commands/oxe/oxe.md +16 -0
- package/commands/oxe/project.md +16 -0
- package/commands/oxe/retro.md +16 -0
- package/commands/oxe/security.md +16 -0
- package/oxe/templates/LESSONS.template.md +43 -0
- package/oxe/templates/PLAN.template.md +2 -1
- package/oxe/templates/SECURITY.template.md +72 -0
- package/oxe/templates/plan-agents.template.json +3 -2
- package/oxe/workflows/execute.md +22 -0
- package/oxe/workflows/help.md +41 -24
- package/oxe/workflows/loop.md +57 -0
- package/oxe/workflows/obs.md +7 -0
- package/oxe/workflows/oxe.md +115 -0
- package/oxe/workflows/plan-agent.md +24 -7
- package/oxe/workflows/plan.md +22 -6
- package/oxe/workflows/project.md +50 -0
- package/oxe/workflows/research.md +16 -0
- package/oxe/workflows/retro.md +62 -0
- package/oxe/workflows/scan.md +14 -0
- package/oxe/workflows/security.md +61 -0
- package/oxe/workflows/spec.md +26 -0
- package/oxe/workflows/verify.md +7 -3
- package/package.json +1 -1
package/bin/banner.txt
CHANGED
package/bin/oxe-cc.js
CHANGED
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oxe:loop
|
|
3
|
+
description: OXE — Execução iterativa de onda com retries automáticos e diagnóstico inline
|
|
4
|
+
argument-hint: "onda <N> [max:<tentativas>]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Edit
|
|
12
|
+
- Task
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
**Workflow canônico:** `oxe/workflows/loop.md`
|
|
16
|
+
|
|
17
|
+
Execute integralmente esse ficheiro na raiz do repositório. `$ARGUMENTS` = onda alvo e máximo de tentativas. Pré-requisito: `.oxe/PLAN.md`.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oxe
|
|
3
|
+
description: OXE — Entrada universal: próximo passo, roteamento de linguagem natural ou help dos 8 comandos essenciais
|
|
4
|
+
argument-hint: "[contexto | 'help' | vazio]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Task
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
**Workflow canônico:** `oxe/workflows/oxe.md`
|
|
15
|
+
|
|
16
|
+
Execute integralmente esse ficheiro. `$ARGUMENTS`: vazio → próximo passo; texto → roteamento inteligente; "help" → 8 comandos essenciais.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oxe:project
|
|
3
|
+
description: OXE — Gestão de projeto: milestone (M-NN), workstream (trilhas paralelas), checkpoint (snapshot)
|
|
4
|
+
argument-hint: "milestone new|complete|status|audit | workstream new|switch|list|close <nome> | checkpoint [slug]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Task
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
**Workflow canônico:** `oxe/workflows/project.md`
|
|
15
|
+
|
|
16
|
+
Execute integralmente esse ficheiro. `$ARGUMENTS` = subcomando. Sem argumento: mostra status atual (milestone ativo, workstreams, último checkpoint).
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oxe:retro
|
|
3
|
+
description: OXE — Retrospectiva de ciclo: sintetiza lições prescritivas em .oxe/LESSONS.md (alimenta ciclos futuros automaticamente)
|
|
4
|
+
argument-hint: "[opcional: contexto sobre o ciclo]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Task
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
**Workflow canônico:** `oxe/workflows/retro.md`
|
|
15
|
+
|
|
16
|
+
Execute integralmente esse ficheiro. Lê VERIFY.md, FORENSICS.md, SUMMARY.md para sintetizar 3–5 lições prescritivas. `$ARGUMENTS` = contexto extra opcional.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oxe:security
|
|
3
|
+
description: OXE — Auditoria de segurança OWASP (.oxe/SECURITY.md): P0 crítico / P1 alto / P2 médio
|
|
4
|
+
argument-hint: "[opcional: categoria OWASP, módulo ou arquivo]"
|
|
5
|
+
allowed-tools:
|
|
6
|
+
- Read
|
|
7
|
+
- Bash
|
|
8
|
+
- Glob
|
|
9
|
+
- Grep
|
|
10
|
+
- Write
|
|
11
|
+
- Task
|
|
12
|
+
---
|
|
13
|
+
|
|
14
|
+
**Workflow canônico:** `oxe/workflows/security.md`
|
|
15
|
+
|
|
16
|
+
Execute integralmente esse ficheiro na raiz do repositório. Lê `STACK.md` para determinar categorias OWASP pertinentes. `$ARGUMENTS` = foco opcional.
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
oxe_doc: lessons
|
|
3
|
+
updated: YYYY-MM-DD
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Lições Aprendidas OXE
|
|
7
|
+
|
|
8
|
+
<!-- Consumido automaticamente por /oxe-spec, /oxe-plan, /oxe-execute, /oxe-verify -->
|
|
9
|
+
<!-- Cada entrada é PRESCRITIVA: diz o que fazer diferente, não apenas o que aconteceu -->
|
|
10
|
+
|
|
11
|
+
| Ciclo | Data | Tipo | Lição (resumo) | Aplicar em | Status |
|
|
12
|
+
|-------|------|------|----------------|------------|--------|
|
|
13
|
+
| C-01 | YYYY-MM-DD | plan | Tarefas de integração requerem Complexidade L mínimo | /oxe-plan | ativo |
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
### C-01 — YYYY-MM-DD
|
|
18
|
+
|
|
19
|
+
**Fonte:** VERIFY.md (gaps) + FORENSICS.md (causa raiz)
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
**L-01** · Tipo: `plan`
|
|
24
|
+
**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.
|
|
25
|
+
**Raiz do problema:** T4 foi marcada `M` mas envolveu 3 serviços externos — estorou 2 ondas.
|
|
26
|
+
**Aplicar em:** `/oxe-plan` — ao planejar tarefas com `INTEGRATIONS.md` externos, elevar complexidade automaticamente.
|
|
27
|
+
**Status:** ativo
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
31
|
+
**L-02** · Tipo: `spec`
|
|
32
|
+
**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.
|
|
33
|
+
**Raiz do problema:** A3 dizia "resposta rápida" — verify não conseguiu evidência objetiva.
|
|
34
|
+
**Aplicar em:** `/oxe-spec` Fase 3 — ao criar critérios de performance, pedir métrica específica antes de aprovar o requisito.
|
|
35
|
+
**Status:** ativo
|
|
36
|
+
|
|
37
|
+
---
|
|
38
|
+
|
|
39
|
+
**L-03** · Tipo: `process`
|
|
40
|
+
**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.
|
|
41
|
+
**Raiz do problema:** plano solo com auth + API + UI causou tarefas que misturavam contexto de 2 domínios.
|
|
42
|
+
**Aplicar em:** `/oxe-plan` — gate de sugestão de `--agents` já existe; reforçar como obrigatório para 3+.
|
|
43
|
+
**Status:** ativo
|
|
@@ -39,10 +39,11 @@ inputs: []
|
|
|
39
39
|
- **Arquivos prováveis:** `…`
|
|
40
40
|
- **Depende de:** —
|
|
41
41
|
- **Onda:** 1
|
|
42
|
-
- **
|
|
42
|
+
- **Complexidade:** S
|
|
43
43
|
- **Verificar:**
|
|
44
44
|
- Comando: `…`
|
|
45
45
|
- Manual: (opcional) …
|
|
46
|
+
- **Implementar:** o mínimo para fazer a verificação acima passar.
|
|
46
47
|
- **Aceite vinculado:** A1, A2 (IDs da tabela de critérios em SPEC.md)
|
|
47
48
|
|
|
48
49
|
---
|
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
---
|
|
2
|
+
oxe_doc: security
|
|
3
|
+
status: draft
|
|
4
|
+
updated: YYYY-MM-DD
|
|
5
|
+
stack_ref: .oxe/codebase/STACK.md
|
|
6
|
+
plan_ref: .oxe/PLAN.md
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
# Auditoria de Segurança OXE
|
|
10
|
+
|
|
11
|
+
## Stack e escopo
|
|
12
|
+
|
|
13
|
+
**Stack identificado:** [linguagem, framework, DB, auth]
|
|
14
|
+
**Categorias OWASP avaliadas:** A01, A02, A03, ...
|
|
15
|
+
**Categorias descartadas:** A04 (motivo), A08 (motivo), ...
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
|
|
19
|
+
## Achados
|
|
20
|
+
|
|
21
|
+
### P0 — Crítico (requer ação imediata)
|
|
22
|
+
|
|
23
|
+
| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
|
|
24
|
+
|----|-----------|--------------|-------------------|--------------|--------|
|
|
25
|
+
| S-01 | A07 — Auth | `src/auth/login.ts:42` | Senha comparada sem hash | Usar bcrypt/argon2 | T_new |
|
|
26
|
+
|
|
27
|
+
### P1 — Alto (antes do próximo deploy)
|
|
28
|
+
|
|
29
|
+
| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
|
|
30
|
+
|----|-----------|--------------|-------------------|--------------|--------|
|
|
31
|
+
| S-02 | A05 — Config | `.env.example:8` | JWT_SECRET sem rotação documentada | Documentar política de rotação | T3 |
|
|
32
|
+
|
|
33
|
+
### P2 — Médio (ação recomendada, compensação aceitável)
|
|
34
|
+
|
|
35
|
+
| ID | Categoria | Arquivo:linha | Padrão encontrado | Recomendação | Tarefa |
|
|
36
|
+
|----|-----------|--------------|-------------------|--------------|--------|
|
|
37
|
+
| 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 |
|
|
38
|
+
|
|
39
|
+
---
|
|
40
|
+
|
|
41
|
+
## Resultado por categoria
|
|
42
|
+
|
|
43
|
+
| Categoria OWASP | Status | Achados |
|
|
44
|
+
|-----------------|--------|---------|
|
|
45
|
+
| A01 — Broken Access Control | ✅ Sem achados | — |
|
|
46
|
+
| A02 — Cryptographic Failures | ⚠️ P1 | S-02 |
|
|
47
|
+
| A03 — Injection | ✅ Sem achados | — |
|
|
48
|
+
| A05 — Security Misconfiguration | ⚠️ P1 | S-02 |
|
|
49
|
+
| A07 — Authentication Failures | ❌ P0 | S-01 |
|
|
50
|
+
| A09 — Logging & Monitoring | ⚠️ P2 | S-03 |
|
|
51
|
+
|
|
52
|
+
---
|
|
53
|
+
|
|
54
|
+
## Sugestões de tarefas novas
|
|
55
|
+
|
|
56
|
+
```
|
|
57
|
+
T_new-S01: Implementar hash de senha com bcrypt (custo ≥ 12)
|
|
58
|
+
Verificar: login falha com senha errada; hash visível no DB.
|
|
59
|
+
Aceite vinculado: [A* de segurança se existir na SPEC]
|
|
60
|
+
|
|
61
|
+
T_new-S03: Filtrar stack traces em logs de produção
|
|
62
|
+
Verificar: log em NODE_ENV=production não expõe stacktrace.
|
|
63
|
+
Aceite vinculado: —
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
---
|
|
67
|
+
|
|
68
|
+
## Próximo passo
|
|
69
|
+
|
|
70
|
+
- **P0 presente:** ação obrigatória antes de qualquer deploy — criar tarefas e adicionar ao PLAN via `/oxe-plan --replan`.
|
|
71
|
+
- **Apenas P1/P2:** priorizar P1 na próxima onda; P2 pode ir para backlog v2.
|
|
72
|
+
- **Sem achados:** registrar como "auditoria limpa em YYYY-MM-DD" e prosseguir.
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"oxePlanAgentsSchema":
|
|
2
|
+
"oxePlanAgentsSchema": 3,
|
|
3
3
|
"runId": "oxe-YYYY-MM-DD-substituir-por-id-opaco",
|
|
4
4
|
"lifecycle": {
|
|
5
5
|
"status": "pending_execute",
|
|
@@ -18,7 +18,8 @@
|
|
|
18
18
|
"taskIds": ["T1"],
|
|
19
19
|
"dependencies": [],
|
|
20
20
|
"inputs": [".oxe/STATE.md", ".oxe/SPEC.md"],
|
|
21
|
-
"outputs": ["src/example.ts"]
|
|
21
|
+
"outputs": ["src/example.ts"],
|
|
22
|
+
"model_hint": "balanced"
|
|
22
23
|
}
|
|
23
24
|
],
|
|
24
25
|
"execution": {
|
package/oxe/workflows/execute.md
CHANGED
|
@@ -72,11 +72,33 @@ Este plano tem [N] tarefas em [X] ondas. Como quer executar?
|
|
|
72
72
|
**Persistir escolha:** registrar em STATE.md: `execute_mode: completo | por_onda | por_tarefa`. Se STATE já tiver o campo, não perguntar novamente — usar o modo armazenado.
|
|
73
73
|
</execution_mode_selection>
|
|
74
74
|
|
|
75
|
+
<failure_mode>
|
|
76
|
+
## Modo de falha inline (Verificar falha durante execute)
|
|
77
|
+
|
|
78
|
+
Quando o comando `**Verificar:**` de uma tarefa `Tn` falha, **não parar silenciosamente**. Executar este ciclo inline sem exigir que o usuário chame `/oxe-debug` separadamente:
|
|
79
|
+
|
|
80
|
+
1. **Diagnóstico rápido:** listar 2-3 hipóteses de causa baseadas no output de erro.
|
|
81
|
+
2. **Fix mais provável:** aplicar o fix para a hipótese #1.
|
|
82
|
+
3. **Re-verificar:** rodar o `Verificar` novamente.
|
|
83
|
+
4. Se passou: continuar onda normalmente; registrar na onda que houve 1 iteração de fix.
|
|
84
|
+
5. Se falhou novamente (2ª tentativa): aplicar hipótese #2 e tentar 1 vez mais.
|
|
85
|
+
6. Se falhou após 2 tentativas: **pausar** — exibir as hipóteses testadas, evidências coletadas, e sugerir `/oxe-forensics` com contexto completo. Registrar em STATE.md: `execute_blocked: Tn | motivo`.
|
|
86
|
+
|
|
87
|
+
**Auto-loop no Modo B:** se `execute_mode: por_onda` e `loop_max` > 1 em STATE.md, o ciclo de retry roda automaticamente até `loop_max` tentativas antes de escalar para forensics.
|
|
88
|
+
</failure_mode>
|
|
89
|
+
|
|
75
90
|
<context>
|
|
76
91
|
**Observações pendentes:** verificar `.oxe/OBSERVATIONS.md` no início de cada onda. Se houver entradas `pendente` com impacto `execute` ou `all`, incorporar no trabalho da onda atual e marcá-las `incorporada → execute (data)`.
|
|
77
92
|
|
|
78
93
|
**Quick-agents (lean PDDA):** se existir **`.oxe/quick-agents.json`** com `status: active` e a execução for baseada em **`QUICK.md`** (não há PLAN.md), adotar o `role` e `persona` de cada agente para os `steps[]` atribuídos. Ao concluir todos os steps, marcar `quick-agents.json` → `status: done` e sugerir `/oxe-verify`.
|
|
79
94
|
|
|
95
|
+
**Model hints (blueprint com agentes):** ao apresentar a atribuição de cada agente no início da onda, exibir `model_hint` se presente:
|
|
96
|
+
```
|
|
97
|
+
Agente: agent-auth — "Especialista em JWT" [modelo: powerful]
|
|
98
|
+
Tarefas: T1, T2
|
|
99
|
+
```
|
|
100
|
+
Se `model_hint` estiver ausente, não exibir a linha. O usuário pode configurar o modelo no IDE antes de iniciar aquele agente.
|
|
101
|
+
|
|
80
102
|
**Blueprint plan-agent (Modo com Agentes):** adotar `role`/`scope` de **`.oxe/plan-agents.json`** SOMENTE quando:
|
|
81
103
|
1. `lifecycle.status` ∈ `{ pending_execute, executing }` (não usar se `closed` ou `invalidated`).
|
|
82
104
|
2. **`runId`** no JSON coincide com **`run_id`** no STATE.md (secção Blueprint de agentes).
|
package/oxe/workflows/help.md
CHANGED
|
@@ -11,11 +11,30 @@ No **projeto**, os passos canónicos estão em **`.oxe/workflows/*.md`** (layout
|
|
|
11
11
|
</context>
|
|
12
12
|
|
|
13
13
|
<output>
|
|
14
|
+
## Os 8 comandos essenciais
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
/oxe → onde estou / o que faço / help (entrada universal)
|
|
18
|
+
/oxe-obs → registrei algo importante — incorporado automaticamente nos próximos passos
|
|
19
|
+
/oxe-quick → tarefa pequena, sem cerimônia (com agentes lean quando necessário)
|
|
20
|
+
/oxe-scan → mapeia o projeto (ou atualiza o mapa se já existir)
|
|
21
|
+
/oxe-spec → nova feature: perguntas → pesquisa → requisitos → roteiro → aprovação
|
|
22
|
+
/oxe-plan → tarefas por onda (--agents para blueprint multi-agente)
|
|
23
|
+
/oxe-execute → implementar (A: 1 sessão | B: por onda | C: por tarefa)
|
|
24
|
+
/oxe-verify → validar (camadas 5+6 opcionais via config: gaps + segurança)
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Tudo o mais é ativado automaticamente por contexto, por config, ou existe como escape hatch.
|
|
28
|
+
|
|
29
|
+
---
|
|
30
|
+
|
|
14
31
|
## Integrações principais (referência)
|
|
15
32
|
|
|
16
33
|
### Cursor
|
|
17
34
|
|
|
18
|
-
Slash commands: `/oxe
|
|
35
|
+
Slash commands essenciais: `/oxe`, `/oxe-obs`, `/oxe-quick`, `/oxe-scan`, `/oxe-spec`, `/oxe-plan`, `/oxe-execute`, `/oxe-verify`
|
|
36
|
+
|
|
37
|
+
Slash commands completos: `/oxe-discuss`, `/oxe-plan-agent`, `/oxe-project`, `/oxe-loop`, `/oxe-security`, `/oxe-update`, `/oxe-forensics`, `/oxe-debug`, `/oxe-route`, `/oxe-research`, `/oxe-validate-gaps`, `/oxe-compact`, `/oxe-checkpoint`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-milestone`, `/oxe-workstream`, `/oxe-next`, `/oxe-help` (instalados em `~/.cursor/commands/` pelo `oxe-cc`). **Review de PR:** no Cursor não há slash dedicado — peça em linguagem natural seguindo `oxe/workflows/review-pr.md` em contexto.
|
|
19
38
|
|
|
20
39
|
### GitHub Copilot (VS Code)
|
|
21
40
|
|
|
@@ -49,29 +68,27 @@ Com **`compact_max_age_days`** em `.oxe/config.json` (ver `oxe/templates/CONFIG.
|
|
|
49
68
|
|
|
50
69
|
## Fluxo completo
|
|
51
70
|
|
|
52
|
-
0. **obs** *(qualquer momento)* — `/oxe-obs` registra uma observação contextual
|
|
53
|
-
1. **scan** — após clonar ou quando o
|
|
54
|
-
2. **spec** — fluxo em **5 fases**: perguntas (máx 3 rodadas) → pesquisa (
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
- **`/oxe-
|
|
68
|
-
- **`/oxe-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
- **`/oxe-compact`** — **refresh do projeto**: compara **`.oxe/codebase/*.md`** ao repositório atual, **atualiza** os sete mapas (incremental ou bootstrap como `scan.md` se faltar base), escreve **`.oxe/CODEBASE-DELTA.md`** (o que mudou na documentação) e **`.oxe/RESUME.md`** (trilha OXE + ponte para o delta). Rotina de desenvolvimento; **não** está ligado a limites de chat ou a ferramentas específicas (ver `compact.md`). *Exemplo:* scan mapeou **Angular 17**; após migração implementada para **21**, o compact **corrige** `STACK.md`/testes/convenções face ao repo — intenção: **documentação OXE = código atual**, não refazer scan completo só por bump de major.
|
|
74
|
-
- **`/oxe-checkpoint`** — **snapshot de sessão**: **`.oxe/checkpoints/…md`** + **`.oxe/CHECKPOINTS.md`**; marco nomeado sem apagar SPEC/PLAN (ver `checkpoint.md`).
|
|
71
|
+
0. **obs** *(qualquer momento)* — `/oxe-obs` registra uma observação contextual; incorporada automaticamente no próximo spec/plan/execute sem re-explicar.
|
|
72
|
+
1. **scan** — após clonar ou quando o codebase mudar. **Inteligente:** se `.oxe/codebase/` já existir, opera em modo refresh (incremental) automaticamente — sem precisar chamar `/oxe-compact` separadamente. Use `--full` para forçar scan completo. Repositórios **legado** (COBOL, JCL, VB6): aplica `legacy-brownfield.md` automaticamente.
|
|
73
|
+
2. **spec** — fluxo em **5 fases**: perguntas (máx 3 rodadas) → pesquisa (proposta inline na Fase 2, sem sair do spec) → requisitos R-ID (v1/v2/fora) → roteiro (`.oxe/ROADMAP.md`) → aprovação. Se `discuss_before_plan: true` na config, o próximo passo após aprovação é `oxe:discuss` antes de plan.
|
|
74
|
+
3. **plan** — plano executável + **Verificar** por tarefa. Se 3+ domínios distintos, **sugere automaticamente** blueprint de agentes (`/oxe-plan --agents`). Sem `--agents`: solo. Com `--agents`: gera também `plan-agents.json` (schema 3 com `model_hint`).
|
|
75
|
+
4. **execute** — modo selecionado 1 vez: **A) Completo** (1 sessão), **B) Por onda**, **C) Por tarefa**. Se Verificar falhar inline: diagnóstico automático (2-3 hipóteses + fix), sem precisar chamar `/oxe-debug` separadamente. Escalação para `/oxe-forensics` só se esgotar tentativas.
|
|
76
|
+
5. **verify** — até **6 camadas** por config: auditoria pré-exec, tarefas + critérios A*, fidelidade D-NN, UAT, **gaps de cobertura** (camada 5 — `verification_depth: "thorough"`), **segurança OWASP** (camada 6 — `security_in_verify: true`). Sem comandos extras.
|
|
77
|
+
6. **retro** *(opcional, recomendado após verify_complete)* — `/oxe-retro` sintetiza 3–5 lições prescritivas em `.oxe/LESSONS.md`. Cada lição diz **o que fazer diferente** no próximo ciclo — consumida automaticamente pelo próximo spec/plan.
|
|
78
|
+
7. **→ próximo ciclo** — spec/plan do próximo ciclo lê LESSONS.md automaticamente. Os erros do ciclo anterior não se repetem.
|
|
79
|
+
|
|
80
|
+
**Escape hatches (não precisam ser decorados — aparecem quando necessários):**
|
|
81
|
+
|
|
82
|
+
- **`/oxe-forensics`** — sugerido automaticamente pelo execute/verify quando falha persiste. Diagnóstico pós-falha + 1 caminho de reentrada.
|
|
83
|
+
- **`/oxe-debug`** — diagnóstico técnico inline durante execute (já integrado ao execute; disponível standalone para controle explícito).
|
|
84
|
+
- **`/oxe-loop`** — iteração até verify passar (disponível standalone; integrado ao Modo B do execute via `loop_max`).
|
|
85
|
+
- **`/oxe-research`** — notas datadas em `.oxe/research/` para spikes, mapas de sistema, engenharia reversa.
|
|
86
|
+
- **`/oxe-route`** — traduz linguagem natural → comando. Equivalente a `/oxe [texto]`.
|
|
87
|
+
- **`/oxe-compact`** — refresh explícito do codebase. Equivalente a `/oxe-scan` sem `--full`.
|
|
88
|
+
|
|
89
|
+
**Gestão de projeto (`/oxe-project`):**
|
|
90
|
+
|
|
91
|
+
Um único comando para: `milestone new|complete|status|audit`, `workstream new|switch|list|close <nome>`, `checkpoint [slug]`. Sem argumento: mostra status atual.
|
|
75
92
|
|
|
76
93
|
**Vertical UI (opcional, mesma trilha):**
|
|
77
94
|
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# OXE — Workflow: loop (execução iterativa até verificação passar)
|
|
2
|
+
|
|
3
|
+
<objective>
|
|
4
|
+
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.
|
|
5
|
+
|
|
6
|
+
Quando verify falha, não interrompe — diagnostica (2-3 hipóteses), corrige, tenta de novo. Escala para **`/oxe-forensics`** apenas quando esgota as tentativas.
|
|
7
|
+
</objective>
|
|
8
|
+
|
|
9
|
+
<context>
|
|
10
|
+
- **Pré-requisito:** `.oxe/PLAN.md` existente com pelo menos 1 onda; `STATE.md` com fase ≥ `plan_ready`.
|
|
11
|
+
- **Máximo de iterações:** padrão = 3; configurável via argumento `max:<N>` (ex.: `/oxe-loop onda 2 max:5`). Nunca exceder 10.
|
|
12
|
+
- **Artefato:** não cria novos arquivos — atualiza `STATE.md` com campos `loop_*` e registra cada iteração como bloco inline no chat.
|
|
13
|
+
- **Escalação:** se esgotou tentativas e ainda falhou → registrar estado em STATE.md + sugerir `/oxe-forensics` com contexto das hipóteses já tentadas.
|
|
14
|
+
- **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.
|
|
15
|
+
</context>
|
|
16
|
+
|
|
17
|
+
<loop_state>
|
|
18
|
+
## Campos em STATE.md durante o loop
|
|
19
|
+
|
|
20
|
+
```yaml
|
|
21
|
+
loop_onda: 2 # número da onda sendo executada
|
|
22
|
+
loop_iteracao: 2/3 # tentativa atual / máximo
|
|
23
|
+
loop_status: retrying # retrying | passed | escalated
|
|
24
|
+
loop_hipoteses: ["H1: ...", "H2: ..."] # hipóteses da última falha
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
Limpar campos `loop_*` ao concluir com `passed` (ou manter `escalated` se escalou para forensics).
|
|
28
|
+
</loop_state>
|
|
29
|
+
|
|
30
|
+
<process>
|
|
31
|
+
1. Ler `.oxe/STATE.md` e `.oxe/PLAN.md`. Identificar a onda alvo (argumento do usuário ou próxima onda pendente em STATE).
|
|
32
|
+
2. Registrar em STATE.md: `loop_onda: N`, `loop_iteracao: 1/<max>`, `loop_status: retrying`.
|
|
33
|
+
3. **Iteração:**
|
|
34
|
+
a. Listar tarefas da onda N com seus comandos `**Verificar:**`.
|
|
35
|
+
b. Implementar todas as tarefas da onda (seguindo `execute.md` `<modo_solo>`).
|
|
36
|
+
c. Executar os comandos `Verificar` de cada `Tn`.
|
|
37
|
+
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`.
|
|
38
|
+
e. **Se algum falhou:**
|
|
39
|
+
- Listar 2-3 hipóteses de causa (baseado no erro/output da verificação).
|
|
40
|
+
- Registrar `loop_hipoteses` em STATE.md.
|
|
41
|
+
- Incrementar iteração: `loop_iteracao: K+1/<max>`.
|
|
42
|
+
- Se `K+1 > max`: ir para passo 4 (escalação).
|
|
43
|
+
- Senão: aplicar fix para a hipótese mais provável → voltar a `c`.
|
|
44
|
+
4. **Escalação (tentativas esgotadas):**
|
|
45
|
+
- Registrar `loop_status: escalated` em STATE.md.
|
|
46
|
+
- Exibir no chat: tentativas realizadas, hipóteses testadas, evidência de cada falha.
|
|
47
|
+
- Sugerir `/oxe-forensics` com contexto: "onda N falhou após <max> tentativas — hipóteses testadas: H1, H2, H3".
|
|
48
|
+
</process>
|
|
49
|
+
|
|
50
|
+
<success_criteria>
|
|
51
|
+
- [ ] STATE.md tem campos `loop_*` atualizados a cada iteração.
|
|
52
|
+
- [ ] Cada falha gera 2-3 hipóteses registradas antes de tentar fix.
|
|
53
|
+
- [ ] Ao passar: campos `loop_*` limpos; onda marcada como concluída em STATE.md.
|
|
54
|
+
- [ ] Ao esgotar: `loop_status: escalated` + sugestão de `/oxe-forensics` com contexto completo.
|
|
55
|
+
- [ ] Nunca excede `max` iterações configurado.
|
|
56
|
+
- [ ] Não altera `.oxe/PLAN.md` (só implementa o que já está planejado).
|
|
57
|
+
</success_criteria>
|
package/oxe/workflows/obs.md
CHANGED
|
@@ -31,6 +31,8 @@ Arquivo: **`.oxe/OBSERVATIONS.md`**
|
|
|
31
31
|
|
|
32
32
|
### OBS-001 — 2026-04-04 | execute/T3
|
|
33
33
|
**Impacto:** spec, plan
|
|
34
|
+
**Afeta (spec):** R3, R5
|
|
35
|
+
**Afeta (plan):** T4, T7
|
|
34
36
|
**Status:** pendente
|
|
35
37
|
|
|
36
38
|
JWT expiration deve ser configurável via `JWT_EXPIRES_IN` env var, não hardcoded 7d.
|
|
@@ -59,6 +61,11 @@ API deve retornar mensagens de erro em português do Brasil.
|
|
|
59
61
|
1. Ler **`.oxe/STATE.md`**: capturar `phase`, `last_task` ou tarefa ativa na onda, `active_workstream`.
|
|
60
62
|
2. Determinar o **próximo ID** (OBS-NNN): contar entradas existentes em `.oxe/OBSERVATIONS.md` ou começar em OBS-001.
|
|
61
63
|
3. Classificar o **impacto** automaticamente com base no texto; se ambíguo, usar `all`.
|
|
64
|
+
3b. **Propagação automática de constraints:**
|
|
65
|
+
- Se existir **`.oxe/SPEC.md`**: ler a tabela de requisitos (R-ID) e critérios (A*) e identificar quais são diretamente afetados pelo texto da observação. Registrar em `**Afeta (spec):**`.
|
|
66
|
+
- Se existir **`.oxe/PLAN.md`**: ler as tarefas (Tn) e identificar quais podem precisar de ajuste no campo `Verificar` ou `Implementar`. Registrar em `**Afeta (plan):**`.
|
|
67
|
+
- Se nenhum R-ID ou Tn identificável: registrar `**Afeta:** (a cruzar na próxima incorporação)`.
|
|
68
|
+
- Esta propagação é automática e não requer input do usuário.
|
|
62
69
|
4. Criar ou atualizar **`.oxe/OBSERVATIONS.md`**:
|
|
63
70
|
- Adicionar linha na tabela de índice.
|
|
64
71
|
- Adicionar seção `### OBS-NNN` com contexto, impacto, status e texto.
|
|
@@ -0,0 +1,115 @@
|
|
|
1
|
+
# OXE — Workflow: oxe (entrada universal)
|
|
2
|
+
|
|
3
|
+
<objective>
|
|
4
|
+
Ponto de entrada inteligente do OXE. Faz uma de três coisas dependendo do input do usuário:
|
|
5
|
+
|
|
6
|
+
1. **Sem input / "o que faço agora?"** → lê `STATE.md` e recomenda exatamente 1 próximo passo (lógica de `next.md`).
|
|
7
|
+
2. **Input em linguagem natural** (ex.: "quero adicionar login", "preciso revisar um PR") → traduz para o comando OXE correto e executa ou orienta (lógica de `route.md`).
|
|
8
|
+
3. **"help", "o que é OXE" ou "comandos"** → apresenta o fluxo dos 8 comandos essenciais e a cadeia canônica.
|
|
9
|
+
|
|
10
|
+
**Princípio:** o usuário não precisa decorar o nome do comando — `/oxe [contexto]` resolve.
|
|
11
|
+
</objective>
|
|
12
|
+
|
|
13
|
+
<context>
|
|
14
|
+
- Este workflow **não gera artefatos** por conta própria. Ele orienta ou delega para o workflow correto.
|
|
15
|
+
- Lê `STATE.md` quando disponível para personalizar a resposta ao estado atual do projeto.
|
|
16
|
+
- Quando o input for claro o suficiente para um workflow específico, **executar diretamente** esse workflow (carregar e seguir o `.md` correspondente) em vez de só sugerir o comando.
|
|
17
|
+
- Quando houver ambiguidade genuína, apresentar 2 opções e pedir escolha — nunca listas longas.
|
|
18
|
+
</context>
|
|
19
|
+
|
|
20
|
+
<modo_status>
|
|
21
|
+
## Modo: Status + Próximo Passo (sem input ou "o que faço agora?")
|
|
22
|
+
|
|
23
|
+
Aplicar a lógica completa de `oxe/workflows/next.md`:
|
|
24
|
+
|
|
25
|
+
1. Se `.oxe/` ou `STATE.md` não existir → **scan** (`npx oxe-cc@latest` primeiro se OXE não instalado)
|
|
26
|
+
2. Se `.oxe/codebase/` incompleto e não for quick isolado → **scan**
|
|
27
|
+
3. Se `quick_active` ou `QUICK.md` sem `PLAN.md` → avaliar promoção (ver `next.md`)
|
|
28
|
+
4. Se sem `SPEC.md` → **spec**
|
|
29
|
+
5. Se SPEC mas sem PLAN → verificar `discuss_before_plan` → **discuss** ou **plan**
|
|
30
|
+
6. Se PLAN sem VERIFY pós-implementação → **execute** ou **verify**
|
|
31
|
+
7. Se VERIFY com falha → **plan --replan**
|
|
32
|
+
8. Se VERIFY OK → próxima feature ou milestone
|
|
33
|
+
|
|
34
|
+
**Saída:** exatamente 1 passo, 1 comando, 1 frase de justificativa.
|
|
35
|
+
</modo_status>
|
|
36
|
+
|
|
37
|
+
<modo_route>
|
|
38
|
+
## Modo: Roteamento de Linguagem Natural (input com contexto)
|
|
39
|
+
|
|
40
|
+
Mapear o input para o workflow correto e executar ou orientar:
|
|
41
|
+
|
|
42
|
+
| Se o usuário disser | Executar |
|
|
43
|
+
|---------------------|----------|
|
|
44
|
+
| "quero [feature / tarefa / entrega]" | Verificar estado → **spec** ou **quick** |
|
|
45
|
+
| "analisa / mapeia o projeto" | **scan** (modo refresh se codebase/ existir) |
|
|
46
|
+
| "pesquisa / spike / quero entender X" | **research** |
|
|
47
|
+
| "revisa PR / diff" | **review-pr** |
|
|
48
|
+
| "auditoria de segurança" | **security** |
|
|
49
|
+
| "valida / verifica" | **verify** |
|
|
50
|
+
| "milestone / release / versão" | **project milestone** |
|
|
51
|
+
| "trilha paralela / workstream" | **project workstream** |
|
|
52
|
+
| "snapshot / checkpoint" | **project checkpoint** |
|
|
53
|
+
| "recuperação / erro / algo quebrou" | **forensics** |
|
|
54
|
+
| "debug / teste falhando" | **debug** |
|
|
55
|
+
| "obs / observação / nota" | **obs** |
|
|
56
|
+
| "atualiza / update OXE" | **update** |
|
|
57
|
+
|
|
58
|
+
Se o input não mapear claramente → apresentar 2 opções mais prováveis e perguntar.
|
|
59
|
+
</modo_route>
|
|
60
|
+
|
|
61
|
+
<modo_help>
|
|
62
|
+
## Modo: Help (quando o usuário pede "help", "o que é OXE", "comandos")
|
|
63
|
+
|
|
64
|
+
Apresentar de forma concisa:
|
|
65
|
+
|
|
66
|
+
### Os 8 comandos que você precisa conhecer
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
/oxe → onde estou / o que faço / help
|
|
70
|
+
/oxe-obs → registrei algo importante agora
|
|
71
|
+
/oxe-quick → tarefa pequena, sem cerimônia
|
|
72
|
+
/oxe-scan → mapeia o projeto (ou atualiza o mapa)
|
|
73
|
+
/oxe-spec → nova feature ou entrega: perguntas → requisitos → roteiro
|
|
74
|
+
/oxe-plan → detalhar em tarefas (--agents para multi-agente)
|
|
75
|
+
/oxe-execute → implementar (A: completo | B: por onda | C: por tarefa)
|
|
76
|
+
/oxe-verify → validar que está pronto
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
### A cadeia
|
|
80
|
+
|
|
81
|
+
```
|
|
82
|
+
/oxe-obs (qualquer momento)
|
|
83
|
+
↓
|
|
84
|
+
/oxe-scan → /oxe-spec → /oxe-plan → /oxe-execute → /oxe-verify → /oxe-retro
|
|
85
|
+
↓
|
|
86
|
+
/oxe-quick (trabalho pequeno)
|
|
87
|
+
```
|
|
88
|
+
|
|
89
|
+
### Para saber o próximo passo agora
|
|
90
|
+
|
|
91
|
+
```
|
|
92
|
+
/oxe
|
|
93
|
+
```
|
|
94
|
+
|
|
95
|
+
### Escape hatches (não precisa decorar — aparecem quando necessários)
|
|
96
|
+
|
|
97
|
+
`/oxe-research`, `/oxe-forensics`, `/oxe-debug`, `/oxe-loop`, `/oxe-security`,
|
|
98
|
+
`/oxe-validate-gaps`, `/oxe-ui-spec`, `/oxe-ui-review`, `/oxe-review-pr`,
|
|
99
|
+
`/oxe-project` (milestone, workstream, checkpoint)
|
|
100
|
+
</modo_help>
|
|
101
|
+
|
|
102
|
+
<process>
|
|
103
|
+
1. Verificar se há input adicional na mensagem:
|
|
104
|
+
- **Sem input ou "next / o que faço / status":** aplicar `<modo_status>`.
|
|
105
|
+
- **"help / comandos / o que é OXE":** aplicar `<modo_help>`.
|
|
106
|
+
- **Qualquer outra coisa (linguagem natural com contexto):** aplicar `<modo_route>` e, se o workflow for claro, carregar e executar diretamente o `oxe/workflows/<nome>.md` correspondente.
|
|
107
|
+
2. Nunca produzir listas longas de alternativas. Um passo, um comando, uma frase.
|
|
108
|
+
3. Se o workflow executado diretamente gerar artefatos, reportar no chat conforme esse workflow.
|
|
109
|
+
</process>
|
|
110
|
+
|
|
111
|
+
<success_criteria>
|
|
112
|
+
- [ ] Usuário recebe exatamente 1 próximo passo (modo status) OU 1 workflow executado (modo route) OU o bloco help compacto (modo help).
|
|
113
|
+
- [ ] Nenhum artefato criado por este workflow diretamente (a menos que o workflow delegado o faça).
|
|
114
|
+
- [ ] Nunca lista mais de 2 alternativas ao mesmo tempo.
|
|
115
|
+
</success_criteria>
|