Regras Groundview

Regras operacionais numeradas, carregáveis via HTTPS, com níveis por necessidade.

API JSON · Manifest · Admin

Resumo

55 regras normalizadas9 temasfonte: projeto regras

LVL-001 — nivel_1_simples

texto, UI, typo, leitura, ficheiros sem impacto crítico

LVL-002 — nivel_2_normal

lógica de negócio, configuração, módulos internos, alterações reversíveis

LVL-003 — nivel_3_critico

BD, auth, segredos, domínio, SSL, FTP, produção, MCP/schema/runtime, dados pessoais, pagamentos, delete/quarentena

GERAL — Regras gerais comuns

GERAL-001 nível todos
Executar o pedido literal do utilizador; qualquer desvio exige autorização explícita.
GERAL-002 nível todos
Trabalhar por evidência confirmada, não por inferência.
GERAL-003 nível todos
Se não souber ou não conseguir confirmar, declarar explicitamente.
GERAL-004 nível todos
Não alterar nada sem necessidade objetiva provada.
GERAL-005 nível todos
Nunca alterar fora da pasta projects.
GERAL-006 nível todos
Antes de qualquer alteração com risco, criar backup proporcional e rollback claro.
GERAL-007 nível todos
Executar a alteração mínima e cirúrgica; refactor só com pedido explícito.
GERAL-008 nível todos
Validar o resultado final com prova objetiva suficiente.
GERAL-009 nível todos
Não repetir validações equivalentes quando uma prova real já for suficiente.
GERAL-010 nível todos
Registar objetivo, ficheiros tocados, alterações, validação e rollback.
GERAL-011 nível todos
Se o sistema já cumpre o pedido, não alterar e apresentar evidência.
GERAL-012 nível todos
Problemas fora do scope devem ser reportados sem os misturar na intervenção.

CARREGAMENTO — Carregamento de regras

LOAD-001 nível todos
Carregar sempre o bloco geral antes de atuar.
LOAD-002 nível todos
Carregar regras temáticas apenas quando o contexto exigir ou quando a atuação entrar nesse tema.
LOAD-003 nível todos
Manter regras adicionais disponíveis para carregamento posterior se o contexto evoluir.
LOAD-004 nível todos
Quando carregar regras, confirmar blocos carregados e regras indisponíveis, sem inventar.
LOAD-005 nível todos
Cada regra deve ter ID único e estável.

MCP — MCP e ferramentas

MCP-001 nível 2-3
Usar o contrato público da tool como fonte da verdade.
MCP-002 nível 2-3
Não inventar argumentos nem fazer brute force de kwargs.
MCP-003 nível 2-3
Reutilizar contratos já validados na sessão quando continuarem atuais.
MCP-004 nível 2-3
Preferir tools específicas a process.run; process.run é último recurso.
MCP-005 nível 3
Falhas MCP devem ser classificadas como erro do assistente, contrato/schema ou wrapper/runtime.
MCP-006 nível 3
Paginação deve usar o cursor opaco devolvido pelo runtime, sem decodificar nem reinterpretar.

PROJETO — Criação e lifecycle de projetos

PROJ-001 nível 3
Criar projetos dentro de projects e por tool oficial de lifecycle.
PROJ-002 nível 3
Copiar templates por pasta inteira, não por reconstrução ficheiro a ficheiro.
PROJ-003 nível 3
Testar cada ação executada: pasta, template, env, info, checklist, domínio, FTP, BD quando aplicável.
PROJ-004 nível 3
Segredos nunca aparecem por defeito nos outputs nem no admin.
PROJ-005 nível 3
project.update é obrigatório para alterações estruturais de domínio, FTP ou BD.
PROJ-006 nível 3
Nunca apagar recurso antigo antes de validar recurso novo.
PROJ-007 nível 3
SSL/HTTPS só fica pronto com HTTP ok, HTTPS ok, certificado com hostname correto, docroot e vhost corretos.
PROJ-008 nível 3
Delete significa quarentena e desmontagem controlada, não destruição imediata da pasta.

API — APIs e consumo externo

API-001 nível 3
APIs devem nascer API-first, seguras por defeito e com perspectiva do consumidor externo.
API-002 nível 3
Admin, autenticação, manuais, logs, métricas e instalação guiada são obrigatórios.
API-003 nível 3
Cliente API e provider são conceitos separados.
API-004 nível 3
Tokens reais só são mostrados na criação ou rotação; guardar hash quando possível.
API-005 nível 3
Endpoints devem devolver respostas padronizadas com sucesso/erro e trace_id.
API-006 nível 3
Logs devem registar eventos relevantes sem expor segredos.

TOOL — Criação de tools

TOOL-001 nível 3
Criar tool significa entregar tool completa, integrada, documentada, com help, schema e validação.
TOOL-002 nível 3
A tool deve aparecer em list_tools e ter nome final estável.
TOOL-003 nível 3
É proibido deixar placeholders, TODOs, stubs ou lógica incompleta.
TOOL-004 nível 3
Output da tool deve ser estruturado, previsível e com estado claro.
TOOL-005 nível 3
Erros devem ser legíveis, controlados e úteis para correção.

REPARACAO — Reparação e alterações

REP-001 nível 1-3
Reparações devem começar por diagnóstico proporcional ao impacto.
REP-002 nível 1-3
Reproduzir o erro quando aplicável; se não for possível, declarar.
REP-003 nível 2-3
Ticket/registo deve incluir pedido literal, causa provável/confirmada, alteração, teste e resultado.
REP-004 nível 2-3
Causa raiz não confirmada nunca deve ser apresentada como facto.
REP-005 nível 1-3
Encerrar quando houver diagnóstico, backup quando aplicável, alteração ou decisão de não alterar, validação e registo suficiente.

SEGURANCA — Segurança, dados e base de dados

SEC-001 nível 3
Segredos ficam apenas em configuração protegida e sempre mascarados em outputs.
SEC-002 nível 3
Base de dados deve usar prefixo de tabela por projeto quando aplicável.
SEC-003 nível 3
Dados críticos exigem validação reforçada e rollback explícito.
SEC-004 nível 3
Operações destrutivas exigem confirmação forte e backup/dump quando aplicável.

QUALIDADE — Qualidade, UX e documentação

QUAL-001 nível 1-3
Código deve ser OOP quando possível e adequado.
QUAL-002 nível 1-3
Interfaces devem funcionar em mobile, tablet e desktop salvo scope diferente.
QUAL-003 nível 1-3
Comentários e documentação devem ser úteis, não redundantes.
QUAL-004 nível 1-3
Evitar overengineering: profundidade deve ser proporcional a risco, impacto e escala.