Skip to main content

Log do Projeto

Este documento preserva decisões, mudanças, descobertas e validações do Weave Network. Ele existe para que uma pessoa ou agente consiga reconstruir rapidamente o estado do projeto e entender por que uma regra mudou.

O roadmap mostra o próximo destino. As especificações descrevem a regra vigente. Este log explica o caminho percorrido e as evidências disponíveis.

Regras do log​

  • Entradas são cronológicas e não devem ser removidas quando uma decisão muda.
  • Correções de texto que não alteram significado podem ser feitas diretamente.
  • Mudanças de significado criam uma nova entrada.
  • Uma decisão substituída aponta para a entrada nova; a entrada nova referencia a anterior.
  • Uma decisão aceita não é automaticamente implementada.
  • Código implementado não é automaticamente validado.
  • Observações em jogo são evidências, não decisões por si mesmas.
  • Commits e PRs devem ser adicionados quando existirem.
  • Fatos, hipóteses e riscos devem ser escritos separadamente.

Tipos e estados​

PrefixoUso
DECDecisão de produto, arquitetura ou processo.
CHGMudança implementada.
FNDDescoberta, divergência ou possível problema.
TSTResultado de validação manual ou automatizada.
DESDefinição de gameplay, visual, lore ou experiência.
HISTRegistro importado do histórico anterior a este log.

Estados usuais: proposta, aceita, implementada, validada, rejeitada e substituída.

Modelo para novas entradas​

## DEC-AAAA-MM-DD-NNN — Título curto

**Tipo:** decisão de arquitetura
**Estado:** aceita
**Área:** topologia
**Substitui:** nenhuma
**Substituída por:** nenhuma

### Contexto
Motivo da entrada.

### Registro
Decisão, mudança, descoberta ou resultado.

### Impacto e pendências
O que isso altera e o que continua aberto.

### Evidências
- Especificação: caminho ou link
- Commit: hash ou pendente
- PR: número ou pendente
- Validação: descrição ou pendente

Snapshot atual​

Data de referência: 10/09/2026.

  • Branch de trabalho: dev para o Marco 1; o Marco 0 foi consolidado na main.
  • Minecraft 1.21.1, Java 21 e NeoForge 21.1.250.
  • Build compila e o cliente de desenvolvimento foi aberto.
  • O histórico Git foi recuperado.
  • O projeto possui implementação extensa até Anchor/Gate, mas não possui um ciclo completo em survival.
  • Builds internas usam mod_version=0.0.0-dev; ainda não houve release pública comprovada por tag.
  • Estado detalhado e próximos marcos: Roadmap até 1.0.

HIST-2026-02-001 — Desenvolvimento inicial​

Tipo: histórico importado Estado: implementado; regressão atual parcial Área: projeto inteiro Substitui: nenhuma Substituída por: nenhuma

Contexto​

Entre 01/02/2026 e 17/02/2026, o repositório recebeu o bootstrap e a maior parte do protótipo técnico. O backlog antigo tratava várias etapas como Done. Esse termo indicava conclusão no contexto da época, mas não representa validação na build retomada.

Registro​

Linha históricaConteúdo registradoEstado na retomada
Bootstrap a v0.4Registros, blocos, runtime, IO, multipart e binding por Fiber.Implementado; regressão pendente.
v0.4.1Hardening do runtime, estados e dumps.Implementado; divergências documentais encontradas.
v0.5Scheduler central, tiers e tuning.Implementado; política precisa de regressão.
v0.6Máquina de estados operacionais.Implementado; comportamento em brownout precisa de decisão.
v0.7Buffer, contenção e transporte de FE.Implementado; alimentação do Controller evoluiu na retomada.
v0.8 canceladaBuffers internos de Port foram implementados e removidos.Decisão histórica preservada.
v0.8.1–0.8.3Fluidos, redstone e infraestrutura de IO por face.Parcial: IO por face não está aplicado a todos os payloads.
v0.9–0.9.5Condenser, Strain, feedback e estrutura de modelos por tier.Implementado; validação atual pendente.
v0.10–0.10.4Linking, Anchors, custos e schedulers multidimensionais.Parcial; requisito Link não é aplicado em todo o caminho.
v0.11–0.11.1Gate, binding intrínseco com Anchor e portal.Parcial; topologia e todos os payloads precisam de validação.

Evidências​

  • Commits históricos: 98d5296, b3e9e08, c1d4a85, df8aa62, f9221b5, 22e1969, 80f70cd, 9138152, 36c2207, 33364ff, 17bbeeb, 40f8ce3, 066162d, 7db7784.
  • Especificações: diretórios docs/02_arquitetura, docs/03_sistemas e docs/04_progressao_player.
  • Validação atual: parcial; ver entradas de setembro de 2026.

FND-2026-09-09-001 — Auditoria estática da retomada​

Tipo: descoberta Estado: validada por inspeção do repositório Área: baseline Substitui: nenhuma Substituída por: DEC-2026-09-10-004, quanto à identidade da versão

Contexto​

O projeto foi retomado após uma pausa desde fevereiro de 2026. A primeira inspeção ocorreu antes de o ambiente Java e o Git estarem novamente disponíveis.

Registro​

  • Minecraft configurado como 1.21.1, NeoForge 21.1.219 e Java 21.
  • mod_version=0.7.0, enquanto commits e backlog descreviam trabalho posterior.
  • Grafo, scheduler, quatro payloads, estados, tiers, Condenser, Anchor e Gate estavam presentes no código.
  • Loom e Stabilizer possuíam BlockEntities vazias.
  • Tuning Key estava registrada como item comum; Debug Wrench concentrava funções de desenvolvimento.
  • Não foram encontradas receitas de gameplay nem interfaces completas.
  • Foram encontrados 57 modelos de bloco e 69 arquivos de textura.
  • Não foram encontrados arquivos .bbmodel.
  • Não havia suíte de testes automatizados descoberta naquele momento.

Impacto e pendências​

A retomada passou a priorizar baseline verificável, integridade da rede, fundação visual e uma alpha T0–T1. Nenhum sistema histórico deve ser considerado validado apenas pela presença de código ou por status antigo do backlog.

Evidências​

  • Inspeção dos arquivos em src/main, docs, build.gradle e gradle.properties.
  • Commit: não aplicável.
  • PR: #1.

CHG-2026-09-10-001 — Atualização do ambiente de desenvolvimento​

Tipo: mudança de infraestrutura Estado: validada Área: build Substitui: versões anteriores do ambiente Substituída por: nenhuma

Registro​

  • NeoForge: 21.1.219 → 21.1.250.
  • ModDevGradle: 2.0.140 → 2.0.146.
  • Gradle Wrapper: 9.2.1 → 9.7.1.
  • SHA-256 oficial adicionado à distribuição Gradle.
  • Parchment 2024.11.17 e Foojay Resolver 1.0.0 mantidos.
  • Sintaxe de atribuição da URL de publicação atualizada para a forma suportada pelo Gradle atual.

Impacto e pendências​

O metadata gerado passa a exigir NeoForge 21.1.250 ou superior. Minecraft permanece em 1.21.1 e Java permanece em 21. Os blocos ainda precisam de regressão completa nessa combinação.

Evidências​

  • Build e geração do JAR concluídas.
  • ./gradlew.bat build --warning-mode all passou após a atualização.
  • Commit: 81901f7 — chore: update NeoForge and Gradle toolchain.
  • Fontes de versão: Maven NeoForge, Gradle Plugin Portal e serviço oficial de versões do Gradle.
  • PR: #1.

TST-2026-09-10-001 — Primeira validação prática da rede retomada​

Tipo: teste manual Estado: parcial Área: payloads e topologia Substitui: nenhuma Substituída por: nenhuma

Registro​

O jogador observou na build em execução:

  • itens transferindo na mesma dimensão;
  • FE transferindo na mesma dimensão;
  • itens transferindo entre dimensões;
  • FE entre dimensões sem confirmação;
  • fonte energética de suporte: reator do Powah;
  • Anchor e Gate funcionando em uma montagem cujo Controller inspecionado era T4;
  • dump desse Controller mostrando anchors=0, gates=0 e acceptNetworkEnergy=true.

Impacto e pendências​

O zero no dump foi inicialmente interpretado como falha de contagem. A revisão das especificações mostrou que a rede T4 não deveria sustentar Anchor/Gate. Essa interpretação foi substituída por DEC-2026-09-10-002.

Ainda falta registrar a montagem exata de cada rede, faces configuradas, chunks carregados e destino usado no teste interdimensional de FE.

Evidências​

  • Teste manual e captura de tela fornecidos pelo usuário.
  • Mods auxiliares disponíveis em run/mods.
  • Commit: não aplicável.
  • PR: #1.

DEC-2026-09-10-001 — Controller pode receber FE diretamente da própria rede​

Tipo: decisão de arquitetura e gameplay Estado: aceita; implementação parcial e validação em mundo pendente Área: energia Substitui: comportamento em que apenas fonte externa ou Port adjacente alimentava o Controller Substituída por: nenhuma

Contexto​

O Controller expunha acceptNetworkEnergy=true, mas o scheduler não o tratava como destino. Foi esclarecido que o Controller deve ser o único bloco, além da Port, capaz de interagir diretamente com a rede para receber FE, sem exigir uma Port encostada nele.

Registro​

  • O Controller participa como destino direto da etapa de FE quando acceptNetworkEnergy está habilitado.
  • O Controller deve ter prioridade absoluta enquanto precisar de energia: sem Controller sustentado, não há rede.
  • A implementação atual o escolhe antes das saídas comuns dentro da etapa de FE, mas ainda não garante prioridade global sobre os demais payloads.
  • Uma única Port INPUT ligada a uma fonte pode alimentar o Controller pela rede.
  • A alimentação continua sujeita ao estado, canais e taxa do scheduler.
  • Uma rede completamente colapsada ainda necessita de uma política explícita de bootstrap; a implementação atual não cria uma exceção de partida.
  • Uma opção para desativar essa prioridade poderá existir futuramente; ela não faz parte do comportamento padrão atual.

Impacto e pendências​

  • Implementar a prioridade absoluta antes do restante do transporte.
  • Definir o comportamento de bootstrap, brownout, collapse e reboot.
  • Avaliar se acceptNetworkEnergy deve continuar controlando também a capability externa.
  • Validar com Powah em mundo.

Evidências​

  • Código: WeaveEnergyScheduler.java e WeaveRuntime.java.
  • Regressão executável: EnergyRegressionTest.java.
  • Build passou com energyRegressionTest.
  • Commit: 12cb077 — fix: feed controller from network energy.
  • PR: #1.

CHG-2026-09-10-002 — Seleção e conservação de FE endurecidas​

Tipo: mudança implementada Estado: validada por regressão isolada; mundo pendente Área: energia e compatibilidade Substitui: seleção do primeiro vizinho com capability Substituída por: nenhuma

Registro​

  • O scheduler coleta capabilities vizinhas e usa simulação para escolher uma fonte ou destino atualmente utilizável.
  • Uma fonte vazia ou receptor cheio deixa de esconder outro endpoint válido.
  • A extração é limitada ao valor que o destino informou aceitar em simulação.
  • Autotransferência é bloqueada.
  • Consultas evitam chunks ausentes.
  • Divergência de handlers entre simulação e execução continua usando devolução por melhor esforço.

Evidências​

  • energyRegressionTest verifica seleção, recebimento pelo Controller, conservação, destino quase cheio e autotransferência.
  • ./gradlew.bat build --warning-mode all passou.
  • O compilador ainda informa uso de API depreciada no scheduler de FE.
  • Uma tentativa de clean falhou por JARs em uso; o build normal posterior passou.
  • Commit: 12cb077 — fix: feed controller from network energy.
  • PR: #1.

DEC-2026-09-10-002 — Anchor e Gate exigem uma rede sustentadora Link​

Tipo: decisão de arquitetura e gameplay Estado: aceita; implementação parcial Área: topologia e progressão Substitui: interpretação em TST-2026-09-10-001 de que o dump deveria contar Anchor/Gate em T4 comum Substituída por: nenhuma

Contexto​

Após observar Anchor/Gate funcionando numa montagem T4, a primeira hipótese foi de que apenas o dump estivesse incorreto. A revisão das especificações mostrou que o funcionamento nessa rede é o problema real.

Registro​

  • Anchor só pode estender uma rede T5 Link, formada por Reinforced Core e Link Singularity.
  • Gates devem ser sustentados por uma rede intermediadora T5 Link.
  • A rede externa que atravessa Gates pode ser normal, Flow, Density ou outro tipo permitido.
  • A intermediadora não processa os payloads externos; sustenta o portal.
  • Contagem e custo no dump continuam condicionados ao suporte Link e não foram ampliados para T4 comum.

Impacto e pendências​

  • A busca multidimensional atravessa Anchors linkados sem validar supportsAnchorGate; essa brecha deve ser fechada no Marco 1.
  • A entrada do Gate já valida que a rede intermediadora está ONLINE e suporta Anchor/Gate, mas os dois extremos e demais invariantes precisam de revisão.
  • Dumps futuros devem diferenciar bloco registrado de link válido e ativo.

Evidências​

DEC-2026-09-10-003 — Governança de roadmap e histórico​

Tipo: decisão de processo Estado: implementada Área: documentação Substitui: backlog único que misturava versões futuras, especificações e histórico Substituída por: nenhuma

Registro​

  • O roadmap usa marcos e critérios de saída, sem inventar versões para features futuras.
  • Versões são escolhidas apenas quando houver uma build candidata a release.
  • Especificações guardam a regra vigente; roadmap guarda direção; este log guarda história e evidências.
  • Entradas substituídas permanecem visíveis e possuem referências bidirecionais.
  • Referências diretas ao antigo versionamento futuro foram atualizadas nas especificações de Anchor/Gate, Condenser e Upgrades; as demais especificações ainda serão auditadas no Marco 0.
  • Os documentos temporários 09_retomada_2026_09.md e 10_validacao_rede_2026_09.md foram absorvidos neste log e removidos.

Evidências​

  • Roadmap até 1.0.
  • Discussão de retomada em 10/09/2026.
  • Commit: 7bbbcf1 — docs: replace version backlog with milestone roadmap.
  • PR: #1.

CHG-2026-09-10-003 — Build estático da documentação restaurado​

Tipo: correção de documentação e ambiente Estado: validada localmente; integração na main pendente Área: Docusaurus e deploy na Vercel Substitui: objetos de status escritos como expressões MDX e faixa aberta de Node >=20.0 Substituída por: nenhuma

Contexto​

O deploy da Vercel para a main, no commit 09bcec1, compilava o site, mas falhava durante a geração estática da rota /docs/sistemas/anchor_gate com ReferenceError: isLinked is not defined.

Registro​

  • As representações dos retornos de getAnchorStatus e getGateStatus estavam fora de código inline. O MDX interpretava as chaves como expressões JavaScript e tentava resolver isLinked durante a renderização no servidor.
  • Os dois objetos de status passaram a usar código inline, preservando o conteúdo literal.
  • O engine do site foi fixado em Node 24.x, também no lockfile, para impedir que a faixa aberta selecione automaticamente uma futura versão principal na Vercel.
  • Os avisos de caniuse-lite desatualizado e de vulnerabilidades do npm audit não eram a causa desta falha e não foram tratados por atualização automática de dependências.

Evidências​

  • node --run build passou com Node 24.19.0 e Docusaurus 3.9.2 para os locales en e pt-BR.
  • Os arquivos estáticos foram gerados em website/build e website/build/pt-BR.
  • Commit: 8c864f8 — fix(docs): escape MDX status objects.
  • PR: #1.

DEC-2026-09-10-004 — Versões passam a identificar somente releases reais​

Tipo: decisão de processo e release Estado: aceita e implementada Área: versionamento, build e documentação Substitui: uso dos números 0.3.1 a 0.11.1 como marcos de implementação e a pendência registrada em FND-2026-09-09-001 Substituída por: nenhuma

Contexto​

O artefato ainda declarava 0.7.0, embora o código contivesse trabalho rotulado internamente até 0.11.1. O pacote privado do Docusaurus declarava 0.3.1, enquanto seu lockfile declarava 0.0.0. A auditoria do histórico local e das referências remotas não encontrou tags de release.

Registro​

  • Os números 0.3.1 a 0.11.1 representam linhas históricas de desenvolvimento, não releases comprovadas.
  • Esses números permanecem apenas em HIST-2026-02-001 e nas evidências cronológicas deste log.
  • Builds do mod sem intenção de distribuição usam 0.0.0-dev.
  • O pacote privado da documentação usa nome weave-network-docs e versão técnica 0.0.0, sem relação com a versão do mod.
  • A próxima versão pública será escolhida quando existir uma build candidata com escopo, validação e tag próprios.
  • Especificações e comentários vigentes descrevem capacidade e estado, sem atrelar trabalho futuro a versões inventadas.

Evidências​

  • git tag e as tags do remoto não retornaram nenhuma release.
  • O histórico contém commits de bump e commits de feature posteriores ao último bump declarado.
  • O JAR gerado passou a ser weave_network-0.0.0-dev.jar, com version="0.0.0-dev" no metadata NeoForge.
  • Commit: 320cbae — chore: reconcile development version.

TST-2026-09-10-002 — Baseline automatizada após reconciliação​

Tipo: validação automatizada Estado: validada dentro da cobertura existente Área: build, energia e documentação Substitui: nenhuma Substituída por: TST-2026-09-10-003, quanto à cobertura automatizada vigente

Registro​

  • ./gradlew.bat build --warning-mode all passou com Java 21 e gerou o JAR 0.0.0-dev.
  • energyRegressionTest passou e continua sendo a única regressão determinística específica descoberta no projeto.
  • O source set de testes convencional permanece NO-SOURCE.
  • node --run build passou no Docusaurus para os locales en e pt-BR.
  • A build não valida itens, fluidos, redstone, lifecycle, topologia em mundo ou compatibilidade com os mods presentes em run/mods.

Impacto e pendências​

A baseline automatizada está verde, mas não basta para encerrar o Marco 0. A próxima validação deve preencher a matriz mínima dos blocos em mundo e separar claramente o que foi observado do que apenas compila.

Evidências​

  • Saída do Gradle em 10/09/2026: BUILD SUCCESSFUL e FE regression checks passed.
  • Saída do Docusaurus em 10/09/2026: arquivos estáticos gerados para en e pt-BR.
  • Commit: 83d6692 — docs: record version reconciliation baseline.

FND-2026-09-10-002 — Contratos de Port incompletos no core​

Tipo: descoberta técnica Estado: corrigida e protegida por regressão Área: core, Ports e canais Substitui: nenhuma Substituída por: nenhuma

Contexto​

A criação da primeira suíte ampla do core exerceu diretamente os contratos INodePort, em vez de depender apenas do comportamento observado no runtime Minecraft.

Registro​

  • WeaveNodePort ainda devolvia valores vazios para identidade, owner, atividade, suporte a payloads e reserva de canais.
  • WeavePort ainda devolvia valores vazios para ownerNodeId, capacidade de canais e suporte a payloads.
  • Esses stubs permitiam que o projeto compilasse e que caminhos mais externos funcionassem sem garantir o contrato público do core.
  • Os dois tipos passaram a expor owner, identidade, atividade, capacidade e payloads, além de aplicar o limite de reserva e liberação de canais.

Impacto e pendências​

As Ports agora possuem um contrato executável e coberto. O uso desses canais pelo runtime completo e a configuração por face continuam pertencendo aos marcos seguintes.

Evidências​

  • CoreRegressionTest.testPortContracts cobre identidade, owner, atividade, payloads e limite de canais.
  • ./gradlew build --warning-mode all passou após a correção.
  • Commit: fd03db3 — test: automate core and world regressions.

CHG-2026-09-10-004 — Suíte automatizada integrada ao build​

Tipo: mudança de infraestrutura e testes Estado: implementada e validada Área: build, core e runtime NeoForge Substitui: ausência de uma suíte base para topologia em mundo descrita em FND-2026-09-09-001 Substituída por: nenhuma

Registro​

  • O source set regression passou a executar também CoreRegressionTest.
  • O check depende das regressões de core e FE e do runGameTestServer; portanto, o build padrão falha se qualquer uma dessas camadas falhar.
  • O GameTestServer usa run-gametest, isolado dos mods auxiliares instalados em run/mods.
  • Foi adicionada uma estrutura vazia reutilizável para testes de mundo.
  • Os primeiros GameTests verificam a criação de todos os BlockEntities da baseline, o caráter stateless da Fiber, o binding Controller–Fiber–Port e o unbind após a quebra da Fiber.

Impacto e pendências​

A baseline agora detecta regressões rápidas do core e regressões reais de bloco em servidor. Ainda faltam testes automatizados para os quatro payloads, persistência e reload, unload de chunk, dimensões, topologias T5 Link e integração com mods auxiliares.

O teste de estados registra o comportamento implementado no momento: BROWNOUT permite scheduling degradado. Isso preserva a baseline enquanto a decisão de gameplay continua aberta; não resolve a divergência documental.

Evidências​

  • CoreRegressionTest.java.
  • WeaveBaselineGameTests.java.
  • data/weave_network/structure/empty.nbt.
  • Build integrado executado em 10/09/2026.
  • Commit: fd03db3 — test: automate core and world regressions.

TST-2026-09-10-003 — Primeira baseline automatizada multicamada​

Tipo: validação automatizada Estado: validada dentro da cobertura declarada Área: core, energia, blocos e topologia mínima Substitui: TST-2026-09-10-002, quanto à cobertura automatizada vigente Substituída por: TST-2026-09-10-004, quanto à cobertura de GameTests vigente

Registro​

  • coreRegressionTest passou cobrindo RingBuffer, ciclo de IO, contratos e canais de Port, lifecycle e cursor do grafo, fallback de tiers, capacidade Link, estados, histerese e orçamento do scheduler.
  • energyRegressionTest passou cobrindo seleção de endpoints, alimentação do Controller, conservação de FE, destino quase cheio e autotransferência.
  • O GameTestServer isolado executou três testes obrigatórios e informou All 3 required tests passed.
  • O servidor carregou somente Minecraft, NeoForge e Weave Network; mods auxiliares não participam desse resultado.
  • ./gradlew build --warning-mode all executou as três camadas e terminou com BUILD SUCCESSFUL em 16 segundos.

Impacto e pendências​

A validação reduz a necessidade de repetir manualmente os comportamentos fundamentais já cobertos. Ela ainda não encerra a matriz mínima do Marco 0, pois itens, fluidos, redstone, FE em mundo e os cenários multidimensionais permanecem fora dos GameTests.

Evidências​

  • Saída do Gradle em 10/09/2026: Core regression checks passed e FE regression checks passed.
  • Saída do GameTestServer em 10/09/2026: três testes obrigatórios aprovados.
  • Commit: fd03db3 — test: automate core and world regressions.

DEC-2026-09-10-005 — Fluxo de branches muda após o Marco 0​

Tipo: decisão de processo Estado: aceita Área: Git e integração Substitui: nenhuma Substituída por: nenhuma

Registro​

  • Durante o Marco 0, mudanças validadas são commitadas diretamente na main para consolidar a baseline recuperada.
  • A partir do Marco 1, o desenvolvimento ocorre na branch dev.
  • A main recebe o trabalho do Marco 1 e dos marcos seguintes por pull request quando o respectivo marco estiver concluído.

Impacto e pendências​

O encerramento do Marco 0 passa a ser também o ponto formal de mudança do fluxo de integração. Commits diretos realizados durante a recuperação não definem o processo dos marcos seguintes.

Evidências​

  • Orientação do mantenedor registrada em 10/09/2026.

CHG-2026-09-10-005 — GameTests cobrem schedulers locais de payload​

Tipo: mudança de testes Estado: implementada e validada Área: itens, fluidos e redstone Substitui: nenhuma Substituída por: nenhuma

Registro​

  • O scheduler de itens é exercitado contra dois baús vanilla e precisa conservar a pilha ao mover oito itens.
  • O scheduler de fluidos é exercitado através da capability NeoForge de caldeirões e precisa mover um balde de água.
  • O scheduler de redstone é exercitado contra um bloco de redstone e precisa propagar intensidade 15 para a Port de saída.
  • Destinos cheios de itens e fluidos precisam deixar a fonte inalterada.
  • A remoção da fonte de redstone precisa limpar o sinal anteriormente emitido.

Limite da validação​

Os testes usam Ports e endpoints reais no mundo, mas constroem o WeaveGraph diretamente e invocam cada scheduler. Eles validam resolução de mundo, capabilities e conservação do payload sem afirmar que Controller, energia de contenção e máquina de estados estejam integrados nesse mesmo cenário.

FE permanece coberto pela regressão determinística. Não existe armazenamento FE vanilla adequado para o mesmo GameTest; a integração em mundo será coberta pela futura camada de compatibilidade com mods auxiliares.

Evidências​

  • Commits: 6971a50 — test: cover local payload schedulers in world; 8ea2ff2 — test: protect payload endpoint edge cases.

TST-2026-09-10-004 — Oito GameTests da baseline aprovados​

Tipo: validação automatizada Estado: validada dentro da cobertura declarada Área: blocos, topologia mínima e schedulers locais Substitui: TST-2026-09-10-003, quanto à cobertura de GameTests vigente Substituída por: TST-2026-09-10-005, quanto à cobertura de GameTests vigente

Registro​

  • Os três testes anteriores de BlockEntities, binding e quebra de Fiber continuam aprovados.
  • Itens, fluidos e redstone passaram nos caminhos positivos em mundo.
  • Itens e fluidos passaram com destino cheio sem consumo da origem.
  • Redstone voltou a zero depois da remoção da fonte.
  • O GameTestServer informou All 8 required tests passed.
  • coreRegressionTest e energyRegressionTest também passaram no mesmo build.
  • ./gradlew build --warning-mode all terminou com BUILD SUCCESSFUL.

Impacto e pendências​

Os schedulers locais de três payloads deixam de depender apenas de testes manuais. A matriz do Marco 0 continua aberta para o fluxo completo pelo runtime, FE em mundo, persistência, unload e cenários multidimensionais.

Evidências​

  • Execução automatizada em 10/09/2026.
  • Commits de teste: 6971a50 e 8ea2ff2.

FND-2026-09-10-003 — Remoção de Port deixava registro no grafo​

Tipo: descoberta técnica Estado: corrigida e protegida por GameTest Área: lifecycle e topologia Substitui: nenhuma Substituída por: nenhuma

Contexto​

A revisão do lifecycle mostrou que Controller, Anchor e Gate limpavam o runtime em setRemoved(), enquanto WeavePortBlockEntity não implementava a mesma etapa.

Registro​

  • Uma Port quebrada deixava sua posição registrada no WeaveGraph até uma reconstrução posterior.
  • O endpoint ausente não transferia payload, mas continuava afetando contagem, observabilidade e potencialmente custos da topologia.
  • A Port agora chama WeaveRuntime.unregisterPort ao ser removida do mundo.

Evidências​

  • GameTest breakingPortUnregistersItFromGraph.
  • Commit: 7b321f9 — fix: clean runtime state when ports are removed.

CHG-2026-09-10-006 — Lifecycle e serialização entram na baseline​

Tipo: mudança de testes e correção Estado: implementada e validada Área: runtime, Controller, Port e NBT Substitui: nenhuma Substituída por: nenhuma

Registro​

  • A remoção de uma Port ligada precisa reduzir imediatamente a contagem do grafo.
  • A remoção do Controller precisa eliminar seu grafo do runtime.
  • Estado ativo, tier, energia, capacidade, UUID e aceitação de FE do Controller passam por round-trip NBT.
  • Binding conhecido, modo global, modo por face e sinal redstone da Port passam por round-trip NBT.
  • O teste de Controller aguarda onLoad(), quando o UUID e o registro no runtime são efetivamente criados.

Limite da validação​

O round-trip chama a serialização e desserialização reais dos BlockEntities com o registry provider do mundo. Ele não descarrega o chunk nem reinicia o servidor; unload/load e world reload continuam pendentes.

Evidências​

  • Commit: 7b321f9 — fix: clean runtime state when ports are removed.

TST-2026-09-10-005 — Doze GameTests da baseline aprovados​

Tipo: validação automatizada Estado: validada dentro da cobertura declarada Área: blocos, topologia mínima, lifecycle, NBT e schedulers locais Substitui: TST-2026-09-10-004, quanto à cobertura de GameTests vigente Substituída por: nenhuma

Registro​

  • Os oito GameTests anteriores continuam aprovados.
  • Remoção de Port e Controller limpa os registros esperados no runtime.
  • Controller e Port preservam seus campos cobertos em round-trip NBT.
  • O GameTestServer informou All 12 required tests passed.
  • coreRegressionTest e energyRegressionTest passaram no mesmo build.
  • ./gradlew build --warning-mode all terminou com BUILD SUCCESSFUL em 15 segundos.

Evidências​

  • Execução automatizada em 10/09/2026.
  • Commit: 7b321f9.

TST-2026-09-10-006 — Marco 0 encerrado com baseline verificável​

Tipo: validação de marco Estado: validada Área: baseline recuperada Substitui: nenhuma Substituída por: nenhuma

Registro​

  • O ambiente usa Minecraft 1.21.1, Java 21, NeoForge 21.1.250, ModDevGradle 2.0.146 e Gradle 9.7.1.
  • Builds internas usam 0.0.0-dev, sem tratar números históricos como releases públicas.
  • O build padrão executa regressões de core, FE e doze GameTests em servidor isolado.
  • Todos os oito blocos registrados possuem uma classificação baseada na evidência disponível.
  • Controller, Fiber e a fundação da Port possuem cobertura funcional mínima; os demais blocos permanecem explicitamente parciais, implementados sem regressão integral ou planejados.
  • As lacunas de integridade, payloads completos, topologia Link e reload permanecem abertas no Marco 1.

Impacto e pendências​

O objetivo do Marco 0 foi atendido: o projeto possui um ponto de partida reproduzível, versionamento coerente e comportamentos fundamentais verificáveis. O encerramento não declara o mod jogável nem valida sistemas além da cobertura registrada.

Conforme DEC-2026-09-10-005, o trabalho passa da main para a branch dev; a próxima integração na main será feita por pull request ao concluir o Marco 1.

Evidências​

  • Builds e validações TST-2026-09-10-002 a TST-2026-09-10-005.
  • Commits técnicos: fd03db3, 6971a50, 8ea2ff2 e 7b321f9.
  • Matriz mínima no Roadmap até 1.0.

Próximas entradas esperadas​

  • Matriz de testes da rede mínima na build atualizada.
  • Decisão completa do modelo energético do Controller.
  • Correção e validação do gating T5 Link para Anchor.
  • Decisão e migração da identidade multidimensional de endpoints.
  • Encerramento do Marco 0 e início do fluxo pela dev.