Arquitetura Modular

ENGiOS é organizado em dez módulos oficiais. A taxonomia dá ao site público e à aplicação autenticada um vocabulário único de produto.

Por que módulos existem

Operações de engenharia são amplas o suficiente para que um portal indiferenciado fique vago rapidamente. Módulos mantêm o sistema compreensível: cada módulo tem propósito, capacidades governadas, áreas operacionais relacionadas e não objetivos explícitos.

Taxonomia oficial de módulos

Os módulos oficiais são ENGiOS Core, ENGiOS Commercial, ENGiOS Engineering, ENGiOS Knowledge, ENGiOS Content, ENGiOS Reporting, ENGiOS AI Studio, ENGiOS Portal, ENGiOS Inbox e ENGiOS Social.

Como áreas operacionais mapeiam para módulos

Áreas comerciais como CRM e propostas pertencem a Commercial. Projetos, documentos, PMO, RFIs e lições pertencem a Engineering. Biblioteca, busca semântica e recuperação assistida por chat pertencem a Knowledge. Campanhas, ativos de publicação e governança editorial pertencem a Content e Social conforme o trabalho seja produção de ativos ou coordenação de canais.

Como módulos evoluem

Cada módulo pode começar como narrativa pública, ganhar documentação operacional e depois se conectar ao comportamento autenticado. A documentação deve sempre marcar se uma capacidade está ativa, planejada ou intencionalmente fora do escopo.

Postura de integração

Esta fundação não publica detalhe interno de runtime. Ela documenta fronteiras de produto e mantém integrações futuras claras: autenticação, serviços backend, sincronização de dados, runtime de IA e portal do cliente seguem como superfícies controladas de implementação.

Detalhe público vs interno

Docs públicas devem descrever capacidade, governança e valor operacional. Docs internas podem carregar inventários de rotas, detalhes de schema, comandos de infraestrutura, procedimentos de segredo e matrizes de teste. O site público não deve misturar esses níveis.