Pular para o conteúdo principal

Backlog oficial (v0.4.0 → v1.0.0)

Este documento define o backlog oficial, completo e normativo do Weave Network, partindo do baseline v0.4.0 até o lançamento da v1.0.0.

Ele é derivado diretamente da documentação técnica oficial e substitui qualquer backlog anterior.

Nada aqui é sugestão.
Tudo aqui é compromisso de escopo.

Baseline travado v0.4.0 Commited​

Garantias inegociáveis a partir deste ponto:

  • Bind exclusivamente via Fiber física
  • Nenhuma transferência sem rede íntegra
  • Scheduler executa apenas em runtime
  • Estados operacionais definidos e respeitados
  • Multipart físico funcional
  • Nenhuma heurística espacial
  • Debug confiável e determinístico

Esse baseline não é rediscutido ao longo do roadmap.

v0.4.1 — Hardening absoluto do runtime Commited​

Objetivo: blindar completamente o lifecycle antes de escalar features.

Escopo:

  • Garantir que o scheduler nunca execute fora do estado ONLINE
  • Bloquear execução durante:
    • RECONFIGURING
    • BROWNOUT
    • COLLAPSE
  • Forçar lastTickTransfers = 0 sempre que a rede estiver bloqueada
  • Dumps passam a expor estado atual + motivo
  • Revisão completa de cenários críticos:
    • quebra e recolocação rápida de Fiber
    • chunk unload e load
    • world reload

v0.5.0 — Scheduler definitivo Commited​

Objetivo: transformar o scheduler em uma plataforma extensível.

Escopo:

  • WeaveScheduler como orquestrador único
  • Sub-schedulers por payload:
    • Item (completo)
    • Energy (estrutura)
    • Fluid (estrutura)
    • Redstone (estrutura)
  • Budget explícito por canal e por payload
  • capacityActiveRatio influencia o throughput real
  • Round-robin determinístico e previsível

v0.6.0 — Estados operacionais reais In progress​

Objetivo: tratar a rede como um sistema vivo.

Estados suportados:

  • OFFLINE
  • BOOTING
  • ONLINE
  • RECONFIGURING
  • BROWNOUT
  • COLLAPSE
  • REBOOT

Regras:

  • Estados são sempre derivados, nunca configuráveis
  • BROWNOUT ocorre quando a energia sustenta apenas contenção
  • COLLAPSE ocorre quando o buffer total chega a zero
  • REBOOT possui delay fixo
  • Retomada para ONLINE apenas com buffer do Controller ≥ 50%

v0.7.0 — Payload completo: Energia (FE)​

Objetivo: energia como mecanismo de contenção da Trama.

Escopo:

  • Buffer energético distribuído em:
    • Controller
    • Fiber
    • Port
  • Consumo de standby por tier
  • Custo lógico por Porta ativa
  • Falta de energia degrada capacidade ativa
  • Energia não paga transporte

v0.8.1 — Payload completo: Fluidos​

Objetivo: transporte abstrato previsível para fluidos.

Escopo:

  • Nenhum tank interno
  • Throughput determinístico
  • Respeito total às regras por Porta
  • Feedback visual básico na Fiber

v0.8.2 — Payload completo: Redstone lógico​

Objetivo: controle declarativo e previsível.

Escopo:

  • Redstone binário disponível a partir do T2
  • Redstone analógico disponível a partir do T3
  • Pode atuar como payload e como condição
  • Estados congelam durante BROWNOUT

v0.9.0 — Topologia avançada v1​

Objetivo: introduzir profundidade estratégica.

Condenser​

  • Aplicável apenas sobre Fiber
  • Sempre opcional
  • Benefícios possíveis:
    • aumento de buffer energético
    • redução de custo de contenção
    • redução de tempo de reconfiguração
    • amortização de strain

v0.10.0 — Topologia avançada v2​

Anchor​

  • Ponte intradimensional
  • Não cria novo grafo
  • Requer T4 + Singularidade Link
  • Consumo energético contínuo

Gate​

  • Ponte interdimensional
  • Conecta Controllers distintos
  • Estados operacionais independentes
  • Custo energético elevado

v0.11.0 — Ferramentas e Port Rules v1​

Ferramentas​

  • Debug Wrench

    • Creative-only
    • Presente, mas desabilitada por datapack na v1.0.0

  • Tuning Key

    • Inspect
    • Configurator
    • Link (Anchor e Gate)
    • Enable e Disable de blocos

Port Rules v1​

  • Direção
  • Allowlist de payload
  • Filtros simples
  • Limites por tick
  • Prioridade simples

v0.12.0 — Sistema de progressão​

Objetivo: progressão completa e jogável.

Escopo:

  • Quartz Dust a partir de Nether Quartz em Deepslate
  • Weave Dust, Filament e Matrix
  • Loom:
    • receitas via datapack
    • energia e tempo configuráveis
    • UI clara e funcional
  • Weave Stabilizer como fonte energética inicial

v0.13.0 — Port Rules v2​

Escopo:

  • Regras condicionais baseadas em:
    • estado do destino
    • estado da rede
    • redstone lógico
  • Regras compostas:
    • AND e OR
    • comparadores
    • thresholds
  • Custo lógico proporcional à complexidade

v0.14.0 — Models finais v1​

Escopo:

  • Models próprios para:
    • Fiber
    • Port
    • Controller
    • Condenser
    • Anchor
    • Gate
  • Comunicação visual básica de estado

v0.15.0 — Models finais v2​

Escopo:

  • Variações visuais por estado:
    • ONLINE
    • BROWNOUT
    • COLLAPSE
  • Animações funcionais:
    • fluxo
    • pulsação
    • apagamento

v0.16.0 — UI avançada e analytics v1​

Controller UI:

  • Estado operacional e motivo
  • Energia e buffers
  • Canais:
    • total
    • livres
    • modo
  • Analytics dos últimos 10 segundos

v0.17.0 — UI avançada e analytics v2​

Port UI:

  • Editor declarativo de regras
  • Última decisão e motivo
  • Inspect via Tuning Key
  • Bloqueios visíveis no mundo

v0.18.0 — Progressão e balanceamento​

Escopo:

  • Tiers completos (T0 → T4 + Singularidades)
  • capacityActiveRatio conforme fórmula oficial
  • Balanceamento totalmente via datapack
  • Testes de progressão em gameplay real

v0.19.0 — Polimento​

Escopo:

  • Performance em redes grandes
  • Cache de contexto de regras
  • Limites duros por tick
  • Tooltips e guias
  • Integração completa com JEI

v1.0.0 — Launch​

Checklist:

  • Core sólido e imutável
  • Progressão completa via Loom
  • Port Rules avançadas
  • UI final com analytics
  • Assets e animações finais
  • Debug Wrench desabilitada por datapack
  • Documentação pública alinhada e final

Fora do escopo da v1.0.0​

  • Addons
  • Integrações com outros mods
  • Auto-routing
  • Storage interno

Diretrizes de desenvolvimento​

Debug não é gameplay​

Ferramentas de debug existem exclusivamente para desenvolvimento e validação.

Regras:

  • Debug Wrench é Creative-only
  • Pode ser desabilitada por datapack
  • Nenhuma mecânica essencial depende de debug

Isso garante separação clara entre:

  • sistema de jogo
  • ferramentas de desenvolvimento