{"rows":[{"id":"17","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 17:31:35"},{"id":"16","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 17:25:19"},{"id":"15","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 17:06:52"},{"id":"14","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 17:01:04"},{"id":"13","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 16:59:20"},{"id":"12","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 16:56:06"},{"id":"11","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 14:56:58"},{"id":"10","tool_id":"read_file","actor_name":"admin","project_name":"regras","params_json":"{\"project\":\"regras\",\"path\":\"regras.md\"}","success":"1","duration_ms":"0","result_json":"{\"project\":\"regras\",\"path\":\"regras.md\",\"content\":\"# Regras Operacionais Globais - Procedimento Seguro\\n\\n<!--\\nCABECALHO DE ALTERACAO (obrigatorio; atualizar a cada alteracao):\\n- Change summary:\\n  - Ajustado o carregamento de regras para nao depender de nome de ficheiro especifico.\\n  - Clarificado quando perguntar ao utilizador vs executar sem explicacoes no chat.\\n  - Atualizado o fluxo 12.1 para aceitar backup automatico das tools de filesystem.\\n  - Adicionada regra obrigatoria para leitura das regras especificas de gestao de versoes do runtime antes de mexer em versoes.\\n  - Adicionada referencia ao documento de verdade `projects/regras/reparar_super_llm` para contexto tecnico do projeto Super_LLM.\\n- Risk level: baixo\\n- Rollback: repor a versao anterior de projects/regras/regras.md a partir do .bak automatico da tool de filesystem.\\n-->\\n\\n\\nRegra: Monitorização do contexto da conversa\\n\\nO assistente deve estimar o uso de tokens da conversa.\\nQuando o uso estimado atingir 75% do limite de contexto,\\ndeve emitir um aviso claro ao utilizador indicando:\\n\\n- percentagem estimada de uso\\n- tokens usados\\n- tokens restantes\\n- recomendação de abrir novo chat ou resumir contexto\\n- \\n\\n\\n## 1. Processo (Gates) — nao saltar passos\\n\\n### 1.1 Gate 0 — Preparacao e backups (antes de mexer)\\n- 1.1.1 Fazer backup antes de tocar em qualquer ficheiro (um por ficheiro, com timestamp).\\n- 1.1.2 Se a intervencao for de risco medio/alto: fazer clone/backup do projeto antes.\\n- 1.1.3 Registar no registo (ver 4.1-4.4) quais os backups, onde estao e como reverter (rollback).\\n\\n### 1.2 Gate A — Diagnostico (primeiro)\\nObjetivo: perceber o problema com evidencia sem alterar logica/estrutura.\\n- 1.2.1 Reproduzir o problema.\\n- 1.2.2 Recolher evidencia: logs, outputs, hashes, diffs.\\n- 1.2.3 Timeboxing de investigacao: definir limite (ex.: 30-60 min). Se exceder: parar e reportar evidencia + hipotese + proximos passos.\\n- 1.2.4 Identificar causa provavel.\\n- 1.2.5 Se necessario: criar ferramentas de diagnostico isoladas (sem mexer em producao/logica).\\n\\nOutput obrigatorio (no registo; ver 4.1-4.4):\\n- 1.2.6 sintomas\\n- 1.2.7 reproducao\\n- 1.2.8 hipotese/causa provavel\\n- 1.2.9 evidencia\\n- 1.2.10 o que nao foi alterado\\n\\n### 1.3 Gate B — Planeamento (antes de reparar)\\nCriar/atualizar um .md com:\\n- 1.3.1 Objetivo geral (1 frase)\\n- 1.3.2 Objetivos especificos\\n- 1.3.3 Definicao de pronto (criterios verificaveis)\\n- 1.3.4 Lista exata de ficheiros a tocar\\n- 1.3.5 Lista do que e proibido tocar\\n- 1.3.6 Plano de rollback (passos concretos)\\n\\n### 1.4 Gate C — Reparacao (cirurgica)\\n- 1.4.1 Alterar apenas o estritamente necessario.\\n- 1.4.2 Proibido: refactor/reformat/limpezas \\\"ja agora\\\".\\n- 1.4.3 Proibido: renomear/mover sem pedido explicito.\\n- 1.4.4 Proibido: alterar logica/estrutura fora do scope.\\n- 1.4.5 Atualizar o registo (ver 4.1-4.4) a cada mudanca (o que mudou, porque, ficheiros tocados, diff/resumo).\\n\\n### 1.5 Gate D — Testes e validacao (depois)\\n- 1.5.1 Executar bateria de testes relevante.\\n- 1.5.2 Minimo de validacao por alteracao: pelo menos 1 prova objetiva (ex.: lint, comando, query, hash, output) registrada no registo.\\n- 1.5.3 Registar comandos executados, outputs/resultados e criterios de pronto cumpridos.\\n\\n### 1.6 Gate E — Encerramento\\n- 1.6.1 Confirmar rollback possivel.\\n- 1.6.2 Confirmar que backups existem e estao referenciados.\\n- 1.6.3 Se houver impacto em tooling/schemas: atualizar RELATORIO_TESTES_MCP.md.\\n\\n---\\n\\n## 2. Regras duras (nao negociaveis)\\n- 2.1 Nunca apagar/renomear qualquer ficheiro sem pedido explicito + rollback testado.\\n- 2.2 Nunca alterar nada que nao foi pedido.\\n- 2.3 Proibido mudancas cosmeticas.\\n- 2.4 Proibido placeholders (ex.: \\\"TODO\\\", \\\"TBD\\\", \\\"lorem ipsum\\\", stubs de conteudo) em entregaveis finais.\\n- 2.5 Proibido placeholders em ficheiros de programacao (ex.: TODO/TBD/stubs) e proibido deixar codigo \\\"meio feito\\\".\\n- 2.6 Proibido executar/alterar sem o utilizador pedir explicitamente.\\n- 2.7 Se surgir problema extra: parar e reportar (nao corrigir \\\"ja agora\\\").\\n\\n---\\n\\n## 3. Evidencia (antes/depois)\\nNo registo (ver 4.1-4.4):\\n- 3.1 Estado antes: project_manifest (ou hashes sha256) + data/hora\\n- 3.2 Estado depois: project_manifest (ou hashes sha256) + data/hora\\n- 3.3 Diffs: diff_text quando possivel (ou resumo objetivo)\\n- 3.4 No reporte ao utilizador: comparar antes vs depois e indicar apenas **IGUAL** ou **ALTERADO** (nao colar sha256 completos), exceto se o utilizador pedir hashes.\\n\\n---\\n\\n## 4. Entregaveis e registos\\n- 4.1 Um registo .md por intervencao, guardado em `projects/registos/`.\\n- 4.2 Formato do nome (apenas para backups .bak):\\n  - 4.2.1 `9999_nome_YYYY-MM-DD_HHMMSS.md.bak` (data/hora = hora do servidor)\\n  - 4.2.2 Prefixo numerico sequencial + nome curto.\\n- 4.3 Ficheiros normais mantem nomes normais (nao forcar esquema de numeracao).\\n- 4.4 Backups referenciados no registo.\\n- 4.5 Ferramentas auxiliares (se existirem) guardadas e referenciadas.\\n- 4.6 Atualizacao do relatorio principal se aplicavel.\\n- 4.7 Log de sessao (apenas a pedido do utilizador):\\n  - 4.7.1 Criar um ficheiro em `projects/log_sessao/` com `numero_sequencial_YYYY-MM-DD_HHMMSS.md` (hora do servidor).\\n  - 4.7.2 O log deve registar: tudo o que foi feito, como foi feito, onde foi feito, como ficou, e o que faltou para fazer.\\n\\n---\\n\\n## 5. Carregamento de regras antes de abrir/criar projeto\\nSempre que o utilizador pedir:\\n- abre projeto <X> ou\\n- cria projeto <X>\\n\\nO assistente deve ANTES:\\n- 5.1 Ler as regras aplicaveis.\\n- 5.2 Aplicar essas regras ao resto do trabalho (backups, gates, registo, etc.).\\n- 5.3 So depois executar o pedido.\\n- 5.4 Ao carregar regras, emitir a confirmacao definida em 9999.\\n\\n---\\n\\n## 6. BD/DDL\\n- 6.1 Regra BD/DDL: qualquer tabela a criar de um projeto deve seguir o prefixo `__<project>_<nome_da_tabela>_`.\\n- 6.2 DDL so e permitido nesse prefixo.\\n\\n---\\n\\n## 7. Caminhos e portabilidade\\n- 7.1 Caminhos sao sempre relativos ao projeto (ex.: `ficheiros/x.php`, `config/env.php`).\\n- 7.2 Proibido usar caminhos absolutos do servidor (ex.: `/home/.../projects/...`) em codigo, configuracoes ou docs.\\n- 7.3 Objetivo: permitir mover/copiar a pasta do projeto sem quebrar o funcionamento.\\n\\n---\\n\\n## 8. PHP (estrutura e OOP)\\n- 8.1 Tudo o que se programar em PHP deve ser OOP.\\n- 8.2 Todas as classes PHP devem ficar numa pasta dedicada do projeto (ex.: `classes/` ou `src/`).\\n- 8.3 Proibido espalhar classes por pastas arbitrarias.\\n\\n---\\n\\n## 9. Unicidade no servidor (env e atividades globais)\\n- 9.1 Qualquer variavel de ambiente, cron/job, cache key, lock file, tabela temporaria, ou outra atividade global deve ser unica por instancia.\\n- 9.2 Para garantir unicidade: usar sempre prefixo do nome do projeto + um valor unico definido em `env.php`.\\n- 9.3 O valor unico (ex.: `INSTANCE_ID`) deve permitir trocar o nome do projeto e/ou o valor, para correr 2+ instancias no mesmo servidor sem colisao.\\n\\n---\\n\\n## 10. Segredos e dados sensiveis\\n- 10.1 Nunca escrever credenciais/tokens/secrets em ficheiros, logs, outputs.\\n- 10.2 Sempre mascarar/redigir (ex.: ****).\\n\\n---\\n\\n## 11. Qualidade e atuacao\\n- 11.1 Nao inventar nem assumir.\\n- 11.2 Nao ocultar informacao relevante.\\n- 11.3 Nao criar suposicoes para fechar lacunas.\\n- 11.4 Nao entregar conteudo nao verificado.\\n- 11.5 So perguntar ao utilizador quando existir um problema real que impeca execucao segura, correta ou autorizada.\\n- 11.6 Atuar sempre como engenheiro senior: clareza, rastreabilidade, risco controlado, validacao antes/depois.\\n- 11.7 Quando escrever ficheiros, registos, documentacao, comentarios de codigo, planos ou relatorios, escrever sempre o que, onde, como e porque; incluir riscos, validacao e rollback quando aplicavel.\\n- 11.8 No codigo, comentar o suficiente para permitir entendimento futuro sem adivinhacao; explicar contexto, decisao tomada, risco relevante e reversao quando fizer sentido.\\n- 11.9 Sempre que o utilizador emitir uma regra nova de comportamento: questionar se e para escrever aqui.\\n\\n---\\n\\n## 12. Gestao de reparacao de bug e criacao de ficheiros\\n\\n### 12.1 Fluxo obrigatorio — reparacao de bug (loop max 4)\\n- 12.1.1 Se a intervencao usar tools de filesystem que ja criam backup `.bak` automaticamente, nao e necessario criar backup manual.\\n- 12.1.2 Se a intervencao nao usar essas tools, criar backup (.bak) antes de alterar.\\n- 12.1.3 Investigar (reproduzir + recolher evidencia).\\n- 12.1.4 Formalizar linha de atuacao (hipotese, plano, criterios de pronto).\\n- 12.1.5 Reorganizar/atualizar o plano se surgir nova evidencia.\\n- 12.1.6 Criar ferramentas de investigacao, caso seja necessario (isoladas do codigo principal).\\n- 12.1.7 Aplicar correcao (cirurgica).\\n- 12.1.8 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.1.9 Se houver erro (mesmo ou novo): voltar ao ponto 12.1.3, atualizar a formalizacao (12.1.4-12.1.5) e repetir.\\n- 12.1.10 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com evidencia + proximos passos.\\n\\n### 12.2 Fluxo obrigatorio — criacao de novo ficheiro (loop max 4)\\n- 12.2.1 Antes de criar: identificar preferencialmente uma fonte da verdade (spec, exemplo, referencia). Se nao existir, pedir ao utilizador.\\n- 12.2.2 Idealizar a solucao e segmentar em partes (se necessario).\\n- 12.2.3 Criar o ficheiro seguindo a fonte da verdade (sem inventar requisitos).\\n- 12.2.4 Testar e validar; criar ferramentas de teste/diagnostico, caso seja necessario.\\n- 12.2.5 Se houver erro: voltar ao ponto 12.2.2, ajustar a idealizacao com base no erro e repetir.\\n- 12.2.6 Limite: no maximo 4 iteracoes. Se falhar, informar o utilizador com o erro + tentativa feita + proximos passos.\\n\\n---\\n\\n## 13. Temas reservados (ainda sem regras especificas)\\n- 13.1 CI/CD e deployments\\n- 13.2 Observabilidade (logs/metrics/tracing)\\n- 13.3 Permissoes e acessos\\n- 13.4 Performance e escalabilidade\\n- 13.5 Integracoes externas e APIs\\n\\n---\\n\\n## 14. Regras obrigatorias\\n- 14.1 Proibido alterar ficheiros do sistema mcp a menos que o user autorize\\n- 14.2 Proibido propor alteracoes de ficheiros ou funcionamento de um projeto sem ter conhecimento do seu funcionamento\\n- 14.3 Proibido dar explicacoes ao utilizador, exceto quando forem pedidas explicitamente ou quando forem indispensaveis para sinalizar erro real, bloqueio, risco ou impossibilidade de execucao.\\n- 14.4 Executar ordem literal do user; caso nao seja direta, calcular a melhor forma e executar sem explicacoes adicionais. Quando o utilizador manda ler, isso significa ler e usar internamente; ler nao significa imprimir, resumir, listar ou expor conteudo, salvo pedido explicito. Quando o utilizador autoriza leitura ampla, como \\\"ler todos os ficheiros .md\\\", essa autorizacao ja cobre a leitura de todos os ficheiros incluidos no pedido, independentemente de quantidade, nome ou numeracao.\\n- 14.5 Proibido fazer conversa, funcao e executar pedidos explicitos\\n\\n---\\n\\n\\n## 9999. Confirmacao ao utilizador\\nSempre que as regras forem carregadas, avisar o utilizador:\\n\\nRegras carregadas com sucesso!\\n\\n<!-- PUBLIC_URLS_START -->\\n## Enderecos publicos (instalacao)\\n\\n- Base publica (Schema 1): `https://self.groundview.pt`\\n\\n\\nPadroes de URL (projetos):\\n- Publico do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/`\\n- Admin do self: `https://self.groundview.pt/admin/` \\n- Admin do projeto: `https://self.groundview.pt/projects/<nome_do_projeto>/public/admin/`\\n\\n<!-- PUBLIC_URLS_END -->\\n\"}","error_text":"","created_at":"2026-03-18 14:56:56"},{"id":"9","tool_id":"read_file","actor_name":"admin","project_name":"demo1","params_json":"{\"project\":\"demo1\",\"path\":\"regras/regras.md\"}","success":"0","duration_ms":"0","result_json":"[]","error_text":"path not allowed","created_at":"2026-03-18 14:54:29"},{"id":"8","tool_id":"read_file","actor_name":"admin","project_name":"demo1","params_json":"{\"project\":\"demo1\",\"path\":\"regras/regras.md\"}","success":"0","duration_ms":"0","result_json":"[]","error_text":"path not allowed","created_at":"2026-03-18 14:51:23"},{"id":"7","tool_id":"read_file","actor_name":"admin","project_name":"demo1","params_json":"{\"project\":\"demo1\",\"path\":\"regras/regras.md\"}","success":"0","duration_ms":"0","result_json":"[]","error_text":"path not allowed","created_at":"2026-03-18 14:43:35"},{"id":"6","tool_id":"read_file","actor_name":"admin","project_name":"demo1","params_json":"{\"project\":\"demo1\",\"path\":\"regras/regras.md\"}","success":"0","duration_ms":"0","result_json":"[]","error_text":"path not allowed","created_at":"2026-03-18 14:43:27"},{"id":"5","tool_id":"list_files","actor_name":null,"project_name":"demo1","params_json":"{\"project\":\"demo1\"}","success":"1","duration_ms":null,"result_json":"{\"project\":\"demo1\",\"items\":[{\"name\":\"docs\",\"type\":\"dir\"},{\"name\":\"moved\",\"type\":\"dir\"},{\"name\":\"ola.txt\",\"type\":\"file\"},{\"name\":\"teste_exec\",\"type\":\"dir\"}]}","error_text":"","created_at":"2026-03-17 19:33:26"},{"id":"4","tool_id":"create_folder","actor_name":null,"project_name":"demo1","params_json":"{\"project\":\"demo1\",\"path\":\"teste_exec\"}","success":"1","duration_ms":null,"result_json":"{\"project\":\"demo1\",\"path\":\"teste_exec\"}","error_text":"","created_at":"2026-03-17 19:33:26"},{"id":"3","tool_id":"preload_tool_schemas","actor_name":null,"project_name":"demo1","params_json":"{\"categories\":[\"filesystem\"]}","success":"1","duration_ms":null,"result_json":"{\"loaded\":[\"list_files\",\"read_file\",\"create_folder\",\"create_file\",\"edit_file\",\"copy_path\",\"move_path\",\"delete_path\"],\"categories\":[\"filesystem\"]}","error_text":"","created_at":"2026-03-17 19:16:29"},{"id":"2","tool_id":"list_projects","actor_name":null,"project_name":"regras","params_json":"[]","success":"1","duration_ms":null,"result_json":"{\"projects\":[\"demo1\",\"regras\"]}","error_text":"","created_at":"2026-03-17 18:24:51"},{"id":"1","tool_id":"list_projects","actor_name":null,"project_name":"regras","params_json":"[]","success":"0","duration_ms":null,"result_json":"[]","error_text":"not implemented","created_at":"2026-03-17 18:10:43"}],"stats":{"total":17,"errors":5,"avg_duration_ms":0,"last24h":0,"by_tool":{"read_file":12,"list_files":1,"create_folder":1,"preload_tool_schemas":1,"list_projects":2},"by_hour":[]}}