# Sistema de TR — Roadmap de Conformidade com a Lei 14.133/2021 **Plataforma Inteligente para Planejamento, Estruturação e Gestão das Contratações Públicas** Documento de referência para o roadmap completo de implementação Sistema: `sistemadetr.com.br` (InfyOm Laravel Generator + Livewire 2.12) Última atualização: 2026-06-08 --- ## 1. Estrutura conceitual da Lei 14.133/2021 ``` CONTRATAÇÃO PÚBLICA │ ┌─────────────────┼─────────────────┐ │ │ │ LICITAÇÃO CONTRATAÇÃO PROCEDIMENTOS (5 modalid.) DIRETA AUXILIARES Art. 28 (sem lic.) Art. 78 │ │ │ ├─ Pregão ├─ Dispensa ├─ Credenciamento (Art. 79) ├─ Concorrência │ (Art. 75) ├─ Pré-qualificação (Art. 80) ├─ Concurso └─ Inexigibilid. ├─ PMI (Art. 81) ├─ Leilão (Art. 74) ├─ SRP — Registro (82–87) └─ Diálogo Comp. └─ Registro Cadastral (87–88) TODAS precisam dos mesmos DOCUMENTOS DA FASE PREPARATÓRIA: DFD → ETP → TR/Projeto Básico → Matriz de Risco → Pesquisa de Preços → Edital ``` ### Observações de taxonomia - **TR não é modalidade.** É um documento que descreve o objeto e precede qualquer modalidade. - **As 5 modalidades de Licitação** definem o RITO (publicação, prazo, julgamento), não o documento. - **Procedimentos Auxiliares** orbitam a contratação — não são modalidades nem contratação direta: - **Credenciamento**: convoca todos os qualificados, sem disputa (saúde, peritos, eventos) - **Pré-qualificação**: habilita previamente fornecedores/produtos - **PMI**: permite que a iniciativa privada apresente estudos para o Poder Público - **SRP**: Ata de Registro de Preços — contratação por até 1 ano sem novo certame - **Registro Cadastral**: cadastro permanente de fornecedores aptos ### Ciclo de vida completo da contratação ``` PRÉ-LICITAÇÃO LICITAÇÃO PÓS-LICITAÇÃO (Planejamento e (Seleção) (Gestão Contratual) Governança) │ │ │ ┌────┴────┐ ┌────┴────┐ ┌────┴────┐ ├ PCA │ ├ DFD │ ├ Contrato│ ├ PLS │ ├ ETP │ ├ Atas │ ├ Mapa │ ├ TR │ ├ Aditivos│ │ Riscos │ ├ Matriz │ ├ Fiscal │ ├ Audiên- │ ├ Pesq. │ ├ Receb. │ │ cias │ │ Preços │ ├ Sanções │ ├ PMI │ ├ Edital │ ├ Reequil.│ ├ Capac. │ ├ Sessão │ └ Encerr. │ ├ Catálogo│ ├ Adjudic.│ │ Local │ └ Homolog.│ └ Banco │ Preços │ ↓ ↓ ↓ CONTROLE INTERNO E CONFORMIDADE (transversal — checklists, parecer, auditoria) ↓ TRANSPARÊNCIA — PNCP, Portal, LAI, LGPD ``` --- ## 2. Inventário do que o sistema JÁ contempla ### Geração principal (wizard `/wizard/create`) | Documento | Status | Onde | |---|---|---| | TR | ✅ | `FaceTrading.php` (`docName='Termo de Referência'`) + wizard | | ETP | ✅ | `samplepage/` + `PlanningSecretariat` | | DFD | ✅ | `Autocomplete3Job` (`doc_type='Documento de Formalização de Demanda'`) | | Matriz de Risco | ✅ | `ProcessMatrizJob` / `ProcessMatrizCommand` | | Pesquisa de Preços | ✅ | `PriceTake` + `SurveyReport` (duas implementações) | ### Funcionalidades do card | Item | Status | Onde | |---|---|---| | Edital | ✅ | `EditalPage.php` + controller + views + jobs | | Contrato | ✅ | `ContractPage.php` + `SignedContract` | | Relatório de Pesquisa de Preços | ✅ | `PriceTake` + `SurveyReport` | | Parecer Jurídico | ❓ lacuna | Existe `LegalBasis` (fundamentação via API), diferente | | Parecer do Controle Interno | ⚠️ parcial | só dentro da Inexigibilidade | | Resposta à Impugnação | ⚠️ parcial | só dentro da Inexigibilidade | | Anteprojeto e Projeto Básico | ✅ | `AnteprojetoPage.php` + `ProjetoBasicoPage.php` | | PCA — Plano Anual de Contratações | ✅ | `AnnualHiringPlan` + Raw + Setting + import/export | | Ata de Registro de Preços | ✅ | `Modules\UnenforceabilityPage\Models\AtaDeRegistro` | | Integração com Portarias e Decretos | ✅ | `NormasInst` — upload PDF + parser + OpenAI | | Geração via WhatsApp | ✅ | `WhatsappFlowManager` + `SendPulseWhatsApp` | | Reconhecimento Facial (assinatura) | ⚠️ | Projeto Django separado em `/var/www/html/django-faceid/` (gunicorn :8001) | | Indicadores de Descarbonização | ⚠️ quebrado | `Descar` + `DescarbonizacaoCommand` usa `auth()->user()` em CLI (sempre null) | | Biblioteca de Obras 2D/3D | ✅ | `DwgRvtLibrary` | | Reequilíbrio Contratual | ⚠️ parcial | `ContractualRebalancing` existe; Job não substitui `[BRASAO]` | | Gestão de Contratos, Atas e Licitantes | ⚠️ disperso | `ContractPage` + `PublicCall` + `Bidder` em telas separadas, sem dashboard | ### Outros módulos identificados Justificativa de Contratação ✅, Certidão de Publicação ✅, Autorização de Fornecimento ✅, Ato Declaratório de Dispensa ✅, Dispensa de Licitação ✅, Inexigibilidade ✅, Memorandos ✅, CATMAT ✅, Tabela CMED ✅, Concorrência (`competition`) ✅. ### Capacidade existente — Gestão de Prompts por Seção (padrão dual) Capacidade já entregue que vale destacar como **princípio arquitetural**: - **Para cada documento licitatório**, o sistema mantém **dois menus separados**: 1. **Menu do documento** — onde o usuário cria, edita e gerencia instâncias do documento (ex.: TR, ETP, DFD) 2. **Menu de prompts do documento** — onde administradores ajustam o prompt da IA usado para cada seção desse documento - Implementado via `FieldConfigurationController@edit` + rotas `/prompts/{nome}` (anteprojetopage, projetobasicopage, ata-de-registro, autorizacao-forencimento, etc.) - Cada Model expõe `fields()` que define as seções e cada seção carrega o prompt editável - **Vantagem operacional:** ajustar a IA não exige redeploy — admin edita e o próximo documento gerado já usa o prompt novo - **Princípio para o roadmap:** todo novo documento entregue (Grupos A, C, D, etc.) **deve seguir esse padrão dual** — tela operacional + tela de prompts/seções via `FieldConfigurationController` --- ## 3. Roadmap de lacunas — Grupos R, A a Q ### Grupo R — Unificação do TR e Reforma do Modelo de Dados (PRIORIDADE 0) **Problema identificado.** O sistema atual tem 5 Models diferentes com `docName='Termo de Referência'` — cada um para uma "modalidade" da antiga Lei 8.666/93. Pela Lei 14.133, o TR é único e independe da modalidade. Além disso, há Models de modalidades **revogadas** ainda vivos: #### R.0a — Auditoria de Nomenclatura (tradução macarrônica) A nomenclatura atual dos Models foi feita por **tradução literal do português para o inglês** sem revisão jurídica/técnica, gerando nomes que não existem em inglês real, que confundem o desenvolvedor, e que mascaram a finalidade do Model. Análise por Model, correlacionando com a Lei 14.133: | Model / Tabela atual | Tradução literal que provavelmente motivou | Bom inglês seria | Finalidade real (português) | Correspondência na Lei 14.133 | Status | |---|---|---|---|---|---| | `SamplePage` / `sample_pages` | "Página Modelo / Amostra" — alguém usou *sample* como "modelo". Mas *sample* = amostra estatística | `TemplatePage` ou `Document` | **TR genérico** — na prática, o único Model ativo, recebe todos os TRs do wizard sem distinção de modalidade | TR (Art. 6º, XXIII) — não é modalidade, é documento | ✅ 18 reg, ativo | | `FaceTrading` / `face_tradings` | "Negociação Face a Face" — *face-to-face* virou *face trading*, quebrando a gramática | `InPersonAuction` ou `LiveBidding` | **Pregão Presencial** (decreto local; eletrônico é regra na 14.133) | Pregão (Art. 28, I + Art. 17, §2º — eletrônico preferencial) | ⚠️ 1 reg, marginal | | `Competition` / `competitions` | "Concorrência" → *competition* | `PublicTender` ou `OpenBidding` | **Concorrência** (modalidade) | Concorrência (Art. 28, II + Art. 6º, XXXVIII) | ⚠️ 1 reg, marginal | | `BiddingWaiver` / `bidding_waivers` | "Renúncia de Licitação" — *waiver* = renúncia/dispensa | `DirectProcurement` ou `BidWaiver` | **Dispensa de Licitação** | Dispensa (Art. 75) | ⚠️ 0 reg, vazia | | `Unenforceability` / `unenforceabilities` | "Inexigibilidade" — *unenforceability* é termo jurídico em inglês, mas significa "cláusula inexequível" (contratos), **não** "inexigibilidade de licitação" | `SoleSourceProcurement` ou `NonCompetitiveProcurement` | **Inexigibilidade de Licitação** | Inexigibilidade (Art. 74) | ⚠️ 1 reg, marginal | | `Invitation` / `invitations` | "Convite" → *invitation* | `LetterOfInvitation` (mas modalidade nem existe mais) | **Carta-Convite** (modalidade extinta) | **REVOGADA** pela Lei 14.133 | ❌ 1 reg de jan/2022, apagar | | `PriceTake` / `price_takes` | "Tomada de Preços" — *tomada* → *take* + *preços* → *price*. Justaposição quebrada em inglês: *price take* não existe como expressão | `PriceQuoteBidding` ou `ShortlistBidding` | **Tomada de Preços** (modalidade extinta) | **REVOGADA** pela Lei 14.133 | ❌ 7 reg de mar/2022, apagar | ##### Outros Models impactados pela mesma tradução macarrônica (ainda que não sejam de TR) | Model atual | Tradução literal | Bom inglês | Finalidade real | Correspondência | |---|---|---|---|---| | `PlanningSecretariat` / `planning_secretariats` | "Secretaria de Planejamento" — confunde, é DFD | `DemandFormalization` | **Documento de Formalização da Demanda (DFD)** | Art. 12, VII | | `Technical` / `technicals` | "Técnico" — genérico demais | `PreliminaryTechnicalStudy` | **Estudo Técnico Preliminar (ETP)** | Art. 18, §1º | | `SurveyReport` / `survey_reports` | "Relatório de Survey" — *survey* sugere questionário social | `PriceResearchReport` | **Relatório de Pesquisa de Preços** | Art. 23 | | `PriceTake` / `PriceTakeController` (já listado acima) | — | — | Conflito adicional: o nome inglês sugere "Pesquisa de Preços", mas o uso real é "Tomada de Preços" (modalidade) | — | | `Matriz` / `matriz_records` | "Matriz" preservado em português | `RiskMatrix` | **Matriz de Risco** | Arts. 22 e 103 | | `EditalPage` / `edital_pages` | "Edital" preservado em português | `PublicNotice` ou `Bidding Notice` | **Edital** | Art. 25 | | `ContractPage` / `contract_pages` | "Contrato" preservado em português | `Contract` | **Contrato** | Art. 89 | | `PublicCall` / `public_calls` | "Chamada Pública" | `PublicCall` (OK) | **Chamada Pública / Ata de Registro de Preços** | Arts. 82–87 | | `AnteprojetoPage` / `anteprojeto_pages` | Português | `PreliminaryDesign` | **Anteprojeto** | Art. 6º, XXIV | | `ProjetoBasicoPage` / `projeto_basico_pages` | Português | `BasicDesign` | **Projeto Básico** | Art. 6º, XXV | | `LegalBasis` / `legal_basis` | "Base Legal" → OK em inglês | `LegalBasis` (OK) | **Fundamentação Jurídica** (consumida via API externa) | — | | `DwgRvtLibrary` / `dwgrvtlibraries` | "Biblioteca DWG/RVT" — siglas técnicas | `DwgRvtLibrary` (OK, técnico) | **Biblioteca de Obras 2D/3D** | — | ##### Observações importantes da auditoria 1. **`SamplePage` é o mais bizarro:** o nome sugere "página exemplo/modelo" mas é **o Model mais usado do sistema** (todos os TRs do wizard caem aqui). Hipótese: começou como tela template do gerador InfyOm, virou TR genérico, e o nome ficou. **Evidência forte de que o sistema já trata o TR como único** — a separação por modalidade nos outros 4 Models é teoria que a prática contradiz. 2. **`Unenforceability` é o mais juridicamente perigoso:** o termo em inglês existe, mas significa "cláusula contratual inexequível", NÃO "inexigibilidade de licitação". Quem ler o código sem contexto interpreta errado. 3. **`PriceTake` e `Invitation` não precisam nem ser renomeados — vão ser apagados** (modalidades revogadas, sem uso há 4 anos). 4. **`PlanningSecretariat`** é o segundo mais confuso: sugere "secretaria de planejamento" mas representa **DFD**. Quem mexer no Model sem contexto vai achar que está numa entidade organizacional. 5. **Padrão de tradução literal de PT-BR → EN sem revisão** é claro: *sample* (modelo), *unforceability* (inexigibilidade), *face trading* (face a face = presencial), *price take* (tomada de preços). Todos seguem o mesmo erro: traduzir palavra-por-palavra sem checar se o termo resultante existe e/ou significa a coisa certa. ##### Conclusão da auditoria de nomenclatura - A nomenclatura confusa **é sintoma da causa estrutural** (separação por modalidade) que a Lei 14.133 declara inexistente para TR. - **Renomear os Models para português correto resolveria o sintoma mas manteria a estrutura errada.** - **Consolidar em `TermoDeReferencia` único + `ProcessoContratacao` com campo `modalidade`** resolve ambos (sintoma e causa) de uma vez. - Os Models de outras peças (ETP, DFD, Matriz, Edital, etc.) também merecem renomeação para PT-BR consistente, mas como **não há duplicação estrutural neles** (cada peça é um Model), o esforço é só cosmético — pode esperar. - **Prioridade absoluta** segue sendo apagar Models de modalidades revogadas (`Invitation`, `PriceTake`) e consolidar os 5 TRs em 1. --- | Model atual | O que representa | Status | |---|---|---| | `SamplePage` | TR genérico (também usado como ETP em alguns fluxos) | manter base | | `FaceTrading` | Pregão Presencial | unificar | | `Competition` | Concorrência | unificar | | `BiddingWaiver` | Dispensa de Licitação | unificar | | `Unenforceability` | Inexigibilidade | unificar | | `PriceTake` | **Tomada de Preços** | **modalidade REVOGADA** — apagar | | `Invitation` | **Convite** | **modalidade REVOGADA** — apagar | **Modelo conceitual novo:** ``` ProcessoContratacao ← entidade central única ├── modalidade: pregao | concorrencia | concurso | leilao | dialogo_competitivo │ | dispensa | inexigibilidade ├── procedimento_auxiliar: srp | credenciamento | pre_qualificacao | pmi | null ├── valor_estimado, status, agentes, ... │ ├── DFD (único por processo) ├── ETP (único por processo) ├── TR ← ÚNICO Model, independe da modalidade ├── Matriz de Risco ├── Pesquisa de Preços ├── Parecer Jurídico ├── Parecer do Controle Interno ├── Edital ← varia conforme modalidade (cláusulas específicas) ├── Contrato └── ... ``` | # | Item | |---|---| | R1 | **Criar `TermoDeReferencia` único** (ou renomear `SamplePage`) | | R2 | **Criar `ProcessoContratacao`** como entidade central com campo `modalidade` | | R3 | **Migrar dados** dos 5 Models existentes para o `TermoDeReferencia` | | R4 | **Mapear campos divergentes** entre os Models antigos e o novo | | R5 | **Apagar `Invitation`** (modalidade Convite, revogada pela 14.133) | | R6 | **Apagar `PriceTake`** (modalidade Tomada de Preços, revogada pela 14.133) | | R7 | **Unificar prompts da IA**: substituir `/prompts/{modalidade}` por `/prompts/tr` parametrizado por modalidade | | R8 | **Atualizar jobs** (`Autocomplete2/3/5Job`, `ProcessMatrizJob`) para usar o Model único | | R9 | **Atualizar views** (consolidar CRUDs e formulários) | | R10 | **Atualizar menu lateral** (remover entradas por modalidade) | | R11 | **Atualizar rotas** (`samplepage`, `facetrading`, `competition`, `biddingwaiver`, `unenforceabilitypage`, `invitation`, `pricetake`) | | R12 | **Migração SQL com backup**: rota segura com rollback | | R13 | **Edital permanece com variações por modalidade** (esse desacoplamento está correto) | **Vantagens:** - Conformidade direta com a Lei 14.133 (TR único) - 1 modelo em vez de 7 → manutenção mais simples - Mesmo TR reaproveitável entre modalidades (Q1 — geração do PCA fica natural) - Conjunto único de prompts → IA mais consistente - Reduz CRUDs duplicados no menu **Cuidados:** - Migração de dados dos 5 Models existentes — fazer com staging + checksum - Alguns Models têm colunas próprias (atestar mapeamento campo a campo antes) - Jobs e views que referenciam o Model precisam ser atualizados — quebrar tudo se feito sem teste **Esse grupo é pré-requisito para vários outros**: A (modalidades faltantes), F (pareceres generalizados), M (checklists por modalidade), P (orquestração), Q (geração do PCA a partir de contratos). --- ### Grupo A — Modalidades de Licitação faltantes | # | Modalidade | Art. | Quando usar | |---|---|---|---| | A1 | **Concurso** | 30 | Trabalhos técnicos, artísticos, científicos com premiação | | A2 | **Leilão** | 31 | Alienação de bens (móveis, imóveis, semoventes) | | A3 | **Diálogo Competitivo** | 32 | Objetos de inovação técnica/financeira não especificáveis previamente | ### Grupo B — Procedimentos Auxiliares ausentes | # | Procedimento | Art. | |---|---|---| | B1 | **Credenciamento** | 79 | | B2 | **Pré-qualificação** | 80 | | B3 | **PMI** (Procedimento de Manifestação de Interesse) | 81 | | — | SRP — já existe parcialmente como `AtaDeRegistro` | 82–87 | ### Grupo C — Documentos da Fase Preparatória faltantes | # | Documento | Art. | |---|---|---| | C1 | **Projeto Executivo** (distinto de Projeto Básico) | 6º, XXVI | | C2 | **Programa de Integridade** (obrigatório p/ contratos de grande vulto) | 25, §4º | ### Grupo D — Documentos da Fase de Seleção faltantes | # | Documento | Art. | |---|---|---| | D1 | **Aviso de Licitação** | 54 | | D2 | **Ata da Sessão Pública** | 60, III | | D3 | **Termo de Adjudicação** | 71 | | D4 | **Termo de Homologação** | 71 | | D5 | **Decisão sobre Recurso** | 165 | | D6 | **Decisão sobre Impugnação** (generalizada, não só Inexigibilidade) | 24 | ### Grupo E — Documentos da Fase Contratual (peças avulsas) | # | Documento | Art. | Obs. | |---|---|---|---| | E1 | **Termo Aditivo** | 124 | → promovido para K1 | | E2 | **Termo de Apostilamento** | 136 | → promovido para K3 | | E3 | **Termo de Rescisão** | 137–139 | → promovido para K4 | | E4 | **Designação de Fiscal/Gestor do Contrato** | 117 | → promovido para I2 | | E5 | **Relatório de Fiscalização Contratual** | 117 | → promovido para I3 | | E6 | **Termo de Recebimento Provisório/Definitivo** | 140 | → promovido para I4 | | E7 | **Minuta de Contrato** (anexa ao edital, se não embutida) | 25, §1º | | ### Grupo F — Pareceres e Controle | # | Documento | Art. | |---|---|---| | F1 | **Parecer Jurídico** (módulo próprio, decisão pendente) | 53 | | F2 | **Parecer do Controle Interno** (generalizado, derivado da checklist M) | 169 | | F3 | **Parecer Técnico** | 18 | ### Grupo G — Sanções Administrativas | # | Documento | Art. | |---|---|---| | G1 | **Processo de Sanção Administrativa** | 155–163 | | G2 | **Auto de Infração** | 158 | | G3 | **Defesa Prévia / Contraditório** | 158 | ### Grupo H — Planejamento Pré-Licitação (governança institucional) | # | Item | Base legal | Status | |---|---|---|---| | H1 | **PLS — Plano de Logística Sustentável** | Dec. 7.746/2012 + Dec. 10.880/2021 + IN SEGES/ME 1/2023 | ❌ ausente | | H2 | **Diagnóstico Institucional / Inventário de Demandas** | boa prática | ❌ | | H3 | **Banco Histórico de Preços** | Art. 23 | ⚠️ parcial (Pesquisa de Preços avulsa, sem banco) | | H4 | **Catálogo Local de Itens** (extensão do CATMAT/CATSER) | Art. 19, II | ⚠️ parcial (CATMAT externo) | | H5 | **Mapeamento de Fornecedores Locais (ME/EPP)** | LC 123/2006 + Art. 4º | ❌ | | H6 | **Audiência / Consulta Pública** | Art. 21 | ❌ | | H7 | **Plano de Capacitação dos Agentes de Contratação** | Art. 7º, §2º | ❌ | | H8 | **Mapa de Riscos Institucional** | Art. 169 (linhas de defesa) | ❌ | | — | PCA — Plano Anual de Contratações | Art. 12, VII | ✅ existe (`AnnualHiringPlan`) | ### Grupo I — Gestão de Contratos (painel real) | # | Item | Base legal | |---|---|---| | I1 | **Painel/Dashboard de Contratos** (status, vigência, fiscal, valor empenhado, alertas) | Art. 117 + boa prática | | I2 | **Designação de Fiscal/Gestor** | Art. 117 | | I3 | **Relatório de Fiscalização** | Art. 117 | | I4 | **Termo de Recebimento Provisório/Definitivo** | Art. 140 | | I5 | **Controle de Garantia Contratual** | Arts. 96–102 | | I6 | **Avaliação de Desempenho do Contratado** | Art. 144 (remuneração variável) | | I7 | **Calendário de Vencimentos** (contratos + atas + certidões) | Art. 117 + boa prática | ### Grupo J — Gestão de Atas (com quantitativos) | # | Item | Base legal | |---|---|---| | J1 | **Painel de Atas com saldo/quantitativo consumido** | Arts. 82–87 | | J2 | **Adesão e Carona** (procedimentos de SRP) | Art. 86 | | J3 | **Replanejamento de quantitativos** | Art. 85 | | J4 | **Republicação trimestral** | Art. 85, §1º | ### Grupo K — Gestão de Aditivos | # | Item | Base legal | |---|---|---| | K1 | **Termo Aditivo** | Art. 124 | | K2 | **Controle dos limites cumulativos** (25% / 50%) | Art. 125 | | K3 | **Apostilamento** | Art. 136 | | K4 | **Termo de Rescisão** | Arts. 137–139 | | K5 | **Reequilíbrio Econômico-Financeiro** (refinar o existente) | Art. 124, II | ### Grupo L — Transparência e Accountability | # | Item | Base legal | |---|---|---| | L1 | **Integração com PNCP** (detalhada no Grupo S — Prioridade 1) | Art. 174 (obrigatório!) | | L2 | **Portal da Transparência automatizado** | Lei 12.527/2011 (LAI) | | L3 | **Relatórios LAI** | Lei 12.527/2011 | | L4 | **LGPD — gestão dos dados coletados** (resolver vazamentos atuais) | Lei 13.709/2018 | ### Grupo M — Controle Interno e Conformidade (checklists) Cada processo do sistema deve ter uma aba/módulo "Controle Interno" com checklist correspondente ao tipo do processo. O **Parecer do Controle Interno** (F2) é derivado das respostas da checklist. | # | Item | Base legal | |---|---|---| | M1 | **Templates de checklist por modalidade** (CRUD admin) | Art. 169 | | M2 | **Preenchimento da checklist por processo** | — | | M3 | **Geração do Parecer do Controle Interno** a partir da checklist | Art. 169 (vincula com F2) | | M4 | **Painel de Conformidade** (% conforme por unidade/período) | boa prática TC | | M5 | **Bloqueio de avanço** em não-conformidade crítica | governança | | M6 | **Integração com modelos do TCE local** (importar checklist oficial) | resoluções TCE | | M7 | **Histórico/auditoria** das respostas | LGPD + accountability | **Modelos de dados sugeridos:** - `ChecklistTemplate` — checklist por tipo de processo - `ChecklistItem` — item da checklist (peso, criticidade, base legal) - `ChecklistResponse` — resposta vinculada a um processo específico - `ChecklistResponseItem` — resposta de cada item (status + observação + anexo) **Tipos típicos de checklist a contemplar:** | Checklist | Onde se aplica | |---|---| | Fase Interna/Preparatória | Todo processo | | Fase Externa/Seleção | Licitações | | Modalidade — Pregão Eletrônico | Pregão | | Dispensa (Art. 75) | Dispensa | | Inexigibilidade (Art. 74) | Inexigibilidade | | Contrato/Formalização | Contratação | | Execução Contratual | Vigência | | Aditivos | Aditivos | | Atas de Registro de Preços | SRP | | Encerramento | Pós-contrato | **Vantagem comercial:** prefeituras pequenas frequentemente são autuadas pelo TCE por falta de controle interno. Vender "geração de TR" + "checklist do TCE pronta" é diferencial enorme — distingue ferramenta de geração de ferramenta de **conformidade**. ### Grupo N — Inteligência Jurisprudencial e Ingestão Externa Mecanismo de coleta periódica de boletins de jurisprudência publicados pelos Tribunais de Contas (TCU, TCE-XX). Alimenta `LegalBasis` (fundamentação jurídica), as checklists do Grupo M e a base do `texto_inteligente`. | # | Item | Justificativa | |---|---|---| | N1 | **Crawler/scraper periódico dos boletins do TCU** | acórdãos do plenário, súmulas, jurisprudência selecionada | | N2 | **Crawler/scraper periódico dos boletins de TCEs** (configurável por UF) | TCE-BA, TCE-SP, TCE-MG, TCE-PE, TCE-AC, TCE-AL etc. | | N3 | **Parsing e classificação** (modalidade, tema, dispositivo legal) | indexar para busca por contexto | | N4 | **Notificação de novos entendimentos** que afetam processos em andamento | ex.: novo entendimento sobre dispensa muda checklist M | | N5 | **API interna para alimentar `LegalBasis` e o motor de geração** | substitui dependência exclusiva da API `precos.sistemadenegocios` | | N6 | **Versionamento** (boletim emitido, data, vigência) | rastreabilidade jurídica | | N7 | **Agendamento (Laravel Scheduler)** | diário/semanal por origem | **Fontes prioritárias:** - TCU — Boletim de Jurisprudência (semanal) + Informativo - TCE — Boletins/súmulas dos estados onde há clientes - AGU — Pareceres referenciais - CGU — Manuais de auditoria **Tabela sugerida:** `jurisprudence_bulletins` (origem, número, data, ementa, texto, tags, modalidade, dispositivo_legal, url_origem, hash, baixado_em). ### Grupo O — Humanização e Qualidade de Texto Camada de pós-processamento sobre a saída da IA, para que os documentos tenham linguagem natural brasileira de servidor público — não estilo de chatbot americano traduzido. | # | Item | Detalhe | |---|---|---| | O1 | **Remoção de travessão `—`** | substituir por vírgula, ponto ou parênteses conforme contexto. ChatGPT/Claude usam excessivamente; brasileiros raramente usam | | O2 | **Aspas curvas para retas** | converter `"..."` em `"..."` no padrão técnico de documento oficial | | O3 | **Remoção de muletas linguísticas de IA** | "vale ressaltar", "é importante destacar", "no entanto", "ademais", "outrossim" — quando em excesso | | O4 | **Voz ativa preferencial** | substituir construções em voz passiva quando possível | | O5 | **Padronização ortográfica AO 1990** | trema, hífen, acento, ortografia oficial | | O6 | **Conformidade com padrão jurídico-administrativo brasileiro** | "deste municí­pio", "o presente Termo", uso de iniciais maiúsculas em peças jurídicas | | O7 | **Verificação de tom institucional** | impessoal, formal, sem coloquialismos ou anglicismos | | O8 | **Score de "humanidade"** opcional | métrica de quanto soa "gerado por IA" vs "escrito por humano" | | O9 | **Verificação de duplicação** | evitar repetição de termos próximos (problema comum da IA) | | O10 | **Templates por região** | adaptar ao vocabulário típico da unidade federativa do cliente | **Implementação sugerida:** - Service `App\Services\TextHumanizer` que recebe texto bruto e aplica camadas de transformação (regex + segunda chamada de IA com prompt "humanize") - Aplicado como **último passo** dentro dos jobs `Autocomplete2/3/5Job`, `ProcessMatrizJob`, `ContractualRebalancingJob`, etc. - Configurável por documento (algumas peças querem manter formalidade dura) - Log de antes/depois para auditoria e ajuste ### Grupo P — Orquestração da Construção do Processo O sistema hoje gera documentos com a cadeia `Bus::chain($chain)` (Autocomplete3 → 5 → 2 → 4), mas é uma sequência fixa por job, não um motor de dependências entre documentos do mesmo processo. Em um processo real, as decisões do DFD influenciam o ETP, que influencia o TR, que influencia o Edital. Cada documento subsequente deve **herdar campos, decisões e fundamentações** do anterior. | # | Item | Detalhe | |---|---|---| | P1 | **Definição da ordem canônica de construção por modalidade** | ex.: Pregão Eletrônico → DFD → ETP → TR → Matriz Risco → Pesquisa Preços → Edital → Minuta Contrato → Aviso → ... → Termo Adjudicação → Homologação → Contrato → Recebimento | | P2 | **Mapa de dependências** entre documentos | quais campos do doc N alimentam o doc N+1 | | P3 | **Bloqueio de avanço** sem o anterior assinado/aprovado | controle de fluxo | | P4 | **Pré-preenchimento automático** de campos a partir do documento anterior | reduz retrabalho | | P5 | **Recálculo em cascata** quando um documento anterior é editado | invalidação controlada dos subsequentes | | P6 | **Linha do tempo do processo** (timeline visual com status) | auditoria + UX | | P7 | **Identificação do agente em cada etapa** (segregação de funções, Art. 8º) | requisitante × pesquisador × parecerista × homologador | | P8 | **Diferentes ordens por modalidade** | Concurso e Diálogo Competitivo têm sequências próprias | | P9 | **Reaproveitamento controlado** quando há documento ETP/TR similar anterior | acelera novos processos | | P10 | **Versionamento de cada peça do processo** | histórico de mudanças com diff | **Tabela sugerida:** `process_workflows` (modalidade, ordem JSON dos documentos, regras de dependência, regras de bloqueio). Conecta diretamente com: - **M (Controle Interno)** — checklists rodam entre as etapas - **F (Pareceres)** — gatilhos automáticos em pontos do fluxo - **I, J, K (Gestão)** — alimentam o pós-licitação - **L1 (PNCP)** — publicações automáticas em pontos do fluxo ### Grupo Q — Bootstrap Institucional, Acervo e Regulamentação Local Peças de **entrada do cliente no sistema** — o que o órgão precisa fazer assim que assina (ou para se regularizar com a Lei 14.133). Reduz fricção de onboarding e **contextualiza a IA com a realidade do órgão**, transformando o produto de "gerador genérico" em "gerador contextualizado". #### Q.1 — Lista de Contratos como documento de nascedouro Muitas prefeituras chegam ao sistema **sem ter o PCA construído**. Mas todas têm contratos vigentes (atuais e dos últimos anos). Importar essa lista vira insumo para: - **Gerar automaticamente o PCA** do exercício seguinte (com base no que historicamente foi contratado) - Inferir **demandas recorrentes** (objetos que se repetem ano a ano) - Identificar **picos de contratação** (sazonalidade) - Detectar **fragmentação** (contratos pequenos do mesmo objeto que deveriam virar SRP) - Sugerir **Atas de Registro de Preços** onde fizer sentido | # | Item | |---|---| | Q1.1 | **Importação de lista de contratos vigentes/históricos** (CSV/XLSX/PDF/PNCP) | | Q1.2 | **Normalização e classificação** (objeto, valor, fornecedor, vigência, fonte de recurso, secretaria) | | Q1.3 | **Inferência de demandas recorrentes** (clusterização de objetos similares) | | Q1.4 | **Geração automática do PCA** a partir do histórico importado | | Q1.5 | **Sugestões de melhoria** (uso de SRP, consolidação, prazo ótimo, modalidade indicada) | | Q1.6 | **Painel de cobertura** (quanto do PCA atual é coberto por contratos vigentes; o que precisa ser licitado) | Essa funcionalidade é **a porta de entrada ideal**: cliente envia planilha de contratos → sistema entrega PCA pronto + insights. Reduz tempo de adoção de meses para horas. #### Q.2 — Decreto Municipal de Regulamentação da Lei 14.133 Cada órgão público precisa publicar um decreto regulamentando a Lei 14.133 localmente. Sem isso, o órgão fica em situação irregular perante TCE/MP. O sistema pode gerar esse decreto parametrizado. | # | Item | |---|---| | Q2.1 | **Wizard de configuração do município** (UF, população, brasão, agentes, sistema eletrônico, regime contábil) | | Q2.2 | **Geração do Decreto de Regulamentação** a partir de modelo CNM/ATRICON parametrizável | | Q2.3 | **Customização de pontos chave** (valores de dispensa, designação de agentes, capacitação obrigatória, etc.) | | Q2.4 | **Versionamento por exercício** (decreto pode ser revisto anualmente) | | Q2.5 | **Modelos alternativos**: Lei Municipal, Resolução interna, Portaria de designação de agentes, Manual de Contratações do Órgão | | Q2.6 | **Banco de decretos publicados** por outros municípios (referência) | #### Q.3 — Onboarding e Configuração Inicial | # | Item | |---|---| | Q3.1 | **Wizard de onboarding** (passos guiados: município → órgão → agentes → preferências → integração PNCP) | | Q3.2 | **Cadastro inicial de fornecedores conhecidos** (importado da lista de contratos Q1) | | Q3.3 | **Configuração do timbre/brasão/papel timbrado** do órgão — ver Q.6 detalhado abaixo | | Q3.4 | **Designação inicial dos agentes** — ver Q.5 detalhado abaixo | | Q3.5 | **Adesão a planos/templates** (template "Prefeitura Pequena", "Prefeitura Média", "Câmara") | #### Q.5 — Designação de Papéis e Segregação de Funções (Art. 8º) A Lei 14.133 exige **segregação de funções** (Art. 8º, §1º). Sem designação formal dos agentes, o órgão fica em situação irregular. Esta etapa, no onboarding, define os papéis fundamentais e gera automaticamente as **Portarias de Designação**. **Papéis a designar no onboarding:** | Papel | Base legal | Como designar | |---|---|---| | Ordenador de Despesas | Art. 8º + Lei 4.320/64 | nominal — assina tudo no fim | | Agente de Contratação | Art. 8º | nominal — conduz a maioria dos processos | | Comissão de Contratação (3+) | Art. 8º, §2º | nominal — bens/serviços especiais | | Pregoeiro | Art. 8º + Dec. 10.024/19 | nominal — modalidade Pregão | | Equipe de Apoio | Art. 8º | nominal | | Autoridade Superior | Art. 8º | nominal — homologa o processo | | Controle Interno | Art. 169 | nominal — parecer obrigatório | | Procuradoria / Jurídico | Art. 53 | nominal — parecer obrigatório | | Pool de Fiscais de Contrato | Art. 117 | cadastro (designação específica por contrato) | | Pool de Gestores de Contrato | Art. 117 | cadastro (designação específica por contrato) | | # | Item | |---|---| | Q5.1 | **Cadastro de cada papel** vinculado a usuário(s) do sistema | | Q5.2 | **Geração automática da Portaria de Designação** (PDF assinável) por papel ou em lote | | Q5.3 | **Convite por e-mail** ao designado para acessar o sistema com o papel | | Q5.4 | **RBAC ativado** — usuário só vê o que cabe ao papel (vide Premissa 12.4) | | Q5.5 | **Validação de segregação de funções** (Art. 8º, §1º) — alerta quando há acúmulo proibido no mesmo processo (ex.: Agente de Contratação ≠ Parecerista Jurídico do mesmo processo) | | Q5.6 | **Versionamento por data** — histórico preservado quando há substituição | | Q5.7 | **Substituição** — fluxo de exoneração + nova designação (não permitir agente "fantasma") | | Q5.8 | **Suplentes** — designar suplente para férias/afastamentos por papel | | Q5.9 | **Acúmulo temporário permitido com alerta** — municípios pequenos cumulam (mesma pessoa Ordenador + Agente); sistema permite mas sinaliza | | Q5.10 | **Vinculação automática ao Decreto de Regulamentação (Q2)** — o decreto local cita nominalmente os agentes designados | | Q5.11 | **Painel de designações vigentes** — quem é quem, com vigências e portarias | | Q5.12 | **Alertas de vencimento** de designações (mandato de pregoeiro tem prazo, etc.) | **Tabelas sugeridas:** - `agent_roles` — papéis existentes (constantes da Lei 14.133) - `agent_designations` — designação atual (papel × usuário × período × portaria) - `agent_designations_history` — histórico de mudanças - `agent_segregation_rules` — pares de papéis que não podem coexistir no mesmo processo #### Q.6 — Identidade Visual e Papel Timbrado Permitir que o órgão envie um arquivo `.docx` ou `.pdf` **apenas como fonte de identidade visual** — o sistema **extrai** dele os componentes do papel timbrado (cabeçalho, rodapé, brasão, fontes, cores, margens) e **aplica** esses componentes nos documentos que o próprio sistema gera (TR, ETP, DFD, Edital, Contrato, etc.). O conteúdo (body) do arquivo enviado é **descartado** — não importa o que está escrito nele, importa apenas o "skin" institucional. **Como funciona tecnicamente:** | Formato | Como o sistema extrai | Como aplica | |---|---|---| | **DOCX** | Abre o ZIP e extrai `word/header*.xml`, `word/footer*.xml`, `word/media/` (brasão), `word/theme/theme1.xml` (cores e fontes), `word/styles.xml` (estilos). O `word/document.xml` (body) é descartado. | A cada documento gerado pela IA, monta novo DOCX usando os componentes extraídos como template e injeta o conteúdo no body | | **PDF** | Parser extrai imagens (brasão) e identifica áreas de texto recorrentes nas margens superior/inferior (cabeçalho/rodapé) | OU usa como overlay/background da página, ou recria o header/footer em DOCX a partir das áreas extraídas | **DOCX é o formato recomendado** porque a extração é determinística e reversível. PDF aceitamos como fallback (com perda de precisão). **Importante:** o arquivo enviado pode até ser um **DOCX vazio com apenas o papel timbrado**, ou um modelo qualquer do órgão cujo conteúdo será ignorado. Só interessa a identidade visual. **Múltiplos papéis timbrados:** órgãos grandes têm vários (Gabinete, Prefeitura, Câmara, Sec. Educação, Sec. Saúde, Procuradoria). Cada um com layout próprio. Sistema permite cadastrar vários e o usuário escolhe na geração; default = papel padrão do órgão. | # | Item | |---|---| | Q6.1 | **Upload de papel timbrado** em DOCX ou PDF | | Q6.2 | **Múltiplos papéis timbrados** por órgão (gabinete, secretaria X, secretaria Y) | | Q6.3 | **Extração dos componentes visuais** (cabeçalho, rodapé, brasão, fontes, cores, margens) — body do arquivo é descartado | | Q6.4 | **Detecção de placeholders dinâmicos** dentro do header/footer extraído (ex.: `{{cidade}}`, `{{ano}}`, `{{processo_numero}}`) | | Q6.5 | **Mapeamento de placeholders** para campos do sistema | | Q6.6 | **Aplicação do skin nos documentos gerados** — cada documento da IA recebe header/footer/fontes/brasão do papel timbrado | | Q6.7 | **Escolha do papel timbrado** no momento da geração (com default por unidade) | | Q6.8 | **Vinculação automática a unidade requisitante** — Secretaria de Saúde gera com timbre próprio | | Q6.9 | **Fonte do brasão por contexto:** papel timbrado do órgão (prioridade) → API `get-coat/{municipio}` (fallback) | | Q6.10 | **Pré-visualização** — renderiza um documento exemplo com o timbre extraído antes de salvar | | Q6.11 | **Versionamento** — quando o órgão atualiza o timbre, documentos antigos mantêm versão usada | | Q6.12 | **Validação no upload** (tamanho, dimensões, fontes embutidas, qualidade do brasão, presença de header/footer detectáveis) | **Tabelas sugeridas:** - `letterhead_templates` — papel timbrado (órgão × unidade × arquivo original × versão × default) - `letterhead_components` — componentes visuais extraídos (header xml, footer xml, brasão image, theme, styles) - `letterhead_placeholders` — placeholders detectados nos componentes (com mapeamento para campos) **Onde aparece no menu:** - `Administração → Configuração do Órgão → Papéis Timbrados` - Disponível também no `Acervo Institucional → Estrutura e Pessoas` (referência cruzada) #### Q.4 — Acervo Institucional do Órgão Upload e indexação semântica de documentos do próprio órgão que **contextualizam** toda a geração de documentos pela IA. Sem isso, a IA produz textos genéricos. Com isso, a IA passa a: - Validar dotação orçamentária (LOA/PPA tem rubrica para o objeto?) - Sugerir SRP quando o objeto se repete em contratos anteriores - Aplicar valores corretos de dispensa (do decreto local, não do federal padrão) - Identificar o agente correto (designações vigentes) - Detectar continuidade (PCA anterior previa e não foi feito?) - Evitar repetir erros apontados pelo TCE ao próprio órgão **Subseções do acervo (já refletidas no menu — Administração → Acervo Institucional):** | Subseção | Documentos | |---|---| | **Orçamento e Planejamento** | PPA (vigência 4 anos), LOA (por exercício), LDO (por exercício), PCA anterior + corrente | | **Histórico de Contratações** | Lista de contratos do exercício anterior e corrente *(já era Q.1)* | | **Marcos Regulatórios** | Decreto de Regulamentação da Lei 14.133 *(já era Q.2)*, Lei Orgânica do Município, Estatuto / Regimento Interno, decretos complementares | | **Estrutura e Pessoas** | Organograma, Portarias de Designação (ordenador, controle interno, agente de contratação, fiscal) | | **Políticas Internas** | Manual de Compras, Política de Sustentabilidade / Compras Verdes | | **Recomendações Externas** | Acórdãos e relatórios do TCE recebidos pelo órgão | | # | Item | |---|---| | Q4.1 | **Upload de PPA, LOA, LDO** com vigência por exercício | | Q4.2 | **Upload de PCA** (anterior + corrente) — distinto da lista de contratos efetivos | | Q4.3 | **Upload de Lei Orgânica, Estatuto/Regimento Interno** | | Q4.4 | **Upload de Decretos Complementares** (LGPD, processo eletrônico, transparência, etc.) | | Q4.5 | **Upload de Portarias de Designação** vigentes | | Q4.6 | **Upload de Manual de Compras e Políticas Internas** | | Q4.7 | **Upload de Acórdãos/Relatórios do TCE** recebidos pelo órgão | | Q4.8 | **Parse semântico** (PDF → texto, chunking ~500 tokens) — base já existe em `NormasInst` | | Q4.9 | **Embeddings vetoriais** dos chunks (ex.: `text-embedding-3-small` do OpenAI) | | Q4.10 | **Vector store** local (pgvector ou extensão MySQL, ou Pinecone/Qdrant externo) | | Q4.11 | **RAG no motor de geração** — busca semântica nos embeddings do acervo antes de chamar a IA. Injeta como contexto relevante | | Q4.12 | **Versionamento por exercício** (LOA 2025 ≠ LOA 2026) | | Q4.13 | **Painel do Acervo** com status (qual documento o órgão já enviou, validade) | | Q4.14 | **Alertas de atualização** (LOA do exercício novo está faltando) | | Q4.15 | **Reuso entre processos do mesmo órgão** — uma vez upado, alimenta todos | **Capacidade técnica nova:** RAG (Retrieval-Augmented Generation) — pré-requisito para Q4.9–Q4.11. Mesma infraestrutura serve para o Grupo N (Jurisprudência) — vale construir uma vez bem feito. **Tabelas sugeridas:** - `imported_contracts_raw` — staging da importação bruta - `imported_contracts` — contratos normalizados - `municipal_decree_templates` — templates de decreto/lei/portaria por base (CNM, ATRICON, customizado) - `municipal_decree_generations` — instâncias geradas com parâmetros do município - `onboarding_state` — progresso do wizard de onboarding por município - `institutional_documents` — documentos do acervo (tipo, vigência, anexo, status) - `institutional_document_chunks` — chunks com embeddings vetoriais ### Grupo T — Customização de Modelo dos Documentos Cada documento padrão do sistema (DFD, ETP, TR, Matriz de Risco, Pesquisa de Preços, Edital, Contrato, etc.) tem um **modelo padrão** com um conjunto de seções fixas. Esse grupo permite que o órgão **adicione ou remova seções** do modelo padrão conforme sua realidade, mantendo a conformidade legal mínima. | # | Item | |---|---| | T1 | **Adicionar nova seção** ao modelo padrão de um documento (com título, posição e conteúdo base) | | T2 | **Remover seção** do modelo padrão de um documento | | T3 | **Reordenar seções** (drag-and-drop) | | T4 | **Seções obrigatórias por lei** marcadas como **não-removíveis** — preserva conformidade (ex.: TR sem objeto, ETP sem estimativa de valor, contrato sem cláusulas mínimas do Art. 92 não passam) | | T5 | **Versionamento do template** — snapshot por data; documentos antigos mantêm a versão de template usada | | T6 | **Reset para o modelo Viva** (restauração de fábrica) | | T7 | **Pré-visualização** do template editado antes de salvar | | T8 | **Aplicação automática** aos próximos documentos gerados (documentos já criados não são afetados retroativamente) | **Tabelas sugeridas:** - `document_templates` — template por órgão × documento (DFD, ETP, TR, etc.) × versão - `document_template_sections` — seções (ordem, título, conteúdo base, flag obrigatória por lei, prompt da IA associado) **Onde aparece no menu:** - `Administração → Templates de Documentos` **Relação com o que já existe:** - O `FieldConfigurationController` (rotas `/prompts/*`) hoje permite editar **o prompt da IA por seção** de cada documento — capacidade entregue e funcional (ver "Capacidade existente — Gestão de Prompts por Seção" na seção 2). - O **Grupo T expande** essa capacidade para também permitir **mexer na estrutura** do documento — adicionar/remover/reordenar **as próprias seções**, não só editar o prompt delas. - O resultado é uma única tela de configuração por documento, com duas abas: **Estrutura** (seções — Grupo T) e **Prompts** (prompt da IA por seção — capacidade existente). **Padrão dual no menu (princípio arquitetural):** - Acesso 1 — direto pelo menu do documento (atalho prático: ao editar um TR, há atalho para "Configurar TR") - Acesso 2 — consolidado em `Administração → Templates de Documentos` (visão geral) - Mesma tela em ambos os caminhos. Mantém o padrão atual do sistema. --- **Vantagem comercial:** **Q1 (lista de contratos) é o "iceberg" do funil de aquisição** — qualquer prefeitura tem contratos antigos e quase nenhuma tem PCA estruturado. **Q2 (decreto) resolve um problema regulatório urgente**. **Q4 (acervo + RAG) é o diferencial técnico** — qualquer concorrente pode gerar TR; quase nenhum gera TR contextualizado pela LOA do órgão. Juntos, transformam o sistema em "regularização + planejamento + execução + gestão contextualizada". ### Grupo S — Integração com o PNCP (PRIORIDADE 1) Integração com o **Portal Nacional de Contratações Públicas** (`pncp.gov.br`), mantido pelo Ministério da Gestão em parceria com o TCU. A Lei 14.133/2021 torna a publicação no PNCP **obrigatória** (Art. 174) e estabelece **prazo de 10 dias úteis** para divulgação dos atos (Art. 94). Sem essa integração, o cliente fica em situação irregular — TCE pode glosar, MP pode acionar e o contrato pode ser considerado inválido. #### Fundamentos técnicos - **Documentação oficial:** `https://www.gov.br/pncp/pt-br` e `https://pncp.gov.br/api/pncp/v1` - **API de Consulta (pública):** `https://pncp.gov.br/api/consulta` — para ler contratações de outros órgãos - **API de Integração (autenticada):** publicar PCAs, editais, contratos, atas, aditivos, sanções - **Autenticação:** OAuth 2.0 + JWT (token tem validade curta, requer refresh) - **Identificação:** cada órgão é identificado pelo **CNPJ** cadastrado no PNCP - **Número de Controle PNCP:** retornado pela API a cada publicação; deve ser armazenado e referenciado em todos os documentos posteriores do mesmo processo #### Capacidades a implementar | # | Item | Base legal | |---|---|---| | S1 | **Cadastro e configuração do órgão no PNCP** (CNPJ, certificado digital A1/A3, ambientes homologação/produção) | Art. 174, §3º | | S2 | **Autenticação OAuth 2.0 + JWT** com refresh automático | API spec | | S3 | **Publicação de PCA** (Plano Anual de Contratações) | Art. 12, VII, §1º | | S4 | **Publicação de Aviso de Licitação** (edital) | Art. 54 + Art. 94 | | S5 | **Publicação de Atas da Sessão Pública** | Art. 60, III | | S6 | **Publicação de Resultados/Homologação** | Art. 71 + Art. 94 | | S7 | **Publicação de Contratos** | Art. 89 + Art. 94 | | S8 | **Publicação de Atas de Registro de Preços** | Arts. 82–87 | | S9 | **Publicação de Termos Aditivos** | Art. 124 + Art. 94 | | S10 | **Publicação de Apostilamento** | Art. 136 | | S11 | **Publicação de Sanções/Penalidades** | Arts. 155–163 | | S12 | **Publicação de Dispensa e Inexigibilidade** | Arts. 74–75 + Art. 94 | | S13 | **Consulta pública** (ler contratações de outros órgãos para inteligência/benchmark) | Art. 174 | | S14 | **Controle de prazo legal** (10 dias úteis — alertas e SLA) | Art. 94 | | S15 | **Repositório local de Números de Controle PNCP** | rastreabilidade | | S16 | **Recuperação de falhas** (retry exponencial, dead letter queue, alertas) | resiliência | | S17 | **Histórico de publicações com diff** | auditoria + LGPD | | S18 | **Suporte a ambiente de homologação** para testes antes da produção | boa prática | | S19 | **Painel de Conformidade PNCP** (publicações pendentes, atrasadas, com erro) | gestão | | S20 | **Webhook/notificação** quando uma contratação publicada é alterada externamente | sincronização | #### Tabelas sugeridas - `pncp_credentials` — config por órgão (CNPJ, ambiente, certificado, tokens) - `pncp_publications` — toda publicação feita: tipo, payload, status, número de controle PNCP, prazo legal, data efetiva - `pncp_consultations` — cache de consultas à API de consulta (para inteligência) - `pncp_failures` — log de erros, retry count, próxima tentativa #### Conecta com - **R (TR unificado)** — cada processo tem uma série de eventos PNCP a publicar; o desacoplamento R facilita esse mapeamento - **D (Fase de Seleção)** — Aviso, Ata da Sessão, Adjudicação, Homologação → publicar automaticamente - **I, J, K (Gestão)** — Contratos, Atas, Aditivos → publicar automaticamente - **G (Sanções)** — Penalidades → publicar automaticamente - **M (Controle Interno)** — checklist deve incluir "publicado no PNCP?" como item crítico - **P (Orquestração)** — fluxo deve disparar publicação automática nos pontos de transição **Vantagem comercial:** prefeituras que tentam publicar manualmente no PNCP gastam horas por processo e cometem erros. Integração automática vira **diferencial irrefutável**: o sistema gera o documento e publica no PNCP dentro do prazo, sem intervenção do usuário. ### Grupo U — Disputa, Auditoria e Controle Externo (Inovação de Ponta) Grupo dedicado a transformar o sistema em **plataforma de disputa e controle**, não só de geração de documentos. Cobre desde a sessão de pregão dentro do próprio sistema até auditoria automatizada por entes de controle externo (TCE/MP/CGU). Inovações de ponta (blockchain, ZKP, biometria, AI watchdog) usadas onde resolvem problema real, não como marketing. #### U.1 — Audit Cockpit (TCE / MP / CGU / Controladoria) Módulo dedicado para entes de controle externo acompanharem processos do órgão **em tempo real e somente leitura**. Resolve dor real dos dois lados — o TCE não precisa pedir cópia, o órgão não precisa enviar manualmente. | # | Item | |---|---| | U1.1 | **Login institucional** dedicado (CNPJ TCE/MP/CGU + papel do auditor) | | U1.2 | **Painel analítico** com filtros (contratos suspeitos, lances atípicos, fornecedores recorrentes, processos atrasados) | | U1.3 | **API stream** (WebSocket) para acompanhar sessões em curso | | U1.4 | **Regras de auditoria como código (Policy-as-Code)** — auditor escreve regra (ex.: "alertar quando lance < 60% do estimado") e sistema executa em todos os processos | | U1.5 | **Trilha de auditoria imutável** (log assinado + espelhamento em S3 object-lock ou IPFS) | | U1.6 | **Webhooks** para sistemas do TCE (SIAFI estaduais, e-TCE, e-Audit) | | U1.7 | **Relatórios de Conformidade** automatizados (semanal / mensal / por processo) | | U1.8 | **Painel de Atestos** — auditor pode marcar processos auditados sem irregularidade | **Modelo comercial extra:** vender módulo SaaS direto para TCEs como ferramenta de fiscalização. #### U.2 — Identidade Forte (Biometria + ICP-Brasil + Tokens de Credenciamento) Camadas combinadas de autenticação para participantes do certame. Mitiga fraude de identidade (compartilhamento de credenciais é problema real e subreportado). | # | Item | |---|---| | U2.1 | **Biometria facial ao vivo** no login + checagens aleatórias durante sessão (aproveita `django-faceid` já existente em `/var/www/html/django-faceid/`) | | U2.2 | **Anti-spoofing** (liveness detection — pisca, vire a cabeça) | | U2.3 | **Assinatura ICP-Brasil** obrigatória em cada lance/decisão (A1 ou A3) — validade jurídica plena MP 2.200-2/2001 | | U2.4 | **Token de credenciamento** após habilitação — contém identidade verificada, certidões válidas, status | | U2.5 | **Tokens reutilizáveis** em certames sucessivos do mesmo órgão (e potencialmente entre órgãos via federação) | | U2.6 | **Revogação** automática em caso de penalidade | | U2.7 | **Histórico de identidade** vinculado a CPF/CNPJ (sessões anteriores + biometrias capturadas) | **Vínculo com infra existente:** reaproveita o `django-faceid` parado em `:8001` — não é módulo do zero, é integração. #### U.3 — Sessão de Disputa com Imutabilidade (Hyperledger + ZKP) Sessão de pregão/disputa rodando sobre **blockchain permissionada** (Hyperledger Fabric) com smart contracts executando regras do certame + **Zero-Knowledge Proofs (ZKP)** para sigilo dos lances durante a fase de disputa. Acaba com a guerra de centavos. | # | Item | |---|---| | U3.1 | **Rede Hyperledger Fabric permissionada** — nós no órgão licitante, TCE, AGU, CGU | | U3.2 | **Smart contracts** executam regras do certame (lance > anterior em X%, validade temporal, etc.) | | U3.3 | **ZKP para lances criptografados** — smart contract valida regra sem revelar valor | | U3.4 | **Revelação progressiva** — somente os N melhores lances são revelados ao fim da fase | | U3.5 | **Imutabilidade** das atas e lances — qualquer alteração registrada como nova transação | | U3.6 | **Âncoras em chain pública** (Polygon, Ethereum) — checksums periódicos para auditabilidade externa adicional | | U3.7 | **Tokens NFT da sessão** — cada sessão gera um NFT representando a ata oficial, transferível entre nós | | U3.8 | **Sandbox de homologação** — TCE testa regras antes de produção | | U3.9 | **Piloto** com TCE parceiro antes de lançamento como produto | **Cautela:** complexidade técnica alta. Construir piloto antes de anunciar como produto final. #### U.4 — AI Watchdog de Conluio (detecção de comportamento anômalo) Modelo de ML que monitora padrões em tempo real e alerta o pregoeiro / Controle Interno / TCE. | # | Item | |---|---| | U4.1 | **Detecção de lances coordenados** (rodízio entre licitantes, divisão de mercado) | | U4.2 | **Detecção de cobertura artificial** (suposto concorrente que dá lances perdedores propositais) | | U4.3 | **Distribuição temporal suspeita** (intervalos atípicos entre lances) | | U4.4 | **Análise de rede** — fornecedores recorrentes em vários processos do mesmo órgão | | U4.5 | **Score de risco** por licitante / processo / sessão | | U4.6 | **Alertas em tempo real** ao pregoeiro durante a sessão | | U4.7 | **Histórico alimenta TCE** (vincula com U.1) | | U4.8 | **Treinamento contínuo** do modelo com dados anonimizados de PNCP + casos conhecidos | **Diferencial comercial:** dá manchete e diferencia competitivamente. #### U.5 — Transparência Cidadã (Livestream + Chat Público + Sync PNCP) Foco em participação cidadã durante o certame. Pura transparência, pouco código, alto impacto comunicacional. Reduz judicialização posterior. | # | Item | |---|---| | U5.1 | **Stream público** da sessão (sem cadastro) — qualquer cidadão acompanha | | U5.2 | **Chat público** com perguntas (leitura para externos, pregoeiro responde) | | U5.3 | **Notificações por e-mail/SMS** para inscritos no acompanhamento | | U5.4 | **Publicação automática no PNCP** a cada ato da sessão (vincula com Grupo S) | | U5.5 | **Embed do livestream** em portais municipais (transparência) | | U5.6 | **Acessibilidade** — closed captions, libras opcional (Decreto 9.296/2018) | | U5.7 | **Histórico público** das sessões anteriores (vídeo + ata + decisões) | **Tabelas sugeridas:** - `audit_cockpit_users` — auditores de controle externo - `audit_rules` — regras Policy-as-Code - `audit_findings` — alertas gerados - `identity_verifications` — registros biométricos e ICP-Brasil - `credentialing_tokens` — tokens de licitante - `dispute_sessions` — sessões de disputa - `blockchain_anchors` — checksums em chain pública - `conluio_alerts` — alertas do AI Watchdog - `livestream_sessions` — sessões transmitidas **Onde aparece no menu:** - `🔍 CONTROLE INTERNO E CONFORMIDADE → Audit Cockpit` (U.1) - `📄 DURANTE → Modalidades → Sessão de Disputa` (U.3) - `📄 DURANTE → Identidade dos Licitantes` (U.2) - `📤 TRANSPARÊNCIA → Livestream e Acompanhamento Cidadão` (U.5) - AI Watchdog (U.4) é camada transversal — alimenta U.1 e gera alertas durante U.3 **Conexões com outros grupos:** - **S (PNCP)** — sync automático a cada evento da sessão - **M (Controle Interno)** — checklists alimentadas pelos findings do Audit Cockpit - **G (Sanções)** — alertas do AI Watchdog podem disparar abertura de processo de sanção - **N (Jurisprudência)** — findings cruzados com boletins do TCU/TCEs - **R (TR unificado)** — `ProcessoContratacao` recebe campos de status de disputa, identidade, conluio score - **F (Pareceres)** — Controle Interno gera parecer derivado de findings **Recomendação estratégica:** Implementar nesta ordem (prioridade decrescente): 1. **U.1 (Audit Cockpit)** — implementação factível em meses, abre mercado novo (TCEs), não exige tecnologia experimental 2. **U.2 (Identidade Forte)** — reusa `django-faceid` existente + ICP-Brasil; quick win com alto impacto 3. **U.5 (Transparência Cidadã)** — pouco código, alto impacto reputacional 4. **U.4 (AI Watchdog)** — exige base de dados e treinamento; viável após U.1 estar coletando dados 5. **U.3 (Hyperledger + ZKP)** — pesquisa-piloto antes; construir como diferencial estratégico de médio prazo ### Grupo W — Bases Públicas e Integrações Externas Conectores reutilizáveis para bases públicas oficiais que enriquecem o processo de contratação (validação de fornecedor, pesquisa de preços, certidões, classificação, contexto socioeconômico). Cada conector tem cache local, fallback gracioso, e indicação de origem da informação no documento gerado (transparência). #### W.1 — Catálogos e Classificação | # | Base | Órgão | Item | |---|---|---|---| | W1.1 | **CATSER** | MGI / Comprasnet | Catálogo de serviços (complementa o CATMAT já usado) | | W1.2 | **CATMAT** *(já usado)* | MGI / Comprasnet | Catálogo de materiais — manter integração | | W1.3 | **CNAE** | IBGE / Receita Federal | Classificação Nacional de Atividades Econômicas (cruza com objeto) | | W1.4 | **NCM** | Receita Federal | Nomenclatura Comum do Mercosul (produtos) | | W1.5 | **CBO** | MTE | Classificação Brasileira de Ocupações (serviços terceirizados) | | W1.6 | **Busca unificada** | — | Consulta cross-catálogo a partir de descrição livre do objeto | #### W.2 — Fornecedores e Idoneidade | # | Base | Órgão | Item | |---|---|---|---| | W2.1 | **SICAF** | MGI | Cadastramento Unificado de Fornecedores (habilitação federal) | | W2.2 | **CEIS** | CGU | Cadastro Nacional de Empresas Inidôneas e Suspensas | | W2.3 | **CNEP** | CGU | Cadastro Nacional de Empresas Punidas (Lei Anticorrupção) | | W2.4 | **CEPIM** | CGU | Cadastro de Entidades Privadas Sem Fins Lucrativos Impedidas | | W2.5 | **Lista de Inidôneos TCU** | TCU | Inidoneidade declarada pelo TCU | | W2.6 | **Listas de TCEs locais** | TCEs estaduais | Sancionados localmente (variável por UF) | | W2.7 | **Bloqueio automático na habilitação** | — | Consulta às 5 bases acima e impede prosseguimento se houver match | | W2.8 | **Painel de alerta de novas sanções** | — | Quando um fornecedor de contrato vigente é sancionado em qualquer base, alerta gerado | #### W.3 — Preços de Referência | # | Base | Órgão | Item | |---|---|---|---| | W3.1 | **Painel de Preços** | MGI / Comprasnet | Preços praticados em contratações federais | | W3.2 | **Banco de Preços do TCU** | TCU | Preços referenciais para contratações | | W3.3 | **SINAPI** | Caixa / IBGE | Custos da construção civil (obras), atualização mensal | | W3.4 | **SICRO** | DNIT | Custos de obras rodoviárias | | W3.5 | **FIPE** | USP | Preços de veículos (frota) | | W3.6 | **CEASAs** | CEASAs estaduais | Hortifrutigranjeiros (merenda escolar) | | W3.7 | **CMED** *(já usado)* | Anvisa | Preços máximos de medicamentos — manter integração | | W3.8 | **Pesquisa de Preços automática** | — | Composição automática da pesquisa (Art. 23) a partir de 3+ fontes | #### W.4 — Certidões e Regularidade Fiscal | # | Base | Órgão | Item | |---|---|---|---| | W4.1 | **CND Federal** | Receita Federal | Certidão Negativa de Débitos federal (consulta automática) | | W4.2 | **CRF (FGTS)** | Caixa | Certificado de Regularidade do FGTS | | W4.3 | **CNDT** | TST | Certidão Negativa de Débitos Trabalhistas | | W4.4 | **CND Estadual** | Receitas Estaduais | Regularidade ICMS (variável por UF) | | W4.5 | **CND Municipal** | Receitas Municipais | Regularidade ISS (variável) | | W4.6 | **Receita Federal — CNPJ** | RF | Status, atividades, sócios (via BrasilAPI ou similar) | | W4.7 | **Status Simples Nacional** | RF | Optante / data de opção (afeta tributação) | | W4.8 | **Monitoramento contínuo** | — | Reconsulta periódica de certidões dos fornecedores em contratos vigentes | #### W.5 — Contexto Socioeconômico | # | Base | Órgão | Item | |---|---|---|---| | W5.1 | **IBGE — Cidades** | IBGE | População, PIB, IDH, dados do município (alimenta o RAG do Acervo) | | W5.2 | **IPCA / INPC** | IBGE | Reajustes contratuais anuais (Art. 124) | | W5.3 | **IGP-M** | FGV | Índice alternativo para reajuste | | W5.4 | **Selic / CDI** | Banco Central | Atualização monetária | | W5.5 | **Reajuste automático de contratos** | — | Aplica IPCA/INPC nos contratos vigentes na data-base (vincula com K) | #### W.6 — Bases Setoriais | # | Base | Órgão | Item | |---|---|---|---| | W6.1 | **Anvisa — Produtos** | Anvisa | Produtos regulados (saúde) | | W6.2 | **ANP — Combustíveis** | ANP | Preços e fornecedores (frota) | | W6.3 | **DataSUS** | Min. Saúde | Dados de saúde (compras de saúde) | | W6.4 | **INEP — Censo Escolar** | MEC | Dados escolares (compras de educação) | | W6.5 | **MAPA — Insumos Agrícolas** | MAPA | Compras agropecuárias | | W6.6 | **Pareceres AGU** | AGU | Pareceres referenciais (vincula com Grupo N) | **Tabelas sugeridas:** - `external_data_sources` — bases configuradas (URL, credenciais, cache TTL) - `external_data_cache` — cache local com expiração - `external_data_consultations` — log de cada consulta para auditoria - `supplier_sanctions` — sanções agregadas (CEIS + CNEP + CEPIM + TCU + TCEs) por CNPJ - `supplier_certifications` — certidões consolidadas por CNPJ com expiração **Conexões com outros grupos:** - **N** (Jurisprudência) — Pareceres AGU + súmulas STF/STJ entram aqui também - **S** (PNCP) — PNCP fica como já planejado; W consome dados que PNCP agrega - **K** (Aditivos) — IPCA/INPC alimentam reajustes (K5) - **I** (Gestão de Contratos) — certidões monitoradas continuamente (W4.8) - **Q.4** (Acervo Institucional) — IBGE Cidades enriquece contexto do órgão para RAG - **D** (Fase de Seleção) — bloqueio automático na habilitação (W2.7) - **C/F** (Pesquisa de Preços) — composição automática (W3.8) **Onde aparece no menu:** - `⚙️ Administração → Bases Públicas e Integrações` (config de cada base, status, tokens) - `🧠 Inteligência → Consulta Cruzada` (consulta agregada às bases para um objeto/fornecedor) - Consumo das bases acontece dentro dos fluxos relevantes (pesquisa de preços, habilitação, gestão de contratos) — não exige usuário ir até as bases **Priorização sugerida** (impacto × esforço): 1. **W.2** (Fornecedores e Idoneidade) — alto impacto regulatório, baixo esforço (APIs CGU consolidadas) 2. **W.4** (Certidões) — alto impacto operacional (automatiza tarefa manual repetitiva) 3. **W.3** (Preços) — alimenta pesquisa de preços do Art. 23 (junto com S do PNCP) 4. **W.1** (Catálogos) — fecha catálogo de objetos 5. **W.5** (Contexto) — alimenta o RAG do Acervo 6. **W.6** (Setoriais) — implementar sob demanda do cliente **Vantagem comercial:** órgãos que tentam consultar essas bases manualmente gastam horas e cometem erros. Integração automática + cache + monitoramento contínuo vira diferencial — especialmente W2.7 (bloqueio automático de fornecedor inidôneo) e W4.8 (alerta de certidão vencida em contrato vigente). ### Grupo X — Analytics, Estatísticas e Inteligência Operacional Sistema deixa de ser apenas "gerador + gestão" e passa a ser **inteligência ativa** sobre o processo. KPIs, alertas proativos, comparativos cross-órgão (alimentados pelo PNCP — Grupo S), previsão e benchmarking. Cada órgão vira mais eficiente porque o sistema sabe **o que está saindo do padrão**. #### X.A — Pipeline e Calendário | # | Item | |---|---| | XA.1 | **Funil de processos** por estágio (DFD em construção → ETP em revisão → ... → Concluído) | | XA.2 | **Gargalos identificados** — em qual etapa os processos ficam mais tempo parados | | XA.3 | **Tempo médio por etapa** com benchmark contra outros órgãos do mesmo porte | | XA.4 | **Calendário consolidado** (vencimentos de contratos + atas + certidões + cronograma do PCA + datas legais) | | XA.5 | **Cumprimento do PCA** — % executado, planejado, atrasado | #### X.B — Riscos e Conformidade | # | Item | |---|---| | XB.1 | **Score de conformidade do órgão** (baseado nas checklists do Grupo M) | | XB.2 | **Mapa de calor de riscos** por categoria de contratação | | XB.3 | **Aderência ao PCA** — contratou o que estava planejado? | | XB.4 | **Alertas de qualidade** — processos sem pesquisa de preço, sem ETP completo, sem matriz de risco | | XB.5 | **Histórico de impugnações** por modalidade (taxa, tempo médio, motivos) | | XB.6 | **Taxa de retorno** — processos que voltam para correção e em qual etapa | #### X.C — Inteligência de Preços (cross-órgão via PNCP) | # | Item | |---|---| | XC.1 | **Comparativo "preço pago vs mercado"** — preço do certame vs média/mediana de municípios similares (porte + região + mesmo objeto) | | XC.2 | **Top fornecedores** para um objeto no estado/região (vencedores em outros municípios) | | XC.3 | **Mapa geográfico de vencedores** — concentração regional | | XC.4 | **Detecção de outlier** — "este TR ficou 40% acima da média de municípios do mesmo porte" | | XC.5 | **Sugestão de fornecedores** baseada em sucesso em municípios similares | | XC.6 | **Histórico de performance de fornecedores** (entrega no prazo, glosas, sanções) | | XC.7 | **Detecção de fornecedor fantasma** — registrado em N municípios mas sem atividade econômica condizente | #### X.D — Eficiência Operacional | # | Item | |---|---| | XD.1 | **Tempo médio do processo completo** (DFD até homologação) por modalidade | | XD.2 | **Comparativo "antes/depois" do sistema** — quanto tempo se economiza vs processo manual | | XD.3 | **Custo médio por processo** (horas-pessoa, servidor envolvido) | | XD.4 | **Taxa de aproveitamento da IA** — % de conteúdo gerado mantido sem alteração após revisão humana | | XD.5 | **Produtividade por agente** (processos por mês por agente de contratação) | #### X.E — Alertas Inteligentes (proativos) | # | Item | |---|---| | XE.1 | **Vencimento de contrato em 90 dias** — sugere iniciar novo processo | | XE.2 | **Ata atingiu 80% do saldo** — sugere replanejamento | | XE.3 | **Certidão de fornecedor vencendo em 30 dias** | | XE.4 | **Fornecedor sancionado em outro município** — alerta em processo em curso (cruza com W.2) | | XE.5 | **TCE publicou novo entendimento** sobre tipo de contratação ativa (cruza com Grupo N) | | XE.6 | **N processos similares concluídos** — considerar SRP | | XE.7 | **Outlier de preço** — "este TR é X% mais caro que objeto similar em município próximo" | | XE.8 | **Inatividade** — "processo P sem atualização há 15 dias" | | XE.9 | **PCA não iniciado** — "contratação prevista até [data] não foi iniciada" | #### X.F — ESG e Sustentabilidade | # | Item | |---|---| | XF.1 | **Indicador de descarbonização** (corrige o `DescarbonizacaoCommand` quebrado) | | XF.2 | **% de contratações sustentáveis** (com critérios ambientais — Arts. 5º e 11) | | XF.3 | **Diversidade de fornecedores** — % ME/EPP, mulheres, pretos (incentivos legais) | | XF.4 | **Local sourcing** — % comprado de fornecedores locais | | XF.5 | **Pegada hídrica/energética** de contratações específicas | #### X.G — Aprendizado Cruzado (Recomendação) | # | Item | |---|---| | XG.1 | **"Outros municípios deste porte usaram esta especificação"** — biblioteca de TRs reutilizáveis | | XG.2 | **"Quem comprou X também comprou Y"** — recomendação combinada | | XG.3 | **"Esta dispensa foi questionada no TCE em outros casos"** — alerta preventivo (cruza com Grupo N) | | XG.4 | **Padrões de especificação reaproveitáveis** entre órgãos parceiros (consórcios, compras conjuntas) | #### X.H — Painéis por Papel Não são KPIs adicionais — é como os dados acima são apresentados, por perfil de usuário (vincula com Premissa 12.7). | # | Painel | Foco | |---|---|---| | XH.1 | **Prefeito / Secretário** | Visão estratégica: gastou × planejou, % sustentável, top categorias | | XH.2 | **Controle Interno** | Score de conformidade, processos críticos, achados | | XH.3 | **Procuradoria** | Pareceres pendentes, prazos legais | | XH.4 | **Pregoeiro** | Sessões na agenda, performance histórica, taxa de êxito | | XH.5 | **Cidadão** (via portal público) | Onde meu dinheiro vai, em tempo real (cruza com U.5) | | XH.6 | **Viva (Mantenedor)** | Telemetria de uso por órgão, qualidade da IA, satisfação | #### X.I — Visão Preditiva (com IA) | # | Item | |---|---| | XI.1 | **Previsão de demanda futura** baseada em histórico (complementa Q.1) | | XI.2 | **Previsão de risco de impugnação** baseada em padrões históricos | | XI.3 | **Previsão de tempo de processo** ("este TR provavelmente levará 45 dias") | | XI.4 | **Recomendação automática de modalidade** baseada em valor + objeto | #### X.J — Indicadores Externos Relevantes | # | Item | |---|---| | XJ.1 | **IPCA acumulado** vs reajustes contratuais aplicados (cruza com W.5) | | XJ.2 | **Sazonalidade** — mês de mais contratações por categoria | | XJ.3 | **Concentração de mercado** — top 3 fornecedores capturam X% das contratações em categoria Y | **Tabelas sugeridas:** - `analytics_snapshots` — snapshots diários/semanais de KPIs - `analytics_alerts` — alertas gerados, status, destinatário, ack - `analytics_benchmarks` — benchmarks cross-órgão (PNCP source) - `analytics_predictions` — previsões da IA (com confidence) - `analytics_dashboards` — configuração de dashboards por papel **Conexões com outros grupos:** - **S (PNCP)** — fonte primária para comparativos cross-órgão (XC) - **N (Jurisprudência)** — alimenta alertas XE.5 e XG.3 - **M (Controle Interno)** — alimenta XB (score de conformidade) - **I, J, K (Gestão)** — alimentam XA, XE - **W (Bases Públicas)** — alimenta XE.4, XJ - **Q (Acervo)** — RAG do acervo enriquece análises contextuais **Onde aparece no menu:** - Visível conforme **Premissa 12.7** (Visões Hierárquicas): cada perfil vê seu painel correspondente - `🏛️ Painel → Dashboard` (consolidado para o perfil do usuário) - `🏛️ Painel → Alertas e Notificações` (XE) - `🧠 Inteligência → Benchmarks cross-órgão` (XC) - `🧠 Inteligência → Previsões` (XI) **Vantagem competitiva:** com S (PNCP), W (Bases), M (Conformidade), N (Jurisprudência), o sistema acumula dados que **outros concorrentes não têm**. Cada novo cliente alimenta a base agregada (com anonimização). Cria efeito de rede — quanto mais municípios usam, melhores ficam os benchmarks. --- ## 4. Decisões pendentes antes da implementação 1. **Parecer Jurídico (F1)**: módulo novo do zero, aproveita o `LegalBasis`, ou ambos coexistem? 2. **Parecer do Controle Interno e Resposta à Impugnação**: hoje só existem na Inexigibilidade. Generalizar para Pregão, Concorrência, Dispensa, etc. (vincular com checklist M). 3. **FaceTrading**: nome sugere reconhecimento facial mas `docName='Termo de Referência'`. É TR para Pregão Presencial? Esclarecer. 4. **Reconhecimento Facial (assinatura)**: integração entre Laravel e Django (`django-faceid` em :8001) — confirmar fluxo end-to-end. 5. **Descarbonização**: command quebrado (`auth()->user()` em CLI). Corrigir. 6. **Reequilíbrio Contratual**: lógica multicritério real ou só rótulo no `docName`? Corrigir bug do brasão. 7. **Gestão (item 15 do card)**: criar painel unificado de contratos/atas/licitantes (Grupo I) — confirmado. 8. **Checklist M**: aceitar modelos próprios de cada TCE (M6) ou padronizar uma versão única adaptável? --- 8. **Renomear `Venda`/`vendas` → `Teste`/`testes` (dívida nomenclatural):** o wizard é predominantemente uma ferramenta de TESTE/exploração; só uma minoria converte em venda. Decisão tomada em 2026-06-08: **defer** para uma Onda futura (provavelmente quando o v1 for sunset). Caminho recomendado quando endereçar: Strangler Fig (criar tabela `testes` para o v2, manter `vendas` em paralelo para o v1, migrar 6 linhas v2, drop `vendas` quando v1 morrer). ## 5. Padrão de implementação sugerido Cada documento novo deve seguir o padrão InfyOm Laravel Generator já usado no projeto: - `app/{Nome}.php` (Model) - `app/Http/Controllers/{Nome}Controller.php` (Controller CRUD) - `app/Jobs/Generate{Nome}PdfJob.php` (geração assíncrona) - `resources/views/{nome}/` (create.blade.php, edit.blade.php, index.blade.php, pdf_view.blade.php, show.blade.php) - `database/migrations/YYYY_MM_DD_HHMMSS_create_{nome}_table.php` - `routes/web.php` (rotas CRUD) - `resources/views/layouts/menu.blade.php` (entrada no menu) - Prompts da IA gerenciáveis via `FieldConfigurationController` (padrão atual: `/prompts/{nome}`) - Integração com brasão via `https://sistemadenegocios.com.br/get-coat/{municipio}` (com timeout e fallback) - Substituição correta dos placeholders `[BRASAO]`, `[CIDADE]`, `[ENDERECO]` --- ## 6. Limpeza realizada (estado atual) Em 2026-06-08: - Removidos arquivos do módulo `farmer` (Model, Controller, Views, Factory, Seeder, Migration) - Tabela `farmers` dropada (estava com 0 registros) - Rotas `/farmer/*` removidas (linhas 706–715 de `routes/web.php`) - Blocos comentados removidos do `menu.blade.php` (farmer + avaliacaoTerapeutica/morbidades/profissionais + avaliacoes/power_breath/dourado/relatorio_mensal) - Menu: de 873 → 811 linhas --- ## 7. Estado de timezone (referência) | Camada | Configuração | |---|---| | SO | `America/Sao_Paulo` | | Cron | reiniciado em BRT | | MySQL global/session | `-03:00` (persistido em `/etc/mysql/conf.d/timezone.cnf`) | | Laravel/PHP | `America/Sao_Paulo` | --- ## 8. Gate de bloqueio do wizard público `validateVenda($venda)` em `ProcessMatrizJob` e `HomeController` (regra duplicada): - Bloqueia se `count(vendas WHERE email = ?) > 10` - Bloqueia se `count(vendas WHERE nome = ?) > 10` - Bloqueia se `count(vendas WHERE municipio = ?) > 10` - Quando bloqueado: envia template `mail_limit_exceeded` e renderiza `blocked_wizard_email` com WhatsApp `(71)99290-6255` - Critérios não usados: IP, cidade do IP, telefone --- ## 9. Sumário do roadmap | Grupo | Tema | Itens | |---|---|---| | **R** | **Unificação do TR e Reforma do Modelo de Dados (PRIORIDADE 0)** | **13** | | **S** | **Integração com o PNCP (PRIORIDADE 1)** | **20** | | A | Modalidades faltantes | 3 | | B | Procedimentos Auxiliares | 3 | | C | Fase Preparatória (peças faltantes) | 2 | | D | Fase de Seleção | 6 | | E | Fase Contratual (avulsos — promovidos para I/K) | 7 | | F | Pareceres | 3 | | G | Sanções | 3 | | H | Planejamento Pré-Licitação | 8 | | I | Gestão de Contratos | 7 | | J | Gestão de Atas | 4 | | K | Gestão de Aditivos | 5 | | L | Transparência e Accountability (L1 → ver Grupo S) | 4 | | M | Controle Interno (checklists) | 7 | | N | Inteligência Jurisprudencial / Ingestão Externa | 7 | | O | Humanização e Qualidade de Texto | 10 | | P | Orquestração da Construção do Processo | 10 | | Q | Bootstrap Institucional, Acervo, Designação de Papéis, Identidade Visual e Regulamentação Local | 56 | | T | Customização de Modelo dos Documentos (adicionar/remover seções) | 8 | | **U** | **Disputa, Auditoria e Controle Externo (Inovação de Ponta)** | **39** | | **W** | **Bases Públicas e Integrações Externas** | **41** | | **X** | **Analytics, Estatísticas e Inteligência Operacional** | **54** | | **Total** | | **~310 entregas** | --- ## 10. Plano de Execução Sequencial — do core para fora Analogia de camadas concêntricas: o **TR** é o núcleo do produto. Cada camada adiciona valor mas depende da anterior estar consolidada. A ordem abaixo é o roteiro completo de implementação. ``` ┌───────────────────────────┐ │ Camada 11 — Bootstrap │ (Q) │ ┌─────────────────────┐ │ │ │ Camada 10 — Transv.│ │ (O, P) │ │ ┌───────────────┐ │ │ │ │ │ Camada 9 — │ │ │ (N) │ │ │ Inteligência │ │ │ │ │ │ ┌─────────┐ │ │ │ │ │ │ │Cam.8— │ │ │ │ (S, L) │ │ │ │Transp. │ │ │ │ │ │ │ │ ┌─────┐ │ │ │ │ │ │ │ │ │Cam.7│ │ │ │ │ (H) │ │ │ │ │Plan.│ │ │ │ │ │ │ │ │ │Pré │ │ │ │ │ │ │ │ │ │┌───┐│ │ │ │ │ │ │ │ │ ││Cam││ │ │ │ │ (G) │ │ │ │ ││6 ││ │ │ │ │ │ │ │ │ ││Sanç│ │ │ │ │ │ │ │ │ │└┬──┘│ │ │ │ │ │ │ │ │ │┌▼──┐│ │ │ │ │ (I, J, K) │ │ │ │ ││C5 ││ │ │ │ │ │ │ │ │ ││Pós││ │ │ │ │ │ │ │ │ ││┌─┐││ │ │ │ │ │ │ │ │ │││4│││ │ │ │ │ (D) │ │ │ │ │││Sel│ │ │ │ │ │ │ │ │ ││└┬┘││ │ │ │ │ │ │ │ │ │└┬┴─┘│ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ (F, M) │ │ │ │ │ C3 │ │ │ │ │ │ │ │ │ │Par./Ctl│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ (B + C) │ │ │ │ │ C2 │ │ │ │ │ │ │ │ │ │Aux │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ (A) │ │ │ │ │ C1 │ │ │ │ │ │ │ │ │ │Mod │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ ← CORE (R) — TR │ │ │ │ │ TR │ │ │ │ │ (1º doc gerado │ │ │ │ │ ▲ │ │ │ │ │ a partir do │ │ │ │ │ │ │ │ │ │ │ OBJETO/DEMANDA) │ │ │ │ │OBJ │ │ │ │ │ ← GATILHO (12.5) │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ │ │ │ │ │Limp│ │ │ │ │ ← FASE 0 │ │ │ │ └────┘ │ │ │ │ ... ``` ### FASE 0 — Limpeza e Sanidade (PRIMEIRO) Antes de construir mais, remover lixo. Reduz risco e custo de cada fase seguinte. | # | Intervenção | Status | |---|---|---| | 0.1 | Remover módulo `farmer` (Model, Controller, Views, Factory, Seeder, Migration) | ✅ feito | | 0.2 | Dropar tabela `farmers` | ✅ feito | | 0.3 | Remover rotas `/farmer/*` | ✅ feito | | 0.4 | Limpar blocos comentados do `menu.blade.php` (avaliacaoTerapeutica, morbidades, profissionais, avaliacoes, power_breath, dourado, relatorio_mensal) | ✅ feito | | 0.5 | Remover Command `cachetest.php` (lixo de debug) | pendente | | 0.6 | Corrigir Command `DescarbonizacaoCommand.php` (usa `auth()->user()` em CLI → null) | pendente | | 0.7 | Remover SendGrid API key comentada em `SendEmails.php` (segredo exposto em código) | pendente | | 0.8 | Reescrever `CheckGunicornServer.php` (faz `shell_exec` sem checar se já roda) | pendente | | 0.9 | Resolver duplicação de `validateVenda()` entre `ProcessMatrizJob` e `HomeController` | pendente | | 0.10 | Mover `today-wizard-tests.txt` para fora de `public/` ou bloquear via `.htaccess` | pendente (vazamento de PII confirmado) | | 0.11 | Remover BCC oculto `abdulsamadmalik8741@gmail.com` em `SendExpiryMail.php` | pendente | | 0.12 | Investigar `/etc/apache2/sites-available/1` e `/root/1` (JWT exposto) | pendente | | 0.13 | Remover comentários gigantes com código morto em `SendEmails.php`, `Autocomplete*Job.php` | pendente | | 0.14 | Validar que `HomeController.php` (>1500 linhas) precisa ser segmentado | pendente | | 0.15 | Mover Adminer (`public/adminer.php`) para fora de `public/` ou proteger por IP | pendente | ### FASE 1 — Core: Unificação do TR (Grupo R, prioridade 0) Reformar o núcleo. Sem isso, todas as fases seguintes vão duplicar trabalho por modalidade. | # | Intervenção | |---|---| | 1.1 | Criar Model único `TermoDeReferencia` (renomear `SamplePage`) | | 1.2 | Criar `ProcessoContratacao` como entidade central com campo `modalidade` | | 1.3 | Migrar dados de `FaceTrading`, `Competition`, `BiddingWaiver`, `Unenforceability` para `TermoDeReferencia` | | 1.4 | Mapear campos divergentes entre os Models antigos | | 1.5 | Apagar `Invitation` (modalidade Convite, revogada) | | 1.6 | Apagar `PriceTake` (modalidade Tomada de Preços, revogada) | | 1.7 | Unificar prompts: `/prompts/{modalidade}` → `/prompts/tr` parametrizado | | 1.8 | Atualizar jobs `Autocomplete2/3/5Job` e `ProcessMatrizJob` | | 1.9 | Consolidar views e CRUDs | | 1.10 | Atualizar menu lateral (remover entradas por modalidade) | | 1.11 | Atualizar rotas | | 1.12 | Migração SQL com staging + checksum + rollback | | 1.13 | Edital permanece com variações por modalidade (correto, manter) | ### FASE 2 — Camada 1: Modalidades de Licitação faltantes (Grupo A) | # | Intervenção | Art. | |---|---|---| | 2.1 | **Diálogo Competitivo** (modalidade nova da 14.133) | 32 | | 2.2 | **Concurso** | 30 | | 2.3 | **Leilão** | 31 | ### FASE 3 — Camada 2: Procedimentos Auxiliares (Grupo B) + Documentos da Preparatória (Grupo C) | # | Intervenção | Art. | |---|---|---| | 3.1 | **Credenciamento** | 79 | | 3.2 | **Pré-qualificação** | 80 | | 3.3 | **PMI** (Procedimento de Manifestação de Interesse) | 81 | | 3.4 | **Projeto Executivo** (distinto de Projeto Básico) | 6º, XXVI | | 3.5 | **Programa de Integridade** (contratos de grande vulto) | 25, §4º | ### FASE 4 — Camada 3: Pareceres + Controle Interno (Grupos F e M) Estes andam juntos: o Parecer do Controle Interno é derivado das checklists. | # | Intervenção | Art. | |---|---|---| | 4.1 | **Parecer Jurídico** como módulo próprio | 53 | | 4.2 | **Parecer Técnico** | 18 | | 4.3 | **Parecer do Controle Interno** generalizado (não só Inexigibilidade) | 169 | | 4.4 | Templates de checklist por modalidade (CRUD admin) | M1 | | 4.5 | Preenchimento da checklist por processo | M2 | | 4.6 | Geração do Parecer do Controle Interno a partir da checklist | M3 | | 4.7 | Painel de Conformidade | M4 | | 4.8 | Bloqueio de avanço em não-conformidade crítica | M5 | | 4.9 | Integração com modelos do TCE local | M6 | | 4.10 | Histórico/auditoria das respostas | M7 | ### FASE 5 — Camada 4: Fase de Seleção (Grupo D) | # | Intervenção | Art. | |---|---|---| | 5.1 | **Aviso de Licitação** | 54 | | 5.2 | **Ata da Sessão Pública** | 60, III | | 5.3 | **Termo de Adjudicação** | 71 | | 5.4 | **Termo de Homologação** | 71 | | 5.5 | **Decisão sobre Recurso** | 165 | | 5.6 | **Decisão sobre Impugnação** generalizada | 24 | ### FASE 6 — Camada 5: Pós-Contratual (Grupos I, J, K) Gestão completa do que foi contratado. | # | Intervenção | Art. | |---|---|---| | 6.1 | Painel de Gestão de Contratos (I1) | 117 | | 6.2 | Designação de Fiscal/Gestor (I2) | 117 | | 6.3 | Relatório de Fiscalização (I3) | 117 | | 6.4 | Termo de Recebimento Provisório/Definitivo (I4) | 140 | | 6.5 | Controle de Garantia Contratual (I5) | 96–102 | | 6.6 | Avaliação de Desempenho do Contratado (I6) | 144 | | 6.7 | Calendário de Vencimentos (I7) | — | | 6.8 | Painel de Gestão de Atas com saldo/quantitativo (J1) | 82–87 | | 6.9 | Adesão e Carona (J2) | 86 | | 6.10 | Replanejamento de quantitativos (J3) | 85 | | 6.11 | Republicação trimestral (J4) | 85, §1º | | 6.12 | Termo Aditivo (K1) | 124 | | 6.13 | Controle dos limites cumulativos 25%/50% (K2) | 125 | | 6.14 | Apostilamento (K3) | 136 | | 6.15 | Termo de Rescisão (K4) | 137–139 | | 6.16 | Reequilíbrio Econômico-Financeiro refinado (K5) | 124, II | ### FASE 7 — Camada 6: Sanções (Grupo G) | # | Intervenção | Art. | |---|---|---| | 7.1 | Processo de Sanção Administrativa | 155–163 | | 7.2 | Auto de Infração | 158 | | 7.3 | Defesa Prévia / Contraditório | 158 | ### FASE 8 — Camada 7: Planejamento Pré-Licitação (Grupo H) | # | Intervenção | |---|---| | 8.1 | PLS — Plano de Logística Sustentável | | 8.2 | Diagnóstico Institucional / Inventário de Demandas | | 8.3 | Banco Histórico de Preços | | 8.4 | Catálogo Local de Itens | | 8.5 | Mapeamento de Fornecedores Locais (ME/EPP) | | 8.6 | Audiência / Consulta Pública | | 8.7 | Plano de Capacitação dos Agentes de Contratação | | 8.8 | Mapa de Riscos Institucional | ### FASE 9 — Camada 8: Transparência e PNCP (Grupos S e L) PNCP é obrigatório por lei, mas tecnicamente depende dos documentos gerados nas fases anteriores. | # | Intervenção | |---|---| | 9.1 | Cadastro do órgão no PNCP (S1) | | 9.2 | Autenticação OAuth 2.0 + JWT (S2) | | 9.3 | Publicação automática do PCA (S3) | | 9.4 | Publicação do Aviso de Licitação (S4) | | 9.5 | Publicação da Ata da Sessão (S5) | | 9.6 | Publicação do Resultado/Homologação (S6) | | 9.7 | Publicação de Contratos (S7) | | 9.8 | Publicação de Atas SRP (S8) | | 9.9 | Publicação de Aditivos (S9) | | 9.10 | Publicação de Apostilamento (S10) | | 9.11 | Publicação de Sanções (S11) | | 9.12 | Publicação de Dispensa/Inexigibilidade (S12) | | 9.13 | Consulta pública (S13) | | 9.14 | Controle de prazo legal — 10 dias úteis (S14) | | 9.15 | Repositório local de Números de Controle (S15) | | 9.16 | Recuperação de falhas (S16) | | 9.17 | Histórico com diff (S17) | | 9.18 | Ambiente de homologação (S18) | | 9.19 | Painel de Conformidade PNCP (S19) | | 9.20 | Webhook para alterações externas (S20) | | 9.21 | Portal da Transparência automatizado (L2) | | 9.22 | Relatórios LAI (L3) | | 9.23 | LGPD — gestão dos dados coletados (L4) | ### FASE 10 — Camada 9: Inteligência Externa (Grupo N) | # | Intervenção | |---|---| | 10.1 | Crawler periódico TCU | | 10.2 | Crawler periódico TCEs (configurável por UF) | | 10.3 | Parsing e classificação | | 10.4 | Notificação de novos entendimentos | | 10.5 | API interna para alimentar LegalBasis e motor de geração | | 10.6 | Versionamento de boletins | | 10.7 | Agendamento via Laravel Scheduler | ### FASE 11 — Camada 10: Camadas Transversais (Grupos O e P) | # | Intervenção | |---|---| | 11.1 | Remoção de travessão `—` (O1) | | 11.2 | Aspas curvas para retas (O2) | | 11.3 | Remoção de muletas de IA (O3) | | 11.4 | Voz ativa preferencial (O4) | | 11.5 | Padronização AO 1990 (O5) | | 11.6 | Conformidade jurídico-administrativa (O6) | | 11.7 | Verificação de tom institucional (O7) | | 11.8 | Score de humanidade opcional (O8) | | 11.9 | Verificação de duplicação (O9) | | 11.10 | Templates regionais (O10) | | 11.11 | Ordem canônica por modalidade (P1) | | 11.12 | Mapa de dependências entre docs (P2) | | 11.13 | Bloqueio de avanço sem o anterior aprovado (P3) | | 11.14 | Pré-preenchimento automático (P4) | | 11.15 | Recálculo em cascata (P5) | | 11.16 | Linha do tempo do processo (P6) | | 11.17 | Identificação do agente em cada etapa (P7) | | 11.18 | Diferentes ordens por modalidade (P8) | | 11.19 | Reaproveitamento controlado (P9) | | 11.20 | Versionamento de cada peça (P10) | ### FASE 12 — Camada 11: Bootstrap Institucional (Grupo Q) | # | Intervenção | |---|---| | 12.1 | Importação de lista de contratos (CSV/XLSX/PDF/PNCP) | | 12.2 | Normalização e classificação | | 12.3 | Inferência de demandas recorrentes | | 12.4 | Geração automática do PCA a partir do histórico | | 12.5 | Sugestões de melhoria | | 12.6 | Painel de cobertura | | 12.7 | Wizard de configuração do município | | 12.8 | Geração do Decreto de Regulamentação | | 12.9 | Customização de pontos chave | | 12.10 | Versionamento por exercício | | 12.11 | Modelos alternativos (Lei, Resolução, Portaria, Manual) | | 12.12 | Banco de decretos publicados | | 12.13 | Wizard de onboarding | | 12.14 | Cadastro inicial de fornecedores | | 12.15 | Timbre/brasão/papel timbrado | | 12.16 | Designação inicial dos agentes | | 12.17 | Templates por porte | --- --- ## 11. Princípio de Organização do Menu **Diretriz arquitetural:** o menu lateral é o **mapa do ciclo de vida** da contratação. Sua organização espelha a ordem do processo licitatório — antes, durante e depois — e cada entrega do roadmap (Grupos R, A a S) preenche a seção correspondente do menu, não é adicionada ao fim do arquivo. Hoje o `menu.blade.php` tem ~811 linhas com itens misturados sem ordenação semântica. À medida que o roadmap avança, o menu evolui para a estrutura proposta abaixo. ### Estrutura-alvo do menu ``` 🏛️ PAINEL ├─ Dashboard (filtrado por perfil — Premissa 12.7) ├─ Calendário de Vencimentos (consolidado: contratos + atas + certidões + PCA) ├─ Alertas e Notificações (proativos — Grupo X.E) └─ Indicadores 📁 MEUS PROCESSOS / OUTROS / ARQUIVADOS ├─ Meus Processos (created_by = usuário logado) ├─ Processos da Equipe (mesmo órgão, criados por outros — RBAC) └─ Processos Arquivados (encerrados, anulados, cancelados, rescindidos) Cada processo abre como TIMELINE + ÁRVORE de documentos: Processo X — Pregão Eletrônico — Status: Em execução ├─ DFD ✓ aprovado ├─ ETP ✓ aprovado ├─ TR ✓ aprovado ├─ Matriz Risco ✓ aprovado ├─ Pesquisa ✓ aprovado ├─ Edital ⏳ em revisão jurídica ├─ Ata Sessão — pendente └─ Contrato — pendente 🗓️ ANTES — Pré-Licitação (Planejamento) ├─ Plano Anual de Contratações (PCA) ├─ Plano de Logística Sustentável (PLS) ├─ Diagnóstico Institucional ├─ Banco Histórico de Preços ├─ Catálogo Local de Itens ├─ Mapeamento de Fornecedores (ME/EPP) ├─ Audiência / Consulta Pública ├─ Plano de Capacitação └─ Mapa de Riscos Institucional 📄 DURANTE — Licitação (Processo) ├─ Processos em Andamento ├─ Documentos Preparatórios │ ├─ DFD · ETP · TR · Projeto Básico │ ├─ Anteprojeto · Projeto Executivo │ ├─ Matriz de Risco │ └─ Pesquisa de Preços ├─ Modalidades de Licitação │ ├─ Pregão · Concorrência · Concurso · Leilão · Diálogo Competitivo │ └─ Sessão de Disputa (Hyperledger + ZKP, com AI Watchdog) ├─ Identidade dos Licitantes │ ├─ Biometria Facial (Faceid) │ ├─ Certificados ICP-Brasil │ └─ Tokens de Credenciamento ├─ Contratação Direta │ └─ Dispensa · Inexigibilidade ├─ Procedimentos Auxiliares │ └─ Credenciamento · Pré-qualificação · PMI · SRP · Registro Cadastral ├─ Fase de Seleção │ ├─ Edital · Aviso de Licitação │ ├─ Ata da Sessão Pública │ ├─ Decisão sobre Impugnação · Decisão sobre Recurso │ └─ Adjudicação · Homologação └─ Pareceres └─ Jurídico · Controle Interno · Técnico 📋 DEPOIS — Pós-Licitação (Gestão Contratual) ├─ Contratos │ ├─ Lista e Painel │ ├─ Designação de Fiscal/Gestor │ ├─ Relatório de Fiscalização │ ├─ Recebimento Provisório/Definitivo │ ├─ Garantia Contratual │ └─ Avaliação de Desempenho ├─ Atas de Registro de Preços │ ├─ Lista e Saldo │ ├─ Adesão e Carona │ └─ Replanejamento ├─ Aditivos e Alterações │ ├─ Termo Aditivo (+ controle 25%/50%) │ ├─ Apostilamento │ ├─ Rescisão │ └─ Reequilíbrio Econômico-Financeiro ├─ Sanções │ └─ Processo · Auto de Infração · Defesa Prévia └─ Licitantes / Fornecedores 🔍 CONTROLE INTERNO E CONFORMIDADE (transversal) ├─ Checklists por Modalidade ├─ Painel de Conformidade ├─ Auditoria └─ Audit Cockpit (TCE/MP/CGU/Controladoria — login dedicado) 📤 TRANSPARÊNCIA (transversal) ├─ Integração PNCP ├─ Portal da Transparência ├─ LAI └─ Livestream e Acompanhamento Cidadão 🧠 INTELIGÊNCIA (transversal) ├─ Jurisprudência (TCU/TCEs) ├─ Fundamentação Jurídica ├─ Banco de Decisões ├─ Consulta Cruzada às Bases Públicas (W) ├─ Benchmarks Cross-Órgão (X.C — preço pago vs mercado, top fornecedores) ├─ Previsões (X.I — demanda, risco, tempo, modalidade) └─ Recomendações (X.G — quem comprou X também comprou Y) ⚙️ ADMINISTRAÇÃO ├─ Configuração do Órgão │ └─ Papéis Timbrados (DOCX / PDF, com múltiplas variantes por unidade) ├─ Acervo Institucional (alimenta a IA por RAG) │ ├─ Orçamento e Planejamento (PPA · LOA · LDO · PCA) │ ├─ Histórico de Contratações (lista por exercício) │ ├─ Marcos Regulatórios (Decreto 14.133 · Lei Orgânica · Regimento) │ ├─ Estrutura e Pessoas (Organograma · Portarias de Designação) │ ├─ Políticas Internas (Manual de Compras · Sustentabilidade) │ └─ Recomendações do TCE ├─ Papéis e Designações (Art. 8º) │ ├─ Designações Vigentes │ ├─ Histórico de Designações │ ├─ Portarias Geradas │ └─ Regras de Segregação de Funções ├─ Onboarding ├─ Templates de Documentos ├─ Bases Públicas e Integrações (W — config de cada base e tokens) └─ Usuários e Permissões (RBAC) ``` ### Mapeamento Grupo → Seção do menu | Grupo do roadmap | Vai preencher | |---|---| | **R** — Unificação do TR | Cria `ProcessoContratacao` → habilita MEUS / OUTROS / ARQUIVADOS. Reduz itens duplicados em "Documentos Preparatórios" e "Modalidades" | | **A** — Modalidades faltantes | DURANTE → Modalidades de Licitação | | **B** — Procedimentos Auxiliares | DURANTE → Procedimentos Auxiliares | | **C** — Fase Preparatória | DURANTE → Documentos Preparatórios | | **D** — Fase de Seleção | DURANTE → Fase de Seleção | | **F** — Pareceres | DURANTE → Pareceres | | **G** — Sanções | DEPOIS → Sanções | | **H** — Planejamento Pré-Licitação | ANTES (toda a seção) | | **I** — Gestão de Contratos | DEPOIS → Contratos | | **J** — Gestão de Atas | DEPOIS → Atas de Registro de Preços | | **K** — Gestão de Aditivos | DEPOIS → Aditivos e Alterações | | **L + S** — Transparência e PNCP | TRANSPARÊNCIA (transversal) | | **M** — Controle Interno | CONTROLE INTERNO (transversal) | | **N** — Inteligência Jurisprudencial | INTELIGÊNCIA (transversal) | | **O** — Humanização | Não vai ao menu (camada de pós-processamento) | | **P** — Orquestração | MEUS PROCESSOS → Timeline e árvore de cada processo | | **Q** — Bootstrap Institucional | ADMINISTRAÇÃO (+ conversão lead → cadastro) | | **(premissa contínua)** | Wizard `/wizard/create` permanece fora do menu autenticado, como porta pública | ### Regras de execução 1. **Toda entrega de um grupo deve atualizar o `menu.blade.php` na seção certa** — não no fim do arquivo. 2. **Após o Grupo R**, eliminar do menu os itens correspondentes aos Models extintos (`Invitation`, `PriceTake`) e consolidar os 5 TRs por modalidade em "TR" único. 3. **Camadas transversais** (Controle Interno, Transparência, Inteligência) ficam no menu como seções independentes — não duplicar dentro das fases. 4. **Ícones consistentes** por seção: 🏛️ Painel, 🗓️ Antes, 📄 Durante, 📋 Depois, 🔍 Controle, 📤 Transparência, 🧠 Inteligência, ⚙️ Administração. 5. **Permissões por papel** (RBAC) ficam transversais ao menu — agente de contratação, fiscal, controle interno, pregoeiro veem apenas as seções relevantes. 6. **Padrão dual de acesso para cada documento licitatório** — capacidade existente que se mantém: - **Menu operacional** do documento (em DURANTE/DEPOIS, conforme o caso) — CRUD do documento - **Configuração** do documento (em Administração → Templates de Documentos) — gerencia estrutura (Grupo T) + prompts da IA por seção (`FieldConfigurationController`) - Atalho da tela operacional do documento abre a tela de configuração correspondente, evitando navegação extra para admins. ### Por que essa ordem funciona - Reflete o **fluxo mental do servidor público**: "preciso planejar → preciso licitar → preciso gerir". - Cada grupo do roadmap sabe **onde** sua entrega aparece — decisão arquitetural pronta. - Reduz **carga cognitiva**: usuário não precisa procurar onde está cada coisa. - Facilita **onboarding** de novos usuários e clientes. - Diferencia o produto de painéis InfyOm genéricos com menu plano. --- ## 12. Premissas de Produto (não-negociáveis) Antes de qualquer entrega do roadmap, essas premissas definem o que o Sistema de TR **é**. Toda nova funcionalidade deve respeitá-las. ### 12.1 Wizard público (`/wizard/create`) — top of funnel comercial **Premissa:** o wizard externo é ferramenta comercial fundamental e **permanece** mesmo após todas as evoluções do roadmap. Sem cadastro, gratuito, gera amostra real, captura lead, alimenta a equipe de vendas. **O que permanece:** - 4 passos no mesmo formato visual - Geração de DFD, ETP, TR, Matriz, Pesquisa via IA - Envio por e-mail dos documentos prontos - Gate de bloqueio `>10` por email/nome/município → converte uso intensivo em lead WhatsApp - Captura de `nome, email, phone, município, instituição, objeto` na `vendas` table **O que evolui (sem comprometer a essência):** - Pré-visualização do documento antes de enviar - "Salve este processo" → gatilho de conversão (lead → cadastro → área autenticada) - Variantes por persona (Vereador, Gestor, Servidor) — mesmo fluxo, copy diferente - Métricas de funil (taxa de conclusão por passo, abandono, conversão) - Geração de mais documentos (Edital, Contrato, Parecer Jurídico) como prévia limitada - Aplicação da humanização (Grupo O) na saída **O que o Grupo R muda internamente:** - O wizard hoje grava em 5 Models distintos (`SamplePage`, `FaceTrading`, etc.). Após R, grava no `TermoDeReferencia` único + `ProcessoContratacao` com `modalidade` apropriada. - Interface externa **não muda**. É melhoria invisível para o lead. ### 12.2 Área autenticada — processo como árvore **Premissa:** o produto autenticado é **organizado por processo**, não por documento avulso. Cada processo é uma **árvore** com seus respectivos documentos em ordem de construção. Esta organização é a espinha dorsal do produto. **Estrutura de menu autenticada (Meus / Outros / Arquivados):** | Filtro | Critério | |---|---| | **Meus Processos** | `processo.created_by = usuário_logado` | | **Processos da Equipe** | `processo.órgão = órgão_usuário AND created_by ≠ usuário_logado` (RBAC) | | **Processos Arquivados** | `processo.status ∈ {concluído, cancelado, anulado, rescindido}` | **Cada processo abre como:** - **Timeline visual** (Grupo P6) — sequência das etapas com status - **Árvore de documentos** — DFD, ETP, TR, Matriz, Pesquisa, Edital, Atas, Contrato, Aditivos, etc., na ordem canônica da modalidade - **Status por documento** — pendente · em construção · em revisão · aprovado · publicado (PNCP) - **Identificação do agente** em cada etapa (Grupo P7, segregação de funções, Art. 8º) - **Comentários e histórico** por documento ### 12.3 Conversão lead → cadastro **Premissa:** o wizard externo gera leads anônimos (registros em `vendas`). A jornada natural é: lead testa → recebe documentos por e-mail → cria conta → seu processo aparece em "Meus Processos" como ponto de partida formal. **Fluxo:** ``` ANÔNIMO → CADASTRO → AUTENTICADO wizard/create (formulário ou /home com (grava em vendas) OAuth) "Meus Processos" [processo do wizard já populado] ``` **Entrega associada:** parte do Grupo Q (Bootstrap Institucional), subseção "conversão de lead". ### 12.4 RBAC — papéis e permissões **Premissa:** segregação de funções (Art. 8º da Lei 14.133) precisa ser refletida nos papéis do sistema. Não basta "usuário admin". Os papéis típicos: | Papel | Vê / Faz | |---|---| | **Requisitante** | Cria DFD, acompanha processos próprios | | **Agente de Contratação** | Conduz processo: ETP, TR, Pesquisa, Edital, Sessão | | **Parecerista Jurídico** | Lê processos, emite parecer jurídico | | **Controle Interno** | Lê processos, preenche checklist, emite parecer (Grupo M) | | **Fiscal de Contrato** | Vê apenas contratos onde é fiscal (Grupo I2) | | **Gestor de Contrato** | Vê apenas contratos onde é gestor | | **Pregoeiro** | Conduz sessão de pregão | | **Ordenador de Despesas** | Homologa e adjudica | | **Admin** | Configurações do órgão, RBAC, integrações | **Entrega associada:** parte da Administração (Grupo Q3) + transversal a todos os módulos. ### 12.5 Objeto (ou demanda) como gatilho central da geração **Premissa fundamental — define a lógica de geração do sistema:** Toda a cascata de documentos do processo deriva de um único insumo: o **objeto** da contratação (descrição do que se pretende contratar). Alternativamente, o usuário pode informar a **demanda** (descrição da necessidade que originou a contratação), e a IA converte automaticamente em objeto, geralmente começando com **"Contratação de empresa para…"**. ``` ┌─────────────────────────────────┐ │ OBJETO ou DEMANDA │ ← input universal │ (campo único de entrada) │ └────────────────┬────────────────┘ │ IA processa, normaliza, expande │ ┌────────────────▼────────────────┐ │ Cascata de geração: │ │ DFD → ETP → TR → Matriz → │ │ Pesquisa → Edital → Contrato → │ │ Aditivos → ... │ └─────────────────────────────────┘ ``` **Implicações para todos os grupos do roadmap:** - **Grupo R (TR unificado):** `ProcessoContratacao` tem **`objeto` como atributo principal**, não o TR. O TR é uma das saídas da cascata. - **Grupo P (Orquestração):** o disparador da timeline é a definição do objeto. Toda revisão do objeto pode disparar recálculo em cascata dos documentos derivados. - **Grupo T (Templates):** cada template/seção recebe o objeto como variável universal de contexto. - **Grupo Q.4 (Acervo + RAG):** a busca semântica no acervo institucional usa o objeto como query base. - **Grupo N (Jurisprudência):** boletins relevantes ao objeto são recuperados via RAG. - **Grupo M (Checklist):** itens da checklist podem variar conforme a natureza do objeto (obra, serviço, bem, TI). **Onde isso já existe no código:** - O wizard (`Venda.php::thirdStepSubmit`) já implementa: recebe o objeto, e se a IA detecta que tem <5 ou >50 palavras, reescreve via OpenAI normalizando o início para "Contratação de empresa para…". - A coluna `objeto` em `vendas` é a porta de entrada. - `TextoInteligente` consolida o objeto + cascata de documentos relacionados. **Implicações de UX:** - Em "Meus Processos / Outros / Arquivados", **cada processo é representado pelo objeto** (nome/título do processo = objeto truncado). - Editar o objeto em um processo já iniciado precisa de fluxo controlado — quais documentos invalidar? Quais regenerar? Linha do tempo de mudanças do objeto preservada. **Salvaguarda:** a edição do objeto após documentos terem sido aprovados não deve apagar o histórico nem afetar versões publicadas. Mudanças no objeto geram nova versão do processo, não substituem a anterior. ### 12.6 Multi-órgão (multi-tenancy) **Premissa:** um usuário pode pertencer a um ou mais órgãos. Cada órgão tem seu próprio decreto, brasão, agentes, processos. Processos não vazam entre órgãos. **Implicações técnicas:** - Toda tabela com escopo de órgão precisa de `orgao_id` (ou tenant_id) - Queries Eloquent passam por `Scope` global de órgão atual - Login pode selecionar órgão (se usuário pertence a mais de um) - Onboarding (Grupo Q3) cria o órgão antes do primeiro processo ### 12.7 Visões Hierárquicas — Fabricante × Cliente **Premissa fundamental:** o sistema tem **muitos menus na visão do fabricante (Viva)**, mas precisa ser **extremamente simples na visão do cliente**. A complexidade do produto serve à manutenção/configuração — não deve ser imposta ao servidor público que só quer fazer seu processo. Três perfis de visualização, com menus que retraem hierarquicamente: | Perfil | O que vê | Como aparece o menu | |---|---|---| | **Mantenedor (Viva)** | Tudo, inclusive configurações globais, prompts de IA por seção, telemetria, suporte | Menu completo (todas as seções A–X) | | **Admin do Órgão** | Parametrização do órgão (Acervo, Decreto, Designações, Papel Timbrado, Templates, RBAC interno) + **todos os Processos do órgão** + Painéis (Grupo X) | Menu enxuto: Painel · Processos · Configurações do Órgão · Analytics | | **Usuário Comum** | **Meus Processos** + processos onde é interveniente (fiscal, parecerista, pregoeiro) + Calendário + Notificações | Menu mínimo: Meus Processos · Calendário · Notificações | **Regras operacionais:** 1. **Menus retraem por perfil** — `menu.blade.php` renderiza condicionalmente (`@if(auth()->user()->canSee('admin'))...`) 2. **RBAC** (Grupo Q.5) ganha 3 nós de "perfil de visualização" **além** dos papéis funcionais (Fiscal, Pregoeiro, etc.). Um usuário pode ter perfil "Usuário Comum" + papel funcional "Fiscal de Contrato". 3. **Mantenedor pode personificar** — "ver como Admin do órgão X" / "ver como Usuário Comum" para suporte e QA. Log de personificação registrado. 4. **Acesso administrativo é exceção** — usuários comuns nunca veem Acervo, Decreto, Designações, Prompts de IA, etc. 5. **Painéis (Grupo X) são filtrados por perfil** — Prefeito vê painel estratégico; Pregoeiro vê painel operacional; Cidadão (em portal público) vê transparência. **Implicação para o roadmap:** - Todo grupo do roadmap (R, A–X) deve declarar qual perfil vê quais itens - A Seção 11 (Estrutura do Menu) é a **visão completa** (Mantenedor). As visões retraídas derivam dela - Premissa precede implementação dos Grupos M, Q.5 e X (que se beneficiam diretamente) **Por que isso é estratégico:** - Reduz **carga cognitiva** do servidor público (curva de adoção rápida) - Diferencia o sistema de **InfyOm cru** (que mostra tudo a todos) - Cria **espaço para complexidade** (a Viva pode evoluir muito sem assustar o cliente) - Onboarding mais simples = vendas mais fáceis ### 12.8 Validação Contínua via Wizard (regression test base) **Premissa fundamental — disciplina de qualidade:** a cada alteração relevante no sistema (especialmente nas que tocam Models de TR, jobs de geração, prompts de IA, schema do banco, fluxo do wizard ou integrações externas), é **obrigatório** validar o sistema através do **wizard público `/wizard/create`** em modo end-to-end, antes de considerar a mudança concluída. **Por que o wizard é a base dos testes:** - O wizard exercita o **fluxo crítico do produto** (DFD → ETP → TR → Matriz → Pesquisa → envio de e-mail) - Toca quase todas as camadas (Livewire, validação, banco, IA externa, jobs assíncronos, e-mail, brasão remoto, gates de bloqueio) - Reproduz a experiência real do cliente final (top of funnel) - Falha cedo se algum campo crítico foi removido ou se o processamento foi alterado **Procedimento padrão de teste (checklist):** 1. **Passo 1** — preencher nome, email (único, com timestamp), telefone 2. **Passo 2** — preencher município (deve existir em `cities`), instituição, endereço 3. **Passo 3** — preencher objeto (entre 5 e 50 palavras, ou disparar a reescrita por IA) 4. **Passo 4** — aguardar e validar: - Insert na tabela `vendas` correto (todos os campos preenchidos) - `GenerationQueue` recebeu entradas para cada documento esperado - Jobs `Autocomplete3 / 5 / 2 / 4` enfileirados - Polling de `/get-generated-files` retorna os documentos com status correto - E-mail enviado (ou registrado no log) com assunto `[SisTR] Documento criado` - Nenhum erro no `storage/logs/laravel.log` 5. **Sanidade adicional:** - Gate `WizardGate::isAllowed` retornou `true` (ou `false` esperado se for cenário de bloqueio) - `today-wizard-tests.txt` NÃO foi criado (verificar que se manteve removido) - API `/api/wizard-leads` retornou o lead novo via cursor **Modo programático (sem UI):** Como o componente Livewire é difícil de scriptar, o caminho prático é simular o que `Venda::thirdStepSubmit()` faz: inserir um lead na tabela `vendas` com timestamp único + disparar manualmente o `autocomplete5` para encadear os jobs. Esse padrão foi usado e validado na simulação que fizemos quando substituímos o `today-wizard-tests.txt` pela API `/api/wizard-leads`. **Quando aplicar:** - ❗ Sempre após mudanças em: Models de TR, `Venda.php`, `HomeController::autocomplete*`, `ProcessMatrizJob`, jobs `Autocomplete*Job`, schema do banco em tabelas tocadas pelo wizard - ❗ Sempre após remoção de Models ou colunas - ❗ Após mudanças em prompts da IA dos documentos gerados pelo wizard - ❗ Após mudanças em integrações externas (`get-coat/`, `precos.sistemadenegocios`, OpenAI/Claude) - Recomendado: incluir o lead de teste com email contendo `+regression-` no padrão para fácil identificação e limpeza posterior **Limpeza pós-teste:** - Apagar o lead de teste do banco (pode ser via `DELETE FROM vendas WHERE id = ?`) - Apagar `texto_inteligente`, `GenerationQueue`, demais artefatos criados (ou marcar com flag de teste) **Evolução futura:** - Estender o procedimento para a tela **Meus Processos** quando estiver implementada (Grupo R + Premissa 12.2): submeter processo completo via área autenticada e validar cascata de geração - Automatizar como **suíte de testes regression** rodando em CI/CD antes de deploy --- ### Observações estratégicas - **OBJETO/DEMANDA é o gatilho central** (Premissa 12.5) — todo o sistema gira em torno desse input universal. Qualquer refactor (Grupos R, P, T, Q.4) deve preservar essa lógica e tratá-lo como atributo principal de `ProcessoContratacao`, não como atributo do TR. - **R (unificação do TR) é prioridade 0** — pré-requisito de A, F, M, P, Q. Hoje o sistema tem 5 Models de TR por modalidade (resíduo da Lei 8.666/93) + 2 Models de modalidades revogadas (`Invitation`, `PriceTake`). Conformar isso com a 14.133 é a primeira fundação. - **S (PNCP) é prioridade 1** — **obrigatório por lei** (Arts. 94 e 174), com prazo de 10 dias úteis. Sem integração, o cliente público fica em situação irregular: TCE pode glosar, MP pode acionar, e contratos podem ser anulados. Hoje o sistema **não publica nada** no PNCP. É diferencial comercial irrefutável quando entregue. - **M (checklists)** é o que distingue ferramenta de geração de ferramenta de **conformidade**. Diferencial comercial enorme. - **I, J, K (painéis de gestão)** é o que faz o produto deixar de ser "gerador" e virar **plataforma**. Diferencial comercial. - **N (jurisprudência)** reduz dependência da API externa `precos.sistemadenegocios` e dá vantagem competitiva real (base própria e atualizada). - **O (humanização)** ataca o "cheiro de IA" que prejudica adoção em órgãos com revisores conservadores. - **P (orquestração)** é o que faz o produto crescer de "gerador unitário" para **fluxo de processo** — mudança qualitativa. - **Q (bootstrap + acervo)** é a **porta de entrada do funil** + **diferencial técnico**: lista de contratos vira PCA (Q1), decreto regulariza o órgão (Q2), **Acervo Institucional (Q4) com RAG contextualiza toda a geração da IA pela realidade do órgão** — concorrentes geram TR genérico, esse sistema gera TR alinhado com a LOA, PCA e decretos do órgão. - **L4 (LGPD)** é risco jurídico real para a Viva (vazamento de PII em `today-wizard-tests.txt`, BCC oculto, JSON com JWT em `/etc/apache2/sites-available/1`). - **U (Disputa + Controle Externo)** é a fronteira de inovação do produto. **U.1 (Audit Cockpit)** abre mercado novo (vender direto para TCEs). **U.2 (Identidade Forte)** reusa `django-faceid` parado. **U.3 (Hyperledger + ZKP)** é diferencial de manchete — começar como piloto-pesquisa, não anunciar como produto sem maturidade. **U.4 (AI Watchdog)** e **U.5 (Transparência Cidadã)** são ganhos paralelos. - **W (Bases Públicas)** é o conjunto de **conectores reutilizáveis** que automatiza tarefas hoje manuais e abre janelas de inteligência. **W.2 (Idoneidade)** e **W.4 (Certidões)** são as prioridades imediatas — automatizam tarefas repetitivas e evitam contratação irregular de fornecedor sancionado. - **X (Analytics)** transforma o produto em **inteligência ativa** sobre o processo. **X.C (Inteligência de Preços cross-órgão)** + **X.E (Alertas proativos)** são os diferenciais comerciais mais visíveis — exigem S (PNCP) e W (Bases) como prérrequisitos. Quanto mais clientes usam, melhores ficam os benchmarks (efeito de rede). - **Premissa 12.7 (Visões Hierárquicas)** é a diretriz que separa **complexidade da Viva** da **simplicidade do cliente**. Todo grupo deve declarar qual perfil vê quais itens; a Seção 11 (Menu) é a visão Mantenedor — as outras derivam. --- _Fim do documento_