🎩 You're Invited:Meet the Socket team at Black Hat in Las Vegas, August 3-6.RSVP →
reversa - npm Package Compare versions
@@ -22,3 +22,3 @@ # Protocolo do debate multiagente (épocas fixas + juiz isolado) | ||
| ```text | ||
| _reversa_bugs/bugs/<ID>/debate/ | ||
| _reversa_bugs/<contexto>/bugs/<ID>/debate/ | ||
| ├── problema.md modo, N, R, P e rubrica congelada (escrito no setup, imutável) | ||
@@ -25,0 +25,0 @@ ├── rodada-0/agente-1..N.md |
@@ -46,3 +46,3 @@ --- | ||
| Estado em `_reversa_bugs/bugs/<ID>/debate/`. Escreva `problema.md` com modo, N, R, o problema P (montado do bug + evidências + spec efetiva) e a rubrica congelada do juiz. | ||
| Estado em `_reversa_bugs/<contexto>/bugs/<ID>/debate/`. Escreva `problema.md` com modo, N, R, o problema P (montado do bug + evidências + spec efetiva) e a rubrica congelada do juiz. | ||
@@ -75,2 +75,2 @@ 1. **Época 0**: cada solver produz a proposta inicial de forma independente, sem ver os outros, em `rodada-0/agente-i.md` | ||
| **Nunca apague, modifique ou sobrescreva arquivos pré-existentes do projeto.** | ||
| Este skill escreve APENAS em `_reversa_bugs/bugs/<ID>/debate/`. Ele decide estratégia, não aplica correção. Nada do projeto vai a harness externo sem o aceite explícito deste setup, e bugs `restricted` nunca saem. | ||
| Este skill escreve APENAS em `_reversa_bugs/<contexto>/bugs/<ID>/debate/`. Ele decide estratégia, não aplica correção. Nada do projeto vai a harness externo sem o aceite explícito deste setup, e bugs `restricted` nunca saem. |
@@ -26,4 +26,6 @@ --- | ||
| 1. Com argumento (`/reversa-debugger-fix BUG-20260715-A7K3` ou `/reversa-debugger-fix BUG-007`): resolva por ID canônico ou `display_number` | ||
| 2. Sem argumento: leia `generated/catalog.jsonl` (ou varra `bugs/*/bug.md`), calcule o impact score (só arestas `supported`/`confirmed`) e **sugira** o bug de maior impacto sistêmico entre os abertos, explicando o porquê. A escolha é do usuário (menu com top 3 + "Outro"). | ||
| 3. Bug `resolved` ou com `blocking` ativo: informe e pergunte como proceder. | ||
| 2. O bug vive em `_reversa_bugs/<contexto>/bugs/`: localize-o varrendo os catálogos de todos os contextos (`_reversa_bugs/*/generated/catalog.jsonl`, ou `_reversa_bugs/*/bugs/*/bug.md` na falta deles). Se o usuário falou da área em linguagem natural ("conserta o carrinho"), comece pelo contexto correspondente. | ||
| 3. Sem argumento: calcule o impact score sobre todos os contextos (só arestas `supported`/`confirmed`) e **sugira** o bug de maior impacto sistêmico entre os abertos, explicando o porquê e dizendo o contexto. A escolha é do usuário (menu com top 3 + "Outro"). | ||
| 4. **Trava DONE**: se existir `DONE.md` na pasta do bug, o bug está encerrado e é SOMENTE LEITURA. Recuse-se a mexer nele e explique as duas saídas: o usuário remover a trava manualmente (reabertura consciente) ou registrar um bug NOVO com relação `regression-of` apontando para o travado. Nunca remova a trava você mesmo. | ||
| 5. Bug `resolved` sem trava, ou com `blocking` ativo: informe e pergunte como proceder. | ||
@@ -85,2 +87,18 @@ ## Modo de controle | ||
| ### 4.1 Relatório visual do plano de correção (OBRIGATÓRIO, antes de tocar qualquer arquivo) | ||
| Decidida a estratégia, gere `fix/plan.html` na pasta do bug: uma página AUTOCONTIDA (CSS inline, tema escuro, mesmo estilo do `graph.html` do contexto) que mostra como a correção SERÁ, antes de ela existir: | ||
| 1. Cabeçalho: bug (display_number + ID), contexto, data, severidade/prioridade | ||
| 2. Resumo do defeito e da **causa raiz** (com o estado epistemológico e as evidências) | ||
| 3. **Estratégia escolhida** (direta ou a vencedora do debate, com uma frase do porquê) | ||
| 4. **Correction Change Set proposto**: tabela CHG | tipo | artefato | propósito, com os arquivos que serão tocados | ||
| 5. **Testes planejados**: reprodução e regressão, o que cada um prova | ||
| 6. **Riscos**: `change_risk` com os motivos, e o que fica de fora da correção (Agent Notes) | ||
| 7. **Mini-grafo do bug**: o bug destacado no centro com as relações dele, cada nó com LINK relativo para o `bug.md` correspondente | ||
| 8. **Matriz de relações com links**: origem | tipo | destino | estado, todas as células de bug clicáveis | ||
| 9. Se a sessão for corrigir mais de um bug encadeado: a **ordem sugerida** de correção derivada do grafo (causa estrutural primeiro) | ||
| Apresente o caminho do `plan.html`, peça para o usuário abrir e **aguarde a aprovação do plano**. Só depois disso entram os gates. Se o usuário pedir mudanças, regenere o plano antes de seguir. | ||
| ### 5. Gate 1: os testes | ||
@@ -117,3 +135,4 @@ | ||
| 3. Só marque `status: resolved` + `closure.satisfied: true` quando a política estiver satisfeita. `resolution_kind: fixed` exige causa `confirmed` + regressão + veredito. | ||
| 4. Atualize as views (`generated/` e `_reversa_sdd/traceability/bugs.md`) pelo protocolo do `/reversa-debugger-graph` | ||
| 4. **Grave a trava**: satisfeita a closure policy, crie `DONE.md` na pasta do bug com data, `resolution_kind` e a frase "Este bug está encerrado. Nenhum agente deve modificar esta pasta. Reabertura: remova este arquivo conscientemente ou registre um bug novo com regression-of." A partir daí a pasta inteira é somente leitura para todos os comandos. | ||
| 5. Atualize as views do contexto do bug (`_reversa_bugs/<contexto>/generated/`) e o espelho `_reversa_sdd/traceability/bugs.md` pelo protocolo do `/reversa-debugger-graph` | ||
@@ -120,0 +139,0 @@ ## Relatório final ao usuário |
@@ -20,7 +20,8 @@ --- | ||
| 1. Leia `.reversa/state.json` (`output_folder`, `doc_language`) | ||
| 2. Se `_reversa_bugs/bugs/` não existir ou estiver vazia, informe que não há bugs registrados e aponte `/reversa-debugger` | ||
| 2. Os bugs vivem agrupados por contexto: `_reversa_bugs/<contexto>/bugs/`. Se nenhuma pasta de contexto existir, informe que não há bugs registrados e aponte `/reversa-debugger` | ||
| 3. Escopo: com argumento (`/reversa-debugger-graph carrinho-de-compras`), regenere só aquele contexto; sem argumento, regenere TODOS os contextos encontrados, um a um | ||
| ## Etapa 1: varredura e validação | ||
| 1. Leia o front matter de TODOS os `bugs/*/bug.md` (só o front matter; corpo apenas quando precisar de detalhe) | ||
| 1. Leia o front matter de TODOS os `_reversa_bugs/*/bugs/*/bug.md` (só o front matter; corpo apenas quando precisar de detalhe). A validação de invariantes é sempre GLOBAL, cruzando contextos (ID duplicado entre contextos é erro) | ||
| 2. Valide as invariantes. Divergência é ERRO EXPLÍCITO, nunca conserto silencioso: | ||
@@ -32,7 +33,8 @@ - ID duplicado (pode acontecer via merge de branches) | ||
| - Relação com ID inexistente, autorrelação, ciclo de `duplicate-of` | ||
| - `DONE.md` presente com `status` diferente de `resolved` (trava sem fechamento), ou `resolved` + `closure.satisfied: true` sem `DONE.md` (fechamento sem trava) | ||
| 3. Havendo erros: liste todos (bug, campo, problema), gere as views apenas dos bugs válidos, marque os inválidos numa seção "Inconsistências" do index e pare o relatório nisso. Consertar é decisão humana. | ||
| ## Etapa 2: views em `generated/` | ||
| ## Etapa 2: views em `<contexto>/generated/` | ||
| Todas com cabeçalho `<!-- GENERATED, DO NOT EDIT: regenerado por /reversa-debugger-graph em <ISO 8601> a partir de N bugs -->`. Escrita atômica. | ||
| Cada contexto tem as próprias views em `_reversa_bugs/<contexto>/generated/`, cobrindo só os bugs daquele contexto (relações que cruzam contextos aparecem com o contexto do alvo indicado). Todas com cabeçalho `<!-- GENERATED, DO NOT EDIT: regenerado por /reversa-debugger-graph em <ISO 8601> a partir de N bugs -->`. Escrita atômica. Crie `generated/` do contexto se ainda não existir. | ||
@@ -57,2 +59,13 @@ ### catalog.jsonl | ||
| ### graph.html (a view que o usuário abre no navegador) | ||
| Página HTML AUTOCONTIDA (CSS inline, sem dependência externa, meta viewport), tema escuro, título "Grafo de Bugs · <contexto>": | ||
| 1. Linha de metadados: gerado por /reversa-debugger-graph, data, N bugs, N inconsistências, legenda "arestas tracejadas = relação proposed (hipótese)" | ||
| 2. **Cards de estatística** no topo: total de bugs, resolved · fixed, abertos/ativos, adendos de spec gerados, inconsistências | ||
| 3. O grafo em SVG com **nós clicáveis**: cada nó é um link relativo para o `bug.md` do bug; conteúdo do nó: display_number + sufixo do ID, título curto, severidade/área e a linha de status (`resolved · fixed` em verde, `active`/`awaiting-human` em amarelo, aberto em vermelho); borda vermelha para severidade high/critical, amarela para medium; setas com o tipo da relação, tracejadas quando `proposed` | ||
| 4. Legenda em prosa apontando o nó central do grafo e contando a história das relações confirmadas | ||
| 5. Seção "Bugs abertos / ativos": tabela com #, ID (link), severidade, prioridade, título, area/module/feature e status | ||
| 6. Seção "Concluídos (travados)": bugs com `DONE.md`, com data de fechamento e `resolution_kind`; este é o registro central de conclusão, derivado das travas, nunca editado à mão | ||
| 7. Bugs `restricted` ficam fora, como nas demais views | ||
| ### spec-matrix.md | ||
@@ -72,4 +85,4 @@ Matriz BUG ↔ SPEC pela `traceability.specs`: linhas por seção de spec, colunas open/active/resolved com os IDs. Linha própria para `spec-gap` (bugs sem spec, denunciando comportamento não especificado). Aponte adendos de bug vigentes em `addenda/`. | ||
| 1. Contagem: bugs varridos, válidos, inconsistências (se houver, listadas) | ||
| 2. Views regeneradas (caminhos) + espelho | ||
| 1. Contagem por contexto: bugs varridos, válidos, inconsistências (se houver, listadas) | ||
| 2. Views regeneradas (caminhos por contexto, destacando cada `graph.html`) + espelho | ||
| 3. Top 3 de impact score e o cluster mais relevante, em uma frase cada | ||
@@ -84,2 +97,2 @@ | ||
| **Nunca apague, modifique ou sobrescreva arquivos pré-existentes do projeto.** | ||
| Este skill escreve APENAS em `_reversa_bugs/generated/` e `_reversa_sdd/traceability/bugs.md` (ambos views regeneráveis). Os `bug.md` são somente leitura aqui: inconsistência se reporta, não se conserta. | ||
| Este skill escreve APENAS em `_reversa_bugs/<contexto>/generated/` e `_reversa_sdd/traceability/bugs.md` (ambos views regeneráveis). Os `bug.md` são somente leitura aqui: inconsistência se reporta, não se conserta. |
@@ -110,7 +110,14 @@ # Schema do bug.md (schema_version: 1) | ||
| ## Trava de conclusão (DONE.md) | ||
| Quando a closure policy é satisfeita, o fix grava `DONE.md` na pasta do bug (data, `resolution_kind` | ||
| e o aviso de somente leitura). Pasta com `DONE.md` é INTOCÁVEL por qualquer agente: reabrir exige o | ||
| usuário remover a trava, ou um bug novo com `regression-of`. | ||
| ## Invariantes (o /reversa-debugger-graph valida e PARA com erro, nunca conserta em silêncio) | ||
| - `status: resolved` exige `resolution_kind` preenchido e `closure.satisfied: true` | ||
| - `DONE.md` sem `status: resolved`, ou `resolved` + `closure.satisfied` sem `DONE.md`, é inconsistência | ||
| - `resolution_kind: fixed` exige `root_cause.state: confirmed`, `regression_tests` não vazio e `spec_verdict` preenchido | ||
| - ID duplicado, referência a ID inexistente, autorrelação e ciclo de `duplicate-of` são erros | ||
| - Relação `proposed` nunca entra em priorização automática nem no impact score |
| # Registro de Bugs (Reversa Bugs) | ||
| > Gerado pelo Reversa em {{DATA}}. Este arquivo é o contrato do registro de bugs deste projeto. | ||
| > Source of truth: cada `bugs/<ID>/bug.md`. Tudo em `generated/` é projeção regenerável. | ||
| > Source of truth: cada `<contexto>/bugs/<ID>/bug.md`. Tudo em `generated/` é projeção regenerável. | ||
@@ -23,2 +23,4 @@ ## Configuração do projeto | ||
| Os bugs são agrupados por **contexto** (feature, módulo ou caso de uso, na linguagem de quem reporta). Cada contexto é uma pasta agregadora com TUDO daquela área: bugs, inspeções e views. A pasta nasce sob demanda, quando o primeiro problema da área é reportado; nada é criado vazio. | ||
| ```text | ||
@@ -28,7 +30,8 @@ _reversa_bugs/ | ||
| ├── taxonomy.yaml vocabulário controlado de area/module/feature | ||
| ├── bugs/BUG-<data>-<sufixo>-<slug>/ pasta única do bug (endereço IMUTÁVEL, nunca se move) | ||
| │ ├── bug.md registro canônico | ||
| │ ├── evidence/ ├── debate/ └── fix/ | ||
| ├── inspections/<feature>/ relatórios do pente-fino | ||
| └── generated/ views regeneradas pelo /reversa-debugger-graph (não editar à mão) | ||
| └── <contexto>/ ex.: sistema-de-credito/, carrinho-de-compras/ | ||
| ├── bugs/BUG-<data>-<sufixo>-<slug>/ pasta única do bug (endereço IMUTÁVEL, nunca se move) | ||
| │ ├── bug.md registro canônico | ||
| │ ├── evidence/ ├── debate/ └── fix/ | ||
| ├── inspections/<varredura>/ relatórios do pente-fino do contexto | ||
| └── generated/ views do contexto, regeneradas pelo /reversa-debugger-graph | ||
| ``` | ||
@@ -42,2 +45,7 @@ | ||
| **Trava de conclusão:** ao satisfazer a closure policy, o bug recebe `DONE.md` na pasta e vira | ||
| SOMENTE LEITURA para todos os agentes. Reabertura: remover a trava conscientemente, ou registrar um | ||
| bug novo com `regression-of`. A lista dos travados aparece no `graph.html` do contexto (view | ||
| derivada, sem edição manual). | ||
| ## Regra de rastreabilidade | ||
@@ -44,0 +52,0 @@ |
| --- | ||
| name: reversa-debugger | ||
| description: Registrador de bugs do Reversa. Faz intake, triagem, dedupe, classificação, rastreabilidade SPEC↔CODE↔TEST↔BUG e correlação BUG↔BUG, criando a pasta única do bug em `_reversa_bugs/bugs/`. Nunca corrige. Use quando o usuário digitar "/reversa-debugger", "reversa-debugger", "registrar bug", "reportar erro", "documentar um bug", "achei um erro no sistema" ou descrever um defeito pedindo para registrá-lo. Ponto de entrada do Time Reversa Bugs; a correção é ato separado via `/reversa-debugger-fix`. | ||
| description: Registrador de bugs do Reversa. Faz intake, triagem, dedupe, classificação, rastreabilidade SPEC↔CODE↔TEST↔BUG e correlação BUG↔BUG, criando a pasta única do bug dentro da pasta agregadora do contexto (feature/módulo/caso de uso) em `_reversa_bugs/<contexto>/bugs/`. Nunca corrige. Use quando o usuário digitar "/reversa-debugger", "reversa-debugger", "registrar bug", "reportar erro", "documentar um bug", ou reclamar de um defeito com frase natural ("deu pau no sistema de crédito", "o carrinho tá com problema de cálculo", "a tela X quebrou"). Ponto de entrada do Time Reversa Bugs; a correção é ato separado via `/reversa-debugger-fix`. | ||
| license: MIT | ||
@@ -17,2 +17,6 @@ compatibility: Claude Code, Codex, Cursor, Gemini CLI e demais agentes compatíveis com Agent Skills. | ||
| O registro é organizado por **contexto**: cada feature/módulo/caso de uso ganha uma pasta agregadora em `_reversa_bugs/<contexto>/` que concentra TUDO daquela área (relatos, bugs, inspeções e views). Assim, quem trata bugs de áreas diferentes nunca mistura as coisas. A pasta do contexto não existe até alguém reclamar daquela área, mas nasce IMEDIATAMENTE quando o usuário diz onde está o problema, porque ela recebe as evidências desde o primeiro print. | ||
| Seu fluxo tem 4 etapas, nesta ordem: **0) resolver o contexto → 1) anotar os relatos e receber evidências → 2) registrar os bugs → 3) gerar as views.** | ||
| ## Antes de começar | ||
@@ -43,32 +47,56 @@ | ||
| 3. Crie `_reversa_bugs/taxonomy.yaml` semeando `area`/`module`/`feature` dos componentes de `_reversa_sdd/architecture.md` e `domain.md` (se existirem). Sem extração, crie com listas vazias e um comentário apontando `/reversa`. | ||
| 4. Crie as pastas `bugs/`, `inspections/`, `generated/`. | ||
| O bootstrap cria APENAS esses dois arquivos. Nenhuma pasta é criada vazia: as pastas de contexto nascem sob demanda (seção abaixo). | ||
| Se `_reversa_bugs/` existir, apenas leia o `README.md` e o `taxonomy.yaml` e siga. | ||
| ## Processo de registro | ||
| ## Etapa 0: resolução do contexto (SEMPRE a primeira coisa) | ||
| ### 1. Entrevista | ||
| Todo bug pertence a um contexto: a feature, módulo ou caso de uso de que o usuário está falando. O usuário quase nunca diz o slug; ele fala natural ("deu pau no sistema de crédito", "o carrinho tá com problema de cálculo"). Antes de qualquer anotação: | ||
| Pergunte o que faltar (não pergunte o que o usuário já contou): | ||
| 1. Liste as pastas de contexto já existentes em `_reversa_bugs/` (todo diretório, exceto arquivos da raiz) | ||
| 2. Case a fala do usuário com: pastas existentes primeiro, depois `taxonomy.yaml` (area/module/feature) e nomes de specs em `_reversa_sdd/` | ||
| 3. Se o usuário NÃO disse onde está o problema, PERGUNTE via menu (nunca pule esta pergunta): | ||
| 1. O que era esperado e o que aconteceu | ||
| 2. Passos para reproduzir e frequência (sempre? às vezes? ambiente específico?) | ||
| 3. Evidências disponíveis (log, print, trace); copie-as depois para `evidence/` do bug | ||
| 4. Severidade e prioridade, via menu com as opções `critical/high/medium/low` e `P0..P3` explicadas | ||
| ``` | ||
| Esse problema é de qual área? | ||
| ### 2. Dedupe | ||
| [1] <contexto-existente> (já tem N bugs registrados) | ||
| [2] Criar novo contexto: <slug-proposto> (proposto a partir da sua descrição) | ||
| [3] Outro: descreva a área com suas palavras | ||
| ``` | ||
| 4. Resolvido o contexto, **crie a pasta IMEDIATAMENTE** se não existir: `_reversa_bugs/<contexto>/` com `bugs/` e `intake/` dentro. Ela precisa existir já, porque o usuário vai passar imagens e documentos de evidência a partir de agora. (`inspections/` e `generated/` continuam nascendo sob demanda.) | ||
| 5. Slug do contexto: kebab-case curto e reconhecível na linguagem do usuário (ex.: `mira-studio-full`, `sistema-de-credito`, `carrinho-de-compras`) | ||
| ## Etapa 1: anotação dos relatos (intake) | ||
| Anotar vem ANTES de registrar. Um desabafo do usuário costuma conter vários problemas misturados, com prints no meio; sua primeira função é ser o escrivão: | ||
| 1. Crie `_reversa_bugs/<contexto>/intake/relato-<YYYYMMDD-HHMM>.md` e vá anotando cada problema relatado, na ordem, com as palavras do usuário e as suas observações | ||
| 2. Toda imagem, print ou documento que o usuário passar: salve em `intake/` ao lado do relato (nomes descritivos, ex.: `intake/teleprompter-retangulo-vermelho.png`) e referencie no ponto certo do relato | ||
| 3. Pergunte o que faltar de cada problema (esperado vs observado, passos, frequência), sem repetir o que o usuário já contou | ||
| 4. Continue anotando até o usuário sinalizar que terminou. Só então pergunte severidade e prioridade de cada problema anotado, via menu com `critical/high/medium/low` e `P0..P3` explicadas | ||
| ## Etapa 2: registro dos bugs (só depois de anotar tudo) | ||
| Um relato pode virar vários bugs (um por defeito distinto). Para CADA problema anotado, siga o processo abaixo. | ||
| ### 2.1 Dedupe | ||
| Antes de criar, procure duplicata: | ||
| 1. Se `generated/catalog.jsonl` existir, filtre por module/feature/palavras do título; senão, faça grep nos `bugs/*/bug.md` | ||
| 2. Leia o corpo só dos 5-10 candidatos mais próximos | ||
| 3. Se encontrar duplicata provável, apresente menu: atualizar o bug existente (acrescentando a nova ocorrência em Evidence), criar mesmo assim como novo, ou "Outro". Nunca decida sozinho. | ||
| 1. Procure primeiro dentro do contexto: `_reversa_bugs/<contexto>/generated/catalog.jsonl` se existir, senão grep em `<contexto>/bugs/*/bug.md` | ||
| 2. Procure também nos outros contextos (`_reversa_bugs/*/generated/catalog.jsonl`): o usuário pode ter reportado o mesmo defeito noutra área | ||
| 3. Leia o corpo só dos 5-10 candidatos mais próximos | ||
| 4. Se encontrar duplicata provável, apresente menu: atualizar o bug existente (acrescentando a nova ocorrência em Evidence), criar mesmo assim como novo, ou "Outro". Nunca decida sozinho. | ||
| 5. **Duplicata travada**: se a duplicata tiver `DONE.md` na pasta, ela é somente leitura. Não a atualize: proponha registrar um bug NOVO com relação `regression-of` apontando para o travado (o defeito voltou). | ||
| ### 3. Identidade | ||
| ### 2.2 Identidade | ||
| 1. ID canônico: `BUG-<YYYYMMDD>-<sufixo>`, onde o sufixo são 4 caracteres base32 derivados de hash curto de título+data+hora. Merge-safe: nunca reutilize nem "conserte" IDs. | ||
| 2. `display_number`: maior `display_number` existente + 1 (apelido humano; colisão de display_number entre branches não é erro, o ID canônico é a identidade). | ||
| 3. Valide que o ID não existe em `bugs/`. Existindo (improvável), gere outro sufixo. | ||
| 2. `display_number`: maior `display_number` existente em QUALQUER contexto + 1 (apelido humano global; colisão entre branches não é erro, o ID canônico é a identidade). | ||
| 3. Valide que o ID não existe em nenhum `_reversa_bugs/*/bugs/`. Existindo (improvável), gere outro sufixo. | ||
| ### 4. Classificação | ||
| ### 2.3 Classificação | ||
@@ -79,3 +107,3 @@ 1. `area`, `module`, `feature` DEVEM usar valores de `taxonomy.yaml`. Se nada servir, use `unclassified` e registre a proposta de novo termo em Agent Notes (não invente termos fora do catálogo). | ||
| ### 5. Rastreabilidade vertical (papel Tracer) | ||
| ### 2.4 Rastreabilidade vertical (papel Tracer) | ||
@@ -86,3 +114,3 @@ 1. Localize em `_reversa_sdd/` a seção de spec que define o comportamento esperado (architecture.md, domain.md, specs em `sdd/`). Considere a **spec efetiva**: original + adendos vigentes em `addenda/`. | ||
| ### 6. Correlação horizontal (papel Correlator) | ||
| ### 2.5 Correlação horizontal (papel Correlator) | ||
@@ -93,8 +121,8 @@ 1. Compare com os bugs existentes (mesmo módulo, mesma spec, mesmos arquivos, sintoma parecido) | ||
| ### 7. Criação da pasta do bug | ||
| ### 2.6 Criação da pasta do bug | ||
| Crie `_reversa_bugs/bugs/BUG-<data>-<sufixo>-<slug>/`: | ||
| Crie `_reversa_bugs/<contexto>/bugs/BUG-<data>-<sufixo>-<slug>/`: | ||
| 1. `bug.md` conforme `references/bug-schema.md` (schema_version 1, `status: open`, `phase: triaging`, closure.policy do README) | ||
| 2. `evidence/` com os artefatos coletados (nunca logs gigantes dentro do Markdown; corpo aponta caminhos relativos) | ||
| 2. `evidence/` com as evidências DAQUELE defeito copiadas do `intake/` (o intake preserva o relato bruto original; nunca logs gigantes dentro do Markdown; corpo aponta caminhos relativos) | ||
| 3. A pasta é o endereço definitivo do bug: **nunca será movida nem renomeada**. Status muda só no front matter. | ||
@@ -104,13 +132,14 @@ | ||
| ### 8. Views | ||
| ## Etapa 3: views (parte da documentação, não um extra) | ||
| Atualize as views de `generated/` e o espelho `_reversa_sdd/traceability/bugs.md` seguindo o protocolo do `/reversa-debugger-graph` (ou informe o usuário para rodá-lo, se preferir manter o registro rápido). Nunca edite views à mão fora do protocolo. | ||
| Registrados os bugs, gere as views do contexto SEM esperar que o usuário peça: elas são o resultado final da documentação. Siga o protocolo do `/reversa-debugger-graph` para `_reversa_bugs/<contexto>/generated/` (index.md, catalog.jsonl, matrix.md, graph.md, graph.html, spec-matrix.md) e o espelho `_reversa_sdd/traceability/bugs.md`. O `graph.html` autocontido (grafo visual + tabela de bugs abertos) é a peça que o usuário abre no navegador. Nunca edite views à mão fora do protocolo. | ||
| ## Relatório final ao usuário | ||
| 1. ID canônico + display_number e caminho absoluto da pasta criada | ||
| 2. Spec vinculada (ou `spec-gap`) | ||
| 3. Relações propostas, marcadas como `proposed` | ||
| 4. Severidade/prioridade registradas | ||
| 5. Se `security_suspected`: aviso sobre visibilidade restrita | ||
| 1. Bugs registrados nesta sessão: ID canônico + display_number de cada um, o contexto e os caminhos das pastas | ||
| 2. Caminho do relato de intake e do `generated/graph.html` do contexto | ||
| 3. Spec vinculada (ou `spec-gap`) por bug | ||
| 4. Relações propostas, marcadas como `proposed` | ||
| 5. Severidade/prioridade registradas | ||
| 6. Se `security_suspected`: aviso sobre visibilidade restrita | ||
@@ -117,0 +146,0 @@ Termine com: |
@@ -20,3 +20,4 @@ --- | ||
| 1. Leia `.reversa/state.json` (`output_folder`, `chat_language`, `doc_language`) | ||
| 2. Se `_reversa_bugs/` não existir, execute o bootstrap do registro descrito no `/reversa-debugger` (README com closure policy, taxonomy.yaml, pastas) | ||
| 2. Se `_reversa_bugs/` não existir, execute o bootstrap do registro descrito no `/reversa-debugger` (APENAS README com closure policy e taxonomy.yaml; nenhuma pasta vazia) | ||
| 2.1. Resolva o **contexto** (pasta agregadora da feature/módulo/caso de uso) como no `/reversa-debugger`: case a fala do usuário com as pastas de contexto existentes em `_reversa_bugs/` e com o taxonomy.yaml, confirme via menu, e só crie `_reversa_bugs/<contexto>/` quando a varredura de fato produzir artefatos | ||
| 3. Pergunte a feature alvo se não veio no argumento, oferecendo as features conhecidas do `taxonomy.yaml` como opções + "Outro" | ||
@@ -72,7 +73,7 @@ | ||
| 3. Apresente a lista de candidatos ao usuário (menu multiescolha: registrar todos os confirmados, escolher quais, ou "Outro") antes de criar | ||
| 4. Registre os aceitos EM SÉRIE seguindo o protocolo do `/reversa-debugger` (IDs merge-safe atribuídos um a um, `origin.type: inspection`, rastreabilidade e relações preenchidas). Achado com sinal de segurança segue o fluxo restrito. | ||
| 4. Registre os aceitos EM SÉRIE seguindo o protocolo do `/reversa-debugger`, dentro de `_reversa_bugs/<contexto>/bugs/` (IDs merge-safe atribuídos um a um, `origin.type: inspection`, rastreabilidade e relações preenchidas). Achado com sinal de segurança segue o fluxo restrito. | ||
| ## Etapa 4: relatório | ||
| Escreva `_reversa_bugs/inspections/<feature>/report.md`: | ||
| Escreva `_reversa_bugs/<contexto>/inspections/<varredura>/report.md` (crie `inspections/` do contexto agora, na primeira varredura): | ||
@@ -84,3 +85,3 @@ 1. Mapa da feature (specs, código, testes, dados) | ||
| Atualize as views pelo protocolo do `/reversa-debugger-graph`. | ||
| Atualize as views do contexto (`_reversa_bugs/<contexto>/generated/`, incluindo o `graph.html`) pelo protocolo do `/reversa-debugger-graph`. | ||
@@ -87,0 +88,0 @@ ## Relatório final ao usuário |
+1
-1
| { | ||
| "name": "reversa", | ||
| "version": "1.2.54", | ||
| "version": "1.2.55", | ||
| "description": "Transform legacy systems into executable specifications for AI coding agents", | ||
@@ -5,0 +5,0 @@ "bin": { |
+1
-1
@@ -248,3 +248,3 @@ # Reversa | ||
| A repository-native causal defect memory: every bug is a self-contained folder under `_reversa_bugs/bugs/` with a YAML front matter record traceable to the specs (`SPEC ↔ CODE ↔ TEST ↔ BUG`), evidence, optional multi-agent debate state and the correction change set. Registering and fixing are strictly separate acts. | ||
| A repository-native causal defect memory, organized by **context** (the feature/module/use case the user is talking about): each context folder under `_reversa_bugs/<context>/` aggregates everything of that area (annotated reports in `intake/`, self-contained bug folders, inspections and generated views incl. a clickable `graph.html`). Every bug carries a YAML front matter record traceable to the specs (`SPEC ↔ CODE ↔ TEST ↔ BUG`), a visual fix plan approved before any change, and a `DONE.md` lock once closed. Registering and fixing are strictly separate acts. | ||
@@ -251,0 +251,0 @@ | Agent | Role | |
New alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Fixed alerts
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Improved metrics
- Total package byte prevSize
1121199
0.94%No dependency changes