List view
# MINEX ABRIL 2026 --- # 📑 Resumo de Planejamento: MINEX ABRIL 2026 **Status:** 🔴 NÃO APROVADO (Aguardando revisão final) ## 1. Quadro Geral de Tarefas e Tempos | ID | Tarefa | Foco Principal | Tempo Estimado | | --------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -------------: | | **1** | **Base Híbrida Inicial do Assistente** | Registry, RAG técnico e SFT dos módulos prioritários de Analysis e Mineral Prospecting | **50 horas** | | **2** | **Migração das funcionalidades de Editing a Project para Lit Refactor** | Refactor dos fluxos de edição, inspeção, geometria e transformação | **50 horas** | | **3** | **Remodelagem Lit da casca do app e componentes transversais** | Navbar, tabsets, Open Project, modais, helper panel, about e shell global | **30 horas** | | **4** | **Testes em nuvem** | gerar produção do pacote e rodar testes | **10 horas** | | **TOTAL** | | | **140 horas** | --- ## Tarefa 1 — Estruturar a base híbrida do auxiliar Minex 2D ### Objetivo geral Construir a base de conhecimento do assistente do Minex 2D usando uma arquitetura híbrida em que: * o **registry leve** faz o mapeamento entre a linguagem do usuário, as funcionalidades do app e os ativos técnicos; * o **RAG técnico** fornece o subsídio dinâmico e factual; * o **fine-tuning / SFT leve** ensina o assistente a conversar, diagnosticar e rotear corretamente. O objetivo do assistente é conseguir responder perguntas como: * “o que esse botão faz?” * “onde vejo o resultado?” * “isso é erro do app, do pod ou do backend?” * “o processo travou em que etapa?” * “qual função ou log devo consultar?” * “que erro de preenchimento eu cometi?” * “qual é o próximo passo seguro para o usuário?” As diretrizes a serem seguidas serão as passadas no mês anterior. Em Report de manutenção março 26. --- ### 1. Princípio da arquitetura Cada funcionalidade coberta deve ser representada por **4 blocos obrigatórios de conhecimento** e **1 bloco de ligação**: 1. **APP CARD** 2. **POD/PRE CARD** 3. **LOG SET** 4. **BACKEND CARD** 5. **LINK CARD / METADATA** Sem esses blocos, a funcionalidade **não está pronta** para entrar na base do assistente. #### Papel de cada camada ##### A. Registry leve Camada pequena, manual ou semiautomática, com foco em **semântica do produto**. Serve para ligar: * nome visível da funcionalidade; * aliases usados por usuários; * tela, componente e botão; * forma de uso; * validações e erros comuns de preenchimento; * pipeline / entrypoint associado; * funções técnicas mais prováveis; * fontes candidatas para busca no RAG. ##### B. RAG técnico Camada grande, factual e atualizável. Aqui entram: * código-fonte; * documentação de funções; * README; * changelog; * testes; * logs de sucesso; * logs de erro; * registros de execução; * artefatos e evidências operacionais; * relatórios derivados úteis ao diagnóstico. ##### C. Fine-tuning / SFT leve Camada pequena, curada, voltada a **comportamento**. Serve para ensinar o assistente a: * interpretar a fala do usuário; * mapear a dúvida para a funcionalidade correta; * diferenciar APP / PRE / BACKEND / DB / INFRA; * decidir quando consultar logs; * decidir quando consultar código; * explicar achados técnicos em linguagem amigável; * não culpar a interface sem evidência; * sugerir o próximo passo correto. --- ### 2. Escopo funcional desta etapa Para respeitar o teto de horas do projeto, esta tarefa **não cobre todo o app**. Ela ficará restrita a **8 módulos prioritários**, organizados por família funcional. #### 2.1 Analysis 1. **Correlation** Inclui o subfluxo de **Two-Variable Correlation / Quick View** como parte do mesmo pacote funcional. 2. **Important Features** 3. **Linear Directional Mean** 4. **Optimal Grid Size** 5. **Factor Analysis of Mixed Data (FAMD)** #### 2.2 Mineral Prospecting 6. **Train Random Forest** 7. **Train Neural Network / Deep Learning** 8. **Apply Model** 9. **train XG Boost** --- ### 3. Módulos explicitamente fora desta onda Para manter o total do projeto em até 140h, ficam **fora da Tarefa 1** nesta versão: * **Train Stacked Ensemble** Esses dois fluxos podem entrar em uma etapa futura de expansão da base híbrida, aproveitando a mesma arquitetura e os mesmos templates já consolidados. --- ### 4. Saídas esperadas Estrutura mínima: 1. `registry/app/` 2. `registry/pre/` 3. `registry/links/` 4. `rag/code/` 5. `rag/logs/` 6. `rag/fingerprints/` 7. `rag/manifest/` 8. `sft/` 9. `evaluation/` Arquivos centrais: * `registry_flows.jsonl` * `rag_manifest.jsonl` * `log_fingerprints.jsonl` * `sft_assistant_train.jsonl` * `evaluation_cases.jsonl` --- ### 5. O que deve ser coletado por módulo Cada módulo coberto deve ser decomposto nestes blocos: * **APP**: o que o usuário vê e usa; * **POD/PRE**: o que o app dispara e o que executa o fluxo; * **LOGS**: o que já aconteceu em execuções reais; * **BACKEND**: funções e métodos usados no fluxo; * **DB mínimo**: só o suficiente para ligar request, status e artefatos. #### 5.1 APP Cobrar por módulo: * `feature_id` * `feature_name` * `aliases` * `user_goal` * `ui_screen` * `ui_module` * `ui_component` * `ui_trigger` * `usage_steps` * `required_inputs` * `optional_inputs` * `expected_ui_feedback` * `expected_user_outputs` * `validation_errors` * `user_mistakes_common` * `auxiliary_processes` * `pre_checks` * `post_actions` * `ui_dependencies` * `app_doc_refs` * `app_test_refs` #### 5.2 POD / PRE Cobrar por módulo: * `job_entrypoint` * `job_package` * `job_trigger_source` * `job_runtime_type` * `pipeline_steps` * `pipeline_functions_owned` * `calls_backend_functions` * `calls_db_functions` * `artifacts_expected` * `runtime_context` * `container_image` * `resource_profile` * `pre_doc_refs` * `pre_test_refs` * `pre_artifact_refs` * `e2e_refs` #### 5.3 LOGS Por módulo, entregar no mínimo: * 1 log de sucesso; * 1 log de erro ou warning; * 1 fingerprint útil. Ideal operacional: * 2 a 4 sucessos representativos; * 2 a 4 erros representativos; * 1 a 2 warnings úteis. #### 5.4 BACKEND Por módulo, entregar: * lista de funções principais; * 3 a 8 function cards relevantes; * code chunks por etapa crítica; * docs ligadas à funcionalidade. #### 5.5 LINK CARD Cada módulo deve permitir navegar assim: `APP feature` → `ui_trigger` → `job_entrypoint` → `pipeline_steps` → `backend_functions` → `logs` → `status/artifacts` --- ### 6. Critérios de aceite Cada módulo deve ter, no mínimo: * 1 APP CARD; * 1 POD/PRE CARD; * 1 LINK CARD; * 3 a 8 function cards do backend; * 1 log de sucesso; * 1 log de erro ou warning; * 1 fingerprint útil; * tags padronizadas; * referências para documentação e testes. Não aceito como “feito”: * só README solto; * só print de tela; * só nome de botão; * só lista de funções; * só log cru; * só código sem metadado; * só documentação sem vínculo com funcionalidade. --- ### 7. Estimativa de esforço #### 7.1 Premissa de cálculo Esta tarefa **não está sendo estimada como 8 microfluxos independentes do zero**. A estimativa já assume: * reaproveitamento de schema; * templates de cards reutilizáveis; * padronização de tags; * estrutura de fingerprints; * agrupamento de subfluxos similares; * forte similaridade entre os treinamentos de modelos. #### 7.2 Quebra recomendada | Bloco | Horas | | ------------------------------------------ | ----: | | Setup, taxonomia e templates base | 6h | | Analysis — 5 módulos prioritários | 20h | | Mineral Prospecting — RF, NN e Apply Model | 12h | | Revisão, linkagem final e validação mínima | 2h | **Total:** **40 horas úteis** --- ## Tarefa 3 — Migração das funcionalidades de Editing a Project para Lit Refactor ### Objetivo geral Migrar as funcionalidades do menu **Edit** para uma arquitetura baseada em **Web Components (Lit)**, removendo dependências de manipulação imperativa do DOM, reduzindo acoplamento com Shiny e criando componentes isolados, rastreáveis, testáveis e reutilizáveis. Esta tarefa é a frente de refactor dedicada ao conjunto de funcionalidades de **Editing a project**. --- ### 1. Escopo funcional de Edit Com base na documentação do app, esta frente cobre: #### 1.1 Ingestão e manutenção 1. **Add New Files** 2. **Change Base Area** 3. **Add Target Variables** 4. **Remove Files** 5. **Rename Files** 6. **Add Layers** 7. **Rename Lithologies** #### 1.2 Derivação, inspeção e transformação 8. **Target Creator** 9. **Object Info** 10. **Graph** 11. **Merge Files** 12. **Resize Grid** 13. **Add Formula** 14. **Voronoi** 15. **Create Target from Processed Layers** 16. **Filter Layer** --- ### 2. Diretriz arquitetural Cada unidade migrada deve ter: * `component_tag` * `@property` * `@state` * `events_emitted` * `events_received` * `validation_rules` * `server_contract` * `payload_schema` * `test_refs` #### Regras obrigatórias **Proibido** * `classList.toggle` * `querySelector` para orquestrar estado central * dependência de seletor global para esconder / mostrar painéis * validação espalhada entre DOM e servidor sem contrato explícito **Obrigatório** * state-driven rendering; * template condicional do Lit; * contratos de evento com `CustomEvent`; * Shadow DOM; * encapsulamento de estilo; * composição por subcomponentes. --- ### 3. Agrupamento por complexidade #### 3.1 Componentes complexos * `mx-target-creator` * `mx-object-info-panel` * `mx-graph-panel` * `mx-add-layers-panel` Características: * múltiplos submodos; * dependência de camada ativa; * sincronização com sidebar + mapa; * modal / confirmação / loading / status; * payloads mais ricos. #### 3.2 Componentes intermediários * `mx-add-formula-panel` * `mx-voronoi-panel` * `mx-create-target-panel` * `mx-filter-layer-panel` * `mx-resize-grid-panel` * `mx-change-base-area-panel` * `mx-add-target-variable-panel` #### 3.3 Componentes padronizados * `mx-add-files-panel` * `mx-remove-files-panel` * `mx-rename-files-panel` * `mx-merge-files-panel` * `mx-rename-lithologies-panel` --- ### 4. Critérios de teste #### 4.1 Testes unitários Lit Cada componente deve ter, no mínimo: * renderização inicial; * property-to-attribute; * comportamento de estados locais; * bloqueio de submit quando inválido; * dispatch do evento correto; * exibição de loading / success / error; * acessibilidade básica via teclado. #### 4.2 Testes de integração Fluxos mínimos: * Add New Files envia payload correto; * Change Base Area valida contenção; * Add Target Variables exige nome e buffer; * Remove Files exige confirmação; * Resize Grid diferencia overwrite e bilinear; * Add Formula constrói expressão corretamente; * Add Layers adiciona seleção múltipla; * Rename Lithologies atualiza níveis; * Target Creator cria geometria e abre modal de persistência; * Graph e Object Info reagem à troca de layer. #### 4.3 Metas de qualidade * **Cobertura Lit/logic ≥ 80%** * **Zero erros de console** * **Contratos de payload documentados** * **Sem dependência crítica de manipulação direta do DOM** * **UI navegável por teclado nos fluxos principais** --- ### 5. Entregáveis Para cada componente ou grupo: * `src/components/<component>/` * `src/components/<component>/__tests__/` * `registry/app/<feature_id>.app.json` * `registry/tests/<feature_id>.tests.json` * `README.md` técnico com API do componente * evidências em `production/frontend/` Artefatos esperados: * `coverage/index.html` * `coverage/coverage-frontend.xml` * `metrics/test_times.csv` * `frontend/cmd_output.txt` * snapshots / workflows quando aplicável --- ### 6. Estimativa de esforço A estimativa abaixo já considera agrupamento por família de componente, reaproveitamento de contratos e uso de infraestrutura comum da casca Lit. | Bloco | Horas | | ----------------------------------------------------- | ----: | | Componentes padronizados | 18h | | Componentes intermediários | 20h | | Componentes complexos | 14h | | Infra comum, contratos, documentação e testes globais | 8h | **Total:** **60 horas úteis** --- ## Tarefa 4 — Remodelagem Lit da casca do app e componentes transversais ### Objetivo geral Executar a remodelagem Lit das partes transversais do aplicativo que organizam navegação, contexto, orientação de uso e interação global, incluindo: * **helper panel** * **correlations** * **open project** * **navbar** * **tabsets** * **about** * **modais** * **shell / remodelagem Lit da casca do app** O objetivo aqui não é apenas transformar telas em componentes, mas criar uma **camada estrutural Lit** que estabilize navegação, comunicação entre áreas, gerenciamento de estado de alto nível e padronização visual. --- ### 1. Escopo funcional #### 1.1 Shell estrutural 1. **App Shell Lit** 2. **Navbar** 3. **Tabsets principais** 4. **Gerência de sidebar / panel host** 5. **Router ou state host de abas** 6. **Modal manager global** #### 1.2 Componentes transversais de negócio 7. **Open Project** 8. **Correlations** 9. **Advanced Analytics Help Panel** 10. **About** #### 1.3 Elementos transversais de UX 11. **Modais de confirmação** 12. **Modais de loading / erro / sucesso** 13. **Componentes compartilhados de cards, alertas, placeholders e estados vazios** --- ### 2. Arquitetura proposta #### 2.1 Shell / layout Criar um componente raiz, por exemplo: * `mx-app-shell` Responsabilidades: * controlar aba ativa; * controlar painel lateral ativo; * registrar modais globais; * distribuir eventos de alto nível; * integrar navbar, tabsets, workspace e resultados; * reduzir acoplamento entre widgets isolados. #### 2.2 Navbar Criar algo como: * `mx-main-navbar` Campos importantes: * aba ativa; * atalhos globais; * suporte / email; * logout; * estado de projeto carregado; * estados de loading globais. #### 2.3 Tabsets Criar uma base comum, por exemplo: * `mx-tabset` * `mx-tab` * `mx-tab-panel` Exigências: * controle por estado; * acessibilidade via teclado; * slots ou composição declarativa; * sincronização com resultados e sidebar; * sem manipulação imperativa do DOM. #### 2.4 Modal manager Criar um host global, por exemplo: * `mx-modal-host` Ele deve gerenciar: * confirmações destrutivas; * feedbacks de submit; * formulários rápidos; * visualização contextual; * empilhamento / prioridade de modais. --- ### 3. Componentes específicos #### 3.1 Open Project Fluxo com: * carregamento do projeto; * exibição de metadados; * box de layers; * warning panel; * seleção múltipla; * renderização de layer no mapa; * reprocessamento de falhas. #### 3.2 Correlations Fluxo com: * seleção de variáveis; * parâmetros estatísticos; * modos de cálculo; * visualização rápida de duas variáveis; * integração com Results. #### 3.3 Advanced Analytics Help Panel Painel autônomo com: * busca contextual; * seção por funcionalidade; * parâmetros explicados; * vínculo com aba ativa; * possibilidade futura de integração com assistente. #### 3.4 About Componente padronizado para: * documentação; * FAQ; * links de suporte; * exemplos; * seções colapsáveis quando necessário. --- ### 4. Critérios de aceite #### 4.1 Técnicos * estado global explícito; * eventos de alto nível documentados; * modal manager funcionando; * navegação por abas sem hacks de DOM; * navbar e tabsets desacoplados da implementação Shiny imperativa; * compatibilidade com widgets migrados nas demais tarefas. #### 4.2 UX * feedback claro de aba ativa; * carregamento previsível; * warning panel do Open Project bem integrado; * modais consistentes; * helper panel reutilizável; * layout mais estável e menos frágil. #### 4.3 Testes * testes unitários de shell; * testes unitários de navbar / tabsets / modais; * testes de integração do fluxo Open Project; * testes da correlação e quick view; * testes do helper panel; * testes de troca de aba e abertura / fechamento de modal. --- ### 5. Entregáveis * `src/components/shell/` * `src/components/navbar/` * `src/components/tabset/` * `src/components/modals/` * `src/components/open-project/` * `src/components/correlation/` * `src/components/help-panel/` * `src/components/about/` * `src/shared/` * `__tests__/` * `README.md` técnico por grupo * evidências de cobertura e integração em `production/frontend/` --- ### 6. Estimativa de esforço | Bloco | Horas | | -------------------------------------------------- | ----: | | App shell + estado global + event contracts | 5h | | Navbar + tabsets | 5h | | Modal manager + modais compartilhados | 5h | | warning panel + modais | 2h | | Correlations | 5h | | Help Panel + About + documentação e ajustes finais | 4h | **Total:** **26 horas úteis** --- ## 3. Detalhamento executivo ### Tarefa 1: Base Híbrida Inicial do Assistente * **Objetivo:** montar a base híbrida inicial do assistente com foco nos módulos prioritários de Analysis e Mineral Prospecting. * **Escopo final desta etapa:** Correlation (com Quick View), Important Features, Linear Directional Mean, Optimal Grid Size, FAMD, Train RF,Train XGBoost, Train NN e Apply Model. * **Fora desta etapa:** Train Stacked Ensemble e demais fora de analise. * **Valor técnico:** já entrega uma base utilizável para suporte orientado a uso, troubleshooting e localização de resultados nos fluxos mais relevantes. ### Tarefa 2: Lit Refactor do menu Edit * **Objetivo:** migrar o conjunto de funcionalidades de edição do projeto para componentes Lit. * **Escopo:** ingestão, manutenção, inspeção, geometria e transformação no menu Edit. * **Valor técnico:** reduz fragilidade de DOM, melhora manutenção e cria base testável de front-end. ### Tarefa 3: Lit Refactor da casca do app * **Objetivo:** estabilizar a infraestrutura visual e de navegação do app em Lit. * **Escopo:** helper panel, correlations, open project, navbar, tabsets, about, modais e shell estrutural. * **Valor técnico:** cria a camada comum necessária para sustentar os refactors dos widgets e painéis. --- ## 4. Resumo de esforço final (Abril 2026) * **Esforço técnico acumulado:** **140 horas úteis** * **Capacidade necessária:** aproximadamente **3 semanas e meia** de desenvolvimento focado, considerando dedicação próxima de 40h semanais * **Observação de planejamento:** o teto de 140h foi respeitado por meio de contenção de escopo na Tarefa 1 * **Dependência natural:** as Tarefas 3 e 4 compartilham infraestrutura de Lit, testes e contratos de evento ### Ordem sugerida de execução 1. **Tarefa 4** 2. **Tarefa 3** 3. **Tarefa 1**
Overdue by 4 day(s)•Due by April 30, 2026# MINEX MARÇO 2026 ## Tarefa 1 — Refatoração do widget de schedule, atualização do about e testes Lit dos novos widgets ### Objetivo geral Substituir a entrega anteriormente prevista para esta tarefa pelos itens alinhados no e-mail, mantendo a mesma carga total de **40 horas**. A tarefa passa a contemplar exclusivamente: * o **refatoramento do widget de schedule** — **20 horas** * a **atualização completa do about** — **10 horas** * a **entrega de testes Lit para todos os novos widgets**, em formato auditável e executável na estrutura — **10 horas** --- ### 1. Escopo da tarefa #### Título **Refatoração do widget de schedule, atualização completa do about e testes Lit auditáveis para os novos widgets** #### Escopo funcional Executar apenas as entregas abaixo, substituindo o conteúdo anterior desta tarefa: 1. **Refatoramento do widget de schedule** 2. **Atualização completa do about** 3. **Testes Lit para todos os novos widgets** O total da tarefa permanece em **40 horas**. --- ### 2. Refatoramento do widget de schedule #### Objetivo Reestruturar o widget de **schedule** para adequá-lo ao padrão atual da aplicação, com foco em manutenção, consistência de comportamento e preparação adequada para testes. #### Escopo funcional * revisar a estrutura do componente * reorganizar o fluxo de interação * alinhar o comportamento com o padrão adotado nos widgets novos * corrigir inconsistências de implementação * preparar o componente para cobertura automatizada #### Saídas esperadas * componente refatorado * fluxo visual revisado * estrutura ajustada para manutenção * contrato de propriedades/eventos revisto, quando aplicável * vínculo com os testes correspondentes #### Estimativa **20 horas** --- ### 3. Atualização completa do about #### Objetivo Atualizar integralmente a área **about**, contemplando conteúdo, organização e consistência visual. #### Escopo funcional * revisar todo o conteúdo exibido * reorganizar os blocos informativos * corrigir textos e estrutura * alinhar a apresentação visual ao padrão atual da aplicação * deixar a área preparada para manutenção futura #### Saídas esperadas * conteúdo revisado * aba/componente atualizado * organização visual ajustada * evidência de funcionamento na estrutura #### Estimativa **10 horas** --- ### 4. Testes Lit para todos os novos widgets #### Objetivo Entregar testes Lit para todos os novos widgets, em formato auditável, executados dentro da estrutura do projeto. #### Escopo funcional * criar testes unitários dos componentes Lit * validar renderização, estados e interações principais * organizar os testes de forma compatível com o pipeline atual * gerar evidências claras de execução * manter vínculo entre widget, teste e artefato gerado #### Casos mínimos esperados ##### A. Renderização * componente renderiza corretamente * estados iniciais são válidos * propriedades mínimas são respeitadas ##### B. Interação * ações do usuário disparam o comportamento esperado * bloqueios e validações aparecem quando necessário * transições de estado ficam reproduzíveis ##### C. Auditoria * testes ficam organizados na estrutura * execução produz evidência verificável * existe vínculo claro entre widget, teste e resultado #### Saídas esperadas * suíte de testes Lit dos novos widgets * evidências de execução na estrutura * organização auditável dos arquivos de teste * referência entre widget e teste correspondente #### Estimativa **10 horas** --- ### 5. Entregáveis da tarefa 1 * `src/components/schedule/` * `src/components/about/` * `src/components/__tests__/` * `production/frontend/` * artefatos auditáveis dos testes Lit --- ### 6. Resumo de esforço da tarefa 1 | Subitem | Descrição | Tempo | | --------- | -------------------------------------- | ------------ | | 1 | Refatoração do widget de schedule | 20 horas | | 2 | Atualização completa do about | 10 horas | | 3 | Testes Lit para todos os novos widgets | 10 horas | | **TOTAL** | | **40 horas** | --- ## Tarefa 2 — Add Layers: reutilizar arquivo já existente, apagar e sobrescrever ### Objetivo geral Evoluir o fluxo de **Add Layers** para que a aba não dependa exclusivamente de um novo upload local. Hoje, o pipeline de criação de layers exige que o usuário envie novamente um arquivo, mesmo quando ele já existe no projeto/blob storage. A tarefa deve permitir: * usar **arquivos já existentes** no projeto para criar novos layers, sem refazer upload * permitir **apagar** arquivos/layers existentes * permitir **sobrescrever** arquivos existentes com novo conteúdo ou nova versão * manter rastreabilidade entre: * funcionalidade do app * arquivo selecionado * pipeline disparado * artefatos/resultado * status da operação --- ### 1. Resultado esperado da funcionalidade Ao final desta tarefa, a funcionalidade **Add Layers** deve suportar estes três modos de operação: #### Modo A — Novo upload Fluxo atual, mantido: * usuário seleciona arquivo local * app envia arquivo * pipeline processa * layer é criado #### Modo B — Reusar arquivo já existente Novo fluxo: * usuário abre Add Layers * visualiza ou pesquisa arquivos já existentes no projeto/blob storage * seleciona um arquivo existente * informa parâmetros da nova camada * pipeline usa a referência do arquivo já salvo, sem novo upload * layer é criado a partir do arquivo existente #### Modo C — Gerenciar arquivo existente Novo fluxo: * usuário pode apagar um arquivo/layer permitido * usuário pode sobrescrever um arquivo existente * o sistema deve controlar: * permissões/regras de sobrescrita * integridade de vínculos * atualização de status e referências --- ### 2. Escopo funcional #### 2.1 Problema atual Hoje, Add Layers exige sempre um novo arquivo, o que gera: * retrabalho para o usuário * duplicação de arquivos no blob * custo operacional desnecessário * inconsistência entre arquivo original e novo layer derivado * dificuldade para reaproveitar dados já existentes no projeto #### 2.2 Objetivo da mudança Permitir que o fluxo de Add Layers opere por **referência** além de operar por **upload**. Ou seja, o sistema deve aceitar dois modos de entrada: * **upload_mode = "new_upload"** * **upload_mode = "existing_blob_reference"** E, adicionalmente, dois modos de gestão do arquivo: * **file_action = "delete"** * **file_action = "overwrite"** --- ### 3. Arquitetura funcional da tarefa A funcionalidade deve ser tratada em 5 blocos obrigatórios: 1. **APP CARD** 2. **POD/PRE CARD** 3. **LOG SET** 4. **BACKEND CARD** 5. **LINK CARD** DB segue como camada mínima de rastreabilidade. --- ### 4. APP — o que precisa mudar Aqui o foco é o que o usuário vê e faz. #### 4.1 Novos comportamentos de UI A aba **Add Layers** deve passar a suportar: ##### A. Seleção do modo de entrada O usuário deve poder escolher entre: * `Upload novo arquivo` * `Usar arquivo já existente no projeto` ##### B. Navegação/seleção de arquivos existentes Ao escolher reutilizar arquivo existente, a UI deve permitir: * listar arquivos do projeto * pesquisar por nome * filtrar por tipo/extensão * visualizar data ou versão * selecionar um item * ver se o arquivo é elegível para Add Layers ##### C. Ações de gestão A UI também deve permitir, quando aplicável: * apagar arquivo * sobrescrever arquivo * confirmar operação destrutiva * exibir feedback de sucesso/erro ##### D. Processos auxiliares do app Devem ser explicitados porque fazem parte da funcionalidade: * carregamento da lista de arquivos existentes * validação de compatibilidade do arquivo selecionado * confirmação de delete/overwrite * polling do status do processamento * refresh da lista de layers * refresh da lista de arquivos do projeto --- #### 4.2 APP CARD — exemplo detalhado ```json id="tadd01" { "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "feature_name": "Add Layers com reutilização de arquivo existente", "aliases": [ "add layers", "adicionar layer", "usar arquivo já enviado", "reusar arquivo do projeto" ], "user_goal": "Criar uma nova layer a partir de um arquivo já existente no projeto, sem novo upload.", "ui_screen": "Add Layers", "ui_module": "layers_module", "ui_component": "AddLayersPanel", "ui_trigger": "Botão Add Layer / Confirmar inserção", "ui_modes": [ "new_upload", "existing_blob_reference" ], "usage_steps": [ "Abrir a aba Add Layers", "Escolher o modo 'Usar arquivo já existente'", "Pesquisar ou selecionar um arquivo do projeto", "Definir os parâmetros da nova layer", "Confirmar a criação" ], "required_inputs": [ "project_id", "file_reference_id", "layer_name" ], "optional_inputs": [ "style", "group", "overwrite_policy" ], "expected_ui_feedback": [ "loading_file_list", "validating_file", "processing", "completed", "failed" ], "expected_user_outputs": [ "nova layer criada", "mensagem de erro de compatibilidade", "mensagem de sucesso", "lista de layers atualizada" ], "validation_errors": [ { "field": "file_reference_id", "condition": "não selecionado", "ui_message": "Selecione um arquivo já existente no projeto." }, { "field": "file_reference_id", "condition": "tipo incompatível", "ui_message": "O arquivo selecionado não é compatível com esta operação." }, { "field": "layer_name", "condition": "vazio", "ui_message": "Informe o nome da nova layer." } ], "user_mistakes_common": [ "Selecionar arquivo incompatível com Add Layers", "Tentar sobrescrever arquivo bloqueado", "Confundir criar layer a partir de arquivo com substituir o arquivo original" ], "auxiliary_processes": [ "carregar lista de arquivos do projeto", "validar elegibilidade do arquivo", "confirmar ação destrutiva", "atualizar lista de layers", "atualizar lista de arquivos" ], "tags": [ "feature:minex2d_add_layers_reuse_file", "layer:app_ui", "ui:add_layers", "component:add_layers_panel", "trigger:add_layer_confirm", "mode:existing_blob_reference", "action:create_layer_from_existing", "validation:required_field", "feedback:ui_success", "feedback:ui_error" ] } ``` --- #### 4.3 Subfluxos adicionais no APP ##### A. Delete ```json id="tadd02" { "feature_id": "MINEX2D_FILE_DELETE", "feature_name": "Excluir arquivo/layer existente", "ui_screen": "Add Layers / Project Files", "ui_trigger": "Botão Excluir", "required_inputs": ["project_id", "file_reference_id"], "expected_ui_feedback": [ "confirm_delete", "deleting", "deleted", "delete_failed" ], "tags": [ "feature:minex2d_file_delete", "layer:app_ui", "action:delete_file", "ui:add_layers" ] } ``` ##### B. Overwrite ```json id="tadd03" { "feature_id": "MINEX2D_FILE_OVERWRITE", "feature_name": "Sobrescrever arquivo existente", "ui_screen": "Add Layers / Project Files", "ui_trigger": "Botão Sobrescrever", "required_inputs": ["project_id", "file_reference_id", "replacement_file"], "expected_ui_feedback": [ "confirm_overwrite", "uploading_replacement", "processing_overwrite", "overwrite_done", "overwrite_failed" ], "tags": [ "feature:minex2d_file_overwrite", "layer:app_ui", "action:overwrite_file", "ui:add_layers" ] } ``` --- ### 5. POD / PRE — o que precisa mudar no pipeline Aqui o foco é o que o app dispara e o que roda no job. Hoje, pela tua descrição, o fluxo presume **input binário novo**. Agora o pipeline precisa aceitar também **referência a arquivo já existente no blob storage**. #### 5.1 Novos modos operacionais no PRE O pipeline deve suportar explicitamente: * `input_mode = "new_upload"` * `input_mode = "blob_reference"` E para gestão: * `operation = "create_layer"` * `operation = "delete_file"` * `operation = "overwrite_file"` --- #### 5.2 O que extrair / exigir do PRE ##### A. Entrypoints Deve ficar claro qual entrypoint trata: * criação de layer por upload * criação de layer por referência * delete * overwrite Pode ser: * um entrypoint único com parâmetros * ou múltiplos entrypoints Mas isso precisa ficar documentado. ##### B. Etapas mínimas do pipeline de reuso Para o modo `existing_blob_reference`, o pipeline precisa contemplar algo como: 1. carregar request 2. validar referência do arquivo 3. resolver path/blob metadata 4. validar compatibilidade do arquivo 5. processar/criar layer 6. persistir layer/resultados 7. atualizar status final ##### C. Delete Fluxo mínimo: 1. carregar request 2. validar permissões/regras 3. validar dependências 4. deletar ou marcar exclusão 5. atualizar status 6. atualizar referências ##### D. Overwrite Fluxo mínimo: 1. carregar request 2. validar permissões/regras 3. receber novo arquivo ou nova referência 4. substituir conteúdo 5. revalidar metadados/compatibilidade 6. atualizar artefatos/referências 7. atualizar status --- #### 5.3 PRE CARD — exemplo detalhado ```json id="tpre01" { "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "job_entrypoint": "add_layers_pipeline", "job_package": "geotrix2dpre", "job_trigger_source": "APP_UI", "job_runtime_type": "kubernetes_job", "supported_modes": [ "new_upload", "blob_reference" ], "supported_operations": [ "create_layer", "delete_file", "overwrite_file" ], "pipeline_steps": [ { "step": "load_request", "functions": ["get_request"], "output": "request carregado" }, { "step": "resolve_input_source", "functions": ["resolve_blob_reference"], "output": "arquivo existente resolvido" }, { "step": "validate_file_compatibility", "functions": ["validate_layer_source"], "output": "compatibilidade confirmada" }, { "step": "create_layer", "functions": ["add_layer_from_source"], "output": "layer criada" }, { "step": "persist_results", "functions": ["save_layer_metadata"], "output": "metadados persistidos" }, { "step": "update_status", "functions": ["update_status"], "output": "status final atualizado" } ], "pipeline_functions_owned": [ "add_layers_pipeline", "resolve_blob_reference", "dispatch_layer_operation" ], "calls_backend_functions": [ "validate_layer_source", "add_layer_from_source", "save_layer_metadata", "update_status" ], "artifacts_expected": [ "layer_record", "layer_preview", "request_status" ], "tags": [ "feature:minex2d_add_layers_reuse_file", "layer:pre_orchestration", "package:geotrix2dpre", "entrypoint:add_layers_pipeline", "runtime:kubernetes_job", "mode:blob_reference", "operation:create_layer", "stage:resolve_input_source", "stage:validate_file", "stage:create_layer", "stage:status_update" ] } ``` --- ### 6. LOGS — o que precisa existir Essa funcionalidade também precisa ter base de logs para o RAG e para diagnóstico. Como falamos antes, eu seguiria a regra prática de: * **mínimo**: 1 sucesso + 1 erro por subfluxo * **ideal**: 5 a 10 logs representativos por funcionalidade principal Como aqui há 3 subfluxos, eu cobraria pelo menos: ###6.1 Conjunto mínimo de logs ####Reuso de arquivo existente * 1 log de sucesso * 1 log de erro de validação * 1 log de erro de processamento ####Delete * 1 log de sucesso * 1 log de erro por dependência/bloqueio ####Overwrite * 1 log de sucesso * 1 log de erro de conflito/incompatibilidade Total mínimo recomendável: **7 a 9 logs úteis** --- #### 6.2 Exemplo detalhado — log de sucesso ```json id="tlog01" { "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "run_id": "RUN_ADD_LAYER_EXISTING_001", "log_type": "success", "duration_seconds": 18.220, "events": [ { "where": "resolve_blob_reference", "message": "Existing project file resolved successfully" }, { "where": "validate_layer_source", "message": "Layer source validated successfully" }, { "where": "add_layer_from_source", "message": "Layer created from existing file" }, { "where": "update_status", "message": "Layer status updated in database" } ], "final_message": "Layer created successfully from existing blob reference", "tags": [ "feature:minex2d_add_layers_reuse_file", "source:log", "status:success", "layer:pre_orchestration", "mode:blob_reference", "operation:create_layer", "function:resolve_blob_reference", "function:add_layer_from_source", "function:update_status" ] } ``` --- #### 6.3 Exemplo detalhado — log de erro ```json id="tlog02" { "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "run_id": "RUN_ADD_LAYER_EXISTING_002", "log_type": "error", "duration_seconds": 4.481, "events": [ { "where": "resolve_blob_reference", "message": "Existing project file resolved successfully" }, { "where": "validate_layer_source", "message": "Validating compatibility of selected file" } ], "error_summary": { "where": "validate_layer_source", "exception_type": "ValidationError", "message": "Selected file type is not compatible with Add Layers" }, "likely_layer": "BACKEND_CORE", "assistant_hint": "Responder que a seleção foi aceita pela UI, mas o arquivo falhou na validação técnica de compatibilidade.", "tags": [ "feature:minex2d_add_layers_reuse_file", "source:log", "status:error", "layer:backend_core", "mode:blob_reference", "operation:create_layer", "error:invalid_layer_source", "severity:error" ] } ``` --- #### 6.4 Exemplos de fingerprints ```json id="tfp001" { "fingerprint_id": "ADD_LAYER_INVALID_SOURCE_TYPE", "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "pattern_type": "error", "match_terms": [ "validate_layer_source", "file type is not compatible", "existing blob reference" ], "likely_layer": "BACKEND_CORE", "technical_reason": "Arquivo existente não atende aos requisitos de tipo/estrutura para criação da layer.", "assistant_hint": "Orientar o usuário a selecionar um arquivo elegível ou revisar o tipo de layer esperado." } ``` ```json id="tfp002" { "fingerprint_id": "DELETE_BLOCKED_BY_DEPENDENCY", "feature_id": "MINEX2D_FILE_DELETE", "pattern_type": "error", "match_terms": [ "delete_file", "dependency exists", "file is still referenced" ], "likely_layer": "BACKEND_CORE", "technical_reason": "O arquivo ainda possui vínculos ativos com layers, relatórios ou processos.", "assistant_hint": "Informar que o arquivo não pode ser apagado enquanto houver dependências ativas." } ``` --- ### 7. BACKEND — o que precisa mudar Aqui está o núcleo técnico da tarefa. O backend precisa suportar semanticamente: * resolução de arquivo existente por referência * validação de elegibilidade/compatibilidade * criação de layer a partir de arquivo já salvo * delete * overwrite * atualização de metadados e status --- #### 7.1 O que extrair do backend #### A. Funções críticas ##### Reuso de arquivo existente * `resolve_blob_reference` * `validate_layer_source` * `add_layer_from_source` * `save_layer_metadata` * `update_status` ##### Delete * `delete_file_reference` * `check_file_dependencies` * `update_status` ##### Overwrite * `overwrite_file_blob` * `revalidate_file_metadata` * `refresh_layer_links` * `update_status` #### B. Card por função Cada função crítica deve ter: * nome * propósito * inputs * outputs * side effects * quem chama * logs relacionados * documentação relacionada --- #### 7.2 Function card — exemplo detalhado ```json id="tbk001" { "doc_id": "FUNC_add_layer_from_source_geotrix", "source_type": "code", "package": "geotrix", "layer": "BACKEND_CORE", "function_name": "add_layer_from_source", "file_path": "R/add_layer_from_source.R", "language": "R", "purpose": "Criar uma nova layer a partir de um arquivo já existente no blob/project storage.", "inputs": [ "project_id", "file_reference_id", "layer_name", "layer_params" ], "outputs": [ "layer_record", "layer_preview" ], "called_by": [ "add_layers_pipeline" ], "side_effects": [ "gera novo registro de layer", "pode gerar preview", "persiste metadados" ], "related_features": [ "MINEX2D_ADD_LAYERS_REUSE_FILE" ], "tags": [ "feature:minex2d_add_layers_reuse_file", "layer:backend_core", "package:geotrix", "function:add_layer_from_source", "role:layer_creation", "mode:blob_reference" ] } ``` --- #### 7.3 Code chunk — exemplo detalhado ```json id="tbk002" { "doc_id": "CODE_add_layers_pipeline_chunk_01", "source_type": "code", "chunk_type": "code_body", "package": "geotrix2dpre", "layer": "PRE_ORCHESTRATION", "feature_ids": ["MINEX2D_ADD_LAYERS_REUSE_FILE"], "file_path": "R/add_layers_pipeline.R", "function_name": "add_layers_pipeline", "chunk_index": 1, "start_line": 1, "end_line": 28, "tags": [ "feature:minex2d_add_layers_reuse_file", "layer:pre_orchestration", "stage:resolve_input_source", "stage:validate_file", "function:resolve_blob_reference", "function:validate_layer_source" ], "summary": "Trecho responsável por resolver a referência do arquivo existente e validar compatibilidade antes da criação da layer." } ``` --- ### 8. DB — mínimo obrigatório Como antes, banco não é o foco principal do RAG, mas precisa existir como elo mínimo. #### 8.1 O que cobrar * `request_entity_name` * `status_field` * `artifact_ref_field` * `file_reference_field` * `where_status_is_updated` ##### Exemplo ```json id="tdb001" { "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "db_min_link": { "request_entity_name": "table_requests", "status_field": "status", "artifact_ref_field": "layer_path", "file_reference_field": "file_reference_id", "where_status_is_updated": "update_status" } } ``` --- ### 9. Como linkar tudo Cada subfluxo precisa ser navegável assim: `APP feature` → `ui_mode` → `ui_trigger` → `job_entrypoint` → `pipeline_steps` → `backend_functions` → `logs` → `status/artifacts` --- #### 9.1 LINK CARD — exemplo detalhado ```json id="tlink1" { "feature_id": "MINEX2D_ADD_LAYERS_REUSE_FILE", "feature_name": "Add Layers com reutilização de arquivo existente", "ui_trigger": "Botão Add Layer / Confirmar inserção", "job_entrypoint": "add_layers_pipeline", "backend_functions": [ "resolve_blob_reference", "validate_layer_source", "add_layer_from_source", "save_layer_metadata", "update_status" ], "request_entity_name": "table_requests", "artifacts_expected": [ "layer_record", "layer_preview", "request_status" ], "main_log_refs": [ "rag/logs/MINEX2D_ADD_LAYERS_REUSE_FILE.success.jsonl", "rag/logs/MINEX2D_ADD_LAYERS_REUSE_FILE.error.jsonl" ], "main_test_refs": [ "tests/testthat/test-add-layers.R::existing_blob_reference", "tests/e2e/test-add-layers-pod.R::existing_blob_reference", "tests/lit/add-layers-existing-file.test.ts" ], "tags": [ "feature:minex2d_add_layers_reuse_file", "link:ui_to_pre", "link:pre_to_backend", "link:backend_to_logs", "link:request_to_artifacts" ] } ``` --- ### 10. Testes automatizados exigidos * **backend** com `covr ≥ 90%`, `rcmdcheck`, `cmd_output.txt`, `production/run_all.R`, `manifest-checksums.json` e evidências em `production/...` * **pods / E2E** com `diff_report.html`, `diff_summary.json`, comparativos com IDs fixos e cobertura do harness quando aplicável * **app** com `shinytest2`, mapa funcionalidade → testes, tempos por teste e integração UI + server --- #### 10.1 Backend — testes obrigatórios ##### Casos mínimos ##### Reuso de arquivo existente * aceita `file_reference_id` válido * rejeita `file_reference_id` inexistente * rejeita tipo incompatível * cria layer corretamente a partir da referência * atualiza status final ##### Delete * deleta arquivo elegível * bloqueia exclusão quando houver dependência * atualiza status corretamente ##### Overwrite * sobrescreve arquivo elegível * bloqueia overwrite incompatível * mantém/atualiza referência esperada * atualiza status corretamente ##### Artefatos obrigatórios * `coverage-backend.xml` * `covr/index.html` * `rcmdcheck/last.txt` * `metrics/test_times.csv` se existir perfil de tempo * integração no `production/run_all.R` ##### Meta * **covr backend ≥ 90%** * **rcmdcheck = 0 ERRORS, 0 WARNINGS** --- #### 10.2 Pod / E2E — testes obrigatórios ##### Casos mínimos E2E ##### Caso E2E 1 — criar layer a partir de arquivo existente * cria request * resolve blob reference * processa pipeline * gera layer * atualiza status * produz artefato esperado ##### Caso E2E 2 — tentativa com arquivo incompatível * request criado * validação falha * pipeline encerra com erro controlado * status final coerente * `diff_summary.json` registra divergência esperada ##### Caso E2E 3 — delete bem-sucedido * request criado * arquivo removido ou marcado como removido * status atualizado * lista final reflete exclusão ##### Caso E2E 4 — delete bloqueado por dependência * pipeline identifica dependência * não remove * retorna erro controlado ##### Caso E2E 5 — overwrite bem-sucedido * request criado * novo conteúdo substitui o anterior * metadados/referências atualizados * status final correto ##### Artefatos obrigatórios * `pods/cmd_output.txt` * `diff_report.html` ou `.md` * `diff_summary.json` * `manifest-checksums.json` * `coverage-pods.xml` se o harness for em R * evidências em `production/...` ##### Meta * **100% dos cenários previstos executados no E2E** * **todos os comparativos críticos pass/fail discriminados em `pods/cmd_output.txt`** --- #### 10.3 App / Lit — testes obrigatórios ##### A. Testes Lit/unitários do componente Se a UI estiver em componentes Lit: * troca de modo `new_upload` ↔ `existing_blob_reference` * render da lista de arquivos * busca/filtro de arquivos * habilitação/desabilitação do botão de confirmação * mensagens de validação * modal de confirmação para delete/overwrite * estados visuais de loading / success / error ##### B. Testes de integração app Mesmo com Lit, eu cobraria integração com o app: * fluxo de criar layer a partir de arquivo existente * fluxo de erro de validação * fluxo de delete * fluxo de overwrite * atualização da tela após operação Se o stack atual continuar com `shinytest2` para a aplicação, a exigência pode ser: * **Lit unit tests** para os componentes * **shinytest2 / integração UI-server** para o fluxo completo Isso segue o padrão já definido para app: testes de UI + server, snapshots/workflows, mapa funcionalidade → testes e cobertura. ####Casos mínimos Lit * `existing-file mode renders correctly` * `confirm button disabled when no file selected` * `validation error shown for incompatible file` * `delete confirmation required` * `overwrite confirmation required` --- ### 11. Critérios de aceite #### 11.1 Critérios funcionais A tarefa será aceita quando: ##### Reuso de arquivo existente * o usuário conseguir criar uma nova layer a partir de um arquivo já existente no projeto/blob storage * sem novo upload local * com atualização correta da lista de layers * com request/status rastreáveis ##### Delete * o usuário conseguir excluir arquivo elegível * com bloqueio quando houver dependências * com feedback claro ##### Overwrite * o usuário conseguir sobrescrever arquivo elegível * com validação de compatibilidade * com atualização correta das referências/artefatos --- #### 11.2 Critérios estruturais Deve existir: * 1 APP CARD por subfluxo principal * 1 PRE CARD consolidado ou por subfluxo * logs normalizados * fingerprints * function cards do backend * LINK CARD * documentação atualizada no README/Tests/production --- #### 11.3 Critérios de aceite com testes automatizados ####Backend * testes unitários/integrados cobrindo os 3 subfluxos * **covr backend ≥ 90%** * `rcmdcheck` sem erros e warnings #### Pod / E2E * todos os cenários críticos executados * `pods/cmd_output.txt` com discriminação pass/fail * `diff_summary.json` e `diff_report.html` gerados * `manifest-checksums.json` válido * 100% dos cenários previstos executados no ambiente de pod/harness #### App / Lit * testes unitários dos componentes Lit cobrindo modos, validações e confirmações * testes de integração cobrindo os fluxos principais * funcionalidade incluída no mapa funcionalidade → testes, como já é exigido para o app --- #### 11.4 Critérios de qualidade O sistema não será aceito se: * continuar exigindo upload em cenários que deveriam aceitar referência * delete apagar arquivo com dependência ativa sem bloqueio * overwrite quebrar vínculos ou perder rastreabilidade * app não diferenciar erro de validação de erro de processamento * logs não permitirem identificar em que etapa a operação falhou --- ### 12. Entregáveis por camada #### APP * `registry/app/MINEX2D_ADD_LAYERS_REUSE_FILE.app.json` * `registry/app/MINEX2D_FILE_DELETE.app.json` * `registry/app/MINEX2D_FILE_OVERWRITE.app.json` #### PRE/POD * `registry/pre/MINEX2D_ADD_LAYERS.pre.json` #### BACKEND * `rag/code/MINEX2D_ADD_LAYERS.function_cards.jsonl` * `rag/code/MINEX2D_ADD_LAYERS.code_chunks.jsonl` #### LOGS * `rag/logs/MINEX2D_ADD_LAYERS.success.jsonl` * `rag/logs/MINEX2D_ADD_LAYERS.error.jsonl` * `rag/fingerprints/MINEX2D_ADD_LAYERS.fingerprints.jsonl` #### LINKS * `registry/links/MINEX2D_ADD_LAYERS.links.json` #### TESTES / ARTEFATOS * `production/VERSAO_DO_PACOTE/covr/index.html` * `production/VERSAO_DO_PACOTE/covr/coverage-backend.xml` * `production/VERSAO_DO_PACOTE/rcmdcheck/last.txt` * `production/VERSAO_DO_PACOTE/pods/cmd_output.txt` * `production/VERSAO_DO_PACOTE/diff_summary.json` * `production/VERSAO_DO_PACOTE/diff_report.html` * `production/VERSAO_DO_PACOTE/manifest-checksums.json` * testes Lit/unitários e integração referenciados no README/Tests --- ### 13. Estimativa de esforço Vou separar por blocos. #### 13.1 Setup inicial Inclui: * taxonomia dos subfluxos * ajustes de schema * desenho de contratos * definição dos testes * atualização de README/Tests **Estimativa:** 6 a 10 horas --- #### 13.2 Implementação por camada ####A. APP / Lit * novos modos na UI * listagem/seleção de arquivos existentes * ações delete/overwrite * validações e confirmações * integração com app **Estimativa:** 8 a 14 horas ##### B. PRE / POD * aceitar blob reference * suportar create/delete/overwrite * ajustar pipeline * atualizar status/artefatos **Estimativa:** 8 a 14 horas ##### C. BACKEND * funções de resolução/validação/criação/delete/overwrite * metadados e rastreabilidade * documentação **Estimativa:** 8 a 14 horas ##### D. LOGS / fingerprints / linkagem * normalização * fingerprints * cards e links **Estimativa:** 3 a 6 horas ##### E. Testes automatizados ##### Backend **4 a 8 horas** ##### Pod / E2E **4 a 8 horas** ##### App / Lit **4 a 8 horas** --- #### 13.3 Total estimado ##### Cenário enxuto * setup: 5 h * implementação: 27 h * testes: 3 h **Total: ~35 horas** ##### Cenário base realista * setup: 6 h * implementação: 36 h * testes: 5 h **Total: ~47 horas** --- ###Estimativa oficial recomendada Para cobrança e planejamento, eu registraria: **Tarefa 2 — Add Layers: 40 horas úteis** Esta é uma migração crítica porque move o Minex 2D de uma manipulação de DOM imperativa (Shiny) para uma arquitetura baseada em componentes reativos (Lit). Para manter o padrão de "cobrança técnica" das tarefas anteriores, precisamos detalhar os **Contratos de Eventos**, a **Gestão de Estado** e os **Artefatos de Teste**. Abaixo, a reestruturação da tarefa com foco em **Registry**, **Lit Components** e **Qualidade de Front-end**. --- ##Tarefa 3 — Migração de Widgets de Análise: Lit Refactor ###Objetivo geral Migrar os widgets de análise de Shiny R para **Web Components (Lit)**, eliminando o acoplamento com o DOM global e garantindo que cada widget seja uma unidade autônoma, testável e documentada. O foco é a transição de manipulação de classes (`classList`) para **State-Driven Rendering**. --- ##1. Widgets Padrão (Análises Estatísticas) *Widgets: Correlation, FAMD, Important Features.* ### 1.1 APP CARD — Especificação do Componente Cada widget deve ser catalogado com os seguintes metadados para o **Registry**: * **component_tag**: Ex: `mx-analysis-correlation` * **properties**: Definição de `@property` (inputs que vêm do servidor/parent). * **events_emitted**: Eventos Customizados (ex: `analysis-submit`). * **events_received**: Como o componente reage a dados externos (ex: `results-ready`). * **internal_state**: Variáveis `@state` que controlam a UI localmente. ### 1.2 Padrão Lit & Shadow DOM * **Encapsulamento**: Estilos 100% contidos no `css` estático do Lit. * **Validação Nativa**: O componente deve validar internamente se `min < max` ou se tipos estão corretos antes de permitir o disparo do evento de execução. * **Comunicação**: Substituir `Shiny.setInputValue` por disparos de `CustomEvent` com `{ bubbles: true, composed: true }`. --- ## 2. Widget Complexo (Mineral Prospecting) ### 2.1 Arquitetura Modular (Parent + Children) Diferente dos widgets padrão, o **Mineral Prospecting** deve seguir o padrão **Container/Presenter**: 1. **Parent (`mx-prospecting-main`)**: Gere o estado global da análise e o payload final. 2. **Children (`mx-model-rf`, `mx-model-xgboost`, etc.)**: Componentes burros que apenas renderizam os parâmetros específicos de cada modelo. ### 2.2 Reatividade vs Imperatividade * **Proibido**: Uso de `this.shadowRoot.querySelector('.panel').classList.toggle('hidden')`. * **Obrigatório**: Uso de condicionais no template Lit: `${this.activeModel === 'RF' ? html`<mx-model-rf></mx-model-rf>` : ''}`. --- ## 3. Critérios de Aceite e Testes Automatizados A entrega de cada widget só será aceita com os seguintes artefatos de teste: ### 3.1 Testes Unitários (Vitest + Web Test Runner) * **Render Check**: O componente renderiza todos os inputs baseados nas propriedades iniciais? * **Property-to-Attribute**: Alterar uma propriedade reflete no atributo do DOM e vice-versa? * **Event Dispatch**: Ao clicar no botão "Executar", o evento customizado é disparado com o payload correto? * **Validation**: Inputs inválidos bloqueiam o disparo do evento e exibem erro visual? ### 3.2 Testes de Integração (E2E Lite) * **Fluxo de Estado**: (Para o Mineral Prospecting) Selecionar "Random Forest" limpa os parâmetros do modelo anterior? * **Payload Integrity**: O objeto JSON gerado pelo widget é idêntico ao esperado pelo backend `geotrix2dpre`? #### Metas de Qualidade: * **Cobertura Lit/Logic ≥ 80%** (comprovada por `coverage/index.html`). * **Zero erros de console** (Hydration ou Runtime). * **Acessibilidade**: Controles básicos via teclado (Tab/Enter). --- ## 4. Documentação e Registry Para cada widget, deve ser entregue um **README.md** técnico contendo: 1. **API do Widget**: Tabela de Atributos, Propriedades e Eventos. 2. **Exemplo de Instanciação**: Snippet HTML de como declarar o componente. 3. **Mapa de Registro**: * `feature_id`: Identificador único no Minex 2D. * `ui_component`: Nome da tag Lit. * `validation_rules`: Lista de travas implementadas no front. --- ## 5. Estimativa de Tempo Revisitada | Atividade | Widgets Padrão (x5) | Widget Complexo (x1) | | -------------------------------------- | ------------------- | -------------------- | | **Refatoração Lit (CSS/HTML/Logic)** | 5h | 12h | | **Implementação de Testes (Unit/Int)** | 1h | 2h | | **Documentação & Registry Card** | 2h | 2h | | **Total por Unidade** | **8 horas** | **16 horas** | | **TOTAL DO PROJETO** | **24 horas** | **16 horas** | **Total Geral Estimado: 40 horas úteis** --- ## 6. Entregáveis por Widget Para cada funcionalidade de análise, o pacote de entrega deve conter: * `src/components/<widget_name>/` (Código Lit e CSS). * `src/components/<widget_name>/__tests__/` (Suíte Vitest). * `registry/app/<feature_id>.app.json` (Vínculo com o assistente). * `production/frontend/coverage-<widget_name>.html` (Evidência de cobertura). Aqui está a consolidação do cronograma e o resumo executivo das atividades para o projeto **MINEX MARÇO 2026**. --- Perfeito. Atualizei a tabela incluindo a nova linha de **Testes em Produção e Melhorias**, o que eleva o cronograma total para **130 horas**. --- ## 📑 Resumo de Planejamento: MINEX MARÇO 2026 **Status:** 🔴 NÃO APROVADO (Aguardando revisão final) ### 1. Quadro Geral de Tarefas e Tempos (Atualizado) | ID | Tarefa | Foco Principal | Tempo Estimado | | --------- | ----------------------------------- | ------------------------------------------------------------ | -------------- | | **1** | **Schedule + About + Testes Lit** | Refatoração do schedule, atualização do about e testes Lit auditáveis | 40 horas | | **2** | **Add Layers: Reuso e Gestão** | Refatoração de Fluxo (Referência vs Upload) | 40 horas | | **3** | **Migração Widgets (Lit Refactor)** | UI/UX, Shadow DOM e Testes de Front-end | 40 horas | | **4** | **Testes em Produção e Melhorias** | Homologação final, ajuste de performance e bugs | 10 horas | | **TOTAL** | | | **130 horas** | --- ### 2. Detalhamento por Tarefa #### Tarefa 1: Schedule + About + Testes Lit * **Objetivo:** Executar a substituição acordada para esta tarefa, mantendo o mesmo total de 40 horas. * **Componentes:** * **Refatoração do widget de schedule** — 20 horas * **Atualização completa do about** — 10 horas * **Testes Lit para todos os novos widgets** — 10 horas * **Entregáveis Críticos:** componentes atualizados, suíte de testes Lit em formato auditável e evidências de execução na estrutura. --- #### Tarefa 2: Add Layers (Evolução de Fluxo) * **Objetivo:** Eliminar a necessidade de uploads repetidos e permitir gestão de arquivos. * **Novos Modos:** `new_upload`, `blob_reference`, `delete` e `overwrite`. * **Qualidade:** Exigência de 90% de cobertura no backend e testes de integridade de vínculos (não apagar arquivos com dependências). --- #### Tarefa 3: Migração de Widgets (Lit Refactor) * **Objetivo:** Modernizar 6 widgets (5 padrão + 1 complexo) para Web Components. * **Widgets:** Correlation, LDM, Optimal Grid, FAMD, Important Features + Mineral Prospecting. * **Tecnologia:** LitElement, Shadow DOM e Vitest. * **Meta:** Fim do uso de `classList` e manipulação direta do DOM global. --- #### Tarefa 4 (ID 4) : Homologação Final Esta etapa de **10 horas** será dedicada exclusivamente ao ambiente de produção para garantir que a migração tecnológica não cause regressões: * **Homologação Final:** Testes de fumaça (*smoke tests*) em ambiente real de produção. * **Ajustes de Performance:** Otimização do carregamento dos componentes Lit e tempo de resposta do RAG. * **Polimento de UI/UX:** Pequenas melhorias visuais baseadas no feedback de uso real após o refactor. * **Correção de Edge Cases:** Resolução de bugs específicos de concorrência ou permissões de blob storage detectados no "mundo real". --- ### 3. Resumo de Esforço Final (Março 2026) * **Esforço Técnico Acumulado:** 130 horas úteis. * **Capacidade Necessária:** Aproximadamente **3 semanas e meia** de desenvolvimento focado (considerando 40h semanais). * **Entrega Estimada:** Final de Março/2026.
Overdue by 1 month(s)•Due by March 31, 2026# Plano de Ação — Minex **2D** - FEVEREIRO/26 (Data Ingestion & Sync) **Período:** Fevereiro/2026 **Foco:** (1) Ingestão de Dados • (2) Sincronização 2D/3D • (3) Novo Widget de Importação • (4) Estabilização **Refs:** `geotrix3d#006` · `minex_qa#012` · `arch_migration#002` **Apps e Pacotes no escopo:** - **Frontend:** `geotrixMap` (Lit Web Components). - **Backend:** `geotrix2dpre` (R/C++). ------ ## 1) Redesign do Widget: Create Project & Add Files **Objetivo:** Modernizar a porta de entrada do app com foco em performance de memória. - **Atividades Frontend (40h):** * Implementação de Web Components (Lit) e leitor de CSV via JS (streaming/chunks) para evitar vazamentos. - Alertas de volumetria (rasters excessivos) e testes unitários JS. - **Atividades Backend (10h):** * Suporte a **GeoTIFF**, revisão do pipeline de targets e trancas para `basearea` sem projeção. - **Estimativa:** **50h** ## 2) Legendas e Visualizadores Sincronizados **Objetivo:** Unificar a experiência visual entre o mapa 2D e o perfil 3D. - **Atividades:** * Centralização de paletas de cores, filtros de atributos e lógica de visibilidade (toggle) compartilhada entre 2D/3D. - Testes de reatividade em JS para garantir que o mapa atualize ao mudar a legenda. - **Estimativa:** **40h** ## 3) Novo Widget de Importação (Inpainting & Mineral) **Objetivo:** Substituir o sistema de importação legado por um fluxo assistido em duas etapas, eliminando erros críticos de dimensão e storage. - **Justificativa:** Trata-se de um componente crítico redesenhado do zero em **Lit**. O fluxo assistido guiará o usuário, prevenindo inputs inválidos que geravam falhas de backend. - **Atividades:** - **Desenvolvimento Lit:** Criação do widget em Web Components com interface dividida em duas etapas (Configuração -> Validação). - **Auxílio Visual:** Interface com tooltips e guias para preenchimento de parâmetros de inpainting. - **Testes Automatizados:** Suite completa de testes unitários e E2E para o componente usando as ferramentas do ecossistema Lit/Open-WC. - **Fix de Backend:** Correção do erro `dim(X) must have a positive length` e tratamento do erro 404 em Storage Services. - **Estimativa:** **30h** ## 4) Bugs, Melhorias e UX **Objetivo:** Refinamento de fórmulas e estabilidade de geometria. - **Atividades:** - **Recategorização (20h):** Suporte a troca/ajuste de *levels* categóricos no widget de fórmulas. - **Humanização de Erros (5h):** Tradução de erros de sistema para mensagens claras (ex: "Nome do modelo ausente"). - **Bug de Geometria (5h):** Correção do processamento de polígonos grandes na `basearea`. - **Estimativa:** **30h** ## 5) Documentação **Objetivo:** Rodar testes e entrega. - **Atividades:** - **Changelog e demais:** Atualizar e versionar documentações; - **Testes:** Rodar testes de pacotes. - **Coverage:** Rodar coverage de pacotes e manter padrão > 85% de cobertura. - **Estimativa:** **10h** ------ ## Resumo e Milestones (Fevereiro/26) | **Atividade** | **Frontend** | **Backend** | **Total** | | ----------------------------------- | ------------ | ----------- | --------- | | **1. Widget Create/Add Files** | 40 h | 10 h | **50 h** | | **2. Legendas & Sync 2D/3D** | 20 h | 10 h | **30 h** | | **3. Novo Widget Importação (Lit)** | 15 h | 5 h | **20 h** | | **4. Estabilização e UX** | 10 h | 20 h | **30 h** | | **5. Documentação ** | | | **10 h** | | **TOTAL ESTIMADO** | | | **140 h** | ------ ## Critérios de Aceite (Definition of Done) 1. **Novo Widget de Importação:** - [ ] O widget funciona em duas etapas claras e impede o avanço sem os campos obrigatórios. - [ ] O erro `dim(X)` não ocorre mais durante o processo de inpainting mineral. - [ ] **Testes Lit:** Mínimo de 80% de cobertura nos componentes do novo widget. 2. **Ingestão e Performance:** - [ ] Arquivos GeoTIFF são importados com sucesso. - [ ] CSVs de alta volumetria não causam pico de memória (Heap JS estável). 3. **Sincronização Visual:** - [ ] Ao filtrar um valor na legenda, os pontos somem instantaneamente tanto no 2D quanto no 3D. 4. **UX e Robustez:** - [ ] O usuário consegue renomear ou agrupar categorias (levels) no fluxo de fórmulas. - [ ] Mensagens de erro técnicas são interceptadas e exibidas em linguagem amigável. - [ ] Polígonos complexos de `basearea` são processados sem erro de backend.
Overdue by 2 month(s)•Due by February 28, 2026# Plano de Ação — Minex **2D** - FEVEREIRO/26 (Data Ingestion & Sync) **Período:** Fevereiro/2026 **Foco:** (1) Ingestão de Dados • (2) Sincronização 2D/3D • (3) Novo Widget de Importação • (4) Estabilização **Refs:** `geotrix3d#006` · `minex_qa#012` · `arch_migration#002` **Apps e Pacotes no escopo:** - **Frontend:** `geotrixMap` (Lit Web Components). - **Backend:** `geotrix2dpre` (R/C++). ------ ## 1) Redesign do Widget: Create Project & Add Files **Objetivo:** Modernizar a porta de entrada do app com foco em performance de memória. - **Atividades Frontend (40h):** * Implementação de Web Components (Lit) e leitor de CSV via JS (streaming/chunks) para evitar vazamentos. - Alertas de volumetria (rasters excessivos) e testes unitários JS. - **Atividades Backend (10h):** * Suporte a **GeoTIFF**, revisão do pipeline de targets e trancas para `basearea` sem projeção. - **Estimativa:** **50h** ## 2) Legendas e Visualizadores Sincronizados **Objetivo:** Unificar a experiência visual entre o mapa 2D e o perfil 3D. - **Atividades:** * Centralização de paletas de cores, filtros de atributos e lógica de visibilidade (toggle) compartilhada entre 2D/3D. - Testes de reatividade em JS para garantir que o mapa atualize ao mudar a legenda. - **Estimativa:** **40h** ## 3) Novo Widget de Importação (Inpainting & Mineral) **Objetivo:** Substituir o sistema de importação legado por um fluxo assistido em duas etapas, eliminando erros críticos de dimensão e storage. - **Justificativa:** Trata-se de um componente crítico redesenhado do zero em **Lit**. O fluxo assistido guiará o usuário, prevenindo inputs inválidos que geravam falhas de backend. - **Atividades:** - **Desenvolvimento Lit:** Criação do widget em Web Components com interface dividida em duas etapas (Configuração -> Validação). - **Auxílio Visual:** Interface com tooltips e guias para preenchimento de parâmetros de inpainting. - **Testes Automatizados:** Suite completa de testes unitários e E2E para o componente usando as ferramentas do ecossistema Lit/Open-WC. - **Fix de Backend:** Correção do erro `dim(X) must have a positive length` e tratamento do erro 404 em Storage Services. - **Estimativa:** **30h** ## 4) Bugs, Melhorias e UX **Objetivo:** Refinamento de fórmulas e estabilidade de geometria. - **Atividades:** - **Recategorização (20h):** Suporte a troca/ajuste de *levels* categóricos no widget de fórmulas. - **Humanização de Erros (5h):** Tradução de erros de sistema para mensagens claras (ex: "Nome do modelo ausente"). - **Bug de Geometria (5h):** Correção do processamento de polígonos grandes na `basearea`. - **Estimativa:** **30h** ## 5) Documentação **Objetivo:** Rodar testes e entrega. - **Atividades:** - **Changelog e demais:** Atualizar e versionar documentações; - **Testes:** Rodar testes de pacotes. - **Coverage:** Rodar coverage de pacotes e manter padrão > 85% de cobertura. - **Estimativa:** **10h** ------ ## Resumo e Milestones (Fevereiro/26) | **Atividade** | **Frontend** | **Backend** | **Total** | | ----------------------------------- | ------------ | ----------- | --------- | | **1. Widget Create/Add Files** | 40 h | 10 h | **50 h** | | **2. Legendas & Sync 2D/3D** | 20 h | 10 h | **30 h** | | **3. Novo Widget Importação (Lit)** | 15 h | 5 h | **20 h** | | **4. Estabilização e UX** | 10 h | 20 h | **30 h** | | **5. Documentação ** | | | **10 h** | | **TOTAL ESTIMADO** | | | **140 h** | ------ ## Critérios de Aceite (Definition of Done) 1. **Novo Widget de Importação:** - [ ] O widget funciona em duas etapas claras e impede o avanço sem os campos obrigatórios. - [ ] O erro `dim(X)` não ocorre mais durante o processo de inpainting mineral. - [ ] **Testes Lit:** Mínimo de 80% de cobertura nos componentes do novo widget. 2. **Ingestão e Performance:** - [ ] Arquivos GeoTIFF são importados com sucesso. - [ ] CSVs de alta volumetria não causam pico de memória (Heap JS estável). 3. **Sincronização Visual:** - [ ] Ao filtrar um valor na legenda, os pontos somem instantaneamente tanto no 2D quanto no 3D. 4. **UX e Robustez:** - [ ] O usuário consegue renomear ou agrupar categorias (levels) no fluxo de fórmulas. - [ ] Mensagens de erro técnicas são interceptadas e exibidas em linguagem amigável. - [ ] Polígonos complexos de `basearea` são processados sem erro de backend.
Overdue by 2 month(s)•Due by February 28, 2026**Período:** Janeiro/2026 **Foco:** (1) Otimização Primitives • (2) Targets de Treino • (3) Slicing Dinâmico • (4) QA & Relatórios **Refs:** `geotrix3d#005` · `minex_qa#011` · `arch_migration#001` **Apps e Pacotes no escopo:** * **Frontend:** `geotrixMap` (Contexto 3D/Cesium). * **Backend:** `geotrix2dpre` (Processamento de dados e regras de negócio). --- ## 1) Otimização e Relatório de Performance (Kalahari33) **Objetivo:** Migrar para `Primitives` e comprovar ganho de eficiência. * **Justificativa:** Migrar de `ImageryLayers` para `GroundPrimitives` é mandatório para suportar rasters de alta resolução sem travar a interface. Além da refatoração do pipeline de dados, será gerado um **Relatório Técnico** comparando as métricas de latência e consumo de memória. * **Atividades:** * Refatoração do renderizador para `GroundPrimitive` (Rectangle Geometry) e otimização de texturas. * **Relatório de Performance:** Execução de script de benchmark no dataset *Kalahari33*. Monitoramento de FPS, Heap Memory (JS) e Tempo de Descompressão de Imagem. * Geração de documento PDF comparativo "Benchmarks: ImageryLayers vs GroundPrimitives". ## 2) Criação de Targets com Teste Automatizado E2E **Objetivo:** Ferramenta de desenho de ROI e validação automatizada de integração. * **Justificativa:** O desenho de targets no 3D é complexo. É crucial garantir que o polígono desenhado no front (`geotrixMap`) seja recebido e processado corretamente pelo back (`geotrix2dpre`). * **Atividades:** * Implementar ferramenta de desenho vetorial no Cesium (Draw Handler). * Conversão de coordenadas (Cartesian -> Cartographic) e envio ao R. * **Teste Automatizado (E2E):** Script `shinytest2` que simula o desenho de um polígono, dispara o evento para o backend `geotrix2dpre` e verifica se o objeto de retorno (filtro espacial) foi criado corretamente. * **Estimativa:** **32h** (22h feature + 10h testes automáticos específicos) ## 3) Mouse Interativo (Picking Rápido) **Objetivo:** Inspeção instantânea de dados. * **Justificativa:** Feedback visual imediato ao passar o mouse sobre furos/pontos, essencial para validação geológica antes de criar um target. * **Atividades:** * Implementar `ScreenSpaceEventHandler` para picking. * Tooltip HTML leve posicionado via coordenadas de tela (sem latência de servidor). * **Estimativa:** **18h** ## 4) Segregação de UI com Lit (Web Components) **Objetivo:** Migrar painéis de Edição e Logs para o Front-end usando Lit. * **Justificativa:** Modernização da arquitetura. O servidor R não deve renderizar HTML estático ou listas de logs. Usaremos **Lit** para criar componentes reativos, rápidos e desacoplados do Shiny. * **Atividades:** * Implementar componentes Lit para a aba "Logs" (renderização virtualizada de listas longas). * Implementar painel de "Edição de Parâmetros" usando Lit Elements, comunicando com R apenas via JSON. * **Estimativa:** **20h** ## 5) Visão alternativa aos dados espaciais **Objetivo:** Visualização estatística (Numérica/Categórica) integrada ao mapa 3D com filtragem interativa. * **Justificativa:** Fornecer uma visão alternativa aos dados espaciais. O usuário precisa analisar a distribuição dos dados (ex: histograma de teores ou contagem de litologias) e usar esses gráficos como controles de filtro. * **Atividades:** * Histogramas Interativos: Implementação de gráficos para dados numéricos (ex: distribuição de teores) e categóricos (ex: barras de litologia). * Coloração Dinâmica: Funcionalidade para alternar a escala de cores dos pontos no mapa 3D baseada em atributos (ex: Colorir por Z/Cota ou Colorir por Teor). * Filtros Visuais (Cross-filtering): Implementar lógica onde a seleção de um intervalo no histograma oculta imediatamente os pontos fora desse intervalo no visualizador 3D (client-side). * **Estimativa:** **20h** ## 6) QA Geral e Documentação (Obrigatório) **Objetivo:** Garantia de estabilidade do pacote. * **Justificativa:** Manutenção do padrão de qualidade e documentação de todas as alterações. * **Atividades:** * Testes unitários (`testthat`) para funções utilitárias. * Instrumentação para cobertura **> 90%** (`covr`). * Geração automática de `CHANGELOG.md`. * **Estimativa:** **24h** --- ## Resumo e Milestones (Janeiro/26) * `Otimização + Relatório Performance` — **32 h** * `Targets + Teste Auto (Front/Back)` — **32 h** * `Mouse Interativo (Picking)` — **18 h** * `Filtragem Dinâmica (Slicing/Shaders)` — **16 h** * `Segregação de UI` — **20 h** * `QA Geral` — **24 h** **TOTAL ESTIMADO:** **142 h** --- ## Critérios de Aceite (Definition of Done) 1. **Performance Comprovada:** * [ ] Entregue documento PDF "Relatório de Performance" mostrando FPS estável (>30) no *Kalahari33* após migração para Primitives. * [ ] Tempo de carga inicial < 5 segundos para 50k pontos. 2. **Targets & Integração:** * [ ] **Teste Automatizado Passou:** O script de teste simula o input no `geotrixMap`, e valida que o `geotrix2dpre` processou a geometria corretamente (retorno verde no CI). * [ ] Usuário consegue desenhar e salvar um target no visualizador. 3. **Funcionalidades Visuais:** * [ ] Visualização: Histogramas (numérico e categórico) são renderizados corretamente com os dados do projeto carregado. * [ ] Interação: Ao filtrar uma categoria ou faixa de valores no gráfico, o mapa 3D atualiza instantaneamente, exibindo apenas os pontos correspondentes. * [ ] Mapeamento: Usuário consegue alternar a coloração dos pontos entre "Cota (Z)" e "Atributo (Teor)". 4. **Qualidade:** * [ ] Cobertura global > 90%. * [ ] Changelog atualizado. * [ ] Interfaces de Log/Edição operacionais via Web Components.
Overdue by 3 month(s)•Due by January 31, 2026# **Proposta: MVP Beta para Mapeamento 3D (CesiumJS \+ R Shiny)** Período de Execução Estimado: 1 Mês. Esforço Total Estimado para o MVP: 147 Horas. Foco da MVP: Criar uma Versão Beta Mínima Viável (MVP Beta) que comprove a comunicação bidirecional entre R/Shiny e CesiumJS e demonstre a conversão e visualização de dados vetoriais simples (pontos). ## **1\. Escopo Simplificado e Entregáveis (Total: 147 Horas)** Esta fase foca apenas no essencial para o funcionamento (comunicação e conversão de dados de pontos). As horas estão distribuídas com base na complexidade e nos testes necessários para cada etapa. | Fase | Título da Fase | Esforço (Horas) | Duração (Dias de Ref.) | Entregáveis Chave | | :-------- | :---------------------------------- | :-------------- | :--------------------- | :----------------------------------------------------------- | | **I** | **Setup e Base de Comunicação** | 45h | 3 Dias | Ambiente Shiny/CesiumJS configurado; Rota de comunicação R \<-\> JS validada. | | **II** | **Conversão e Visualização Básica** | 60h | 4 Dias | Função R para conversão de um *dataset* de pontos para CZML; Renderização de entidades CZML no CesiumJS; Injeção de dados dinâmicos do R para o mapa. | | **III** | **Validação e Plano de Estudo** | 42h | 3 Dias | MVP Beta Funcional (mostrando pontos 3D); Documentação mínima da API; Plano detalhado para as próximas fases de estudo e aprimoramento. | | **TOTAL** | | **147h** | **10 Dias** | | ## **2\. Cronograma Detalhado do MVP (147 Horas)** ### **FASE I: Setup e Base de Comunicação (Total: 45h)** Foco em fazer o R, Shiny e CesiumJS "conversarem". | Esforço (Horas) | Atividade | Foco Principal | Ferramentas | | :-------------- | :---------------------------------------------- | :----------------------------------------------------------- | :---------------------------------------- | | **15h** | **Setup do Ambiente e Inicialização do Cesium** | Configuração do projeto R Shiny (ui.R e server.R); Inclusão do CesiumJS via CDN. Inicialização do visor 3D básico. | R, RStudio, Shiny, CesiumJS | | **15h** | **Comunicação R \-\> JavaScript (Handlers)** | Implementação de um *Shiny Message Handler* (JS) para receber comandos do R, como "voe para a coordenada X". | R (session$sendCustomMessage), JavaScript | | **15h** | **Comunicação JavaScript \-\> R (Binders)** | Criação de um *Shiny Custom Input Binding* (JS) para enviar eventos do CesiumJS para o R (ex.: notificar o R sobre a coordenada clicada pelo usuário). | JavaScript, R (input$...) | ### **FASE II: Conversão e Visualização Básica (Total: 60h)** Foco na conversão e visualização do tipo de dado mais simples (pontos) para validação do fluxo completo. | Esforço (Horas) | Atividade | Foco Principal | Entregável Parcial | | :-------------- | :-------------------------------------------- | :----------------------------------------------------------- | :------------------------------------------------- | | **15h** | **Função R de Conversão de Pontos** | Desenvolvimento da função R para ler um data.frame ou objeto sf de PONTOS e formatá-lo como uma estrutura JSON simples. | Função R de conversão de PONTOS para JSON. | | **15h** | **Geração Simplificada de CZML** | Adaptar a estrutura JSON para o formato CZML (o formato de dados vetoriais nativo do Cesium). Focar apenas nas propriedades de posição. | Módulo R de geração de CZML para Pontos. | | **15h** | **Renderização de Dados Dinâmicos no Cesium** | Criação da função JavaScript para receber o CZML do R e carregá-lo no visor 3D do Cesium. | Script JS de carregamento dinâmico de CZML. | | **15h** | **Visualização End-to-End** | Teste completo: Botão no Shiny (R) dispara a conversão de dados, que são enviados via API e visualizados como entidades 3D no CesiumJS. | Prova de conceito funcional (visualizando pontos). | ### **FASE III: Validação e Plano de Estudo (Total: 42h)** Fase de polimento, documentação mínima para estudo e definição dos próximos passos. | Esforço (Horas) | Atividade | Foco Principal | Entregável Parcial | | :-------------- | :-------------------------------------- | :----------------------------------------------------------- | :------------------------------------------------------ | | **15h** | **Tratamento de Erros Básico** | Implementação de uma estrutura try-catch mínima para evitar que a aplicação quebre durante a conversão ou comunicação. | Tratamento de erros básico (R e JS). | | **15h** | **Documentação Mínima da API** | Documentação das funções R (convert\_to\_czml) e das funções JS de comunicação (sendToR, handleFromR). | Documentação técnica da comunicação. | | **12h** | **Revisão e Plano de Estudo Detalhado** | Revisão final do MVP. Elaboração de um plano de estudo para os 10 dias restantes do mês, focando em Raster, Tiling e CRS. | **MVP Beta Finalizado** e Roteiro de Estudo para o Mês. | ## **3\. Próximos Passos (Fases Futuras após o MVP)** Após a conclusão das 147 horas de esforço (MVP), você terá uma base sólida. As funcionalidades mais complexas, como conversão de Rasters (DEM) para Terreno 3D, a implementação de *Tiling* e as ferramentas de medição 3D, serão tratadas em passos futuros ou durante o seu período de estudo no restante do mês.
Overdue by 4 month(s)•Due by December 31, 2025GEOTRIX 3D MANUTENCAO OUTUBRO/25 1 — Streaming de objetos 3D Label: backend, performance, geotrix3D Tempo estimado: 24 h Descrição: implementar carregamento “on-request” de objetos 3D. Objetivo: reduzir uso de memória e tempo de abertura. Critérios de aceite: logs mostram fetch apenas sob demanda. 2 — Tag de execução de análise Label: frontend, results, UX Tempo estimado: 7 h Descrição: replicar mecanismo de tag da versão 2D no Minex 3D. Objetivo: padronizar rastreabilidade entre dimensões. Critérios de aceite: tag visível e filtrável no painel 3D. 3 — Gráfico por coordenadas (X/Y/Z × valor) Label: analytics, UI Tempo estimado: 4 h Descrição: adaptar gráfico espacial para o ambiente 3D. Objetivo: exibir distribuição por eixo ou corte. Critérios de aceite: render 3D interativo sem travamentos. 4 — Erro (to – from)/by no painel de métricas Label: bug, stats Tempo estimado: 4 h Descrição: corrigir bins inválidos quando target é selecionado. Objetivo: evitar exceções de intervalo negativo. Critérios de aceite: testes passam com target ativado. 5 — Gráfico de correlação entre variáveis Label: analytics, UI, stats Tempo estimado: 4 h Descrição: adicionar gráfico de correlação no painel 3D. Objetivo: visualizar dependência entre teores. Critérios de aceite: mostra r e p-value em tooltip. 6 — Exportação de resultados (PDF / HTML) Label: reports, docs, production Tempo estimado: 7 h Descrição: criar exportação padronizada com layout unificado. Objetivo: permitir auditoria cruzada entre 2D e 3D. Critérios de aceite: cabeçalho, logotipo e parâmetros idênticos.
Overdue by 6 month(s)•Due by October 31, 2025