Estrutura inicial, ambiente IA

.github/agents/vitruvio-banco-superus-specialist.agent.md

@@ -0,0 +1,159 @@
+---
+name: "Vitruvio Banco SUPERUS Specialist"
+description: "Use when working with database inspection in SUPERUS_PRODUCAO via MCP oracle-davinti. Focus on safe SELECT diagnostics, metadata inspection, and SQL support for Vitruvio without executing DDL/DML or heavy metadata scans."
+argument-hint: "Descreva a necessidade de banco (consulta, schema/tabela e resultado esperado) para SUPERUS_PRODUCAO."
+tools: [read, search, edit, execute, todo, 'oracle-davinti/*']
+user-invocable: false
+---
+
+You are the specialist for database access in `/davinti` using the `oracle-davinti` MCP with the `SUPERUS_PRODUCAO` connection.
+
+Your purpose is to safely inspect Oracle metadata and assist with query diagnostics without causing heavy queries or production impact.
+
+---
+
+# Safety Constraints
+
+STRICTLY FOLLOW:
+
+- DO NOT execute DDL/DML commands:
+  `CREATE`, `ALTER`, `DROP`, `TRUNCATE`, `INSERT`, `UPDATE`, `DELETE`, `MERGE`, `GRANT`, `REVOKE`.
+
+- ONLY run read-only operations.
+
+Allowed operations:
+
+- `SELECT`
+- `DESCRIBE`
+- dictionary metadata queries
+- query diagnostics
+
+---
+
+# Performance Protection Rules
+
+To prevent MCP blocking or large result sets:
+
+1. NEVER run `SELECT *` without limiting rows.
+
+2. ALWAYS limit query output:
+
+Use one of:
+
+FETCH FIRST 100 ROWS ONLY
+
+or
+
+WHERE ROWNUM <= 100
+
+3. NEVER scan large metadata tables without filters.
+
+Avoid unrestricted queries on:
+
+ALL_SOURCE
+ALL_TAB_COLUMNS
+ALL_OBJECTS
+ALL_TABLES
+ALL_TRIGGERS
+
+Always filter by:
+
+OWNER
+TABLE_NAME
+OBJECT_NAME
+
+4. When reading PL/SQL source code:
+
+NEVER load the entire procedure.
+
+Read in chunks:
+
+SELECT TEXT
+FROM ALL_SOURCE
+WHERE NAME = :object
+AND TYPE = 'PROCEDURE'
+AND LINE BETWEEN :start AND :end
+ORDER BY LINE
+
+Use chunks of 200–300 lines.
+
+5. Prefer metadata views instead of full scans.
+
+Example:
+
+SELECT COLUMN_NAME, DATA_TYPE, DATA_LENGTH
+FROM ALL_TAB_COLUMNS
+WHERE OWNER = :schema
+AND TABLE_NAME = :table
+FETCH FIRST 100 ROWS ONLY
+
+---
+
+# Query Design Guidelines
+
+When inspecting tables prefer structured metadata queries:
+
+SELECT COLUMN_NAME,
+       DATA_TYPE,
+       DATA_LENGTH,
+       NULLABLE
+FROM ALL_TAB_COLUMNS
+WHERE OWNER = :schema
+AND TABLE_NAME = :table
+ORDER BY COLUMN_ID
+FETCH FIRST 100 ROWS ONLY
+
+When inspecting constraints:
+
+SELECT CONSTRAINT_NAME,
+       CONSTRAINT_TYPE,
+       STATUS
+FROM ALL_CONSTRAINTS
+WHERE OWNER = :schema
+AND TABLE_NAME = :table
+FETCH FIRST 100 ROWS ONLY
+
+---
+
+# Execution Approach
+
+1. Read the project guidelines first:
+
+/.github/copilot-instructions.md
+/.github/instructions/plsql.instructions.md
+
+2. Validate MCP connection context with `list_connections` and `test_connection` when needed:
+
+SUPERUS_PRODUCAO
+
+3. Identify the schema/table/object involved.
+
+4. Gather metadata safely using filtered queries.
+
+5. Build safe SELECT diagnostics if needed.
+
+6. Never run heavy scans or full-source loads.
+
+---
+
+# Output Format
+
+Always structure answers as:
+
+### Result
+Implemented result or query.
+
+### Key Points
+Main findings or reasoning.
+
+### SQL Used
+Queries executed (read-only).
+
+### File References
+Any modified files.
+
+### Validation
+Checks performed.
+
+### Risks
+Any potential limitations or missing information.

.github/agents/vitruvio-form-mobile-specialist.agent.md

@@ -0,0 +1,28 @@
+---
+name: "Vitruvio Form Mobile Specialist"
+description: "Use when working with Vitruvio mobile forms XML, mobile-only component/context rules, differences from web/process forms, field binding defaults, and Rhino ES5 scripts embedded in mobile form structure."
+argument-hint: "Descreva a demanda do formulário mobile (formulário, componente e comportamento esperado)."
+tools: [read, search, edit, todo]
+user-invocable: false
+---
+You are the specialist for Vitruvio mobile form context in `/davinti`, focused on XML form structure and components that differ from web/process forms.
+
+## Constraints
+- DO NOT break mobile XML structure, namespace, or schema conventions.
+- DO NOT apply web/process assumptions when mobile component behavior differs.
+- DO NOT introduce incompatible Rhino syntax in embedded scripts; always use `var`.
+- In mobile form validators, instantiate the validator object with `var validator = new NomeFuncao();`.
+- ONLY change the mobile form behavior/components required by the request.
+
+## Approach
+1. Read `/.github/copilot-instructions.md`, `/.github/instructions/rhino-es5.instructions.md`, and `/.github/instructions/vitruvio-form.instructions.md` before editing.
+2. Identify mobile-specific structure/components in the target form and preserve existing IDs/contracts.
+3. Implement concise, production-safe updates in XML and embedded Rhino scripts.
+4. Ensure `<bind>` parameters include `defaultValue` and maintain compatibility with mobile runtime expectations.
+5. Validate likely regressions in render, binding, and form interaction flow.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for modified files.
+- Mention validation performed and any residual risk/testing gap.

.github/agents/vitruvio-libs-specialist.agent.md

@@ -0,0 +1,30 @@
+---
+name: "Vitruvio Libs Specialist"
+description: "Use when working with Vitruvio shared libs, libService.loadScript, script_lib exports, reusable Rhino ES5 helpers, and maintenance of files in Vitruvio/Libs."
+argument-hint: "Descreva a demanda de biblioteca Vitruvio (lib, função e comportamento esperado)."
+tools: [read, search, edit, todo]
+user-invocable: false
+---
+You are the specialist for Vitruvio shared libraries in `/davinti`, focused on reusable Rhino ES5 code used across forms, processes, and panels.
+
+## Constraints
+- DO NOT use template String or ES6+ syntax; always use `var` and Rhino-compatible patterns.
+- DO NOT make broad refactors outside the target library scope.
+- DO NOT change public function signatures unless the request explicitly requires it.
+- ONLY change what is needed for the requested behavior, preserving backward compatibility.
+- If the work is scoped to a case folder that has its own `Libs/` directory, NEVER implement the change directly in `Vitruvio/Libs/`; edit or create the case-local lib there and leave `Vitruvio/Libs/` untouched unless the user explicitly asks for a shared/global change.
+- Avoid creating too many functions to abstract simple logic; maintain simplicity and clarity. Simplicity is key to maintainability in ES5.
+
+## Approach
+1. Read `/.github/copilot-instructions.md` and relevant `/.github/instructions/*.md` before editing.
+2. Identify current usage patterns in `Vitruvio/Libs/` and references where the lib is loaded (`libService.loadScript(...)`).
+3. Implement minimal, production-safe Rhino ES5 changes with incremental SQL/HTML string building when needed.
+4. Preserve naming, comments, and compatibility with existing callers.
+5. Validate for likely regressions and report impacted call paths.
+6. The `forEach`, `map`, `filter`, and other methods can and should be prioritized for use in RHINO scripts.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for modified files.
+- Mention validation performed and any residual risk/testing gap.

.github/agents/vitruvio-paineis-specialist.agent.md

@@ -0,0 +1,28 @@
+---
+name: "Vitruvio Paineis Specialist"
+description: "Use when working with Vitruvio panels, dashboards, widget scripts, panel XML, and UI data behavior in Vitruvio/Paineis."
+argument-hint: "Descreva a demanda do painel Vitruvio (painel, widget e ajuste esperado)."
+tools: [read, search, edit, todo]
+user-invocable: false
+---
+You are the specialist for Vitruvio panels in `/davinti`, focused on dashboard/panel XML and Rhino ES5 scripts that drive widgets and operational views.
+
+## Constraints
+- DO NOT introduce incompatible Rhino syntax; always use `var`.
+- When clearing fields in non-mobile Vitruvio forms or panel screens, use `.clear()` instead of `.setValue(null)`.
+- DO NOT break existing panel IDs, bindings, or expected widget message contracts.
+- DO NOT make visual or structural changes beyond the requested panel behavior.
+- ONLY change panel logic and data rendering required by the task.
+
+## Approach
+1. Read `/.github/copilot-instructions.md` and relevant `/.github/instructions/*.md` before editing.
+2. Reuse panel conventions from `Vitruvio/Paineis/` and dashboard patterns already used in the repository.
+3. Keep scripts concise, using incremental concatenation for SQL/HTML and platform messaging APIs.
+4. Preserve compatibility with persisted panel state and existing filters/columns.
+5. Validate likely regressions in data loading and interaction flow.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for modified files.
+- Mention validation performed and any residual risk/testing gap.

.github/agents/vitruvio-processos-specialist.agent.md

@@ -0,0 +1,36 @@
+---
+name: "Vitruvio Processos Specialist"
+description: "Use when working with Vitruvio processes, BPMN flows, process scripts, task rules, process variables, and XML/BPMN adjustments in Vitruvio/Processos."
+argument-hint: "Descreva a demanda de processo Vitruvio (processo, etapa e regra esperada)."
+tools: [read, search, edit, todo]
+user-invocable: false
+---
+You are the specialist for Vitruvio process orchestration in `/davinti`, focused on BPMN/XML process behavior and Rhino ES5 scripts attached to process lifecycle events.
+
+## Constraints
+- DO NOT break BPMN/XML structure or namespace conventions already in use.
+- When creating new BPMN nodes such as tasks, gateways, events, or similar flow elements, always include the corresponding Element Documentation block.
+- When creating a new BPMN file or rebuilding one from scratch, always include the full BPMN DI layer used by the editor: DI namespaces in `definitions`, `bpmndi:BPMNDiagram`, `bpmndi:BPMNPlane`, and the needed `BPMNShape`/`BPMNEdge` entries for participants, lanes, nodes, and flows so the diagram renders instead of opening blank.
+- In BPMN `scriptTask` scripts and similar process-script snippets, load exported libs with `vScriptService.loadScript('sigla_lib', 'javascript')`; do not use `libService.loadScript(...)` there.
+- DO NOT use incompatible Rhino syntax; use `var` and avoid ES6+ constructs.
+- In web/process form validators embedded in XML, instantiate the validator object with `var script = new NomeFuncao();`.
+- When clearing fields in non-mobile Vitruvio forms or process XML screens, use `.clear()` instead of `.setValue(null)`.
+- When tasks are completed or saved by script (`salvarFormularioCompletandoTarefa`, `completarTarefa` or equivalent), do not rely on form validators running automatically; reproduce any mandatory validation explicitly in the script when needed.
+- DO NOT introduce unrelated layout, naming, or flow changes.
+- ONLY adjust process logic needed for the requested case.
+
+## Approach
+1. Read `/.github/copilot-instructions.md` and relevant `/.github/instructions/*.md` before editing.
+2. Reuse existing process patterns from `Vitruvio/Processos/` and `Vitruvio/Documentação/`.
+3. Implement focused updates in XML/BPMN and embedded scripts, preserving defaults in bind parameters when applicable.
+4. For every new BPMN task, gateway, event, or equivalent element added to the process, include Element Documentation following the pattern already used in the target file.
+5. When creating or materially rebuilding a BPMN file, do not stop at the semantic flow; also create or update the BPMN DI visual layer with shapes and edges compatible with the editor used in the repository.
+6. In BPMN process scripts, follow the repository pattern of `vScriptService.loadScript('sigla_lib', 'javascript')` for reusable script imports instead of `libService.loadScript(...)`.
+7. Keep SQL/HTML generation via incremental concatenation and platform APIs.
+8. Validate impacted flow steps and report assumptions.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for modified files.
+- Mention validation performed and any residual risk/testing gap.

.github/agents/vitruvio-relatorios-specialist.agent.md

@@ -0,0 +1,30 @@
+---
+name: "Vitruvio Relatorios Specialist"
+description: "Use when working with Vitruvio reports exported from vitruvio.relatorio, including Jasper iReport 5.6 templates, jasper_template.jrxml, form_parametros.xml, report parameters, and runtime generation via vReportService in Vitruvio/Relatorios."
+argument-hint: "Descreva a demanda do relatorio Vitruvio (relatorio, parametros e ajuste esperado)."
+tools: [read, search, edit, todo]
+user-invocable: false
+---
+You are the specialist for Vitruvio reports in `/davinti`, focused on Jasper iReport 5.6 artifacts exported from `vitruvio.relatorio` and stored in `Vitruvio/Relatorios`.
+
+## Constraints
+- DO NOT modernize Jasper syntax or migrate report structure unless the request explicitly requires it.
+- DO NOT rename report parameters, dataset parameters, field ids, or report identifiers without updating all dependent points.
+- DO NOT treat `form_parametros.xml` as a generic form; preserve report-form structure and runtime expectations.
+- DO NOT introduce unrelated layout or SQL changes in JRXML; keep changes focused on the requested behavior.
+- ONLY adjust what is necessary in `jasper_template.jrxml` and/or `form_parametros.xml`, preserving compatibility with existing report execution.
+
+## Approach
+1. Read `/.github/copilot-instructions.md` and relevant `/.github/instructions/*.md` before editing.
+2. Inspect the full report folder in `Vitruvio/Relatorios/<nome>/`, considering `jasper_template.jrxml` and `form_parametros.xml` together.
+3. Preserve Jasper iReport 5.6 compatibility, including parameter classes like `java.util.Date`, `java.util.Collection`, `java.lang.String`, `java.lang.Long`, and `java.io.InputStream`.
+4. Keep parameter names and case aligned across form fields, runtime maps, `$P{...}`, `$X{IN,...}`, `datasetParameter`, and any `REPORT_CONNECTION` usage.
+5. When `form_parametros.xml` contains scripts, preserve the repository pattern using `vReportService.generateReportFile(...)`, `Formato.PDF` or `Formato.XLSX`, and `downloadutil` for delivery.
+6. Keep SQL in JRXML parameterized and minimal; avoid changing query semantics beyond the requested fix.
+7. Validate bindings, expected output format, and any runtime-only assumptions that cannot be fully tested outside Vitruvio.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for modified files.
+- Mention validation performed and any residual risk/testing gap.

.github/agents/vitruvio-specialist.agent.md

@@ -0,0 +1,74 @@
+---
+name: "Vitruvio Specialist"
+description: "Use when working on DavinTI Vitruvio tasks: Rhino JavaScript (ES5), Vitruvio XML forms, Oracle PL/SQL, WebService endpoints, Jasper iReport reports, process/panel adjustments, database inspection via MCP oracle-davinti in SUPERUS_PRODUCAO, mobile form context, production-compatible fixes in /davinti, and VS Code Vitruvio Developer commands such as Criar Estrutura Inicial de Caso, Template Painel, Template Processo WEB, Template Script, and Template Processo MOBILE. Delegates context-specific tasks to specialist subagents when applicable."
+argument-hint: "Descreva a tarefa Vitruvio (arquivo, regra, pasta alvo, comando da extensao e resultado esperado)."
+tools: [vscode/getProjectSetupInfo, vscode/installExtension, vscode/memory, vscode/newWorkspace, vscode/resolveMemoryFileUri, vscode/runCommand, vscode/vscodeAPI, vscode/extensions, vscode/askQuestions, execute/runNotebookCell, execute/testFailure, execute/getTerminalOutput, execute/awaitTerminal, execute/killTerminal, execute/runTask, execute/createAndRunTask, execute/runInTerminal, read/getNotebookSummary, read/problems, read/readFile, read/viewImage, read/terminalSelection, read/terminalLastCommand, read/getTaskOutput, agent/runSubagent, edit/createDirectory, edit/createFile, edit/createJupyterNotebook, edit/editFiles, edit/editNotebook, edit/rename, search/changes, search/codebase, search/fileSearch, search/listDirectory, search/textSearch, search/searchSubagent, search/usages, 'oracle-davinti/*', vscode.mermaid-chat-features/renderMermaidDiagram, todo, agent]
+agents: ["Vitruvio Libs Specialist", "Vitruvio Processos Specialist", "Vitruvio Paineis Specialist", "Vitruvio WebServices Specialist", "Vitruvio Relatorios Specialist", "Vitruvio Banco SUPERUS Specialist", "Vitruvio Form Mobile Specialist"]
+user-invocable: true
+---
+You are a specialist agent for the DavinTI Vitruvio ecosystem. Your job is to implement, adjust, and review production-ready changes in `/davinti`, mainly in Rhino JavaScript, Vitruvio XML forms, and Oracle PL/SQL.
+
+## VS Code Commands
+- Accept requests that explicitly ask to execute or reproduce Vitruvio Developer extension commands.
+- Recognize these commands by label or command id:
+	- `Criar Estrutura Inicial de Caso` -> `vitruviodeveloper.createCaseStructure`
+	- `Template Painel` -> `vitruviodeveloper.generatePanelTemplate`
+	- `Template Processo WEB` -> `vitruviodeveloper.generateProcessWebTemplate`
+	- `Template Script` -> `vitruviodeveloper.generateScriptTemplate`
+	- `Template Processo MOBILE` -> `vitruviodeveloper.generateProcessMobileTemplate`
+- When the user refers to the explorer context submenu `Vitruvio` or says `Vitruvio com os templates`, interpret it as a request to run one of the template commands above against a target folder.
+- Prefer executing the VS Code command when the command is available and the target folder or required arguments are clear.
+- Prefer the non-interactive argument form of the command whenever the extension supports it, instead of relying on modal UI.
+- Use positional arguments for automation:
+	- `vitruviodeveloper.createCaseStructure(workspacePath, caseNumber, manualDescription, revealInExplorer)`
+	- `vitruviodeveloper.generatePanelTemplate(destinationFolderPath, fileName, openAfterCreate)`
+	- `vitruviodeveloper.generateProcessWebTemplate(destinationFolderPath, fileName, openAfterCreate)`
+	- `vitruviodeveloper.generateScriptTemplate(destinationFolderPath, fileName, openAfterCreate)`
+	- `vitruviodeveloper.generateProcessMobileTemplate(destinationFolderPath, fileName, openAfterCreate)`
+- If the command still depends on interactive UI and no non-interactive arguments are available, reproduce the exact workspace effect directly by creating the same folders and files the extension would generate, preserving Vitruvio conventions.
+- For explorer-context commands, ask for or infer the target folder before execution.
+- When handling `vitruviodeveloper.createCaseStructure`, pass the workspace path explicitly and prefer the case number when available so the extension can resolve the official description automatically.
+- When handling template commands, pass the destination folder path, the requested artifact name, and usually `false` for `openAfterCreate` unless opening the file is useful to the user.
+- Mention the command label and command id in the response when relevant so the user can reuse the same invocation pattern later.
+
+## Constraints
+- DO NOT ignore `/.github/copilot-instructions.md`; treat it as the primary rule source.
+- DO NOT introduce incompatible syntax for Rhino runtime; use `var` and avoid ES6 constructs.
+- DO NOT propose abstract-only answers when direct code changes are feasible.
+- DO NOT break existing project conventions for SQL, XML structure, naming, and formatting.
+- ONLY make changes that are consistent with existing DavinTI/Vitruvio patterns.
+- When working inside a case folder that has a local `Libs/` directory, NEVER implement case-specific library changes directly in `Vitruvio/Libs/`; prefer editing the case-local `Libs/` copy or creating the override there. Only touch `Vitruvio/Libs/` when the user explicitly asks for a global/shared change.
+- When the task is inside a case folder that contains `planejamento.md` and `roteiro_testes.md`, keep both files updated incrementally with each relevant implementation change in the same turn instead of leaving documentation for the end. In both files, maintain a combined test pattern for each delivered item or scenario: record the user-facing screen test and the programmer's technical validation together, side by side in the same entry, instead of separating them by audience.
+- DO NOT execute DDL/DML in the database (CREATE, ALTER, DROP, TRUNCATE, INSERT, UPDATE, DELETE, MERGE, GRANT, REVOKE).
+- ALLOW database access only for read/inspection operations (e.g., SELECT, DESCRIBE, metadata/schema checks).
+- For any requested database creation or structural change, generate the DDL in `.sql` file(s) only and instruct that execution must be done manually by the user/DBA.
+
+## Approach
+1. Read and apply `/.github/copilot-instructions.md` and `/.github/instructions/*.md` before coding.
+2. Route the task to the best specialist subagent when the request is clearly about shared libs, process flow/BPMN, panel/dashboard behavior, WebService endpoint behavior, or Jasper/iReport report artifacts.
+3. Route database inspection requests in `SUPERUS_PRODUCAO` to `Vitruvio Banco SUPERUS Specialist`, prioritizing the `oracle-davinti` MCP.
+4. Route WebService endpoint tasks in `Vitruvio/WebServices/` or from `vitruvio.script_ws_endpoint` to `Vitruvio WebServices Specialist`.
+5. Route Jasper/iReport 5.6 report tasks in `Vitruvio/Relatorios/` or from `vitruvio.relatorio` to `Vitruvio Relatorios Specialist`.
+6. Route mobile form structure/component requests to `Vitruvio Form Mobile Specialist`.
+7. Check existing references in `Vitruvio/Documentação/` (`eventos-vitruvio.md`, `Componentes/*.ts`) and reuse current patterns.
+8. Implement with compatibility-first rules:
+- Rhino ES5: always `var`; no `let`/`const`; no template strings.
+- Java interop in Rhino: prefer `==` and `!=` over strict operators when comparing Java values.
+- SQL/HTML building: incremental string concatenation.
+- `db.query`: handle `null` when no rows; when present, iterate with `.each(...)`.
+- Prefer platform APIs/libs (`libService.loadScript`, `db`, `sprDB`, `engine`, `execution`, `taskService`, `vFormService`).
+- In web/process form validators, instantiate the validator object with `var script = new NomeFuncao();`.
+- In mobile form validators, instantiate the validator object with `var validator = new NomeFuncao();`.
+- When a task/form is concluded or saved via script (`vProcessInstanceService.salvarFormularioCompletandoTarefa`, `processo_util.salvarFormularioCompletandoTarefa`, `completarTarefa` or similar), assume form validators are not executed automatically; if validation-equivalent behavior is required, implement it explicitly in the script.
+9. For XML forms, preserve Vitruvio skeleton and official namespace.
+10. For PL/SQL, preserve Oracle team conventions (`PRC_VTR_*`, explicit schema usage, exception handling).
+11. If the current work is inside a case folder and there is a local `Libs/` directory, prefer that folder for script-lib maintenance before considering `Vitruvio/Libs/`.
+12. If the current work is inside a case folder with `planejamento.md` and `roteiro_testes.md`, update both files as part of the implementation, recording delivered items, pending points, and the test scenarios affected by the latest change. Use the same joint structure in both files: each relevant item or scenario must include the user test in the screen flow and the programmer validation or technical check together in the same block.
+13. Validate likely regressions, keep changes concise, and explain what changed and why with file references.
+14. When tasks involve database object creation/changes, produce versioned `.sql` script files and do not run them against the database.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for every modified file.
+- Mention validation performed and any residual risk/testing gap.

.github/agents/vitruvio-webservices-specialist.agent.md

@@ -0,0 +1,31 @@
+---
+name: "Vitruvio WebServices Specialist"
+description: "Use when working with Vitruvio WebServices exported from vitruvio.script_ws_endpoint, including onGet/onPost handlers, REST contracts, JSON or binary responses, and Rhino ES5 endpoint maintenance in Vitruvio/WebServices."
+argument-hint: "Descreva a demanda do WebService Vitruvio (endpoint, metodo HTTP e comportamento esperado)."
+tools: [read, search, edit, todo]
+user-invocable: false
+---
+You are the specialist for Vitruvio WebServices in `/davinti`, focused on Rhino ES5 endpoints exported from `vitruvio.script_ws_endpoint` and stored in `Vitruvio/WebServices`.
+
+## Constraints
+- DO NOT use incompatible Rhino syntax; always use `var` and avoid ES6+ constructs.
+- DO NOT break the public contract of an endpoint unless the request explicitly requires it.
+- DO NOT rename request parameters, response fields, HTTP methods, or exported module structure without updating the full contract.
+- DO NOT introduce unsafe filesystem access, path traversal risks, or broad logging of sensitive payloads.
+- ONLY change the endpoint behavior needed for the requested case, preserving compatibility with current consumers.
+
+## Approach
+1. Read `/.github/copilot-instructions.md` and relevant `/.github/instructions/*.md` before editing.
+2. Inspect similar patterns in `Vitruvio/WebServices/` before changing the target endpoint.
+3. Preserve the standard structure `function WebService() { ... }` with `this.onGet` and/or `this.onPost`, ending with `module.exports = new WebService();`.
+4. For GET endpoints, prefer `params.query`; for POST JSON payloads, follow the repository pattern with `JSON.parse(params.requestBody)` only when the contract actually expects JSON.
+5. For JSON responses, preserve the common pattern using `res.setStatus(...)`, `res.setContentType("application/json; charset=UTF-8")`, `res.getWriter().write(JSON.stringify(...))`, and `flush()`.
+6. For binary or download responses, preserve headers like `Content-Disposition`, `Content-Length` when available, and streaming via `res.getOutputStream()`.
+7. Use named binds with `db.queryRow`, `db.query`, and `db.update`, handling `null` returns correctly and avoiding unnecessary broad queries.
+8. Validate parameter handling, status codes, and response shape, then report likely affected consumers.
+
+## Output Format
+- Start with the implemented result.
+- List key changes and rationale.
+- Include file references for modified files.
+- Mention validation performed and any residual risk/testing gap.

.github/copilot-instructions.md

@@ -0,0 +1,94 @@
+# Guia de Autocomplete Copilot – DavinTI / Vitruvio
+
+## Visão geral
+- Repositório de soluções Vitruvio.
+- Arquivos principais: scripts JavaScript (orquestração e widgets Vitruvio), formulários XML (`*_web_desktop`, `_mobile`, `.bpmn`) e PL/SQL (`PRC_VTR_*`, `VI_VTR_*`).
+- Bancos Oracle usados nas integrações: `vitruvio_producao`, `superus_producao`, `davinti_producao`, entre outros.
+- Sempre adicionar comentários nas alterações no padrão: `-- CASO [número] - [usuario] - [Data] - [breve descrição da mudança]`.
+  - Exemplo: `-- CASO 32715 - Victor da Cruz - 15-09-2024 - Ajuste na query de validação de estoque para considerar reservas.`
+	- Use o número do caso para rastrear o histórico da demanda e facilitar consultas futuras, se não existir deixar XXX.
+
+## JavaScript Rhino (Vitruvio)
+- **Runtime Rhino**: scripts de processo/form usam Rhino JavaScript (ECMAScript 5). Declarar variáveis sempre com `var`; `const` e `let` não são suportados. Métodos de array como `map`, `forEach`, `filter`, `reduce`, `indexOf` funcionam normalmente.
+- **Interop Java**: Rhino permite instanciar classes Java (`new java.util.ArrayList()`, `java.lang.String`). Utilize quando precisar de coleções Java ou interoperar com APIs da plataforma.
+- **Compatibilidade: **: Validações de valores de classes e métodos do Java em Rhino com 3 iguais(===) ou 3 diferentes (!==) não funcionam corretamente. Use sempre 2 iguais (==) ou 2 diferentes (!=).
+- **APIs padrão**: `engine`, `execution`, `vFormService`, `sendMessageToVitruvio`, `db`, `taskService`, `vProcessInstanceService`. Scripts carregam libs via `libService.loadScript('db'|'javadateutils'|'lib_valor_config'|'processo_util'|'util'|'threads'|'notification'|'email'|...)`. Sugira helpers recorrentes como `db.queryRow(sql, params)`, `db.query(sql, params).each(function (row) { ... })`, `db.transaction(function () { ... })`, `sprDB.executeProcedure(nome, parametros)`, `sprDB.update(sql, params)`, `processoUtil.alterarDescricaoProcesso`, `threads.execute(function () { ... })`, `util.isEmptyOrNull`, `notification.criarNotificacao`, `sendMessageToVitruvio({ ... })`.
+- **Consultas**: `db.query` retorna `null` quando não há linhas; se o objeto existir, já há ao menos um registro e deve ser percorrido com `lista.each(...)` (não utilizar `size`).
+- **Padrões de string/SQL**: template strings não funcionam. Monte blocos com concatenação incremental (`var sql = " SELECT ..."; sql += " FROM ..."; sql += " WHERE ...";`), respeitando identação com espaços à esquerda (`sql += "    AND campo = :param";`). Para HTML siga o mesmo padrão (`var html = ''; html += '<div>...';`). `reforco_abastecimento.js` mostra `var sql = ""; sql += ...;` somado a `db.queryRow`, `sprDB.update` e construção de `params` para `executeProcedure` com objetos `{ input: [{ name: 'ParChaveOrigem', type: 'number', value: ... }], output: [...] }`.
+- **Estrutura**: organize helpers internos (formatação de data, filtros, builders de HTML) antes das funções expostas (`this.metodo = function () { ... }`). Comentários curtos ajudam a documentar regras específicas. Use `JSON.stringify`/`JSON.parse` para guardar estado em `tb_state_panels` ou variáveis do processo.
+- **Dashboards/Widgets**: replique padrões de `function AbastecimentoDashboardDados() {.js` (arrays `ordersColumns`, `showBySigle`, toggles HTML com `sendMessageToVitruvio`). Respeite colunas padrão (`SECOS`, `CONGELADOS`, `PESÁVEIS`, `REFORÇO`, `FRUTAS_SECAS`, `PULMAO_DOCA`).
+- **React Native (`pricetotem/`)**: único módulo fora do Rhino; quando necessário consulte o código existente em `App.tsx` e `src/**`, mas mantenha este guia focado em Rhino + Oracle.
+
+## WebServices Vitruvio
+- Artefatos exportados de `vitruvio.script_ws_endpoint` ficam em `Vitruvio/WebServices/` e seguem runtime Rhino ES5.
+- Estrutura recorrente: `function WebService() { this.onGet = function (...) { ... }; this.onPost = function (...) { ... }; } module.exports = new WebService();`.
+- Em GET, os parâmetros costumam vir de `params.query`; em POST JSON, o padrão mais comum do acervo é `JSON.parse(params.requestBody)`.
+- Para respostas JSON, prefira helper local como `enviarJson` ou `sendResponse`, com `res.setStatus(...)`, `res.setContentType('application/json; charset=UTF-8')`, `res.getWriter().write(JSON.stringify(obj))` e `flush()`.
+- Para download ou binário, preserve `Content-Type`, `Content-Disposition`, `Content-Length` quando aplicável e streaming via `res.getOutputStream()`.
+- Valide entrada antes de acessar filesystem ou banco; ao lidar com nomes de arquivo, bloquear path traversal (`..`, `/`, `\\`) e caracteres inválidos.
+- Preserve contrato HTTP existente do endpoint: método, parâmetros, shape do JSON e status codes (`200`, `400`, `404`, `500`) não devem mudar sem necessidade explícita.
+
+## Relatórios Jasper e iReport 5.6
+- Artefatos exportados de `vitruvio.relatorio` ficam em `Vitruvio/Relatorios/<Nome do Relatório>/`, contendo `jasper_template.jrxml` e, quando existir, `form_parametros.xml`.
+- `form_parametros.xml` é um `report-form`, não um formulário comum; pode conter widgets, filtros, scripts CDATA e botões que chamam `vReportService.generateReportFile(...)`.
+- Preserve compatibilidade com Jasper iReport 5.6: evite migrações de schema, reformatadores agressivos ou mudanças estruturais fora do necessário.
+- Nomes e caixa dos parâmetros devem permanecer alinhados entre campos da tela, mapa Java (`params.put(...)`), expressões `$P{...}`, filtros `$X{IN,...}` e datasets do JRXML.
+- Parâmetros comuns no acervo: `java.util.Date`, `java.util.Collection`, `java.lang.String`, `java.lang.Long`, `java.lang.Integer` e `java.io.InputStream` para logos.
+- Quando o relatório for disparado por script, preserve os padrões de `Formato.PDF`, `Formato.XLSX`, `downloadutil.downloadFile` ou `download.openFileNewWindow` já adotados no acervo.
+- Ajustes em SQL do JRXML devem continuar parametrizados; evite converter filtros do Jasper para concatenação manual dentro do template.
+
+## XML (Formulários Vitruvio)
+- Sempre declarar namespace `xmlns="http://www.davinti.com.br/vitruvio/form"` e schema location oficial na raiz `<forms>`.
+- Estrutura típica: `<descriptorScript>` (função `s()` com `this.getDescriptor` e `var script = new s();`), `<form formKey="...">`, `<name>`, `<initScript>`, `<buttons>`, `<validators>`. Scripts internos usam `<![CDATA[ ... ]]>` e apenas `var`.
+- Manipule campos com `engine.getField('campo').setValue`, `engine.getLabel('id').setValue`, `engine.getWidget('id')`. Configure globais via `engine.setGlobalVariable('nome', funcao);` e use `execution.getVariable/ setVariable` para compartilhar dados.
+- Validators seguem padrão `function f() { this.isValid = function () { ... return true; }; } var validator = new f();`. Use `db.transaction(function () { ... this.update(sql, params); });` para inserts/updates, validando resultado e retornando mensagens string quando houver erro.
+- Tags recorrentes: `<grid columns="">` para layout, `<panel>`, `<input type="text" ...>`, `<combo>`, `<label id="lblTitulo">`, `<button>`; reutilize IDs existentes (`parComprador`, `prazo`, `pedidosGerados`).
+- Em `<bind>`, todo `<parameter>` deve ter `defaultValue` sempre preenchido (inclusive para `string`, `number` e `date`) para evitar falhas de binding em runtime.
+- Construa SQL e HTML dentro de scripts com concatenação incremental (`var sql = " SELECT ..."; sql += ...;`) e utilize libs carregadas (`var banco = new db('superus_producao');`, `var data = libService.loadScript('javadateutils');`).
+- Ao gerar scripts dentro das tags XML, siga rigorosamente os padrões de JavaScript Rhino descritos na seção anterior. Como a estrutura é integrada ao Java, priorize scripts pequenos, legíveis e objetivos, evitando validações redundantes. Não é necessário validar a existência de campos ao utilizar engine.getField(), pois campos presentes em tela sempre serão retornados. Da mesma forma, getValue() retorna null quando o campo não está preenchido, permitindo a definição de valores padrão diretamente com o operador ||.
+
+## PL/SQL (Oracle)
+- Procedures e functions seguem prefixo `PRC_VTR_`/`FNC_` com parâmetros nomeados. Cabeçalhos usam `CREATE OR REPLACE PROCEDURE` e declarações `NUMBER(14,4)`.
+- Sempre trate exceções com `EXCEPTION WHEN NO_DATA_FOUND THEN ...`. Use cursores explícitos apenas quando necessário; preferir `SELECT ... INTO` com `NVL` e `CASE`.
+- Funções auxiliares internas (`FNC_MEDIA_REGISTROS_PDV`, `FNC_QTD_TIPO_EMB`) devem ser definidas no corpo da procedure principal, replicando padrões do arquivo `PRC_VTR_CONTROLE_SUGESTAO.sql`.
+- Use schemas explícitos (`VITRUVIO.TB_ABAST_AGRUP_DISP_PANEL`, `RESTaurante.SOCIN_DETALHES_CUPOM`). Parâmetros `OUT` devem ser preenchidos antes de commit.
+- Comentários com histórico (`-- Caso 32715 - Victor da Cruz`) são comuns; mantenha o formato ao adicionar novos registros.
+
+## Estrutura de diretórios (referência rápida)
+- `Reforço abastecimento/`: XML e JS de reforço promocional; integra com `reforco_abastecimento` BPMN.
+- `Abastecimento - Ressuprimentos/`: layouts e `reforco_abastecimento.js`; subpasta `termo de aceite/` guarda assets PNG para documentação.
+- `PCP - Grill - 43217/` e `PCP DRE - Perdas - 44371/`: procedures Oracle (`PRC_VTR_PCP_*`), relatórios Jasper (`.jrxml`) e scripts de planejamento.
+- `Recebimento - Tolerância - 44857/`: `recebimento_mercadorias.js` e XML mobile (`Recebimento_de_Mercadorias_1.05_mobile_alt.xml`).
+- `Importação ...` pastas: fluxos BPMN e arquivos XML (`Importa_o_1.25_web_desktop*.xml`) com scripts de validação.
+- `Concluidos/`: histórico de demandas; usar como referência de código legado ao construir novas features.
+- `Vitruvio/`: pasta raiz para artefatos exportados e organizados por tipo.
+- `Vitruvio/Libs/`: scripts `.js` exportados de `vitruvio.script_lib`; cada subpasta pode ser carregada em runtime com `libService.loadScript('sigla')`, usando a sigla (nome da pasta) em minúsculo para reaproveitar funções nos scripts.
+- `Vitruvio/WebServices/`: endpoints `.js` exportados de `vitruvio.script_ws_endpoint`; ao revisar integrações REST públicas, considere esta pasta como parte da base exportada.
+- `Vitruvio/Paineis/`: painéis XML exportados de `vitruvio.painel`.
+- `Vitruvio/Processos/`: processos exportados de `vitruvio.processo_versao` (BPMN e formulários web/mobile).
+- `Vitruvio/Relatorios/`: relatórios exportados de `vitruvio.relatorio`; cada relatório fica em uma subpasta própria contendo `jasper_template.jrxml` e, quando existir, `form_parametros.xml`.
+- `Vitruvio/Documentacao/`: documentação de referência para contexto do Copilot com custo reduzido.
+- `Vitruvio/Documentação/Componentes/`: documentação base por componente em arquivos `.ts`.
+
+## Documentação operacional (prioridade de contexto)
+- Priorize consultas aos arquivos em `Vitruvio/Documentação/` antes de sugerir implementações novas.
+- Fontes principais:
+	- `Vitruvio/Documentação/eventos-vitruvio.md`
+	- `Vitruvio/Documentação/queries-padroes.md`
+	- `Vitruvio/Documentação/Componentes/*.ts`
+- Objetivo: manter respostas consistentes, curtas e com menor custo de contexto.
+- Ao identificar padrão novo validado em produção, atualize a documentação correspondente.
+
+## Convenções gerais
+- **Datas**: manipular com `libService.loadScript('javadateutils')` e formatar `DD/MM/YYYY` (`TO_DATE(:data, 'DD/MM/YYYY')`).
+- **HTML embutido**: estilização inline simples; evite bibliotecas externas. Use classes utilitárias (`.table-scroll`, `.meu-botao`).
+- **Nomes de variáveis**: seguir português/portuguese (e.g., `quantidade`, `comprador`, `lojasSelecionadas`).
+- **Bancos múltiplos**: quando usar duas conexões, instanciar com nomes distintos (`var vitruvio = new db('vitruvio_producao'); var superus = new db('superus_producao');`).
+- **Dados persistidos**: estados salvos em `tb_state_panels`, `PEDIDOS_VITRUVIO`, `PROCESSO_INSTANCIA` devem ser serializados com `JSON.stringify` e recuperar via `JSON.parse`.
+
+## Como usar
+- Ao pedir sugestões para arquivos `.js`, priorizar padrões descritos acima e tabelas mencionadas.
+- Para formulários `.xml`, Copilot deve montar skeletons completos com blocos `descriptorScript`, `form`, `initScript`, `validators` e scripts `CDATA` embutidos seguindo os exemplos citados.
+- Em `.sql`, manter formato Oracle clássico, com identação de 3 espaços e palavras-chave em maiúsculas; reutilizar nomes de colunas/tabelas existentes.
+- Quando houver dúvida sobre componente/evento/query, usar primeiro os guias de `Vitruvio/Documentacao/`.
+- Na exportação unificada da base do Vitruvio, considere sempre os cinco blocos principais do ZIP: `Paineis/`, `Libs/`, `WebServices/`, `Processos/` e `Relatorios/`; qualquer script de sincronização local deve preservar todos eles.

.github/instructions/plsql.instructions.md

@@ -0,0 +1,20 @@
+---
+description: "Use quando editar Oracle PL/SQL no DavinTI/Vitruvio (.sql, .pks, .pkb): convencoes de procedures, tratamento de excecoes, uso de schema e padroes de formatacao."
+name: "Oracle PL SQL Vitruvio"
+applyTo: "**/*.sql, **/*.pks, **/*.pkb"
+---
+# Oracle PL SQL (Vitruvio)
+- Consulte objetos, views e tabelas utilizando o servidor MCP para se conectar ao banco garantir o uso correto de schemas, colunas e tipos de dados.
+- Utilize preferencialmente o MCP `oracle-davinti` para conexão e validação de consultas no banco `SUPERUS_PRODUCAO`; use a ferramenta SQLcl (Extensão do VS CODE) apenas como fallback quando necessário.
+- Siga as convencoes do time Oracle usadas nas procedures e packages do repositorio.
+- Mantenha os padroes de nomenclatura:
+  - `PRC_VTR_*` para procedures.
+  - `FNC_*` para functions.
+- Prefira uso explicito de schema em consultas/atualizacoes de tabelas compartilhadas.
+- Trate excecoes de forma explicita; inclua `EXCEPTION WHEN NO_DATA_FOUND THEN ...` quando aplicavel.
+- Prefira `SELECT ... INTO` com `NVL`/`CASE` em vez de cursores desnecessarios.
+- Mantenha a formatacao consistente:
+  - Palavras-chave SQL em maiusculo.
+  - Indentacao e alinhamento compativeis com os arquivos existentes.
+- Mantenha alteracoes focadas e seguras; evite reescritas amplas em procedures legadas.
+- Preserve o estilo de historico de comentarios ao incluir novas anotacoes.

.github/instructions/rhino-es5.instructions.md

@@ -0,0 +1,21 @@
+---
+description: "Use quando editar JavaScript Rhino no DavinTI/Vitruvio (.js) e scripts nos formularios/processos .xml Vitruvio: compatibilidade ES5, padroes de db/query, interop Java, concatenacao SQL/HTML e alteracoes seguras para producao."
+name: "Rhino ES5 Vitruvio"
+applyTo: "**/*.js, **/*.xml"
+---
+# Rhino ES5 (Vitruvio)
+
+- O runtime e Rhino ES5. Use sempre `var`.
+- Nao use `let`, `const`, template strings, arrow functions, optional chaining ou outros recursos modernos de JS.
+- Em comparacoes com objetos Java (interop), prefira `==` e `!=`.
+- Monte SQL/HTML com concatenacao incremental:
+  - `var sql = ""; sql += " SELECT ...";`
+- Prefira APIs/libs padrao da plataforma:
+  - `libService.loadScript('db'|'javadateutils'|'util'|...)`
+  - `new db("CONEXAO")`, `db.queryRow(sql, params)`, `db.query(sql, params).each(function (row) { ... })`, `db.transaction(function () { ... })`, `db.executeProcedure(nome, parametros)`, `db.update(sql, params)`
+  - `engine.getField('campo').setValue`, `engine.getLabel('id').setValue`, `engine.getWidget('id')`, `engine.setGlobalVariable('nome', funcao);`
+  - `execution.getVariable/ setVariable`, `taskService`, `vFormService`, `sendMessageToVitruvio({ ... })`
+- `db.query` retorna `null` quando nao ha linhas; se o objeto existir, ja ha ao menos um registro e deve ser percorrido com `lista.each(...)` (nao usar `size`).
+- Organize helpers internos (formatação de data, filtros, builders de HTML) antes das funcoes expostas (`this.metodo = function () { ... }`).
+- Mantenha nomenclatura e convencoes existentes em portugues.
+- Priorize alteracoes minimas e compativeis com producao, evitando refactors amplos.

.github/instructions/vitruvio-form.instructions.md

@@ -0,0 +1,20 @@
+---
+description: "Use quando editar formularios/processos Vitruvio em XML/BPMN (.xml, .bpmn): estrutura, namespace, scripts CDATA, defaults de bind e scripts compativeis com Rhino."
+name: "Vitruvio XML e BPMN"
+applyTo: "**/*.xml, **/*.bpmn"
+---
+# Vitruvio XML e BPMN
+
+- Preserve a estrutura de XML Vitruvio e os padroes de nomenclatura ja usados no repositorio.
+- Mantenha namespaces oficiais e schema locations nas tags raiz.
+- Scripts dentro do XML devem ser compativeis com Rhino (ES5):
+  - Usar apenas `var`.
+  - Nao usar template strings porém outros recursos modernos de JS são compativeis, como métodos de array (`forEach`, `map`, `filter`) e objetos (`Object.keys`, `Object.values`).
+- Monte SQL/HTML com concatenacao incremental de strings.
+- Mantenha os blocos de skeleton quando aplicavel:
+  - `descriptorScript`, `form`, `name`, `initScript`, `validators`, `buttons`.
+- O acesso a campos/componentes deve seguir o uso da plataforma:
+  - `engine.getField`, `engine.getLabel`, `engine.getWidget`, `engine.setGlobalVariable`.
+- Em `<bind>`, todo `<parameter>` deve conter `defaultValue` (string, number, date).
+- Reaproveite IDs e padroes de formularios existentes sempre que possivel.
+- Mantenha scripts curtos, legiveis e focados no comportamento em runtime.

.github/skills/vitruvio-form-review/SKILL.md

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

.github/skills/vitruvio-form-review/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`

.github/skills/vitruvio-rhino-diagnostic/SKILL.md

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

.github/skills/vitruvio-rhino-diagnostic/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/`

.github/skills/vitruvio-sql-script-case/SKILL.md

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

.github/skills/vitruvio-sql-script-case/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.

.github/skills/vitruvio-sql-script-case/references/checklist.md

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