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):

{
  "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:

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.

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.

Relatório parcial ao fim de cada fatia:

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:

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:

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:

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:

# 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.