# Plano Tecnico Revisado: Suporte Oficial a Dados Locais (JSON) na `praxis-table`

## 1. Objetivo
Implementar suporte oficial a dados locais via input `[data]` na `praxis-table`, mantendo regressao zero no fluxo remoto (`resourcePath`) e garantindo que o filtro dinamico funcione de forma real em modo local.

## 2. Decisoes de Produto e Engenharia
- Mudanca aditiva, sem breaking change para consumidores atuais.
- `resourcePath` explicito continua soberano quando informado.
- `data` ativa modo local oficial quando nao houver `resourcePath` efetivo.
- Conexao persistida entra apenas como fallback quando nao houver `resourcePath` explicito nem modo local ativo.
- Runtime, editor e documentacao devem mostrar o mesmo modo efetivo.
- Filtro dinamico em local deve ser funcional (nao apenas visual), sem chamadas HTTP.

## 3. Estado Atual Validado (snapshot em codigo)
### 3.1 `praxis-table`
- Template principal esta acoplado a `resourcePath` para render de tabela e filtro.
- Empty state aparece quando `resourcePath` esta vazio, mesmo se existirem dados locais.
- `onAdvancedFilterSubmit/Clear` so dispara `fetchData()` quando existe `resourcePath`.
- Nao existe engine explicita de avaliacao de `advancedFilters` para dataset local.

### 3.2 `praxis-filter`
- O componente aceita `fieldMetadata` estatico e, quando presente, evita carregamento de schema remoto.
- O payload emitido no `submit` eh um DTO dinamico limpo (`Record<string, any>`), removendo valores vazios.
- O formato dos valores varia por tipo de campo (range, dateRange, select com objeto, etc), o que exige avaliador local tipado.

### 3.3 Editores
- Ja existe fallback de metadata por colunas em partes do editor.
- Ainda ha risco de UX contraditoria (configuracao server ativa quando runtime efetivo eh local).

### 3.4 Drift de contrato
- README ja sinaliza uso com `[data]`.
- Runtime/metadata publica ainda nao garantem esse contrato de ponta a ponta.

## 4. Contrato Final (API Publica + Runtime)
1. Novo input no componente:
   - `@Input() data: any[] | null = null;`
2. Normalizacao:
   - `resourcePathNormalized = (resourcePath ?? '').trim()`
   - `hasExplicitResourcePath = resourcePathNormalized.length > 0`
   - `hasLocalData = Array.isArray(data)`
3. Modos efetivos:
   - `remote`: existe `resourcePath` efetivo.
   - `local`: `resourcePath` vazio e `data` eh array (inclui `[]`).
   - `empty`: sem `resourcePath` efetivo e sem `data` valido.
4. Precedencia por origem:
   - `resourcePath` explicito (input/quick-connect/editor) > `data` > conexao persistida.
5. Conflito `resourcePath + data`:
   - Mantem `remote`, ignora `data`, logando warning apenas em debug.
6. Metadata publica:
   - Incluir `data` em `PRAXIS_TABLE_COMPONENT_METADATA.inputs`.

## 5. Comportamento Alvo por Cenario
| Cenario | Modo efetivo | Comportamento alvo |
|---|---|---|
| Standalone com `resourcePath` | `remote` | Fluxo atual inalterado |
| Standalone com `[data]` sem `resourcePath` | `local` | Render + sort + paginacao + advanced filter client-side |
| Standalone com `resourcePath` + `[data]` | `remote` | `data` ignorado (warning debug) |
| Standalone sem `resourcePath` e sem `data` | `empty` | Empty state com CTA de conexao |
| `praxis-crud` com `metadata.resource.path` | `remote` | Sem regressao |
| `praxis-crud` sem `metadata.resource.path` | `empty` (no CRUD) | Mantem comportamento atual |

## 6. Filtro Dinamico em Modo Local (requisito critico)
### 6.1 Renderizacao do filtro no modo local
- O `praxis-filter` deve renderizar tambem em `local` (nao apenas em `remote`).
- Em `local`, passar `fieldMetadata` derivado das colunas da tabela.
- `resourcePath` deve ser passado como string (vazia ou virtual), apenas para contrato do componente; sem uso de backend.
- Definir `persistenceKey` estavel por tabela para evitar colisao de preferencias entre instancias locais.

### 6.2 Fonte de metadata para o filtro local
- Base: `config.columns` com `filterable !== false`.
- Mapeamento minimo recomendado:
  - `string/custom` -> input textual (contains).
  - `number/currency/percentage` -> numero/range.
  - `date` -> date ou dateRange.
  - `boolean` -> toggle/select boolean.
- Aplicar overrides de metadata ja existentes em `advancedFilters.settings.alwaysVisibleFieldMetadataOverrides`.
- Se metadata estiver incompleta, cair para comportamento deterministico (input textual).

### 6.3 Contrato de payload local (shape esperado)
O avaliador local deve suportar os formatos realmente emitidos pelo `praxis-filter`:
- Primitivos: `string | number | boolean | Date`.
- Arrays: `any[]` (multiselect, chips, etc).
- Faixa numerica/tempo: `{ start, end }`.
- Faixa numerica legado: `{ minPrice, maxPrice }`.
- Faixa de data: `{ startDate, endDate, preset?, label? }`.
- Select/lookup assinado por objeto: `OptionDTO` ou objeto equivalente (`id`, `value`, `label`, ...).

### 6.4 Engine de avaliacao local
Implementar pipeline local explicito: `filtro -> ordenacao -> paginacao`.

Pseudo fluxo:

```ts
function recomputeLocalView(): void {
  const source = localDataSource;
  const filtered = source.filter((row) => matchesAdvancedCriteria(row, filterCriteria));
  const sorted = applyClientSort(filtered, sortState, visibleColumns);
  const total = sorted.length;
  const paged = applyClientPagination(sorted, pageIndex, pageSize);

  dataSubject.next(paged);
  syncLocalPaginationTotal(total);
}
```

Contrato de matching (deterministico):
- `string` criterio: `contains` case-insensitive e accent-insensitive.
- `number/boolean/date`: igualdade semantica.
- `array` criterio: regra `IN` (qualquer valor valido).
- `{start,end}` ou `{minPrice,maxPrice}`: comparacao de faixa inclusiva.
- `{startDate,endDate}`: faixa de datas inclusiva (normalizada).
- `objeto select/lookup`: comparar por `id`; fallback para `value` e depois `label`.
- `null/undefined/empty`: ignorar criterio (defensivo, mesmo com payload limpo).

### 6.5 UX e performance do filtro local
- Submit/Clear devem recalcular dataset local sem HTTP.
- `change` (debounce) pode ficar desabilitado na fase 1 para evitar recomputacao excessiva em datasets grandes.
- Atualizar contador de filtros ativos e chips com o mesmo contrato de remoto.
- Em local, esconder mensagens/CTAs de schema remoto no filtro/tabela.

## 7. Matriz de Transicao de Modo (obrigatoria)
| De | Para | Acoes obrigatorias |
|---|---|---|
| `empty` | `remote` | `configure`, `loadSchema/verify`, `fetchData`, limpar erros |
| `empty` | `local` | hidratar dados locais, reset de pagina/sort/selecao, limpar erros remotos |
| `remote` | `local` | parar efeitos remotos, limpar `schemaError/dataError`, recomputar pipeline local |
| `remote` | `empty` | limpar datasource e estados remotos |
| `local` | `remote` | configurar service, carregar schema (se preciso), buscar remoto |
| `local` | `empty` | limpar datasource e manter empty state coerente |

## 8. Plano de Implementacao Revisado
### Fase 0: Camada central de modo e origem
1. Adicionar `@Input() data`.
2. Criar helpers centralizados:
   - `getDataMode(): 'remote' | 'local' | 'empty'`
   - `isRemoteMode()`, `isLocalMode()`, `isEmptyMode()`
   - `hasUsableDataSource()`
3. Resolver `resourcePath` efetivo por origem (explicito vs persistido).
4. Logar modo/origem apenas em debug.

### Fase 1: Ciclo de vida e transicoes
1. `ngOnInit`: nao restaurar conexao persistida quando local ja estiver resolvido.
2. `ngOnChanges`: tratar `data` e `resourcePath` pela matriz de transicao.
3. Entrando em local: limpar erros remotos, resetar pagina/sort/selecao, popular fonte local.
4. Entrando em remote: manter fluxo atual `configure -> loadSchema/verify -> fetchData`.

### Fase 2: Template orientado a modo
1. Trocar condicionais de `resourcePath` por helpers de modo.
2. Exibir tabela em `remote` e `local`.
3. Exibir empty state apenas em `empty`.
4. Limitar quick-connect, disconnect, retry schema/data ao modo `remote`.

### Fase 3: Filtro dinamico local (core)
1. Renderizar `praxis-filter` em `local` com `fieldMetadata` de colunas.
2. Implementar `buildLocalFilterMetadata(columns)`.
3. Implementar `matchesAdvancedCriteria()` e comparadores por tipo/shape.
4. Integrar recalculo local em `onAdvancedFilterSubmit/Clear`.
5. Garantir `getPaginationLength()` refletindo total filtrado local.

### Fase 4: Sort/paginacao locais consistentes
1. Introduzir estrategia efetiva:
   - em `local`: sempre `client`;
   - em `remote`: respeitar config/default atual.
2. `onPageChange/onSortChange`:
   - local: recalcular pipeline local;
   - remote: manter `fetchData()`.

### Fase 5: Acoes backend-dependent
1. `onRowAction` autoDelete:
   - local: nao chamar API; emitir evento.
2. `onToolbarAction` bulk autoDelete:
   - local: nao chamar API; emitir evento.
3. `retryData/reloadSchema/refetch`:
   - no-op seguro fora de `remote`.

### Fase 6: Editores alinhados
1. Expor `dataMode` para editor.
2. Bloquear/avisar contradicao `local + server` em strategy.
3. Melhorar hints do `FilterSettings` quando metadata vier de colunas locais.
4. Permitir limpar conexao explicitamente (remote -> local).

### Fase 7: Docs, metadata e release notes
1. Atualizar README com precedencia real (`resourcePath > data > persistido`).
2. Incluir exemplo oficial de filtro dinamico em modo local.
3. Atualizar metadata publica com input `data`.
4. Remover drift entre docs, metadata e runtime antes do merge.

## 9. Plano de Testes (minimo obrigatorio)
### 9.1 `praxis-table` runtime
- Renderiza linhas em modo local com `[data]`.
- Atualiza reativamente ao trocar `data`.
- Precedencia `resourcePath > data`.
- Empty state apenas em `empty`.
- Transicoes: `remote->local`, `local->remote`, `local->empty`, `empty->local`.

### 9.2 Filtro dinamico local
- Em local, `onAdvancedFilterSubmit` nao chama `crudService.filter()`.
- Em local, `onAdvancedFilterClear` recomputa dataset sem HTTP.
- Cobrir shapes de payload:
  - primitivo (`string`, `number`, `boolean`),
  - array,
  - `{start,end}`,
  - `{minPrice,maxPrice}`,
  - `{startDate,endDate}`,
  - objeto lookup (`id/value/label`).
- Validar compatibilidade com nested fields (`a.b.c`) usando `getNestedPropertyValue`.

### 9.3 Sort/paginacao locais
- `onSortChange` em local nao chama HTTP e reordena dataset local.
- `onPageChange` em local nao chama HTTP e pagina localmente.
- `getPaginationLength()` reflete total filtrado local.

### 9.4 Template/UX
- Quick connect nao aparece em local.
- Banner/erro remoto nao aparece em local.
- `praxis-filter` aparece em local quando advanced filter esta habilitado.

### 9.5 Metadata publica e docs
- Input `data` presente na metadata.
- README alinhado ao contrato runtime.

### 9.6 Regressao CRUD
- Fluxo remoto atual do `praxis-crud` permanece inalterado.
- Sem regressao em `refetch` apos save/delete.

## 10. Riscos e Mitigacoes
1. Risco: filtro local renderizar mas nao filtrar de fato.
- Mitigacao: engine local obrigatoria + testes de payload real.

2. Risco: conexao persistida sobrescrever local.
- Mitigacao: precedencia por origem + gate no init.

3. Risco: estrategia visual divergir da execucao.
- Mitigacao: estrategia efetiva centralizada (local sempre client).

4. Risco: autoDelete chamar API em local.
- Mitigacao: bloqueio explicito + emissao de eventos.

5. Risco: performance ruim com dataset grande.
- Mitigacao: debounce, recompute apenas em submit na fase 1, documentar limite recomendado.

## 11. Checklist Final de PR
- [x] Input `data` implementado e documentado.
- [x] Resolucao central de modo (`remote|local|empty`) aplicada no runtime.
- [x] Matriz de transicao implementada sem estado residual.
- [x] Template orientado a modo (nao a `resourcePath` cru).
- [x] `praxis-filter` habilitado em local com metadata de colunas.
- [x] Engine local de `advancedFilters` implementada (shapes reais cobertos).
- [x] Sort/paginacao locais sem HTTP.
- [x] `getPaginationLength()` sincronizado com total local filtrado.
- [x] Bloqueio de autoDelete remoto no local.
- [x] Editores alinhados ao modo efetivo.
- [x] Metadata publica atualizada com `data`.
- [x] README e exemplos alinhados ao runtime.
- [x] Testes de regressao local/remote/empty + CRUD aprovados.

Status de execucao da lane (2026-02-23):
- Suite isolada da pre-implementacao executada com `ChromeHeadless` via `cmd.exe`.
- Resultado final: `TOTAL: 48 SUCCESS`.
- Coberturas criticas executadas: preservacao de `pageSize` local e estabilidade de `fieldMetadata`.
- Coberturas de transicao executadas: `remote->local`, `local->remote`, `local->empty`, `empty->local`.
- Revalidacao complementar de regressao em `praxis-crud` (`praxis-crud.component.spec.ts`) executada com `ChromeHeadless` + `zone.js`/`zone.js/testing`.
- Resultado final da suite alvo de CRUD: `TOTAL: 6 SUCCESS`.
- Coberturas de regressao confirmadas em CRUD: encaminhamento de `resourcePath` para `praxis-table` e refresh (`refetch`) apos `save/delete`.
- Evolucao da etapa seguinte (CRUD local sem `metadata.resource.path`) implementada e validada na suite alvo de CRUD.
- Resultado atualizado da suite alvo de CRUD: `TOTAL: 9 SUCCESS`.
- Coberturas adicionais confirmadas: renderizacao da tabela em modo local com `metadata.data`, empty state quando nao ha `resourcePath` nem dados locais e precedencia `resourcePath + data` mantendo fluxo remoto.

Status de validacao operacional (2026-02-24):
- Gate seguro revalidado com ChromeHeadless (Windows): `praxis-table` lane isolada + `praxis-crud` suite completa.
- Resultado da lane isolada `praxis-table`: `TOTAL: 48 SUCCESS`.
- Resultado da suite completa `praxis-crud`: `TOTAL: 30 SUCCESS`.
- Criterio atual de continuidade: manter este gate seguro verde em toda etapa incremental.
- Observacao: `ng test praxis-table` completo permanece fora do gate por drift de compilacao cross-lib no workspace, sem relacao direta com a implementacao local/remote da tabela.

## 12. Fora de Escopo (fase 1)
- Virtualizacao local com garantia de consistencia.
- Otimizacoes avancadas para datasets muito grandes (chunking/worker).

## 13. Pacote Pre-Implementacao (PR-0 a PR-6)
Objetivo: preparar base tecnica e cobertura de regressao para implementar modo local sem quebrar o uso normal remoto.

### 13.1 PR-0 - Characterization Tests Remoto (gate inicial)
Escopo:
1. Congelar comportamento remoto atual em testes.

Entregaveis:
1. Casos cobrindo:
   - bootstrap remoto (`resourcePath` -> `configure/loadSchema/fetchData`);
   - `onSortChange` e `onPageChange` com HTTP em remoto;
   - `onAdvancedFilterSubmit/Clear` com HTTP em remoto;
   - `retryData/reloadSchema/refetch` em remoto;
   - `praxis-crud` chamando `table.refetch()` apos save/delete.
2. Documento curto de baseline com o que esta protegido por teste.

Criterios de aceite:
1. Todos os testes novos verdes.
2. Nenhum comportamento remoto critico sem cobertura.

### 13.2 PR-1 - Contrato de Modo e Precedencia (sem alterar comportamento)
Escopo:
1. Introduzir tipos e helpers de modo sem mudar output funcional.

Entregaveis:
1. `type DataMode = 'remote' | 'local' | 'empty'`.
2. Helpers centrais:
   - `getDataMode()`;
   - `hasExplicitResourcePath()`;
   - `hasLocalDataInput()`.
3. Documento de precedencia oficial:
   - `resourcePath explicito > data > conexao persistida`.

Criterios de aceite:
1. Snapshot de comportamento remoto permanece identico.
2. Logs de debug de modo/origem disponiveis para diagnostico.

### 13.3 PR-2 - Documento Canonico de `resourcePath` no Editor
Escopo:
1. Remover ambiguidade de "string vazia" em apply/save do editor.

Entregaveis:
1. Envelope canonico de autoria com:
   - `bindings.resourcePath`.
2. Handshake editor -> tabela sem side-channel implicito.
3. Testes para:
   - set remoto;
   - clear remoto;
   - round-trip do documento.

Criterios de aceite:
1. Nao existe desconexao remota acidental em save.
2. Limpar conexao e um ato explicito e rastreavel.

### 13.4 PR-3 - Feature Flag de Rollout
Escopo:
1. Isolar novas capacidades locais atras de flag.

Entregaveis:
1. Flag ex.: `behavior.localDataMode.enabled`.
2. Flag default `false`.
3. Telemetria/log de flag ativa por instancia.

Criterios de aceite:
1. Com flag `false`, fluxo remoto e identico ao baseline.
2. Com flag `true`, habilita trilha de evolucao local sem impactar remoto por padrao.

### 13.5 PR-4 - Scaffolding de Integracao Local (sem ligar feature final)
Escopo:
1. Preparar pontos de extensao sem ativar pipeline local completo.

Entregaveis:
1. Estrutura de dados local separada (`localSource`, `localView`, `localTotal`).
2. Stub de `recomputeLocalView()` sem alterar caminho remoto.
3. Ajustes de template por helper de modo, mantendo remoto equivalente.

Criterios de aceite:
1. Delta funcional remoto zero.
2. Codigo pronto para conectar engine local no PR seguinte.

### 13.6 PR-5 - Engine Local em Modulo Puro (isolado)
Escopo:
1. Construir avaliador local fora de `praxis-table` para facilitar teste.

Entregaveis:
1. Modulo puro:
   - `matchesAdvancedCriteria(row, criteria)`;
   - comparadores por shape (`primitive`, `array`, `range`, `dateRange`, `lookupObject`).
2. Suite de testes unitarios da engine.

Criterios de aceite:
1. Cobertura de todos os shapes previstos no contrato.
2. Sem acoplamento com `GenericCrudService` ou Angular component lifecycle.

### 13.7 PR-6 - Guard Rails de Regressao Remota
Escopo:
1. Adicionar protecoes para evitar regressao ao ligar modo local.

Entregaveis:
1. Assertivas:
   - em remoto, nao enviar `fieldMetadata` para `praxis-filter` por engano;
   - em remoto, `onSortChange/onPageChange` continuam com fetch quando estrategia efetiva for server.
2. Testes negativos de regressao:
   - remoto nao usa pipeline local;
   - remoto continua com schema/fetch/filter HTTP.
3. Checklist de release go/no-go.

Criterios de aceite:
1. Suite de regressao remota aprovada.
2. Bloqueios automatizados impedem merge de regressao conhecida.

### 13.8 Ordem de Execucao Recomendada
1. PR-0.
2. PR-1.
3. PR-2.
4. PR-3.
5. PR-4.
6. PR-5.
7. PR-6.

### 13.9 Go/No-Go para iniciar implementacao principal (Fases 0-7)
Todos os itens abaixo devem estar `true`:
1. Baseline remoto protegido por testes (`PR-0`).
2. Precedencia e modo formalizados (`PR-1`).
3. Protocolo de `resourcePath` sem ambiguidade (`PR-2`).
4. Rollout com feature flag pronto (`PR-3`).
5. Scaffolding e engine local testavel disponiveis (`PR-4` e `PR-5`).
6. Guard rails e testes negativos de remoto ativos (`PR-6`).

### 13.10 Status de Execucao Atual (2026-02-24)
1. Pacote pre-implementacao (PR-0 a PR-6) consolidado em codigo e testes da lane isolada.
2. Bloqueio operacional de browser headless no ambiente Linux/sandbox foi contornado com execucao via Chrome do Windows.
3. Trilha segura operacionalizada para regressao continua permanece verde:
   - `praxis-table` lane isolada: `48 SUCCESS`;
   - `praxis-crud` suite completa: `30 SUCCESS`.
4. Revalidacao da suite completa `praxis-table` foi concluida no mesmo ambiente operacional:
   - comando: `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - resultado: `TOTAL: 372 SUCCESS`.
5. Classificacao atual:
   - gate local-data (lane isolada + CRUD full): verde;
   - suite completa `praxis-table`: verde e apta para regressao continua.

### 13.11 Proxima Frente Recomendada (hardening pos-estabilizacao)
1. Concluido: remocao de `// @ts-nocheck` em `projects/praxis-table/src/test-dev/integration-tests/**`, com tipagem restaurada por arquivo.
2. Concluido: setup compartilhado de `TestBed` consolidado em `projects/praxis-table/src/test-dev/integration-tests/testbed.providers.ts`, incluindo providers de `HttpClient`, `API_URL`, pipes e stub de `GlobalConfigService`.
3. Concluido: specs migradas para o setup compartilhado:
   - `advanced-filter-toggle.spec.ts`;
   - `praxis-table-v2-integration.spec.ts`;
   - `row-action-contract.spec.ts`;
   - `end-to-end-workflow.spec.ts`;
   - `auto-delete.spec.ts`;
   - `row-actions-overflow.spec.ts`.
4. Concluido: reexecucao incremental e full executadas apos a consolidacao, mantendo a suite verde.

### 13.12 Status de Estabilizacao Full Suite (2026-02-24)
1. Compilacao TypeScript da suite completa (`tsc -p projects/praxis-table/tsconfig.spec.json --noEmit`) voltou a verde.
2. Imports quebrados em `projects/praxis-table/src/test-dev/integration-tests/**` foram normalizados para `../../lib/**`.
3. Falhas de runtime de `TestBed` por providers ausentes (ex.: `NG0201: No provider found for _HttpClient`) foram eliminadas no fluxo de validacao atual.
4. Expectativas defasadas em specs alvo foram alinhadas ao contrato vigente da `praxis-table`.
5. Execucao full validada:
   - `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - `TOTAL: 372 SUCCESS`.
6. Revalidacao dirigida das specs hardenizadas (sem `@ts-nocheck`) concluida:
   - `migration-system.spec.ts` + `end-to-end-workflow.spec.ts` + `config-editors-integration.spec.ts`;
   - `TOTAL: 62 SUCCESS`.
7. Revalidacao full apos hardening dos integration tests:
   - `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - `TOTAL: 372 SUCCESS`.
8. Consolidacao de setup compartilhado de providers concluida:
   - helper criado em `projects/praxis-table/src/test-dev/integration-tests/testbed.providers.ts`;
   - specs migradas: `advanced-filter-toggle.spec.ts`, `praxis-table-v2-integration.spec.ts`, `row-action-contract.spec.ts`, `end-to-end-workflow.spec.ts`.
9. Revalidacao dirigida pos-consolidacao dos providers:
   - `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing --include projects/praxis-table/src/test-dev/integration-tests/advanced-filter-toggle.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/praxis-table-v2-integration.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/row-action-contract.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/end-to-end-workflow.spec.ts`;
   - `TOTAL: 24 SUCCESS`.
10. Revalidacao full pos-consolidacao dos providers:
   - `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - `TOTAL: 372 SUCCESS`.
11. Expansao da consolidacao de providers para os specs adicionais:
   - `auto-delete.spec.ts`;
   - `row-actions-overflow.spec.ts`.
12. Revalidacao dirigida apos a expansao:
   - `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing --include projects/praxis-table/src/test-dev/integration-tests/advanced-filter-toggle.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/praxis-table-v2-integration.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/row-action-contract.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/end-to-end-workflow.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/auto-delete.spec.ts --include projects/praxis-table/src/test-dev/integration-tests/row-actions-overflow.spec.ts`;
   - `TOTAL: 31 SUCCESS`.
13. Revalidacao full apos a expansao:
   - `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - `TOTAL: 372 SUCCESS`.
14. Revalidacao complementar do wrapper CRUD apos o hardening:
   - `ng test praxis-crud --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - `TOTAL: 30 SUCCESS`.
15. Validacao da lane dedicada:
   - `bash ./scripts/test-table-preimpl-lane.sh`: bloqueada por infraestrutura (`No usable Chromium binary found for headless capture`).
   - fallback operacional via Windows Chrome com os mesmos includes da lane:
     `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing --include ...`;
   - resultado do fallback: `TOTAL: 48 SUCCESS`.
16. Mitigacao operacional validada sem alterar o script da lane:
   - wrapper: `tools/karma/chromium-bin-wrapper.sh` (contorna apenas probe `--dump-dom`);
   - execucao:
     `CHROMIUM_REAL_BIN=<puppeteer-executablePath> CHROMIUM_BIN=tools/karma/chromium-bin-wrapper.sh CHROME_BIN=tools/karma/chromium-bin-wrapper.sh bash ./scripts/test-table-preimpl-lane.sh`;
   - resultado: `TOTAL: 48 SUCCESS`.
17. Revalidacao integrada do gate seguro apos mitigacao:
   - gate legado removido; usar `npm run test:table` e, quando aplicavel, `bash tools/karma/run-table-dsl-compat-gate.sh`;
   - `praxis-table lane`: `PASS` (`TOTAL: 48 SUCCESS`);
   - `praxis-crud full`: `PASS` (`TOTAL: 30 SUCCESS`).
18. Automacao do gate seguro concluida:
   - runner legado removido; `tools/karma/karma.headless.conf.cjs` agora centraliza a configuracao headless;
   - revalidacao sem env manual:
    `npm run test:table`;
   - resultado: `praxis-table lane PASS (48 SUCCESS)` e `praxis-crud full PASS (30 SUCCESS)`.
19. Cobertura adicional no wrapper `praxis-crud` para precedencia remoto > local concluida:
   - novo teste para `metadata.table.resourcePath` prevalecer sobre `metadata.data`;
   - novo teste para `metadata.table.resourcePath` em branco (apenas espacos) manter modo local com `metadata.data`;
   - arquivo: `projects/praxis-crud/src/lib/praxis-crud.component.spec.ts`;
   - validacao dirigida executada com tsconfig temporario isolado (evitando erro externo de compilacao em `praxis-dynamic-fields`):
     `ng test praxis-crud --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing --ts-config .tmp-preimpl-lane/tsconfig.crud-isolated.json --include projects/praxis-crud/src/lib/praxis-crud.component.spec.ts`;
   - resultado: `TOTAL: 11 SUCCESS`.
20. Revalidacao do gate apos ampliar cobertura do CRUD:
   - comando atual: `npm run test:table`;
   - tentativa legada da lane `praxis-table` permaneceu bloqueada por deteccao de Chromium (`No usable Chromium binary found for headless capture`);
   - fallback automatico via `cmd.exe + ChromeHeadless` executou com sucesso;
   - resultado final:
     - `praxis-table lane`: `PASS` (`TOTAL: 48 SUCCESS`);
     - `praxis-crud full`: `PASS` (`TOTAL: 32 SUCCESS`).
21. Revalidacao full da `praxis-table` apos a ampliacao de cobertura no CRUD:
   - comando: `ng test praxis-table --watch=false --browsers=ChromeHeadless --polyfills=zone.js --polyfills=zone.js/testing`;
   - resultado: `TOTAL: 372 SUCCESS`.
22. Hardening da lane no script dedicado concluido:
   - `scripts/test-table-preimpl-lane.sh` agora aplica automaticamente `tools/karma/chromium-bin-wrapper.sh` quando o probe direto de Chromium falha;
   - revalidacao direta da lane, sem env manual:
     `bash ./scripts/test-table-preimpl-lane.sh`;
   - resultado: `TOTAL: 48 SUCCESS`.
   - revalidacao adicional com ambiente limpo de browser vars:
     `env -u CHROMIUM_BIN -u CHROME_BIN -u CHROMIUM_REAL_BIN bash ./scripts/test-table-preimpl-lane.sh`;
   - resultado: `TOTAL: 48 SUCCESS`.
23. Revalidacao do gate seguro apos hardening da lane:
   - comando atual: `npm run test:table`;
   - resultado final: `praxis-table lane PASS (48 SUCCESS)` e `praxis-crud full PASS (32 SUCCESS)`;
   - nesta execucao, a lane concluiu na trilha primaria.
24. Revalidacao completa do gate seguro em modo estrito + full suite:
   - comando:
    `npm run test:table`;
   - resultado final:
     - `praxis-table lane`: `PASS` (`TOTAL: 48 SUCCESS`);
    - `praxis-table lane path`: `headless`;
     - `praxis-crud full`: `PASS` (`TOTAL: 32 SUCCESS`);
     - `praxis-table full`: `PASS` (`TOTAL: 372 SUCCESS`).