# Praxis Table Playground Second-Opinion Prompt

Faça uma análise criteriosa e independente da estratégia de curadoria dos cenários do playground de `@praxisui/table`.

Seu papel aqui não é apenas concordar com o plano. Você deve atuar como uma segunda opinião técnica/editorial exigente, procurando:

- pontos cegos;
- simplificações perigosas;
- capacidades subestimadas ou superestimadas;
- cenários redundantes;
- cenários ausentes;
- riscos de comunicação errada sobre a maturidade real do componente.

## Contexto

O componente `@praxisui/table` é mais do que uma grid configurável. Pela leitura do código-fonte e da documentação da lib, ele já combina:

- modo remoto com bootstrap por schema;
- modo local com precedência formal de fonte de dados;
- filtro dinâmico como feature transversal, com `praxis-filter`, metadata, persistência local e contrato backend;
- renderers ricos, inclusive `compose`;
- seleção, row actions e bulk actions;
- governança de colunas com reorder, teclado, undo e persistência;
- verificação de schema via ETag com reconciliação;
- settings/editor com documento canônico autorável;
- DSL de regras com helpers nativos de JSON, tempo, listas e texto;
- expansão de linhas com contrato tipado e restrições explícitas de virtualização;
- virtualização como modo governado.

Ao mesmo tempo, a investigação também encontrou limites importantes no runtime atual:

- `behavior.sorting.multiSort` ainda é `schema-only`;
- `behavior.filtering.columnFilters.enabled` ainda é `schema-only`;
- `behavior.dragging.rows` ainda é `schema-only`;
- expansão é bloqueada quando virtualização está ativa na política atual;
- export aparece como affordance de toolbar, mas não deve ser tratado automaticamente como fluxo end-to-end completo;
- a README ainda contém exemplos de eventos/API desatualizados em relação ao runtime real.

## Problema Atual do Playground

A curadoria atual do playground da tabela parece excessivamente orientada por domínio e pouco orientada por capacidade.

Exemplos do problema:

- cinco cenários operacionais (`minimal`, `financial`, `crm`, `sla`, `backoffice`) reaproveitam a mesma gramática de runtime com datasets e copy diferentes;
- vários demos de regras parecem fragmentos do mesmo showcase, com pouca diferenciação real de interação;
- os três exemplos genéricos de expansão parecem variantes de layout empacotadas como presets separados, quando poderiam ser um único laboratório com patches;
- recursos fortes do componente, como filtro dinâmico, modo local, schema reconciliation, settings-driven authoring, seleção/bulk e governança de colunas, estão sub-representados ou praticamente ausentes;
- a vitrine atual comunica bem “rules styling”, mas comunica mal a ideia de plataforma governada para dados enterprise.

## Objetivo do Plano

O plano proposto tenta substituir a vitrine atual por um catálogo menor, mais claro e mais honesto, organizado por capacidade.

Catálogo alvo proposto:

1. `Remote CRUD Baseline`
2. `Dynamic Filter Workbench`
3. `Local Data Projection`
4. `Renderer Gallery`
5. `Rules and DSL Playground`
6. `Selection and Bulk Operations`
7. `Column Governance`
8. `Schema Reconciliation`
9. `Settings-Driven Authoring`
10. `Expansion Lab`
11. `Virtualized High Volume`

Racional do plano:

- reduzir redundância entre cenários orientados por domínio;
- usar patches para variantes, em vez de multiplicar presets quase iguais;
- destacar capacidades estratégicas e diferenciais reais da tabela;
- evitar que o playground prometa maturidade maior que a do runtime;
- reposicionar `praxis-table` como superfície governada de dados, não só como demo de badges/regras.

## Documento-base do plano

Use como referência principal o documento:

- `projects/praxis-table/docs/playground-scenario-curation-plan.md`

## O que eu quero da sua resposta

Quero uma revisão crítica de verdade, não um resumo.

Avalie:

1. Se o diagnóstico do catálogo atual está correto ou superficial.
2. Se o catálogo alvo realmente cobre o poder do componente.
3. Se algum cenário proposto está abstrato demais ou genérico demais.
4. Se falta algum cenário essencial para provar valor enterprise.
5. Se algum cenário proposto deveria ser fundido, renomeado, quebrado ou removido.
6. Se a separação entre “Renderer Gallery” e “Rules and DSL Playground” está boa ou artificial.
7. Se “Settings-Driven Authoring” merece mesmo ser um cenário flagship ou deveria ser incorporado a outro.
8. Se “Schema Reconciliation” está sendo tratado com a importância correta.
9. Se “Virtualized High Volume” deve ser cenário próprio ou apenas patch de outro.
10. Se a proposta respeita bem os limites atuais do runtime e evita oversell.

## Formato esperado da resposta

Responda com:

1. `Veredito executivo`
   - diga se o plano está forte, incompleto, enviesado ou mal calibrado.

2. `Principais achados`
   - liste os problemas ou acertos mais importantes, em ordem de impacto.

3. `Ajustes recomendados no catálogo`
   - diga exatamente o que manter, fundir, criar, remover ou renomear.

4. `Riscos de comunicação`
   - destaque onde o playground ainda pode induzir interpretação errada sobre o componente.

5. `Catálogo final recomendado`
   - proponha sua própria versão final, se diferente.

## Instrução final

Se você discordar do plano, seja explícito. Prefiro uma crítica dura e útil a uma validação diplomática.