AutSteelTech — Orquestrador MCP
Diretrizes gerais de engenharia de software e instruções de uso para agentes de IA. Regras locais do repositório continuam definindo arquitetura e convenções específicas.
Como a IA deve usar este MCP
# Guia de uso do Orquestrador MCP Consulte para tarefas técnicas de projeto ou pedido explícito. O pedido define escopo e aceite; orientação não autoriza etapas adicionais. 1. Consulte get_global_guidance para orientação técnica aplicável. 2. Confirme repositório, checkout, branch e estado pelo executor. Use list_projects/resolve_project_context quando houver cadastro; catálogo vazio ou projeto não cadastrado permite descoberta local. 3. Use list_skills com resumo fiel e get_skill somente para gatilhos pertinentes. Não releia documentos já entregues sem necessidade. 4. Consulte o grafo disponível e confirme arquivos relevantes. Sem snapshot, continue pela evidência acessível; não exija indexação por rotina. 5. Em retomada, leia a memória anunciada e reconcilie com o pedido atual. Confira scopes reais. 6. Implemente a menor mudança autorizada. Branch, ticket, delegação, checklist, testes e PR são condicionais ao pedido e às instruções aplicáveis. 7. Para branch/PR, use git-branch-validation e obtenha aprovação explícita de nome exato e base por repositório. 8. Execute somente validações pedidas/definidas no aceite. Separe build, lint, teste e evidência visual. 9. Revise o diff pertinente e registre checkpoint quando exigido e disponível. Confirmação humana de sucesso encerra sem nova verificação. 10. Incorpore aprendizados confirmados na fonte adequada sem publicar dados episódicos ou generalizar convenções de domínio. ## Capacidades reais Ferramentas de orientação: get_global_guidance, list_projects, resolve_project_context, list_skills, get_skill, search_project_graph, get_project_graph_context e trace_project_graph_impact; recursos MCP expõem documentos anunciados. Quando anunciadas/autorizadas: save_checkpoint/list_checkpoints/read_memory, record_error/record_rejected_decision, record_feedback, approve_feedback/reject_feedback/promote_feedback_to_global e list_audit_events. Não presuma que ferramentas do Orquestrador local existam neste runtime. Confira tools/list e scopes. Orientação textual não implementa ferramenta. Node oferece orientação/grafo com Bearer; memória e OAuth dependem do PHP configurado. Checkpoint registra demanda, decisões, arquivos, base/head pertinentes, operações e testes reais, bloqueios e próximo passo. Não publique checkpoints em content/ZIP. Falha de leitura não prova ausência de checkpoint. Falha de escrita não permite afirmar persistência; informe e continue com fatos da sessão. Não use arquivo, branch ou commit como fallback. O executor realiza arquivos, Git, testes e publicações. Não alegue operações sem evidência nem imponha fornecedor. Login/sessão e 401/403 locais exigem recuperação segura somente quando a tarefa pedir validação autenticada. Nunca use credenciais de produção. Página: / — disponibilidade: /health — endpoint: /mcp.php.
Padrões globais de código
# Regras globais de trabalho com código Estas práticas valem para qualquer linguagem e projeto. O pedido atual define objetivo, escopo e aceite; instruções locais, código e contratos determinam os detalhes específicos. ## Antes de alterar - Confirme o repositório, o checkout, a branch e o estado atual. Preserve o trabalho existente. - Leia as instruções locais aplicáveis e encontre o ponto de entrada e o padrão mais próximo da mudança. Quando o pedido ou aceite incluir cobertura, consulte também o teste mais próximo. - Baseie decisões em código, contratos, configuração e testes existentes quando relevantes. Separe fatos de hipóteses. - Identifique consumidores e limites entre camadas quando a mudança tocar mais de um arquivo, API, tela ou modelo de dados. - Interprete “analise” ou “planeje” como investigação. Um pedido claro para implementar autoriza a menor alteração necessária dentro do escopo definido. - Não crie ticket, checklist ou outro artefato de processo por rotina. Delegue somente quando o usuário pedir ou houver ganho concreto, com escopo e arquivos exclusivos. ## Escreva código alinhado ao projeto - Prefira a menor solução coesa que atenda ao pedido. Reutilize componentes, serviços, bibliotecas e abstrações existentes quando seus contratos servirem. - Siga nomes, organização, formatação, padrões de erro e estilo usados no repositório. Evite refatoração ou formatação ampla fora do escopo. - Preserve a formatação local de estruturas existentes. Não compacte arrays, listas ou blocos multilinha apenas para reduzir linhas quando o arquivo já adota a forma expandida. - Quando o arquivo já organizar classes por imports, prefira importar a classe uma vez e usar o nome curto em vez de repetir FQCNs no código ou nos testes. - Não crie aliases, wrappers, métodos delegadores ou relacionamentos apenas por conveniência futura. Antes de adicioná-los, confirme um consumidor real ou uma exigência explícita do contrato. - Não crie camadas, dependências, opções ou generalizações para casos hipotéticos. Extraia código compartilhado quando houver necessidade real ou requisito explícito. - Preserve compatibilidade dos contratos existentes. Se precisar alterá-los, localize os consumidores afetados e avalie o impacto conforme o pedido e o aceite. - Valide entradas nas fronteiras apropriadas; trate erros de forma explícita e não esconda falhas com valores padrão silenciosos. - Proteja dados e permissões por padrão: menor privilégio, consultas seguras, saída adequada ao contexto e nenhum segredo em código, logs, testes ou documentação. - Para mudanças de dados, confira esquema, migração, integridade e reversibilidade antes de propor operações que possam afetar dados existentes. ## Validação - Não exija nem adicione testes automaticamente apenas porque houve uma mudança. - Execute testes, build, lint, navegação ou screenshots somente quando pedidos pelo usuário ou previstos no aceite definido por ele. - Quando testes fizerem parte do pedido ou do aceite, cubra sucesso, entradas inválidas e limites relevantes do contrato; evite testes que apenas repitam a implementação. - Trate cada tipo de validação separadamente; uma não comprova a outra. - Nunca declare uma validação que não executou. Informe falhas e limitações observadas. - Uma confirmação clara do usuário de que funcionou encerra o ciclo. Não inicie nova validação sem solicitação posterior. ## Git e histórico - Crie worktree ou branch, publique branch ou abra/atualize PR somente quando pedido ou exigido pelo workflow aplicável. - Antes dessas operações, aplique a regra do projeto e `git-branch-validation`, confira branches existentes e apresente repositório, nome exato da branch e base. Aguarde aprovação explícita desses parâmetros. Se houver colisão ou mudança de nome/base, peça nova aprovação. - Siga as convenções de commit do próprio repositório, verificadas nas instruções e no histórico. Não imponha um formato global. - Commit, push, merge, rebase, release e deploy exigem autorização para a ação e o alvo. Preserve alterações locais e o estado do stage. ## Checkpoints e memória - Checkpoint é memória episódica. Use ferramentas de memória somente quando o pedido ou o workflow exigir e as ferramentas e scopes estiverem disponíveis. - Em retomada, leia o checkpoint disponível e reconcilie-o com o pedido atual e o estado real do executor. - Se a memória estiver indisponível, informe a limitação e continue com os fatos da sessão. Não use arquivo local, commit ou branch como fallback. - Registre somente operações e validações realmente executadas. Nunca grave credenciais ou dados pessoais. ## Segurança e fechamento - Não leia nem publique `.env`, tokens, cookies, chaves, dados pessoais ou arquivos locais sem necessidade autorizada. - Não pare nem reinicie servidores do usuário. Não rode limpeza, reset, migração destrutiva ou alteração de banco sem autorização explícita e alvo confirmado. - Relate o comportamento alterado, os arquivos relevantes, as validações executadas e as pendências reais. - Separe o que foi concluído e verificado do que continua pendente ou bloqueado. - Arquivos, Git e validações pertencem ao executor autorizado; checkpoints só são persistidos pelas ferramentas de memória anunciadas. Não alegue operação que não foi confirmada. - Registre aprendizados reutilizáveis somente com evidência, na fonte de conhecimento adequada. Mantenha checkpoint episódico separado de feedback candidato e não promova decisões específicas da demanda automaticamente.
Diretrizes globais
# Diretrizes técnicas globais O pedido atual define objetivo, escopo e entrega. Instruções locais e evidência do código determinam contratos; recomendações do MCP não autorizam ações adicionais. ## Bootstrap seletivo - Consulte este MCP para inspecionar/alterar arquivos de projetos, executar comandos, validar aplicações ou retomar checkpoints técnicos. Conversa geral, redação, explicações e configuração global não exigem consulta, salvo pedido explícito. - Descubra repositório, branch, estado e capacidades necessárias. Catálogo vazio não comprova ausência do projeto. - Use o grafo disponível e confirme achados nos arquivos relevantes. Pesquisa ampla, auditoria e pesquisa externa somente quando pedidas ou quando uma dúvida concreta impedir a execução correta. - Classifique separadamente tipo técnico e esforço. Ajustes pequenos seguem descoberta e execução diretas; não crie ticket, plano, checklist, agente ou worktree por rotina. - Aplique skills somente aos gatilhos pertinentes. Roteamento é sugestão, não autorização. - Implementação explícita autoriza a menor alteração após delimitar escopo e contratos, sem aprovação intermediária de rotina. - Não crie conversas, agentes, arquivos auxiliares, branches, commits, PRs ou saídas fora do pedido e das instruções aplicáveis. ## Execução, memória e retomada - O MCP distribui orientação e, quando anunciado e autorizado, persiste estado. Código, Git, testes e operações externas pertencem ao executor. - Não imponha Git CLI, GitHub, SSH, Docker ou worktree globalmente. Use o ambiente oficial comprovado do projeto. - Em retomada, leia o checkpoint disponível e reconcilie pedido atual, projeto, checkout, branch e estado. O pedido atual prevalece. - Checkpoints são episódicos, separados de regras públicas. Use ferramentas de memória com scopes anunciados; falha não comprova ausência de memória. - Se a persistência estiver indisponível, informe a limitação e continue com fatos da sessão. Não invente persistência nem crie arquivo, commit ou branch como fallback. - Registre somente operações reais; hipóteses, comandos planejados e confirmação humana não são testes executados. ## Git e publicação - Antes de criar worktree com branch, criar/renomear/publicar branch ou abrir/atualizar PR, aplique git-branch-validation e a regra do projeto. - Confira branches existentes para reutilizar somente a da mesma demanda. Apresente nome exato, base e repositório e aguarde aprovação explícita antes da operação. - Derive nome do objetivo técnico confirmado, não apenas de ID/verbo genérico salvo regra local. Colisão ou mudança de nome/base exige nova aprovação. - Commit, push, merge, rebase, release, deploy e operação destrutiva exigem autorização para ação/alvo. Aprovação já dada para os mesmos parâmetros permanece válida. - Preserve trabalho local e stage. Quando o usuário for commitar, entregue alterações e mensagem; não faça commit. - Convenções pertencem ao projeto: confira instruções e histórico; não imponha formato global. ## Implementação e validação - Preserve arquitetura, contratos, permissões, logs e cálculos existentes. Reutilize padrões reais e evite abstrações, dependências e fallbacks especulativos. - Antes de persistir dados, confirme fonte de verdade e relações. Dado derivado só é duplicado com requisito explícito de histórico, auditoria ou snapshot. - Filtros devem atravessar UI/serialização, rota, validação, DTO/service e query com o mesmo contrato; um where isolado não prova o fluxo. - Adicione/execute testes, build, lint, navegação e screenshots somente quando pedidos ou previstos no aceite definido pelo usuário. - Menu, permissão, estado ou regra funcional não são design por rotina. Revisão visual aplica-se quando apresentação e aceite visual forem afetados. - Sessão expirada, login, storageState ausente e 401/403 locais são recuperáveis. Autenticação aplica-se somente quando a validação autorizada exigir. - Nunca leia ou exponha segredos. Preparação autorizada pode consumi-los internamente, sem valores em argumentos, logs, screenshots ou artefatos. - Não pare/reinicie serviços nem use reset, fresh, truncate ou escrita destrutiva por conveniência. ## Comunicação e fechamento - Responda a cada mensagem nova antes de continuar. Pergunta ou mudança de direção tem prioridade. - Antes de operação demorada, comunique o objetivo. Prefira comandos curtos e atualizações com evidência nova. - Não pergunte se deve continuar quando o próximo passo estiver claro. Obedeça imediatamente a parar/encerrar/aguardar. - Confirmação clara de sucesso encerra o ciclo sem nova validação não solicitada. - Relate comportamento alterado, resultados observados e limitações. Review, checkpoint e Draft PR seguem somente o workflow autorizado. - Após erro confirmado, confira equivalentes e diferencie regra durável de caso pontual. Incorpore conhecimento aprovado na fonte mais específica, preservando histórico. - Feedback candidato não é regra aprovada. Promoção exige decisão controlada e scopes reais; regra de domínio não vira orientação global.