PRAXIUM — Arquivo de Suporte e Recuperação de Contexto

 PRAXIUM — Arquivo de Suporte e Recuperação de Contexto

PRAXIUM — Documento Funcional de Referência

Mapa funcional + suporte e recuperação de contexto

Versão 0.1 • 04/09/2026 • preparado para Google Drive / Google Docs

IDEIA CENTRAL
Este documento permite que uma IA ou operador humano saiba o que existe no PRAXIUM, onde está, qual função exerce, o que foi comprovado e o que ainda precisa ser inspecionado — sem reconstruir o contexto a cada retomada.

Índice funcional rápido

Componente

Função principal

PRAXIUM

Cognição, decisão, governança e execução validada.

Aurora

Assistente pessoal, vetor de contexto, suporte e continuidade.

Sentinela / SRE

Vigilância, segurança, detecção de pane e recuperação.

Janelinha / PRX-DIRECT

Interface humana principal.

AURORA_INBOX

Fila operacional da Aurora.

Google Agenda / Gmail

Fontes externas de agendamento e contexto.

PowerShell

Contingência / último recurso.



https://assistente-inteligente-ia.blogspot.com/2026/09/praxium-arquivo-de-suporte-e.html

Criei uma primeira versão do Mapa Funcional Canônico do PRAXIUM, em dois formatos:

Ideia central: o mapa não diz só “que arquivo existe”. Ele registra o que faz, onde está, o que foi realmente comprovado e o que ainda precisa ser inspecionado.

Já coloquei nele os blocos que temos confirmados hoje: Janelinha/PRX-DIRECT, Router, PTC, Governança, Aurora/MAA-01, AURORA_INBOX, Sentinela/SRE, Google Agenda/Gmail e a separação correta de C:\AUTORA.

Agora precisamos transformar isso num inventário real do disco, arquivo por arquivo.

O próximo passo é gerar a árvore técnica do ACTIVE sem alterar nada. Rode só este comando:

Get-ChildItem C:\PRAXIUM\ACTIVE -Recurse -File |
    Select-Object FullName, Length, LastWriteTime |
    Export-Csv C:\PRAXIUM\MAPA_FUNCIONAL_INVENTARIO_ACTIVE.csv -NoTypeInformation -Encoding UTF8

Depois me envie esse CSV. Aí eu consigo começar a montar a versão seguinte com precisão:

arquivo
→ localização
→ módulo
→ função
→ quem chama
→ quem ele chama
→ entrada
→ saída
→ dependências
→ risco
→ estado funcional
→ teste/evidência

Aí sim teremos um mapa de máquina do PRAXIUM, não mais um mapa baseado em memória.


PRAXIUM — Mapa Funcional Canônico v0.1

Ideia central: este documento é um índice funcional para humanos e IAs. Ele registra o que existe, onde está, o que faz, o que foi realmente comprovado e o que ainda precisa ser inspecionado.

Regra de uso

Nenhuma IA deve inferir função apenas pelo nome do arquivo. Cada item deve carregar um estado de comprovação. O mapa deve ser atualizado quando houver inspeção, patch, teste, movimentação de arquivo ou mudança de responsabilidade.

Arquitetura funcional resumida

Usuário / Mundo / Agenda / Gmail
              ↓
            Aurora
              ↓
           PRAXIUM
              ↓
         Governança
              ↓
           Executor
              ↓
          Evidência
              ↓
      Reentrada cognitiva
              ↓
       Aurora / continuidade

Pane → Sentinela/SRE → Aurora → recuperação controlada → validação → PRAXIUM

Componentes mapeados

Janelinha / PRX-DIRECT

Papel: Interface humana principal e entrada direta para o PRAXIUM
Estado: CONFIRMADO_FUNCIONAL
Caminhos conhecidos:

  • C:\PRAXIUM\JANELINHA_PRX\janelinha_prx.py

  • C:\PRAXIUM\JANELINHA_PRX\prx_direct_server.py

  • C:\PRAXIUM\ACTIVE\praxium_direct_handler.py
    O que faz:

  • recebe comandos do usuário

  • encaminha para o Router

  • expõe authorize/execute no fluxo governado

  • faz reentrada cognitiva após execução governada
    Validação atual: Fluxo HTTP real validado; execução governada, evidência e reentrada cognitiva comprovadas.
    Pendências de mapeamento:

  • tratar erro de reentrada sem apagar o fato de que a execução já ocorreu

Router / núcleo de entrada cognitiva

Papel: Orquestra processamento da demanda e integração com PQR, Reason DNA, PTC, governança e gate final
Estado: CONFIRMADO_FUNCIONAL
Caminhos conhecidos:

  • C:\PRAXIUM\ACTIVE\.praxium\run\prx_core_router.py
    O que faz:

  • processa input

  • propaga prx_run_id

  • recebe evidencia_execucao_governada

  • submete operação concreta ao runtime governado

  • reavalia PTC e gate final
    Validação atual: Testes focados e fluxo HTTP real passaram.
    Pendências de mapeamento:

  • endurecer validação contra evidência sintética/fabricada

PTC - Padrões de Trabalho e Controle

Papel: Avalia se execução e teste realmente ocorreram e se o ciclo pode encerrar
Estado: CONFIRMADO_FUNCIONAL
Caminhos conhecidos:

  • C:\PRAXIUM\ACTIVE\.praxium\run\prx_core\padroes_trabalho_controle.py
    O que faz:

  • marca PTC-EXE-001 somente com execução observada

  • marca PTC-TST-001 somente quando teste foi realizado e aprovado

  • controla pode_encerrar
    Validação atual: Regressão corrigida; suíte integrada passou.

Governança / Governed Runtime

Papel: Controla risco, autorização humana, execução sandbox e recibos de evidência
Estado: CONFIRMADO_FUNCIONAL
Caminhos conhecidos:

  • C:\PRAXIUM\app\governance_security_gate\code_agent_adapter.py

  • C:\PRAXIUM\app\governance_security_gate\integration.py

  • C:\PRAXIUM\app\governance_security_gate\__init__.py
    O que faz:

  • classifica risco

  • exige autorização humana quando aplicável

  • emite permit/result receipts

  • executa operações em sandbox

  • impede promoção/autonomia não autorizada
    Validação atual: Submit/authorize/execute reais validados, incluindo expiração de token.
    Pendências de mapeamento:

  • persistência de decisões além do runtime em memória

Aurora / MAA-01

Papel: Assistente pessoal, vetor de contexto e sistema de suporte operacional do PRAXIUM
Estado: PARCIALMENTE_CONFIRMADO
Caminhos conhecidos:

  • C:\PRAXIUM\ACTIVE\PROJECTS\AURORA\MAA-01\maa01_processor.py

  • C:\PRAXIUM\ACTIVE\PROJECTS\AURORA\MAA-01\reports\scheduler_logs
    O que faz:

  • processamento MAA-01

  • organização/continuidade/preparação de contexto

  • histórico de scheduler real
    Validação atual: Processador e logs confirmados; integração atual completa com Gmail/Agenda ainda não comprovada.
    Pendências de mapeamento:

  • mapear entradas reais do maa01_processor.py

  • confirmar integração Gmail/Google Agenda

  • mapear relação com AURORA_INBOX

AURORA_INBOX

Papel: Fila operacional associada à Aurora
Estado: CONFIRMADO_EXISTE
Caminhos conhecidos:

  • C:\Users\55249\AURORA_INBOX
    O que faz:

  • armazenamento/filas operacionais da Aurora
    Validação atual: Diretório confirmado no perfil do usuário; comportamento interno ainda precisa ser inventariado.
    Pendências de mapeamento:

  • listar subpastas e arquivos

  • identificar produtores e consumidores

Sentinela / PRAXIUM_SRE

Papel: Segurança, monitoramento, detecção de pane e recuperação
Estado: CONFIRMADO_EXISTE_NAO_MAPEADO
Caminhos conhecidos:

  • C:\Users\55249\PRAXIUM_SRE

  • C:\Users\55249\prax_sre.ps1
    O que faz:

  • linha SRE histórica/operacional a ser inspecionada

  • provável health check/restart/recuperação
    Validação atual: Diretório e script confirmados; função exata ainda não inspecionada.
    Pendências de mapeamento:

  • inspecionar prax_sre.ps1

  • identificar health checks

  • identificar restart/bootstrap

  • identificar logs e validação

  • definir relação formal com Aurora e PRAXIUM

Google Agenda / Gmail como fontes externas

Papel: Agendamento e entrada de contexto/tarefas para Aurora
Estado: CONFIRMADO_NO_LADO_EXTERNO
O que faz:

  • Google Agenda já contém rotinas PRAXIUM/Aurora/TEMPO

  • notificações chegam ao Gmail
    Validação atual: Eventos e notificações reais fornecidos pelo usuário.
    Pendências de mapeamento:

  • comprovar ponte automática Gmail/Agenda -> Aurora

  • definir idempotência e proveniência

AUTORA

Papel: Projeto antigo de produção de textos e livros
Estado: CONFIRMADO_NAO_E_AURORA_PESSOAL
Caminhos conhecidos:

  • C:\AUTORA
    O que faz:

  • linha histórica separada
    Validação atual: Identificação confirmada pelo usuário.

Estrutura mínima para cada novo arquivo

Cada arquivo novo ou descoberto deve entrar no mapa com: componente, arquivo, caminho, papel, entrada, saída, dependências, quem chama, quem ele chama, efeitos colaterais, risco, estado de comprovação, último teste, prx_run_id relacionado e observações.

Próxima etapa de inventário

O mapa ainda não é completo. O próximo passo deve ser gerar inventário técnico do sistema ativo, começando por C:\PRAXIUM\ACTIVE, C:\Users\55249\AURORA_INBOX e C:\Users\55249\PRAXIUM_SRE, e depois enriquecer cada item com relações de chamada e função observada.

Regra canônica

O mapa funcional deve distinguir sempre: existência → acionamento → execução → efeito causal → resultado observado.


PRAXIUM_MAPA_FUNCIONAL_CANONICO_v0_1.json 

Comentários

Postar um comentário

Postagens mais visitadas deste blog

MODULO COMPUTACIONAL ESTÁVELE FUNCIONAL: PAPEIS E CENAS PROCESSAMENTO EM SILIGISMO LÓGICOS ESTÁVREIS

  MODULO COMPUTACIONAL ESTÁVELE FUNCIONAL: PAPEIS E CENAS PROCESSAMENTO EM SILIGISMO LÓGICOS ESTÁVREIS Princípio de Realidade Operacional 1) Tese central em forma de silogismo (lógico e testável) Premissa A: No nível físico, “é a mesma máquina” pode ser verdadeiro e irrelevante. Princípio de Realidade Operacional … Premissa B: No nível de software/governança, papéis só “existem” se houver mecanismos: interfaces, limites, logs, versionamento. Princípio de Realidade Operacional… Conclusão: “Papel” é real se ele produz diferença mensurável e auditável no output+log. Princípio de Realidade Operacional… Princípio de Realidade Operacional… 2) Modelo operacional (Atores e Cenas) Atores (papéis): conjuntos de regras + responsabilidades. Cenas (contextos): tipo de tarefa e risco (jurídico, código, síntese, planejamento etc.). Trocar ator/cena deve mudar: o que pode dizer/fazer, critério de parada, e registro do feito. motor socrático 02 18 12 2025 Teste de realidade do sistema...
Leia mais

PAPEIS E CENAS PROCESSAMENTO EM SILIGISMO LÓGICOS ESTÁVREIS

PAPEIS E CENAS PROCESSAMENTO EM SILIGISMO LÓGICOS ESTÁVREIS Princípio de Realidade Operacional  1) Tese central em forma de silogismo (lógico e testável) Premissa A: No nível físico, “é a mesma máquina” pode ser verdadeiro e irrelevante. Princípio de Realidade Operacional … Premissa B: No nível de software/governança, papéis só “existem” se houver mecanismos: interfaces, limites, logs, versionamento . Princípio de Realidade Operacional… Conclusão: “Papel” é real se ele produz diferença mensurável e auditável no output+log. Princípio de Realidade Operacional… Princípio de Realidade Operacional… 2) Modelo operacional (Atores e Cenas) Atores (papéis): conjuntos de regras + responsabilidades. Cenas (contextos): tipo de tarefa e risco (jurídico, código, síntese, planejamento etc.). Trocar ator/cena deve mudar: o que pode dizer/fazer, critério de parada, e registro do feito. motor socrático 02 18 12 2025 Teste de realidade do sistema (critério seco): mesmo input → Executor entre...
Leia mais

Princípio de Realidade Operacional: Papéis e Resultados (Atores e Cenas)

  Princípio de Realidade Operacional: Papéis Distintos Geram Resultados Distintos (Atores e Cenas) “Isso tudo é ilusão. É tudo a mesma máquina.” Essa frase parece demolir qualquer arquitetura modular. E, num nível, ela está certa: no nível físico, um único CPU/SoC executa tudo. Mas em informática e engenharia de software, a verdade que importa não é ontológica (“quantas máquinas existem?”) — é operacional (“o comportamento muda de forma verificável?”) . A pergunta útil, portanto, não é “módulos existem de verdade?”. É esta: Que diferença observável e auditável aparece quando eu digo que um papel está ativo? Se a resposta for “nenhuma”, então sim: é só nome. Se a resposta for “o sistema muda seu comportamento, seus limites e seu rastro”, então não é ilusão: é controle . Três níveis: onde “é a mesma máquina” é irrelevante 1) Nível físico (hardware) Sim: é a mesma máquina. Aqui, “módulos” são abstrações e não precisamos fingir o contrário. 2) Nível de execução (softwar...
Leia mais