@hybridlabor-api/aos 4.3.0 → 4.4.1

package/mcps/tdmcp/docs/pt/guide/local-copilot.md

@@ -1,164 +0,0 @@
----
-title: Copiloto local (sem API)
-description: "Rode o tdmcp — o servidor MCP para TouchDesigner — com uma LLM local gratuita. O `tdmcp chat` abre um copiloto no navegador conectado ao TouchDesigner: sem API paga, funciona offline."
----
-
-# Copiloto local (sem API)
-
-O tdmcp inclui um **copiloto local** para você controlar o TouchDesigner com uma
-**LLM gratuita rodando na sua própria máquina** — sem API paga, sem conta, funciona
-offline. O comando `tdmcp chat` abre uma pequena página de chat no navegador,
-conectada à mesma ponte do TouchDesigner que os outros clientes usam.
-
-É o caminho econômico e privado: ótimo para o dia a dia, e ele passa o bastão para
-o [Claude](/pt/guide/install) ou o [Codex](/pt/guide/codex) na hora em que você
-quiser montar um sistema inteiro.
-
-::: tip Qual caminho é este?
-O [Claude Desktop](/pt/guide/install) é a rota sem terminal. Esta página é para
-rodar o tdmcp com um **modelo local** em vez de um assistente pago — precisa do
-[Node.js 20+](https://nodejs.org), como os caminhos do Codex e do Cursor.
-:::
-
-## Para que serve
-
-O copiloto local recebe um **subconjunto curado e seguro** das ferramentas, então
-é rápido e difícil de usar errado. Ele é feito para o simples:
-
-- **Inspecionar** seu projeto — o que tem, como está ligado.
-- **Ler erros** e explicar o que está errado.
-- **Criar, conectar e ajustar operadores individuais** — um nó de cada vez.
-
-Ele de propósito **não** monta sistemas inteiros (sem geradores da Layer 1) e
-**não roda Python cru**. Quando você quiser uma rede generativa ou reativa a áudio
-completa, clique em **Escalate ⇪** na interface: ela copia um prompt pronto para
-colar que você entrega ao [Claude](/pt/guide/install) ou ao [Codex](/pt/guide/codex).
-Eles dirigem o *mesmo* projeto, então nada precisa se mover.
-
-## O que você precisa
-
-- **[TouchDesigner](https://derivative.ca/download)** com a ponte ligada (o mesmo
-  passo de uma linha de todo cliente — [veja abaixo](#turn-on-the-bridge)).
-- **[Node.js 20+](https://nodejs.org)** — usado para iniciar o copiloto.
-- **[Ollama](https://ollama.com)** — o executor de modelos locais gratuito. O
-  `tdmcp chat` o inicia para você se ele ainda não estiver rodando.
-
-## Como iniciar
-
-O caminho mais rápido não precisa de clone — só Node e Ollama instalados:
-
-```bash
-# uma vez: instale o Ollama em https://ollama.com e, se quiser, baixe um modelo antes
-ollama pull qwen2.5:3b      # opcional — a UI também tem um botão de download
-
-npx --yes --package=@dpantani/tdmcp tdmcp chat # abre http://127.0.0.1:4141 no seu navegador
-```
-
-Se você já clonou e compilou o tdmcp (o
-[caminho a partir do código-fonte](/pt/guide/install#other-clients)), o comando é
-só `tdmcp chat` (ou `node dist/index.js chat`).
-
-O `tdmcp chat` **inicia o Ollama para você** se o daemon não estiver de pé —
-destacado e deixado rodando, então fechar o chat nunca tira seu modelo do ar.
-Flags úteis:
-
-- **`--read-only`** — força o tier seguro/somente leitura na sessão inteira.
-- **`--creative`** — usa o tier criativo e uma temperatura mais quente.
-- **`--prompt <texto>`** — roda um prompt headless e imprime a resposta sem abrir
-  o navegador.
-- **`--no-ollama`** — não iniciar automaticamente (para um endpoint remoto ou um
-  daemon que você gerencia).
-- **`--no-open`** — não abrir o navegador automaticamente.
-- **`--profile <nome>`** / **`--config <caminho>`** — usa uma config/perfil salvo
-  para esta execução do chat.
-- **`--help`** — listar tudo.
-
-::: tip Qual modelo local?
-O **`qwen2.5:3b`** é o padrão — medido em 100% de tool-calling na carga de tarefas
-simples, tão confiável quanto modelos maiores, mas mais rápido e leve. Modelos
-abaixo de 3B são instáveis; suba para `qwen2.5:7b` só se quiser mais folga de
-qualidade nas respostas. Mais detalhes na
-[referência do CLI](/reference/cli#local-copilot-tdmcp-chat) (em inglês).
-:::
-
-## Usando o chat
-
-A interface no navegador está conectada ao seu projeto do TouchDesigner ao vivo.
-Ela tem:
-
-- Um botão **somente leitura** — deixa ele olhar, mas não mexer.
-- **Troca de modelo** ao vivo e **configurações de endpoint**, além de um
-  **download de modelo** num clique se algum não estiver baixado.
-- **Histórico persistente**, então sua conversa sobrevive a um reinício.
-- **Escalate ⇪** — copia um prompt de transição para o Claude ou o Codex quando
-  uma tarefa é grande demais para o modelo local.
-
-## Fluxo de RAG e geração
-
-Creative RAG e Project RAG são fontes de contexto primeiro, não builders
-automáticos. `tdmcp ask --with-creative` pode adicionar referências da Creative
-RAG ao prompt, e `project_rag_search` pode encontrar projetos, componentes e
-snippets reais de TouchDesigner, mas ambos são somente leitura até você escolher
-explicitamente uma tool que modifica o projeto.
-
-Para transformar um card da Creative RAG em uma rede TouchDesigner, habilite o
-caminho protegido de apply e rode um dry-run antes de mutar o projeto:
-
-```bash
-export TDMCP_RAG_ENABLED=1
-export TDMCP_RAG_APPLY_CARD=1
-tdmcp-agent apply-creative-card --params '{"card_id":"<card-id>","dry_run":true}'
-```
-
-Revise a tool de destino e os argumentos planejados, depois rode novamente com
-`"dry_run":false` só quando quiser que o tdmcp crie operadores. Trate resultados
-da Project RAG como referências técnicas e provenance, não como instruções de
-projeto executáveis.
-
-## Aponte para outro modelo
-
-Por padrão o copiloto fala com o Ollama local, mas ele usa a API padrão compatível
-com a da OpenAI — então você pode apontá-lo para qualquer lugar com duas variáveis
-de ambiente:
-
-| Variável | Padrão | Use para |
-| --- | --- | --- |
-| `TDMCP_LLM_BASE_URL` | `http://127.0.0.1:11434/v1` | LM Studio, uma GPU na nuvem ou uma API paga. |
-| `TDMCP_LLM_MODEL` | `qwen2.5:3b` | Qualquer id de modelo disponível naquele endpoint. |
-| `TDMCP_LLM_TIER` | `standard` | Inicia a UI em modo `standard`, `safe` ou `creative`. |
-| `TDMCP_LLM_MAX_STEPS` | `8` | Limita iterações modelo/tool em um turno. |
-| `TDMCP_LLM_TEMPERATURE` | `0.4` | Ajusta a temperatura de amostragem do endpoint de chat. |
-
-A lista completa (incluindo `TDMCP_LLM_API_KEY` e a porta do chat) está em
-[variáveis de ambiente](/pt/reference/environment#copiloto-local-tdmcp-chat).
-
-## Ligue a ponte {#turn-on-the-bridge}
-
-Como todo cliente, o copiloto precisa da pequena ponte rodando *dentro* do
-TouchDesigner. O jeito mais fácil é arrastar o `.tox` do release — sem Textport
-([veja Instalação](/pt/guide/install#drag-in-tox)). Prefere uma linha? Abra o
-**Textport** (**Dialogs → Textport and DATs**), cole esta única linha e aperte
-Enter:
-
-```python
-import urllib.request; exec(urllib.request.urlopen("https://github.com/Pantani/tdmcp/raw/v0.12.0/td/bootstrap.py").read().decode())
-```
-
-Você deve ver `[tdmcp] bridge running on port 9980`. Veja
-[Instalação](/pt/guide/install#turn-on-the-bridge) para os detalhes e como remover
-depois.
-
-## Não conecta?
-
-- Confirme que a ponte está ligada: `curl http://127.0.0.1:9980/api/info` deve
-  devolver JSON.
-- Garanta que o Ollama está instalado e um modelo baixado (o botão de download da
-  UI faz isso por você).
-- A [Solução de problemas](/pt/guide/troubleshooting) completa cobre os casos
-  comuns.
-
-Com o TouchDesigner aberto e a ponte ligada, peça em linguagem natural — *"o que
-tem neste projeto?"*, *"por que este nó está vermelho?"*, *"adiciona um blur depois
-do ruído".* Para ideias maiores, veja as
-[receitas de prompt](/pt/guide/prompt-cookbook) ou escale para o
-[Claude](/pt/guide/install) / [Codex](/pt/guide/codex).

package/mcps/tdmcp/docs/pt/guide/lops-integration.md

@@ -1,143 +0,0 @@
----
-description: "Use o tdmcp de dentro do TouchDesigner pelo MCP Client (LOPs) da dotsimulate — aponte para o launcher reforçado e um agente dentro do TD constrói e inspeciona o seu projeto."
----
-
-# Usar do TouchDesigner (LOPs)
-
-O **"MCP Client" (LOPs)** da dotsimulate roda *dentro* do TouchDesigner e fala com
-qualquer servidor MCP. Aponte ele para o tdmcp e um agente que vive na sua rede do
-TD pode criar, conectar, inspecionar e dar preview de operadores nesse mesmo
-projeto — fechando o ciclo **TD (MCP Client dos LOPs) → servidor tdmcp → ponte do
-tdmcp → a sua rede.**
-
-Isto **não** é trocar o modelo de IA: os LOPs trazem o próprio modelo (OpenAI /
-Claude / Ollama); o tdmcp são as *ferramentas* que ele chama, exatamente como o
-Claude ou o Cursor fariam.
-
-## O que você ganha
-
-O cliente LOPs recebe a **superfície completa de ferramentas do tdmcp** — as
-ferramentas de criar/inspecionar/dar preview **mais** as ferramentas da base de
-conhecimento (`get_td_classes`, `get_td_class_details`, `get_module_help`,
-`search_operators`, `find_td_nodes`). Essas ferramentas de KB cobrem parte do que
-o *dotContext* da dotsimulate oferece, então você não precisa de uma camada
-separada de referência de operadores junto do tdmcp.
-
-Quando você conecta pelo launcher recomendado (abaixo), o tdmcp inicia no
-**perfil `safe`** — as ferramentas destrutivas ficam ocultas para que um agente
-autônomo dentro do TD não apague nós nem rode código sem revisão por acidente.
-
-## Pré-requisitos
-
-- A **ponte do tdmcp está instalada e rodando** dentro da *mesma* instância do
-  TouchDesigner — veja o [passo 3 da instalação, "ligue a ponte"](/pt/guide/install#turn-on-the-bridge).
-- **Node.js 20+ no seu PATH** — os LOPs vão iniciar o `node`.
-- Você rodou **`npm run build`** no seu clone do tdmcp, então o `dist/index.js`
-  existe.
-- Os **LOPs** da dotsimulate estão instalados, com o componente MCP Client.
-
-## Conectar (recomendado: o launcher)
-
-O `servers_config.json` da dotsimulate documenta `transport`, `command`, `args`,
-`cwd` e `description` — mas **nenhum campo `env`** — então não dá para definir as
-variáveis de reforço do tdmcp direto pela configuração. O tdmcp inclui um pequeno
-launcher, `scripts/tdmcp-lops.mjs`, que define essas variáveis por você e então
-inicia o servidor. Aponte o cliente LOPs para ele:
-
-```json
-{
-  "mcpServers": {
-    "tdmcp": {
-      "transport": "stdio",
-      "command": "node",
-      "args": ["/abs/path/to/tdmcp/scripts/tdmcp-lops.mjs"],
-      "cwd": "/abs/path/to/tdmcp",
-      "description": "tdmcp — build & inspect this TouchDesigner project (hardened: safe profile)"
-    }
-  }
-}
-```
-
-Troque `/abs/path/to/tdmcp` pela pasta onde você clonou o tdmcp (rode `pwd`
-dentro dela). Use o **caminho absoluto completo** tanto em `command`/`args` quanto
-em `cwd` — os LOPs resolvem o `cwd` de um jeito diferente dos clientes de linha de
-comando, então não confie em caminhos relativos. O launcher `tdmcp-lops.mjs`
-define o perfil `safe` por você.
-
-## Alternativa: um bloco `env` (se a sua versão dos LOPs aceitar)
-
-O esquema publicado da dotsimulate **não** documenta um campo `env`, então o
-launcher acima é o padrão seguro. Se a sua versão dos LOPs por acaso repassar um
-bloco `env`, você pode em vez disso apontar `args` direto para o `dist/index.js` e
-definir as variáveis você mesmo:
-
-```json
-{
-  "mcpServers": {
-    "tdmcp": {
-      "transport": "stdio",
-      "command": "node",
-      "args": ["/abs/path/to/tdmcp/dist/index.js"],
-      "cwd": "/abs/path/to/tdmcp",
-      "env": {
-        "TDMCP_RAW_PYTHON": "off",
-        "TDMCP_TOOL_PROFILE": "safe"
-      },
-      "description": "tdmcp — hardened for an in-TD agent"
-    }
-  }
-}
-```
-
-Se o bloco `env` for ignorado (você vai ver as ferramentas destrutivas ainda
-listadas), volte para o launcher.
-
-## Observação de reforço (hardening)
-
-Para um agente autônomo dentro do TD — sem ninguém revisando cada chamada —
-reforce a superfície:
-
-- **`TDMCP_RAW_PYTHON=off`** remove as duas ferramentas de Python cru
-  (`execute_python_script`, `exec_node_method`), em que o *cliente* escreve o
-  código. Isto **não** é um botão que desliga toda execução de código: muitas
-  ferramentas de nível mais alto ainda mandam o próprio Python *em template* para
-  a ponte.
-- **`TDMCP_TOOL_PROFILE=safe`** vai além e também esconde ferramentas destrutivas
-  (deleção de nós, reescrita de DATs, writes de checkpoint/componente/pacote,
-  writes de previews e controles de panic) — um superconjunto estrito de
-  `RAW_PYTHON=off`. O launcher define isto por você. Veja
-  [Variáveis de ambiente](/reference/environment) (em inglês).
-- A execução arbitrária do lado da ponte agora fica fechada por padrão, exceto
-  quando **`TDMCP_BRIDGE_TOKEN`** estiver configurado ou
-  **`TDMCP_BRIDGE_ALLOW_EXEC=1`** for definido no ambiente do *próprio
-  TouchDesigner*. Mantenha fechado para uso autônomo com LOPs.
-
-## Como funciona
-
-Tanto o cliente LOPs quanto a ponte do tdmcp vivem no **mesmo** processo do
-TouchDesigner. O cliente LOPs inicia o `node dist/index.js` (o servidor tdmcp) por
-stdio; esse servidor então fala HTTP com a ponte em `127.0.0.1:9980` — o mesmíssimo
-TD — que manipula a sua rede. Nenhuma troca de transporte é necessária; stdio é o
-padrão do tdmcp. O servidor iniciado é de vida curta, atrelado ao ciclo de vida do
-cliente MCP. Veja [Arquitetura](/reference/architecture#transports-events) (em
-inglês).
-
-## Isto **não** substitui o `tdmcp chat`
-
-O [copiloto local](/pt/guide/local-copilot) (`tdmcp chat`) é uma superfície
-*separada* — o tdmcp rodando o próprio modelo local. Os LOPs são um **cliente que
-consome o próprio modelo** (OpenAI / Claude / Ollama) e chama as ferramentas do
-tdmcp; não é um substituto para o modelo do copiloto. Use o que encaixar melhor no
-seu fluxo de trabalho.
-
-## Algum problema?
-
-- **"node not found"** — os LOPs não acharam o Node no PATH. Instale o
-  [Node.js 20+](https://nodejs.org) e garanta que ele está no PATH que o processo
-  do TD herda.
-- **"dist/index.js not found"** — o launcher imprime isto no stderr quando o build
-  está faltando. Rode `npm run build` na sua pasta do tdmcp.
-- **"bridge not reachable"** — a ponte do tdmcp não está rodando neste TD, ou está
-  em outro host/porta. Confira de novo o
-  [passo 3 da instalação](/pt/guide/install#turn-on-the-bridge) e a
-  [Solução de problemas](/pt/guide/troubleshooting).

package/mcps/tdmcp/docs/pt/guide/mcp-resources.md

@@ -1,96 +0,0 @@
----
-description: "Os recursos MCP tdmcp:// que um cliente de IA pode ler — operadores, API Python, receitas, snippets GLSL, cheatsheets, trilhas de aprendizado, prompts, digests de cena ao vivo e mais."
----
-
-# Recursos MCP
-
-Além das ferramentas que pode *chamar*, o tdmcp expõe uma biblioteca de **recursos**
-que um cliente de IA pode *ler* — docs de operadores, snippets de shader, receitas,
-cheatsheets, uma trilha de aprendizado, até um snapshot ao vivo do seu projeto em
-execução. Os recursos são como o assistente se aterra em fatos do TouchDesigner e na
-própria superfície do tdmcp antes de construir, em vez de chutar.
-
-Você raramente endereça estes na mão; um cliente capaz os lista e lê por você. Mas
-conhecer as famílias ajuda a fazer perguntas melhores — *"cheque o recurso de
-operadores"*, *"leia o catálogo de snippets GLSL primeiro"* — e explica de onde vem o
-conhecimento do assistente.
-
-::: tip Este é o mapa voltado ao artista
-Para a referência completa por recurso (cada template de URI, cada parâmetro), as
-páginas [Architecture](/reference/architecture) e
-[Tools reference](/reference/tools) são a fonte da verdade. Esta página é a
-orientação.
-:::
-
-## Base de conhecimento (sempre ligada)
-
-A base de conhecimento de operadores commitada, exposta como recursos legíveis:
-
-| Família | URI | O que expõe |
-| --- | --- | --- |
-| Operadores | `tdmcp://operators/{name}` | Catálogo de operadores — leia uma categoria (TOP, CHOP, SOP, DAT, COMP, MAT, POP) para listar, ou um nome de operador para a doc completa. |
-| Conexões de operadores | `tdmcp://operator-connections/{operator}` | Operadores prováveis antes/depois, padrões de workflow relacionados e sugestões de próximo operador aterradas nas docs e patterns importados. |
-| Exemplos de operadores | `tdmcp://operator-examples/{operator}` | Snippets Python salvos, expressões, padrões de uso gerados e dicas para um operador específico. |
-| API Python | `tdmcp://python-api/{class_name}` | Referência das classes Python do TouchDesigner — membros e métodos. |
-| Versões TD | `tdmcp://td-versions/{version}` | Metadados de releases estáveis do TouchDesigner, notas de versão Python, destaques e mudanças de compatibilidade. |
-| Builds experimentais | `tdmcp://td-experimental/{series_or_category}` | Dados de séries experimentais do TouchDesigner, feature flags, novos operadores e notas de breaking changes. |
-| Compatibilidade | `tdmcp://compat/operators/{operator}`, `tdmcp://compat/python/{class_or_member}` | Consultas diretas de compatibilidade de operadores e API Python, com notas de versão adicionada/alterada/removida. |
-| Patterns | `tdmcp://patterns/{pattern_name}` | Padrões de workflow de cadeias de operadores (a fiação recomendada). |
-| GLSL patterns | `tdmcp://glsl/{pattern_name}` | Técnicas de shader nomeadas com snippets de fragment shader prontos. |
-| GLSL snippets | `tdmcp://glsl-snippets` | Um catálogo vetado e com licença limpa de snippets GLSL embutidos que o agente monta sem adivinhar IDs. |
-| Packs de técnicas | `tdmcp://techniques/{category}` | Packs de técnicas do Bottobot, como audio-visual, GPU compute, machine learning, networking e Python avançado. |
-| Classes TD | `tdmcp://td-classes/{family}` | Referências de classes por família de operadores do TouchDesigner, como TOP Class, CHOP Class e COMP Class. |
-| Receitas | `tdmcp://recipes/{recipe_name}`, `tdmcp://recipes/search/{query}` | Templates de rede compostos pré-validados, mais busca por palavra-chave em receitas built-in e do vault. |
-| Tutoriais | `tdmcp://tutorials/{tutorial_name}` | Fundamentos e workflows do TD em formato longo. |
-
-## Guia & onboarding (sempre ligados)
-
-Guias compactos e aterrados na KB que ajudam o agente a escolher o próximo passo:
-
-| Família | URI | O que expõe |
-| --- | --- | --- |
-| Cheatsheets | `tdmcp://cheatsheets` | Lembretes compactos de workflows comuns (famílias de operadores, o loop de debug, montagem de GLSL TOP, binding de áudio, biblioteca do vault), com links para recursos mais ricos. |
-| Trilha de aprendizado | `tdmcp://learning/touchdesigner` | Uma trilha curada que casa o prompt `teach_touchdesigner` com recursos de operadores e tutoriais embutidos. |
-| Cookbook | `tdmcp://cookbook`, `tdmcp://cookbook/{locale}` | O cookbook de prompts como recurso, em inglês (`en`) ou português (`pt`). |
-
-## Descoberta de superfície (sempre ligada)
-
-Para clientes e o copiloto local ficarem em sincronia com o registro real em vez de
-divergirem:
-
-| Família | URI | O que expõe |
-| --- | --- | --- |
-| Comandos | `tdmcp://commands` | Os verbos de CLI, gerados a partir do dispatcher real (seguro / mutante / inseguro). |
-| Prompts | `tdmcp://prompts` | Os prompts MCP que o tdmcp oferece, gerados a partir do registro de prompts. |
-| Perfil de sessão | `tdmcp://session/profile` | O seu perfil persistente entre sessões — veja [Perfil de sessão & aprendizado de corpus](/pt/guide/session-profile). |
-
-## Projeto ao vivo (precisa da ponte)
-
-Quando a [ponte](/pt/guide/install#turn-on-the-bridge) está acessível, dois recursos leem
-o seu projeto em execução. Eles ficam inertes sem um cliente do TD e cacheiam por
-pouco tempo (5 s quente, 1 s offline):
-
-| Família | URI | O que expõe |
-| --- | --- | --- |
-| Resumo de cena | `tdmcp://scene/{view}` | Um snapshot compacto do projeto em execução — `current` (topologia + perf + erros), `operators` (inventário completo) ou `errors` (lista agrupada). |
-| Digest do grafo | `tdmcp://digest/{path}` | Um digest estruturado e barato em tokens (<500 tokens) de uma subárvore: cabeçalho, contagens por família, a cadeia upstream da saída principal e os principais erros agrupados. |
-
-## Bibliotecas opt-in (desligadas por padrão)
-
-Registradas só quando suas flags de feature estão ligadas — veja
-[Perfil de sessão & aprendizado de corpus](/pt/guide/session-profile):
-
-| Família | URI | Gate |
-| --- | --- | --- |
-| Creative RAG | `tdmcp://creative/cards/{id}`, `tdmcp://creative/search` | `TDMCP_RAG_ENABLED=1` |
-| Project RAG | `tdmcp://project/cards/{id}`, `tdmcp://project/search`, `tdmcp://project/sources` | `TDMCP_RAG_ENABLED=1` e `TDMCP_PROJECT_RAG_ENABLED=1` |
-
-Ambas são somente-leitura e carregam URL de origem, licença e notas de direitos em
-cada resultado.
-
-## Veja também
-
-- [Architecture](/reference/architecture) para como os recursos são registrados e
-  servidos.
-- [Perfil de sessão & aprendizado de corpus](/pt/guide/session-profile) para os
-  recursos de perfil de sessão e RAG em profundidade.

package/mcps/tdmcp/docs/pt/guide/mediapipe-adapters.md

@@ -1,93 +0,0 @@
----
-description: "Conecte rastreamento de rosto, mãos, corpo e segmentação do MediaPipe no TouchDesigner com o tdmcp — ferramentas adaptadoras que carregam o plugin gratuito do torinmb e entregam CHOPs e máscaras canônicas e limpas."
----
-
-# Adaptadores MediaPipe
-
-O guia de rastreamento de corpo mostra como *usar* um corpo rastreado. Esta página
-é sobre a camada de baixo: as **ferramentas adaptadoras** que carregam o plugin
-gratuito
-[torinmb/mediapipe-touchdesigner](https://github.com/torinmb/mediapipe-touchdesigner),
-ligam o pipeline que você quer, encontram a saída do engine e te entregam um CHOP ou
-máscara canônica e limpa que você conecta em qualquer coisa.
-
-Use um adaptador quando quiser dados de rosto / mãos / corpo / segmentação como um
-sinal estável — landmarks em coordenadas do TD, uma máscara de pessoa, pontos em
-espaço de tela para UI — em vez de um visual pronto.
-
-## Pegue o plugin
-
-O plugin é licenciado sob MIT e roda em macOS e Windows a partir de uma webcam
-comum. O gerenciador de pacotes do tdmcp pode prepará-lo para você:
-
-```bash
-npx --yes --package=@dpantani/tdmcp tdmcp install mediapipe-touchdesigner
-```
-
-Isso baixa o release MIT e extrai em `~/.tdmcp/packages`; os adaptadores resolvem o
-caminho preparado automaticamente (com fallbacks legados e manuais). Veja
-[Rastreamento de corpo](/pt/guide/body-tracking) para os detalhes de permissão de
-câmera e primeira execução.
-
-::: tip A timeline precisa estar tocando
-O navegador embutido do plugin só captura enquanto a timeline do TD toca. Se os
-dados lerem zero, dê play.
-:::
-
-## Os adaptadores
-
-Cada adaptador carrega o engine (idempotente — reutiliza um existente), liga o
-pipeline que você pedir e constrói um pequeno COMP wrapper cujo Script CHOP/TOP lê a
-saída JSON do engine e a republica como um sinal canônico. Eles sondam os nomes de
-saída do engine entre versões do plugin, então continuam funcionando conforme o
-plugin evolui.
-
-| Adaptador | Layer | O que conecta | Saída |
-| --- | --- | --- | --- |
-| **`setup_body_tracking`** | 1 | Pipeline de pose → um CHOP de pose canônico; opcionalmente constrói um visual de esqueleto. | CHOP de 33 landmarks (`tx`/`ty`/`tz`/confiança), centrado no quadril |
-| **`setup_face_tracking`** | 2 | Pipeline de face-mesh → um CHOP de rosto canônico. | CHOP de 468 (ou 478 com íris) landmarks, centrado no nariz |
-| **`setup_hand_tracking`** | 2 | Pipeline de mãos → um CHOP de mão canônico, em espaço world ou image. | CHOP de `max_hands` × 21 landmarks, com handedness e canais de espaço de tela |
-| **`setup_segmentation`** | 2 | Pipeline de selfie-segmentation → um TOP de máscara com feather, opcionalmente um RGBA pré-chaveado. | TOP de máscara (+ `person_rgba` opcional para compositing direto) |
-| **`setup_mediapipe_plugin`** | 1 | Carrega o engine **uma vez** e liga Face/Hand/Body/Segmentation juntos; descobre e exporta o caminho de saída de cada pipeline. | os caminhos de DAT/TOP descobertos do engine |
-
-> *"Configure o rastreamento de mãos em espaço world para até duas mãos."*
-> *"Configure a segmentação com feather de 12 px e publique uma máscara de pessoa
-> pré-chaveada."*
-
-Use `setup_mediapipe_plugin` quando quiser vários pipelines de um engine numa só
-chamada; use os adaptadores `setup_*` individuais quando quiser exatamente uma
-modalidade e seu wrapper canônico.
-
-## Do adaptador à arte
-
-Os adaptadores produzem sinais; as ferramentas `create_*` os consomem. Aponte a
-fonte de um consumidor para o CHOP/TOP de saída do adaptador e o resto da rede se
-comporta exatamente como no modo sintético:
-
-- **Pose** → `create_pose_tracking`, `create_pose_skeleton`,
-  `create_body_reactive` (veja [Rastreamento de corpo](/pt/guide/body-tracking)).
-- **Mãos** → `create_hand_gesture_bus` (publica canais de gesto estáveis) →
-  `create_hand_hologram`, `create_hand_ableton_mapper`.
-- **Segmentação** → alimente a máscara ou `person_rgba` em qualquer cadeia de
-  compositing.
-
-## Receitas prontas
-
-Três templates navegáveis acompanham a [galeria de receitas](/pt/guide/recipes) —
-diga *"liste as receitas"*:
-
-- **Pose Skeleton (MediaPipe)** — o esqueleto de palito a partir de uma webcam ao
-  vivo.
-- **MediaPipe Body Dots** — pontos brilhantes rastreando cada junta.
-- **MediaPipe Face Overlay** — uma nuvem de pontos sobre o vídeo ao vivo a partir
-  dos landmarks de rosto.
-
-Cada uma espera o plugin carregado; aponte seu Select CHOP para a saída do adaptador
-correspondente.
-
-## Veja também
-
-- [Rastreamento de corpo](/pt/guide/body-tracking) — o guia do lado consumidor e o
-  passo a passo de câmera/primeira execução.
-- [Reativo a câmera & movimento](/pt/guide/prompt-cookbook#reativo-a-camera-movimento)
-  no cookbook de prompts.

package/mcps/tdmcp/docs/pt/guide/physical-installations.md

@@ -1,135 +0,0 @@
----
-description: "Como montar projetos tdmcp confiáveis para salas, projetores, sensores e hardware externo sem confundir demo com instalação validada."
----
-
-# Instalações físicas
-
-Instalações com hardware falham de um jeito diferente de visuais puros. A rede
-pode montar sem erro, o preview pode parecer certo, e a sala ainda estar errada
-porque o sensor vê a parede de outro ângulo, o projetor está fora do campo da
-câmera, a interface de áudio está em outro sample rate, ou um plugin de device
-derruba o TouchDesigner na inicialização.
-
-A harpa de parede com Kinect transformou esses problemas num padrão reutilizável
-para o tdmcp: construir a obra, o diagnóstico e a fronteira com hardware como
-partes separadas.
-
-## A forma confiável
-
-Use esta ordem para projetores, câmeras de profundidade, MIDI/OSC e sensores de
-sala:
-
-1. **Construa primeiro uma versão segura com fonte sintética.** O componente deve
-   renderizar, expor controles e gerar entrada de teste plausível sem hardware
-   conectado.
-2. **Adicione uma tela de diagnóstico antes da calibração.** Mostre o que o
-   device realmente vê: RGB/profundidade/IR, crops, proporção de amostras válidas
-   e blobs candidatos. Não comece ajustando a arte final.
-3. **Mantenha hardware instável fora do `.toe` principal.** Se um plugin ou SDK
-   pode derrubar o TouchDesigner, rode em um processo auxiliar e envie OSC, MIDI,
-   UDP, WebSocket ou arquivos normalizados para o TD.
-4. **Calibre na superfície projetada.** Coloque o wizard ou padrão de calibração
-   na mesma saída de projetor que o performer vai usar. Calibração cronometrada
-   por chat é frágil demais para setup de sala.
-5. **Separe claims ao vivo de gates offline.** Typecheck, testes e preview
-   sintético provam o formato da ferramenta. Um passe na sala prova sensor,
-   projetor, interface de áudio e distância do performer.
-
-## O que o Kinect ensinou
-
-- **Câmera de profundidade não é tela touch mágica.** O Kinect detecta
-  descontinuidades de profundidade perto do plano da parede; ele não entende
-  linhas projetadas ou cores como áreas tocáveis. O software mapeia blobs
-  rastreados para a coordenada da projeção.
-- **As coordenadas de sensor e projeção precisam ser explícitas.** Uma mão no
-  lado direito da parede pode acionar o lado esquerdo se crop, espelho ou eixo Y
-  forem chutados.
-- **Marcadores de debug podem enganar.** Mãos sintéticas ajudam no ensaio, mas o
-  overlay de debug precisa desligar claramente quando não há tracking real.
-- **Problema de áudio muitas vezes é runtime, não volume.** Um synth com ruído ou
-  glitch pode vir de sample rate, clipping interno, vozes demais em paralelo ou
-  dispositivo de saída errado.
-- **Reiniciar helper faz parte da feature.** Um stream de profundidade travado
-  deve reiniciar o processo auxiliar ou marcar tracking offline; não deve
-  congelar silenciosamente a ponte. No bridge da harpa Kinect, use
-  `--status-json <path>` quando um operador ou componente TD gerado precisar de
-  uma superfície de saúde legível por máquina. Projetos gerados por
-  `create_kinect_wall_harp` leem o mesmo arquivo no DAT `bridge_status` e
-  expõem canais numéricos no `bridge_status_chop`.
-- **Crop de projetor deve vir de RGB mais depth registrado.** Quando Kinect e
-  projetor enxergam a mesma parede, rode primeiro o padrão de calibração da
-  projeção e o diagnóstico externo do ambiente. O diagnóstico grava
-  `/tmp/kinect_environment_diagnostic.json`; passe esse arquivo para
-  `scripts/kinect-wall-harp-bridge.mjs --projection-calibration-json ...` para a
-  ponte usar `registered_projection_bbox` como crop de profundidade. O contrato
-  OSC preserva tanto os pontos no espaço do crop/projetor (`x/y`) quanto as
-  coordenadas registradas completas (`raw_x/raw_y`), permitindo que componentes
-  TD reutilizem os controles `Input*` da wall harp para o alinhamento final.
-
-## Ferramentas atuais
-
-- **`create_kinect_wall_harp`** monta a harpa de linhas projetadas com fallback
-  sintético, modo OSC Kinect, controles de calibração e synth interno.
-- **`scripts/create-kinect-projection-calibration-pattern-td.py`** projeta o alvo
-  de sala de alto contraste, e **`scripts/kinect-environment-diagnostic.cpp`**
-  lê RGB/profundidade/IR do Kinect com registro do libfreenect2 para gerar o JSON
-  de crop de projeção usado pelo bridge OSC.
-- **`create_test_pattern`** dá à sala um alvo visível antes de projection mapping
-  ou calibração.
-- **`create_interactive_projection_mapping`** é o rig de ensaio para movimento de
-  câmera ou fonte sintética dirigindo uma saída de projetor.
-- **`create_live_source`** monta entradas de câmera, NDI, Syphon/Spout,
-  screen-grab ou vídeo de rede e agora expõe `source_status` e
-  `source_status_chop` para o projeto gerado saber se a fonte está ausente,
-  aguardando, com falha ou rodando.
-- **`create_depth_silhouette`** e **`create_blob_reactive`** são opções mais leves
-  quando a obra precisa de máscaras ou blobs rastreados em vez de um instrumento
-  customizado. `create_depth_silhouette` também expõe `source_status` e
-  `source_status_chop` para a fonte escolhida: sintética, arquivo ou sensor de
-  profundidade ao vivo.
-- **`create_external_io`** é a rota padrão para OSC, MIDI, DMX, NDI e
-  Syphon/Spout.
-- **`diagnose_hardware_environment`** é o primeiro preflight genérico da sala:
-  checa se a bridge responde, se há displays/projetores suficientes e se DATs
-  gerados como `source_status` / `bridge_status` estão saudáveis antes da
-  calibração.
-- **`watch_node`**, **`get_node_state_runtime`** e
-  **`inspect_gpu_and_displays`** ajudam a verificar se o projeto TD está cozinhando
-  e saindo no display correto.
-
-## Backlog que saiu do Kinect
-
-A harpa aponta para um pequeno kit reutilizável de instalação:
-
-| Candidato | O que adicionaria | Por que importa |
-|---|---|---|
-| extensões de `diagnose_hardware_environment` | Adicionar métricas de frames RGB/profundidade e checagens de device de áudio ao preflight já entregue para bridge/display/status-DAT. | O artista precisa saber se a sala está errada antes de ajustar a obra. |
-| `create_projection_calibration_wizard` | Refinar o crop automático por bbox registrado para calibração por pares de pontos projetados/ChArUco com homografia salva. | O crop automático agora é o primeiro passe padrão; pose precisa do modelo de calibração mais rico. |
-| `run_external_sensor_bridge` | Supervisor reutilizável para processos de sensor, com detecção de dado velho, política de restart e saída OSC/WebSocket/status JSON normalizada. | Isolamento de crash e restart não devem ser reimplementados por device. |
-| `external_sensor_status_surface` | Primitivo compartilhado para builders gerarem superfícies DAT/CHOP a partir de status JSON de helpers externos ou status local de operadores TouchDesigner. | Toda ferramenta de sensor físico deve expor a mesma forma de saúde para painéis, overlays e lógica. |
-| `diagnose_audio_device` | Checagens de device de saída, sample rate, clipping e contagem de vozes para cadeias de áudio TD. | Áudio com glitch é comum em instrumentos interativos e precisa de checklist próprio. |
-| `organize_generated_project` | Move, rotula e limpa COMPs gerados sob `/project1` preservando diagnósticos úteis. | Iteração ao vivo deixa sobras; a limpeza precisa ser segura e explicar o que ficou. |
-
-Trate esses itens como próximos slices, não como capacidades já entregues. Cada
-um precisa de um formato de teste offline e, quando envolver hardware, uma nota
-de validação ao vivo.
-
-## Checklist de sala
-
-Antes de chamar uma instalação física de pronta:
-
-- a saída final está no projetor ou display correto;
-- a tela de diagnóstico mostra frames ou canais vivos do device real;
-- o fallback sintético é visualmente diferente do tracking ao vivo;
-- crop, espelho e eixo Y foram verificados com toques à esquerda/direita e
-  topo/base;
-- o áudio sai na interface pretendida e não clipa;
-- processos auxiliares se recuperam de travamentos ou falham com status visível;
-- o componente final ainda renderiza quando o hardware é desconectado.
-
-## Veja também
-
-- [Receitas de prompt](/pt/guide/prompt-cookbook#saida-mapeamento)
-- [Geradores Layer-1](/pt/guide/generators#instalacoes-estudos)
-- [Solução de problemas](/pt/guide/troubleshooting)
-- [Bridge & REST API](/reference/bridge-api)