2.0.12 — Historical Release Evidence, Regression Gate Hardening e Test Suite Stability — V1

• Inicia a linha 2.0.12 sem reutilizar a release 2.0.11 já promovida.
• Estágio 1 corrige o gate histórico 2.0.9 para usar evidência congelada em vez do README/metadata da release atual.
• Estágio 2 cria ReleaseEvidenceAssertions e separa explicitamente CURRENT_RELEASE de HISTORICAL_RELEASE.
• Estágio 3 audita os gates históricos 2.0.x, classifica-os em CURRENT_VERSION_GATE, HISTORICAL_EVIDENCE_GATE, STRUCTURAL_BASELINE_GATE, RUNTIME_UNCHANGED_GATE e API_COMPATIBILITY_GATE.
• Estágio 4 sela 57 artefatos históricos de 2.0.9–2.0.11 por SHA-256 canônico, impede sobrescrita/regeneração silenciosa de manifests/baselines e cria uma baseline 2.0.12 nova gerada diretamente do estado atual, sem copiar a baseline 2.0.11.
• Estágio 5 blinda o mínimo temporal: TOTAL_CYCLE=1 permanece apenas como entrada legada de migração/rejeição, 2/3/20/480 permanecem operacionais, SPLIT_DAY_NIGHT 1+1 continua válido, e gates históricos não podem voltar a tratar 1 minuto como configuração válida; cenários antigos equivalentes a 20x passam a testar a matemática diretamente.
• Estágio 6 adiciona gate cumulativo da arquitetura temporal: preserva gameTime como relógio técnico/monotônico e dayTime como calendário/solar, sela SeasonCalendar → dayTime, mantém TemperatureAPI.API_VERSION = 1, GameTimeSnapshot, TemporalDiscontinuityAPI e TemporalForwardAdvanceAPI, exige um único writer absoluto server-side, valida avanço sazonal estritamente futuro e impede que avanço monotônico autorizado gere nova epoch, observedDayTimeRewinds ou EXTERNAL_MOD_TIME_CHANGE; /time set e /time add mantêm contratos distintos.
• Estágio 7 adiciona gate cumulativo de comandos, cliente, ecologia e compatibilidade: preserva /ecotermico season como consulta e as 12 combinações spring|summer|autumn|winter × early|mid|end, proíbe /eco, none, back e previous, sela a cadeia ThermalCommands → SeasonTimeAdvanceService → SeasonForwardTargetMath → TemporalForwardAdvanceAPI, mantém rebase visual monotônico/revision ordering/snapshot autoritativo, exige reconciliação sazonal limitada a estado já carregado e preserva WildVitals, Sidereon e os consumidores API required/required-v1-legacy/optional.
• Estágio 8 fecha a release 2.0.12 com gate final de evidência corrente/histórica, baseline runtime 2.0.11 ↔ 2.0.12 byte-idêntica, manifest full-source e propriedade estrutural targetDayTime > currentDayTime; o fechamento definitivo exige a suíte automatizada completa com 0 failed.
• Fechamento 2.0.12 preserva API V1, runtime temporal, WildVitals, Sidereon, ausência de force-load e todas as features existentes; nenhuma remoção de feature ou mudança de src/main foi necessária.
• A comparação de versões passa a ter contrato semântico exato: 2.0.1 não corresponde a 2.0.10, 2.0.11 ou 2.0.12, e 2.0.9 não corresponde a 2.0.90.
• Remove verificações frágeis por substring de mod_version nos gates 2.0.4 e nos validadores Python históricos auditados; o novo gate de Stage 3 impede sua reintrodução.
• Releases históricas são comprovadas por baseline, manifest, hashes, changelog histórico e contratos congelados da própria release; nunca precisam continuar ativas em gradle.properties ou README.
• Contratos runtime unchanged comparam baseline congelada da release anterior com baseline congelada da release que declarou não alterar runtime; não comparam baseline antiga contra src/main futuro.
• Migra os gates de evidência/runtime-unchanged 2.0.5–2.0.11 para o contrato histórico canônico, preservando as regras específicas de cada gate.
• src/main permanece byte-idêntico à 2.0.11 durante este hardening de testes/gates.
• Sincroniza as regiões CURRENT_RELEASE dos 13 living documents para 2.0.12 sem reclassificar conteúdo histórico como release ativa.
• Versionamento continua exclusivamente manual; nenhum script de bump/set/promote version é introduzido.

2.0.11 — Temporal Test Suite Regression Hotfix — V1

• Promove manualmente EcoTermico 2.0.10 → EcoTermico 2.0.11; não reutiliza 2.0.10 e não regride para versões anteriores.
• Corrige as 9 falhas observadas no primeiro ./gradlew.bat clean test --stacktrace executado integralmente após a promoção 2.0.10: 1392 tests completed, 9 failed.
• Atualiza testes antigos de TOTAL_CYCLE que ainda tentavam executar o valor legado de 1 minuto; testes operacionais passam a usar o mínimo vigente de 2 minutos, enquanto o caso 1 → 2 continua coberto exclusivamente como migração/rejeição.
• Mantém matrizes históricas de apresentação que usam taxa 20x sem tratá-las como configuração TOTAL_CYCLE=1; o gate de duração configurável usa explicitamente CONFIGURABLE_CYCLE_MINUTES = {2, 5, 10, 20}.
• Corrige o gate de integrações opcionais para reconhecer somente declarações Gradle reais no início da linha, evitando falso positivo com nomes de pacote/classe como api.integration.EcoTermicoSidereonAuthorityPolicyTest.
• Corrige os gates históricos 2.0.1/2.0.2 para comparar baseline congelada → baseline final da própria release, em vez de comparar o runtime 2.0.11 contra hashes históricos.
• Preserva o hash histórico do Baseline201StructuralContractTest dentro da baseline 2.0.1 sem exigir que o arquivo de teste atual permaneça byte-idêntico para sempre.
• Corrige o gate 2.0.3 de regressão de versão: deixa de usar substring mod_version=2.0.1, que interpretava incorretamente 2.0.10/2.0.11, e passa a usar correspondência de linha exata.
• Preserva integralmente o limite mínimo de 2 minutos, /ecotermico season, avanço estritamente para frente, TemporalForwardAdvanceAPI, GameTimeSnapshot, TemporalDiscontinuityAPI, TemperatureAPI.API_VERSION = 1, WildVitals e Sidereon.
• src/main permanece byte-idêntico à 2.0.10; API pública, config keys, registry/network IDs, SavedData, protocolo e comportamento de gameplay não mudam.
• Mantém Minecraft 1.21.1, NeoForge 21.1.248 e Java 21.
• Versionamento permanece manual; nenhum set-version, bump-version ou promote-version foi criado.

2.0.10 — Minimum 2-Minute Day Cycle, Forward-Only Season Administration e Temporal Compatibility API Hardening — V1

• Promove manualmente EcoTermico 2.0.9 → EcoTermico 2.0.10; 2.0.9 e todas as baselines anteriores permanecem preservadas somente como histórico/evidência.
• Define TOTAL_CYCLE com mínimo operacional canônico de 2 minutos, mantendo o padrão de 20 minutos e a faixa máxima de 480 minutos.
• Mantém SPLIT_DAY_NIGHT com mínimo individual de 1 minuto por fase, de modo que 1 + 1 = 2 minutos continue válido como menor ciclo completo.
• Migra uma única vez o valor legado totalCycleMinutes=1 para 2, preservando a intenção administrativa sem converter indevidamente para 20; 0 e valores negativos nunca são durações operacionais válidas.
• Adiciona /ecotermico season [spring|summer|autumn|winter] [early|mid|end], mantendo /ecotermico season sem argumentos como consulta e /ecotermico como única raiz administrativa.
• As 12 combinações sazonais usam a matemática proporcional canônica de SeasonCalendarMath.stageForDay(...) e avançam para o primeiro dia do estágio solicitado.
• Toda mudança administrativa de estação é somente para frente: o alvo satisfaz obrigatoriamente targetDayTime > currentDayTime; alvos iguais ou passados são resolvidos no próximo ano climático, nunca por rewind.
• Preserva exatamente timeOfDayTicks, alterando apenas a quantidade de dias necessária para alcançar o destino futuro.
• Centraliza a operação em SeasonTimeAdvanceService e mantém TemporalForwardAdvanceAPI como único writer absoluto server-side autorizado para avanço monotônico normal.
• Avanço monotônico autorizado não escreve gameTime, não troca TOTAL_CYCLE/SPLIT_DAY_NIGHT, não altera dayTimeFraction/dayTimePerTick, não reseta rate controller, não cria nova temporalEpoch e não é classificado como EXTERNAL_MOD_TIME_CHANGE.
• Saltos administrativos grandes permitem rebase visual para frente no cliente sem interpolar por dezenas/centenas de dias, preservando o ClientMonotonicPresentationGuard, proteção contra micro-rewind/zero-crossing e ordering de snapshots.
• Reutiliza os mecanismos existentes de SeasonSyncData, foliage, phenology, plant dormancy, seasonal snow, precipitation, thermal season modifier e chunk seasonal reconciliation; nenhum chunk é force-loaded e não existe varredura global síncrona.
• Adiciona a capability pública time.forward_advance, preservando time.dual_clocks, time.day_rate e season.calendar.
• Mantém GameTimeSnapshot como contrato temporal completo, preserva TemporalDiscontinuityAPI e mantém TemperatureAPI.API_VERSION = 1 porque a evolução é aditiva.
• Preserva compatibilidade com WildVitals, Sidereon, consumidores obrigatórios/ opcionais e consumidor legado API V1; Sidereon não recebe autoridade sobre dayTime, gameTime, estação física ou clima físico.
• Não cria nova fonte temporal, não recria /eco, não remove features e não introduz scripts de versionamento.
• Gate final obrigatório: temporalRelease210Stage8 valida a cadeia SeasonForwardTargetMath → TemporalForwardAdvancePolicy → TemporalForwardAdvanceAPI e uma matriz final de 50.400 destinos; remover a propriedade de avanço estrito quebra o release gate.
• Mantém Minecraft 1.21.1, NeoForge 21.1.248 e Java 21.
• Nova linha mínima de manutenção: 2.0.10 → 2.0.11 → 2.0.12 → ....

2.0.9 — Gradle Configuration Cache Temporal Release Gate Hotfix — V1

• Promove manualmente EcoTermico 2.0.8 → EcoTermico 2.0.9; não reutiliza 2.0.8 e não regride nenhuma feature, API, protocolo, persistência ou hardening temporal.
• Confirma pelo resultado real do usuário que clean test da 2.0.8 passa e que a falha NoSuchFileException: mainargs.txt foi encerrada.
• Corrige a falha residual de clean build em temporalReleaseGate com Gradle 9.2.1/configuration cache: o gate não chama mais file(...) dentro de doLast.
• Move a resolução dos caminhos obrigatórios para a fase de configuração, cria temporalReleaseRequiredGateSources como FileCollection e registra a coleção em inputs.files(...) com path sensitivity relativa.
• A ação de execução usa somente task.inputs.files.files para validar ausência de fontes obrigatórias, sem capturar Project, Project.file(), projectDir, rootProject ou o objeto do script Gradle.
• Preserva a arquitetura 2.0.8 de um único executor JUnit real, a task padrão test preparada pelo ModDevGradle/NeoForge; os aliases temporais históricos continuam desabilitados e dependentes de test.
• Adiciona temporalCompatibility209 e TemporalConfigurationCache209ContractTest ao gate cumulativo, mantendo todos os gates 2.0.0–2.0.8.
• Mantém org.gradle.parallel=true e org.gradle.configuration-cache=true; a correção não mascara o problema desligando recursos globais do Gradle.
• Mantém src/main byte-idêntico à baseline final 2.0.8; nenhuma regra de gameplay, relógio, epoch, revision, fingerprint, snapshot, atomic commit, REBASE/HUD, zero-crossing, sign-flip ou Monotonic Presentation Guard foi alterada.
• Mantém Minecraft 1.21.1, NeoForge 21.1.248 e Java 21.
• Preserva versionamento exclusivamente manual; nenhum set-version, bump-version ou promoção automática foi criado.
• Nova linha mínima de manutenção: 2.0.9 → 2.0.10 → 2.0.11 → ....

2.0.8 — Canonical ModDevGradle JUnit Executor Hotfix — V1

• Promove manualmente EcoTermico 2.0.7 → EcoTermico 2.0.8; não reutiliza 2.0.7 e não regride nenhuma feature, API, protocolo, persistência ou hardening temporal.
• Corrige a falha ainda reproduzida no clean build do Windows/Gradle 9.2.1 em temporalCompatibility203, onde um executor temporal customizado ainda podia falhar antes do JUnit com java.nio.file.NoSuchFileException: mainargs.txt.
• Substitui a estratégia de "vários executores Test serializados" por uma autoridade única de execução JUnit: a task padrão test, que é a task preparada pelo neoForge.unitTest/ModDevGradle para o bootstrap de Minecraft/NeoForge.
• Preserva os nomes históricos temporalMatrix200 até temporalCompatibility207 como aliases/gates de compatibilidade. Eles continuam registrados, mas suas ações Test ficam desabilitadas e cada alias depende de test; assim, qualquer gate temporal ainda executa a suíte JUnit, porém o processo JUnit é iniciado uma única vez.
• Adiciona temporalCompatibility208 ao temporalReleaseGate e mantém todos os gates cumulativos 2.0.0–2.0.7.
• Preserva org.gradle.parallel=true e org.gradle.configuration-cache=true; não é necessário desligar o paralelismo global nem a configuration cache.
• Mantém o contrato 2.0.7 (TemporalTestExecutionLock, maxParallelForks=1, mustRunAfter(test)) como proteção histórica, embora os aliases não iniciem mais executores próprios.
• Mantém src/main byte-idêntico à baseline final 2.0.7; nenhuma regra de gameplay, clock, epoch, revision, fingerprint, snapshot, atomic commit, REBASE/HUD, zero-crossing, sign-flip ou Monotonic Presentation Guard foi alterada.
• Mantém Minecraft 1.21.1, NeoForge 21.1.248 e Java 21.
• Preserva versionamento exclusivamente manual; nenhum set-version, bump-version ou promoção automática foi criado.
• Nova linha mínima de manutenção: 2.0.8 → 2.0.9 → 2.0.10 → ....

2.0.7 — Windows Gradle Temporal Test Executor Isolation Hotfix — V1

• Promove manualmente EcoTermico 2.0.6 → EcoTermico 2.0.7; não reutiliza 2.0.6 e não regride nenhuma feature, API, protocolo, persistência ou hardening temporal.
• Corrige o clean build no Windows/Gradle 9.2.1 em que as matrizes temporais customizadas eram lançadas simultaneamente com org.gradle.parallel=true e os executores falhavam antes dos testes com java.nio.file.NoSuchFileException: mainargs.txt.
• Mantém o paralelismo global do Gradle habilitado e serializa somente as tasks temporais registradas por registerTemporalMatrixTask, através de um BuildService compartilhado com maxParallelUsages=1.
• Define maxParallelForks=1 em cada task temporal para impedir forks concorrentes dentro da mesma matriz, sem afetar a task test normal nem outras tasks do projeto.
• Preserva o working directory atual das matrizes; contratos históricos que leem arquivos do projeto não são deslocados para diretórios temporários.
• Mantém temporalMatrix200, temporalMatrix201Residual, temporalMatrix202MicroRewind, temporalCompatibility203, todos os gates 2.0.4, temporalCompatibility205 e temporalCompatibility206; adiciona temporalCompatibility207 ao temporalReleaseGate.
• Mantém org.gradle.parallel=true; a correção não reduz o paralelismo do restante do build.
• Mantém src/main byte-idêntico à baseline final 2.0.6; nenhuma regra de gameplay, clock, epoch, revision, fingerprint, snapshot, atomic commit, REBASE/HUD ou Monotonic Presentation Guard foi alterada.
• Preserva versionamento exclusivamente manual; nenhum set-version, bump-version ou promoção automática foi criado.
• Nova linha mínima de manutenção: 2.0.7 → 2.0.8 → 2.0.9 → ....

2.0.6 — Temporal Residual Test Contract Hotfix — V1

• Promove manualmente EcoTermico 2.0.5 → EcoTermico 2.0.6; não reutiliza 2.0.5 e não regride nenhuma feature, API, protocolo, persistência ou hardening temporal.
• Corrige as 3 falhas residuais observadas após clean test da 2.0.5, mantendo src/main byte-idêntico às baselines finais 2.0.4/2.0.5.
• Torna TemporalTestInfrastructure205ContractTest histórico/forward-compatible: ele continua provando a existência da evidência 2.0.5 sem exigir que releases futuras permaneçam exatamente em 2.0.5 e passa a validar a redação real 23 falhas de teste.
• Corrige ClientTemporalSnapshotTrackerTest para modelar corretamente a identidade autoritativa epoch → gameTime → revision: o snapshot subsequente usa revision=2, preservando a regra de revision estritamente crescente dentro do epoch.
• Corrige TemporalEpochAuthorityContractTest para distinguir tick de housekeeping de ticker temporal. LevelTickEvent.Post permanece permitido exclusivamente para expirar/remover autorização single-use; o contrato proíbe nesse bloco newState, authorizeInternal, SEQUENCE.next, PacketDistributor e qualquer writer de clocks.
• Preserva ServerLevel#setDayTime(long) observado em HEAD, beforeAbsoluteDayTimeWrite, rewind cumulativo, /time set, /time add, sleep skip, autorização consumível, epoch/revision/fingerprint, atomic commit, REBASE/HUD, zero-crossing, sign-flip stateful e Monotonic Presentation Guard.
• Mantém src/main sem alterações; esta release corrige somente testes, gates, documentação, versão e baseline de release.
• Adiciona temporalCompatibility206 ao temporalReleaseGate sem remover nenhuma matriz/gate 2.0.0–2.0.5.
• Versionamento permanece manual; nenhum script de set-version, bump-version ou promoção automática foi criado.
• Nova linha mínima de manutenção: 2.0.6 → 2.0.7 → 2.0.8 → ....

2.0.5 — Temporal Test Suite & Mixin JUnit Infrastructure Hotfix — V1

• Promove manualmente EcoTermico 2.0.4 → EcoTermico 2.0.5; não reutiliza 2.0.4 e não regride nenhuma feature, API, protocolo, persistência ou hardening temporal.
• Corrige as 23 falhas de teste observadas após clean test da 2.0.4, mantendo src/main byte-idêntico à baseline 2.0.4.
• Corrige contratos de fonte que assumiam o working directory do JUnit: TemporalDeprecation204Stage5SourceContractTest e TemporalEpochAuthorityContractTest passam a localizar explicitamente a raiz do projeto antes de ler arquivos.
• Remove carregamento direto de classes @Mixin pelos contratos JUnit de callback. Os testes agora separam corretamente owner/método mapped por reflexão de assinatura do callback por contrato de fonte, evitando IllegalClassLoadError/NoClassDefFoundError sem enfraquecer a validação.
• Atualiza o contrato residual 2.0.1 de sign-flip para a política stateful vigente (SMALL_SIGN_FLIP_JITTER + advanceSignFlipPolicyState) em vez de exigir o helper histórico removido stabilizeNearZeroSignFlip.
• Liga TemporalHardening201Stage6StructuralContractTest de fato à temporalMatrix201Residual e à lista obrigatória do temporalReleaseGate.
• Alinha ClientTemporalSnapshotTrackerTest ao ordering autoritativo atual: o primeiro snapshot é FIRST; localArrivalGameTime não volta a ser relógio/estimador de latência e não reintroduz clientGameTime - serverGameTime.
• Alinha o contrato de lifecycle à arquitetura centralizada em ClientTemporalLifecycleCoordinator, que continua resetando snapshot, epoch, revision, rate, local tick clock e correção visual.
• Alinha o contrato de /time add ao comportamento vigente: autorização consumível single-use preservando continuidade e sem epoch artificial, enquanto /time set continua autorizando a descontinuidade/epoch apropriada.
• Preserva integralmente LevelDayTimeDiscontinuityMixin em ServerLevel#setDayTime(long) HEAD, beforeAbsoluteDayTimeWrite, rewind cumulativo, autorização consumível, epoch/revision/fingerprint, atomic commit, REBASE/HUD, zero-crossing, sign-flip stateful e Monotonic Presentation Guard.
• Preserva as baselines 2.0.0–2.0.4 como histórico/evidência e adiciona a baseline estrutural 2.0.5.
• Nova linha mínima de manutenção: 2.0.5 → 2.0.6 → 2.0.7 → ....
• Versionamento permanece exclusivamente manual; nenhum script de promoção automática foi criado.

2.0.4 — ServerLevel DayTime Mixin Compatibility, JUnit Bootstrap Hardening e Temporal Test API Cleanup — V1

Estágio 7/7 — EcoTermico 2.0.4, Changelog e Nova Baseline

• Promove manualmente EcoTermico 2.0.3 → EcoTermico 2.0.4, sem reutilizar 2.0.3 e sem regressão para 2.0.2, 2.0.1, 2.0.0 ou 1.x.
• Corrige o target inválido de LevelDayTimeDiscontinuityMixin: o observer deixa de mirar Level#setDayTime e passa a mirar diretamente ServerLevel#setDayTime(long).
• Preserva TemporalEpochStateSync.beforeAbsoluteDayTimeWrite(level, attemptedDayTime) em HEAD, antes do write nativo, mantendo observer ≠ writer: o mixin não cancela o setter, não altera attemptedDayTime, não escreve dayTime, gameTime ou dayTimePerTick e não cria segundo clock.
• Preserva o rewind externo cumulativo de ExternalTemporalRewindTracker, a distinção entre mudança autorizada e rewind externo inesperado e o avanço de epoch somente conforme a arquitetura temporal existente.
• Preserva /time set, /time add, sleep skip, autorizações consumíveis single-use, REBASE/HUD, STALE_EPOCH, OUT_OF_ORDER, epoch, revision, fingerprint, snapshot e atomic commit.
• Audita todos os targets temporais críticos de Mixin, incluindo owner, método, descriptor, lado client/server, remap e assinatura dos callbacks para ServerLevel, MinecraftServer, ClientLevel e handler NeoForge.
• Mantém "required": true e "defaultRequire": 1; não introduz required=false, require=0, mixin opcional ou refmap artificial para mascarar target inválido.
• Adiciona novo gate de bootstrap de Mixin e hardening por contratos, fazendo o gate falhar antes da release se reaparecer target/descriptor inválido, segundo writer, cancelamento do setter ou enfraquecimento da política de injeção.
• Migra os testes temporais ativos para as APIs atuais: ClientTemporalReconciliation, validateReconciliation(...), tracker.classify(snapshot), TemporalReconciliationContext e TemporalSnapshotAge.
• Preserva os shims deprecated necessários para compatibilidade binária/integração; testes de legacy API continuam deliberados e usam apenas @SuppressWarnings("deprecation") localizado.
• Remove os 25 warnings de APIs temporais deprecated dos testes ativos, sem suppress global e sem reintroduzir clientGameTime - serverGameTime.
• Preserva integralmente as matrizes e o hardening temporal 2.0.0–2.0.3, incluindo Physical Time × Presentation Time, zero-crossing hardening, sign-flip stateful e Monotonic Presentation Guard.
• Preserva o cenário 5 min / rate 4 / server 10 TPS / client 20 TPS / delay 0 com visualRegressionCount = 0.
• Cria a baseline final EcoTermico 2.0.4 em docs/BASELINE_SRC_MAIN_SHA256_2.0.4_FINAL.txt, docs/FILE_MANIFEST_SHA256_2.0.4_FINAL.txt, docs/PROTECTED_CONTRACTS_SHA256_2.0.4_FINAL.txt, docs/BASELINE_STRUCTURAL_SHA256_2.0.4_FINAL.txt e src/test/resources/baseline/2.0.4/.
• As baselines 2.0.0, 2.0.1, 2.0.2 e 2.0.3 permanecem somente como histórico/evidência e não são reutilizadas como identidade da release atual.
• O temporalReleaseGate continua cumulativo e passa a incluir temporalRelease204Stage7, sem remover temporalMatrix200, temporalMatrix201Residual, temporalMatrix202MicroRewind, temporalCompatibility203 ou os gates 2.0.4 dos Estágios 1–6.
• Versionamento permanece exclusivamente manual; nenhum set-version, bump-version, promote-version ou equivalente foi criado.
• Nova linha mínima: 2.0.4 → 2.0.5 → 2.0.6 → ....

Gate de promoção revalidado antes da mudança de versão: Estágio 4 81/81, Estágio 5 58/58, Estágio 6 53/53, todos com ERRORS=0; contratos isolados 6/6, 11/11 e 21/21.

Progresso: 7/7 — concluído e promovido.

[Histórico pré-release] EcoTermico 2.0.4 — Candidato, Estágio 5/7 — Limpeza de APIs Temporais Deprecated — V1

• Naquele estágio pré-release, a release vigente ainda era 2.0.3 e a promoção para 2.0.4 permanecia reservada ao estágio final.
• Migra testes temporais ativos de validateResolved(...) para ClientTemporalReconciliation + validateReconciliation(...).
• Migra classificação normal para tracker.classify(snapshot) e remove dependência de localArrivalGameTime dos testes correntes.
• Substitui usos normais de packetAgeTicks(...) por TemporalReconciliationContext/TemporalSnapshotAge, sem reintroduzir clientGameTime - serverGameTime.
• Migra projeções normais do overload deprecated projectAuthoritativeSnapshot(long, snapshot) para o fluxo atual de contexto/metadados autoritativos.
• Preserva os shims deprecated no código principal para compatibilidade binária e integração.
• Mantém chamadas deprecated apenas em testes explicitamente de compatibilidade legacy, com @SuppressWarnings("deprecation") localizado no método; não existe supressão global.
• Adiciona temporalDeprecation204Stage5 ao temporalReleaseGate, preservando todos os gates anteriores.
• src/main permanece byte-idêntico ao candidato do Estágio 4; nenhuma regra de gameplay, epoch, revision, fingerprint, snapshot, atomic commit ou mixin temporal foi alterada neste estágio.
• O conjunto dos sete testes migrados compila com Java 21 e -Xlint:deprecation sem warnings de depreciação.

Progresso do candidato 2.0.4: 5/7.

2.0.3 — NeoForge 1.21.1 Compile Compatibility Hotfix — V1

• Promove manualmente EcoTermico 2.0.2 → EcoTermico 2.0.3; não reutiliza 2.0.2 e não regride versão.
• Corrige falha de compilação em TemporalSnapshotRevisionStateSync: GameRules.ADVANCE_TIME não existe na API usada pelo Minecraft 1.21.1 / NeoForge 21.1.248.
• Usa a gamerule booleana nativa GameRules.RULE_DAYLIGHT por getBoolean(...), preservando exatamente o estado doDaylightCycle incluído no fingerprint temporal.
• Não altera gameTime, dayTime, dayTimeFraction, dayTimePerTick, epoch, revision, fingerprint ordering, commit atômico ou a arquitetura Physical Time × Presentation Time.
• Preserva integralmente monotonic presentation, zero-crossing hardening, sign-flip stateful, matrizes 2.0.0/2.0.1/2.0.2 e temporalReleaseGate.
• Nenhuma feature, API pública, persistência, fenologia, ecologia, TemperatureAPI, WildVitals ou integração autoritativa foi removida.
• Linha mínima futura: 2.0.3 → 2.0.4 → 2.0.5 → ....
• Versionamento permanece manual; nenhum script automático de promoção foi criado.

2.0.2 — Monotonic Presentation Time, Zero-Crossing Hardening e Temporal Gate Expansion — V1

Estágio 7/7 — EcoTermico 2.0.2, Changelog e Nova Baseline

• Promove manualmente EcoTermico 2.0.1 → EcoTermico 2.0.2, sem reutilizar 2.0.1, sem regressão para 2.0.0 e sem retorno à linha 1.x.
• Corrige o micro-recuo visual próximo de zero sem alterar o relógio físico, gameplay, TemperatureAPI, fenologia, ecologia server-side ou integrações autoritativas.
• Refatora SIGN_FLIP_JITTER para uma política stateful que distingue ZERO_CROSSING_NORMAL, SMALL_SIGN_FLIP_JITTER, REAL_DIRECTION_CHANGE, AUTHORIZED_BACKWARD_JUMP e REBASE.
• Adiciona dead-zone estável com histerese ao redor de zero, impedindo efeito mola e oscilações como -0.5 → +0.4 → -0.3 → +0.2 de produzirem movimento visual para trás.
• Garante apresentação monotônica em sincronização normal: em timeline física forward, presentation[n+1] >= presentation[n].
• Preserva a convergência de correctionDebt em budget finito; clamps de apresentação não escondem dívida válida, não introduzem snap e não substituem a lógica de sincronização.
• Adiciona ClientMonotonicPresentationGuard usando representação contínua/carry-aware, sem comparar ingenuamente valores reduzidos módulo 24000.
• Preserva separados presentationCelestialTime e presentationAbsoluteDayTime; REBASE celestial não altera indevidamente o dia absoluto do HUD.
• Corrige especificamente a regressão ciclo 5 min / rate 4 / server 10 TPS / client 20 TPS / delay 0, agora coberta por matriz automatizada com visualRegressionCount = 0.
• Amplia a matriz 2.0.2 para 360 combinações-base de ciclos 1/2/5/10/20 min, server TPS 20/18/15/12/10/5, client TPS 20/15/10 e delays 0/1/2/5 ticks, além de jitter, reorder, freeze curto, rate change, dívidas próximas de zero e cruzamentos de sinal.
• Corrige o Gate Temporal Definitivo: o temporalReleaseGate agora executa obrigatoriamente a matriz temporal completa 2.0.0, a matriz residual 2.0.1 e a matriz de micro-recuo 2.0.2, em vez de apenas verificar a existência de fontes antigas.
• Preserva integralmente o hardening 2.0.1: rewind cumulativo, autorizações consumíveis, sleep skip, /time add, REBASE/HUD, epoch/revision/fingerprint, STALE_EPOCH, ordering, jitter/reorder handling e commit atômico.
• Preserva a arquitetura Physical Time × Presentation Time, mantendo renderer/HUD read-only e impedindo segundo writer server-side, uso de clientGameTime - serverGameTime como latência e uso de TPS estimado para modificar tempo físico.
• Cria docs/BASELINE_SRC_MAIN_SHA256_2.0.2_FINAL.txt, docs/FILE_MANIFEST_SHA256_2.0.2_FINAL.txt, docs/PROTECTED_CONTRACTS_SHA256_2.0.2_FINAL.txt e src/test/resources/baseline/2.0.2/ como nova baseline mínima.
• As baselines 2.0.0 e 2.0.1 permanecem imutáveis como histórico/evidência de não regressão.
• Nova linha mínima de manutenção: 2.0.2 → 2.0.3 → 2.0.4 → ....
• Versionamento permanece exclusivamente manual; nenhum set-version, bump-version, promote-version ou equivalente foi criado.

Gate de promoção revalidado antes da mudança de versão: Stage 5 53/53, ERRORS=0, runner comportamental 5/5; Stage 6 54/54, ERRORS=0; cenário obrigatório com visualRegressionCount = 0.

Progresso: 7/7 — concluído e promovido.

2.0.1 — Hardening Temporal Pós-2.0.0, Rewinds Externos e Coerência de Apresentação — V1

Estágio 8/8 — EcoTermico 2.0.1, Changelog e Nova Baseline

• Promove manualmente EcoTermico 2.0.0 → EcoTermico 2.0.1, sem reutilizar 2.0.0 e sem regressão para a linha 1.x.
• Consolida a detecção cumulativa de rewinds externos: pequenos rewinds repetidos acumulam evidência, enquanto ruído isolado continua tolerado.
• Impede tempestade de epochs para o mesmo burst por latch de incidente, liberado por recuperação, autorização/lifecycle ou inatividade real.
• Integra autorizações consumíveis com razão, epoch e validade curta para /time set, /time add, sleep, rebuild, reset e TemporalDiscontinuityAPI.authorize(...), evitando falsos positivos e dupla epoch.
• Adiciona convergência visual segura e limitada após sleep skip, grandes /time add e mudanças administrativas para frente, sem snap, overshoot, efeito mola ou céu para trás.
• Corrige divergência física × visual prolongada com budgets finitos de correção e mantém correctionDebt → 0 dentro de janela limitada.
• Separa fase celestial de apresentação de dia absoluto de apresentação: REBASE pode remover ciclos completos da fase sem fazer o HUD perder o número absoluto do dia.
• Corrige a coerência de relógio, número do dia, Sol, Lua, estrelas e sky angle durante REBASE.
• Adiciona matrizes automatizadas para rewinds cumulativos, forward jumps e REBASE/HUD, além do Gate Temporal Definitivo 2.0.1.
• Mantém STALE_EPOCH, ordering por epoch/revision/fingerprint, commit atômico e rejeição de snapshots antigos.
• Preserva integralmente as features e contratos públicos da 2.0.0, incluindo protocolo de rede 8, API V1, persistência e ownership único de dayTimePerTick.
• Não reintroduz segundo writer temporal server-side, renderer escrevendo clocks, estimativa clientGameTime - serverGameTime ou TPS estimado modificando tempo físico.
• Cria docs/BASELINE_SRC_MAIN_SHA256_2.0.1_FINAL.txt e src/test/resources/baseline/2.0.1/ como nova baseline mínima para futuras hotfixes 2.0.2+.
• Versionamento permanece exclusivamente manual; nenhum set-version, bump-version ou script de promoção automática foi criado.

Progresso: 8/8 — concluído.

2.0.0 — Arquitetura Temporal Definitiva, Sincronização Autoritativa e Estabilidade de Ciclos Curtos — V1

Estágio 10/10 — EcoTermico 2.0.0, Changelog e Nova Base Temporal

• Promove oficialmente e manualmente EcoTermico 1.2.41 → EcoTermico 2.0.0 após os gates temporais definitivos demonstrarem ERRORS=0; não cria 1.2.42, 1.3.0 ou 1.9.x para esta consolidação.
• Encerra a arquitetura temporal 1.x e estabelece EcoTermico 2.0.0 como nova base mínima oficial. A versão 2.0.0 não deve ser reutilizada para correções posteriores: hotfixes compatíveis avançam para 2.0.1, 2.0.2, ...; evoluções maiores seguem 2.1.0, 2.2.0, ...; nenhuma build nova deve voltar para 1.x.
• Mantém autoridade temporal exclusiva server-side: DayNightCycleManager continua como único writer interno da rate física e o servidor continua sem correções destrutivas de dayTime a cada tick. Snapshot e renderer nunca se tornam writers do servidor.
• Corrige definitivamente a divergência entre ticks independentes de servidor e cliente. A simulação cliente passa a reproduzir gameTime, dayTime, dayTimeFraction e dayTimePerTick com a mesma semântica de carry nativa usada pelo ClientLevel.
• Modela a sincronização periódica na cadência real do servidor, aproximadamente 1 snapshot a cada 20 server ticks, separando server temporal advancement, sync interval, network delivery e client advancement; sincronizações extraordinárias legítimas continuam suportadas por revision/epoch.
• Remove o snap visual causado pela antiga política abs(rawDebt) > 1200 → none. Dívidas grandes agora usam políticas explícitas NORMAL_CORRECTION, ACCELERATED_CORRECTION, REBASE e, somente para descontinuidade autorizada, AUTHORIZED_JUMP.
• Consolida a nova política adaptativa de reconciliação visual, considerando dívida, rate, tempo local e histórico recente, com convergência matemática sem overshoot, efeito mola, oscilação ou retorno visual.
• Confirma estabilidade com TPS reduzido 20/18/15/12/10/5, inclusive períodos prolongados a 15/10/5 TPS, sem acumular dívida ilimitada e sem usar TPS estimado para alterar o tempo físico.
• Confirma estabilidade durante stalls/freeze de servidor e cliente de 1/2/3/5/10 s, inclusive congelamentos em momentos diferentes, sem snap para trás na retomada.
• Mantém projeção de trânsito de rede em zero por não existir fonte segura de one-way latency. Latência, jitter, pacote atrasado, reorder, burst e perda lógica de update intermediário são absorvidos pela reconciliação/ordering, sem reintroduzir clientGameTime - serverGameTime como estimador.
• Consolida estabilidade dos ciclos acelerados de 1, 2, 5, 10 e 20 minutos nos modos TOTAL_CYCLE e SPLIT_DAY_NIGHT, incluindo mudanças rápidas de rate 20→1, 20→0.5, 10→1, 4→1, 2→20 e 1→20.
• Corrige descontinuidades legítimas via /time set, minecraft:time set e comandos aninhados execute ... run time set, garantindo nova epoch antes da sincronização quando a linha temporal é alterada para trás. /time add e sleep skip preservam continuidade monotônica quando aplicável.
• Adiciona interoperabilidade explícita para mods externos por TemporalDiscontinuityAPI, além de detecção defensiva de regressão absoluta significativa em Level#setDayTime; pequenas diferenças não são promovidas indevidamente a nova epoch.
• Unifica a apresentação temporal por ClientPresentationTimeSource, mantendo Sol, Lua, estrelas, sky angle, sky darkening, atmosfera visual, HUD e instrumentos coerentes durante reconciliação.
• Fecha a separação definitiva entre Physical Time e Visual/Presentation Time. TemperatureAPI, WildVitals, fenologia, ecologia, gameplay e demais consumidores autoritativos permanecem no relógio físico; presentation time é client-side e read-only.
• Preserva a API autoritativa e os contratos públicos usados por WildVitals, Sidereon e integrações futuras; adiciona a API pública de descontinuidade sem remover contratos da 1.2.41.
• doDaylightCycle=false passa a usar política explícita PAUSED_HOLD: a apresentação congela coerentemente, a dívida não fica presa nem cresce indefinidamente e a retomada converte a âncora em correção limitada/rebase sem backlog visual gigante.
• Amplia os testes de clocks independentes e institui gates definitivos para TPS baixo, freezes, ciclos acelerados, latência, jitter, reorder, burst, lifecycle, comandos e snapshots atrasados.
• Gate de promoção revalidado antes da mudança de versão: Stage 9 38/38, matriz independente 46/46 + 19/19 Java 21 e runner definitivo 17/17, todos com ERRORS=0.
• O invariante principal da 2.0.0 está coberto diretamente: em sincronizações normais não administrativas, rendered celestial time permanece visualmente contínuo e não regressivo, mesmo quando o clock físico do cliente é realinhado à autoridade server-side.
• Nenhuma feature da 1.2.41 foi removida. O runtime final preserva a baseline funcional e adiciona apenas os deltas temporais explicitamente auditados dos Estágios 4–8; o Estágio 9 é exclusivamente de testes/gates.
• Cria docs/BASELINE_SRC_MAIN_SHA256_2.0.0_FINAL.txt e baseline estrutural src/test/resources/baseline/2.0.0/ como identidade da nova linha mínima oficial.
• Mantém Minecraft 1.21.1, NeoForge 21.1.248, API pública V1, Capability Contract V1, protocolo interno 8 e schema persistente V1.
• Versionamento permanece manual: não são criados set-version, bump-version, promote-version ou equivalentes.
• Progresso: 10/10 — concluída e promovida.

Estágio 9/10 — Gates Definitivos de Não Regressão Temporal

• Adiciona TemporalRelease2DefinitiveGateStage9Test como gate comportamental final da candidata 2.0.0, modelando Server Tick Clock, Client Tick Clock e Network Delivery Clock como domínios independentes.
• A matriz obrigatória cobre ciclos 1/2/5/10/20 min, modos TOTAL_CYCLE e SPLIT_DAY_NIGHT, TPS 20/18/15/12/10/5 e atrasos 0/1/2/5/10/20 client ticks.
• Cobre as seis transições de velocidade exigidas: 20→1, 20→0.5, 10→1, 4→1, 2→20 e 1→20, preservando rate final, ordering e continuidade visual.
• Cobre server freeze e client freeze de 1/2/3/5/10 s, além de congelamentos deslocados em momentos diferentes e posterior recuperação estável.
• Rede adversarial inclui jitter 1→5→1→10→2, reorder determinístico, burst de snapshots legítimos e perda lógica de update intermediário; snapshot obsoleto nunca substitui o estado mais novo.
• Comandos cobertos: /time set, minecraft:time set, execute ... run time set, /time add e sleep skip. Backward /time set exige nova epoch; time add/sleep permanecem avanços monotônicos no mesmo domínio quando aplicável.
• Lifecycle cobre login, logout, respawn, mudança de dimensão e reload administrativo de rate. Hard boundaries resetam snapshot/epoch/revision/rate/correção/local clock; reload de configuração preserva ordering e compromete a nova rate atomicamente.
• A matriz mede diretamente presentationRegressions == 0 depois de client ticks e commits normais. Este é o gate executável do invariante principal da release: rendered celestial time contínuo e não regressivo em sincronização normal.
• Adiciona TemporalRelease2StaticInvariantStage9Test para bloquear regressões estruturais: ownership único da rate server-side, writes cliente apenas no commit atômico, renderer/presentation sem writers, ausência de clientGameTime - serverGameTime como latência e proibição do antigo descarte de dívida >1.200.
• build.gradle ganha o task explícito temporalReleaseGate; check depende dele e ele depende de test, fazendo os gates Stage 9 participarem da cadeia normal build -> check -> test. O task não altera versão nem promove release.
• Validação consolidada do estágio: 38/38 checks, matriz independente 46/46 + 19/19 Java 21 e runner definitivo 17/17 (13 gates novos + 4 regressões de pausa/retomada herdadas).
• O runtime de produção permanece exatamente o do Estágio 8: 572 arquivos, delta cumulativo autorizado de 22 arquivos contra a baseline 1.2.41 e 0 alterações novas em src/main neste estágio.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece até o Estágio 10 confirmar a promoção final.
• Progresso da checklist: 9/10.

Estágio 8/10 — Coerência Visual Completa: Céu, Sol, Lua, Estrelas e HUD

• Adiciona ClientPresentationTimeSource como fonte client-only única para tempo de apresentação. Ela deriva sempre do ClientLevel físico sincronizado + correção visual limitada; não avança relógio próprio e não é autoridade de gameplay.
• ClientCelestialVisualTimeSource passa a delegar à nova fonte comum. O override de LevelTimeAccess#getTimeOfDay(float) continua alimentando Sol, Lua, estrelas, sky angle, sky color, sky darkening e star brightness pela mesma fase final de frame.
• DigitalClockHudOverlay e a seção de relógio do UnifiedInstrumentHudOverlay deixam de ler ClientLevel#getDayTime() diretamente e passam a exibir o mesmo presentation time observado pelo céu durante reconciliações.
• SeasonalFoliageClientState, VegetationClimateResolver e ClientPrecipitationVisualResolver, todos explicitamente render/client-only, usam a mesma referência de apresentação para janelas visuais de noite e modificadores diurnos visuais. Isso evita céu em uma fase e foliage/precipitação visual em outra durante amortização.
• Sistemas físicos permanecem separados: TemperatureAPI, WildVitals, fenologia/ecologia server-side, caches térmicos, calendário autoritativo e gameplay continuam consumindo o relógio Minecraft físico/autoritativo; nenhum pacote common/server importa ClientPresentationTimeSource.
• Introduz PAUSED_HOLD para doDaylightCycle=false. Ao pausar, a dívida ativa é consolidada em uma âncora visual congelada: sourceDebtTicks=0, amortização=0 e apresentação permanece estável sem dívida crescendo ou sendo paga artificialmente.
• Enquanto pausado, snapshots normais podem atualizar o clock físico sem deslocar a apresentação congelada. AUTHORIZED_DISCONTINUITY continua sendo o único caminho para AUTHORIZED_JUMP e pode substituir explicitamente a âncora pausada.
• Ao reativar doDaylightCycle, a âncora congelada é convertida uma única vez em correção limitada normal/accelerated/rebase. Não existe backlog acumulado por tempo de pausa; discrepâncias de múltiplos dias continuam usando rebase por rotações completas de 24.000 ticks.
• A retomada preserva velocidade visual para frente, sem snap, overshoot, retorno ou efeito mola; a dívida volta a convergir pela política adaptativa do Estágio 5.
• Adiciona ClientPresentationPausePolicyStage8Test com 4 regressões Java 21 para consolidação de pausa, retomada sem snap, rebase de discrepância muito grande e salto autorizado explícito.
• O runtime passa a 572 arquivos: 568 da baseline 1.2.41 + três adições do Estágio 7 + ClientPresentationTimeSource. O delta cumulativo autorizado contra a baseline fica restrito a 22 arquivos, sem remoções.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece até os gates temporais finais.
• Progresso da checklist: 8/10.

Estágio 7/10 — Epoch, /time, Comandos Aninhados e Mods Externos

• Refatora TemporalIntegrityCommandClassifier para tokenização estrutural e resolução recursiva do comando executado após execute ... run, sem depender apenas do primeiro token bruto.
• Reconhece time set, minecraft:time set, execute run time set, execute as ... run time set e execute positioned ... run minecraft:time set como a mesma descontinuidade administrativa absoluta.
• Mantém CommandEvent como hook pré-execução: /time set autorizado recebe uma nova epoch antes de Vanilla/NeoForge alterar dayTime, inclusive quando o novo valor é menor por poucos ticks.
• Adiciona LevelDayTimeDiscontinuityMixin no HEAD de Level#setDayTime(long) apenas como observador server-side. O mixin não escreve clocks e permite detectar uma regressão absoluta externa antes do commit da escrita.
• Adiciona TemporalExternalDayTimeDiscontinuityPolicy: alterações externas para trás só são elevadas a descontinuidade quando excedem tolerância pequena proporcional à dayTimePerTick, evitando criar epoch por ruído/correção mínima.
• Autorizações explícitas mantêm um token curto e consumível por dimensão; quando o setter correspondente ocorre, esse token é consumido e impede uma segunda epoch para a mesma alteração.
• Uma regressão externa significativa sem autorização prévia recebe EXTERNAL_MOD_TIME_CHANGE, nova epoch e payload de epoch antes da escrita nativa. O diagnóstico recebe origem EXTERNAL_MOD em vez de mascarar a alteração como normal.
• Adiciona TemporalDiscontinuityAPI pública para integrações externas autorizarem ADMINISTRATIVE_TIME_CHANGE, TIMELINE_REBUILD, SERVER_RESET ou EXTERNAL_MOD_TIME_CHANGE imediatamente antes de alterar o relógio absoluto.
• A API pública e o sistema de epoch permanecem metadata-only: não chamam setDayTime, setGameTime nem setDayTimePerTick e não viram uma segunda autoridade temporal.
• EXTERNAL_MOD_TIME_CHANGE recebe wire id aditivo 5; o payload de epoch existente continua usando o mesmo formato/protocolo e apenas passa a compreender a nova razão.
• Segurança contra snapshots atrasados permanece inalterada: STALE_EPOCH, OUT_OF_ORDER, MONOTONICITY_VIOLATION, revision e fingerprint continuam decidindo ordering no cliente.
• Adiciona 11 regressões puras Java 21 para comandos aninhados/namespaced, tolerância de regressão externa, extremos long, reason wire e classificação diagnóstica de rewind externo.
• O runtime passa de 568 para 571 arquivos por três adições explícitas. O delta cumulativo contra a baseline 1.2.41 fica restrito a 15 arquivos; nenhum writer temporal físico é adicionado.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece até os gates temporais finais.
• Progresso da checklist: 7/10.

Estágio 6/10 — Projeção Segura, Jitter e Atraso de Rede

• Audita TemporalReconciliationContext, TemporalProjectionWindow e TemporalSnapshotAge e confirma que o runtime não possui fonte confiável de one-way network delay para o snapshot temporal.
• Remove o campo morto estimatedNetworkDelayTicks da infraestrutura temporal em vez de expor uma capacidade que produção sempre preenchia com zero.
• Mantém a regra absoluta de não usar clientGameTime - serverGameTime como latência; o shim legado packetAgeTicks(...) continua retornando zero.
• Um snapshot reconciliado imediatamente na chegada agora possui projection age = 0 por construção. Latência de trânsito, jitter e reorder não são convertidos em projeção temporal sintética.
• TemporalProjectionWindow passa a limitar exclusivamente tempo local monotônico realmente observado depois da chegada, como uma espera curta por metadata de rate. O padrão continua 4 client ticks e o teto absoluto continua 20.
• A diferença causada por rede atrasada é absorvida pela política visual adaptativa dos Estágios 4/5 depois que ordering/epoch/revision aceitam o snapshot; isso não altera tempo físico nem cria autoridade cliente.
• Adiciona TemporalNetworkJitterStage6Test com 8 regressões Java 21 cobrindo atrasos fixos 0/1/2/5/10/20, jitter 1 → 5 → 1 → 10 → 2, pacote atrasado, reorder, burst, perda lógica de update intermediário e proibição de AUTHORIZED_JUMP por rede comum.
• Reorder continua protegido por epoch/gameTime/revision/fingerprint: pacote antigo que chega depois de um mais novo é rejeitado e não sobrescreve a réplica.
• Burst de atualizações legítimas mantém a ordem de revisão e preserva continuidade visual; jitter não produz movimento de vai-e-volta.
• O delta cumulativo de runtime contra a baseline 1.2.41 passa a 6/568 arquivos: os dois arquivos visuais dos Estágios 4/5 mais ClientTemporalContinuityMath, TemporalProjectionWindow, TemporalReconciliationContext e TemporalSnapshotAge. Os outros 562/568 permanecem byte a byte congelados.
• Nenhum writer server-side, protocolo, epoch/revision, cadência de snapshot ou ownership de dayTimePerTick é alterado.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece até os gates temporais finais.
• Progresso da checklist: 6/10.

Estágio 5/10 — Correção Adaptativa para TPS Baixo sem Retorno Visual

• Substitui no runtime a amortização visual fixa como única decisão por uma política adaptativa baseada em faixa da dívida, rate comprometida, ticks locais transcorridos e histórico recente de reconciliação.
• Mantém o overload legado de ClientVisualTemporalCorrectionState.forCommit(...) somente para compatibilidade determinística dos gates anteriores; o ClientVisualTemporalCorrectionTracker usa o novo AdaptiveContext em produção.
• Introduz três faixas explícitas de apresentação: SMALL (até 240 ticks), MEDIUM (até 1.200) e LARGE (acima de 1.200, respeitando a política de rebase do Estágio 4).
• Mede observedDebtPressureTicksPerLocalTick somente pela dívida nova injetada entre duas reconciliações e pelo relógio local monotônico. Esse valor não é TPS estimado, não altera gameTime/dayTime/dayTimeFraction/dayTimePerTick e existe apenas na camada de apresentação.
• O tracker mantém EWMA com alpha=0.35 da pressão recente para evitar reação brusca a um único pacote e manter resposta suficiente quando a degradação persiste.
• Dívida positiva é quitada somente desacelerando a apresentação e preservando velocidade estritamente para frente. Os tetos por faixa são 80%, 88% e 92% da rate comprometida, permitindo acompanhar degradação prolongada sem inverter o céu.
• Dívida negativa usa catch-up limitado à própria rate e ao teto absoluto de 20 ticks/client tick; não há aceleração ilimitada.
• A demanda adaptativa combina piso suave da faixa, dívida/tempo-alvo, pressão observada atual e pressão recente suavizada; offsetAt(...) continua clampado a zero, impedindo overshoot, oscilação de sinal e efeito mola.
• AUTHORIZED_JUMP, REBASE e IRRECOVERABLE_STATE do Estágio 4 permanecem preservados; TPS baixo/stall continuam incapazes de criar salto autorizado.
• Adiciona ClientVisualTemporalAdaptiveCorrectionStage5Test com 10 regressões Java 21, incluindo períodos prolongados em 15/10/5 TPS, rate 20, rate 1, retorno a 20 TPS, convergência correctionDebt → 0, ausência de overshoot e preservação de movimento para frente.
• O delta cumulativo de runtime em relação à baseline 1.2.41 fica restrito a 2/568 arquivos: ClientVisualTemporalCorrectionState.java e ClientVisualTemporalCorrectionTracker.java; os demais 566/568 continuam byte a byte congelados.
• Nenhum writer físico, protocolo, epoch/revision, cadência server-side ou ownership de dayTimePerTick é alterado.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece até os gates temporais finais.
• Progresso da checklist: 5/10.

Estágio 4/10 — Reconstrução da Política de Correção Visual

• Remove a regra da 1.2.41 em que abs(rawDebt) > 1200 descartava a correção visual e podia expor o novo clock nativo como um snap para trás no mesmo frame.
• Mantém 1.200 ticks somente como orçamento de NORMAL_CORRECTION; discrepâncias acima disso passam a ACCELERATED_CORRECTION em vez de none.
• Introduz política explícita NORMAL_CORRECTION, ACCELERATED_CORRECTION, REBASE, AUTHORIZED_JUMP e IRRECOVERABLE_STATE dentro de ClientVisualTemporalCorrectionState.
• Garante que o caso crítico 14000 → 12799 (dívida 1.201) preserve a âncora visual 14.000 no commit e converja, sem salto instantâneo para trás.
• Correção grande usa convergência acelerada com teto absoluto de 20 ticks/client tick e limita pagamento de dívida positiva a 90% da taxa nativa, impedindo reversão de um céu que deveria avançar.
• Para discrepâncias de múltiplos dias, REBASE remove somente rotações completas de 24.000 ticks e limita o offset retido a [-12000,+12000], preservando a fase celeste visível.
• Entradas não finitas ou overflow da subtração são classificadas como IRRECOVERABLE_STATE; NaN/Infinity nunca são persistidos como dívida visual.
• AUTHORIZED_JUMP continua exclusivo de AUTHORIZED_DISCONTINUITY; no ordering atual apenas EPOCH_ADVANCE recebe essa resolução. TPS baixo, stall, DELAYED e SAME_TICK_NEWER_REVISION permanecem correções normais/acceleradas.
• Mantém /time set, alteração administrativa absoluta e reconstrução de timeline como caminhos server-side explícitos que autorizam nova epoch antes de qualquer salto intencional.
• Amplia ClientVisualTemporalCorrectionStateStage6Test para 19 regressões Java 21, cobrindo threshold 1.201, convergência de dívida grande, rebase por dias completos, overflow e stall/rate baixo.
• O único delta de runtime em relação à baseline final 1.2.41 fica confinado a ClientVisualTemporalCorrectionState.java; nenhum writer, protocolo ou componente de autoridade é alterado.
• Atualiza gates históricos para aceitar somente esse delta de runtime explicitamente aprovado, mantendo os outros 567/568 arquivos byte a byte congelados.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece até os gates temporais finais.
• Progresso da checklist: 4/10.

Estágio 3/10 — Cadência Real de Snapshots Temporais

• Corrige a simulação do Estágio 2 para que avanço temporal server-side e emissão de snapshot deixem de ser a mesma operação: SimServer.tick() pode avançar sem produzir pacote.
• Introduz cadência periódica explícita de 1 snapshot a cada 20 server ticks, sem gerar snapshot a cada server tick e sem usar tick do cliente como relógio da sincronização.
• Mantém ServerTickClock, ClientTickClock e NetworkDeliveryClock independentes; a cadência periódica é contada somente por ticks realmente executados pelo servidor.
• Valida a frequência esperada em tempo de rede/parede: 20 TPS → ~1 s, 10 TPS → ~2 s, 5 TPS → ~4 s entre snapshots periódicos.
• Modela sincronizações extraordinárias para mudança de dayTimePerTick, alteração administrativa monotônica e avanço de epoch, sem reiniciar a cadência periódica.
• Permite que sync periódica e extraordinária ocorram legitimamente no mesmo server tick; cada emissão recebe revision própria e a segunda é classificada como SAME_TICK_NEWER_REVISION, não como duplicata.
• Reseta a sequência de revision ao avançar a epoch, preservando ordering dentro do novo domínio temporal.
• Remove do teste a falsa garantia de convergência baseada em snapshot sintético no fim da simulação: o cliente pode terminar entre sincronizações com atraso autoritativo inferior a 20 server ticks.
• Mantém todo src/main byte a byte igual à baseline final 1.2.41; este estágio altera somente simulação, gates e documentação.
• A suíte temporal acumulada passa a executar 19 regressões Java 21 sem Gradle.
• Adiciona validate-2-0-0-temporal-stability-stage3-v1.py, herdando integralmente os gates dos Estágios 1 e 2.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 permanece como identidade da baseline congelada até o gate final.
• Progresso da checklist: 3/10.

Estágio 2/10 — Simulação Temporal Realista de Cliente e Servidor

• Refatora TemporalIndependentClockRegressionStage9Test para que o cliente simulado não avance apenas clientNativeGameTime: cada client tick agora avança gameTime e, quando doDaylightCycle está ativo, dayTime/dayTimeFraction pela mesma NativeDayTimeAdvanceMath usada para reproduzir o carry float nativo.
• Passa a manter/aplicar dayTimePerTick commitado durante o avanço entre snapshots e cobre explicitamente doDaylightCycle=false, onde gameTime continua avançando sem mover o relógio solar.
• Corrige outra diferença da simulação antiga: snapshot aceito agora reproduz o commit atômico real e realinha clientNativeGameTime, dayTime, dayTimeFraction e dayTimePerTick antes de a predição nativa continuar.
• Introduz ServerTickClock, ClientTickClock e NetworkDeliveryClock como três domínios explícitos e independentes; entrega de rede não depende de tick do servidor nem do cliente.
• Amplia a matriz de TPS server-side para 20/18/15/12/10/5 TPS, mantendo cliente a 20 TPS e provando por contadores separados que a simulação não pressupõe 1 client tick = 1 server tick.
• Preserva e reforça server freeze, client freeze e congelamentos em janelas diferentes, enquanto o relógio de entrega de rede continua avançando.
• Mantém latência, rate changes, SPLIT_DAY_NIGHT, ordering, epoch/revision, lifecycle e ciclos de 1/2/5/10 minutos sob o modelo corrigido.
• Atualiza o gate histórico independente para 46 checks e 15 regressões Java 21, todas executadas sem Gradle.
• Adiciona validate-2-0-0-temporal-stability-stage2-v1.py, que herda o congelamento do Estágio 1 e exige a nova simulação realista sem alterar src/main.
• Não promove 2.0.0 neste estágio; mod_version=1.2.41 continua sendo somente a baseline de desenvolvimento congelada.
• Progresso da checklist: 2/10.

Estágio 1/10 — Congelamento da Base Temporal 1.2.41 e Invariantes da 2.0.0

• Congela EcoTermico 1.2.41 como baseline obrigatória da linha de estabilização 2.0.0, com src/main verificado byte a byte contra docs/BASELINE_SRC_MAIN_SHA256_1.2.41_FINAL.txt (568/568 arquivos idênticos).
• Formaliza por gate automatizado: servidor como autoridade temporal absoluta; cliente como réplica com previsão temporária; renderer apenas como apresentação; predição cliente incapaz de bloquear autoridade do servidor; snapshot antigo incapaz de substituir snapshot novo; correção visual incapaz de virar segunda autoridade.
• Preserva integralmente revision, epoch, fingerprint, commit atômico, separação física/visual, ClientVisualTemporalCorrectionTracker, NativeDayTimeAdvanceMath, proteção de dayTimePerTick e lifecycle/reset client-side da 1.2.41.
• Mantém DayNightCycleManager como único writer server-side de dayTimePerTick, protegido por DayNightRateWriteGuard e pelo mixin de ownership.
• Mantém o cliente sem clientGameTime - serverGameTime como estimador de latência e sem arrivalDayTime como autoridade temporal.
• Mantém ordering por epoch/gameTime/revision/fingerprint e política de pending em que snapshot obsoleto/duplicado é rejeitado e snapshot comprovadamente mais novo pode superseder o anterior.
• Mantém correção visual somente após o commit dos clocks/taxa e sem setters de clocks no ClientVisualTemporalCorrectionTracker.
• Preserva TOTAL_CYCLE e SPLIT_DAY_NIGHT; VANILLA continua somente como token legado migrado/normalizado e não pode voltar silenciosamente como controlador operacional.
• Adiciona TemporalStability200Stage1ContractTest com 8 contratos code-only e validate-2-0-0-temporal-stability-stage1-v1.py, sem Gradle e sem testes manuais.
• Não promove 2.0.0 neste estágio: mod_version=1.2.41 permanece apenas como marcador da base congelada de desenvolvimento. A promoção manual para 2.0.0 continua bloqueada até os gates temporais finais.
• Não cria set-version, bump-version ou qualquer script de promoção automática.
• Progresso da checklist: 1/10.