Estrutura inicial, ambiente IA

This commit is contained in:
victor
2026-05-14 09:54:24 -03:00
commit 48095a3c64
49 changed files with 4596 additions and 0 deletions
@@ -0,0 +1,33 @@
---
name: vitruvio-form-review
description: "Revise e ajuste formularios e processos Vitruvio em XML ou BPMN. Use para validar namespace, skeleton, bind com defaultValue, eventos como initScript, valueChange, onClickScript, itemChange, scripts CDATA em Rhino ES5 e compatibilidade com componentes Vitruvio."
argument-hint: "Descreva o formulario, componente ou regra que precisa revisar."
---
# Revisao de Formulario Vitruvio
## Quando usar
- Ajustes ou revisao de arquivos `.xml` e `.bpmn` do Vitruvio.
- Erros de bind, evento, componente, namespace ou estrutura do formulario.
- Duvidas sobre em qual evento implementar uma regra de negocio.
## Objetivo
Revisar a estrutura do formulario antes da alteracao, aplicar apenas mudancas compativeis com Vitruvio e confirmar que o script Rhino esta encaixado no evento certo.
## Procedimento
1. Identifique se o artefato e formulario web, mobile ou XML de processo. Se a demanda for claramente mobile-only, prefira o agente especialista de mobile.
2. Confira a estrutura base: namespace oficial, `schemaLocation`, `descriptorScript`, `form`, `name`, `initScript`, `validators` e `buttons`.
3. Valide os blocos de `bind`; todo `parameter` deve conter `defaultValue`.
4. Mapeie o comportamento pedido para o evento correto usando o [checklist de revisao](./references/checklist.md).
5. Confirme componentes e IDs existentes antes de adicionar novos atributos ou trocar a hierarquia do XML.
6. Se houver script em `CDATA`, aplique Rhino ES5: `var`, concatenacao incremental de SQL e HTML, e comparacoes com Java usando `==` ou `!=`.
7. Reaproveite padroes existentes no repositorio antes de criar estruturas novas.
8. Ao concluir, explique o que foi alterado, o evento escolhido e qualquer risco residual de runtime.
## Saida esperada
- XML ou BPMN ajustado com mudancas minimas e compativeis com producao.
- Explicacao curta do motivo do evento e da estrutura escolhida.
- Registro claro do que foi validado na revisao.
## Recursos
- [Checklist de revisao](./references/checklist.md)
@@ -0,0 +1,29 @@
# Checklist de Revisao
## Estrutura base
- Preserve o namespace `http://www.davinti.com.br/vitruvio/form` e o `schemaLocation` oficial na raiz quando o artefato for formulario Vitruvio.
- Confirme a presenca e a ordem logica dos blocos `descriptorScript`, `form`, `name`, `initScript`, `validators` e `buttons` quando o tipo de arquivo usar esse skeleton.
- Mantenha IDs e nomes existentes sempre que possivel para evitar quebra de bind e scripts acoplados.
## Bind e dados
- Em `bind`, todo `parameter` precisa de `defaultValue`, inclusive para `string`, `number` e `date`.
- Reuse parametros ja existentes antes de criar novos binds paralelos.
- Se a alteracao depende de variavel de processo, confira se ela sai de `execution.getVariable` ou se precisa ser registrada no `initScript`.
## Escolha de evento
- `initScript`: inicializacao de globais, filtros padrao, datas iniciais e estado de tela.
- `valueChange`: recarga de campos dependentes e widgets quando filtros mudam.
- `itemChange`: persistencia e validacao de celulas editaveis em `DBTable`.
- `onClickScript`: acoes principais como gerar, enviar, processar ou abrir fluxo auxiliar.
- `TabChangeScript`: alternancia de abas e atualizacao de widgets dependentes da aba atual.
## Script embarcado
- Use apenas sintaxe compativel com Rhino ES5.
- Monte SQL e HTML com concatenacao incremental.
- Use `engine.getField`, `engine.getLabel`, `engine.getWidget` e `engine.setGlobalVariable` seguindo os padroes do repositorio.
- Evite criar validacoes redundantes para componentes que ja existem em tela.
## Fontes internas do workspace
- `Vitruvio/Documentação/eventos-vitruvio.md`
- `Vitruvio/Documentação/Componentes/README.md`
- `Vitruvio/Documentação/Componentes/*.ts`
@@ -0,0 +1,33 @@
---
name: vitruvio-rhino-diagnostic
description: "Diagnostique e corrija scripts Rhino ES5 do Vitruvio em arquivos .js ou blocos CDATA de XML. Use para erros de sintaxe ES6, db.query retornando null, comparacoes com objetos Java, uso de libService.loadScript, SQL ou HTML montados errado, globais do engine e bugs de runtime em formularios, processos, libs ou paineis."
argument-hint: "Descreva o script, erro ou comportamento inesperado."
---
# Diagnostico de Script Rhino Vitruvio
## Quando usar
- Falhas em scripts `.js` do Vitruvio ou em `CDATA` dentro de `.xml`.
- Erros de runtime ligados a `db.query`, `queryRow`, `engine`, `execution`, `sendMessageToVitruvio` ou libs carregadas via `libService.loadScript`.
- Ajustes em formularios, processos, paineis e libs compartilhadas sem introduzir sintaxe incompativel.
## Objetivo
Encontrar a causa raiz do problema em runtime Rhino, corrigir com a menor mudanca segura possivel e preservar compatibilidade de producao.
## Procedimento
1. Identifique onde o script roda: lib, formulario, processo, painel ou widget.
2. Verifique incompatibilidades de sintaxe primeiro usando o [guia de falhas comuns](./references/common-failures.md).
3. Confirme se as libs necessarias foram carregadas antes do uso.
4. Revise o acesso a dados: `db.query` retorna `null` sem linhas; quando existir, percorra com `.each(...)`.
5. Revise comparacoes com objetos Java e valores vindos da plataforma usando `==` e `!=`.
6. Garanta que SQL e HTML estejam montados com concatenacao incremental e parametros nomeados.
7. Se a logica depender de globais, confirme registro por `engine.setGlobalVariable` antes do consumo em botoes ou eventos.
8. Ao finalizar, descreva o defeito encontrado, o ajuste aplicado e o risco residual se houver dependencia de dados externos.
## Saida esperada
- Correcao compativel com Rhino ES5.
- Explicacao curta da causa raiz.
- Validacao do ponto de falha mais provavel e do padrao correto adotado.
## Recursos
- [Falhas comuns e padroes corretos](./references/common-failures.md)
@@ -0,0 +1,27 @@
# Falhas Comuns e Padroes Corretos
## Sintaxe incompativel
- Troque `let` e `const` por `var`.
- Nao use template strings, arrow functions, optional chaining ou outros recursos modernos nao suportados.
- Em comparacoes com objetos Java, prefira `==` e `!=`.
## Banco e consultas
- `db.query(sql, params)` retorna `null` quando nao ha linhas.
- Se o resultado existir, ele ja possui ao menos um registro e deve ser percorrido com `.each(function (row) { ... })`.
- Use `db.queryRow` quando a expectativa for uma unica linha.
- Prefira parametros nomeados e evite concatenar valores diretamente na clausula SQL.
## SQL e HTML
- Monte blocos com concatenacao incremental: `var sql = ""; sql += " SELECT ...";`.
- Mantenha identacao consistente nos trechos adicionados por concatenacao.
- Evite blocos gigantes sem helper quando houver repeticao clara de montagem.
## Engine e globais
- Registre globais em `initScript` ou no ponto de bootstrap antes de chama-las em eventos.
- Use `engine.getField`, `engine.getLabel`, `engine.getWidget` e `execution.getVariable` conforme o contexto do artefato.
- Nao assuma que uma variavel de processo ja esta populada; valide a origem do dado.
## Fontes internas do workspace
- `Vitruvio/Documentação/eventos-vitruvio.md`
- `Vitruvio/Documentação/queries-padroes.md`
- `Vitruvio/Libs/`
@@ -0,0 +1,34 @@
---
name: vitruvio-sql-script-case
description: "Crie ou ajuste scripts Oracle PL SQL por caso no DavinTI Vitruvio. Use para gerar .sql, .pks ou .pkb com comentario de CASO, convencoes PRC_VTR ou FNC, schema explicito, tratamento de excecoes, consulta segura de metadata e preparo de DDL sem executar nada no banco."
argument-hint: "Descreva o caso, o objeto SQL e o resultado esperado."
---
# Script SQL por Caso
## Quando usar
- Criacao ou ajuste de arquivos `.sql`, `.pks` e `.pkb` no padrao DavinTI e Vitruvio.
- Demandas que pedem procedure, function, package, query de apoio ou DDL versionado.
- Casos em que e necessario consultar metadata ou objetos do banco sem executar mudancas no ambiente.
## Objetivo
Produzir scripts Oracle prontos para revisao e execucao manual, mantendo o historico por caso, convencoes do time e limites seguros de acesso ao banco.
## Procedimento
1. Identifique se a demanda e de consulta, ajuste de logica PL SQL ou geracao de DDL.
2. Se faltar contexto de tabela, view, coluna ou schema, consulte metadata apenas com `SELECT`, `DESCRIBE` ou ferramentas equivalentes de inspecao.
3. Comece pelo [template base](./assets/caso-template.sql) e troque os placeholders do caso.
4. Use schemas explicitos, convencoes `PRC_VTR_*` e `FNC_*`, e mantenha formatacao consistente com o repositorio.
5. Prefira `SELECT ... INTO` com `NVL` ou `CASE` em vez de cursores desnecessarios.
6. Trate excecoes de forma explicita, incluindo `WHEN NO_DATA_FOUND THEN` quando aplicavel.
7. Se a demanda envolver DDL ou alteracao estrutural, gere apenas o arquivo; nao execute no banco.
8. Ao concluir, descreva o que precisa de execucao manual e quais validacoes foram feitas por inspecao.
## Saida esperada
- Script Oracle alinhado ao caso e pronto para revisao.
- Comentario de historico no padrao do time.
- Descricao curta das premissas, da validacao feita e do que depende de execucao manual.
## Recursos
- [Checklist SQL](./references/checklist.md)
- [Template base](./assets/caso-template.sql)
@@ -0,0 +1,21 @@
-- CASO XXX - [usuario] - DD-MM-YYYY - [descricao breve da mudanca]
CREATE OR REPLACE PROCEDURE VITRUVIO.PRC_VTR_NOME_DA_PROCEDURE (
p_chave IN NUMBER,
p_saida OUT VARCHAR2
) AS
v_valor NUMBER;
BEGIN
SELECT NVL(MAX(campo_exemplo), 0)
INTO v_valor
FROM VITRUVIO.SUA_TABELA
WHERE CHAVE_EXEMPLO = p_chave;
p_saida := TO_CHAR(v_valor);
EXCEPTION
WHEN NO_DATA_FOUND THEN
p_saida := '0';
END PRC_VTR_NOME_DA_PROCEDURE;
/
-- Se a demanda envolver DDL, gere em arquivo separado e execute manualmente via DBA ou fluxo aprovado.
@@ -0,0 +1,22 @@
# Checklist SQL
## Antes de escrever
- Identifique o numero do caso, usuario responsavel e data da alteracao.
- Verifique se o objeto ja existe no repositorio para reaproveitar padroes de assinatura e formatacao.
- Quando houver duvida de schema, coluna ou tipo, faca apenas inspecao segura de metadata.
## Convencoes do script
- Adicione comentario de historico no formato `-- CASO [numero] - [usuario] - [data] - [descricao]`.
- Use `PRC_VTR_*` para procedures e `FNC_*` para functions quando for novo desenvolvimento.
- Use schema explicito em tabelas e objetos compartilhados.
- Mantenha palavras-chave SQL em maiusculo e identacao compativel com os arquivos existentes.
## Logica PL SQL
- Prefira `SELECT ... INTO` com `NVL` ou `CASE` antes de criar cursores sem necessidade.
- Trate `NO_DATA_FOUND` de forma explicita quando o fluxo exigir fallback controlado.
- Preencha parametros `OUT` antes de `COMMIT` quando houver esse padrao no objeto.
## Limites de seguranca
- Nao execute `CREATE`, `ALTER`, `DROP`, `TRUNCATE`, `INSERT`, `UPDATE`, `DELETE`, `MERGE`, `GRANT` ou `REVOKE` como parte da analise.
- Gere DDL e scripts de mudanca em arquivo para execucao manual posterior.
- Se a validacao depender do ambiente, deixe isso explicitado no resultado.