Arquitetura e Fluxos — Hermes, Foundry e Ecossistema RPG

Regra de governança inviolável

Endpoints Tailscale, diretórios Syncthing, caminhos absolutos/relativos, método de acesso e política de escrita descritos aqui são restrições operacionais. Hermes não pode alterar, contornar ou substituir qualquer um deles sem: (1) apresentar o motivo técnico; (2) delimitar impacto e rollback; e (3) obter aprovação explícita e prévia de Yan.

Segredos

Este documento registra nomes de variáveis e arquivos de credenciais, mas não contém senhas, API keys, tokens, salts nem IDs privados completos de dispositivos. Credenciais continuam nos arquivos apropriados (.env, ~/.foundry-api.sh, configuração do Syncthing).

0. Escopo, método e estado da auditoria

Auditoria executada em 2026-07-30 18:22 BRT/ESAST (UTC-3), combinando:

1. testes HTTP/Tailscale e MCP sem escrita;
2. inspeção do estado vivo da b450m e da VM Oracle;
3. leitura de options.json, manifests de worlds/systems/modules e configurações Syncthing;
4. consulta da documentação oficial viva de foundryrestapi.com/docs;
5. leitura do código local de foundryvtt-mcp e 5e-statblock-importer;
6. revisão de sessões históricas, erros, correções e validações feitas por Yan;
7. consolidação das skills locais de Foundry, Obsidian, D&D 5e, WoD5e e TOR2e.

Estado observado, em uma linha

• b450m Foundry: offline em 100.72.191.109:30000 e 127.0.0.1:30000 no momento da auditoria.
• VM Foundry: online em 100.108.186.76:30000, Foundry 13.351, world vivo pathfinder2e-kingmaker, sistema PF2e 7.12.2.
• Foundry REST relay: chave válida, seis clients cadastrados, todos isOnline: false; portanto CRUD/execute-js não pôde ser validado end-to-end sem abrir uma sessão de browser do módulo.
• MCP Windows: fvtt-b450m-to-b450m e fvtt-b450m-to-oracle iniciaram o transporte stdio, mas terminaram em Connection closed; os dois MCPs Linux falharam no Windows como esperado (/usr/bin/node inexistente).
• Syncthing: VM íntegra e em sync para Foundry; b450m com 234 arquivos pendentes/erros no folder Foundry, principalmente colisões de caixa de nomes, além de aproximadamente 2,7 mil arquivos sync-conflict históricos, incluindo 279 no escopo de LevelDB de worlds.

---

1. Diagnóstico de logs e testes de conexão

1.1 Resultados dos testes ativos

Teste	Resultado	Latência/estado	Interpretação
http://100.72.191.109:30000/api/status	falhou	~2,04 s, conexão recusada	Foundry local b450m não estava ouvindo em :30000
http://127.0.0.1:30000/api/status na b450m	falhou	~2,05 s, conexão recusada	confirma ausência de listener local
http://100.108.186.76:30000/api/status	HTTP 200	~0,043 s total	Tailscale e Foundry VM operacionais
VM → 127.0.0.1:30000/api/status	HTTP 200	~0,0034 s	processo Foundry local à VM saudável
SSH alias foundry	sucesso	batch auth	acesso administrativo à VM operacional
PM2 VM	foundry:online	processo ativo	não foi reiniciado nem interrompido
Syncthing VM	ativo	processo PID presente	sincronização em execução
REST relay /clients	HTTP/autenticação válidos	6 clients, todos offline	relay acessível, mas nenhum world conectado por browser
MCP b450m→b450m	falhou	Connection closed em ~9,9 s	esperado enquanto Foundry local está offline
MCP b450m→Oracle	falhou	Connection closed em ~8,6 s	HTTP chega à VM, mas handshake/auth MCP não concluiu; provável incompatibilidade de usuário/world ativo ou erro no fluxo Socket.IO

Próxima verificação segura para o MCP Oracle

Antes de qualquer write:

1. confirmar que o usuário hermes-mcp existe no world atualmente ativo (pathfinder2e-kingmaker);
2. testar o fluxo de autenticação Socket.IO de quatro etapas contra o world vivo;
3. capturar stderr/debug do MCP sem imprimir senha;
4. executar hermes mcp test fvtt-b450m-to-oracle novamente;
5. só após Connected + descoberta de tools, executar uma leitura (get_world_summary);
6. não usar FOUNDRY_WRITE_ENABLED=true como permissão implícita para mutar dados.

1.2 O que funcionou historicamente

Foundry REST API

• GET /clients com x-api-key carregado de ~/.foundry-api.sh.
• PUT /update quando clientId e uuid são passados em query parameters.
• organização de Item, Actor e Folder sem execute-js: criar com POST /create ou POST /create-folder, depois atribuir/mover com PUT /update?uuid=<Tipo>.<id> e data.folder contendo o ID da pasta pai.
• POST /execute-js usando payload JSON gerado em arquivo/pipe, evitando escaping frágil.
• criação de páginas via JournalEntry.createEmbeddedDocuments("JournalEntryPage", ...) e atualização posterior do conteúdo.
• HTML renderizado com text.format: 1 no Foundry v13.
• operações complexas via execute-js, seguidas de releitura por /get, /structure ou JavaScript vivo.
• assets em WebP copiados para a raiz correta e referenciados por caminho relativo images/....

MCP/Socket.IO e D&D 5e

• parser local import_dnd5e_statblock registrado e compilado no MCP;
• criação de Actor por modifyDocument('Actor', 'create') com persistência confirmada por conexão Socket.IO fresca;
• correção de cache adicionando o Actor recém-criado a worldData.actors;
• create_actor_item como rota validada para items que exigem Active Effects;
• IDs de activities/Active Effects com exatos 16 caracteres alfanuméricos;
• vinculação activity.effects[]._id === item.effects[]._id;
• saves com dc.calculation ligado ao atributo ou spellcasting, em vez de fórmula fixa quando o DC deriva do Actor;
• recharge 5–6 representado por formula: "5", period: "recharge", type: "recoverAll";
• verificação por Socket.IO fresco/UI em vez de confiar no cache MCP.

5e Statblock Importer

Módulo instalado: 5e-statblock-importer 2.3.15.

API confirmada no README e código do módulo:

const api = game.modules.get("5e-statblock-importer").api;
const parsed = api.parse(statblockText);
const { actor5e, importIssues } = await parsed.actor.createActor5e(folderId);
// ou
const { actor5e, importIssues } = await api.import(statblockText, folderId);

O parser exige layout WotC padrão. O resultado de parse() contém actor, statBlocks, lines e unknownLines. Spells na Spellbook dependem do compendium de spells instalado. A execução dentro do client Foundry preserva hooks e validação do sistema melhor do que criar payloads parciais externamente.

1.3 Falhas históricas, causas e correções

Falha	Causa comprovada/provável	Solução operacional validada
Agent preso navegando UI sem criar ficha	escolha do caminho indireto	parser → schema → criação direta → releitura → UI apenas para QA
Actor criado, mas MCP não encontra	cache worldData stale	sincronizar cache no createActor ou verificar via Socket.IO fresco
refreshWorldData() timeout	world aguardando atualização de packs/cache	não usar como única verificação; abrir nova conexão
t is not a function após create	consequência do fluxo do world, não prova de não persistência	conferir LevelDB/Socket.IO vivo antes de diagnosticar perda
Items sem features/actions	activity IDs curtos/inválidos e schemas incompletos	IDs de 16 chars e template completo de activity
Effects existentes, mas não aplicados	referência da activity aponta para ID antigo	reconciliar IDs após clone/create
Active Effects ignorados em items embedded	rota Socket.IO de create não materializou effects	recriar item via create_actor_item com source.type: "inline"
Spell criada manualmente incorreta	school/range/duration/properties/target incompletos	copiar do compendium e usar spellcasting
Journal criado vazio	conteúdo enviado ao campo flat content ou não relido	JournalEntryPage + format: 1; verificar página e conteúdo
Campaign Codex vazio	texto colocado em pages, mas sheet lê flags	usar flags.campaign-codex.data.description/notes
REST Invalid client ID	relay/browser desconectado ou flutuação	esperar client online, retry curto, nunca reiniciar Foundry como “fix”
REST Entity not found no update	uuid/clientId no body	mover ambos para query string
folder ignorado no create	limitação/quirk do endpoint	criar primeiro; mover com PUT /update (uuid e clientId na query string; data.folder com o ID da pasta). Não requer execute-js; reler a estrutura/pasta depois.
LevelDB inconsistente	o mesmo world aberto nos dois hosts ou sync incompleto de runtime	sincronização total por pasta de world; nunca abrir o mesmo world simultaneamente nas duas pontas; ignorar só travas/temporários cirúrgicos
caminhos VM escritos no Windows	options.json sincronizado entre SOs	CLI --dataPath correto por host; não confiar no arquivo sincronizado

---

2. Matriz de infraestrutura e rede

2.1 b450m versus VM

Camada	b450m (Windows 10)	VM Oracle (Ubuntu)
Host Hermes	perfil default em C:\Users\Yanbd\AppData\Local\hermes	réplica em ~/.hermes via Syncthing
Foundry app	C:\Users\Yanbd\foundry-app\v13.351\	/home/ubuntu/foundry/
Foundry data root	C:\Users\Yanbd\foundry-data\v13\	/home/ubuntu/Data/
Conteúdo Foundry (Data)	C:\Users\Yanbd\foundry-data\v13\Data\	/home/ubuntu/Data/Data/
Imagens	...\Data\images\	/home/ubuntu/Data/Data/images/
Worlds	...\Data\worlds\	/home/ubuntu/Data/Data/worlds/
Config	...\Config\	/home/ubuntu/Data/Config/
Foundry interno	127.0.0.1:30000 quando ativo	127.0.0.1:30000
Tailscale	100.72.191.109:30000	100.108.186.76:30000
Processo	app Windows; offline na auditoria	PM2 → bash → node ... --dataPath=/home/ubuntu/Data --port=30000
Syncthing folder	foundry-data-v13 → raiz Windows	foundry-data-v13 → ~/Data
Policy de write MCP viva	.env: true	.env.vm usado pela b450m: true; requer governança manual

Divergência de policy

A documentação histórica dizia que Oracle era read-only, mas os .env vivos da b450m tinham FOUNDRY_WRITE_ENABLED=true tanto para local quanto para VM. O valor vivo é tecnicamente efetivo; a regra de governança deste documento é mais restritiva: nenhum write de produção sem intenção explícita da tarefa e verificação do world ativo.

2.2 URIs e regra de roteamento

Origem	Destino	URI correta	MCP pretendido
Hermes na b450m	Foundry b450m	http://100.72.191.109:30000	fvtt-b450m-to-b450m
Hermes na b450m	Foundry VM	http://100.108.186.76:30000	fvtt-b450m-to-oracle
Hermes na VM	Foundry VM	http://127.0.0.1:30000	fvtt-oracle-to-oracle
Hermes na VM	Foundry b450m	http://100.72.191.109:30000	fvtt-oracle-to-b450m
Automação REST em qualquer host	relay	https://foundryrestapi.com	HTTP + clientId do world

Regras:

1. nomenclatura MCP é origem-to-destino;
2. MCP Windows usa Node/path Windows; MCP Linux usa /usr/bin/node;
3. não trocar Tailscale por hostname público, tunnel, localhost remoto ou relay REST sem aprovação;
4. sempre chamar /api/status antes de assumir world/sistema ativo;
5. DOTENV_CONFIG_PATH deve estar em env:, nunca em args:;
6. não registrar segredos no YAML compartilhado se houver arquivo .env local apropriado.

Acesso ao PC local quando está suspenso

Os endpoints Tailscale documentados nesta matriz dependem de a b450m estar ligada e com a rede operacional; eles não constituem, por si só, um mecanismo para acordar o PC. Para acesso remoto após suspensão, Wake-on-LAN (WoL) é uma possibilidade a ser validada no hardware, BIOS/UEFI, adaptador de rede e Windows.

Um acionamento remoto de WoL requer um emissor que permaneça ligado na LAN da b450m e consiga enviar o Magic Packet ao adaptador de rede. Um dispositivo local alcançável pela tailnet — por exemplo, configurado também como subnet router quando isso for necessário para os demais recursos da LAN — pode cumprir esse papel. Isto é uma arquitetura possível, não confirmação de que exista um emissor configurado hoje.

Antes de adotar: verificar suporte a WoL por Ethernet no PC, comportamento em suspensão/hibernação, configuração do roteador e realizar teste de ponta a ponta. Qualquer mudança de rede ou de acesso remoto continua sujeita à regra de governança deste documento.

Fontes consultadas em 2026-08-24:

• Microsoft Learn, Unwanted wake-up events when you enable WOL
• Tailscale Docs, Subnet routers

2.3 Estado vivo dos worlds

• VM viva: pathfinder2e-kingmaker — título Pathfinder2e Season of Ghosts, PF2e 7.12.2.
• b450m Config/options.json: raiders-of-the-serpent-sea, mas o serviço local estava offline.
• VM Config/options.json sincronizado também contém path Windows e raiders-of-the-serpent-sea, mas o PM2 força --dataPath=/home/ubuntu/Data; o world vivo era outro.

Não confiar em options.json sincronizado

O estado vivo de /api/status e os argumentos do processo têm precedência. Nunca escrever em um world com base apenas no options.json.

---

3. Syncthing, conflitos e matriz de paths

3.1 Folders sincronizados

Folder ID	b450m	VM	Tipo
foundry-data-v13	C:\Users\Yanbd\foundry-data\v13	~/Data	send-receive
hermes-agent-yan	C:\Users\Yanbd\AppData\Local\hermes	~/.hermes	send-receive
obs-sync-yan	C:\Users\Yanbd\dev\Wiki-Yan	~/Wiki-Yan	send-receive
guias-dnd-5e	não confirmado nesta b450m config	~/DnD5e-Drive/Guias	send-receive na VM
obs-raquel	não faz parte do vault Yan	~/obsidian-syncthing-raquel	fora do escopo

3.2 Auditoria de integridade Syncthing

Arquitetura multi-world — regra de ouro

• worlds, systems e modules são sincronizados integralmente para redundância e trabalho paralelo.
• Cada campanha tem banco isolado em Data/worlds/<world-id>/.
• Mundos diferentes podem ficar abertos/ser editados em paralelo na b450m e na VM.
• O mesmo world nunca pode ficar aberto simultaneamente nos dois hosts. Antes de trocar um world de host, aguardar o Syncthing concluir e verificar needFiles=0/errors=0 para aquele conteúdo.
• .ldb, .log, CURRENT e MANIFEST-* ativos são dados reais e permanecem sincronizados.
• O .stignore cirúrgico, idêntico nos dois hosts, ignora apenas LOCK/lock, LOG.old, MANIFEST-*.tmp, .DS_Store e Thumbs.db.

Reparo autorizado de 2026-07-31

• Backup integral pré-limpeza: C:\Users\Yanbd\foundry-backups\worlds-pre-syncthing-cleanup-20260731-103117.tar.gz (609.816.958 bytes; SHA-256 71d9a7f19a15375aaabc483754bcaf313304b055c7797ebc7794d9664c995a8d; gzip PASS; 6.499 entradas).
• 2.738 arquivos *.sync-conflict-* removidos na b450m, sendo 282 sob Data/worlds/*/data/*.
• Pós-check: zero conflitos restantes; arquivos normais preservados 183.723 → 183.723; .ldb normais preservados 5.236 → 5.236.
• Manifesto da exclusão: C:\Users\Yanbd\foundry-backups\removed-sync-conflicts-20260731-104454.tsv.
• VM após rescan: idle, 150438/150438, needFiles=0, errors=0.
• b450m após rescan: idle, 150204/150438, 234 pull errors/pendências residuais de case collision em assets; não são novos .sync-conflict e exigem tratamento separado por renomeação coordenada.

Leitura forense offline de LevelDB (registro de 2026-09-08)

Relato de execução em lote de curadoria: uma técnica Python leu dados de campanhas Foundry v13 diretamente de arquivos LevelDB (.ldb/SSTable e .log/WAL) sem iniciar o servidor. O procedimento relatado percorre índices varint e usa cramjam.snappy.decompress_raw para descompactar blocos Snappy brutos, visando recuperar documentos como Actors, biografias HTML e itens embutidos.

Limite operacional

Isto é somente um recurso de leitura forense e ainda não foi validado independentemente neste vault. Não editar, reempacotar ou usar a leitura direta como confirmação de persistência. Para alterações, continuam valendo o Foundry/API/Socket.IO, a releitura por conexão fresca e a proibição de manipular LevelDB com o Foundry aberto.

3.3 Regra para novas imagens

1. Produzir/stagear em C:\Users\Yanbd\Downloads\<lote>\ para aprovação quando for arte gerada por IA.
2. Após aprovação, escolher um único writer canônico por lote.
3. Para conteúdo que será usado na VM, publicar em /home/ubuntu/Data/Data/images/<campanha>/<categoria>/ e aguardar Syncthing.
4. Para conteúdo exclusivamente local/offline, publicar em C:\Users\Yanbd\foundry-data\v13\Data\images\... somente se a b450m for o writer deliberado.
5. Nunca editar o mesmo filename nos dois hosts durante a mesma janela.
6. Sempre versionar: arquivo-v1.webp, arquivo-v2.webp; nunca sobrescrever.
7. Confirmar no destino: arquivo existe, decodifica, tamanho/alpha corretos e URL relativa responde.
8. Só então atualizar img, prototypeToken.texture.src ou HTML do journal.

Integridade em cópias entre VM e Windows (registro de 2026-08-28)

Relato operacional local: uma cópia de PDF entre a VM e o PC Windows apresentou divergência de tamanho no destino. Uma nova cópia igualou os tamanhos. O relato não isola a causa da divergência; portanto, não deve ser tratado como falha confirmada de SCP, SSH, Tailscale ou do arquivo de origem.

Procedimento obrigatório para arquivos relevantes ou grandes

Após qualquer cópia direta entre hosts, comparar o tamanho de origem e destino e abrir/decodificar o arquivo no destino. Para artefatos que não possam ser validados por abertura, registrar também um checksum gerado em ambos os lados. Não considerar upload, backup ou espelhamento concluído apenas pela saída bem-sucedida do comando de transferência.

Evidência local: lote de captura batch-1bbd835f4574468ca3b04433bc1ef240, evento c68fe1d7ae882566c85fbf59. Consultado em 2026-09-28.

3.4 Matriz de equivalência de caminhos

Foundry relativo	b450m absoluto	VM absoluto
images/<campanha>/<categoria>/arquivo-vN.webp	C:\Users\Yanbd\foundry-data\v13\Data\images\<campanha>\<categoria>\arquivo-vN.webp	/home/ubuntu/Data/Data/images/<campanha>/<categoria>/arquivo-vN.webp
images/rotss/creatures/<Nome>-vN.webp	...\Data\images\rotss\creatures\<Nome>-vN.webp	/home/ubuntu/Data/Data/images/rotss/creatures/<Nome>-vN.webp
images/rotss/unnoficial/tokens/td_<Nome>-vN.webp	...\Data\images\rotss\unnoficial\tokens\td_<Nome>-vN.webp	/home/ubuntu/Data/Data/images/rotss/unnoficial/tokens/td_<Nome>-vN.webp
images/rome-modern/characters/<Nome>-vN.webp	...\Data\images\rome-modern\characters\<Nome>-vN.webp	/home/ubuntu/Data/Data/images/rome-modern/characters/<Nome>-vN.webp
images/rome-modern/sessions/<Cena>-vN.webp	...\Data\images\rome-modern\sessions\<Cena>-vN.webp	/home/ubuntu/Data/Data/images/rome-modern/sessions/<Cena>-vN.webp
images/over-hill-under-hill/tokens/<Nome>-vN.webp	...\Data\images\over-hill-under-hill\tokens\<Nome>-vN.webp	/home/ubuntu/Data/Data/images/over-hill-under-hill/tokens/<Nome>-vN.webp
worlds/<world>/data/actors/*	...\Data\worlds\<world>\data\actors\*	/home/ubuntu/Data/Data/worlds/<world>/data/actors/*

Caminhos Foundry sempre usam /, sem / inicial e sem prefixo Data/.

---

4. Ecossistema MCP multi-sistema

4.1 Princípio central

O endereço base conecta ao Foundry ativo, não a um sistema fixo. O MCP carrega worldData do world vivo. A seleção de schema é determinada por world.system, manifests locais e payloads do sistema. Não há roteamento mágico “por nome de campanha”.

Fluxo obrigatório:

/api/status → confirmar world + system + version
→ escolher schema/tool compatível
→ leitura/parse
→ payload versionado/reversível
→ write somente se autorizado
→ releitura pelo Foundry vivo
→ verificação visual quando player-facing

4.2 Campanhas e sistemas

Campanha solicitada	World observado	Sistema	Estratégia
Raiders of the Serpent Sea	raiders-of-the-serpent-sea	dnd5e	parser 5e/MCP + schema dnd5e 5.2.5; biografias e assets RotSS
Heróis de Thylea / Odyssey	heroes-of-thylea, heroes-of-thylea-friday, herois-de-tylea-sunday	dnd5e	fonte: MD/PDF da campanha; compendium/5e.tools só para criatura genérica
Descendo ao Avernus	descendo-ao-avernus; continuação chains-of-asmodeus	dnd5e	dnd5e 5.2.5; Campaign Codex/journals conforme world
Rusthenge / Season of Ghosts	pathfinder2e-kingmaker (título vivo: Season of Ghosts)	pf2e	usar compendia PF2e e schemas do sistema; não usar importer dnd5e
Roma Aeterna	rome-chronicle-vampire	wod5e	actors completos wod5e, Campaign Codex, powers/clan/items
Sombras de Merritt	sombras-de-merritt	dnd5e no manifest auditado	pode usar adereços narrativos de VTM, mas MCP/API devem usar exclusivamente schema dnd5e
Over Hill and Under Hill	over-hill-and-under-hill	tor2e	journals/source-first, scenes sem grade para mapas de referência, tokens/portraits separados

4.2.1 Registro de provisão — Heróis de Thylea (2026-09-07)

No world heroes-of-thylea-friday, as espécies, subclasses e antecedentes épicos do Heroes Handbook foram cadastrados como conteúdo de criação de personagem para as seguintes combinações:

Personagem	Espécie	Classe e subclasse	Antecedente épico
Anesidora	Automatos	Ranger — Amazonian Conclave	The Exile
Brick Rustfuse	Deep Gnome (Svirfneblin)	Artificer	The Cursed One
Kallistos	Sereira Tyleana	Warlock — The Sphinx Patron	The Timeless One
Lysandros	Humano (Tyleano)	Paladin — Oath of the Dragonlord	The Haunted One
Orelios	Humano (Tyleano)	Rogue — The Odyssean	The Vanished One
Semestra	Nymph	Não informado no registro de execução	The Demigod (Vallus)

• O conteúdo mecânico deve continuar sendo conferido contra os materiais de criação locais antes de uma alteração; não usar IDs de documento como referência durável.
• Modelo de vínculo dnd5e (registro declarado no lote de curadoria de 2026-09-07): species, subclasses e epic backgrounds foram modelados como Item de criação, com as features completas em inglês na description e referências @UUID para os documentos de feature. Subclasses devem declarar o classIdentifier; species, subclasses e backgrounds concedem as features pelo avanço ItemGrant. Confirmar o schema e os UUIDs no world ativo antes de reutilizar o padrão.
• Fontes locais relacionadas: Guia de Criação de Personagens de Thylea, Bruxo — Patrono da Esfinge e The Timeless One.

4.2.2 Correção de identidade — Brick Rustfuse (2026-09-11)

Correção confirmada no registro de execução de 2026-09-11: o personagem que usa o antecedente épico The Cursed One é Brick Rustfuse, um Deep Gnome (Svirfneblin) Artificer. Ele recebeu as features Cursed One, Blessing of the Gods e Heroic Tasks: The Cursed One.

• Este registro substitui a atribuição anterior a um personagem chamado Brontes, que não é sustentada pela execução posterior.
• A mecânica e o texto das features permanecem em inglês nos Item de criação; conferir a fonte local antes de editar ou reutilizar conteúdo.
• Não usar IDs de documentos do registro como referência durável. Confirmar schema, UUIDs e efeitos no world ativo antes de qualquer alteração.
• Fontes locais: Appendix A — Creating Heroes e The Cursed One.

4.2.3 Associação de Semestra — Nymph e The Demigod (Vallus) (2026-09-11)

O registro de execução de 2026-09-11 associa Semestra à espécie Nymph e ao antecedente épico The Demigod (Vallus) no world heroes-of-thylea-friday, em dnd5e. A espécie foi registrada com as ancestralidades Aurae, Dryad, Naiad, Nereid e Oread; o antecedente inclui a Blessing of Wisdom, as tarefas heroicas e o item de escolha Pendant of the Sun.

• A classe ou subclasse de Semestra não consta no registro de execução disponível; confirmar no world ativo antes de documentá-la.
• A fonte local define Nymph como espécie nativa de Thylea e descreve suas ancestralidades e magias. O antecedente de Vallus exige nativo de Thylea e apresenta a busca pelo pai, os segredos de Vallus e a herança como tarefas heroicas.
• Não usar IDs de Item do relato como referências duráveis. Antes de editar ou reutilizar a implementação, conferir o texto e os valores contra as fontes locais e confirmar os ItemGrant, UUIDs e efeitos no world ativo.
• Fontes locais: Appendix B — Playable Races e The Demigod (Vallus).

4.2.4 Tokens dos seis heróis — Heroes of Thylea Friday (2026-09-11)

Confirmado no registro de execução de 2026-09-11: os tokens top-down de Anesidora, Brick Rustfuse, Kallistos, Lysandros, Orelios e Semestra foram gerados, receberam alpha transparente e foram configurados nos respectivos Actors do world heroes-of-thylea-friday.

• A orientação declarada é câmera estritamente vertical a 90°, personagem voltado ao sul e equipamento contido na silhueta.
• O lote seguiu geração com fundo chroma verde e remoção posterior, com entrega intermediária em Downloads.
• Os tokens devem permanecer versionados; antes de qualquer substituição, confirmar o arquivo RGBA/WebP, o caminho relativo no Foundry e o prototypeToken.texture.src no world ativo. Aplicar as regras gerais de tokens e de versionamento de imagens desta nota.

4.2.5 Assets de Taneias e Javon — Heroes of Thylea Friday (2026-09-11)

Registro declarado de execução, ainda sem releitura independente do world: portraits e tokens top-down de Taneias e Javon, ambos Scouts, foram gerados e associados aos Actors correspondentes no world heroes-of-thylea-friday.

• Taneias: caçador veterano de Thylea, com couro batido, manto verde com capuz, arco recurvo e aljava. Arquivos relatados: taneias_portrait_v1.webp e td_taneias_v1.webp.
• Javon: jovem caçador com túnica em tons terrosos, armadura leve de batedor, lança curta, arco e aljava. Arquivos relatados: javon_portrait_v1.webp e td_javon_v1.webp.
• Os tokens são declarados como vista estritamente vertical a 90°, voltados ao sul e com alpha transparente. Os arquivos foram versionados em v1.
• Antes de depender desses assets em jogo, confirmar no Foundry ativo o img e o prototypeToken.texture.src de cada Actor, a existência dos WebP no armazenamento e o canal alpha; não usar IDs de Actor como referência durável.

4.2.6 Tokens dos heróis — Over Hill and Under Hill (2026-09-13)

Registro declarado de execução, sem releitura independente do world: quatro tokens top-down foram gerados e configurados como prototypeToken dos respectivos Actors no world over-hill-and-under-hill (TOR2e). A entrega reporta alpha real com despill e orientação vertical a 90°, voltada ao sul.

Herói reportado	Cultura / papel reportado	Arquivo reportado
Valakhir	Haradrim Warden	images/over-hill-under-hill/tokens/td_valakhir-v1.webp
Thalion	Man of Dol Amroth Captain	images/over-hill-under-hill/tokens/td_thalion-v1.webp
Vohnkar	Wilderland Hobbit Champion	images/over-hill-under-hill/tokens/td_vohnkar-v1.webp
Poppy	Men of Bree Messenger	images/over-hill-under-hill/tokens/td_poppy-v1.webp

• As recaps de sessão usam as grafias Valakir e Vonkar; o registro deste lote usa Valakhir/Vohnkar, inclusive nos filenames. Tratar os caminhos acima como identificadores literais até uma conferência do world ativo, sem renomear assets por inferência.
• Antes de reutilizar ou substituir esses tokens, confirmar no Foundry vivo a associação de cada Actor, prototypeToken.texture.src, existência e decodificação do WebP, e canal alpha. Aplicar as regras gerais de tokens e de versionamento desta nota.

4.2.7 Gundovald — Over Hill and Under Hill (2026-10-04)

Registro declarado de execução; não revalidado nesta curadoria por releitura independente do world. A ficha do NPC Gundovald, um Woodman Scholar introduzido para dar suporte de cura e exploração à companhia, foi relatada como revisada no world over-hill-under-hill (TOR2e). A grafia canônica é Gundovald; a variante Gundelwald registrada em 2026-09-20_The Traitor’s Lure- A Journey to the Hidden Valley deve ser tratada como erro de transcrição.

• Assets declarados: portrait images/over-hill-under-hill/characters/gundovald_portrait-v1.webp e token images/over-hill-under-hill/tokens/td_gundovald-v1.webp.
• A ficha passou a incluir Great Bow, Axe, Dagger e Leather Corslet, bem como Rhymes of Lore, Herb-lore, Patient, Rustic e a bênção cultural Woodcrafty.
• Antes de reutilizar ou substituir a ficha, confirmar no Foundry vivo a associação de img e prototypeToken.texture.src, a existência e decodificação dos WebP, a composição efetiva do inventário e traits, e o canal alpha/orientação do token. Não usar o ID do Actor citado no relato como referência durável.

Fonte local: lote de knowledge capture batch-8cc63f659b74405abac258594aace9d0, conversa registrada em 2026-10-04; contexto de campanha em 2026-09-13_The Fall of the Fang of the North.

4.2.8 Assets de NPCs e criaturas — Ilha de Thêmis (2026-09-16)

Registro declarado de execução, sem releitura independente do world: portraits e imagens de token foram associados a Actors na pasta OotD ➔ 05.7 Ilha de Thêmis. O relato informa os seguintes pares de assets:

Actor reportado	Portrait (img)	Token (prototypeToken)
Amazon Warrior	portrait_amazon_warrior_v1.webp	td_amazon_warrior_v1.webp
Amazon Myrmidon	portrait_amazon_myrmidon_v1.webp	td_amazon_myrmidon_v1.webp
Stimfay	portrait_stimfay_v1.webp	td_stimfay_v1.webp
Rainha Tesileia VI	05_npc_thesilea_humana_rainha.webp	06_npc_thesilea_medusa_revelada.webp
Leah, Alta Sacerdotisa	09_npc_leah_medusa_templo.webp	09_npc_leah_medusa_templo.webp
Nura, Guardiã dos Basiliscos	npc_nura_guardia_basiliscos.webp	npc_nura_guardia_basiliscos.webp
Bront, o Ciclope Ferreiro	08_npc_bront_ferreiro_jancan_v4.webp	08_npc_bront_ferreiro_jancan_v4.webp
Capitã Andrônika	10_npc_capita_andronika.webp	10_npc_capita_andronika.webp
Princesa Darien	07_npc_darien_princesa_legitima.webp	07_npc_darien_princesa_legitima.webp
Vytha	npc_lizardfolk_prisioneiro_vytha.webp	npc_lizardfolk_prisioneiro_vytha.webp
Rinotitã	enc_rhinotitan_besta_sagrada.webp	enc_rhinotitan_besta_sagrada.webp
Golem de Mármore Guardião	npc_golem_de_marmore_guardiao.webp	npc_golem_de_marmore_guardiao.webp

• O relato declara token top-down a 90° somente para Amazon Warrior, Amazon Myrmidon e Stimfay; Bront foi reportado como 2×2 e Rinotitã como 3×3.
• Os filenames devem ser preservados literalmente, inclusive onde não seguem o padrão -vN; não renomear por inferência.
• Antes de usar ou substituir os assets em jogo, confirmar no Foundry ativo os campos img e prototypeToken.texture.src, a existência e decodificação dos WebP, dimensão do token e canal alpha quando aplicável. A evidência deste registro é o lote de execução local de 2026-09-16, não uma consulta independente ao world.

4.2.9 Validação de nome do Prototype Token (2026-10-14)

Registro declarado de execução; não revalidado nesta curadoria no world ativo. Um lote de três tokens top-down — Chasgiter, Damian e Nabanar — foi relatado como aplicado diretamente aos respectivos Actors no Foundry. O token de Damian tinha o nome herdado incorreto Tristan e foi corrigido.

• Além de prototypeToken.texture.src, a validação de entrega deve conferir que prototypeToken.name corresponde ao nome do Actor. Um arquivo visual correto não corrige uma identificação herdada incorreta.
• O relato declara tokens 1×1 amigáveis, orientação a 90° voltada ao sul, WebP com alpha real (argb) e verificação de tamanho após a transferência ao host Windows. Confirmar esses campos e o asset no armazenamento antes de reutilizar o lote.
• Não registrar IDs de Actor nem caminhos temporários como referência durável; o evento não informa um world ou caminho final verificável.

Fonte local: lote de knowledge capture batch-2820ecde84ea48dcb7c6732464167e43, conversa registrada em 2026-10-14.

IDs vencem nomes e estética

Não existe world separado chamado rusthenge no inventário auditado; pathfinder2e-kingmaker tem título “Season of Ghosts” e usa PF2e 7.12.2. sombras-de-merritt usa manifest dnd5e mesmo quando incorpora adereços narrativos de VTM. Sempre resolver schema por world ID + /api/status, nunca por título ou estética.

4.3 Guia por sistema

D&D 5e 5.2.5

• Preferir 5e-statblock-importer no client quando hooks/compendia são essenciais, ou import_dnd5e_statblock MCP para fluxo direto validado.
• Statblock WotC limpo, sem headings Markdown.
• Activities/Effects usam IDs de 16 chars.
• Passivas não recebem activity artificial.
• Saves usam atributo calculado; spells usam spellcasting.
• Items com Active Effects: create_actor_item + reconciliação de IDs.
• Active Effect — deslocamento: para alterar caminhada, usar a chave system.attributes.movement.walk; em valores/fórmulas de efeitos, @attributes.movement.walk referencia a caminhada já preparada. A ordem de preparação dos tipos de movimento importa: a caminhada pode servir de referência para outra velocidade preparada depois, mas não o inverso. Confirmado no Active Effect Guide do sistema dnd5e (consultado em 2026-09-08). Validar no world de teste antes de aplicar à produção.
• Não usar condições inventadas em D&D 2024; effects custom descrevem mechanics.
• Sempre criar versões Nome (vN) e nunca apagar versão anterior sem aprovação.

Pathfinder 2e 7.12.2

• Usar compendia e APIs PF2e do world vivo; PF2e já modela strikes, actions, rules elements e effects de forma própria.
• Não converter schema dnd5e para PF2e.
• Para NPC/creature, estudar um Actor equivalente do compendium e clonar/ajustar Rule Elements.
• Módulos instalados relevantes: Rusthenge, Season of Ghosts, PF2e Assistant, Automations, Workbench, NPC Architect, Token Packs.
• Validar level, traits, perception, saves, skills, strikes, spellcasting entries e Rule Elements.

World of Darkness 5e 5.3.15

• Actor types: vampire, mortal, ghoul, hunter, werewolf, spc, group.
• NPC vampiro completo: 9 attributes, 27 skills, disciplines, powers como items, clan, predator type, headers, bio, touchstones originais, backgrounds/merits/flaws, gear e token.
• discipline não é item; poderes são power items.
• armorvalue e weaponvalue são lowercase.
• Roma Aeterna: conteúdo narrativo e técnico em inglês; assets em images/rome-modern/.
• Campaign Codex usa flags e secrets em <section class="secret">.

Sourcing de itens WoD5e para Actors

Registro declarado em lote de curadoria (2026-09-03; sem inspeção independente do world ou da skill): para Actors WoD5e, o fluxo preferencial relatado é obter os itens diretamente dos compêndios oficiais vampire-the-masquerade-5e-compendium.* e incorporá-los em actor.items. O objetivo é preservar os dados de origem e evitar cópias soltas ou duplicadas no world.

Antes de aplicar esse padrão em produção, confirmar o pack, o UUID e a compatibilidade com a versão do sistema no world ativo; a build MCP auditada não suporta compendium source em create_actor_item via Socket.IO (ver limites em §5.1). Continuam obrigatórias a autorização explícita de escrita e a releitura do Actor no Foundry vivo.

The One Ring 2e 5.5.2

• Fonte primeiro: PDF/transcrição/handouts/mapas oficiais.
• Não aceitar defaults de Actor como fatos (idade e bio de character podem ser placeholders).
• Mapas numerados são referência/exploração, não battlemaps D&D.
• Scenes de mapa: padding: 0, grid desabilitado quando apropriado.
• Combate é abstrato por stances, engagement e ranges.
• Portrait e token separados; token estritamente top-down, facing south, alpha real.

---

5. MCP local: funções, parâmetros e limites

Fonte: C:\Users\Yanbd\dev\foundryvtt-mcp\src\tools\definitions.ts.

5.1 Tools declaradas na build auditada

Grupo	Tools	Parâmetros/limites principais
Dice	roll_dice	formula obrigatório; reason opcional
Actors	search_actors, get_actor_details, import_dnd5e_statblock	search default 10; importer: statblock, folderId, img, tokenImg, dryRun
Actor writes	update_actor_attributes, delete_actor	actorId; patch dot-path; write-enabled + Socket.IO
Items	search_items	filtros query, type, rarity, default 10
Compendium	search_compendium	query obrigatório; filters; default 20; cursor; comentário do código exige REST API key
Actor items	create_actor_item, update_actor_item, delete_actor_item	Actor/item IDs; inline source; JSON merge patch
Scene	get_scene_info	sceneId opcional
Combat	get_combat_state, next_turn, end_combat, set_initiative, start_combat	active combat; token IDs/scene; GM/owner
Token	move_token, apply_status_effect	coordenadas em pixels; status id; scene opcional
Chat/users	get_chat_messages, get_users	chat 1–100, default 20
Journals	search_journals, get_journal	query/default 10; journalId
World	search_world, get_world_summary, refresh_world_data	search default 5 por coleção
Generation	generate_npc, generate_loot, lookup_rule	NPC level 1–20; loot CR 0–30
Diagnostics	get_recent_logs, search_logs, get_system_health, diagnose_errors, get_health_status	logs 1–100; diagnose_errors é stub

Limites conhecidos:

• transport muda para REST quando FOUNDRY_API_KEY existe; é switch, não camada paralela;
• writes requerem FOUNDRY_WRITE_ENABLED=true e Socket.IO ativo;
• cache de world pode ficar stale;
• refresh_world_data já sofreu timeout;
• update_actor_attributes só altera actor.system, não img/prototypeToken;
• compendium source em create_actor_item ainda não é suportado sobre Socket.IO conforme descrição do código;
• a build auditada não declara create_journal ou update_journal, apesar de documentação histórica citar essas tools;
• tools MCP se vinculam ao world ativo, não a todos os worlds simultaneamente.

---

6. Foundry REST API: rotas, grupos e limites

Fonte de verdade: Foundry REST API Docs consultada durante a auditoria. Módulo instalado localmente: foundry-rest-api 3.2.3.

6.1 Autenticação e conexão

• header: x-api-key;
• world: clientId;
• module/browser precisa manter WebSocket conectado ao relay;
• scopes por endpoint, por exemplo entity:read, entity:write;
• clients offline tornam operações de world indisponíveis;
• para criação/atualização de journals, REST API é o protocolo padrão: consultar /clients e exigir o clientId alvo com isOnline: true antes de qualquer request; create_journal e update_journal não existem na build MCP auditada;
• chaves ficam em ~/.foundry-api.sh: FKR (key), FKC (client), FKB (base URL); valores não são documentados aqui.

6.2 Inventário de rotas oficiais

Auth

POST /auth/key-request; GET /auth/key-request/:code/status; POST /auth/key-request/exchange.

Canvas

GET|POST|PUT|DELETE /canvas/:documentType; GET /measure-distance; POST /move-token.

Chat

GET|POST /chat; DELETE /chat/:messageId; DELETE /chat; GET /chat/subscribe (SSE).

Clients

GET /clients.

D&D 5e

GET /dnd5e/get-actor-details; POST /dnd5e/modify-item-charges; short-rest; long-rest; skill-check; ability-save; ability-check; death-save; modify-experience; GET /dnd5e/concentration; POST /dnd5e/break-concentration; concentration-save; equip-item; attune-item; transfer-currency; modify-currency; prepare-spell; use-ability; use-feature; use-spell; use-item.

Effects

GET /effects; GET /effects/list; POST /effects; DELETE /effects.

Encounter

GET /encounters; POST /start-encounter; next-turn; next-round; last-turn; last-round; end-encounter; add-to-encounter; remove-from-encounter.

Entity

GET /get; POST /create; PUT /update; DELETE /delete; POST /give; remove; decrease; increase; kill.

Parâmetros críticos:

• /get: clientId, uuid ou selected, actor, userId;
• /create: entityType, data, clientId, folder, keepId, override, userId;
• /update: data, clientId, uuid ou selected, actor, userId;
• /delete: clientId, uuid ou selected, userId.

Events/SSE

GET /hooks/subscribe; /encounters/subscribe; /actor/subscribe; /scene/subscribe.

Macro

GET /macros; POST /macro/:uuid/execute.

Playlist

GET /playlists; POST /playlist/play; stop; next; volume; POST /stop-sound.

Roll

GET /rolls; GET /lastroll; POST /roll; GET /rolls/subscribe (SSE).

Scene

GET /scene; GET /scene/image/raw; POST|PUT|DELETE /scene; POST /switch-scene; GET /scene/image.

Search

GET /search.

Session

POST /session-handshake; POST /start-session; DELETE /end-session; GET /session.

Sheet

GET /sheet.

Structure

GET /structure; GET /get-folder; POST /create-folder; DELETE /delete-folder; GET /contents/:path.

User

GET /users; GET /user; POST|PUT|DELETE /user.

Utility

POST /select; GET /selected; GET /players; GET /world-info; POST /execute-js.

WebSocket/File System

A documentação oficial possui grupos próprios de WebSocket e File System. Consultar a página específica da versão viva antes de implementar upload/streaming, pois o inventário de links é mais atual do que skills locais.

6.3 Quirks e regras

• /update: uuid e clientId na query string.
• /macro/:uuid/execute: UUID completo Macro.<id>.
• create de Journal/Actor pode ignorar folder; mover via PUT /update com uuid/clientId na query string e data.folder com o ID da pasta. Esse fluxo também permite aninhar Folder sem execute-js.
• Journal v13: conteúdo em pages, text.format: 1.
• Campaign Codex: conteúdo principal em flags, não pages.
• execute-js é poderoso e deve ser usado com scripts idempotentes e releitura.
• Python urllib já recebeu 403 no relay; curl é a rota validada.
• nenhum success: true sem releitura conta como conclusão.
• não usar /start-session ou headless session para contornar a exigência do módulo/browser sem aprovação explícita.

6.4 Fallback sem execute-js para conteúdo de criação dnd5e

Registro operacional informado em 2026-09-10; revalidar no world ativo antes de reutilizar. Quando POST /execute-js estiver desativado, o fluxo REST para backgrounds, species e subclasses pode manter a organização e os vínculos sem esse endpoint:

1. criar a pasta pai com POST /create-folder;
2. criar primeiro os Item filhos de feature (tipo feat) e guardar os _id retornados;
3. criar o Item pai de criação (background, race ou subclasse), incluindo os avanços ItemGrant e as referências @UUID aos filhos já criados;
4. mover o pai, cada filho e qualquer subpasta com PUT /update, usando uuid e clientId na query string e data.folder com o ID da pasta de destino;
5. reler a estrutura e os documentos (GET /structure e GET /get) para confirmar pasta, ItemGrant e UUIDs.

O folder informado na criação não substitui a movimentação posterior: o endpoint pode ignorá-lo. Este procedimento especializa a regra de organização da seção 6.3; manter o texto das features em inglês e confirmar o schema dnd5e e os UUIDs conforme a seção 4.2.

---

7. Manual criativo, visual e narrativo

7.1 Princípios narrativos

1. Fonte primeiro: livro/PDF/MD da campanha antes de web genérica.
2. Expansão sem apagar o cânone: separar citação/fato canônico de adaptação de mesa.
3. Preparação acionável: aproximação → âncoras sensoriais → NPC voice lines → escolhas → consequência → fallback.
4. Conteúdo player-facing versus GM-only: não misturar spoilers.
5. Mecânica na linguagem do sistema: narrativa em PT-BR para mesas PT; termos mecânicos em EN quando essa é a convenção. Roma Aeterna deve permanecer em inglês.
6. D&D 2024: apenas condições reais; efeitos custom por texto mecânico.
7. Criaturas RotSS: Player’s Reference EN → Visual Description/AI Prompt → seção PT; sem statblock na bio.
8. V5: horror pessoal, relações, ambição/desejo, fraquezas e segredos; fichas completas.
9. TOR2e: tom literário e de viagem, source-first, combate abstrato e mapas não convertidos artificialmente em grid D&D.

7.2 Padrões visuais

Marca DM Yan

• títulos: MedievalSharp;
• corpo: DM Sans;
• logo: DMYan-white;
• banners limpos, título amplo, sem sobreposição;
• alta legibilidade e contraste;
• capas de campanha/listing: arte sem texto gerado, depois overlay externo com título e subtítulo em dourado metálico legível e badge do sistema no canto inferior direito;
• publicar revisões como arquivos versionados (_vN.webp) em vez de sobrescrever a imagem anterior, para evitar cache desatualizado.

Retratos e imagens de cena

• WebP para Foundry;
• estilo por campanha, consistente dentro do lote;
• RotSS: dark Norse fantasy, luz dramática, materiais e silhuetas legíveis;
• Roma Aeterna: identidade gótica/contemporânea coerente e conteúdo em inglês;
• cenas: 16:9 quando usadas como establishing shots/handouts;
• sempre revisar pixels, não aprovar só pelo prompt.

Tokens

• câmera 90° bird’s-eye estrita;
• facing south/down;
• equipamento dentro da silhueta;
• fundo chroma #00FF00 na geração;
• remoção por chroma/segmentação;
• RGBA WebP com alpha real, extremos 0 e 255;
• sem base, frame, texto, grid, sombra ou fake checkerboard;
• stage em Downloads para aprovação antes de publicar.

7.3 Obsidian

• raiz canônica do vault: C:\Users\Yanbd\dev\Wiki-Yan\content;
• notas RPG: content\RPG\;
• documentação de sistema: content\Sistemas\Documentacao_Hermes\;
• usar frontmatter, headings semânticos, tabelas e callouts;
• wikilinks [[...]] para navegação;
• campanhas usam prefixos numéricos quando a pasta adota sequência;
• packs grandes: 00 - Index, overview, people, places, encounters, visual prompts;
• não criar monólito quando múltiplas notas melhoram uso na mesa.

Callouts recomendados:

> [!read-aloud] Narração
> 
> Texto pronto para mesa.
 
> [!warning] Regra/risco
> 
> Informação operacional importante.
 
> [!secret] GM only
> 
> Spoiler, motivação ou consequência oculta.

7.4 Foundry HTML/CSS

• HTML semântico: <h1>, <h2>, <p>, <ul>, <blockquote>, <strong>;
• evitar inline colors/backgrounds de baixo contraste;
• journals normais: JournalEntryPage, text.format: 1;
• Campaign Codex: flags.campaign-codex.data.description e notes; a imagem de capa/card é flags.campaign-codex.image;
• secrets: <section class="secret">...</section>;
• imagens: paths relativos images/...;
• sempre verificar page count, conteúdo não vazio, folder, ownership e renderização no dark theme.

Padrão de handout para NPCs e locais — decisão de 2026-10-14

Decisão de Yan: toda descrição de NPC ou local preparada para uma campanha deve ser entregue também como handout no Foundry VTT, não apenas como texto em conversa ou nota externa.

• O handout deve ser um JournalEntry organizado na pasta temática apropriada, com página(s) de conteúdo em HTML semântico e text.format: 1.
• Quando houver portrait ou imagem aprovada, referenciá-lo por caminho relativo local; a presença do arquivo e o carregamento no handout fazem parte da verificação.
• O conteúdo destinado a jogadores e os segredos de GM devem permanecer separados e obedecer ownership/permissões. Segredos usam <section class="secret">...</section> quando aplicável.
• Se o world usar Campaign Codex, o handout não substitui a entrada estruturada: preencher também as flags exigidas pela folha do Codex, conforme sua versão validada.
• A entrega só é concluída após releitura do Journal e confirmação de páginas, conteúdo, pasta, ownership e renderização. A criação continua sujeita ao protocolo de escrita e à confirmação do world ativo desta nota.

Fonte local: instrução direta de Yan registrada em conversa em 2026-10-14. Esta regra define o padrão de entrega; não comprova por si só a persistência de um handout específico.

---

8. Protocolo operacional estrito

8.1 Antes de qualquer ação Foundry

• GET /api/status e registrar world/system/version.
• Confirmar destino: b450m ou VM.
• Confirmar rota: MCP, REST ou Socket.IO.
• Confirmar intenção de leitura versus escrita.
• Conferir policy viva de write sem expor segredo.
• Conferir se há sessão ativa de jogadores.
• Nunca parar/reiniciar Foundry sem aprovação explícita.

8.2 Writes

• Criar versão vN; não sobrescrever/deletar.
• Operação idempotente ou com rollback.
• Um writer por asset/lote entre hosts.
• Nunca editar LevelDB com Foundry aberto.
• Nunca usar LevelDB direto como atalho silencioso.
• Releitura pela API/Socket.IO fresca.
• Verificação visual para fichas/assets/journals.

8.3 Syncthing

• Não alterar folder paths, types, ignore rules ou device routing sem aprovação.
• Não limpar sync-conflict automaticamente.
• Sincronizar integralmente worlds, systems e modules; não ignorar .ldb, .log, CURRENT ou MANIFEST ativos.
• Nunca abrir o mesmo world nos dois hosts; mundos diferentes podem operar em paralelo.
• Antes de migrar um world entre hosts: fechar o world de origem, aguardar Syncthing estabilizar, verificar o destino e só então abrir.
• Para correção futura: backup → janela controlada → equivalência de .stignore cirúrgico → rescan → relatório.
• Resolver colisões de caixa por renomeação versionada e coordenada entre Linux/Windows.

8.4 Proibição de contorno

Hermes não pode:

• substituir IP Tailscale por túnel/host público “porque funciona”;
• usar REST para escapar de policy MCP, ou MCP para escapar de scopes REST;
• ativar headless session para contornar client offline;
• alterar dataPath, PM2, Syncthing ou .env sem proposta e aprovação;
• parar Foundry para liberar LevelDB;
• declarar sucesso sem releitura e, quando aplicável, UI/asset verification.

---

Registro de manutenção: limpeza seletiva relatada (2026-09-21)

Confirmado no relato de execução; não revalidado nesta nota contra a VM viva. Após a auditoria anterior, foi relatada uma limpeza seletiva que preservou os diretórios e arquivos de composição das stacks desativadas.

Escopo	Ação relatada	Estado e cuidados duráveis
Stack n8n “Fellipe” (fellipe-n8n, worker, PostgreSQL e Redis)	docker compose down; os quatro containers foram removidos.	Dados e docker-compose.yml teriam sido preservados em /home/ubuntu/fellipe-n8n/ para eventual reativação.
Nginx Proxy Manager (npm) e Wallos	Containers desligados e removidos.	O relato atribui o tráfego externo ao Cloudflare Tunnel e informa banco Wallos sem assinaturas; validar rotas e dados antes de recriar ou descartar componentes.
Resquícios de teste de pool do Foundry e proxy VNC	Containers parados foundry-a, foundry-b, foundry-c, foundry_proxy e gemini_vnc_proxy removidos.	Não representa parada nem reinício do Foundry em produção.
Crontab e logs	Removidas as entradas do cron do Firefly III e do auto-deploy de handouts; deploy_log.txt foi truncado.	A remoção foi justificada por referências a componentes inativos. Antes de restaurar, confirmar o serviço consumidor e a necessidade operacional.

O relato também declarou redução de seis containers ativos e ausência de containers parados após a operação; esses números são históricos e não devem ser usados como estado atual da VM.

Revalidação obrigatória

Antes de reativar, remover mais componentes ou usar prune, inspecionar o estado vivo, dependências externas, dados necessários e rollback. Não inferir que DNS, rotas, certificados ou serviços atuais continuam equivalentes ao relato.

Fonte local: conversa de manutenção registrada no lote de knowledge capture em 2026-09-21. A resposta disponível estava truncada; esta nota preserva apenas os itens explicitamente relatados e não substitui inspeção independente.

Registro de manutenção: fichas de Sombras de Merritt e Sarsi (2026-09-22)

Relato de execução no world sombras-de-merritt; não revalidado nesta curadoria por releitura do Foundry vivo. Foram relatadas revisões de 18 fichas nas pastas Sombras de Merritt e Sarsi — Cidadela Sem Sol, no sistema dnd5e 5.3.3. O objetivo declarado foi normalizar a distribuição de capacidades tomando como referência o padrão de apresentação de Where Evil Lies (MCDM).

O padrão aplicado separa capacidades entre Ação, Multiattack, Ação Bônus, Reação, Traços Passivos e, quando pertinente, Ações Lendárias ou de Covil. O relato também declara que as habilidades acionáveis foram modeladas no sistema nativo de Activities, com ataques, danos, salvaguardas e CD parametrizados; passivas não devem receber uma Activity artificial.

Segundo o relato posterior, a aba Statblock vazia no Tidy5e foi atribuída à ausência de system.resources e system.spells: a renderização teria tentado acessar resources.legact, legres e lair antes de esses objetos existirem. A correção declarada inicializou esses recursos — com valores zerados quando não aplicáveis — e os campos system.tools e system.bonuses.

O mesmo relato registrou dois requisitos de modelagem que devem ser confirmados no world antes de reaproveitar dados: em system.activities, a chave de cada entrada deve coincidir com o _id da Activity; Features de monstro devem ter system.type.value: "monster", e armas precisam de system.equipped: true para serem agrupadas como ataques pelo Tidy5e. Essas são condições relatadas para a combinação então usada de D&D5e/Tidy5e, não uma especificação validada universalmente nesta nota.

Reutilização e manutenção

Este registro confirma apenas o que foi declarado pela execução. Antes de editar, clonar ou depender de uma ficha, confirmar no world ativo a versão do sistema, as Activities, as CDs, os efeitos e a persistência. Permanecem obrigatórios IDs alfanuméricos de 16 caracteres para Activities/Active Effects e a reconciliação de referências de efeito descritas em §1.2.

Fonte local: lotes de knowledge capture batch-7a925e66ce8a424f90a04ce64fdad8b6 e batch-0b14c0042bcd4317837697e12b9516b3, conversas registradas em 2026-09-22. Não há fonte externa aplicável: trata-se de estado e manutenção declarados do Foundry de Yan.

9. Pendências e recomendações que exigem aprovação

1. Resolver os 234 erros de case collision em assets SRD por renomeação coordenada Linux/Windows; não alterar sem autorização específica.
2. Investigar MCP b450m→Oracle no world PF2e ativo: usuário/auth/handshake.
3. Corrigir divergência de options.json por host: o arquivo VM contém path Windows, embora PM2 faça override correto.
4. Mapear client IDs restantes do REST para nomes de world: requer cada world conectado ou leitura específica das settings.

Concluídos em 2026-07-31: .stignore cirúrgico nos dois hosts, backup integral, remoção validada dos 2.738 conflitos, regra multi-world e schema real de Sombras/Season of Ghosts documentados. FOUNDRY_WRITE_ENABLED=true permanece ativo em .env e .env.vm, condicionado à validação do world vivo por /api/status antes de qualquer write.

---

10. Referências técnicas

• Foundry REST API Docs
• 5e Statblock Importer
• C:\Users\Yanbd\dev\foundryvtt-mcp\src\tools\definitions.ts
• C:\Users\Yanbd\foundry-data\v13\Data\modules\5e-statblock-importer\README.md
• Skills locais: foundry-local-audit, foundry-vtt, foundry-rest-api, mcp-creature-creation, obsidian

Changelog

• 2026-07-30: auditoria inicial prática e histórica; testes de rede/MCP/REST/Syncthing; protocolo estrito consolidado.
• 2026-07-31: arquitetura corrigida para sincronização total multi-world; .stignore cirúrgico aplicado nos dois hosts; backup e limpeza de 2.738 conflitos validados; REST definido como padrão para journals com preflight isOnline: true.

---

11. Persistência e confirmação

• Obsidian: esta nota foi gravada em Sistemas/Documentacao_Hermes/Arquitetura_e_Fluxos.md dentro do vault C:\Users\Yanbd\dev\Wiki-Yan\content.
• Honcho: o peer card foi atualizado e relido com 28 fatos. Os fatos duráveis agora registram a sincronização total multi-world, a proibição de abrir o mesmo world nos dois hosts, o .stignore cirúrgico, o reparo dos 2.738 conflitos, os schemas reais de Sombras/Season of Ghosts, REST como padrão para journals e a policy de write condicionada a /api/status.
• Honcho conclusions: o endpoint específico de conclusions havia recusado a auditoria inicial; a persistência vigente foi confirmada pelo peer card, preservando os fatos anteriores e substituindo o fato obsoleto que dizia que a b450m não possuía .stignore.
• Segredos: nenhum valor de senha, API key, token ou device ID completo foi persistido na nota ou nos fatos adicionais.