@analizza-ai/testspec 0.1.1

package/src/utils/config.js

@@ -0,0 +1,29 @@
+/**
+ * src/utils/config.js
+ * Reads and validates testspec.config.json from the project root.
+ */
+
+import { readFileSync, existsSync } from 'fs';
+import { join } from 'path';
+
+const DEFAULTS = {
+  sdd: 'openspec',
+  agent: 'claude',
+  unitFramework: 'vitest',
+  stubs: { unit: true, integration: true },
+  loadHints: true,
+  chaosHints: true,
+};
+
+/**
+ * @param {string} root  project root directory
+ * @returns {object}
+ */
+export function loadConfig(root) {
+  const configPath = join(root, 'testspec.config.json');
+  if (!existsSync(configPath)) {
+    return { ...DEFAULTS };
+  }
+  const raw = JSON.parse(readFileSync(configPath, 'utf-8'));
+  return { ...DEFAULTS, ...raw };
+}

package/src/utils/logger.js

@@ -0,0 +1,13 @@
+/**
+ * src/utils/logger.js
+ * Thin logger with coloured output via chalk.
+ */
+
+import chalk from 'chalk';
+
+export const log = {
+  info: (msg) => console.log(chalk.cyan(msg)),
+  success: (msg) => console.log(chalk.green('✔ ' + msg)),
+  warn: (msg) => console.warn(chalk.yellow('⚠ ' + msg)),
+  error: (msg) => console.error(chalk.red('✖ ' + msg)),
+};

package/src/utils/sdd-detector.js

@@ -0,0 +1,23 @@
+/**
+ * src/utils/sdd-detector.js
+ * Auto-detects which SDD framework is in use by scanning known folder patterns.
+ */
+
+import { existsSync } from 'fs';
+import { join } from 'path';
+
+const SIGNATURES = [
+  { name: 'openspec', path: 'openspec/changes' },
+  { name: 'speckit', path: 'specs' },
+];
+
+/**
+ * @param {string} root  project root directory
+ * @returns {string|null}  detected SDD name, or null if none found
+ */
+export function detectSdd(root) {
+  for (const sig of SIGNATURES) {
+    if (existsSync(join(root, sig.path))) return sig.name;
+  }
+  return null;
+}

package/templates/agent-instructions/AGENTS.md

@@ -0,0 +1,39 @@
+# testspec — Agent instructions (unified)
+
+This project uses **@analizza-ai/testspec** (SDT — Spec Driven Test).
+
+## Generate tests.md
+
+```bash
+testspec generate [--change <name>] [--api] [--no-stubs]
+```
+
+Reads SDD spec artifacts → builds a prompt → writes `tests.md` + optional test stubs.
+
+## SDD framework: OpenSpec
+
+Artifacts are in `openspec/changes/{change-name}/`:
+- `proposal.md` — intent, non-goals, scope
+- `design.md` — API contracts, DB schema
+- `specs/**/*.md` — behaviour, scenarios, rules
+- `tasks.md` — implementation boundary
+- `tests.md` — **output**: CT-01..N test cases (written by testspec)
+
+## tests.md CT structure
+
+| Field               | Description                              |
+|---------------------|------------------------------------------|
+| Type                | unit / integration / e2e / load / chaos  |
+| Layer               | developer / qa / chaos                   |
+| Precondition        | Required system state before the test    |
+| Input               | Request body / method params             |
+| Expected output     | HTTP response / return value             |
+| DB validation       | SQL query or description of DB state     |
+| Acceptance criteria | Bullet checklist from spec               |
+
+## Other commands
+
+```bash
+testspec validate --results <test-results.json>  # map pass/fail to CTs
+testspec report                                   # gap: which CTs have no stub
+```

package/templates/agent-instructions/CLAUDE.md

@@ -0,0 +1,48 @@
+# /testspec-generate — Spec Driven Test generation
+
+Run `testspec generate` to read the current SDD change and generate `tests.md` + test stubs.
+
+## What this command does
+
+1. Reads spec artifacts from `openspec/changes/{latest}/` (proposal.md, design.md, specs/**/*.md, tasks.md)
+2. Parses them into a SpecContext
+3. Builds a prompt and either:
+   - prints it to chat for you to paste back (default)
+   - calls the Claude API directly (`--api` flag)
+4. Writes `tests.md` with CT-01..N test cases
+5. Generates unit and integration test stubs
+
+## Usage
+
+```bash
+# generate tests.md for the latest change (prints prompt to chat)
+testspec generate
+
+# generate for a specific change
+testspec generate --change my-feature
+
+# call Claude API directly (requires ANTHROPIC_API_KEY)
+testspec generate --api
+
+# skip stub generation
+testspec generate --no-stubs
+```
+
+## tests.md structure
+
+Each CT (test case) follows this table format:
+
+| Field               | Value                        |
+|---------------------|------------------------------|
+| Type                | unit / integration / e2e / load / chaos |
+| Layer               | developer / qa / chaos       |
+| Precondition        | ...                          |
+| Input               | request / params             |
+| Expected output     | response / return value      |
+| DB validation       | SQL assertion or description |
+| Acceptance criteria | · bullet list                |
+
+## When pasting the prompt back
+
+After running `testspec generate` without `--api`, paste the printed prompt into this chat.
+I will generate the full `tests.md` content. Copy my output and save it to the path shown in the CLI output.

package/templates/agent-instructions/copilot.md

@@ -0,0 +1,52 @@
+# testspec — Spec Driven Test context for GitHub Copilot
+
+This project uses **testspec** (`@analizza-ai/testspec`) to generate `tests.md` from SDD spec artifacts.
+
+## How to generate tests.md
+
+Run in terminal:
+```bash
+testspec generate
+```
+
+This prints a structured prompt. Paste it here (in Copilot Chat) and I will generate the full `tests.md`.
+
+## tests.md format
+
+```
+---
+feature: <name>
+change: <change-folder>
+generated: <ISO timestamp>
+sdd: openspec
+sdt: <version>
+stack: { lang, db }
+---
+
+# Tests — <feature>
+
+## Scope
+## Out of scope
+
+## Test cases
+
+### CT-01 — <title>
+| Field               | Value |
+|---------------------|-------|
+| Type                | unit / integration / e2e / load / chaos |
+| Layer               | developer / qa / chaos |
+| Precondition        | ... |
+| Input               | ... |
+| Expected output     | ... |
+| DB validation       | ... |
+| Acceptance criteria | · bullet |
+
+## Load profile hints
+## Chaos scenarios
+```
+
+## SDD artifact locations (OpenSpec)
+- `openspec/changes/{name}/proposal.md`
+- `openspec/changes/{name}/design.md`
+- `openspec/changes/{name}/specs/**/*.md`
+- `openspec/changes/{name}/tasks.md`

package/templates/agent-instructions/skills/testspec-apply-qa.md

@@ -0,0 +1,424 @@
+# testspec-apply-qa
+
+Implementa os scripts de teste QA (k6, Gatling ou outra ferramenta) a partir das tasks pendentes em `./testspec/{feature-name}/tasks.qa.md`, usando `spec.qa.md` como contrato técnico. Gera código real e executável, marcando cada task como concluída após a implementação.
+
+## Quando usar
+
+Após `/testspec-specify-qa` ter gerado `spec.qa.md` e `tasks.qa.md` para a feature.
+
+---
+
+## Instructions
+
+### 0. Ler arquivos globais do projeto QA (SEMPRE, antes de qualquer outra etapa)
+
+Leia **ambos** os arquivos abaixo em paralelo. São obrigatórios — se não existirem, informe o usuário e encerre:
+
+**`./testspec/instructions.md`**
+- Contém: padrões de arquitetura do código, produto, princípios de qualidade, tecnologias e convenções do projeto QA
+- Aplique todas as diretrizes ao gerar o código — elas têm precedência sobre os templates e defaults desta skill
+- Exemplos do que pode conter: padrão de import, estrutura de funções, naming de variáveis, padrão de assertion, configurações de ambiente
+
+**`./testspec/current-feature.md`**
+- Contém: nome da feature atualmente em foco (ex: `kafka-consumer-order-request`)
+- Se existir e tiver um nome válido, **use-o diretamente** como feature ativa — pule a seleção (passo 1)
+- Se estiver vazio ou ausente, execute o passo 1 normalmente
+
+---
+
+### 1. Identificar a feature
+
+> **Atenção:** se `./testspec/current-feature.md` já definiu a feature no passo 0, este passo é ignorado.
+
+**Se argumento passado:** use como nome da feature diretamente.
+
+**Se nenhum argumento e `current-feature.md` está vazio:**
+- Liste os diretórios em `./testspec/` no diretório atual (excluindo `instructions.md` e `current-feature.md`)
+- Se houver apenas um diretório de feature, use-o diretamente
+- Se houver mais de um, pergunte via **AskUserQuestion** (single select):
+  > "Qual feature deseja implementar os testes?"
+
+Se `./testspec/` não existir ou não tiver nenhum diretório de feature:
+```
+Nenhuma feature encontrada em ./testspec/.
+Execute /testspec-specify-qa primeiro.
+```
+
+### 1.1 Fixar a feature em `current-feature.md`
+
+Independentemente de como a feature foi identificada (argumento, seleção ou `current-feature.md` já preenchido), **sempre escreva** o nome da feature no arquivo:
+
+```
+./testspec/current-feature.md
+```
+
+Conteúdo do arquivo (apenas o nome, sem formatação extra):
+```
+{feature-name}
+```
+
+Isso garante que todas as skills subsequentes da sessão (`/testspec-run-qa` e outras) usem a mesma feature sem perguntar novamente.
+
+---
+
+### 2. Ler os artefatos de especificação
+
+Leia **ambos** os arquivos antes de qualquer implementação:
+
+1. `./testspec/{feature-name}/spec.qa.md` — contrato técnico completo
+2. `./testspec/{feature-name}/tasks.qa.md` — checklist de tasks
+
+Extraia de `spec.qa.md`:
+- **Ferramenta e extensão** (`{tool}`, `{ext}`) — linha `> Ferramenta:`
+- **Protocolo de entrada** — HTTP ou Kafka (seção `## Contrato Técnico`)
+- **HTTP method, path, headers, request body** — com tipos e exemplos reais
+- **Response esperada** — status, `Location` header (se presente), body fields
+- **Regras de negócio** — seção `## Regras de Negócio para Testes`
+- **Banco de dados** — tabela e campos a assertar (se presente)
+- **Load profile** — estágios de RPS e duração (se seção Load presente)
+- **Chaos scenarios** — tipo e mecanismo (se seção Chaos presente)
+- **Mapeamento detalhado por CT** — seção `## Casos de Teste — Mapeamento Detalhado`
+
+Extraia de `tasks.qa.md`:
+- Lista de **tasks pendentes** (`- [ ]`) com caminho completo do arquivo a criar
+- Lista de **tasks já concluídas** (`- [x]`) para não reimplementar
+
+---
+
+### 3. Confirmar o escopo de implementação
+
+Se houver tasks pendentes E tasks já concluídas, pergunte via **AskUserQuestion** (single select):
+> "Existem {N} tasks já concluídas e {M} pendentes. O que deseja fazer?"
+
+- **Implementar apenas as pendentes** — continua de onde parou
+- **Reimplementar tudo** — recria todos os scripts (sobrescreve)
+- **Escolher tasks específicas** — exibe lista das pendentes para seleção
+
+Se "Escolher tasks específicas": use **AskUserQuestion** (multi select) com a lista de tasks pendentes.
+
+---
+
+### 4. Implementar cada script
+
+Para cada task selecionada, na ordem em que aparecem no `tasks.qa.md`:
+
+#### 4a. Identificar o tipo de script
+
+A partir do caminho da task:
+- Contém `/e2e/` → script E2E funcional
+- Contém `/load/` → script de carga
+- Contém `/chaos-engineering/` → script de chaos
+
+#### 4b. Identificar o CT correspondente
+
+Extraia o número do CT do nome da task (ex: `CT-01`) e leia o bloco `### CT-01` no `spec.qa.md`.
+
+#### 4c. Gerar o código
+
+Gere o arquivo conforme as regras de implementação abaixo para a ferramenta identificada.
+
+#### 4d. Escrever o arquivo de script
+
+Escreva o arquivo de script (`.js`, `.scala`, etc.) no caminho exato especificado na task, relativo ao diretório atual. Crie os diretórios intermediários se não existirem.
+
+#### 4d.1 Gerar o run plan `.md` (sempre, para todo script gerado)
+
+Imediatamente após criar o script, gere o run plan correspondente:
+
+- O nome do arquivo `.md` é idêntico ao do script, substituindo a extensão por `.md`
+  - Ex: `k6-e2e-create-order-success.js` → `k6-e2e-create-order-success.md`
+- O conteúdo segue o **Formato do Run Plan** definido na skill `/testspec-specify-qa`
+- Popule cada seção com os dados reais extraídos de `spec.qa.md`:
+  - `## Script` — caminho completo do `.js` gerado
+  - `## Execução` — ferramenta, comando com variáveis de ambiente identificadas no script
+  - `## Coleta de Logs` — namespace, pod selector, query Splunk derivados da descrição do run plan
+  - `## Análise de Banco de Dados` — tabela e queries SQL derivadas dos critérios do CT
+  - `## Relatório` — seções fixas conforme o formato padrão
+  - `## Publicação no Confluence` — espaço, página pai e título derivados da descrição do run plan
+- Escreva o `.md` no mesmo diretório do script imediatamente após gerá-lo
+
+#### 4e. Marcar tasks como concluídas
+
+No `tasks.qa.md`, substitua `- [ ]` por `- [x]` nas linhas do script e do seu run plan `.md` (se gerado).
+**Faça isso imediatamente após cada par de arquivos criado** — nunca em lote no final.
+
+#### 4f. Reportar progresso
+
+Após cada script (e run plan, se gerado):
+```
+[x] {caminho do script}   — CT-{NN}: {nome do cenário}
+[x] {caminho do run plan} — run plan para /testspec-run-qa
+```
+
+---
+
+## Regras de Implementação por Ferramenta e Tipo
+
+---
+
+### K6 — E2E Script
+
+**Estrutura obrigatória:**
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+
+// Variáveis de ambiente — nunca hardcode URLs ou credenciais
+const BASE_URL = __ENV.BASE_URL || 'http://localhost:8080';
+const HEADERS = {
+  'Content-Type': 'application/json',
+  // Incluir outros headers do contrato (Authorization, X-Correlation-Id, etc.)
+};
+
+export const options = {
+  vus: 1,
+  iterations: 1,
+  thresholds: {
+    http_req_failed: ['rate==0'],
+    http_req_duration: ['p(95)<2000'],
+  },
+};
+
+export default function () {
+  // --- ARRANGE ---
+  // Payload extraído do CT — use valores reais do spec.qa.md, não placeholders
+  const payload = JSON.stringify({
+    // campos do request body com valores de exemplo reais
+  });
+
+  // --- ACT ---
+  const res = http.{method}(`${BASE_URL}{path}`, payload, { headers: HEADERS });
+
+  // --- ASSERT ---
+  check(res, {
+    // Um check por critério de aceite do CT
+    'status is {código}': (r) => r.status === {código},
+    // Se Location header presente:
+    'Location header presente': (r) => r.headers['Location'] !== undefined,
+    // Se body field:
+    '{campo} no body': (r) => JSON.parse(r.body).{campo} === {valor},
+  });
+
+  // Se Location header presente: extrair ID para uso em asserções
+  // const locationId = res.headers['Location']?.split('/').pop();
+
+  sleep(0.5);
+}
+```
+
+**Regras específicas para E2E:**
+- `vus: 1`, `iterations: 1` — é um teste funcional, não de carga
+- Um `check()` por critério de aceite listado no CT
+- Nomes dos checks descrevem o que estão validando (string legível)
+- Para CT de rejeição: o `check` de status deve ser o código de erro (400, 422, etc.)
+- Se o CT tem critério de banco de dados: adicionar comentário `// TODO: validar banco via endpoint de healthcheck ou query direta`
+- Nunca hardcode URL, senha ou token — sempre `__ENV.VARIAVEL`
+- Adicionar `sleep(0.5)` ao final para não saturar o sistema em iterações sequenciais
+
+---
+
+### K6 — Load Script
+
+**Estrutura obrigatória:**
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+
+const BASE_URL = __ENV.BASE_URL || 'http://localhost:8080';
+const HEADERS = { 'Content-Type': 'application/json' };
+
+// Estágios derivados do loadProfile do spec.qa.md
+export const options = {
+  stages: [
+    { duration: '1m', target: {vus_ramp} },   // warmup — ramp up até o platô
+    { duration: '{duracao}', target: {vus_plateau} }, // platô — carga alvo
+    { duration: '30s', target: 0 },           // cooldown
+  ],
+  thresholds: {
+    http_req_failed:   ['rate<0.01'],          // menos de 1% de erros
+    http_req_duration: ['p(95)<500', 'p(99)<1000'], // latência p95 < 500ms
+  },
+};
+
+export default function () {
+  const payload = JSON.stringify({ /* campos do happy path CT-01 */ });
+  const res = http.{method}(`${BASE_URL}{path}`, payload, { headers: HEADERS });
+
+  check(res, {
+    'status is {código}': (r) => r.status === {código},
+  });
+
+  sleep(1);
+}
+```
+
+**Regras específicas para Load:**
+- Baseado **sempre** no CT de sucesso (happy path)
+- VUs do platô: calcule como `VUs = RPS × latência_média` (use 0.2s se não informado)
+  - Exemplo: 100 RPS × 0.2s = 20 VUs
+- Warmup: rampa de 1 minuto até o platô
+- Cooldown: 30 segundos descendo a zero
+- Thresholds: `p(95) < 500ms` e `error_rate < 1%` como defaults — ajuste se o `loadProfile` especificar outros
+- `sleep(1)` ao final para simular comportamento de usuário real
+- Um arquivo por estágio de RPS definido no `loadProfile`
+
+---
+
+### K6 — Chaos Script
+
+**Estrutura obrigatória:**
+
+```javascript
+import http from 'k6/http';
+import { check, sleep } from 'k6';
+import exec from 'k6/execution';
+
+const BASE_URL = __ENV.BASE_URL || 'http://localhost:8080';
+const HEADERS = { 'Content-Type': 'application/json' };
+
+// Namespace e deployment alvo — configuráveis via env
+const K8S_NAMESPACE  = __ENV.K8S_NAMESPACE  || 'default';
+const K8S_DEPLOYMENT = __ENV.K8S_DEPLOYMENT || '{deployment-name}';
+
+export const options = {
+  stages: [
+    { duration: '2m', target: 20 },   // carga baseline antes do caos
+    { duration: '3m', target: 20 },   // caos injetado durante este estágio
+    { duration: '2m', target: 20 },   // recuperação observada
+    { duration: '30s', target: 0 },
+  ],
+  thresholds: {
+    http_req_failed:   ['rate<0.05'],   // tolerância maior durante caos (5%)
+    http_req_duration: ['p(95)<2000'],
+  },
+};
+
+// Injeção de caos executada uma vez no início do segundo estágio
+export function setup() {
+  // IMPORTANTE: este bloco requer kubectl configurado no ambiente de execução
+  // Substitua pelo mecanismo de caos definido no chaosScenarios do spec.qa.md
+  console.log(`[chaos] Iniciando injeção: {tipo-caos} em ${K8S_DEPLOYMENT}`);
+  // Ex para shutdown-pods:
+  // exec.test.abort() se kubectl não disponível — não falhe silenciosamente
+}
+
+export default function () {
+  const payload = JSON.stringify({ /* campos do happy path CT-01 */ });
+  const res = http.{method}(`${BASE_URL}{path}`, payload, { headers: HEADERS });
+
+  check(res, {
+    'status is {código} or 503 durante caos': (r) => [200, 201, 503].includes(r.status),
+  });
+
+  sleep(1);
+}
+
+export function teardown() {
+  console.log('[chaos] Teardown: restaurar estado do ambiente');
+}
+```
+
+**Regras específicas para Chaos:**
+- Baseado **sempre** no CT de sucesso (happy path)
+- O mecanismo de caos vem do `chaosScenarios` do `spec.qa.md`
+- Se o mecanismo for `shutdown-pods`: comentário explícito de que requer `kubectl`
+- Thresholds mais tolerantes: `error_rate < 5%` e `p(95) < 2000ms`
+- O script **não executa kubectl diretamente** — documenta o comando esperado via `console.log` e instrução em comentário
+- Inclui `setup()` e `teardown()` para marcar início/fim do caos
+
+---
+
+### Gatling — E2E Script
+
+**Estrutura obrigatória (Scala):**
+
+```scala
+import io.gatling.core.Predef._
+import io.gatling.http.Predef._
+import scala.concurrent.duration._
+
+class {FeatureName}E2E{CenarioName}Simulation extends Simulation {
+
+  val httpProtocol = http
+    .baseUrl(sys.env.getOrElse("BASE_URL", "http://localhost:8080"))
+    .header("Content-Type", "application/json")
+
+  val payload = """{
+    // payload do CT com valores reais
+  }"""
+
+  val scen = scenario("{nome do cenário}")
+    .exec(
+      http("{nome da requisição}")
+        .{method}("{path}")
+        .body(StringBody(payload))
+        .check(status.is({código}))
+        // Se Location header:
+        // .check(header("Location").exists)
+        // Se body field:
+        // .check(jsonPath("$.{campo}").is("{valor}"))
+    )
+
+  setUp(
+    scen.inject(atOnceUsers(1))
+  ).protocols(httpProtocol)
+}
+```
+
+---
+
+### Kafka (qualquer ferramenta) — adaptações
+
+Se o protocolo for Kafka (identificado no `spec.qa.md`):
+- Substituir chamada HTTP por publish no tópico configurado via `__ENV.KAFKA_BOOTSTRAP_SERVERS`
+- Para k6: usar extensão `xk6-kafka` com `import { Writer, SchemaRegistry } from 'k6/x/kafka'`
+- Nomenclatura do arquivo: `{tool}-e2e-consume-{cenario}{ext}` (verbo `consume` em vez de método HTTP)
+- O script publica a mensagem e faz polling do banco ou de um endpoint de healthcheck para confirmar persistência
+
+---
+
+### 5. Relatório final
+
+Após implementar todas as tasks selecionadas:
+
+```
+Implementação concluída para '{feature-name}'
+
+Scripts criados:
+  [x] src/test/features/{feature-name}/e2e/{tool}-e2e-{...}{ext}
+  [x] src/test/features/{feature-name}/e2e/{tool}-e2e-{...}{ext}
+  [x] src/test/features/{feature-name}/load/{tool}-load-{...}{ext}
+  [x] src/test/features/{feature-name}/chaos-engineering/{tool}-dr-{...}{ext}
+
+tasks.qa.md atualizado: {N}/{total} tasks concluídas
+
+Como executar:
+  E2E:   BASE_URL=http://seu-host k6 run src/test/features/{feature-name}/e2e/{tool}-e2e-{...}.js
+  Load:  BASE_URL=http://seu-host k6 run src/test/features/{feature-name}/load/{tool}-load-{...}.js
+  Chaos: K8S_NAMESPACE=seu-ns BASE_URL=http://seu-host k6 run src/test/features/{feature-name}/chaos-engineering/{tool}-dr-{...}.js
+
+Próximo passo: /testspec-run-qa para executar os testes via agente IA.
+```
+
+---
+
+## Guardrails
+
+- **`instructions.md` e `current-feature.md` são lidos SEMPRE** como primeiro passo, antes de qualquer outra ação — não são opcionais
+- **`instructions.md` tem precedência** sobre qualquer template ou default desta skill — se definir padrão de import, assertion, naming ou estrutura de função, siga-o exatamente
+- **`current-feature.md` elimina a pergunta de seleção** — se contiver um nome de feature, use-o diretamente sem perguntar ao usuário
+- **Leia `spec.qa.md` integralmente antes de gerar qualquer linha de código** — o contrato técnico é a fonte da verdade
+- **Nunca use valores placeholder** no código gerado (ex: `"your-customer-id"`, `"TODO"`) — use os valores reais do `spec.qa.md`
+- **Nunca hardcode** URL, host, porta, credencial ou token — sempre `__ENV.VARIAVEL`
+- **Marque cada task como `- [x]` imediatamente** após criar o arquivo — nunca em lote
+- **Um arquivo por task** — não combine múltiplos CTs em um mesmo script
+- **Paths sempre relativos ao diretório atual** — nunca absolutos
+- **Check names em k6 devem ser frases descritivas** — o relatório k6 os exibe como labels; evite nomes genéricos como `"ok"` ou `"check1"`
+- **Não invente critérios de aceite** — implemente somente o que está no `spec.qa.md`; se um critério for impossível de validar na ferramenta, documente com `// NOTE:` e implemente o que for possível
+- **Kafka**: nunca usar chamada HTTP no script se o protocolo for Kafka; adapter explicitamente para xk6-kafka ou equivalente
+- **Chaos**: nunca executar comandos destrutivos diretamente — apenas documentar e logar a intenção via `console.log` e comentários
+- **Run plan**: gerado **sempre** junto com cada script — incondicional, não há flag nem verificação
+- **Um `.md` por script**: o run plan acompanha exatamente o script que descreve — nunca um `.md` cobrindo múltiplos scripts
+- **Conteúdo do run plan**: use apenas dados reais extraídos de `spec.qa.md` — nunca placeholders como `{namespace}` no arquivo final