Dream / Reflexão

Arquitetura de prévia do Dream e fluxo de trabalho de revisão explícita

O Dream é um recurso de Preview separado e revisado pelo usuário, disponível no Memory Console em https://xmemo.dev/me#dream. Ele é distinto da ferramenta de manutenção reflect (que executa passagens programáticas de consolidação sob demanda via MCP/API; consulte /docs/tools/reflect). Em vez de executar mutações silenciosas em segundo plano, o Dream prioriza o que o usuário revisa e escolhe salvar, organizando o contexto conversacional disperso em candidatos fundamentados em fontes.

• Espaço de trabalho do console: No Memory Console em https://xmemo.dev/me#dream, o Dream fornece um espaço de trabalho de prévia interativo sob o subtítulo: "Review recurring patterns before they become long-term memory."
• Revisão orientada pelo usuário: O Dream nunca modifica a memória persistente em segundo plano; todos os itens candidatos exigem inspeção e confirmação humanas explícitas antes que qualquer gravação de destino ocorra.
• Distinção em relação ao reflect: O Dream é um recurso de prévia separado em que os candidatos são gerados para inspeção do usuário e nada é salvo sem confirmação humana explícita. Por outro lado, a passagem de manutenção reflect (/docs/tools/reflect) é uma ferramenta interna cuja ação summarize lê memórias episódicas ativas e grava resumos fundamentados em fontes sob reflections/episodic. Para fatos recorrentes, o reflect fornece uma ação promote de episódico para semântico que exige importância média de pelo menos 0.35 e confiança média de pelo menos 0.6. Suas ações de ciclo de vida executam expire, decay e archive, com o dry_run fornecendo planejamento seguro sem gravações no destino.
• Limite arquitetônico: A geração de candidatos do Dream é estritamente um mecanismo de prévia e não implementa uma arquitetura especulativa de múltiplas passagens Light, REM ou Deep nem mutações autônomas em segundo plano.
• Postura de falha segura: Se uma execução for interrompida ou encontrar um problema, a memória existente permanecerá intacta ("Dream stopped safely. Existing memory was not changed.").

Disponibilidade de conta, status no catálogo de planos e limites de prévia

O Dream opera estritamente se o Dream estiver habilitado para sua conta. Todos os controles de runtime são desativados por padrão em ambientes de produção. A documentação pública evita expor sinalizadores de configuração interna.

• Disponibilidade de conta: O Dream opera estritamente se o Dream estiver habilitado para sua conta. Se o recurso não estiver ativo para um espaço de trabalho, o console exibirá: "Dream is not enabled for this workspace yet. Your memory remains unchanged."
• Status no catálogo: No catálogo de planos de produtos, o Dream não está incluído no nível Free, enquanto o nível Plus lista os recursos do Dream. No entanto, a documentação não afirma que o Plus desbloqueia o Dream na prática hoje, pois o provedor de fallback pessoal nega acesso quando a aplicação comercial está inativa.
• Limite de defeito: O Dream está atualmente em prévia e pode ainda não gerar candidatos para sua conta. A síntese baseada em modelo não pode ser executada diretamente no ambiente de worker fornecido, e a confirmação de candidatos depende da configuração de capacidade do servidor.
• Confirmação humana estrita: O sistema impõe um limite estrito de confirmação humana. A documentação rejeita qualquer alegação de salvamento automático ou anexação em segundo plano; cada item proposto requer o consentimento manual do usuário.

Ciclo de vida de execução, elegibilidade de evidências e códigos de motivo de filtro

Uma execução do Dream revisa evidências de memória elegíveis ao longo de uma janela de observação configurável (padronizada em 30 dias) para identificar padrões recorrentes sem alterar os registros de origem:

• Coleta de evidências: Uma execução de prévia examina memórias episódicas ativas e recuperáveis criadas dentro da janela de observação (personalizável via --window-days em até 365 dias).
• Candidatos fundamentados: Evidências elegíveis são agrupadas em temas recorrentes, gerando itens candidatos exibidos com linhagem de origem e uma pontuação de confiança ("Confidence Score").
• Por que as evidências foram filtradas: No console, o resumo da execução relata "Why evidence was filtered" usando chips de motivo padronizados: score below threshold, insufficient occurrences, insufficient evidence days, insufficient query contexts, duplicate candidate, source not episodic, source inactive e contradiction detected.
• Resumo de execução sem conteúdo: Execuções concluídas exibem um resumo de revisão: "Dream reviewed {{considered}} signals, generated {{generated}} grounded candidates, and saved {{promoted}} confirmed memories.", acompanhado da garantia de segurança: "This report is review-only and never becomes Dream evidence."

Modos operacionais do console e predefinições de agendamento

As configurações do Dream fornecem controle granular sobre os modos de execução e cronogramas de avaliação no painel de configurações do console:

• Modos operacionais: Os usuários selecionam entre dois modos de comportamento: "Preview only" (avalia evidências e gera candidatos revisáveis sem permissões de gravação) e "Allow explicit confirmation" (habilita a interface de confirmação para que os usuários possam revisar e confirmar seletivamente candidatos individuais).
• Predefinições de agendamento: A frequência de execução é configurada por meio de três predefinições: "Manual only" (executa exclusivamente sob demanda ao selecionar "Run Preview" no console ou emitir um comando de prévia via CLI), "Daily around 03:00" (execução diária agendada avaliada por volta das 03:00 no fuso horário local do usuário) e "Weekly on Monday around 03:00" (execução semanal agendada avaliada às segundas-feiras por volta das 03:00 no fuso horário local do usuário).
• Restrição de execuções agendadas: As execuções agendadas operam no modo preview only; as avaliações de agendamento em segundo plano nunca gravam memória nem ignoram a revisão humana.
• Ancoragem de fuso horário: As execuções agendadas usam o fuso horário local do navegador do usuário.

Fluxo de trabalho de confirmação, resultados tipados e ciclo de vida de destino

A confirmação de candidatos é append-only e requer ação explícita do usuário. O console suporta confirmação de item único e resultados tipados opcionais:

• Confirmação principal: No modo de prévia padrão, clicar no botão "Confirm and save" em um cartão de candidato cria um NOVO registro de memória sob o caminho dream/confirmed/... com a chave semântica dream:confirmed:... . As memórias de origem nunca são editadas ou sobrescritas.
• Configuração de resultados tipados: Quando resultados tipados estão disponíveis, o painel de configurações apresenta a pergunta "What should Dream prepare?" com a orientação "Choose what to generate. Turning a type off keeps existing drafts and saved content."
• Seis opções de geração: (1) Preferences: "Clarify your preferences"; (2) Knowledge: "Distill knowledge worth keeping"; (3) Skills: "Turn experience into reusable skills"; (4) Projects: "Organize project memory"; (5) Patterns: "Discover lasting patterns"; (6) Durable Memory: "Build reusable long-term memory".
• Chave de geração vs. consentimento de destino: Habilitar uma chave de geração não concede consentimento a um destino; todos os resultados preparados aparecem em "Prepared for your review" exigindo revisão manual.
• Ações de revisão de candidatos: Os revisores podem selecionar "Save edits" para modificar títulos e conteúdos propostos, "Review later" para adiar, "Reject" para descartar ou aceitar no destino pretendido.
• Aceitação por destino: Knowledge é aceito via "Add draft to knowledge base" em uma base de conhecimento escolhida como DRAFT (com estados de indexação de busca: "Saved. Preparing for search.", "Search index is ready. Publication is a separate choice.", "Saved, but indexing needs another attempt."); Skill é aceito via "Add draft to Cloud Skills" como DRAFT; Project é aceito via "Confirm project organization" (o resultado de associação de projeto é o único caminho que reatribui memórias existentes a um espaço de trabalho de projeto); Memory é aceito via "Save as memory".
• Remoção: Resultados confirmados tornam-se memórias padrão, rascunhos de conhecimento ou rascunhos de habilidades em seus respectivos armazenamentos. Eles são excluídos usando ações padrão de remoção do console ou da API; não há mecanismo de reversão ou desfazer específico do Dream.

Isolamento de espaço de trabalho, limites de equipe e operações de CLI

Permissões de espaço de trabalho e ferramentas de CLI impõem limites multilocatário estritos e recursos de função:

• Delimitação do espaço de trabalho: O cabeçalho do console identifica o espaço de trabalho ativo como "Personal space" ou "Team space".
• Permissões de equipe: Em espaços Team, apenas proprietários e administradores de equipe podem modificar as configurações do Dream, cancelar execuções ativas ou confirmar memórias candidatas ("Only Team owners and admins can change Dream settings.").
• Limitação de resultados tipados em equipe: Resultados tipados não estão disponíveis em espaços Team. Espaços de trabalho Team operam no modo preview-only ou no modo de confirmação de memória v1.
• Comandos de CLI verificados: A CLI do xmemo (commit fixado d412c7866b7a4c8eedb3a0cf40748c6aef8707ec, src/commands/dream.js) suporta três comandos verificados: xmemo dream preview [--window-days <n>] [--wait] [--json] (aciona a prévia; falha em modo fechado se a prévia estiver desativada com "Dream preview is disabled; CLI will not change Dream settings."), xmemo dream show <run-id> [--wait] [--json] (exibe itens candidatos; suporta --receipt-out para recibos de leitura) e xmemo dream apply <run-id> --item <id> --from <view.json> --yes [--json] (confirma um candidato usando o endpoint de confirmação v1).
• Limites operacionais da CLI: A CLI não pode alterar as configurações de configuração do Dream (as configurações devem ser gerenciadas no console), e dream apply opera exclusivamente com confirmação de memória v1 (não realiza mutações de resultado tipado).

# Trigger a candidate preview across a 30-day window
xmemo dream preview --window-days 30 --wait --json

# Inspect candidate proposals and record a read receipt
xmemo dream show <run-id> --receipt-out receipt.json

# Confirm a candidate proposal into memory via v1 confirmation
xmemo dream apply <run-id> --item <item-id> --from view.json --yes