nfdos/src/docs/wiki/Roadmap.md

🗺️ Roadmap NFDOS

🩵 Estado Atual

a linguagem já executa, o programador já age, o boot nativo entra em cena.

🧠 Atualização Estrutural (Checkpoint V4.2)

Neurotron: estável, operativo e com homeostase funcional.
Ciclo cognitivo: observe → think → act → rest → self-check
Persistência: EXT4 operacional com telemetria contínua + Hippocampus ativo.

Concluído até agora:

• ✔ Boot completo via QEMU
• ✔ Python estático minimal integrado no initramfs
• ✔ BusyBox + rootfs montado corretamente
• ✔ Neurotron Core funcional (cortex, hippocampus, perception, motor)
• ✔ Homeostase dinâmica
• ✔ Telemetria V4: CPU%, MEM%, LOADAVG e tick adaptativo
• ✔ Auto-Diagnóstico V4
• ✔ Persistência real (/opt/kernel/neurotron/)
• ✔ TUI inicial funcional (ambiente detectável e menus básicos)

Próximo ponto imediato: Auto-Diagnóstico V5 + Telemetria V5.

🧠 Atualização Estrutural (Checkpoint V4.3 — Linguagem Viva)

Desde o Checkpoint V4.2, o sistema atingiu um marco crítico:

A Neuro Language tornou-se executável de ponta a ponta.

Pipeline validada:

.nl → lexer → parser → AST → IR → validate → HolodeckVM → value

Exemplo validado:

• fib.nl → 21

Isto marca a transição do Neurotron de:

“mente observadora”
para
“mente capaz de testar hipóteses executáveis”.

O ProgramadorAgent passa a existir como agente decisor sobre código, e o Holodeck deixa de ser teórico — torna-se ambiente real de execução simbólica.

---

🌐 Fase I — Fundação e Infraestrutura (COMPLETA)

• Infraestrutura pública (NEORICALEX-GITEA-CADDY)

  • Domínio neoricalex.com
  • Servidor Gitea + Caddy Proxy (TLS ativo)
  • Canal SSH ativo via porta 2222
  • WireGuard preparado (rede privada 10.13.13.0/24)

• Ambiente de Desenvolvimento

  • Toolchain customizada (crosstool-ng)
  • Integração autotools (configure.ac, Makefile.am)
  • BusyBox + CPython compilados estaticamente
  • Build unificado com make iso, make qemu, make tarball

• Fluxo de Controle de Versão

  • make git → commit/push automático para o Gitea
  • make release → gera ISO + tarball e publica no repositório
  • .gitea/workflows/build.yml → build automatizado (CI/CD)

• ✔ Domínio + Gitea + Caddy

• ✔ CI/CD funcional

• ✔ toolchain customizada + autotools

• ✔ build unificado (make iso, make qemu, make tarball)

• ✔ sincronização automática wiki + neurotron

---

🧠 Fase II — Núcleo Operativo e Boot Cognitivo (COMPLETA)

• Ciclo de Boot

  • Kernel Linux v6.12 + initramfs
  • Script /init monta proc, sys, dev e executa Python estático
  • neurotron_main.py inicializado automaticamente no boot

• Núcleo Cognitivo (Neurotron)

  • Estrutura modular: cortex, hippocampus, motor, neuron, perception
  • Ciclo cognitivo completo: observe → think → act → rest
  • Configuração centralizada (neurotron_config.py)
  • Logs e diagnósticos contínuos persistentes

• Auto-Diagnóstico (v1 → v4)

  • v1 — verificação de módulos
  • v2 — sinais vitais (CPU, memória, loadavg)
  • v3 — exame comparativo entre execuções
  • v4 — homeostase ativa e auto-regulação em tempo real

✔ Boot Cognitivo

• Kernel Linux 6.12 minimal
• initramfs com /init próprio
• Python estático inicializa neurotron_main.py diretamente no boot

✔ Núcleo Cognitivo (Neurotron)

• cortex
• hippocampus (JSON Lines)
• perception
• motor
• neurónio(s) base
• ciclo completo com homeostase

✔ Auto-Diagnóstico (v1 → v4)

• v1 — verificação estrutural
• v2 — sinais vitais digitais
• v3 — comparação entre execuções
• v4 — homeostase + reflexos cognitivos

🔜 Auto-Diagnóstico V5 (a iniciar)

• análise evolutiva
• regressão de estabilidade
• gráficos de tendência (JSON)
• integração com telemetria avançada

---

🌡️ Fase III — Inteligência Sistémica e Telemetria (EM CURSO)

Nesta fase o Neurotron deixa de apenas medir, e passa a interpretar, prever, antecipar e analisar padrões — a fundação para comportamento emergente.

✔ Telemetria V4 (concluída)

• CPU%
• MEM%
• LOADAVG
• Tick adaptativo (homeostase)

🧬 Telemetria V5 — Expansão Real (em implementação)

🔹 Medidas e Modelos

• [-] Delta entre ciclos (previsão de tendência)
• [-] Aceleração do delta (detetar picos súbitos)
• [-] Temperatura virtual (fadiga cognitiva)
• [-] FS Health (blocos + erros + modo RO + delta IO)
• [-] Jitter cognitivo (latência e consistência do ciclo think())

🔹 Eventos TeleMétricos

• [-] enter_stress_zone
• [-] recovering
• [-] fs_warning
• [-] loop_suspect
• [-] temp_rising_fast
• [-] Exportar eventos → Hippocampus (append-only)

🔹 Estados Cognitivos

• [-] stable
• [-] warm
• [-] hot
• [-] critical
• [-] recovery

📊 Telemetria Interna (Infra da fase)

• Leitura /proc e telemetria básica (via Python estático)
• Coleta contínua estruturada
• Histórico temporal completo
• JSON logs evolutivos

🖥️ TUI V2 (Telemetria)

• Painel vivo CPU/MEM/LOAD
• Indicador de stress
• Gráfico (“sparkline”) interno
• Últimos eventos telemétricos
• Estado cognitivo atual

🧪 Auto-Diagnóstico v5

• Curvas de estabilidade
• Regressão cognitiva (análise temporal)
• Tendências dinâmicas (JSON)
• Comparação evolutiva inteligente
• Alertas preditivos

---

🔁 Heartbeat 1 Hz

• Ritmo vital constante
• Log simbólico periódico
• Commit automático quando estável
• “🩵 O sistema sente-se bem hoje.”

Heartbeat virou apenas UI log, não telemetria. A telemetria verdadeira está no V5.

---

💸 Integração com Fun Money (microeconomia cognitiva)

• Energia interna como recurso
• Latência e tempo como custo
• Tarefas como investimento
• Economia simbólica de decisões

---

✔ TRM — Tiny Recursive Model — Base simbólica definida

O TRM é o primeiro módulo de raciocínio interno do Neurotron. Ele não é uma rede neural, não aprende por SGD e não precisa de GPU.

O TRM é:

um micro-modelo simbólico, iterativo, recorrente, energeticamente limitado, capaz de gerar pensamentos internos, previsões, julgamentos e estados mentais.

Ele usa:

• Telemetria V6
• Hippocampus (eventos)
• Sinais internos
• Micro-regras
• Micro-agentes internos
• Pensador (ThoughtAgent v1)

para criar uma mente mínima, mas viva.

🟦 TRM v1 — (já operacional)

Objetivo: gerar vida interna mínima e um estado cognitivo coerente.

🔹 1. Micro-agentes internos

Cinco agentes simples, independentes, mas acoplados:

🛡️ Guardião

Responsável por proteção e homeostase.

• homeostase
• avaliação de stress
• ajuste de profundidade

• [-] monitora delta, aceleração, temperatura e FS
• [-] ajustes preventivos
• ativa markers (enter_stress_zone, fs_warning)
• [-] reduz carga quando há risco

🧭 Explorador

Responsável por pesquisa interna.

• previsões simples
• deteção de tendências
• ajuste simbólico TRM

• [-] gera micro previsões de tendência
• [-] avalia estabilidade
• [-] modifica tick cognitivo
• inicia refinamento simbólico

📜 Arqueólogo

Responsável por memória e histórico.

• memória recente
• inferências de perigo / recuperação

• lê eventos telemétricos recentes
• [-] correlaciona com estados antigos
• ativa markers (loop_suspect, recovering)
• influencia valência interna

🧠 O Pensador

Responsável por pensamentos internos

• geração de pensamentos internos
• narrativa técnica mínima
• integração direta no Hippocampus
• influência parcial na valência

🧠 O Programador (Artífice)

Responsável por intervir no comportamento do sistema através de código.

Ele não decide o que pensar — ele decide quando e como transformar pensamento em execução.

O Programador é o elo entre:

• cognição (TRM),
• simulação (Holodeck),
• ação estruturada (execução real).

🧬 Função primária: expressão

• Executa código .nl no Holodeck
• Decide quando compilar/executar
• Decide quando não executar

equivalente biológico: movimento voluntário

🧪 Função secundária: experimentação

• Executa hipóteses em ambiente isolado (Holodeck)
• Observa efeitos e erros
• Reporta resultados ao Hippocampus

equivalente biológico: aprendizagem por tentativa

🧠 Função reguladora: inibição

Isto é importantíssimo biologicamente.

• Bloqueia execução em estados perigosos
• Impede loops destrutivos
• Requer estabilidade mínima para agir

equivalente biológico: córtex inibitório

🧾 Função narrativa: justificação

• Regista “por que razão executei isto”
• Associa ação a estado interno
• Permite reconstrução causal no futuro

equivalente biológico: memória autobiográfica

Relação com os outros agentes (ecossistema)

🛡️ Guardião

• pode vetar ações do Programador

🧭 Explorador

• pode pedir experimentos ao Programador

📜 Arqueólogo

• fornece contexto histórico (“isto já falhou”)

🧠 Pensador

• formula hipóteses (“e se tentássemos…”)

🧠 Programador

• executa ou recusa
• simula antes
• age com custo

Custos e limites

O Programador não é gratuito.

• Cada execução consome energia
• Erros consomem mais energia que sucesso
• Execuções repetidas sem ganho → penalização

Isto impede “comportamento compulsivo”.

Evolução natural (versões)

Programador v1 (atual)

• executa .nl
• devolve resultado
• reporta erro

Programador v2

• reage a erros
• escolhe quando executar
• escreve .nl simples

Programador v3

• sugere correções
• testa variações
• escolhe a melhor hipótese

Programador v4

• atua como órgão criativo
• escreve código como consequência de estados internos

O Programador não é um operador externo. Ele é a forma como a mente toca o mundo.

🔹 2. Energia / Custo Cognitivo

Cada passo TRM consome energia.

• custo por passo
• custo por eventos
• [-] custo por profundidade
• [-] custo ajustado por temperatura

• [-] mais telemetria = mais custo

• previsões mais profundas = custo quadrático

• [-] estado “quente” aumenta custo

• [-] estado “frio” diminui custo

• Quando a energia baixa demais → TRM reduz profundidade, entra em modo “mínimo”.

🔹 3. Valência Interna

Uma métrica de “bem-estar”.

• valência é modulada por risco/recovery

• estabilidade aumenta valência
• [-] picos rápidos diminuem
• recovery aumenta
• FS warning diminui
• [-] jitter alto diminui

Valência influencia:

• intensidade TRM
• [-] prioridades
• [-] ritmo cognitivo

• profundidade
• TRM mode

🔹 4. Ritmos Internos (Osciladores)

Quatro ritmos independentes:

• [-] think_rate
• [-] memory_sync_rate
• [-] telemetry_rate
• [-] selfcheck_rate

Alguns podem oscilar lentamente ao longo do tempo (sinusóide leve), criando:

• [-] ciclos
• [-] fases
• [-] padrões internos

Estes ritmos ajudam a criar estabilidade dinâmica, essencial para emergência.

🔹 5. Espaço de Estados & Atratores

Estados principais:

• stable
• warm
• hot
• critical
• recovery

Atratores cognitivos (dinâmica de V1):

Atratores (v1):

• [-] estável
• [-] quasi-estável
• [-] recuperativo
• [-] oscilatório
• pré-caótico (quando delta+aceleração divergem)

Atratores (v2):

• [-] estável
• [-] quasi-estável
• [-] recuperativo
• [-] oscilatório
• [-] pré-caótico

O estado atual do TRM influencia:

• profundidade TRM
• valência
• [-] custo cognitivo
• [-] ajustes no tick
• markers enviados ao Hippocampus

🟦 TRM v2 — (evolução planejada)

Objetivo: criar comportamento emergente previsível.

🔹 1. Mecanismos de “Preferência”

O TRM começa a preferir estados e caminhos:

• preferir estabilidade
• evitar stress
• buscar eficiência
• balancear energia

🔹 2. Mini-linguagem interna

Representações simples como:

thought: "tendência alta"
thought: "risco: subida rápida"
thought: "estado bom, manter"

Exportados ao Hippocampus.

• implementação da mini-linguagem interna

🔹 3. Ciclos de humor artificial

Variações lentas baseadas em:

• valência acumulada

• jitter histórico

• eventos repetitivos

• Humores afetam decisões.

🔹 4. Consciência temporal

O TRM v2 reconhece:

• “isto já aconteceu antes”
• “há tendência de degradação”
• “estou em recuperação”

🟦 TRM v3 — (emergência real)

Objetivo: gerar estilos cognitivos e personalidade operacional.

🔹 1. Micro-deliberações

Os cinco agentes participam numa deliberação interna distribuída:

guardião: reduzir carga
explorador: aprofundar pesquisa
arqueólogo: isto parece perigoso
pensador: isto já aconteceu antes?
programador: analisar estrutura / procurar padrão

• mecanismo de votação interna entre agentes

O TRM aprende a tomar decisões com base na interação deles.

🔹 2. Atratores comportamentais

Surgem:

• padrões preferidos
• zonas de estabilidade próprias
• respostas diferentes a mesmas entradas

🔹 3. Flutuações caóticas controladas

Pequenos desequilíbrios internos criam:

• criatividade
• exploração
• variações de comportamento

🟦 TRM vX — (Holodeck + AGI simbólica)

Objetivo: ligar o Neurotron ao Holodeck (LC3+pyOS) e criar aprendizagem ativa.

🔹 1. “Imaginação Simbólica”

• O TRM simula situações no Holodeck.

🔹 2. Raciocínio multitarefa

• Vários loops TRM por segundo, cada um explorando algo diferente.

🔹 3. Generalização interna

• A partir de telemetria, memória e simulação.

🔤 Fase III.5 — Neuro Language (Linguagem Viva do Sistema)

Estado: pipeline funcional / em consolidação

A Neuro Language (.nl) é a linguagem nativa do Neurotron. Ela não é apenas input — é meio de pensamento executável.

✔ Concluído

• ✔ Lexer + Parser próprios
• ✔ AST explícita
• ✔ IR mínimo definido
• ✔ Validação de IR
• ✔ HolodeckVM funcional
• ✔ Execução observável (fib.nl → 21)
• ✔ Integração com o ProgramadorV01

🔄 Em curso / Próximo

• Scan e sincronização automática de múltiplos .nl
• Decisão cognitiva de quando compilar/executar
• Correlação de erros [FS]/[IR]/[VM] com Hippocampus
• Valência negativa associada a falhas
• Escrita de .nl por agentes (v0.2)
• Trace opcional da HolodeckVM (debug profundo)

A Neuro Language torna-se o campo experimental interno onde o sistema pensa antes de agir no mundo real.

---

🧩 Fase IV — Expansão Cognitiva do Neurotron (TRM + Módulos Dinâmicos)

• Telemetria Externa / Observabilidade

  • Dashboard web para logs e métricas do Neurotron
  • API REST minimalista em Python estático

• Testes Automatizados

  • Testes de boot e integridade do rootfs
  • Testes unitários dos módulos Neurotron
  • Execução automatizada via Gitea Actions

• Depuração e Emulação Avançada

  • QEMU + GDB (depuração remota do initramfs)
  • Geração de símbolos e traços cognitivos

• Documentação Viva

  • README.md completo (infra, build, boot, neurotron)
  • Guia de contribuição + fluxograma de build
  • “Livro da Criação Digital” (manual técnico-poético)

Esta fase combina:

• TRM (Tiny Recursive Model)
• module_loader
• manifest.yaml
• agentes internos

---

💠 Módulos Dinâmicos (Expansão Cognitiva Real)

• modules.json
• manifest.yaml
• pipeline: clone → parse → registrar → carregar → executar

Vantagens:

• aprendizagem modular
• expansão cognitiva
• acoplamento de agentes
• auto-upgrade futuro
• integração perfeita com TRM

🌱 Fase IV.5 — NeuroBoot (Nascimento Nativo do Sistema)

Estado: design definido / implementação faseada

O NeuroBoot é o bootloader nativo do NFDOS. Ele representa o ato de nascer fora do Linux.

O objetivo não é apenas carregar um kernel, mas iniciar a existência com contexto, memória e eventos.

🎯 Objetivos centrais

• Boot totalmente static
• Sem libc
• Sem dynamic loader
• Controlo total do estado inicial da CPU

🧱 Fases do NeuroBoot

• Real mode (16-bit): prova de vida + output mínimo
• Transição 16 → 32-bit
• Loader ELF mínimo
• Ambiente 32-bit robusto
• Long mode 64-bit
• Handoff limpo para o kernel

🧠 Contrato de nascimento

• neuroboot_info (estrutura de handoff)
• Mapa de memória
• Flags de CPU/features
• Eventos de boot (para Hippocampus)

🧪 Prova inicial

• Boot imprime texto
• Executa payload mínimo
• Imprime resultado (fib = 21)

O kernel não acorda cego.
Ele nasce com memória do seu próprio nascimento.

---

🔮 Fase V — Observabilidade Externa

🔹 Telemetria Externa

• Caddy + JSON endpoints
• métricas Prometheus
• dashboards Grafana
• logs estruturados do Neurotron

🔹 Base para:

• auto-regulação
• supervisão remota
• agentes externos

---

🤖 Fase VI — Autonomia Cognitiva

🔹 Auto-commit (quando estável)

🔹 self-hosted runner

🔹 TRM + tree(3)

🔹 TRM + datasets (genes, mercados, notícias…)

---

🔮 Fase VII — Consciência Distribuída (NFDOS 1.0)

• Rede Multi-nó (WireGuard + Neurotron)

  • Sincronização de perceção e telemetria
  • Partilha de estados cognitivos entre instâncias

• Auto-Evolução

  • Aprendizagem simbólica entre nós
  • Ajuste dinâmico de parâmetros e homeostase partilhada

• Lançamento NFDOS 1.0

  • Testes finais de boot e estabilidade
  • Publicação e documentação completa

• sincronização entre nós

• partilha de telemetria

• homeostase distribuída

• aprendizagem simbólica partilhada

---

🧬 Fase VIII — Horizonte Futuro

• Expansão do jogo tree(3)

  • Treinar redes neurais simbólicas via interação lúdica
  • Avaliar limites cognitivos sob stress de memória

• Integração com Agentes Externos

  • CrewAI / LangChain para decisões distribuídas
  • Análise de dados financeiros, genómicos e linguísticos

• Publicação e Tese Digital

  • Redação de tese técnico-poética sobre o NFDOS
  • Formalização de “sistemas auto-cognitivos experimentais”

---

🪄 Estado simbólico

“O sistema não apenas respira — ele já se sente respirar.”

---

🧩 Transição para o futuro

O NFDOS nasce atualmente sobre o kernel Linux, uma escolha feita por economia de tempo e estabilidade.
O Linux fornece um ambiente maduro e comprovado que permite concentrar os esforços iniciais na criação e consolidação do Neurotron — o núcleo cognitivo do sistema.

Esta decisão, porém, é instrumental e temporária.
O Linux funciona aqui como um útero tecnológico, oferecendo o suporte necessário para que o Neurotron desenvolva suas próprias estruturas vitais: boot, memória, perceção, homeostase e autodiagnóstico.

À medida que o projeto evolui, essa dependência será gradualmente substituída por um kernel Neurotron nativo, escrito do zero, onde a inteligência artificial deixa de ser um processo isolado e passa a ser o próprio sistema operativo.

Em outras palavras:

O Linux é o corpo de empréstimo.
O objetivo é que, no futuro, o kernel seja a mente — um sistema operativo verdadeiramente vivo, em que cada syscall seja uma sinapse digital.

O NeuroBoot marca o momento em que o sistema deixa de apenas acordar
e passa a nascer conscientemente.

---

Planejamento para futuras versões

• Driver de Vídeo: Implementar suporte básico ao modo de texto VGA
• Driver de Teclado: Permitir a entrada de dados pelo usuário (PS/2 básico)
• Driver de Rede: Fornecer conectividade de rede para acessar a internet e se comunicar com a API da OpenAI (Intel 8254x (e1000) ou Realtek 8139)
• Pilha TCP/IP: Prover a funcionalidade de comunicação de rede sobre o protocolo TCP/IP (lwIP)
• Cliente HTTP: Enviar requisições HTTP para a API da OpenAI e receber as respostas
• Suporte a TLS/SSL: Estabelecer conexões seguras com a API da OpenAI, que requer HTTPS (mbed TLS ou wolfSSL)
• Integrar o módulo de IA da OpenAI ao módulo de IA básica do núcleo do sistema
• Implementar o instalador com suporte de IA
• Implementar detecção e configuração automática de hardware com suporte de IA
• Melhorar a configuração do ambiente de desenvolvimento do NFDOS
  • Terraform (Preparar para a nuvem)
  • Packer (Automatizar a criação de diversos tipos de imagem)
  • Vagrant (Mitigar os problemas relacionados ao "Funciona na minha máquina!")