# Logiccom ## Conexão host: localhost port: 3306 database: logiccom password: ## Estrutura - back/: PHP + Composer - front/: Vue 3 + Vite ## Ambiente Frontend utiliza: VITE_API_URL_BASE VITE_GOOGLE_CLIENT_ID VITE_GOOGLE_REDIRECT_URI Backend é executado localmente via Devilbox. ## Regras - Não alterar regras de negócio sem solicitação explícita. - Não alterar rotas existentes. - Não alterar estrutura do banco sem aprovação. - Manter compatibilidade com Devilbox. - Sempre executar npm run build após alterações no frontend. - Sempre executar composer install quando alterar dependências PHP. - Corrigir erros de lint e build antes de finalizar uma tarefa. ## Padrões do projeto - Vue 3 - Vite - PHP - MySQL - Bootstrap 5 ## Fluxo Antes de finalizar qualquer tarefa: 1. Rodar build do frontend mas de forma opcional, sempre peça uma confirmação. 2. Verificar imports quebrados. 3. Não criar dependências desnecessárias. 4. Não remover código legado sem autorização. # Layout de Telas As telas devem seguir um padrão de layout consistente, utilizando os componentes e estilos definidos no projeto. Toda tela nova que terá CRUD deve ter uma estrutura padrão 1 - Sempre vai ter duas telas, uma de listagem e outra de cadastro/edição. 2 - A tela de listagem deve conter filtros, tabela e paginação. 3 - A tela de listagem deve sempre usar datatable para exibir os dados. 4 - A tela de cadastro/edição deve conter formulário com validação. 5 - Na listagem sempre deve conter a opção de exportar os dados para CSV e PDF. 6 - Na listagem sempre deve conter em cada linha da tabela a opção de editar e excluir o registro porém em forma de ícones. 7 - Os arquivos de listagem e cadastro/edição devem estar na mesma pasta, com nomes padronizados, por exemplo: listagem.vue e cadastro.vue. 8 - Os formulários devem ser componentizados para que esse cadastro possa ser usado em outras telas, caso necessário. 9 - Sobre os filtros na tela, nunca deve ficar sempre exposto, sempre deve ter um botão para abrir e fechar os filtros, para não poluir a tela. 10 - O filtro deve ficar em um Componente de Dialog, que deve ser aberto ao clicar no botão de filtros. 11 - O Botão de filtros deve ficar sempre no canto superior direito da tela, próximo do botão de exportar e deve conter um ícone de filtro. 12 - Todos os botões de ação devem ter ícones apenas e um tooltip com a descrição da ação. 13 - A paginação do datatable deve funcionar pelo backend, garantindo que apenas os dados necessários sejam carregados. 14 - Filtros devem ser enviados para o backend para que a listagem seja filtrada corretamente. 15 - Campos de status sempre devem ser exibidos como toggle/switch no sistema. 16 - Campos de telefone sempre devem usar mascara no sistema. 17 - Toggles/switches em formularios devem ficar sempre abaixo dos inputs/selects, nunca ao lado deles. Quando houver mais de um toggle no mesmo formulario, eles devem ficar lado a lado entre si, em uma linha propria abaixo dos campos. 18 - Inputs e selects de formularios devem ocupar a largura total disponivel quando nao houver uma necessidade clara de compor campos relacionados na mesma linha. 19 - Listagens nao devem exibir toggles/switches para campos booleanos/status. Em tabelas, esses campos devem ser exibidos como texto ou badge, pois switch em listagem sugere acao interativa. 20 - Campos monetarios devem usar input de moeda com mascara/formato pt-BR e BRL, nunca input numerico simples. ## Linguagem das interfaces - Todo texto visível ao usuário deve usar linguagem simples, direta e compreensível para pessoas sem conhecimento técnico. - Mensagens, alertas, validações, estados de carregamento, tooltips e confirmações não devem mencionar detalhes internos como API, endpoint, payload, HTTP, backend, banco de dados, integração, stack trace ou nomes de serviços. - O feedback deve explicar o que aconteceu e, quando necessário, qual ação o usuário pode tomar. - Termos próprios do trabalho do usuário, como NCM, CFOP, NFC-e e certificado digital, podem ser usados quando forem necessários para identificar o campo ou a operação. - Detalhes técnicos devem ficar restritos a logs seguros e documentação destinada aos desenvolvedores. Todas as telas devem ser responsivas e compatíveis com dispositivos móveis. Todas as telas devem seguir o padrão de cores e tipografia definido no projeto. Algumas telas podem sair do padrão, mas isso deve ser justificado e aprovado pelo time de desenvolvimento. Quase todo o layout e estilo do sistema já está definido no projeto, então não é necessário criar novos estilos ou componentes sem necessidade. Quase todo o layout e estilo do sistema já está definido no projeto, então não é necessário criar novos estilos ou componentes sem necessidade. Caso necessário verifique os estilos em [main.scss](C:/devilbox/data/www/projetos/htdocs/logiccom/front/src/assets/scss/main.scss) e na pasta [components](C:/devilbox/data/www/projetos/htdocs/logiccom/front/src/assets/scss/components/) estão todos os componentes que poderá usar nas telas # Prompts Todos os prompts devem ser registrados na pasta [prompts](C:/devilbox/data/www/projetos/htdocs/logiccom/front/src/assets/prompts/) e devem seguir o padrão de nomenclatura definido no projeto. As respostas devem ficar na pasta [prompts](C:/devilbox/data/www/projetos/htdocs/logiccom/prompts/) no mesmo arquivo do prompt, matendo a conversação guardada. Um arquivo MD de prompt pode referenciar outros prompts, mas não deve conter respostas de outros prompts. A pasta [prompts](C:/devilbox/data/www/projetos/htdocs/logiccom/front/src/assets/prompts/) deve conter prompts de todos os tipos, como prompts de cadastro, prompts de listagem, prompts de edição, prompts de exclusão, prompts de validação, prompts de erro, prompts de sucesso, prompts de confirmação, prompts de alerta, prompts de informação, prompts de ajuda, prompts de tutorial, prompts de onboarding, prompts de feedback, prompts de pesquisa, prompts de filtro, prompts de ordenação, prompts de paginação, prompts de exportação, prompts de importação e outros. A pasta [prompts](C:/devilbox/data/www/projetos/htdocs/logiccom/front/src/assets/prompts/) deve funcionar como um centralizador de todos os prompts do sistema e funcionar como uma memória centralizada. # Demo Existe um aplicativo de demonstração do sistema, onde tem telas criadas usando os padrões do projeto, para servir como referência para novos desenvolvimentos. Essa pasta é [demo](C:/devilbox/data/www/projetos/htdocs/logiccom/front/src/assets/demo/) e contém telas de exemplo, componentes de exemplo e estilos de exemplo. Você não pode criar uma nova pasta prompt sempre use a que já existe ## Referência de código Esse sistema logiccom é uma melhoria de um sistema antigo, o sistema antigo você pode encontrar na pasta [Logiccom-old](C:\devilbox\data\www\projetos\htdocs\logiccom-old) e pode usar como referência de código, mas não pode copiar código sem necessidade, pois o sistema antigo não segue os padrões do projeto atual. Mas serve para tomar como referência de código, para entender como o sistema antigo funcionava e como o sistema atual deve funcionar. E o nome do banco de dados do sistema antigo é logiccom_old, então se precisar consultar o banco de dados do sistema antigo, você pode usar esse nome de banco de dados.