# Feature Parity Audit

> Audita as funcionalidades de um SaaS de referência navegando pelo produto com o Playwright MCP (preset pronto para o Codental, app.codental.com.br), repete os mesmos fluxos no app do usuário (localhost ou staging) e gera um relatório de gaps com backlog priorizado. Use quando o usuário pedir comparação de funcionalidades com um concorrente, paridade de features, "o que falta no meu site/sistema", auditoria de funcionalidades, feature gap analysis, benchmarking de produto ou testes exploratórios de fluxos (agendamento, cadastro, orçamento, financeiro) com Playwright.

- Skill: `dougfsantos2026/feature-parity-audit` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add dougfsantos2026/feature-parity-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dougfsantos2026/feature-parity-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: dougfsantos2026 (https://skillmd.com/u/dougfsantos2026)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/dougfsantos2026/feature-parity-audit

---


# Feature Parity Audit

Auditoria de paridade de funcionalidades entre um **produto de referência** (concorrente) e o **app do usuário**, executada com o Playwright MCP em navegador real.

O resultado não é um relatório de bugs: é um **inventário de funcionalidades comparado** e um **backlog priorizado** do que falta implementar.

Preset incluído: Codental (software odontológico). O mesmo processo serve para qualquer par referência/app — troque o baseline.

## Pré-requisitos

1. **Playwright MCP configurado** no cliente. Config recomendada para esta skill (`~/.cursor/mcp.json`):

```json
{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y", "@playwright/mcp@latest",
        "--caps=testing,storage",
        "--viewport-size=1440x900",
        "--output-dir=./audit/artifacts"
      ]
    }
  }
}
```

`--caps=testing` habilita `browser_verify_*`; `--caps=storage` habilita `browser_storage_state` (reaproveitar login entre sessões e alternar entre perfis). Modo headed (padrão) é preferível: reCAPTCHA e código por e-mail/SMS exigem intervenção humana.

No Claude Code, o equivalente é `claude mcp add playwright -- npx -y @playwright/mcp@latest --caps=testing,storage --viewport-size=1440x900 --output-dir=./audit/artifacts`, conferido com `claude mcp list`. Detalhes em `HANDOFF.md`.

2. **Acesso legítimo à referência**: conta própria do usuário (trial ou assinatura). No Codental o cadastro é aberto em `https://app.codental.com.br/registration/sign_up`.
3. **App do usuário rodando** e acessível (ex.: `http://localhost:3000`), de preferência com dados de teste.

Se o Playwright MCP não estiver disponível no ambiente, pare e informe: as fases 2 e 3 não podem ser simuladas com `curl`. A fase 1 (recon) funciona sem ele.

### Como chamar os scripts

A sessão roda no diretório do app do usuário, mas os scripts moram no diretório da skill. Resolva o caminho uma vez e reutilize:

```bash
SKILL_DIR=~/.claude/skills/feature-parity-audit     # skill pessoal (Claude Code)
# SKILL_DIR=.claude/skills/feature-parity-audit     # skill do projeto
# SKILL_DIR=~/.cursor/skills/feature-parity-audit   # Cursor
```

Todos os exemplos abaixo usam `python3 "$SKILL_DIR/scripts/..."`. Caminhos de **saída** são relativos ao projeto do app (`audit/...`) — é lá que a auditoria mora.

## Regras invioláveis

- **Nenhuma mensagem é disparada.** Nunca acionar envio de WhatsApp, SMS ou e-mail para paciente — nem em teste, nem "só para ver o que acontece". Automação, anamnese, confirmação de consulta, orçamento e documento são auditados **por inspeção**: tela de configuração, modelo de mensagem, variáveis disponíveis, gatilhos, histórico de envios já existentes. Chegou na tela com o botão de enviar? Registre os campos e **pare ali**. Se a única forma de verificar algo for disparando, o status é `bloqueado` com motivo "exige disparo real".
- **Conta própria, sempre.** Nunca usar credenciais de terceiros, nunca tentar burlar login, paywall ou gating de plano. Funcionalidade indisponível no plano contratado é registrada como `bloqueado`, não investigada por outros meios.
- **Zero dado real de paciente.** O tenant da referência precisa ser trial/demo com dados sintéticos. Se aparecer qualquer dado pessoal real, não capture screenshot, não copie para o relatório (LGPD).
- **Só leitura no que for de terceiro.** Criar registros apenas no tenant de teste do usuário. Nunca excluir/alterar dados que não foram criados na própria auditoria.
- **Ritmo humano.** Uma sessão de navegador por vez, sem paralelizar requisições contra a referência. Se aparecer bloqueio, rate limit ou captcha, pare e pergunte ao usuário.
- **Comparar funcionalidade, não copiar produto.** Registre *o que* o produto faz e *quais campos/estados* existem. Nunca copie código, HTML, CSS, textos de marketing ou assets.

## Fase 0 — Briefing

Decisões já fechadas para a auditoria Codental. Não repergunte; apenas confirme o que ainda falta (marcado como **pendente**) e siga.

| Item | Decisão |
|---|---|
| Acesso à referência | Trial de 7 dias com acesso aparentemente total. **Sem pressa:** o usuário retoma o acesso quando precisar, e a auditoria é retomável (ver "Continuidade de acesso"). |
| Perfis de acesso | O usuário tem todos os perfis, mas ainda **não definiu o padrão de permissão de cada um**. A matriz de permissões da referência é entregável desta auditoria, não pré-requisito. |
| Ritmo | **Incremental, em fatias.** Poucas funcionalidades por vez, comparadas no app do usuário antes de seguir. Sem big bang. |
| Profundidade | **Criar registros** ponta a ponta nos dois lados, com dados sintéticos prefixados `Teste QA`. |
| Mensageria | **Proibido disparar mensagem** (WhatsApp, SMS, e-mail). Automação é auditada por inspeção de configuração. |
| Mobile | Incluir, mas como **passe final** (Fatia 6), não a cada fluxo. |
| Saída | `audit/` na raiz do projeto do app do usuário, com versionamento seletivo (ver "Saída e versionamento"). |
| Pendente | URL/porta do app e credenciais de teste por perfil. |

Para auditar outro par referência/app, refaça o briefing das sete perguntas em `references/briefing.md`.

### Continuidade de acesso

Não trate o fim do trial como prazo. A auditoria é feita para sobreviver a interrupção:

- **Evidência primeiro, conclusão depois.** Cada fatia captura screenshot e estrutura da referência em `audit/artifacts/` antes de comparar. Com isso, perder o acesso no meio do caminho não invalida nada do que já foi levantado.
- **Fatia interrompida por falta de acesso** vira `bloqueado` com motivo "acesso à referência indisponível", e a auditoria segue nas partes que já têm evidência.
- **Retomada é normal**, não exceção: o inventário é a fonte da verdade sobre onde parou.

Quando e como renovar o acesso é decisão do usuário — a skill não faz e não sugere contorno de limite de trial. Se a continuidade for importante, o caminho limpo é assinar um mês do plano que cobre os módulos ainda não auditados.

## Fatias de execução

Ordem padrão. Cada fatia é: explorar na referência → repetir no app do usuário → atualizar inventário → relatório parcial → confirmar com o usuário antes da próxima.

| Fatia | Fluxos | Por que nessa ordem |
|---|---|---|
| 1 | F2 pacientes, F3 agenda | Núcleo operacional; sem isso nada mais importa |
| 2 | F7 prontuário/odontograma, F8 orçamento | Coração clínico e comercial, depende de paciente cadastrado |
| 3 | F9 financeiro | Depende de orçamento aprovado na Fatia 2 |
| 4 | F4 automação (só configuração), F11 relatórios | Relatórios só fazem sentido com dados criados nas fatias anteriores |
| 5 | F1 onboarding, F5 autoagendamento, F6 anamnese, F10 documentos, F12 permissões e extras | Cauda longa e matriz de permissões |
| 6 | Passe mobile nos fluxos das Fatias 1 e 2 | Responsividade do que é usado todo dia |

Relatório parcial ao fim de cada fatia:

```bash
python3 "$SKILL_DIR/scripts/build_gap_report.py" audit/inventario.csv --fluxo F2,F3 -o audit/relatorio-fatia1.md
```

## Checklist de progresso

Copie e mantenha atualizado com o TODO tool:

```
- [ ] Fase 1: recon sem login (referência + app do usuário)
- [ ] Fatia 1: F2 pacientes + F3 agenda (referência → meu app → relatório parcial)
- [ ] Fatia 2: F7 prontuário + F8 orçamento
- [ ] Fatia 3: F9 financeiro
- [ ] Fatia 4: F4 automação (config) + F11 relatórios
- [ ] Fatia 5: F1, F5, F6, F10, F12 + matriz de permissões
- [ ] Fatia 6: passe mobile
- [ ] Fechamento: relatório consolidado + backlog priorizado
```

## Fase 1 — Recon sem login

Levanta o mapa de módulos antes de gastar interação de navegador. Rode nos **dois** lados:

```bash
python3 "$SKILL_DIR/scripts/mine_routes.py" https://app.codental.com.br/login --out audit/recon-referencia.md
python3 "$SKILL_DIR/scripts/mine_routes.py" http://localhost:3000 --out audit/recon-meu-app.md
```

O script baixa o HTML com user-agent de navegador, coleta os bundles JS/CSS e extrai strings de rota, agrupando por módulo. Rode `--help` antes de customizar.

Complementos:
- Ler `references/codental-baseline.md` — inventário de módulos da referência já levantado, com o mapeamento rota → funcionalidade e o gating por plano.
- Páginas públicas de produto/preço da referência para o gating de plano (no Codental: `/preco`, `/sistema-para-dentista`).
- No app do usuário: rotas do próprio código (router, controllers, migrations) valem mais que o bundle. Use Grep/Glob.

Saída da fase: lista de módulos candidatos dos dois lados. Rota existir não é evidência de funcionalidade pronta — só define o que investigar na Fase 2.

## Fase 2 — Explorar a referência

Leia `references/playwright-mcp.md` (mapa de ações → tools, padrão snapshot-first, persistência de sessão) e `references/fluxos-canonicos.md` (os fluxos e os pontos de comparação de cada um).

Loop pelos fluxos da fatia corrente (não da auditoria inteira):

1. **Login uma vez.** Autentique com as credenciais do usuário e salve a sessão (`browser_storage_state`) para não relogar a cada fluxo.
2. **Percorra o fluxo real**, do começo ao fim, como um usuário: `browser_navigate` → `browser_snapshot`/`browser_find` → `browser_click`/`browser_fill_form` → verificar. Crie registros com dados sintéticos.
3. **Registre a estrutura, não só o resultado**: campos do formulário (nome, tipo, obrigatoriedade, máscara, validação), status possíveis de um registro, filtros de listagem, ações em massa, opções de exportação, gatilhos de automação, permissões por perfil.
4. **Capture evidência**: `browser_take_screenshot` por etapa relevante, nome `ref-<fluxo>-<etapa>.png`. Anote o caminho no inventário.
5. **Anote o inesperado**: atalhos, integrações (Serasa, Memed, boleto, WhatsApp), campos com IA, automações agendadas. É aí que costumam estar os gaps que o usuário não imaginava.
6. **Tela de envio: registre e pare.** Modelo de mensagem, variáveis, gatilho e destinatário são evidência suficiente. Nenhum disparo.
7. Se um fluxo estiver indisponível no plano, marque `bloqueado` e siga. Não insista.

Alimente `audit/inventario.csv` (schema em `assets/inventario-template.csv`) enquanto explora, uma linha por funcionalidade granular — não uma linha por módulo. Granularidade correta: "agenda: sugestão automática de horário livre", não "agenda".

## Fase 3 — Repetir no app do usuário

Mesmos fluxos da fatia, mesma ordem, mesmos pontos de comparação. Sem improvisar critérios novos: a régua é o inventário da Fase 2.

Para cada linha do inventário, atribua `meu_status`:

| Status | Critério |
|---|---|
| `ok` | Existe e cobre o mesmo caso de uso ponta a ponta |
| `parcial` | Existe mas incompleto (falta campo, automação, filtro, exportação, validação) — descreva o que falta em `observacao` |
| `ausente` | Não existe |
| `bloqueado` | Não foi possível verificar (permissão, plano, ambiente) — diga o motivo |
| `na` | Não se aplica ao produto do usuário (decisão de escopo, não gap) |

Evidência é obrigatória para `ok` e `parcial`: screenshot ou trecho de snapshot que comprove. Sem evidência, o status é `bloqueado`.

Funcionalidade de mensageria auditada só por configuração recebe `ok`/`parcial` normalmente, com `observacao` começando por "verificado por configuração, sem disparo". Só é `bloqueado` quando nem a configuração é inspecionável.

Erros de console (`browser_console_messages`) e requisições falhando (`browser_network_requests`) no app do usuário entram numa seção separada do relatório: são bugs encontrados de passagem, não gaps de funcionalidade.

Ao fim de cada fatia: gere o relatório parcial, mostre ao usuário os gaps encontrados e **pergunte se segue para a próxima fatia ou se ele quer implementar algo antes**. Nunca encadeie fatias sem esse aval.

## Fase 4 — Classificar e gerar o relatório

Preencha `prioridade` de cada linha:

- `P0` — bloqueia a operação básica da clínica (agendar, cadastrar paciente, registrar recebimento).
- `P1` — diferencial competitivo forte, citado no marketing da referência e usado no dia a dia (confirmação automática, orçamento com aprovação, odontograma).
- `P2` — conveniência, ganho de tempo, relatórios avançados.
- `P3` — nicho, cosmético ou dependente de integração paga.

Gere o relatório:

```bash
python3 "$SKILL_DIR/scripts/build_gap_report.py" audit/inventario.csv -o audit/relatorio-paridade.md
```

O script calcula a paridade por módulo e monta o backlog ordenado por prioridade (`ok`=1, `parcial`=0,5, `ausente`=0; `na`/`bloqueado` ficam fora do denominador e são listados à parte). Não faça essas contas na mão.

## Fase 5 — Backlog e fechamento

No relatório final, para cada gap `P0`/`P1` escreva uma linha acionável: **o que implementar**, **onde entra no app do usuário** (rota/tela existente), **dependência** (integração externa, modelo de dados novo, job agendado). Sem estimativa de prazo.

Feche o resumo com: paridade geral e por módulo, os 5 gaps de maior impacto, o que não foi verificado (e por quê) e o que a referência **não** tem que o app do usuário tem (vantagem a preservar).

Template em `assets/relatorio-template.md`.

### Entregável extra: matriz de permissões

O usuário ainda não definiu o que cada perfil pode ver. Enquanto audita a referência, monte `audit/matriz-permissoes.md`: uma linha por módulo/ação, uma coluna por perfil (dono, dentista, secretária), marcando o que a referência libera para cada um. Isso serve como **proposta de padrão** para o app do usuário — apresente como sugestão, não como verdade, e aponte onde o app dele já divergiria.

## Saída e versionamento

Tudo em `audit/` na raiz do projeto do app do usuário. Versione o conhecimento durável e ignore o que é pesado, efêmero ou sensível:

```gitignore
# Auditoria de paridade
audit/artifacts/
audit/session-*.json
audit/snapshots/
```

Versionado (vale revisar em PR e consultar meses depois): `inventario.csv`, `relatorio-paridade.md`, `relatorio-fatia*.md`, `matriz-permissoes.md`, `recon-*.md`.

Ignorado: screenshots (pesados e podem conter dado de tela), snapshots brutos e arquivos de sessão (contêm cookie de autenticação — **nunca** comitar).

Crie o `.gitignore` antes de gerar a primeira evidência, não depois.

## Retomada

Auditoria em fatias passa de uma sessão por definição. Ao ser invocada de novo, antes de qualquer coisa: leia `audit/inventario.csv`, identifique a última fatia com linhas preenchidas, confirme se o acesso à referência ainda está ativo, informe ao usuário onde parou e retome da fatia seguinte. Nunca recomece do zero sem confirmar.

## Arquivos de apoio

- `HANDOFF.md` — estado da auditoria, instalação (Cursor e Claude Code) e o que perguntar antes de começar. Leia primeiro ao assumir a auditoria em outro agente ou outra máquina.
- `references/briefing.md` — as sete perguntas do briefing, para reusar a skill com outro par referência/app.
- `references/codental-baseline.md` — inventário de módulos da Codental (rota → funcionalidade), gating por plano e integrações conhecidas.
- `references/fluxos-canonicos.md` — os 12 fluxos da auditoria com passos e pontos de comparação.
- `references/playwright-mcp.md` — mapa ação → tool, snapshot-first, sessão persistida, dados sintéticos, obstáculos comuns.
- `scripts/mine_routes.py` — recon do mapa de rotas sem login.
- `scripts/build_gap_report.py` — relatório e backlog a partir do inventário.
- `assets/inventario-template.csv` — schema do inventário.
- `assets/relatorio-template.md` — estrutura do relatório final.