@brunosps00/dev-workflow 2.0.0 → 2.2.0
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/.claude-plugin/marketplace.json +1 -0
- package/.claude-plugin/plugin.json +1 -1
- package/CHANGELOG.md +176 -0
- package/README.md +10 -5
- package/lib/build-plugin.js +4 -1
- package/lib/constants.js +8 -2
- package/lib/init.js +26 -0
- package/lib/validate.js +21 -0
- package/package.json +1 -1
- package/scaffold/en/agent-instructions.md +2 -0
- package/scaffold/en/commands/dw-autopilot.md +2 -0
- package/scaffold/en/commands/dw-brainstorm.md +12 -8
- package/scaffold/en/commands/dw-bugfix.md +4 -2
- package/scaffold/en/commands/dw-claude-run.md +1 -1
- package/scaffold/en/commands/dw-codex-run.md +1 -1
- package/scaffold/en/commands/dw-copilot-run.md +1 -1
- package/scaffold/en/commands/dw-harness-audit.md +2 -0
- package/scaffold/en/commands/dw-help.md +6 -2
- package/scaffold/en/commands/dw-pause.md +1 -0
- package/scaffold/en/commands/dw-plan.md +2 -2
- package/scaffold/en/commands/dw-refactor.md +1 -0
- package/scaffold/en/commands/dw-report.md +169 -0
- package/scaffold/en/commands/dw-review.md +33 -2
- package/scaffold/en/commands/dw-run.md +3 -1
- package/scaffold/en/commands/dw-triage.md +220 -0
- package/scaffold/en/commands/dw-worktree.md +100 -0
- package/scaffold/en/templates/idea-onepager.md +28 -0
- package/scaffold/en/templates/task-template.md +1 -0
- package/scaffold/en/templates/tasks-template.md +9 -8
- package/scaffold/en/templates/triage-needs-info-template.md +23 -0
- package/scaffold/en/templates/triage-out-of-scope-template.md +36 -0
- package/scaffold/en/templates/triage-record-template.md +88 -0
- package/scaffold/pt-br/agent-instructions.md +2 -0
- package/scaffold/pt-br/commands/dw-autopilot.md +83 -81
- package/scaffold/pt-br/commands/dw-brainstorm.md +12 -9
- package/scaffold/pt-br/commands/dw-bugfix.md +4 -2
- package/scaffold/pt-br/commands/dw-claude-run.md +20 -20
- package/scaffold/pt-br/commands/dw-codex-run.md +20 -20
- package/scaffold/pt-br/commands/dw-context-budget.md +10 -10
- package/scaffold/pt-br/commands/dw-copilot-run.md +21 -21
- package/scaffold/pt-br/commands/dw-dockerize.md +102 -102
- package/scaffold/pt-br/commands/dw-find-skills.md +52 -52
- package/scaffold/pt-br/commands/dw-goal.md +41 -41
- package/scaffold/pt-br/commands/dw-harness-audit.md +13 -11
- package/scaffold/pt-br/commands/dw-help.md +6 -2
- package/scaffold/pt-br/commands/dw-intel.md +70 -70
- package/scaffold/pt-br/commands/dw-learn.md +24 -24
- package/scaffold/pt-br/commands/dw-new-project.md +88 -88
- package/scaffold/pt-br/commands/dw-open-design.md +53 -53
- package/scaffold/pt-br/commands/dw-opportunities.md +45 -45
- package/scaffold/pt-br/commands/dw-pause.md +40 -39
- package/scaffold/pt-br/commands/dw-plan.md +2 -2
- package/scaffold/pt-br/commands/dw-refactor.md +31 -30
- package/scaffold/pt-br/commands/dw-report.md +169 -0
- package/scaffold/pt-br/commands/dw-resume.md +22 -22
- package/scaffold/pt-br/commands/dw-review.md +33 -2
- package/scaffold/pt-br/commands/dw-run.md +3 -1
- package/scaffold/pt-br/commands/dw-skill-health.md +10 -10
- package/scaffold/pt-br/commands/dw-subtask-complete.md +4 -4
- package/scaffold/pt-br/commands/dw-subtask-start.md +4 -4
- package/scaffold/pt-br/commands/dw-triage.md +220 -0
- package/scaffold/pt-br/commands/dw-worktree.md +100 -0
- package/scaffold/pt-br/templates/bugfix-summary-template.md +20 -20
- package/scaffold/pt-br/templates/concerns-template.md +20 -20
- package/scaffold/pt-br/templates/idea-onepager.md +28 -0
- package/scaffold/pt-br/templates/project-onepager.md +32 -32
- package/scaffold/pt-br/templates/state-template.md +13 -13
- package/scaffold/pt-br/templates/task-template.md +1 -0
- package/scaffold/pt-br/templates/tasks-template.md +9 -8
- package/scaffold/pt-br/templates/triage-needs-info-template.md +23 -0
- package/scaffold/pt-br/templates/triage-out-of-scope-template.md +36 -0
- package/scaffold/pt-br/templates/triage-record-template.md +88 -0
- package/scaffold/scripts/hooks/git-guardrails.mjs +42 -24
- package/scaffold/scripts/lib/worktree-gc.mjs +460 -0
- package/scaffold/skill-registry.json +1 -1
- package/scaffold/skills/dw-cli-run/SKILL.md +10 -1
- package/scaffold/skills/dw-debug-protocol/SKILL.md +2 -0
- package/scaffold/skills/dw-debug-protocol/references/six-step-triage.md +60 -1
- package/scaffold/skills/dw-execute-phase/references/wave-coordination.md +14 -14
- package/scaffold/skills/dw-grilling/SKILL.md +17 -7
- package/scaffold/skills/dw-grilling/references/decision-tree.md +30 -7
- package/scaffold/skills/dw-simplification/references/deep-modules.md +50 -0
- package/scaffold/skills/dw-testing-discipline/SKILL.md +3 -1
- package/scaffold/skills/dw-testing-discipline/references/tdd-loop.md +83 -0
|
@@ -1,70 +1,70 @@
|
|
|
1
1
|
<system_instructions>
|
|
2
|
-
|
|
2
|
+
Você é o scout de oportunidades do dev-workflow para o workspace atual. Este comando descobre o que o projeto deveria considerar a seguir antes do usuário já ter uma ideia concreta.
|
|
3
3
|
|
|
4
|
-
<critical>Este comando e apenas discovery.
|
|
5
|
-
<critical>Sempre considere oportunidades de produto, UX,
|
|
4
|
+
<critical>Este comando e apenas discovery. Não implemente código, não crie PRD, não faça refactor e não rode auditoria profunda de segurança salvo se o usuário pedir explicitamente depois.</critical>
|
|
5
|
+
<critical>Sempre considere oportunidades de produto, UX, automação, alavancagem técnica e segurança. Não reduza "oportunidade" a ideias de feature.</critical>
|
|
6
6
|
|
|
7
7
|
## Quando Usar
|
|
8
|
-
- Use quando o
|
|
9
|
-
- Use quando o
|
|
10
|
-
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
8
|
+
- Use quando o usuário perguntar o que construir agora, quiser ideias novas, pedir roadmap, ou quiser oportunidades específicas do projeto.
|
|
9
|
+
- Use quando o usuário disser "sugere ideias", "encontra oportunidades", "o que vem agora?", "o que deixaria isso melhor?", ou similar.
|
|
10
|
+
- NÃO use quando o usuário já tem uma feature concreta pronta para PRD; use `/dw-plan`.
|
|
11
|
+
- NÃO use para auditoria dedicada de saúde do código; use `/dw-refactor`.
|
|
12
|
+
- NÃO use para security gate dedicado; use `/dw-secure-audit`.
|
|
13
13
|
|
|
14
|
-
##
|
|
14
|
+
## Invocação
|
|
15
15
|
|
|
16
|
-
|
|
|
16
|
+
| Invocação | Comportamento |
|
|
17
17
|
|-----------|---------------|
|
|
18
18
|
| `/dw-opportunities` | Escaneia o projeto instalado e propoe oportunidades. |
|
|
19
|
-
| `/dw-opportunities <foco>` | Restringe o scan a
|
|
20
|
-
| `/dw-opportunities <foco> --research` | Adiciona pesquisa externa atual com
|
|
19
|
+
| `/dw-opportunities <foco>` | Restringe o scan a módulo, fluxo, persona, área de produto ou objetivo. |
|
|
20
|
+
| `/dw-opportunities <foco> --research` | Adiciona pesquisa externa atual com citações quando mercado, framework, compliance ou estado da arte importam. |
|
|
21
21
|
|
|
22
|
-
##
|
|
22
|
+
## Posição no Pipeline
|
|
23
23
|
**Predecessor:** contexto existente do projeto | **Sucessores:** `/dw-brainstorm`, `/dw-plan prd`, `/dw-redesign-ui`, `/dw-refactor`, `/dw-secure-audit`
|
|
24
24
|
|
|
25
|
-
## Grounding Local
|
|
25
|
+
## Grounding Local Obrigatório
|
|
26
26
|
|
|
27
27
|
Antes de propor qualquer coisa, inspecione o estado do projeto:
|
|
28
28
|
|
|
29
|
-
Trate a
|
|
29
|
+
Trate a documentação produzida por `/dw-analyze-project` como evidência primária. Isso inclui `.dw/rules/`, `.dw/constitution.md`, `.dw/rules/concerns.md`, `.dw/intel/` e `DESIGN.md` de frontend quando existir.
|
|
30
30
|
|
|
31
|
-
1. `.dw/spec/prd-*/` para
|
|
32
|
-
2. `.dw/rules/`, `.dw/constitution.md` e `.dw/rules/concerns.md` para
|
|
33
|
-
3. `.dw/intel/` para stack, grafo de arquivos, APIs,
|
|
34
|
-
4. `.dw/bugfixes/` para defeitos recorrentes e fluxos
|
|
35
|
-
5. `README*`, docs, manifests, arquivos de
|
|
36
|
-
6. `DESIGN.md` quando existir para
|
|
31
|
+
1. `.dw/spec/prd-*/` para superfície de produto entregue ou planejada.
|
|
32
|
+
2. `.dw/rules/`, `.dw/constitution.md` e `.dw/rules/concerns.md` para convenções, principios e áreas de risco conhecidas.
|
|
33
|
+
3. `.dw/intel/` para stack, grafo de arquivos, APIs, dependências é arquitetura.
|
|
34
|
+
4. `.dw/bugfixes/` para defeitos recorrentes e fluxos frágeis.
|
|
35
|
+
5. `README*`, docs, manifests, arquivos de dependências e commits recentes.
|
|
36
|
+
6. `DESIGN.md` quando existir para restrições visuais/produto de frontend.
|
|
37
37
|
|
|
38
|
-
Se uma fonte estiver ausente, diga que ela
|
|
38
|
+
Se uma fonte estiver ausente, diga que ela está ausente e siga com a evidência disponível.
|
|
39
39
|
|
|
40
40
|
## Categorias de Oportunidade
|
|
41
41
|
|
|
42
|
-
Avalie todas as categorias sempre, mesmo que a lista final
|
|
42
|
+
Avalie todas as categorias sempre, mesmo que a lista final não tenha card em uma delas:
|
|
43
43
|
|
|
44
44
|
| Categoria | Procurar | Follow-up |
|
|
45
45
|
|-----------|----------|-----------|
|
|
46
|
-
| `Product` | Workflows
|
|
47
|
-
| `UX/UI` |
|
|
46
|
+
| `Product` | Workflows não atendidos, lacunas de ativacao/retenção, gaps de produto, alavancagem de roadmap. | `/dw-brainstorm` ou `/dw-plan prd` |
|
|
47
|
+
| `UX/UI` | Fricção, hierarquia confusa, estados empty/loading/error fracos, gaps de acessibilidade, desalinhamento com `DESIGN.md`. | `/dw-redesign-ui <target>` |
|
|
48
48
|
| `Automation` | Trabalho manual repetido, gaps no fluxo de agentes, oportunidades de comando, rituais do projeto que podem ficar confiaveis. | `/dw-brainstorm` ou `/dw-plan prd` |
|
|
49
|
-
| `Engineering Leverage` | Tech debt, fluxo duplicado,
|
|
50
|
-
| `Security` | Gaps de auth/session, defaults inseguros,
|
|
49
|
+
| `Engineering Leverage` | Tech debt, fluxo duplicado, módulos de alta mudança, testes frágeis, drift arquitetural, docs confusas. | `/dw-refactor <target>` |
|
|
50
|
+
| `Security` | Gaps de auth/session, defaults inseguros, validação ausente, risco em secrets, risco de dependências, hardening/gates ausentes. | `/dw-secure-audit` ou `/dw-secure-audit --plan` |
|
|
51
51
|
|
|
52
|
-
Regras de roteamento de
|
|
53
|
-
- Use `/dw-secure-audit --plan` para
|
|
52
|
+
Regras de roteamento de segurança:
|
|
53
|
+
- Use `/dw-secure-audit --plan` para dependências, CVEs, pacotes defasados ou oportunidades de plano de remediacao.
|
|
54
54
|
- Use `/dw-secure-audit` para hardening amplo, auth/session, secrets, SAST, IaC ou security gate completo.
|
|
55
|
-
-
|
|
55
|
+
- Não invente argumentos de target que `/dw-secure-audit` não suporta.
|
|
56
56
|
|
|
57
57
|
Regras de roteamento de refactor:
|
|
58
|
-
- Use `/dw-refactor <target>` quando a oportunidade exigir
|
|
59
|
-
-
|
|
58
|
+
- Use `/dw-refactor <target>` quando a oportunidade exigir análise de code smells, duplicacao, coesão/acoplamento ou simplificação preservando comportamento.
|
|
59
|
+
- Não faça a auditoria profunda dentro de `/dw-opportunities`; entregue evidência é um alvo claro de handoff.
|
|
60
60
|
|
|
61
61
|
## Modo Research
|
|
62
62
|
|
|
63
63
|
Quando `--research` estiver presente:
|
|
64
|
-
- Use a disciplina `dw-source-grounding` se
|
|
64
|
+
- Use a disciplina `dw-source-grounding` se disponível.
|
|
65
65
|
- Use web sources para contexto externo de mercado, framework, compliance, competidores ou estado da arte.
|
|
66
66
|
- Cite fatos inline com URLs e data de retrieval.
|
|
67
|
-
- Mantenha a pesquisa proporcional. O comando ainda deve retornar oportunidades,
|
|
67
|
+
- Mantenha a pesquisa proporcional. O comando ainda deve retornar oportunidades, não um relatório completo.
|
|
68
68
|
|
|
69
69
|
## Scoring
|
|
70
70
|
|
|
@@ -72,16 +72,16 @@ Pontue cada candidata de forma leve:
|
|
|
72
72
|
|
|
73
73
|
| Campo | Significado |
|
|
74
74
|
|-------|-------------|
|
|
75
|
-
| Impact | Valor para
|
|
75
|
+
| Impact | Valor para usuário/negócio/segurança/engenharia se resolvido. |
|
|
76
76
|
| Reach | Quanto do produto ou time se beneficia. |
|
|
77
|
-
| Frequency | Com que
|
|
78
|
-
| Confidence |
|
|
77
|
+
| Frequency | Com que frequência a dor ou oportunidade aparece. |
|
|
78
|
+
| Confidence | Força da evidência local. |
|
|
79
79
|
| Effort | `S` / `M` / `L`. |
|
|
80
|
-
| Risk | Risco de entrega,
|
|
80
|
+
| Risk | Risco de entrega, segurança, migração ou UX. |
|
|
81
81
|
|
|
82
|
-
Priorize oportunidades de alto impacto, alta
|
|
82
|
+
Priorize oportunidades de alto impacto, alta confiança e esforço baixo/médio. Inclua uma aposta estratégica de alto upside quando houver evidência.
|
|
83
83
|
|
|
84
|
-
## Formato de
|
|
84
|
+
## Formato de Saída
|
|
85
85
|
|
|
86
86
|
```markdown
|
|
87
87
|
## Leitura do Projeto
|
|
@@ -120,12 +120,12 @@ Priorize oportunidades de alto impacto, alta confianca e esforco baixo/medio. In
|
|
|
120
120
|
- `/dw-secure-audit` ou `/dw-secure-audit --plan` para oportunidades de seguranca.
|
|
121
121
|
```
|
|
122
122
|
|
|
123
|
-
## Anti-
|
|
123
|
+
## Anti-padrões
|
|
124
124
|
|
|
125
|
-
- Sugerir ideias SaaS genericas sem citar
|
|
126
|
-
- Ignorar oportunidades de refactor e
|
|
127
|
-
- Rodar
|
|
128
|
-
- Produzir roadmap sem
|
|
125
|
+
- Sugerir ideias SaaS genericas sem citar evidência local do projeto.
|
|
126
|
+
- Ignorar oportunidades de refactor e segurança porque elas não são features de produto.
|
|
127
|
+
- Rodar análise profunda de refactor ou segurança dentro deste comando.
|
|
128
|
+
- Produzir roadmap sem próximo comando para cada item.
|
|
129
129
|
- Tratar `--research` como substituto de ler o projeto local primeiro.
|
|
130
130
|
|
|
131
131
|
</system_instructions>
|
|
@@ -1,66 +1,67 @@
|
|
|
1
1
|
<system_instructions>
|
|
2
|
-
|
|
2
|
+
Você é um agent de session-handoff. Seu trabalho e consolidar o estado mental da sessão atual em `.dw/STATE.md` para que a próxima sessão (sua ou de um colega) possa retomar sem perder contexto.
|
|
3
3
|
|
|
4
4
|
## Quando Usar
|
|
5
|
-
- Use quando o
|
|
6
|
-
- Use proativamente antes de uma pausa longa, antes de trocar de projeto ou antes de uma
|
|
7
|
-
-
|
|
8
|
-
-
|
|
5
|
+
- Use quando o usuário disser "pausar trabalho", "encerrar sessão", "preciso parar agora", "salvar o que estamos fazendo"
|
|
6
|
+
- Use proativamente antes de uma pausa longa, antes de trocar de projeto ou antes de uma compactação iminente do context window
|
|
7
|
+
- NÃO use no meio de uma task quando nada foi decidido ou aprendido (nada a consolidar)
|
|
8
|
+
- NÃO use como substituto de `/dw-commit` — STATE.md e estado mental, não mudancas de código
|
|
9
9
|
|
|
10
|
-
##
|
|
11
|
-
**Predecessor:** qualquer
|
|
10
|
+
## Posição na Pipeline
|
|
11
|
+
**Predecessor:** qualquer sessão de trabalho | **Sucessor:** `/dw-resume` (numa sessão futura)
|
|
12
12
|
|
|
13
|
-
## O que este comando
|
|
14
|
-
-
|
|
15
|
-
-
|
|
16
|
-
-
|
|
13
|
+
## O que este comando NÃO faz
|
|
14
|
+
- NÃO commita código (use `/dw-commit`)
|
|
15
|
+
- NÃO substitui o `MEMORY.md` por-PRD (memória de workflow para uma feature única vive lá; skill `dw-memory` gerencia)
|
|
16
|
+
- NÃO promove nada para ADRs (use `/dw-adr` para decisões arquiteturais duráveis)
|
|
17
17
|
|
|
18
18
|
## Local do Arquivo
|
|
19
|
-
- Artefato
|
|
20
|
-
- Template: `.dw/templates/state-template.md` (usado apenas na primeira
|
|
19
|
+
- Artefato único: `.dw/STATE.md` (nível de projeto, não por-PRD)
|
|
20
|
+
- Template: `.dw/templates/state-template.md` (usado apenas na primeira criação)
|
|
21
21
|
|
|
22
22
|
## Workflow
|
|
23
23
|
|
|
24
24
|
### 1. Garantir que STATE.md existe
|
|
25
|
-
- Se `.dw/STATE.md`
|
|
26
|
-
- Se `.dw/templates/state-template.md`
|
|
25
|
+
- Se `.dw/STATE.md` não existir, copie `.dw/templates/state-template.md` para `.dw/STATE.md`. Avise no chat: "STATE.md não encontrado — inicializado a partir do template."
|
|
26
|
+
- Se `.dw/templates/state-template.md` também não existir (projeto muito antigo), crie um STATE.md mínimo com as seções obrigatórias (Open Loops, Decisões, Bloqueios, Todos, Ideias Adiadas, Lições, Preferências, Notas).
|
|
27
27
|
|
|
28
|
-
### 2. Mapear a
|
|
28
|
+
### 2. Mapear a sessão
|
|
29
29
|
Leia o contexto da conversa e identifique, **sem inventar**:
|
|
30
30
|
|
|
31
|
-
- **Pontas soltas (Open Loops)**: tarefas/trabalho iniciados mas
|
|
32
|
-
- **
|
|
33
|
-
- **
|
|
34
|
-
- **
|
|
31
|
+
- **Pontas soltas (Open Loops)**: tarefas/trabalho iniciados mas não finalizados (ex: "PRD `prd-foo` está no estágio TechSpec, aguardando aprovação"; "Task 3 do `prd-bar` falhando no lint")
|
|
32
|
+
- **Worktrees sobrando**: rode `node .dw/scripts/lib/worktree-gc.mjs list`. Toda entrada `REMOVABLE` é um open loop pra fechar **agora** com `/dw-worktree clean --apply` — não algo pra registrar; entradas `KEEP:*` vão em Open Loops com veredito e motivo.
|
|
33
|
+
- **Decisões tomadas**: escolhas acordadas entre usuário e agent durante a sessão que afetam trabalho futuro
|
|
34
|
+
- **Bloqueios encontrados**: o que parou o avanço (esperando input, tooling quebrado, lacuna de conhecimento)
|
|
35
|
+
- **Todos mencionados de passagem** que ainda não tem PRD ou task
|
|
35
36
|
- **Ideias exploradas e parqueadas** (com motivo do park)
|
|
36
|
-
- **
|
|
37
|
-
- **
|
|
37
|
+
- **Lições aprendidas** — pequenas lições operacionais que valem registrar
|
|
38
|
+
- **Preferências expressas** — convenções que o usuário quer aplicadas dali em diante
|
|
38
39
|
|
|
39
40
|
### 3. Merge no STATE.md
|
|
40
41
|
|
|
41
|
-
<critical>NUNCA sobrescreva STATE.md cegamente. Leia o arquivo existente, parseie as
|
|
42
|
+
<critical>NUNCA sobrescreva STATE.md cegamente. Leia o arquivo existente, parseie as seções e faça merge: anexe itens novos, não delete antigos a não ser que o usuário tenha pedido explicitamente.</critical>
|
|
42
43
|
|
|
43
44
|
Regras:
|
|
44
45
|
- Cada entrada nova ganha prefixo de data `YYYY-MM-DD` (data de hoje).
|
|
45
|
-
- Use bullet lists. Cada item em uma linha onde
|
|
46
|
-
- Se uma
|
|
46
|
+
- Use bullet lists. Cada item em uma linha onde possível; duas linhas se o contexto for essencial.
|
|
47
|
+
- Se uma seção acabar com placeholder `_nenhum_` e você não tiver nada a acrescentar, mantenha `_nenhum_`.
|
|
47
48
|
- Atualize o campo `last_paused` no frontmatter para a data de hoje (YYYY-MM-DD).
|
|
48
49
|
|
|
49
|
-
### 4. Passada de
|
|
50
|
+
### 4. Passada de Compactação (quando STATE.md cresceu)
|
|
50
51
|
|
|
51
|
-
Se
|
|
52
|
+
Se após o merge o STATE.md ultrapassar **~6KB** ou qualquer seção tiver mais que **20 itens**, compacte:
|
|
52
53
|
|
|
53
|
-
- **Pontas soltas resolvidas durante a
|
|
54
|
-
- **Todos
|
|
55
|
-
- **
|
|
56
|
-
- **
|
|
57
|
-
- **Ideias Adiadas com mais de 90 dias sem trigger de revisita**: pergunte ao
|
|
54
|
+
- **Pontas soltas resolvidas durante a sessão**: remova.
|
|
55
|
+
- **Todos concluídos durante a sessão**: remova.
|
|
56
|
+
- **Decisões com mais de 30 dias que foram formalizadas em ADR ou na constitution**: remova (o ADR e o registro durável).
|
|
57
|
+
- **Lições com mais de 60 dias**: mantenha apenas as ainda relevantes; descarte conselhos taticos datados.
|
|
58
|
+
- **Ideias Adiadas com mais de 90 dias sem trigger de revisita**: pergunte ao usuário antes de descartar.
|
|
58
59
|
|
|
59
|
-
Se a
|
|
60
|
+
Se a compactação remover mais de 5 itens, liste no chat para o usuário poder vetar.
|
|
60
61
|
|
|
61
62
|
### 5. Report
|
|
62
63
|
|
|
63
|
-
Apresente um resumo curto ao
|
|
64
|
+
Apresente um resumo curto ao usuário:
|
|
64
65
|
|
|
65
66
|
```
|
|
66
67
|
## Sessao Pausada
|
|
@@ -77,16 +78,16 @@ Atualizado `.dw/STATE.md`:
|
|
|
77
78
|
Retome com `/dw-resume` na proxima sessao.
|
|
78
79
|
```
|
|
79
80
|
|
|
80
|
-
## Comportamento
|
|
81
|
+
## Comportamento Obrigatório
|
|
81
82
|
|
|
82
|
-
<critical>NUNCA fabrique estado. Se
|
|
83
|
+
<critical>NUNCA fabrique estado. Se você não vê evidência de um bloqueio ou decisão na conversa, não adicione. Seções vazias estão ok.</critical>
|
|
83
84
|
|
|
84
|
-
<critical>NUNCA toque em arquivos de
|
|
85
|
+
<critical>NUNCA toque em arquivos de memória por-PRD (`.dw/spec/*/MEMORY.md`, `.dw/spec/*/tasks/*_memory.md`). Esses são gerenciados pela skill `dw-memory` e são locais ao PRD.</critical>
|
|
85
86
|
|
|
86
|
-
<critical>NUNCA descarte
|
|
87
|
+
<critical>NUNCA descarte conteúdo do usuário em silêncio. Se compactar, liste o que removeu.</critical>
|
|
87
88
|
|
|
88
89
|
## Inspirado em
|
|
89
90
|
|
|
90
|
-
Este comando adapta o pattern de session-handoff de [`tech-leads-club/agent-skills/tlc-spec-driven`](https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(development)/tlc-spec-driven) (CC-BY-4.0, Felipe Rodrigues).
|
|
91
|
+
Este comando adapta o pattern de session-handoff de [`tech-leads-club/agent-skills/tlc-spec-driven`](https://github.com/tech-leads-club/agent-skills/tree/main/packages/skills-catalog/skills/(development)/tlc-spec-driven) (CC-BY-4.0, Felipe Rodrigues). Adaptações: local `.dw/STATE.md` em vez de `.specs/project/STATE.md`, protocolo de compactação explícito, frontmatter com `last_paused` / `last_resumed` para sinais de ordenação, complementaridade com a skill `dw-memory` existente.
|
|
91
92
|
|
|
92
93
|
</system_instructions>
|
|
@@ -69,7 +69,7 @@ Antes do Stage 1, verifique se há um one-pager de ideia em `.dw/spec/ideas/<slu
|
|
|
69
69
|
- `schema_version: "1.1"`;
|
|
70
70
|
- `status: aligned`;
|
|
71
71
|
- `alignment.confirmed_by_user: true`;
|
|
72
|
-
- toda branch de dependência resolvida (nenhum nó de decisão aberto);
|
|
72
|
+
- o **Decision Map** tem toda branch de dependência resolvida (nenhum nó de decisão aberto e `Frontier: none`);
|
|
73
73
|
- contradições glossário/código fechadas;
|
|
74
74
|
- nenhuma entrada **bloqueante** resta em Remaining Decisions.
|
|
75
75
|
Se QUALQUER check falha — ou o arquivo está malformado, internamente inconsistente, `draft` ou `paused` — o one-pager é **input, não handoff confiável**: leia para contexto, mas trate todas as suas decisões como **descobertas** e pergunte normalmente. Nunca suprima uma pergunta de produto só pela força do `status: aligned`; `alignment.confirmed_by_user: true` e uma árvore resolvida, não-bloqueante e sem contradições também são exigidos.</critical>
|
|
@@ -167,7 +167,7 @@ Roda em modo padrão (após aprovação do TechSpec) OU `plan tasks`.
|
|
|
167
167
|
4. **Test placement (`dw-testing-discipline`):** toda subtask que adiciona teste nomeia seu invariant per placement doctrine. Owning layer especificado.
|
|
168
168
|
5. **Constitution alignment:** toda task lista `Constitution: respects P-NNN` ou `Constitution: deviates P-NNN — ADR planejado: <slug>` ou `Constitution: n/a — motivo: <one-liner>`.
|
|
169
169
|
6. **Subtask LLM-eval (quando aplicável):** se PRD tem feature AI, uma task deve incluir Eval Plan subtask (reference dataset path, oracle rungs, judge calibration, target metrics).
|
|
170
|
-
7. **Declaração de dependência:** cada task lista explicitamente quais tasks anteriores
|
|
170
|
+
7. **Declaração de dependência:** cada task lista explicitamente de quais tasks anteriores depende. Escreva o campo como `Depends on: none` ou `Depends on: 1.0, 2.0` em `tasks.md` e em cada `<N>_task.md`. Validação rejeita ciclos.
|
|
171
171
|
8. **Outputs:**
|
|
172
172
|
- Summary: `.dw/spec/prd-<feature-slug>/tasks.md`
|
|
173
173
|
- Per-task: `.dw/spec/prd-<feature-slug>/<N>_task.md`
|
|
@@ -1,54 +1,55 @@
|
|
|
1
1
|
<system_instructions>
|
|
2
|
-
|
|
2
|
+
Você é a entrada de auditoria de refactor do dev-workflow. Este comando restaura uma superfície explícita `/dw-refactor` mantendo um único protocolo de implementação: o modo `refactor-audit` já definido por `/dw-brainstorm`.
|
|
3
3
|
|
|
4
|
-
<critical>Este comando audita e planeja refactoring.
|
|
5
|
-
<critical>Use o protocolo `refactor-audit` existente como fonte de verdade.
|
|
4
|
+
<critical>Este comando audita e planeja refactoring. Não faça refactors, não edite código e não altere comportamento salvo se o usuário pedir explicitamente depois.</critical>
|
|
5
|
+
<critical>Use o protocolo `refactor-audit` existente como fonte de verdade. Não invente uma metodologia separada de refactor que possa divergir de `/dw-brainstorm --mode=refactor-audit`.</critical>
|
|
6
6
|
|
|
7
7
|
## Quando Usar
|
|
8
|
-
-
|
|
9
|
-
- `/dw-opportunities` identifica um card `Engineering Leverage` e roteia para
|
|
10
|
-
- Use antes de mexer em
|
|
8
|
+
- Usuário pede oportunidades de refactor, auditoria de code health, scan de tech debt, limpeza de módulo baguncado ou higiene arquitetural trimestral.
|
|
9
|
+
- `/dw-opportunities` identifica um card `Engineering Leverage` e roteia para cá.
|
|
10
|
+
- Use antes de mexer em área arriscada quando um plano de refactor é mais seguro que limpeza oportunística.
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## Invocação
|
|
13
13
|
|
|
14
|
-
|
|
|
14
|
+
| Invocação | Comportamento |
|
|
15
15
|
|-----------|---------------|
|
|
16
16
|
| `/dw-refactor <target>` | Audita o target usando o protocolo `refactor-audit` existente. |
|
|
17
|
-
| `/dw-refactor` | Pergunta o target dentro das perguntas
|
|
17
|
+
| `/dw-refactor` | Pergunta o target dentro das perguntas obrigatórias de esclarecimento. |
|
|
18
18
|
|
|
19
|
-
##
|
|
20
|
-
**Predecessor:** `/dw-opportunities` ou target escolhido pelo
|
|
19
|
+
## Posição no Pipeline
|
|
20
|
+
**Predecessor:** `/dw-opportunities` ou target escolhido pelo usuário | **Sucessor:** `/dw-plan`, `/dw-run`, ou implementação manual de refactor após aprovação do usuário
|
|
21
21
|
|
|
22
|
-
## Comportamento
|
|
22
|
+
## Comportamento Obrigatório
|
|
23
23
|
|
|
24
|
-
1. Leia a
|
|
24
|
+
1. Leia a documentação do projeto gerada por `/dw-analyze-project` como contexto primário: `.dw/rules/`, `.dw/constitution.md`, `.dw/rules/concerns.md`, `.dw/intel/` e `DESIGN.md` quando existir.
|
|
25
25
|
2. Leia `.dw/commands/dw-brainstorm.md`.
|
|
26
|
-
3. Localize `Modo: refactor-audit (
|
|
27
|
-
4. Siga essa
|
|
28
|
-
- Fazer exatamente 3 perguntas de esclarecimento antes de iniciar a
|
|
26
|
+
3. Localize `Modo: refactor-audit (catálogo de code smells + deep-modules)`.
|
|
27
|
+
4. Siga essa seção exatamente, incluindo:
|
|
28
|
+
- Fazer exatamente 3 perguntas de esclarecimento antes de iniciar a análise.
|
|
29
29
|
- Usar a taxonomia de smells de Fowler.
|
|
30
|
-
- Carregar `dw-review-rigor` e `dw-simplification` quando
|
|
30
|
+
- Carregar `dw-review-rigor` e `dw-simplification` quando disponíveis.
|
|
31
31
|
- Aplicar Chesterton's Fence e deep-modules antes de propor refactor.
|
|
32
|
+
- Carregar as seções avançadas de deep-modules (`Dependency categories decide seam tests` e `Design It Twice for interface findings`) apenas quando o finding sobrevivente for interface rasa, vazamento de interface ou seam no lugar errado.
|
|
32
33
|
- Deduplicar findings e ordenar severidade P0-P3.
|
|
33
|
-
- Salvar a
|
|
34
|
-
5. Se o target
|
|
34
|
+
- Salvar a saída em `<target>/refactor-plan.md`.
|
|
35
|
+
5. Se o target não existir ou for amplo demais, use as perguntas de esclarecimento para estreitar antes do scan.
|
|
35
36
|
|
|
36
|
-
## Fronteira de
|
|
37
|
+
## Fronteira de Segurança
|
|
37
38
|
|
|
38
|
-
- Findings de
|
|
39
|
-
- Se o scan de refactor encontrar sinais de auth/session, secrets,
|
|
40
|
-
-
|
|
39
|
+
- Findings de segurança pertencem a `/dw-secure-audit`, não a `/dw-refactor`.
|
|
40
|
+
- Se o scan de refactor encontrar sinais de auth/session, secrets, dependências, SAST ou hardening, adicione nota de que o follow-up e `/dw-secure-audit` ou `/dw-secure-audit --plan`.
|
|
41
|
+
- Não duplique o security gate dentro do relatório de refactor.
|
|
41
42
|
|
|
42
|
-
##
|
|
43
|
+
## Saída
|
|
43
44
|
|
|
44
|
-
Use o formato de
|
|
45
|
+
Use o formato de saída do modo `refactor-audit` de `/dw-brainstorm`. O resumo mostrado ao usuário deve incluir:
|
|
45
46
|
|
|
46
47
|
- Contagem de findings por P0-P3.
|
|
47
48
|
- Top 3 oportunidades de refactor com maior alavancagem.
|
|
48
|
-
- Testes ou cobertura de
|
|
49
|
-
-
|
|
50
|
-
- `/dw-plan` para refactor em
|
|
51
|
-
- `/dw-run` apenas para task de refactor estreita e
|
|
52
|
-
- `/dw-secure-audit` quando o scan revelar
|
|
49
|
+
- Testes ou cobertura de caracterização exigidos antes da implementação.
|
|
50
|
+
- Próximo comando explícito:
|
|
51
|
+
- `/dw-plan` para refactor em múltiplos passos.
|
|
52
|
+
- `/dw-run` apenas para task de refactor estreita e já aprovada.
|
|
53
|
+
- `/dw-secure-audit` quando o scan revelar preocupações de segurança.
|
|
53
54
|
|
|
54
55
|
</system_instructions>
|
|
@@ -0,0 +1,169 @@
|
|
|
1
|
+
<system_instructions>
|
|
2
|
+
Você é o loop de report de progresso. Enquanto há trabalho longo rodando nesta sessão, você emite um report detalhado e carimbado com data e hora numa cadência fixa (default a cada 10 minutos) dizendo **o que já foi feito, o que está sendo feito agora e o que ainda falta** — sem o usuário precisar perguntar "e aí?". Cada report vai pro chat E é anexado num log diário em `.dw/reports/`. O loop se desarma sozinho quando o trabalho termina.
|
|
3
|
+
|
|
4
|
+
## Quando Usar
|
|
5
|
+
- Use quando o usuário disser "report de N em N minutos", "me mantém informado enquanto isso roda", "quero status periódico", "quero saber onde estamos a cada 10 minutos".
|
|
6
|
+
- Auto-armado por `/dw-run` (modos todas-as-tasks e `--resume`), por `/dw-autopilot` (invocação de execução) e pelos adapters `dw-cli-run` (`/dw-codex-run`, `/dw-claude-run`, `/dw-copilot-run`) quando disparam trabalho longo. O auto-arme é idempotente e pode ser desligado com `DW_REPORT_AUTO=off`.
|
|
7
|
+
- NÃO use como substituto de `/dw-pause` (handoff de estado mental) nem de `/dw-goal status` (estado do contrato de goal). Isto é um heartbeat sobre trabalho em andamento, não estado durável do projeto.
|
|
8
|
+
- NÃO use pra fazer polling de uma task em background que o harness já notifica — o loop reporta *em volta* dessas notificações; nunca as substitui.
|
|
9
|
+
|
|
10
|
+
## Posição no Pipeline
|
|
11
|
+
**Predecessor:** qualquer comando de longa duração (`/dw-run`, `/dw-autopilot`, `/dw-goal`, `/dw-codex-run`, builds, deploys) | **Sucessor:** nenhum — o loop termina com um report final; `/dw-pause` pode consumir o log do dia.
|
|
12
|
+
|
|
13
|
+
## Modos
|
|
14
|
+
|
|
15
|
+
| Invocação | Comportamento |
|
|
16
|
+
|-----------|---------------|
|
|
17
|
+
| `/dw-report` | Arma o loop na cadência default (**10 minutos**). Se já estiver armado, imprime o estado atual e não faz mais nada. |
|
|
18
|
+
| `/dw-report --every <N>m` | Arma (ou re-arma) o loop em `N` minutos (`5m`, `10m`, `15m`, `30m`; `--every 600s` também é aceito). Mínimo `1m`. |
|
|
19
|
+
| `/dw-report now` | Emite um report imediatamente, sem mexer na cadência. Funciona armado ou não. |
|
|
20
|
+
| `/dw-report status` | Mostra se o loop está armado, a cadência, quando foi armado, a hora do último report, quantos reports foram emitidos e o caminho do log. |
|
|
21
|
+
| `/dw-report stop` | Desarma. Emite um report final antes se houver progresso não reportado. |
|
|
22
|
+
|
|
23
|
+
## Entradas
|
|
24
|
+
|
|
25
|
+
| Variável | Descrição | Exemplo |
|
|
26
|
+
|----------|-----------|---------|
|
|
27
|
+
| `{{EVERY}}` | Cadência. Opcional; default `10m`. | `--every 5m` |
|
|
28
|
+
| `DW_REPORT_AUTO` | Env var. `off` desliga o auto-arme vindo de outros comandos (o `/dw-report` manual continua funcionando). | `DW_REPORT_AUTO=off` |
|
|
29
|
+
| `DW_REPORT_BELL` | Env var. Comando shell opcional executado logo antes de cada report ser escrito (som local, notificação de desktop etc.). Silencioso quando não definido. | `DW_REPORT_BELL="paplay /usr/share/sounds/freedesktop/stereo/message.oga"` |
|
|
30
|
+
|
|
31
|
+
`report.bell` em `.dw/config.json` é o equivalente em arquivo de `DW_REPORT_BELL` (a env var vence). Como o bell é específico da máquina, prefira a env var a commitar isso.
|
|
32
|
+
|
|
33
|
+
## Estado e Artefatos
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
.dw/reports/
|
|
37
|
+
├── .gitignore # ????-??-??.md e .active.json são locais da máquina (criado pelo init/update)
|
|
38
|
+
├── .active.json # estado do loop — existe só enquanto armado
|
|
39
|
+
└── YYYY-MM-DD.md # log diário append-only; uma entrada por report emitido
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
Schema do `.active.json`:
|
|
43
|
+
|
|
44
|
+
```json
|
|
45
|
+
{
|
|
46
|
+
"schema_version": "1.0",
|
|
47
|
+
"armed_at": "2026-08-24 15:10:02",
|
|
48
|
+
"every_seconds": 600,
|
|
49
|
+
"vehicle": "wakeup | background-bash",
|
|
50
|
+
"armed_by": "user | dw-run | dw-autopilot | dw-cli-run",
|
|
51
|
+
"seq": 3,
|
|
52
|
+
"last_report_at": "2026-08-24 15:40:12",
|
|
53
|
+
"last_state": "working | blocked | finished"
|
|
54
|
+
}
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
Timestamps são **reais** — sempre obtidos de `date '+%Y-%m-%d %H:%M:%S'`, nunca estimados.
|
|
58
|
+
|
|
59
|
+
## Veículo — como o loop se mantém vivo
|
|
60
|
+
|
|
61
|
+
<critical>A thread principal nunca dorme em foreground. Escolha UM veículo, registre em `.active.json`, e nunca afirme "loop armado" sem que esse veículo esteja de fato agendado.</critical>
|
|
62
|
+
|
|
63
|
+
1. **Wakeup nativo (PREFERIDO — Claude Code).** Use a facilidade de despertar agendado do harness (o mesmo mecanismo do `/loop` em modo self-paced): depois de cada tick, agende o próximo despertar em `every_seconds`. Passe `noop: true` num tick silencioso e `noop: false` num tick que reportou. O `reason` é `dw-report tick every <N>m`. O loop morre com a sessão — sem órfão.
|
|
64
|
+
2. **Timer shell em background (FALLBACK — Codex, Copilot, OpenCode, ou qualquer harness sem wakeups).** Rode, em background, `sleep <every_seconds>; date '+%Y-%m-%d %H:%M:%S'`. Quando a notificação de conclusão chegar, execute o tick e inicie o próximo timer. Um timer por vez; nunca encadeie sleeps em foreground.
|
|
65
|
+
3. **Nunca um cron de sistema.** Cron não sabe quando o trabalho acabou e continua disparando (e tocando o bell) por dias. Se o harness só oferecer agendamento estilo cron, use-o mas trate `/dw-report stop` e a regra de auto-desarme como limpeza obrigatória.
|
|
66
|
+
|
|
67
|
+
Se o trabalho trocar de veículo no meio (ex.: a sessão foi retomada em outro lugar), `/dw-report status` precisa dizer isso honestamente: `armado no arquivo de estado, mas nenhum wake-up está agendado nesta sessão — rode /dw-report pra re-armar`.
|
|
68
|
+
|
|
69
|
+
## Protocolo do Tick (a cada disparo)
|
|
70
|
+
|
|
71
|
+
1. **Timestamp.** `date '+%Y-%m-%d %H:%M:%S'`.
|
|
72
|
+
2. **Avaliar a partir da sessão.** A fonte de verdade é o trabalho da própria sessão — o que você fez, o que iniciou, o que voltou. Use checagens observáveis e baratas como evidência, não como arqueologia: `git log --oneline` desde o último report, `git status --short | wc -l`, o tail de um log ou stream que esta sessão iniciou, o número de passos concluídos num stream de CLI (`grep -c '"type":"item.completed"' <stream>.jsonl`), a última notificação de uma task em background. NÃO saia minerando `.dw/spec/`, `.dw/goals/` ou `STATE.md` pra reconstruir história da qual você não participou.
|
|
73
|
+
3. **Classificar o momento.**
|
|
74
|
+
- **working** — algo está em andamento (um comando, um subagente, um workflow, uma execução de CLI, um build, um deploy) ou você está implementando ativamente.
|
|
75
|
+
- **blocked** — nada está rodando porque o trabalho espera o usuário (uma decisão, uma aprovação, uma credencial).
|
|
76
|
+
- **finished** — o trabalho pra o qual o loop foi armado está completo (ou falhou terminalmente) e nada mais está na fila.
|
|
77
|
+
4. **Decidir se fala.**
|
|
78
|
+
- `working` → **REPORTA**. Sempre. Mesmo quando nada mudou desde o último tick ("build ainda no passo 6/9, ~4 min restantes" é um report válido e esperado).
|
|
79
|
+
- `blocked` → reporta **uma vez** quando o estado muda pra blocked (isso é novidade); depois, em todo tick em que nada mudou, **fica em silêncio**: nenhuma linha no chat, nenhuma entrada no log, nenhum bell. A checagem acontece; o output não.
|
|
80
|
+
- `finished` → **REPORT FINAL imediatamente** (não espere a cadência quando notar a conclusão fora de um tick), depois **desarma**: apaga `.active.json`, cancela o wake-up/timer pendente e diz isso no report final.
|
|
81
|
+
5. **Bell (opcional).** Se `DW_REPORT_BELL` (ou `report.bell`) estiver definido, execute *antes* de escrever. Nunca num tick silencioso.
|
|
82
|
+
6. **Escrever.** O report vai pro chat e é anexado literalmente em `.dw/reports/YYYY-MM-DD.md` (crie o arquivo com o cabeçalho `# Reports — YYYY-MM-DD` se não existir). Atualize `.active.json` (`seq`, `last_report_at`, `last_state`).
|
|
83
|
+
7. **Re-armar** o veículo — a menos que o passo 4 tenha desarmado o loop.
|
|
84
|
+
|
|
85
|
+
## Formato do Report — acumulado com delta destacado
|
|
86
|
+
|
|
87
|
+
O usuário pediu report **detalhado**. Detalhado significa: todo item carrega evidência, todo item em andamento carrega um número de progresso mensurável, e a lista do que falta vem ordenada com o próximo marco primeiro.
|
|
88
|
+
|
|
89
|
+
```markdown
|
|
90
|
+
📊 Report — 2026-08-24 15:40:12 (#3 · every 10m · armado 15:10)
|
|
91
|
+
|
|
92
|
+
## ✅ Feito (acumulado)
|
|
93
|
+
- ➕ Task 3/7 — parser de importação trata campos entre aspas — `src/import/parser.ts`, commit `a1b2c3d`, 14 testes verdes
|
|
94
|
+
- ➕ Task 2/7 — validação de schema CSV — commit `9f8e7d6`, `npm test` 41/41
|
|
95
|
+
- Task 1/7 — fixtures de importação — commit `1234abc`
|
|
96
|
+
|
|
97
|
+
## 🔄 Fazendo
|
|
98
|
+
- Task 4/7 — endpoint de upsert em lote — 6 arquivos tocados, último comando `npm test -- import` (rodando há 1m40s); stream do codex: 23 passos concluídos, último `command_execution: pnpm build`
|
|
99
|
+
|
|
100
|
+
## ⏳ Falta
|
|
101
|
+
1. Task 5/7 — download do relatório de erros (próximo marco, depende da Task 4)
|
|
102
|
+
2. Task 6/7 — ligação da UI
|
|
103
|
+
3. Task 7/7 — E2E do caminho feliz
|
|
104
|
+
4. Review Level 2 + QA + security gate
|
|
105
|
+
|
|
106
|
+
## ⚠️ Bloqueios / decisões necessárias
|
|
107
|
+
- nenhum
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
Regras:
|
|
111
|
+
- **`➕` marca itens concluídos desde o report anterior.** Itens mais antigos ficam na lista sem o marcador, então cada report é autocontido e ainda mostra o ritmo.
|
|
112
|
+
- **Evidência ou não aconteceu:** um caminho de arquivo, um SHA de commit, uma contagem de testes, uma linha de log. "Implementei X" sem evidência não é permitido.
|
|
113
|
+
- **Progresso mensurável no Fazendo:** um contador de passos, uma contagem de arquivos, um comando rodando com o tempo decorrido, uma porcentagem vinda de uma linha de progresso real. Nunca um "em andamento" pelado.
|
|
114
|
+
- **Falta é ordenado:** o próximo marco primeiro, depois o resto; inclua os gates do pipeline que ainda estão pela frente (review, QA, security audit, commit, PR) quando se aplicarem.
|
|
115
|
+
- **Seção de bloqueios só quando há algo a dizer** — senão escreva `- nenhum` ou omita.
|
|
116
|
+
- **Contadores do cabeçalho são reais:** `#n` é o `seq`, a cadência e a hora de arme vêm de `.active.json`.
|
|
117
|
+
- Quando o loop foi armado por outro comando, o primeiro report diz isso: `armado por /dw-run (todas as tasks pendentes)`.
|
|
118
|
+
|
|
119
|
+
### Report final
|
|
120
|
+
|
|
121
|
+
Mesma forma, com o cabeçalho `📊 FINAL Report — <timestamp> (#n · loop desarmado)`, uma linha explícita de desfecho sob Feito (`Desfecho: todas as 7 tasks commitadas, review APROVADO` ou `Desfecho: FALHOU na task 4 — ver bloqueios`), e `Falta` listando o que o usuário ainda precisa fazer à mão (abrir o PR, aprovar o gate, mergear).
|
|
122
|
+
|
|
123
|
+
### Saída no chat para arm / status / stop
|
|
124
|
+
|
|
125
|
+
```
|
|
126
|
+
📊 Report loop armado — every 10m · veículo: wakeup · log: .dw/reports/2026-08-24.md
|
|
127
|
+
Primeiro report em ~15:20. Silencioso enquanto bloqueado; report final + auto-desarme quando o trabalho terminar. Pare com /dw-report stop.
|
|
128
|
+
```
|
|
129
|
+
|
|
130
|
+
```
|
|
131
|
+
📊 Report loop — ARMADO · every 10m · desde 15:10 · 3 reports · último 15:40 · estado: working · log: .dw/reports/2026-08-24.md
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
📊 Report loop — NÃO armado. Arme com /dw-report [--every <N>m].
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
## Disciplina de Cadência
|
|
139
|
+
|
|
140
|
+
<critical>A cadência é do usuário, não sua. Nunca estique o intervalo pra "esperar o build terminar" ou "evitar ruído" — um report que diz "nada mudou, ~X min restantes" é o produto enquanto há trabalho rodando. Mude o intervalo apenas por instrução explícita do usuário (`--every`).</critical>
|
|
141
|
+
|
|
142
|
+
<critical>Nunca afirme que o loop está ativo sem um wake-up agendado ou um timer em background vivo. `/dw-report status` lê `.active.json` E checa o veículo; se discordarem, diga.</critical>
|
|
143
|
+
|
|
144
|
+
<critical>Silêncio é só pro estado blocked/ocioso. Estado working sempre reporta; a transição pra blocked reporta uma vez; a conclusão reporta imediatamente.</critical>
|
|
145
|
+
|
|
146
|
+
## Contrato de Auto-arme (para os comandos que chamam este)
|
|
147
|
+
|
|
148
|
+
Quando `/dw-run` (Modo 2 / Modo 3), `/dw-autopilot` (invocação de execução) ou um adapter `dw-cli-run` inicia trabalho longo, ele invoca `/dw-report` **antes** de despachar:
|
|
149
|
+
|
|
150
|
+
- **Idempotente:** se `.dw/reports/.active.json` existe e o veículo está vivo, não faz nada (mantém a cadência existente). Se o arquivo existe mas o veículo morreu, re-arma e avisa.
|
|
151
|
+
- **Respeita o opt-out:** se `DW_REPORT_AUTO=off`, pula em silêncio (uma linha na saída do chamador: `report loop: auto-arme desligado por DW_REPORT_AUTO`).
|
|
152
|
+
- **Registra o chamador:** `armed_by` em `.active.json`, ecoado no primeiro report.
|
|
153
|
+
- **Termina com o trabalho do chamador:** a conclusão do chamador (todas as tasks feitas + review final, goal completo + gate de PR, execução de CLI gateada) é o estado `finished` — report final, depois desarme. O chamador não precisa chamar `/dw-report stop`.
|
|
154
|
+
- **Nunca bloqueia o chamador:** armar custa uma chamada de tool; se o veículo não estiver disponível, o chamador segue e imprime `report loop: nenhum veículo de wake-up disponível neste harness — rode /dw-report manualmente se quiser um timer em background`.
|
|
155
|
+
|
|
156
|
+
## Anti-patterns
|
|
157
|
+
- Reportar "em andamento" sem número, comando ou arquivo.
|
|
158
|
+
- Inventar timestamp, SHA de commit ou contagem de testes.
|
|
159
|
+
- Emitir linhas `idle` / `sem novidades` enquanto nada roda — é exatamente o ruído que este loop existe pra evitar.
|
|
160
|
+
- Esticar ou pular um tick enquanto há trabalho rodando.
|
|
161
|
+
- Deixar um cron de sistema pra trás depois que o trabalho acabou.
|
|
162
|
+
- Ler `.dw/spec/` ou `.dw/goals/` pra narrar trabalho que esta sessão não fez.
|
|
163
|
+
- Tocar o bell num tick silencioso.
|
|
164
|
+
|
|
165
|
+
## Structured Return
|
|
166
|
+
|
|
167
|
+
Depois de armar, parar ou a cada report, o status do próprio comando é totalmente descrito pela linha no chat mais `.dw/reports/.active.json`. Outros comandos só precisam saber: **armed (bool), every_seconds, seq, last_state**.
|
|
168
|
+
|
|
169
|
+
</system_instructions>
|