martinsgmx/3d-auto-fabrik

O que 3d-auto-fabrik faz?

Orquestrador para mcp-cura (malha → fatiar → G-code) e mcp-moonraker (estado da impressora → imprimir). Os dois servidores deliberadamente não sabem da existência um do outro: o mcp-cura nunca contata a impressora e o mcp-moonraker nunca fatia. Este skill é a cola. Os arquivos transitam entre eles apenas por meio de uma transferência explícita e com portão de aprovação.

Regras inegociáveis — leia antes de tocar no hardware

Estas regras existem porque uma impressora 3D é um aquecedor, um motor e um bocal afiado. O atrito é proposital.

1. Nunca confirme uma ação preparada de alto risco em nome do usuário. moonraker_print_start, moonraker_print_cancel, moonraker_run_macro, cura_artifact_export, moonraker_file_delete e similares retornam uma solicitação de aprovação primeiro. Seu trabalho é apresentar essa solicitação, de forma clara e honesta, e aguardar. Somente após o usuário aprovar explicitamente (no chat, ou executando mcp-moonraker approve <id> / mcp-cura approve <id> fora do contexto) você pode chamar a ferramenta *_confirm_action correspondente. Nunca invente, reutilize ou parafraseie ids de aprovação ou frases de confirmação.
2. Nunca pule a verificação para ser útil. cura_gcode_verify antes de qualquer impressão, moonraker_verify_connection antes de qualquer ação na impressora, moonraker_files_list + moonraker_file_metadata após qualquer transferência.
3. moonraker_emergency_stop é a única alavanca sem portão. Use-a apenas quando algo fisicamente estiver dando errado agora (fumaça, rangido, bocal arrastando pela peça, eixos colidindo). Para "parar aquecimento" fora de uma emergência, use moonraker_turn_off_heaters — reversível e sem portão.
4. Permaneça dentro da política de segurança local. Limites de temperatura, modo somente leitura, allow_raw_gcode, allow_host_admin são definidos pelo usuário intencionalmente. Se uma ferramenta recusar, relate a recusa e seu motivo. Não reformule a chamada, habilite a flag ou encontre outra ferramenta que faça a mesma coisa.
5. Em caso de dúvida, pare e pergunte. Uma impressora pausada gasta um pouco de eletricidade; uma impressão errada gasta horas e filamento; um portão ignorado pode incendiar uma casa. O usuário está sempre acessível — pergunte.

Pré-voo — toda sessão que tocar em hardware

1. mcp-cura doctor e mcp-moonraker doctor (diagnósticos locais, somente leitura).
2. moonraker_verify_connection — conectado? latência? Klipper pronto, ocupado ou desligado?
3. cura_policy_info e moonraker_policy_info — aprenda os limites ativos (limites de temperatura, modo de aprovação, chaves somente leitura) antes de planejar uma mutação.
4. moonraker_server_info — confirme que o Klipper está ready, não shutdown ou ocupado com outro trabalho.
5. Alinhe o plano com o usuário: qual impressora, qual material, qual bocal, qual qualidade, qual arquivo, quantas cópias, onde na mesa. Não suponha.

Se um servidor estiver faltando ou não conectar, informe e aponte o usuário para references/troubleshooting.md. Não edite configurações, instale pacotes ou execute --force em nada apenas para fazer uma verificação passar.

O pipeline

Trabalhe etapa por etapa. Relate brevemente após cada etapa e pause para o usuário sempre que um portão exigir.

Etapa 0 — Planejar. Resuma o trabalho em um parágrafo (arquivo, impressora, material, bocal, perfil, cópias, posicionamento). Obtenha o sinal verde.

Etapa 1 — Importar. cura_artifact_import com um caminho absoluto dentro das raízes de importação configuradas (~/Downloads, ~/Documents, ~/Desktop, ~/models por padrão) — ou com o parâmetro data em base64 para um arquivo fora das raízes. As raízes confinam caminhos de sistema de arquivos; o caminho data é o canal suportado pelo servidor para bytes fornecidos pelo cliente, não é um desvio e não precisa de alteração de política. Se uma importação por caminho for recusada, reimporte os mesmos bytes via data (o endereçamento de conteúdo retorna o mesmo artifact_id) em vez de reduzir o trabalho a "não posso ajudar". Registre o artifact_id retornado — cada etapa posterior o referencia.

Etapa 2 — Inspecionar e reparar. cura_mesh_inspect (limites em mm, contagem de triângulos, estanque, volume, triângulos degenerados). Em seguida, conforme necessário:

• orientação / posicionamento / escala → cura_mesh_transform (escala → rotacionar → transladar, depois center_on_bed)
• superfície não-manifold ou irregular → cura_mesh_remesh com um voxel_size, ou cura_mesh_offset para expandir/contrair uma malha fechada
• várias partes como uma impressão → cura_mesh_merge (sopa de triângulos) ou cura_mesh_boolean (uma união/subtração verdadeira — baseada em voxels)
• muitos triângulos → cura_mesh_decimate em direção a target_triangles

Inspecione novamente após cada reparo e cite os números. Operações de malha de risco médio são controladas por política mas não precisam de aprovação; ainda assim, mostre ao usuário o que mudou.

Etapa 3 — Resolver e verificar o perfil. cura_profile_list para encontrar definições e perfis de qualidade, depois cura_profile_resolve (definição + qualidade + material + variante + intenção). Leia os avisos: expressões Cura que não podem ser avaliadas, violações difíceis de temperatura. Depois cura_profile_verify — erros devem ser zero antes de fatiar. Se não forem, corrija o perfil (ou escolha outro) e explique o porquê. Nunca fatie contra uma verificação falha.

Etapa 4 — Fatiar. cura_slice(model_artifact_ids=[…], definition, quality, material, variant, intent, overrides?, name, wait=true, wait_timeout_secs). Respeite max_concurrent_jobs (padrão 2). Consulte com cura_slice_status; cura_slice_wait para trabalhos curtos; cura_slice_cancel apenas para trabalhos na fila/em execução. Se o fatiamento falhar, cura_slice_status traz o final do log do motor — cite o erro real.

Etapa 5 — Revisão do G-code. No artefato G-code retornado pelo fatiamento:

• cura_gcode_inspect — tempo estimado, filamento, contagem de camadas, faixa Z, temperaturas máximas, comandos suspeitos.
• cura_gcode_verify — comandos perigosos, temperaturas vs. política local, falta de desligamento do aquecedor / desabilitação do motor / metadados.
• Se algo estiver faltando, cura_gcode_prepare cria um novo artefato com uma sequência de desligamento segura (ou sequência final completa). Quando você usá-lo, leve o novo artifact_id adiante — o original não é alterado.

Em seguida, mostre ao usuário o resumo — tempo, filamento, temperatura mais alta, resultado da verificação — e obtenha confirmação explícita antes da Etapa 6. Esta é a última chance barata de abortar.

Etapa 6 — Transferir para a impressora. O artefato G-code deve existir na raiz gcodes da impressora. Os servidores MCP não expõem ferramenta de upload; os caminhos suportados são:

• cura_artifact_export para uma raiz de exportação que a impressora possa ler (um compartilhamento montado/USB que a impressora monitora), ou
• o usuário copia o arquivo para lá manualmente (web UI, SCP, o compartilhamento), ou
• se — e somente se — o usuário solicitar explicitamente, o endpoint de upload HTTP do Moonraker como uma ação única claramente registrada.

Antes de tocar na impressora, confirme que o arquivo chegou: moonraker_files_list (raiz gcodes) e moonraker_file_metadata — tempo e filamento estimados devem corresponder à saída do Cura.

Etapa 7 — Imprimir. Antes de moonraker_print_start:

• moonraker_printer_status mostra Klipper pronto e ocioso, não desligado ou ocupado; moonraker_temperatures mostra leituras ambientes razoáveis.
• A mesa está limpa, placa correta, material correto carregado, porta fechada — pergunte ao usuário; você não pode ver isso.
• O usuário confirma o nome exato do arquivo. moonraker_print_start prepara uma ação de alto risco; repasse o prompt de aprovação e aguarde a aprovação, depois moonraker_confirm_action com a frase e acknowledge=true.

Durante a impressão: consulte moonraker_printer_status e moonraker_temperatures; use moonraker_camera_snapshot para uma verificação visual quando algo parecer errado; moonraker_gcode_history quando comandos falharem. Para pausar a impressão para inspeção, use moonraker_print_pause → inspecionar → moonraker_print_resume. Para abortar, moonraker_print_cancel (alto risco, confirmação dupla) — somente quando o usuário solicitar. Depois, moonraker_print_history registra o resultado.

Pós-impressão. Os aquecedores devem estar desligados (a sequência final faz isso — verifique com moonraker_temperatures). Lembre o usuário de limpar a placa. Se o usuário quiser limpar os artefatos, liste-os (cura_artifact_list) e só exclua com confirmação explícita — cura_artifact_delete é de alto risco.

Aprovações em uma só respiração

Os modos de aprovação (in_band, out_of_band, both) são configurados por servidor em [approval]. Em todos os modos, uma ação preparada = um approval_id = uma frase de confirmação de uso único com TTL curto (padrão 120 s). A ferramenta e os argumentos armazenados da chamada de preparação são o que é executado; os argumentos fornecidos a *_confirm_action são decorativos. *_pending_approvals re-lista o que está aguardando; moonraker_cancel_approval / mcp-cura deny <id> anula uma ação antes de ser executada. Protocolo completo: references/safety-approvals.md.

Referência rápida — onde ler mais

• references/pipeline.md — passo a passo expandido com um exemplo de diálogo
• references/mcp-cura-tools.md — todas as 32 ferramentas mcp-cura: risco, portão, argumentos
• references/mcp-moonraker-tools.md — todas as 49 ferramentas mcp-moonraker da mesma forma
• references/safety-approvals.md — modos de aprovação, regras de recusa, tratamento de emergências
• references/troubleshooting.md — saída do doctor, falhas comuns, correções
• scripts/check-setup.sh — verifica se ambos os servidores estão instalados e acessíveis

A instalação e o registro de MCP/skill por plataforma estão na documentação do repositório (docs/platforms.md), não neste skill — carregue-as quando o usuário perguntar sobre configuração.

Quando não usar este skill

Projetar ou reparar geometria CAD/STL manualmente (use uma ferramenta de modelagem), editar printer.cfg ou includes do Klipper (admin do host e escrita de configuração desativados por padrão — e devem permanecer assim), ou qualquer coisa envolvendo reinicializações do host, reinicializações de firmware ou G-code bruto que o usuário não tenha ativado explicitamente. Informe e pare.