Uma biblioteca de possibilidades.

Produto e problema

O foco são tarefas cujo próximo passo pode ser enumerado. O domínio oferece perguntas booleanas, escolhas ou escores, em vez de solicitar ferramentas em texto livre. O juiz de rubrica proposto navega documentos e imagens sob demanda. A economia de contexto é plausível, mas depende do número de passos e da qualidade da seleção. Avaliar um relatório completo exige também verificar se a navegação deixou passar evidência contrária.

Arquitetura observada

package.json declara versão 0.1.1, módulos ES e Node mínimo 22.18. Exporta núcleo, CLI, modelos e utilitários de teste. Depende de pi-ai, Commander e Zod; exemplos e viewer ficam fora do pacote npm principal. O código separa domínio, helper de escolhas, loop, definição, trace e replay. Essa organização permite incorporar o núcleo em outro programa sem adotar a interface dos exemplos nem transformar o framework em serviço multiusuário.

Mecanismo no código

src/core/loop.ts confirma inicialização, registro do hash da definição, perguntas por estado e aplicação da transição até não existirem questões. Distingue done, step limit e failed. Define três tentativas por lote e fator 0,7 para reduzir visão quando o contexto excede a janela. Esses controles limitam falhas de transporte e contexto; não provam correção da decisão nem garantem que uma transição tenha efeitos seguros ou idempotentes.

Contrato do domínio

DOMAINS.md explicita que não existe opção de parada automática. O domínio deve fornecê-la e retirar escolhas já executadas. Limite de passos fica desligado enquanto não configurado. picking exige chaves e textos distintos, seleciona opções por prioridade e converte a resposta na transição correspondente. Uma lista incompleta pode tornar impossível uma resposta adequada. O responsável pelo domínio precisa modelar evidência insuficiente, desistência, erro e estados terminais antes de avaliar modelos.

Providers e autenticação

piAiDecider exige provider/id e um modelo registrado como classifier. Rejeita modelo desconhecido, toma janela do catálogo e configura timeout padrão de 300 segundos e duas retentativas de transporte. A chave pode ser explícita ou resolvida pelo provider, como TYPESAFE_API_KEY. O contrato não é o de qualquer chat OpenAI-compatible: perguntas tipadas e probabilidades são centrais. Não foram medidas disponibilidade, limites de conta, latência real ou políticas de retenção do provider.

Persistência e recuperação

run.json, result.json, trace.jsonl e requests.jsonl registram definição, resultados, perguntas e respostas. Replay completo usa estados gravados e não executa transições nem consulta modelo. Fork repete o prefixo e volta à inferência. O código valida domínio e caso e anota divergência de hash. Isso reconstrói o percurso histórico; não confirma que arquivos externos ainda têm o mesmo conteúdo ou que efeitos produzidos no mundo real possam ser repetidos com segurança.

Segurança e privacidade

Escolhas finitas reduzem geração arbitrária de comandos, mas as transições continuam com os poderes do processo. Não foram identificados sandbox universal, RBAC multiusuário ou criptografia em repouso nas fontes selecionadas. Views e imagens podem seguir ao provider, e requests/traces podem conter material sensível. Um uso no Lab exigiria minimizar dados, restringir ferramentas e planejar retenção. A lista finita não neutraliza automaticamente instruções maliciosas presentes nos documentos que o modelo consulta.

Deploy e experiência

A distribuição principal é biblioteca/CLI; o viewer é pacote separado para acompanhar casos no navegador. O manifesto contém build, lint, typecheck, cobertura e mutação, evidência de verificações disponíveis, sem execução nesta missão. Windows, extração de PDFs e dependências dos exemplos continuam sem validação funcional. Não há prova de acessibilidade do viewer ou de navegação mobile. Um piloto deveria começar com domínio local sintético e sem privilégios, antes de adicionar documentos reais e renderizadores.

Licença e custos

LICENSE contém MIT. Uso e modificação exigem preservar os avisos aplicáveis; a licença não fornece modelo, créditos de inferência ou direitos sobre documentos de entrada. A perspectiva de especialização muito mais barata é argumento do autor, não resultado reproduzido. Custos incluem API, construção do domínio, preparação de páginas e armazenamento dos rastros. A contabilidade de usage ajuda quando o provider informa números completos, mas não cobre automaticamente infraestrutura nem tempo de revisão humana.

Maturidade e manutenção

Foram consultados release v0.1.1 e commit da branch padrão de 30 de outubro de 2026. É versão inicial. O próprio README declara que Jev é fraco em xadrez e ainda não substitui os melhores modelos de chat como juiz. Separar qualidade do framework e do modelo evita conclusões erradas. Não houve auditoria de todos os testes, issues, dependências ou incidentes. Atividade recente indica manutenção, sem estabelecer estabilidade, suporte ou capacidade de produção.

Alternativas e pertinência

Pode complementar avaliadores determinísticos e revisão consultiva em rubricas estreitas com fontes navegáveis. Regras diretas são preferíveis quando os critérios são objetivos; juiz de chat cobre ambiguidades que uma lista fechada exclui. Para o Lab, o valor é investigar rastreabilidade, calibração e custo numa unidade pequena. Não substituiria aceite humano, gate canônico ou protocolo de sessão. Uma probabilidade é saída de modelo e não autoridade para publicar, concluir trabalho ou alterar arquivos.

Próximos ensaios propostos

Com autorização futura, fixar corpus público, rótulos humanos e alternativas explícitas, incluindo insuficiência de evidência. Comparar regras, classificador e juiz de chat em erro, cobertura, calibração, custo total e latência. Exercitar loop sem parada, resposta inválida, contexto excessivo, retomada e mudança de domínio entre run e replay. Inspecionar se cada nota cita evidência suficiente. Nenhum ensaio foi executado: esta pesquisa fornece contrato e riscos para decidir a abertura de um piloto.

Produto e foco pedagógico

O mantenedor descreve quatro momentos: medir entendimento, planejar dependências, ensinar por passos e praticar em contextos variados. Campos de raciocínio e confiança alimentam a adaptação. O grafo registra ideias e premissas, não uma nota global da pessoa. É uma proposta pedagógica apoiada por ferramentas, sem estudo de eficácia identificado nesta amostra. Melhor interface ou memória mais longa não demonstram aprendizagem, transferência para problemas novos nem redução de erros conceituais.

Arquitetura e fronteiras

A arquitetura situa páginas e APIs em app, interface em components, composição em src/server, agentes em src/agent, contratos em src/core e persistência em src/store. Electron hospeda a versão desktop. package.json confirma Next.js, Electron e versão 0.4.1. O documento reconhece que as regras de import não constituem arquitetura hexagonal completa nem garantem escritor único entre processos. Essa autolimitação evita confundir separação de pastas com isolamento demonstrado.

Turno e recuperação

O servidor é dono do histórico; o navegador envia eventos, não substitui a transcrição. Admissão valida entrada, resolve modelo, reclama liveness por chat e grava a entrada antes de inferir. Uma corrida retorna 409. O streaming pode se reconectar ao turno aceito, enquanto retry de falha é ação explícita. Essa separação é relevante para evitar duplicação após perda de transporte. A documentação não equivale a teste de queda ou recuperação realizado nesta missão.

Perguntas, prática e subagentes

Perguntas são executadas no servidor e respondidas no navegador. O plano valida um DAG Mermaid restrito. A prática impõe um problema ativo e rejeita conclusão sem problema. Pesquisador, leitor de PDF, criador de demos e gerador visual rodam em segundo plano com jobs persistidos. A existência dessas rotas pode melhorar continuidade, mas também amplia chamadas, arquivos e efeitos externos. A pesquisa não mediu se os agentes obedecem corretamente ao método pedagógico em português.

Grafo e armazenamento

Chats ficam em JSON e o grafo em JSONL de proposições, cadeias, sessões e cobertura. Fingerprints identificam prosa ainda não extraída. O documento distingue limiar de disparo e tamanho de lote: mudar o primeiro não muda automaticamente o segundo na composição atual. Leitores ignoram certas linhas inválidas; algumas substituições usam rename. Não há transação de banco abrangente ou lock entre processos. Recomenda-se um servidor dono do perfil, com backup e recuperação ensaiados.

Modelos e endpoint customizado

A implementação usa Pi para streams, ferramentas e metadata. A documentação permite um endpoint OpenAI-compatible com vários modelos; a URL deve incluir o caminho completo, sem acréscimo automático de /v1. Descoberta falha pode recorrer a IDs manuais, mas 401/403, redirects e limites excedidos falham explicitamente. Seleção de Vision não prova que o modelo compreenda imagens. Budgets declarados controlam pedidos e compactação, sem aumentar a janela real do servidor de inferência.

Identidade e credenciais

Configuração não secreta fica em settings.json; credenciais salvas usam auth.json separado. O endpoint customizado vincula autorização a URL, modo e identificador aleatório. Mudança de destino exige nova chave ou consentimento explícito para reutilizar. Operações verificam binding e revisões opacas evitam sobrescrever edições concorrentes. Electron mantém fronteiras próprias para certas assinaturas. Esses mecanismos não são autenticação multiusuário web. Não houve inspeção integral dos fluxos OAuth nem validação dos termos de cada serviço.

Privacidade e acesso a dados

Ferramentas de arquivo são de leitura, porém não confinadas ao diretório de dados ou projeto: resolvem caminhos também contra o home do usuário. Anexos por caminho não constituem sandbox de upload. Modelos recebem contexto; pesquisa pode fazer fetch direto; ditado usa Deepgram. Dados locais e chaves locais não significam offline. Para o Lab, seria prudente começar com perfil descartável e fontes públicas, sem corpus privado, e registrar os destinos efetivos de cada modalidade antes de conectar produção.

Plataformas, UX e acessibilidade

O README oferece macOS Apple Silicon, Windows x64 e Linux x64, com atualizações internas. Windows é descrito como não assinado; macOS como assinado/notarizado. Há referências de teclado e interface de grafo, mas esta pesquisa não verificou foco, contraste, leitor de tela ou toque. O fluxo depende de separar sessão, problema e job, o que exige UX clara em erros e pausas. Compatibilidade de embalagem não prova paridade funcional das ferramentas em todas as plataformas.

Licença e custo

LICENSE contém AGPLv3 e o manifesto declara AGPL-3.0-only. A aplicação não cobra assinatura própria segundo o mantenedor, mas providers, busca e ditado podem cobrar. O medidor estima custos de API conhecidos; assinatura, CLI e endpoint customizado têm limites de contabilização. Cache prolongado pode aumentar escrita de cache. Um orçamento de piloto deve incluir extração do grafo e tarefas de fundo, além das respostas visíveis. Direitos sobre PDFs e dados de alunos permanecem separados da licença.

Manutenção e alternativas

A consulta encontrou release v0.4.1 de 31 de outubro de 2026. O guia de arquitetura diferencia implementação atual de documentos arquivados, sinal útil para leitura fiel. Isso não estabelece estabilidade nem eficácia. Frente a cadernos RAG, o diferencial é medir e praticar entendimento; frente a tutor por chat, é persistir proposições e dependências. ai-memory atende continuidade de agentes, não acompanhamento pedagógico. No Lab, o melhor valor imediato é referência de método e contrato de turno, sem adoção automática.

Ensaios futuros e limites

Um piloto autorizado deveria usar aula pública curta, critérios definidos por docente e avaliação antes/depois com problema novo. Testar retomada, retry, conflito 409, corrupção de JSONL, extração parcial, troca de provider e imagem rejeitada. Medir se o grafo preserva erros do professor e como corrigi-los. Validar Português, teclado, custo completo e restauração. Nenhum produto foi instalado ou executado aqui; alegações de ensino adaptativo e segurança permanecem qualificadas por documentação e leitura estática.

Produto e unidade de memória

O objetivo é permitir que outro harness retome trabalho sem reexplicar arquitetura, tentativas falhas e questões abertas. A unidade legível é uma página Markdown numa wiki com Git. Handoffs têm protocolo de posse e claim único segundo o mantenedor. Isso difere de recuperar apenas similaridade semântica: há identidade de sessão e responsabilidade pela passagem. Não foi demonstrado que todos os harnesses emitam eventos equivalentes ou que um handoff capture integralmente decisões humanas importantes.

Arquitetura observada

Cargo.toml confirma workspace Rust, mínimo 1.95, runtime Tokio, rusqlite com SQLite bundled, Axum e cliente HTTP. A arquitetura descreve separação entre store, LLM, CLI e transporte MCP. Wiki é fonte legível; SQLite fornece índices e estruturas derivadas, inclusive busca textual, entidades e vizinhança de links. Não exige manter banco vetorial separado. O número de features é amplo: auditar somente o binário de captura seria insuficiente para aprovar painel administrativo, automação e providers opcionais.

Captura e processamento

Hooks registram observações sanitizadas de prompts, ferramentas e fronteiras de sessão. Consolidação pode seguir caminho local baseado em regras; opções LLM reescrevem páginas. A arquitetura afirma que histórico armazenado entra como dado não confiável, com separadores explícitos. Isso reduz ambiguidade de prompt, sem provar imunidade a injeção. A fidelidade depende do adaptador do harness, das regras de sanitização e do que os eventos realmente expõem. Não foram lidos transcripts privados nem executados hooks nesta missão.

Busca, esquecimento e evidência

A busca combina FTS, entidades, links e vetores opcionais. Retenção ponderada por uso e curvas por camada procuram evitar memória eternamente crescente. Algumas transformações que reescrevem ou descartam conteúdo ficam desabilitadas por padrão segundo o README. O original pode permanecer no Git ou cadeia de versões, mas isso exige distinguir remoção da vista, expiração e eliminação física. Para o Lab, uma busca que encontra algo não prova que encontrou a decisão vigente nem que resolve contradições normativas.

Estado e recuperação

A arquitetura apresenta Markdown como verdade e banco como derivado reconstruível, com estado bruto sanitizado de workstreams gerenciados em diretório próprio. Backup usa mecanismos adequados ao SQLite, não simples cópia cega de banco ativo. A reconstrução precisa preservar identidade, escopo e metadados. Não foi executado reindex, restore ou migração entre versões. Operação segura exigiria testar restauração num perfil isolado e verificar se handoffs e autorizações sobrevivem sem transformar índice perdido em perda de autoridade.

Providers e dados externos

DATA_HANDLING.md descreve embeddings locais all-MiniLM-L6-v2 de 384 dimensões e download inicial de cerca de 87 MB; none evita o download. Embeddings remotos podem receber todo o texto de páginas, inclusive backfill do corpus existente. LLMs opcionais recebem observações e páginas para consolidação e outras funções; reranker recebe consulta e snippets. Webhooks de admissão podem receber corpo completo de escrita. Uma mudança de configuração pode alterar retroativamente o destino de dados previamente locais.

Autenticação e isolamento

SECURITY.md documenta bearer, usuários, sessões humanas, rotas administrativas e permissões por projeto. Não-loopback sem autenticação falha fechado, salvo override explícito. TLS continua necessário fora de loopback; autenticar não cifra o transporte. O projeto distingue identidade atribuída por proxy confiável de direitos administrativos. Há validações de paths/reparse points e escopo descritas. Não se trata de prova de isolamento entre organizações hostis: confiança no operador, no proxy e nos grants continua parte do modelo.

Privacidade e limites

Sem criptografia própria em repouso, a proteção depende de permissões e disco do sistema. Sanitização é best-effort e não cobre igualmente todos os caminhos de saída. Captura de texto final do assistente tem opt-in duplo segundo a política, mas destinos remotos continuam demandando revisão. Git também retém versões que parecem removidas da interface. O Lab precisaria mapear retenção, dados pessoais e corpus secreto por escopo antes de permitir captura automática; nenhuma configuração privada foi consultada ou alterada.

Plataformas e integração

README lista Linux e macOS suportados, WSL2 suportado e Windows nativo experimental. Integrações variam entre hooks completos, MCP-only e hooks-only; uma tabela ampla não garante paridade de retomada. Setup pode criar serviço e registrar componentes em vários agentes encontrados. Essa conveniência implica efeitos de ambiente relevantes. No Lab, estudo deve começar por plano de mudanças e amostra de um único consumidor, preservando launchers, atualizadores e configuração nativa, antes de qualquer integração familiar.

Licença e custos

LICENSE é MIT, mas o custo de operação inclui disco, retenção histórica, CPU para embeddings e eventual inferência externa. Ausência de chamada LLM padrão não significa ausência de rede: download inicial existe. Opções de cloud têm contratos e cobrança próprios. A pesquisa não validou preço de API nem disponibilidade por subscription. O modelo de arquivos legíveis favorece portabilidade, mas migração e revisão de dados custam trabalho. Um piloto deve comparar ganho de continuidade ao custo de captura e curadoria.

Manutenção e pertinência

Foram observados commit e release v3.3.3 em 3 de novembro de 2026, além de documentação extensa de segurança e dados. A rapidez de mudança aumenta a necessidade de fixar SHA e testar migração, em vez de concluir maturidade pela atividade. O diferencial frente a memória por harness é passagem explícita entre ferramentas; frente a vector store, é arquivo legível com índices derivados. Para o Lab, interessa comparar esse protocolo com posse e STATE existentes sem converter memória inferida em cânone.

Próximos ensaios propostos

Após autorização, criar corpus público com decisões contraditórias e migração entre dois harnesses, verificando claim único, origem, datas e escopo. Testar zero-LLM sem internet após pré-carga, ausência de download em none, bloqueio de projeto e backup/restore. Medir recuperação de decisão vigente, ruído, vazamento entre perfis e alterações reais de setup. Revisar diff dos arquivos nativos antes de aplicar. Nenhuma instalação, migração, consulta a dados privados ou prova funcional ocorreu nesta pesquisa.

Produto e escopo

A ferramenta visualiza sessões existentes e resume seu último estado conhecido. O escritório é metáfora visual, não um orquestrador nem scheduler. Lista separa Needs you, Working e Finished e oferece comandos de retomada. A distinção é importante para o Lab: um cartão pode ajudar a localizar atenção necessária, sem autorizar concluir que uma missão acabou. O monitor não substitui o ledger ou a confirmação do executor sobre o recurso sob sua posse.

Arquitetura observada

package.json e fontes mostram CLI JavaScript, servidor HTTP local e frontend estático. src/watcher.js descobre históricos e emite mudanças; src/server.js produz snapshots e Server-Sent Events. Não há API de modelo obrigatória para observar agentes. A animação 3D usa bundle de Three.js, com código fonte separado do bundle distribuído. A simplicidade reduz componentes de infraestrutura, mas os adapters dependem de formatos locais que podem mudar sem contrato estável.

Mecanismo de leitura

Watcher usa polling de um segundo e redescoberta periódica, em vez de depender de fs.watch. Codex é localizado percorrendo todas as datas e filtrando por mtime, de modo que chat antigo retomado continue visível. Leituras guardam offsets e pedaços incompletos; alguns logs grandes usam cabeça e cauda. O código define limites e estratégias diferentes por cliente. Isso torna consumo limitado, mas também pode reduzir contagens ou perder contexto em históricos enormes.

Estados e falsas conclusões

O README distingue final de chamada, ferramenta e turno. Grok com ferramenta Pending não é automaticamente aprovação; resposta sem evento terminal eventualmente vira Idle, não Done. Gateway Magpie não fornece todas as fronteiras e não pode provar conclusão. Esse cuidado é útil, mas continua dependente de eventos corretos do cliente. Para o Lab, liveness, posse, execução e aceite precisam continuar separados. Timeout de silêncio é indício operacional, não evidência de que o comando morreu.

Providers e dados

A ferramenta não escolhe modelos nem autentica nas APIs de inferência. Lê JSONL e, para OpenCode/Hermes, bancos SQLite locais via node:sqlite. Essas duas integrações exigem Node suficientemente recente e podem ser omitidas em runtime antigo. Magpie é integração opcional com gateway local e chave própria, sem ser chave de provider. A leitura de histórico pode expor prompts, respostas e ferramentas no navegador; o fato de não fazer inferência não torna o conteúdo não sensível.

Persistência e identidade

O processo mantém trackers e snapshots dos históricos de origem. Comandos resume derivam da identidade nativa da sessão; subagentes devem preservar parentesco. O monitor não se torna fonte canônica do trabalho. Variáveis de ambiente permitem localizar homes alternativos, sem mover os dados. A pesquisa não demonstrou sincronização multi-host, retenção própria de longo prazo ou reconstrução perfeita após rotação de logs. Cada versão do adapter deve ser confrontada com amostras sintéticas do formato realmente usado.

Autenticação e defesa local

src/server.js valida Host entre localhost, 127.0.0.1 e ::1 para reduzir DNS rebinding. Ações como shutdown, update e instalar cena exigem cabeçalho específico, ausente em requests simples cross-site. Transcripts são recusados quando privacy está ativo. Esses controles foram lidos, não testados. Não foi identificado login multiusuário nem autorização granular por projeto. A confiança é na sessão do usuário local; exposição via proxy, túnel ou rede mudaria esse modelo.

Privacidade e rede

O README diz que o serviço escuta somente loopback. Entretanto há verificação de atualização do package.json remoto e cenas que podem ser baixadas; Magpie opcional também faz polling. Assim, a frase promocional sobre nada sair deve ser entendida sobre conteúdo observado, não como ausência total de rede. O modo private oculta conversa na página e no endpoint de transcript. Seria necessário verificar também títulos, diretórios, notificações e screenshots antes de usar numa tela compartilhada.

Plataformas e UX

Polling é escolhido para comportamento consistente em macOS, Linux e Windows. Interface tem português e outras línguas, filtros, notificações e pop-out. Document PiP oferece interação onde disponível; fallback de vídeo é apenas visual e sofre throttling de segundo plano. Contagens Today podem ser baixas em logs muito grandes. Não foram testados acessibilidade, leitores de tela, consumo de GPU ou paridade entre navegadores. A metáfora 3D deve ser comparada à lista simples em utilidade e carga visual.

Licença e custo

O projeto declara MIT, e assets Kenney usam CC0 conforme documentação. Não requer API paga para o caminho básico. Custos relevantes são CPU, memória, leitura de disco, renderização 3D e manutenção dos parsers. Atualização executa git pull e reinicia, portanto é mutação do ambiente e não mera observação. Hooks opcionais também alteram configuração do Claude. Esta pesquisa não acionou update, instalador, hook ou leitura de logs reais dos agentes do usuário.

Maturidade e alternativas

Release v0.7.0 e commit correspondente foram consultados em 3 de novembro. O repositório contém suites sintéticas para watchers, clients, UI e privacidade; isso não prova aprovação dessas suites nesta missão. O foco difere de Otto e Kanzo: observa o que já existe, enquanto os outros hospedam fluxo ou tarefas. Pode complementar o Lab como visão rápida, preservando logs e ledger existentes. Estrelas ou qualidade visual não medem fidelidade de cada status.

Próximos ensaios propostos

Após autorização, gerar históricos fictícios com pausa, aprovação, erro, tool concluída e turno ainda ativo. Testar replay incremental, chat antigo retomado, JSON truncado, banco bloqueado e rotação. Comparar snapshot ao evento exato, medir falso Done e falso Waiting. Rodar modo privado contra todos os endpoints e notificações, sem usar transcripts privados. Verificar Node do host e CPU em 2D/3D. Nenhum desses testes ocorreu; a entrega permanece documental e estática.

Produto e foco

Otto apresenta Home para resumo diário e cartões e Chat para sessões, bots e equipes, junto a documentos e automações. A proposta é reunir trabalho antes disperso por terminais e aplicativos. Os agentes continuam sendo CLIs e contas do usuário. Isso difere de vender um modelo próprio e implica dependência do comportamento dos providers. Para avaliar utilidade, seria preciso medir se a integração reduz troca de contexto sem esconder aprovações, erros ou a origem efetiva de cada resultado.

Arquitetura observada

Package.swift exige Swift 6.2 e define bibliotecas e executáveis especializados: modelos, persistência, runtime, harness, ferramentas, MCP, controle, observabilidade e componentes de app. Há ligação explícita a sqlite3. O README exige macOS 15 e Xcode 26 para o app, com companion iOS e daemon headless. Módulos remotos podem ter partes Linux, mas isso não é aplicativo Windows equivalente. A organização modular ajuda localizar contratos, sem demonstrar isolamento de segurança entre todas as bibliotecas.

Loop de ferramentas

HarnessRunner.swift confirma sessão carregada/criada, gravação do prompt antes da inferência e até 20 rodadas de ferramentas por padrão. Cada chamada recebe recibo executing, completed ou uncertain quando lança erro. O runner exige continuation e resposta final não vazia; ausências geram erro explícito. Contexto anterior é inserido com rótulo de dado recuperado. Esses detalhes favorecem recuperação honesta, porém recibo completed apenas indica retorno do executor, não verificação independente do efeito externo.

Providers e compatibilidade

PROVIDER_ADAPTERS.md descreve descoberta de executáveis e versões, especificações por lançamento e diferenças entre Claude, Codex, Hermes, Kimi, Cursor, OpenCode e Grok. Alguns clientes exigem bridges; outros não expõem histórico ou modo read-only suficientemente estrito. Há endpoint local OpenAI-compatible no harness próprio. Uma lista de adapters não prova paridade: retomada, streaming, seleção de modelo, ferramenta e autenticação variam. Atualização de um CLI pode alterar contrato mesmo quando o aplicativo continua abrindo.

Persistência e perfis

O README descreve SQLite, memória por bot e separação Work/Personal. O threat model inclui journals e restauração após crash. No runner, mensagens e recibos são salvos antes/depois de ferramentas, permitindo distinguir resultado incerto de operação nunca iniciada. Não foi exercitado backup, migração, encerramento de processo ou restauração. No Lab, a fronteira crítica seria preservar identidade e dados de cada perfil sem transformar memória resumida em autorização para alterar um corpus ou concluir missão.

Identidade e autorização

Credenciais são declaradas em Keychain ou ambiente de lançamento, com tokens de controle escopados. A documentação de daemon remoto usa túnel SSH e token de 256 bits, sem listener TCP público. Rotação só muda credencial após substituição durável e confirmação. São contratos documentados, não certificação de segurança. Processos de provider continuam com a permissão escolhida pelo usuário; modo irrestrito conserva capacidade ampla. A autoridade não deve vir de texto de browser, terminal ou áudio transcrito.

Privacidade e rede

Execução local não impede envio a modelos cloud, conectores, voz xAI ou bridge remoto. O threat model protege prompts, áudio, credenciais, worktrees e histórico, mas reconhece riscos residuais de CLIs. A documentação remete login/MFA/CAPTCHA ao humano em browser, sem transportar senha por chat. Não foram capturados tráfego nem credenciais. Uma avaliação do Lab precisaria enumerar destinos por recurso e comparar permissões reais à UI, especialmente quando um agente acessa browser, email e terminal no mesmo contexto.

Deploy e operação

É software desktop com ferramentas de desenvolvimento e daemon, não só um frontend. O roteiro de build cria identidade de assinatura local no modo Dev; esse efeito não foi realizado. O README explica execução serial de testes por recursos PTY/process-wide, e certos testes dependem da presença do CLI correspondente. Nenhum teste foi rodado. Para o host Windows atual do Lab, pertinência imediata é arquitetural; qualquer piloto Mac dependeria de máquina e ambiente explicitamente autorizados.

UX e acessibilidade

A integração oferece Home, chat, work panel, browser, documentos e comandos. Um ambiente tão amplo precisa mostrar claramente qual provider age, em qual perfil e com que autorização. A pesquisa não verificou VoiceOver, foco, teclado ou companion mobile. O acesso remoto pode complicar onde arquivos e processos realmente vivem. Recomendação de estudo: confrontar a interface com journal e PTY, para garantir que um estado visual não oculte ferramenta incerta ou job que ainda segue no host remoto.

Licença e custo

LICENSE é Apache 2.0; NOTICE, marcas e componentes de terceiros têm regras próprias. A licença do código não concede contas, modelos ou uso ilimitado de API. Custos incluem Mac, inferência, voz, servidores remotos e manutenção dos providers. Nome/logo ficam sujeitos à política de marcas mencionada no README. Não foi consultada tabela comercial completa nem assumido que módulos com nomes comerciais impliquem cobrança específica. O orçamento real deve acompanhar chamadas e credenciais usadas por cada adapter.

Maturidade e comparação

Release v0.2.14 de 2 de novembro e commit de sincronização do main privado foram consultados. Sincronização pública não revela todo processo interno de desenvolvimento. A versão permanece inicial; threat model e testes listados são evidência de desenho, não validação local. Comparado a whatsmyagentdoing, Otto executa e controla, ampliando risco. Comparado a Kanzo, oferece ambiente completo em vez de quadro leve. O Lab deve avaliar cada função sem adotar o pacote inteiro por entusiasmo com a interface.

Próximos testes propostos

Em piloto futuro Mac, usar projeto público e credenciais descartáveis, verificar PTY, cancelamento, restart, recibo uncertain e limite de rodadas. Testar separação Work/Personal, token revogado, tunnel caído, atualização do provider e restauração de SQLite. Confrontar read-only anunciado com efeito permitido no sistema. Medir acessibilidade e mostrar o artefato real ao Pai. Nenhum desses ensaios ocorreu nesta pesquisa; a leitura pública não autoriza instalar, autenticar, parear mobile ou iniciar daemon.

Identidade atual do projeto

A referência suna permanece acessível, mas o README atual chama o produto Kortix CompanyOS. O foco deixou de ser descrito apenas como agente geral: apresenta time compartilhando agentes, memória, conectores e sessões persistentes. É importante pesquisar a versão atual, sem atribuir arquitetura histórica Python a este snapshot TypeScript. As promessas de milhares de agentes, milhares de apps e operação contínua são alegações do fornecedor, sem ensaio de escala ou cobertura realizado nesta missão.

Arquitetura observada

package.json e apps/api/package.json mostram workspace e monólito API Bun/TypeScript. Dependências incluem Hono, contratos internos, Drizzle/PostgreSQL, Supabase, AWS S3/SQS, Composio, Daytona, Stripe e Sentry. O entrypoint importa montagem da aplicação, bootstrap, schema e dispatch de entrada. A fonte confirma componentes conectados e escopo operacional amplo; não prova que toda feature anunciada esteja habilitada no pacote self-host ou disponível sem serviços comerciais. Dependência SDK também não prova uso obrigatório em cada rota.

Mecanismo de orquestração

README descreve agentes customizados sobre pi, acionados por agenda, webhook assinado, evento de conector ou mensagem. My Kortix delega a sessões separadas; cada uma tem computador próprio que pode dormir e acordar. O estado é distribuído entre Git, Drive, workspace e registro da sessão. Isso é uma separação interessante entre compute descartável e memória durável, mas exige regras de consistência e retry. Não foram rastreados todos os handlers de evento até a execução do agente.

Boot e operação no código

apps/api/src/index.ts confirma preparação de processo, verificação de schema e boot de serviços quando executado como entrypoint. Importação para tooling evita parte dos efeitos de produção. O código registra audit de entrada e handlers de WebSocket para app, tunnel e sandbox. Há tratamento de URL absoluta e explicação de timeout para streams longos. Essas evidências mostram preocupações reais de operação, sem garantir que retries, dreno e deploy concorrente sejam corretos em todos os serviços.

Providers e custos de inferência

O README oferece modelos geridos, chaves próprias e conexões de assinatura, passando por gateway com budgets e regras de acesso. O manifesto confirma pacotes de catálogo e LLM gateway. Isso não demonstra que uma subscription específica seja autorizada para qualquer workload nem que esteja incluída sem limites. Providers, cloud computers e conectores podem ter faturamento separado. Não foram abertas contas nem verificados preços ao vivo. Uma análise econômica precisaria contabilizar execução ociosa, armazenamento e eventos recorrentes.

Persistência e recuperação

O desenho distribui estado por repo, Drive, workspace e histórico. Apps são descritos com volumes, snapshots, releases e rollback; sessões continuam após preencher contexto consultando registro completo. Recuperação fiel depende de manter vínculos entre esses sistemas e de saber qual é fonte de verdade para cada recurso. Não houve backup/restore, desastre ou migração testados. O Lab deveria exigir inventário de cada armazenamento, retenção e procedimento de recuperação em vez de aceitar persistência como uma propriedade única do produto.

Identidade e permissões

O fornecedor declara roles, grupos, permissões por recurso, SAML, SCIM, audit log e segredos cifrados por projeto. Agentes devem propor mudanças por change request com merge humano e deny-by-default. O entrypoint faz referência a permissões de membros, mas esta pesquisa não auditou middleware ou enforcement de todas as rotas. Consultor separado que verifica outcome também não substitui aceite humano. As garantias precisam ser conferidas por função e edição, sobretudo self-host, cloud e white-label.

Privacidade e observabilidade

Self-host não significa desconectado: o README diz que imagens vêm de Docker Hub e sandboxes usam provider configurado, Platinum por padrão. Dependências e entrypoint mostram caminhos de observabilidade como Sentry. Isso não demonstra envio de payload sensível, mas impede prometer ausência de rede sem configuração e tráfego verificados. Claims de soberania e SOC 2 Type I são do fornecedor; não foi inspecionado relatório de auditoria, escopo de controles ou cobertura do ambiente que o Lab eventualmente operaria.

Licença e white-label

LICENSE contém Elastic License 2.0, incluindo limitação a oferecer funcionalidade substancial como serviço hospedado/gerido e preservação de avisos. Portanto não é seguro traduzir a expressão open source do README em licença permissiva irrestrita. WHITE-LABEL-LICENSE.md é instrumento separado, anunciado como gratuito sob condição de usar Platinum exclusivamente no compute que ele oferece. Isso pode afetar comercialização e custo. A pesquisa não interpreta contrato como parecer jurídico nem afirma que o Lab já atende condições de concessão.

Plataformas e experiência

README apresenta web, desktop, mobile, CLI e canais como Slack/Teams/email, com mesmo estado compartilhado. Não foi verificada paridade de feature, instalação ou acessibilidade. A superfície central reúne sessões, outcomes, Drive, conectores e apps, ampliando a necessidade de mostrar quem atua e sob qual orçamento. Self-host é descrito como stack Compose, mas continua dependente de rede/configuração externa. No Lab, um futuro piloto deveria limitar-se a uma jornada e conta de teste, sem conectar serviços produtivos.

Manutenção e alternativas

A consulta encontrou release v0.14.17 de 3 de novembro e commit em atividade no mesmo dia. Arquivos lidos na branch dev e arquivo de entrypoint fixado em SHA podem ter janela diferente; blobs são identificados nas fontes. A amplitude de mudanças pede cuidado com documentação histórica. Comparado a Otto, o foco é time e cloud; comparado a AgentFlux, é plataforma empresarial mais ampla. O interesse no Lab é arquitetura e governança de execução, sem tomar declarações comerciais como provas.

Próximos ensaios propostos

Antes de adoção, fixar release e mapear licença, edição, serviços externos e custos. Em ambiente autorizado, testar trigger duplicado, sandbox suspenso, perda de callback, budget excedido, permissão negada e merge humano. Exercitar recuperação de repo/Drive/workspace em conjunto, isolamento de projetos e logs sem segredos. Conferir destinos de telemetria e conexão de assinatura. Nenhum ensaio ocorreu: não foram instalados CLI, Compose, sandboxes ou conectores, nem usados dados e credenciais privados.

Escopo declarado

O README descreve editor visual com 17 etapas preconfiguradas, templates, ramificações e importação/exportação JSON; agentes podem ser descritos em linguagem natural, receber fontes e modelo e rodar manualmente ou em agenda. Também anuncia importação de arquivos e conexões HTTP, pastas e programas aprovados. Isso delimita o produto como construtor/executor de fluxos na própria aplicação; não é controle genérico do desktop.

Execução e dependências

A instalação rápida documentada carrega duas imagens Docker e executa Compose; a release contém app, interface, FFmpeg e speech service local. A plataforma não inclui o modelo geral de linguagem/visão: exige apontar para Ollama, LM Studio, vLLM ou endpoint OpenAI-compatible e credenciais conforme o provedor. O speech model Whisper é componente separado incluído/cacheado em volume próprio. README fixa prebuild em Linux/amd64 e não testado em outros alvos; no Windows orienta Docker Desktop em modo Linux.

Análise de vídeo

O README do commit consultado e a release v0.3.0 afirmam que análise de gravações já está incluída no pacote Docker. O sistema analisa segmentos sobrepostos de um minuto com mudanças de tela, quadros periódicos e fala transcrita com Whisper local. Gravações são enviadas à própria instância e removidas após processamento/cancelamento; até 24 quadros selecionados por segmento vão ao modelo de visão, e áudio/imagem externos requerem autorização separada. Limites declarados: 250 MB/30 minutos, orçamento de chamadas/tokens, codec e ações breves podem impedir cobertura completa. Isso corrige a documentação da release anterior, que não incluía o recurso.

Dados, segredos e rede

O README diz que workflows, documentos, credenciais e logs ficam no volume agentflux-data e orienta backup integral, incluindo .vault-key; volumes são removidos com docker compose down -v. Gravação vai à instância AgentFlux e quadros são enviados ao modelo de visão escolhido, não se conclui que saiam diretamente do browser ao endpoint. O texto documenta aprovações para processamento externo de imagem/áudio e não estabelece política de retenção do modelo/provedor remoto.

Licença, distribuição e atualização

O repositório declara Apache-2.0. A release v0.3.0 distribui imagem prebuild, compose e checksums; o commit HEAD v0.3.0 tem verificação smoke própria descrita para API, interface e persistência ao substituir container, mas nós não repetimos a verificação. Checksum confirma integridade do artefato baixado frente ao valor esperado, não segurança, proveniência de build nem compatibilidade. Atualização deve comparar conteúdo empacotado, preservar volume/chave e manter caminho de retorno.

Pertinência ao Lab

É uma hipótese de bancada para transformar documentos e dados estruturados em fluxos revisáveis, com resultados e logs exportáveis. Pode ser comparado a ferramentas de knowledge/workflow, mas o modelo, conexões de rede, permissões de programas e configuração de volume teriam de ser delimitados antes de uso com material real. O preview de vídeo talvez facilite derivar procedimentos de uma gravação, mas sua cobertura amostral limita tarefas rápidas e não substitui observação humana.

Próximos ensaios

Em bancada isolada, medir instalação/reversão da release, portas publicadas, autenticação, limites de leitura dos diretórios conectados e o que efetivamente é persistido no volume. Usar documentos sintéticos e um vídeo com ações deliberadamente curtas e longas para conferir lacunas entre amostragem e workflow proposto; repetir com servidor de modelo local e remoto e capturar destinos/bytes. Nenhum ensaio, instalação, build ou execução do AgentFlux foi feito nesta pesquisa.

Pipeline de mídia e privacidade

O produto apaga gravações após processamento ou cancelamento segundo o README. Essa declaração não especifica todos os temporários, logs, dumps ou backups, portanto um ensaio deve localizar cada cópia e verificar remoção após caminhos de sucesso, erro e cancelamento. Volume de dados e volume de modelos de fala são separados e ambos precisam constar no plano de preservação/reversão; excluir apenas o container não os remove.

Estado da release e instalação

Consulta da API oficial do GitHub em 2026-11-03 identifica v0.3.0 publicada em 2026-10-30 e HEAD b197134d8f8062c744104b6759daae30fae82c70. A documentação desse commit aponta tarball de imagem Linux/amd64, compose e checksums; build do código pode conter novidades que não estão na release. O quickstart usa Docker Compose e abre localhost:4310; precisa-se revisar bindings de porta no Compose antes de assumir que só loopback aceita tráfego.

Formato de avaliação sugerido

Separar quatro coisas em uma avaliação: se a etapa de workflow executa; se os dados persistem após atualizar container; se a imagem enviada corresponde ao que o operador aprovou; e se o resultado do modelo é correto. Registrar commit, tag, arquitetura e hash de imagem; testar cancelamento durante ingestão e confirmar que arquivos de gravação temporários são removidos. Rodar ainda um caso com endpoint remoto e um caso sem rede para identificar degradação honesta.

Autenticação e dados em repouso

A instalação oficial liga 4310 a 127.0.0.1 e declara produto single-user sem autenticação/roles; para acesso remoto exige camada de controle de acesso. A documentação afirma AES-256-GCM para credenciais, com chave .vault-key no mesmo diretório do banco, enquanto documentos, workflows e logs não são cifrados. Portanto proteção de credenciais depende de proteger o diretório inteiro; backups devem guardar DB e chave juntos, e um vazamento do volume expõe conteúdo e credenciais. Estas são declarações de docs não verificadas em runtime.

Importações, conectores e redaction

Docs limitam upload a 12 MB por arquivo/response, 500 registros por import e 40 arquivos por pasta sem recursão; PDF exige texto legível e OCR não vem incluído. Pastas adicionais requerem allowlist de raiz e mount explícito, enquanto programas precisam de allowlist e habilitação. HTTP GET pode transmitir dados em URL/cabeçalhos ainda que cloud/POST exijam aprovações globais e por workflow. Redaction é regex/pattern matching, pode omitir informação ou alterar texto benigno, e exige revisão manual do que sai.

Produto e alegações

O README apresenta AutoBot como infraestrutura controlada pelo operador, com chat, base RAG, grafo de memória, gateway multi-LLM com fallback, governança, módulos e gestão de frota. Chama a solução de privada e compatível com requisitos de governança, mas também esclarece que não reivindica certificação de conformidade. Essas frases delimitam intenção e desenho declarado, não verificação independente de privacidade, conformidade, desempenho ou segurança.

Arquitetura e operação

A documentação descreve camadas Core, SLM e módulos. O quickstart distingue instalar o control plane SLM com shell privilegiado de subir Compose para avaliação/desenvolvimento; a própria página declara que o SLM não é a plataforma inteira e provisiona nós da frota. A arquitetura enumera frontend, backend FastAPI, Redis, PostgreSQL, ChromaDB, Ollama opcional, monitoramento e browser automation. Trata-se de um sistema distribuído com requisitos e estados de serviço distintos, não de um único binário local.

Provedores, dados e limites locais

O README oferece gateway para modelos locais e hospedados, com fallback configurável. A página de arquitetura enumera Ollama local e API OpenAI cloud como opções. Portanto self-hosting da plataforma não implica inferência local nem elimina transferências; isso depende dos papéis, fallback e endpoints configurados. A alegação de controle de dados deve ser verificada por captura de tráfego, configuração e logs em uma instalação isolada. Não foi avaliado código de cada conector nem política externa.

Escala, manutenção e sinais de risco

O repositório é de superfície excepcionalmente ampla, com documentação para deployment, funções de infraestrutura, governance, autenticação e múltiplos serviços. Uma issue pública arquivada descreve status de agentes retornando 503 em modo single_user por dependência de PostgreSQL e fragmentação entre registries; é um relato específico e datado, não prova do estado presente após correções. O registro de issues muito ativo e o volume de componentes aumentam custo de atualização, revisão e regressão. É preciso verificar branch/commit e changelog em vez de tomar issue isolada como estado atual.

Licença e custo total

O projeto declara Apache License 2.0. A licença não remove custos de servidores, GPU, armazenamento, backups, operação da frota, observabilidade e eventuais APIs de modelo. A própria tabela de requisitos separa control plane dos nós de plataforma, com requisitos mínimos diferentes. A noção de zero custo marginal de inferência local, presente na proposta modular, não inclui hardware nem suporte operacional.

Pertinência e próximos ensaios

Pode ser referência de arquitetura para separar agentes, serviços, memória e governança; para o Lab, a aderência funcional precisa ser reduzida a um caso verificável. Proposta de ensaio: revisão de um commit pinado, Compose de avaliação em rede isolada, autenticação/RBAC por perfil, coleta de destinos de rede, ingestão de documentos sintéticos e restauração de cada store. Avaliar também degradar quando Postgres/Redis/model gateway falham. Nenhuma instalação, execução de comandos sugeridos pelo projeto ou teste funcional foi realizado nesta pesquisa.

Modelo de implantação e risco de privilégio

README distingue control plane SLM da plataforma instalada nos nós e recomenda instalador de uma linha com sudo bash em host Ubuntu dedicado; alternativa Compose é rotulada como avaliação/desenvolvimento. Esse fluxo precisa de revisão de script e checksum antes de executar, porque ele opera com privilégio elevado e configura administração de frota. Não tratamos o comando de instalação no README como procedimento validado nem instalamos dependências.

Requisitos e custo de operação

O README separa requisitos mínimos: SLM 2 cores/1.5 GB/20 GB, plataforma 4 cores/8 GB/20 GB e recomendação 8+ cores/16+ GB/50+ GB, com Ubuntu/Docker mínimos distintos. Hardware é apenas uma parte do custo: múltiplas VMs, stores, backups, monitoramento, atualização de modelos e serviços de rede adicionam carga. GPU aparece como aceleração recomendada, não requisito absoluto em modo CPU.

Mudança de arquitetura e documentação

A visão de arquitetura consultada declara ser mapa central com data 2025-12-13, enquanto README/HEAD foram atualizados em novembro de 2026. Por isso, tecnologias descritas no architecture overview podem ser mapa histórico parcial e não substituem inventário atual de services/Compose. A diferença de datas é uma lacuna de documentação a reconciliar antes de confiar no diagrama para segurança ou planejamento.

Estado do projeto e reprodutibilidade

O HEAD consultado em 2026-11-03 foi 6f8c8d9f82df2bbeecbc0d3778396af38cec6a06; a API oficial lista releases até v0.10.0 (2026-09-28), portanto release tagged e main têm janela de desenvolvimento posterior relevante. Uma comparação deve piná-los separadamente, revisar migrações e registrar hashes de imagens/container. A issue #10511 é datada e marcada closed; ela motiva checagem de regressão no single_user, mas não sustenta alegação de bug atual.

Domínio e promessa

README descreve criação e execução de aplicações completas, APIs, automações, chatbot e agentes no mesmo cloudlet; endpoints podem ser publicados como ferramentas MCP. A camada de programação usa Hyperlambda e funções/slots ativos. O escopo combina ambiente de desenvolvimento, runtime web e plataforma de agente, em vez de ser apenas uma skill que escreve código. As comparações com Lovable, Bolt e automações concorrentes são posicionamento do autor.

Arquitetura e requisitos

README informa backend .NET 10, dashboard React/Vite/TypeScript e plugins .NET; banco SQLite por padrão com opções MySQL, PostgreSQL, MariaDB e SQL Server. Docker Compose publica backend na 4444 e frontend na 5555, com volumes separados para dados, configuração e módulos. Executar do código requer .NET 10 e Node LTS. A publicação gera uma superfície web e API que precisa ser tratada como serviço, não como script isolado.

Autenticação e exposição inicial

O quickstart usa root/root no primeiro login, tanto no Compose quanto em desenvolvimento local. Exemplo Compose publica as portas em todas interfaces por padrão; o README informa autenticação OIDC disponível, mas isso depende de configuração de client ID/secret por provedor. Antes de redear ou expor, operador teria de trocar credenciais iniciais e configurar identidade, TLS, segmentação e roles. Essas são observações de documentação/configuração, não tentativa de login ou varredura de endpoint.

Modelo de ameaça e segurança alegada

O mantenedor afirma sandbox do Hyperlambda, lista de funções permitidas por RBAC e validação server-side das chamadas de Chat Ops. A mesma documentação admite que usuários root podem gerar/executar Python ou terminal e criar extensões C#, e alerta contra expor endpoints que permitam execução arbitrária. A alegação de que funções inexistentes são recusadas não cobre erros lógicos, configuração permissiva, plugin malicioso, cadeia de dependências ou falhas do sandbox. A promessa de prêmio por vulnerabilidade não equivale a auditoria ou certificação.

Modelos, MCP e custos

Chat Ops mostra chave OpenAI e escolha de modelo; plugins Ollama/HuggingFace podem substituir inferência e busca BM25 local evita embeddings externos em chatbot. Busca semântica/híbrida continua podendo usar embeddings OpenAI. Uso via MCP pode dispensar chave OpenAI para o controle pelo cliente, mas não faz o servidor de ferramenta automaticamente offline. Custos incluem hardware/infra e APIs selecionadas; a expectativa de preço futura do gerador hospedado é declaração temporal do README.

Manutenção e releases

A página de releases lista mudanças frequentes; v24.4.11, datada de 2 de novembro de 2026 na página consultada, corrige tratamento de argumentos desconhecidos em auth.jwks. A cadência indica manutenção ativa, mas exige revisão de changelog, compatibilidade de dados e migrações antes de atualização. Releases recentes não demonstram que uma imagem específica esteja sem vulnerabilidades.

Licença e pertinência

O repositório declara MIT; isso é licença de código, não licença de dados, plugins externos nem serviço hospedado. Magic pode servir como laboratório para API e ferramenta MCP sob controle local, mas a amplitude de funções administrativas e execução dinâmica eleva os riscos. Pertinência ao Lab é hipótese: avaliar com código descartável, identidade segregada, rede sem exposição e sem credenciais/dados reais antes de qualquer uso continuado.

Próximos ensaios

Fazer revisão estática direcionada ao fluxo geração→validação→execução Hyperlambda, autenticação ticket/JWT e autorização de funções; testar papéis root/não-root e MCP com ferramentas permitidas/negadas; confirmar bindings de porta, CORS, persistência e atualização/reversão. Medir fluxos externos para OpenAI/embeddings e testar busca BM25 offline com corpus sintético. Nenhum serviço foi instalado, executado, explorado ou submetido a teste de segurança nesta pesquisa.

Caminho de geração e permissões

A documentação diz que o modelo produz AST/Hyperlambda e que chamadas não declaradas no contrato de função são recusadas; a autorização também é descrita como execução sob JWT e função com auth.ticket.verify. Isso restringe parte da chamada de ferramentas, mas não valida a semântica dos argumentos nem a correção do código gerado. O caso de uso inclui browser headless, acesso a banco e execução de scripts; cada integração amplia a capacidade real do agente e precisa de política menor privilégio.

Mudança e estado dos binários

HEAD consultado pela API do GitHub é fa8d220b12560856174f410932554a268fc2dd07; a release mais recente observada é v24.4.11 em 2026-11-02, com correção reportada de argumentos desconhecidos no plugin auth.jwks. README orienta puxar imagens latest no Compose, o que reduz reprodutibilidade; para validação deve-se usar tag/digest fixo e registrar migrations. O release note mostra correção de parser/auth, não uma avaliação global de segurança.

Leitura de desempenho e comparação

Afirmações no README de aceleração frente a FastAPI/Flask, LangChain e ferramentas visuais são medições do mantenedor, sem configuração e conjunto de carga suficientemente comparáveis no trecho consultado. Há badges de SonarCloud no README, mas não foram inspecionados ou correlacionados ao commit. Não usar tais números para dimensionamento sem replicar workload e hardware. Custo de chamadas do gerador hospedado e de embeddings deve ser apurado com preços correntes e estimativa de volume.

Produto declarado

README define Kanzo como board web e servidor MCP no mesmo programa. Humanos e agentes trabalham nas mesmas tarefas; comandos exportam board a Markdown/JSON, sincronizam por Git e permitem apontar cada agente ao projeto a partir do remote do repositório de trabalho. Isso descreve integração de tarefas, não orquestração de execução de código nem um agente autônomo embutido.

Dados e sincronização

A documentação situa kanzo.db e config.toml em ~/kanzo, alterável por --home/KANZO_HOME. A sincronização transforma a pasta em repositório Git e faz commit/pull/push; se ambos os lados mudaram, há opção de escolher conteúdo local ou remoto. A partilha recente é outro modo: uma instância hospeda board e clientes conectam-se. Repo privado protege transporte/controle apenas conforme configuração e identidade Git; conteúdo do board, anexos e comentários precisam ser considerados dados sincronizados.

Exposição de rede e acesso MCP

README mostra config listen=127.0.0.1 por padrão e alerta que 0.0.0.0 expõe board à rede sem login. Também documenta MCP sobre HTTP em /mcp e acesso de agentes ao board. A release v0.3.0 adiciona share/join para computadores diferentes. Antes de usar numa rede além da máquina local é necessário determinar quem pode alcançar a porta, se transporte é protegido e quais ferramentas MCP têm acesso; nesta pesquisa não tentei conexão ou autorização.

Plataformas e maturidade

Release v0.3.0 indica suporte nativo para Windows via instalador PowerShell e destaca compartilhamento entre máquinas. Página de releases lista versões 0.1.0 a 0.3.0, sinal de projeto recente com evolução rápida. O README anuncia medidas de memória/velocidade em Apple M4; são medidas do autor e não generalizáveis para hardware diferente. Não há evidência nesta pesquisa de backup/restauração comprovado nem de carga concorrente segura além da descrição de uso.

Licença e custo

A licença declarada é AGPL-3.0. O fato de ser gratuito para baixar não elimina obrigações ao distribuir versões derivadas ou oferecer a versão modificada pela rede; a avaliação jurídica do caso concreto requer examinar a licença integral. Há custo de operação do host e do repositório Git, mesmo com aplicação leve.

Pertinência e ensaio

Pode preencher um espaço simples de fila compartilhada entre agente e pessoa, com estado revisável fora da conversa. Antes de usá-lo como fonte autorizativa, avaliar concorrência, conflitos de sync, anexos e exposição MCP; comparar sua fronteira de confiança com um board convencional. Um ensaio seguro usa diretório descartável e repo privado de teste, sem dados reais, testa migração v0.2→v0.3, rede local segregada, conflitos e backup/restore. Nenhuma instalação ou execução foi feita aqui.

Permissões MCP e fronteira agente/humano

README especifica que os agentes podem pegar tarefas, mover cartões e comentar; um cartão marcado Human fica fora da fila de ação dos agentes. É uma separação útil, mas essa regra de produto só protege se toolset e servidor MCP estiverem alcançáveis pelos agentes pretendidos. Um board compartilhado não é fonte de verdade de execução: comentários e estados precisam de histórico externo e revisão humana quando forem usados como evidência.

Atualização automática e proveniência

README diz que o app oferece instalar nova versão no sidebar e em Windows limita o self-update ao caso de kanzo.exe no diretório bin referido. A documentação recomenda verificar downloads com gh attestation verify e apresenta releases assinadas pelo GitHub. Isso fornece mecanismo verificável de proveniência, mas não confirma que um artefato não foi modificado no host nem avalia conteúdo malicioso. Nenhuma attestation foi conferida nesta pesquisa.

Implementação e disponibilidade

Cargo.toml identifica implementação Rust e a página de release fornece binários Windows/macOS/Linux. O README lista board SQLite e config TOML, mas não especifica neste recorte criptografia, ACL por usuário, logs de auditoria, backup automatizado ou resolução avançada de conflitos. Ausência no recorte documental não prova ausência no código; esses pontos devem ser localizados e testados em source code antes de confiar dados sensíveis.

Reprodutibilidade de versão

HEAD capturado foi 862399f762e78149eccea38b0bcb82c53a3ffa93, um commit de dependências após a tag v0.3.0 e8740b778ccd6e5dfb169e76313bd001c52f9ecb. Logo, release publicada e HEAD de desenvolvimento não são o mesmo objeto. A avaliação deve piná-los separadamente, preservar binário/attestation e medir upgrade; anúncios de tamanho e velocidade (4.5 MB, ~1 ms em release) são do autor e não medições independentes.

Objetivo e método

README posiciona a skill primariamente para Claude Opus 5.5 em Claude Code e propõe planejar um filme com números, construir animação determinística e medir propriedades que o agente não consegue observar diretamente. Os formatos incluem HTML, Canvas, SVG, Three.js, GSAP e Remotion. Esta é uma metodologia de trabalho/instrução; não entrega modelo próprio, serviço de vídeo remoto nem shots prontos para reutilização.

Conteúdo e dependências

O inventário lista SKILL.md, templates de treatment/timeline/fatos/relatório, números de craft, catálogo de QA, rubric de crítica, scripts check_timeline.py e qa_video.py, três briefs de eval e metodologia baseada em oito repositórios. README requer ffmpeg/ffprobe e Python com numpy/Pillow; filmes HTML exigem Node, Playwright e Chromium ou Remotion; faster-whisper é opcional para narração. A lista de ferramentas define uma cadeia operacional que deve ser compatível e mantida no ambiente que renderiza.

O que os checks conseguem dizer

Os checks mencionados medem critérios como contraste/tamanho de texto, frame inicial, flashes, cortes, congelamento, costura de loop, loudness, silêncio e contato visual. Eles podem revelar defeitos mensuráveis, mas não certificam coerência narrativa, direitos de mídia, identidade de produto, fidelidade de briefing nem qualidade percebida integral. A própria skill distingue orientação e revisão humana; resultado automatizado precisa ser conferido em playback com áudio e contexto.

Evidência publicada

README relata três briefs por configuração, com 28/28 versus 25/28 assertions e preferência cega 2–1 em uma rodada, depois 30/32 versus 26/32 e 3–0 em outra; custo reportado inclui aproximadamente o dobro de tempo/tokens na primeira. O mantenedor observa que houve apenas uma execução por configuração, que character/illustrated/revision/live-page foram acrescentados depois sem avaliação e que comparação entre modelos não foi estabelecida. Esses limites impedem generalizar os resultados como medição robusta.

Portabilidade e licença

Instruções se concentram em Claude Code e recomendam um modelo nomeado, mas outros agentes de código podem seguir o workflow se disponibilizarem as ferramentas necessárias. A qualidade depende de ferramentas locais e modelo selecionado. Repositório declara MIT. Ausência de releases nomeadas indica distribuir diretamente o conteúdo versionado em Git; isso não elimina necessidade de pinagem de commit antes de avaliação reproduzível.

Pertinência e validação

Pode ser referência para transformar um brief audiovisual em tratamento, timeline, código reproduzível e pacote de QA. Para o Lab, o material útil seria a disciplina de critérios/relato, não assumir um modelo como padrão ou confiar em seus outputs sem conferência de fonte e produto. Avaliar em um único vídeo sintético com oráculo de tempo/texto/áudio, repetir configuração, comparar resultado cego e separar medição de aceitação estética. Nenhuma skill, dependência ou script foi instalado ou executado nesta pesquisa.

Gates do processo

README anuncia gates de etapa e skill descreve briefing, treatment, timeline, build contract e definição de pronto. Isso aumenta a rastreabilidade potencial: a validação da timeline ocorre antes da geração e a inspeção do MP4 após render. O gate só vale quando é executado, e um script sem erro não substitui conferência do vídeo/audio, fontes, direitos ou aceite de quem pediu o trabalho.

Reprodutibilidade e formatos de entrega

A abordagem determinística pressupõe controlar timebase, viewport, fontes, assets, versão de navegador, exportador e parâmetros do encoder. MP4 final sozinho perde editabilidade e relação com timeline; para repetir, guardar código, brief, timeline, dependências e relatório junto com o render. QA inclui contato sheets, loudness e silêncio; isso suporta inspeção, mas não certifica equivalência entre máquinas.

Licença e cadeia de ferramentas

O repositório declara MIT. Dependências mencionadas (Node/Playwright/Chromium, ffmpeg, Remotion, TTS, faster-whisper) possuem licenças e condições próprias, não cobertas automaticamente pelo MIT da skill. Incorporar música, fontes, gravações ou vídeos requer autorizações individuais. Nenhuma SBOM, pinagem de versões nem auditoria de licenças transitivas foi publicada no trecho consultado.

Estado e maturidade

HEAD pinado é 4747e5c153509ef7f8f7fd1a0aad6acfda36280d (30 out 2026 conforme API GitHub); a página de releases não lista releases. A avaliação então depende de clone/commit e não de artefato versionado assinado. README e metodologia são fontes mutáveis; para reprodução, registrar SHA, modelo exato e custo/tokens de cada sessão. A inexistência de release não implica inatividade ou defeito, apenas muda a garantia de distribuição.

Escopo declarado

README diz que Claude consulta prompts próximos ao briefing, escolhe mídia, escreve spec antes de codificar e captura screenshots para corrigir defeitos. Inventaria 40 prompts de exemplo, mais de 50 vídeos, 30 recortes 3D, 29 imagens e 55+ receitas. Há também template de spec, QA para assets quebrados/overflow/fontes/vídeo e modo de prompt para outras ferramentas. A expressão 'award-level' e a avaliação de que são exemplos mais apreciados são alegações do mantenedor.

Fluxo e ambiente

O repositório oferece instalação por Claude Skills upload, marketplace/plugin do Claude Code ou cópia manual. A etapa de screenshot requer code execution; Playwright/Chromium é recomendação opcional para look-and-fix. A skill não é gerador hospedado autônomo: depende de Claude, execução de código, navegador e fontes de mídia acessíveis. Prompts podem direcionar para imagens/vídeos externos e acrescentar rede/direitos/licenças à análise.

Direitos de prompts e mídia

README afirma que instruções e código são MIT, mas os prompts de exemplo e a mídia permanecem copyright da MotionSites; diz que mídia/prompts podem ser usados nos sites construídos com a skill. Trata-se de autorização declarada no README com escopo específico, não cessão geral para republicar, redistribuir ou treinar. Biblioteca premium e MCP são produtos separados, não incluídos integralmente no pacote gratuito. Para trabalho de cliente, conferir termos correntes e proveniência de cada asset.

Avaliação e limites

O processo de screenshots e rubric pode reduzir bugs visuais simples, mas não prova acessibilidade, compatibilidade cross-browser, legibilidade real, direitos de mídia nem conformidade com identidade de marca. Também pode reproduzir estilos de exemplos se o agente seguir referências sem supervisão. A própria finalidade de usar prompts próximos demanda rastrear o que veio de referência e o que é original. Não foi instalada nem executada a skill e não foi gerada página.

Versão e manutenção

A página de releases registra v1.0.0 em 26 de outubro de 2026 e fornece ZIP para upload/instalação por plugin. O README atual chama essa versão de pacote de distribuição. Main é móvel e pode divergir do ZIP de release; teste deve piná-los separadamente e comparar arquivos e termos. A existência de release não comprova a qualidade visual ou compatibilidade de skill em cada versão do Claude.

Pertinência ao Lab

Pode ser referência para brief visual explícito, biblioteca curada e loop screenshot→QA. Para mídia ligada a produto, o método precisa manter insumos aprovados e geometria real separados de referências de estilo, e assegurar licença de assets. As receitas podem acelerar protótipos de landing page, mas não autorizam publicar nem substituir revisão visual humana. Qualquer ensaio deve usar assets licenciados e página não publicada.

Dependências e fronteira de execução

Upload da skill no Claude desktop depende de code execution; Claude Code pode carregar plugin, enquanto Playwright/Chromium é recomendado para observar resultado. Isso introduz subprocessos, navegador, instalação de dependências e acesso à rede para puxar mídia. O fato de os arquivos principais serem markdown não significa que o workflow seja passivo quando executado: a permissão do harness e os destinos acessíveis permanecem determinantes.

Referências criativas e originalidade

O fluxo sugere escolher 2–3 exemplos próximos do catálogo para calibrar nível de detalhe; isso pode melhorar consistência, mas também induzir layouts derivados. A origem de prompt e mídia deve acompanhar o projeto, especialmente se a saída for comercial. A autorização descrita pelo autor para usar prompt/media em sites feitos com a skill não significa poder redistribuir a biblioteca ou incorporá-la em outro pacote de skill.

Estado do código e pacote distribuído

HEAD consultado foi faa30d512e3973e58675c72101a7ef42ed37ae83, posterior à publicação da v1.0.0 por poucos minutos/commits segundo datas da API. README recomenda release ZIP ou plugin marketplace, enquanto main é fonte mutável. Para avaliação reproduzível, registrar se foi usada v1.0.0 ou HEAD e comparar conteúdos; não atribuir a release comportamento observado apenas no branch.

Critérios de sucesso e riscos

Uma comparação útil mede defeitos objetivos (overflow, 404 de assets, fonte ausente, autoplay, controles móveis e tempo de carregamento) e apreciação cega de usuários, além de custo de geração. Evitar usar a pontuação proprietária de 'gallery-level' sem rubrica reproduzível. Confirmar também teclado, contraste, reduced motion, carregamento de vídeo sob banda limitada e desempenho móvel, dimensões pouco cobertas pela descrição resumida do README.

Produto e alegações

README descreve Hob como alternativa desktop a Claude/ChatGPT, capaz de preencher PDFs e trabalhar com documentos usando modelos open-weight e configurar modelo conforme computador. GitHub anuncia macOS, Windows e Linux e declara uso privado/offline. São afirmações do projeto; a página do código não prova que todo fluxo ocorre sem rede ou que qualquer máquina suporte o modelo sugerido.

Distribuição e plataforma

README distribui instaladores para Mac ARM64, Windows x64 e Linux x86_64 AppImage via latest release. Repositório apresenta árvore Electron e diretórios app/catalog/docs; isso indica aplicação desktop multi-plataforma. Release v0.2.6 publicada em 30 de outubro de 2026 inclui menu de chats para fixar, renomear, salvar como Markdown e excluir. v0.2.0 menciona ajuste de estado/handoff de conexões Calendar/Mail, não comprova quando ou como esses conectores foram adicionados. A existência de binários/releases não foi reproduzida nem verificada por assinatura neste trabalho.

Inferência local e fronteira offline

Para usar modelo local, os pesos e runtime precisam estar disponíveis; download do app/modelo e checagem de novos modelos usam a rede. Web access e conectores também criam tráfego quando ligados. Para operar offline, desligar Web access e connectors não equivale a bloquear rede durante download/update, nem substitui captura de tráfego para confirmar o comportamento. A documentação explicita exceções, embora Issue #12 tenha registrado dificuldade em selecionar disco de destino em 27 de outubro.

Dados e privacidade

A documentação detalhada afirma que chats e arquivos ficam na máquina e não há telemetria, com ressalva explícita de que Hob acessa a rede para downloads/verificação de modelos, Web access (busca, fetch por código e instalação de pacotes PyPI) e conectores. Isso é declaração do projeto, não confirmação dinâmica de que não há outros destinos de rede. A exposição também inclui dados enviados a serviços conectores configurados pelo operador.

Licença do software e modelos

O repositório declara MIT para o aplicativo. MIT não concede automaticamente direitos de redistribuição/comercialização dos pesos open-weight selecionados; cada modelo, runtime, documentos de exemplo e assets precisam de licença própria. 'Open-weight' tampouco significa dados de treino abertos ou ausência de restrições de uso. Não examinei catálogo completo de pesos nesta pesquisa.

Maturidade e manutenção

A release v0.2.6 demonstra entrega multiplataforma inicial; a página lista 208 commits no momento consultado. Métricas sociais não são sinal de confiabilidade. Issue #12 permanece aberta no momento da leitura e há uma release nova em 30 de outubro, o que aponta evolução rápida de setup/armazenamento, mas não permite deduzir a qualidade de suporte. Testar migração, exportação, destino de modelos e remoção antes de usar como arquivo durável.

Pertinência ao Lab

Pode ser útil como interface de estudo local de PDFs/documentos quando uma workstation consegue hospedar modelo adequado. Comparar a qualidade de extração, citações, tabelas, OCR e velocidade com o fluxo existente do Lab em corpus sintético, não com dados privados. Se houver Calendar/Mail, tratá-los como integrações independentes e revisar escopo de autorização antes de conectar contas. Nenhuma conexão foi configurada ou autorizada aqui.

Próximos ensaios

Fixar release e hash de instalador; verificar assinatura/proveniência, permissões e destinos de rede durante primeiro início, download de modelo, leitura de PDF e uso offline. Testar PDF textual, digitalizado, com tabelas e imagens; comparar respostas com fatos conhecidos e checar retenção/exclusão, exportação/backup e recuperação. Medir requisitos de RAM/GPU e uso de CPU, e rever termos/licenças dos modelos. Nenhum teste funcional, instalação ou inspeção do código foi feita nesta pesquisa.

Rede habilitada e plugins

Documentação detalhada do HEAD distingue uso local do tráfego externo: Hob conecta para baixar/verificar modelos, Web access pode consultar metabusca, permitir que código obtenha dados e instalar pacotes PyPI; conectores também ficam online. Para manter isolamento, Web access deve ser desligado e connectors ausentes ou restritos; isso não elimina tráfego de download/update antes da operação. O texto diz que chats/arquivos ficam na máquina e não há telemetria, afirmação do autor ainda não confirmada por inspeção de rede.

Execução de código, consentimento e dados persistidos

Docs descrevem confirmações antes de alterar arquivos, Undo por tarefa e sandbox para execução Python limitado à pasta do chat; lista de pacotes pode instalar via PyPI quando necessário. Isso cria uma área de confiança concreta: conteúdo e scripts no chat, pacotes de terceiros e filesystem do projeto. Remover Hob apaga app/modelos/chats/configurações segundo a documentação, enquanto arquivos criados permanecem na pasta de documentos; no Windows, modelos baixados em outra unidade demandam exclusão separada. Fazer backup e remoção devem cobrir cada caminho.

Problema de armazenamento e versão

Issue #12, aberta em 27 de outubro, registra que modelos iam para C: e falhavam quando faltava espaço; ela aparece aberta. A documentação do HEAD, datada de 30 de outubro, diz que Windows e Linux podem selecionar outro drive na configuração inicial. A discrepância pode refletir correção posterior ainda sem fechamento da issue; precisa validar no instalador 0.2.6. É um exemplo de por que issue e doc são evidências de momentos diferentes, não prova que o comportamento atual está resolvido.

Domínio e promessa

O autor apresenta o produto como alternativa aberta ao NotebookLM, com múltiplos provedores, conteúdo multimodal, respostas contextualizadas e podcasts de vários participantes. Essa é uma descrição do escopo pretendido, não uma comparação independente das capacidades atuais do concorrente. O valor observável da distribuição é reunir fontes, notas e configurações de modelos em uma aplicação que o operador pode hospedar e inspecionar.

Arquitetura e dependências

O manifesto exige Python entre 3.11 e 3.13 e declara FastAPI, LangChain, LangGraph, SurrealDB, Esperanto, content-core e podcast-creator. O compose separa SurrealDB do serviço de aplicação, que reúne interface, API e worker. Portanto o serviço web visível não representa sozinho a arquitetura: falhas de banco, fila e provedor podem ocorrer em camadas distintas e exigem diagnóstico específico.

Contexto e mecanismo de RAG

A classe Notebook recupera fontes e notas associadas por relações no banco. Listagens normais omitem corpos grandes; get_context solicita texto integral e reúne os insights das fontes para fluxos longos, inclusive podcasts. Isso demonstra montagem explícita de contexto, não uma garantia de que qualquer resposta usará recuperação vetorial adequada. O README distingue busca textual de vetorial; precisão, cobertura e citações continuam sem ensaio nesta pesquisa.

Processamento documental

São anunciadas fontes PDF, vídeo, áudio e páginas web. O compose revela opções de extração pesada: Docling pode adicionar OCR e imagens; Crawl4AI pode instalar Chromium local ou usar um servidor remoto. Essas opções podem baixar runtimes no primeiro início e guardar cache no volume. Convém separar PDF textual, digitalização, tabela e página dinâmica, porque funcionar para texto simples não comprova fidelidade dos demais caminhos.

Podcasts e provedores

O manifesto inclui podcast-creator. O README promete até quatro participantes e controle de roteiro. Custo de áudio inclui gerar roteiro e sintetizar vozes; aceitar um LLM para conversa não significa possuir TTS e STT no mesmo provedor. A matriz inclui serviços remotos e Ollama; Anthropic e Groq não oferecem embeddings nela. Operação local exige escolher cada papel. Qualidade em português, pronúncia e fidelidade ao corpus permanecem sem teste.

Persistência e recuperação

O compose mantém surreal_data para banco e notebook_data para aplicação, além de chave de criptografia de credenciais. O guia alerta que alterar a chave impede ler credenciais existentes e não há comando de rotação. Recuperação deve verificar originais, notas, configurações e segredos em cópias separadas. Reiniciar containers com volumes existentes não prova restauração em host novo; backups e chave juntos também permitem acesso às credenciais.

Identidade e exposição de rede

O guia descreve uma senha compartilhada, sem contas individuais, e CORS aberto por padrão. O compose publica 8502 e 5055 sem limitar à interface local; apenas SurrealDB é vinculado a 127.0.0.1. Também distribui chave de criptografia de exemplo conhecida. São fatos de configuração nesta revisão, sem exploração executada. A senha de acesso e a chave de criptografia cumprem funções diferentes; trocar somente uma não resolve a outra fronteira.

Criptografia e privacidade

O guia declara Fernet para credenciais e derivação PBKDF2-HMAC-SHA256 de 600 mil iterações. Isso não implica criptografia dos documentos, logs, backups ou proteção contra operador do host. O slogan de manter pesquisa privada depende de provedores e extração selecionados. Conteúdo enviado a API externa entra em outra relação de serviço. Não foi feita auditoria criptográfica ou inspeção dinâmica de tráfego, portanto nenhuma certificação de segurança é emitida.

Licença e custos

LICENSE contém MIT. Permissão do código não concede créditos de modelos, licença dos documentos nem computação gratuita. Há custos de hardware ou servidor, discos, backups, downloads e eventualmente APIs por texto, embeddings e áudio. A comparação comercial do README não substitui uma conta por carga real. Nenhuma estimativa mensal confiável foi produzida sem volume e combinação de provedores definidos; funcionalidades locais continuam consumindo recursos e manutenção.

Manutenção e versão

Foi fixado o HEAD consultado e lida a coleção de releases. A versão 1.15.0 relata novos provedores, correções de jobs e derivação de credenciais; isso é evidência de publicação e relato do mantenedor. Uma tag publicada e um HEAD posterior são objetos diferentes. Atualização deve preservar volumes e chave, testar migração e reservar retorno. As suítes e os ensaios mencionados no release não foram repetidos aqui.

Alternativas e pertinência ao Lab

StudyAI concentra estudo de slides e repetição espaçada; course2md transforma aulas gravadas em notas. Open Notebook está mais próximo de bancada de conhecimento e diálogo com fontes heterogêneas. Pode apoiar pesquisa e docência no Lab, sem substituir corpus canônico ou virar memória autorizativa de agentes. Uma resposta com citações continua sendo conteúdo a conferir. Adoção permanece hipótese até reduzir trabalho mantendo proveniência, recuperação e fronteiras de acesso.

Próximos ensaios

Um ensaio autorizado começaria com documentos sintéticos de fatos e lacunas conhecidos. Medir extração, citação, exclusão e reindexação, origem de chamadas de rede, bytes enviados e custo por pergunta ou minuto de podcast. Simular interrupção de worker e restauração completa em diretório isolado. Acessibilidade por teclado, português e erros precisam de uso real. Nenhum teste funcional, instalação, execução de terceiros ou alteração de infraestrutura foi realizado nesta pesquisa.

Problema e unidade de conteúdo

A unidade principal é a aula importada de PowerPoint, ligada a curso, slides e material de estudo. O autor anuncia leitura de texto, tabelas, gráficos, SmartArt, notas e fórmulas, com relatório de extração e marcação de imagens sem texto extraível. Isso é mais específico que um chat de documentos: o fluxo tenta manter o vínculo entre resposta, citação e slide original para permitir conferência pelo aluno.

Arquitetura do aplicativo

O package.json declara React, Vite, Dexie, MiniSearch, fflate, fast-xml-parser, KaTeX, ts-fsrs e Zod. Essas dependências são coerentes com interface estática, banco IndexedDB, busca textual, leitura de ZIP/XML, fórmulas e repetição espaçada. Exige Node22 ou posterior para desenvolvimento. Scripts distinguem build do aplicativo, CLI e tipos do Worker. A presença de testes no manifesto não significa que eles tenham sido executados nesta pesquisa.

Separação de IA

O entrypoint do Worker envia rotas de API ao backend e decide entre servir arquivos públicos ou exigir o proprietário para o site. O backend é um Durable Object nomeado owner. A entrada não é um proxy genérico de URLs. Assim, app de estudo e serviço opcional têm responsabilidades separadas. A confirmação de que nenhum pacote final realiza chamadas externas exige build e observação de rede, ausentes desta pesquisa.

Mecanismo pedagógico

O README descreve FSRS para flashcards, plano de exame orientado ao tipo de conteúdo e verificações de citações diretamente nos slides. A checagem de um trecho citado pode provar correspondência textual, mas não prova que a conclusão está correta ou que a nota sugerida é justa. Questões sobre fórmulas, provas e diagramas precisam de avaliação didática por conjunto conhecido, incluindo erro do modelo e perda na extração.

Plataformas e experiência

O fluxo documentado funciona em navegador e mostra interface responsiva, sem exigir conta para estudo. Arquivos antigos .ppt precisam ser convertidos, enquanto formatos baseados em OOXML são citados como entradas. O servidor de desenvolvimento usa porta estável para evitar que a biblioteca pareça desaparecer ao trocar origem. Leitura em celular, acessibilidade, apresentações grandes e limite de armazenamento são critérios de uso real ainda sem ensaio local.

Persistência e backup

Biblioteca, notas, cartões, exames e progresso ficam no IndexedDB da origem exata. Outro navegador, perfil ou porta representa outra biblioteca. Exportação ZIP é o mecanismo documentado de transporte e backup. SECURITY esclarece que o aplicativo não criptografa dados locais em repouso e não pretende resistir ao controle do perfil ou dispositivo. Logo local-first reduz dependência de backend sem constituir cofre para conteúdo privado.

Provedor e orçamento

O tutor foi desenhado para Gemini free tier e Cloudflare gratuito. O documento financeiro diferencia confirmação humana de verificação: o proprietário precisa conferir o estado de cobrança. Antes de cada chamada há gate, limites, reserva de pior caso e liquidação do uso. Timeout ou resposta inconclusiva conserva a reserva até reconciliação. Essas regras representam desenho defensivo relatado, não garantia nossa contra cobrança em toda condição de conta ou plataforma.

Dados enviados e segurança

O autor documenta prévia do conteúdo que sai do dispositivo, chave somente no Worker, cookies assinados, CSRF, checagem de hosts e validação de ZIP/XML e JSON. O tutorial alerta que conteúdo de faixa gratuita pode ser usado pelo provedor para melhoria de produtos. São fronteiras distintas: evitar chamadas por padrão não altera termos do serviço quando o usuário liga o tutor. Material confidencial requer decisão própria antes de qualquer envio.

Licença, terceiros e manutenção

LICENSE é MIT; package.json registra versão0.1.0 e licenças de dependências são remetidas pelo README a avisos separados. A coleção de releases estava vazia na consulta; isso não prova abandono. SECURITY declara suporte apenas ao main mais recente, sem garantia de prazo ou recompensa para relatos. Fixar o commit é especialmente importante nessa fase: atualizar pode trazer alterações de formato e comportamento sem uma linha de releases estáveis.

Alternativas e custos reais

Open Notebook cobre fontes variadas e podcasts; course2md começa em vídeo. StudyAI faz sentido quando o insumo principal é slide e o resultado desejado é revisão estruturada. Sem IA, continuam existindo custo de dispositivo, tempo e backup; com IA, há limites e condições de terceiros. Pacotes produzidos por uma assinatura de agente não dispensam revisar conteúdo e direitos. Não foi estimada economia nem superioridade pedagógica em relação a Anki ou estudo manual.

Pertinência ao Lab

A hipótese mais clara é apoiar materiais de docência que já têm apresentações e exigem provas de citação. Pode inspirar separar estudo local de funções opcionais de IA e mostrar lacunas da extração ao usuário. Não foi adotado como plataforma, nem conectado a aulas reais. Conteúdo importado, pacote de estudo e saída de modelo permanecem dados não confiáveis para um harness; nenhum deles deve virar instrução de autoridade.

Próximos testes

Em bancada autorizada, montar PPTX sintético com equações, notas, tabela, gráfico, SmartArt e texto em imagem. Conferir extração e vínculo ao slide; importar pacote com citação falsa e questão incoerente; exportar e restaurar ZIP em outra origem. Inspecionar rede com tutor desligado e ligado, testar orçamento inconsistente sem modelo real e verificar teclado e leitor de tela. Só depois avaliar material docente real e eventual serviço externo.

Domínio e saída

O produto promete transformar aulas gravadas em notas com uma imagem por slide e transcrição associada, salvas em course.md e arquivos de imagem. O leitor oferece resumo, índice, busca e exportações HTML, ZIP e JSON. O benefício principal é manter artefatos comuns, editáveis e guardáveis fora da interface; isso não garante que toda mudança visual represente um slide nem que as palavras estejam alinhadas ao instante correto.

Arquitetura e revisão

Cargo.toml e docs/CRATES descrevem workspace Rust dividido por responsabilidade; o pipeline está na engine e a configuração inclui captura, transcrição e LLM. A separação permite compartilhar motor entre CLI e desktop, mas não comprova paridade de todas as opções. O HEAD consultado corresponde à reorganização3.0.0-alpha.1. A release reconhece aceite ainda incompleto; portanto comportamento de main não deve ser apresentado como versão estável já validada.

Pipeline de slides

O template expõe similaridade, intervalo de amostragem, cooldown, modo first ou stable, tempo de estabilidade e região de interesse. Esses controles mostram que captura depende de comparação temporal e parâmetros, não de interpretação infalível do slide. Animações, câmera do professor, tela compartilhada e pequenos incrementos podem exigir ajustes. A qualidade precisa ser julgada por omissões, duplicações, legibilidade e alinhamento com a fala em um vídeo conhecido.

Fala, legendas e modelos

A configuração distingue transcript_source auto, subtitle e asr. Auto prefere legendas; ASR admite CoreML, GPU, CPU, NPU e API, com compatibilidades de modelo próprias. O README menciona modelos entre cerca de1 e2,4GB e dependências específicas. Escolher NPU não garante que um modelo arbitrário carregue. A release2.0.1 relata correção desse caminho com Whisper no Intel NPU; trata-se de relato versionado, sem execução nossa.

IA e provedores opcionais

O template oferece ASR em API compatível com OpenAI, modo de transcrição ou chat, endpoint e chave. LLM é separado e controla revisão, resumo, visão, concorrência e tradução. Assim um operador pode transcrever localmente e ainda transmitir texto ou capturas ao ligar a revisão. Compatibilidade de endpoint não equivale a todos os recursos do provedor; visão e formatos de resposta precisam de teste. Custo cresce com áudio, tamanho do texto, imagens e repetição de chamadas.

Plataformas e ferramentas

O README descreve desktop macOS Apple Silicon, Windows x64 e Linux x86_64, com limitações distintas para Intel Mac e Linux ARM64. A distribuição desktop inclui ferramentas de vídeo; CLI pode depender de ffmpeg, yt-dlp, aria2 e llama-server. Em Windows, reconhecimento GPU/CPU pode exigir runtime Visual C++. Os pacotes não foram baixados nem executados; compatibilidade anunciada não é prova de funcionamento no host do Lab.

Downloads e contas

O autor afirma perguntar antes de baixar modelo; em scripts sem terminal o comportamento documentado é interromper, salvo autorização explícita por flag ou variável. Para plataformas online existem login Bilibili e leitura de cookies de navegador pelo yt-dlp. Essas funções tratam credenciais e podem afetar a conta; não fazem parte desta pesquisa. Espelhos de modelos e localização automática também podem alterar destinos de rede e precisam de inventário antes de uso.

Persistência e continuidade

A biblioteca mantém notas e imagens em diretórios escolhidos, com tarefas pausáveis e retomáveis. CLI e desktop compartilham alguns logins e modelos, mas preservam configurações próprias. O README alerta que a biblioteca2.0 não lista automaticamente todas as notas1.x, embora arquivos permaneçam legíveis. Isso separa preservação dos bytes de continuidade da interface. Recuperação deve conferir mídias, capturas, metadados, configuração e capacidade de reabrir as notas sem o aplicativo.

Segurança e privacidade

Reconhecimento local reduz envio de áudio, mas URL online, cookies, atualização, modelos e APIs opcionais continuam criando rede e superfícies de confiança. A release relata retirar chaves de logs de trace e evitar repetição de solicitações pagas em retomadas. Isso é evidência de correção declarada no objeto, sem certificação geral. Capturas podem incluir dados de outras janelas; um vídeo privado não se torna seguro somente por gerar Markdown local.

Licença e custo

LICENSE contém MIT. Ferramentas empacotadas, modelos, vídeos, plataformas e serviços têm condições próprias; a licença do conversor não concede direitos sobre aulas ou downloads. O custo pode ser computação local, disco para vídeo e modelos, banda, energia e APIs opcionais. Nenhum valor recorrente foi estimado. Uma assinatura mencionada pelo autor não significa que o Lab tenha rota ou uso incluído para integração automática; isso exige verificação e autorização específica.

Alternativas e Lab

StudyAI começa no PPTX e oferece estudo ativo; Open Notebook organiza fontes variadas e conversa contextual. course2md é mais útil antes dessas etapas, ao transformar gravações em artefatos portáveis. A hipótese para docência é produzir rascunho com imagens e tempo, preservando vídeo como origem. Não substitui revisão editorial e didática. Adotar a pipeline exigiria mostrar que economiza esforço sem apagar dúvidas da transcrição ou reconstruir fórmulas erradas com aparência convincente.

Próximos ensaios

Usar vídeo sintético com slides estáticos, animação, quadro, fórmula, silêncio e vocabulário português conhecido. Comparar legenda e ASR, medir capturas perdidas ou repetidas e erro de alinhamento. Interromper a tarefa e observar retomada sem repetir requisições pagas. Gerar Markdown e HTML e reabrir em máquina isolada. Rede, credenciais, custo e exclusão devem ter testes separados; nenhum login, download, conversão ou benchmark foi feito nesta pesquisa.

Produto e foco efetivo

CONFIRMADO: o README apresenta editor, terminal, depurador, Git e clientes HTTP/banco em uma aplicação desktop inspirada no fluxo IntelliJ. RELATADO: a cobertura anunciada passa de sessenta linguagens. Essa frase agrega níveis diferentes de suporte, como gramática, realce, servidor de linguagem e integração específica. A utilidade deve ser avaliada por linguagem e tarefa; sem execução, não se afirma que refatoração, inspeções e build tenham a profundidade do IntelliJ IDEA.

Arquitetura observável

CONFIRMADO: Cargo.toml organiza um workspace com crates ide-core, ide-vfs, ide-text, ide-index, ide-lsp, ide-dap, ide-host, ide-agent e outros. A interface usa React, CodeMirror, Zustand e xterm; Tauri oferece a ponte de comandos para Rust. É uma arquitetura híbrida, embora a apresentação diga reconstruída em Rust. A separação de host, protocolos e UI é material para estudo de fronteiras e tipagem IPC no AOS, sem significar compatibilidade automática.

UI versus capacidade implementada

CONFIRMADO: commands/lsp.rs exporta comandos de conclusão, hover, navegação e edições que delegam para ide_host::ops::lsp. Isso demonstra caminhos de implementação além de menus. A existência dos comandos não prova comportamento correto em todo servidor, timeout ou documento grande. Deve-se evitar tanto classificá-lo apenas como clone visual quanto tratá-lo como substituto maduro de uma IDE estabelecida; cobertura funcional permanece NÃO IDENTIFICADA neste levantamento.

Dependências e extensibilidade

CONFIRMADO: os manifests incluem tree-sitter, redb, tokio, gix, portable-pty e clientes de rede e bancos. O workspace exclui sdk e plugins do build principal porque esses usam workspaces próprios para wasm32-wasip2. O SDK e os plugins sugerem uma superfície extensível, mas o contrato completo de permissões não foi auditado. Compilar exige toolchain Rust e frontend compatíveis com os manifests; não se deve deduzir simplicidade de manutenção apenas do tamanho do instalador.

Plataformas e distribuição

CONFIRMADO: a release v0.1.35 lista pacotes Windows, macOS e Linux. Existência do artefato publicado não demonstra inicialização no host do Lab. RELATADO: a issue1089 registra falha de inicialização em RPM no Wayland; é um relato individual, não resultado reproduzido aqui. A seleção de um pacote deve considerar arquitetura, assinatura, dependências do webview e caminho de atualização, mantendo a entrada nativa das ferramentas atuais.

Persistência e integrações

CONFIRMADO: o desenho inclui indexação, filesystem virtual e bibliotecas de banco e HTTP. O terminal e os comandos de agente ampliam o alcance para processos externos. Os locais exatos de caches, credenciais, históricos e dados de projeto não foram inventariados nesta amostra, portanto permanecem NÃO IDENTIFICADOS. Para o Lab, essa lacuna importa mais que abrir uma tela: um ensaio precisa acompanhar escrita no projeto e no perfil e identificar tráfego por integração.

Segurança e dados

Análise: IDEs executam builds, extensões, servidores de linguagem e agentes sob o usuário. Um projeto aberto pode conter scripts e configuração não confiáveis; a leitura de um repositório não concede autorização de executar esses elementos. A presença de DOMPurify no frontend é uma dependência observada, não certificado contra injeção. O conjunto completo de permissões de plugins e a proteção de segredos no caminho de agentes permanecem NÃO IDENTIFICADOS. Só projetos sintéticos seriam adequados a um futuro ensaio inicial.

Benchmark e comparabilidade

RELATADO: o autor mede abertura do projeto freqtrade com caches aquecidos, cinco execuções e hardware Windows específico. O próprio README ressalva análise Python mais profunda no IDEA e significados diferentes de pronto. Logo, os números publicados são evidência da metodologia descrita, não prova de equivalência de trabalho ou ganho para o Lab. Um comparativo útil precisaria fixar commit, arquivos, diagnósticos concluídos, memória de todos os processos e operações editáveis idênticas.

Licença, custo e manutenção

CONFIRMADO: LICENSE é Apache2.0 e há inventário THIRD_PARTY_LICENSES.md para componentes de terceiros. A licença do projeto não elimina obrigações desses componentes ou custos de provedores usados em agentes. O SHA consultado e releases mostram trabalho público recente; issues PHP sobre nível de linguagem também mostram lacunas concretas. Não foi identificado SLA, suporte contratado ou teste de migração. Popularidade e velocidade de commits não substituem estabilidade observada.

Alternativas e pertinência ao Lab

Análise: a comparação funcional apropriada envolve IntelliJ IDEA para profundidade de linguagem, VSCode/VSCodium para ecossistema e Zed para outro desenho de editor. São referências de comparação, sem avaliação atual dessas alternativas. OpenIDEA pode ensinar organização modular e APIs de UI/host. O Lab já exige compatibilidade nativa e preservação de configuração; portanto o aproveitamento documental é imediato, enquanto uma troca de IDE exigiria contrato e evidência próprios.

Próximos ensaios verificáveis

Proposta, sem execução autorizada neste relatório: usar um projeto descartável com testes conhecidos, medir inicialização fria e quente e verificar conclusão, goto, rename, depuração, terminal e diff. Depois registrar arquivos tocados, tráfego, cancelamento e atualização/rollback. Comparar uma linguagem principal por vez e testar perda de servidor LSP. O critério deve ser a tarefa concluída corretamente com dados preservados, e não semelhança da interface ou ausência de crash em uma abertura.

Produto e escopo

CONFIRMADO: o README mostra importação de Button e Switch como componentes React com estilos incorporados. A árvore inclui input, menu, slider, segmented-control, search-field e tab-bar. RELATADO: a descrição apresenta fidelidade ao Liquid Glass da Apple; esse é um posicionamento do autor, não certificação da Apple ou teste perceptual independente. O pacote é uma camada visual/interativa para aplicações, não um framework completo, backend, sistema de design universal ou motor de criação de telas.

Mecanismo visual real

CONFIRMADO: lens.ts constrói mapas de deslocamento a partir da geometria da lente; refraction.ts calcula a borda luminosa usando canvas2D e disponibiliza filtros SVG. CSS aplica blur, saturação e backdrop-filter. Portanto chamar o projeto simplesmente de shader WebGL seria impreciso. O mecanismo combina JavaScript, bitmap gerado, SVG e CSS, com custo dependente da área filtrada e do movimento. As observações sobre Safari no código pertencem ao autor e não foram medidas neste host.

Compatibilidade de navegadores

CONFIRMADO: refractsBackdrop detecta Chromium pelo user-agent para escolher o caminho do backdrop. Comentários em lens.ts registram peculiaridades de unidades e invalidação de filtros no WebKit, além de custo alto para conteúdo grande em movimento. Isso sustenta uma distinção de caminhos de implementação, sem garantir cobertura de cada versão do navegador. Firefox, mobile, webviews embutidos e modos de economia precisariam de matriz de teste própria; uma demo no desktop não resolveria essa dimensão.

Arquitetura e dependências

CONFIRMADO: package.json define módulos ESM/CommonJS, tipos TypeScript e React/react-dom como peerDependencies a partir de18. Os componentes compartilham helpers de controle, press, hold, spring, lens e classes. Não foi identificado serviço remoto obrigatório no desenho do pacote. A build usa tsdown e a validação declarada usa TypeScript e Vitest. Esses scripts demonstram intenção de manutenção e distribuição, não execução dos testes nesta pesquisa.

Interação e estado

CONFIRMADO: Switch aceita checked, defaultChecked e onCheckedChange; o helper compartilhado suporta uso controlado e interno. O componente trata pointer capture, gesto horizontal, rolagem vertical, clique e cancelamento e encerra animações/listeners no cleanup. Há complexidade relevante em conciliar toque e scroll: o resultado deve ser testado em dispositivos reais. A API não persiste preferências automaticamente; a aplicação consumidora continua responsável por salvar dados e decidir efeitos de cada mudança.

Acessibilidade observável e lacunas

CONFIRMADO: o Switch termina em button com role switch e aria-checked, enquanto a decoração fica aria-hidden. O exemplo do README fornece aria-label; rótulo continua responsabilidade do consumidor. O CSS contém focus-visible e uma media query prefers-reduced-motion. Isso é evidência de mecanismos, não prova de WCAG. Permanecem NÃO IDENTIFICADOS o contraste em fundos variáveis, leitores de tela, zoom elevado, forced-colors e a redução efetiva de todas as animações JavaScript.

Performance e persistência

Análise: mapas dependem de dimensões, densidade e tema; o código mantém cache de bordas e observa resize e alterações de tema. A combinação pode evitar recomputações, mas o custo agregado de muitas lentes requer medição. Filtros sobre conteúdo extenso e animação contínua podem competir com tarefas principais. Não há banco ou armazenamento de usuário identificado no pacote; o estado observado vive em componentes, mapas de cache e DOM. Persistência de negócio pertence ao app.

Segurança e privacidade

Análise: uma biblioteca de apresentação que roda dentro do app herda acesso do JavaScript da aplicação ao DOM. Ausência de API externa obrigatória não é auditoria de cadeia de dependências ou de distribuição npm. Não se identificou autenticação ou sistema de permissões porque essa função está fora do foco implementado. Antes de usar no Lab, seria preciso conferir versão publicada contra o código revisto, lockfile, conteúdo distribuído e efeitos de políticas CSP sobre filtros e imagens geradas.

Licença, distribuição e manutenção

CONFIRMADO: LICENSE é MIT e package.json informa versão0.5.0. A coleção de releases do GitHub consultada veio vazia; isso não implica ausência de publicação npm. As entradas abertas consultadas são PRs sobre controle de Menu, homepage e scheduler de springs, não defeitos reproduzidos aqui. A PR4 descreve interferência de frame pendente com fake timers; é um alerta de teste e lifecycle, sem atribuir automaticamente falha visível a usuários.

Alternativas e aplicações no Lab

Análise: CSS nativo com uma camada sólida, controles HTML e primitivas de acessibilidade oferece um comparador mais simples. Outras bibliotecas de componentes podem ser comparadas por contrato e semântica; não foram auditadas neste recorte. Para o AOS, Glisse interessa sobretudo como estudo de filtros, limites de webviews e interação tátil. A decisão estética continua do Pai e do design do projeto: o efeito não autoriza substituir bordas e geometria canonizadas do Blog.

Próximos ensaios

Proposta: criar uma pequena tela sintética separada com switch, menu, campo e slider sobre fundos claros, escuros e complexos. Medir frame time e memória em Chromium, Safari/WebKit e Firefox, com áreas grandes e várias lentes. Percorrer tudo por teclado e leitor de tela, testar zoom, scroll touch, disabled e reduced-motion. Comparar com a versão sólida, registrar legibilidade e verificar desmontagem. Nenhum desses ensaios foi executado; o pacote permanece candidato documental.

Produto e foco

CONFIRMADO: o programa recebe URL ou arquivo, mantém uma webview executando e encaminha console para stdout e exceções para stderr. O modo console lê instruções do stdin e aguarda promessas. O objetivo é usar capacidades de página como DOM, áudio ou WASM em scripts e processos duradouros. Não é um servidor web nem um navegador completo com ecossistema de automação equivalente ao Playwright. Suporte a cada API depende também do motor e da plataforma.

Arquitetura e runtime

CONFIRMADO: go.mod usa tractor.dev/webframe e redireciona glaze para progrium/glaze; purego é dependência indireta. O runtime utiliza o webview já instalado, em vez de empacotar Chromium. A API exige criação e loop principal na goroutine apropriada e expõe callbacks de carregamento, erro e término. O binário pequeno desloca complexidade para bibliotecas do sistema e sessão gráfica; portabilidade de build não significa comportamento idêntico entre os três motores.

Plataformas e implantação

RELATADO e documentado: macOS usa WebKit, Windows precisa WebView2 e Linux precisa WebKitGTK e display ou Xvfb; quando não há display o programa pode criar Xvfb privado. O target musl tem exceção de build com cgo/zig. Há Dockerfile Alpine com usuário não root e sandbox WebKit mantida segundo o projeto. Nada foi instalado. Para o host Windows do Lab, a presença efetiva do runtime e o acesso à sessão desktop continuariam gates próprios.

Controle e ciclo de vida

CONFIRMADO: flags permitem script após load, injeção anterior aos scripts da página, timeout, saída no primeiro erro, janela opcional e inspector. A página pode chamar webframe.exit e fechar o processo; sem timeout uma tarefa pode continuar indefinidamente. A documentação admite que falha inicial de navegação não é reportada no Windows. Assim, scripts que dependam de um status de saída precisam considerar plataforma, timeout e assertivas de conteúdo, sem inferir sucesso pelo silêncio.

Persistência e permissões

CONFIRMADO: a opção privada mantém cookies, cache e storage somente em memória, conforme README e contrato da CLI. Sem essa opção não se assume ausência de persistência. Variáveis selecionadas por -E ficam em webframe.env e podem ser lidas por todo script da página, inclusive terceiro. Expor uma variável explicitamente não torna seu destino confiável. O escopo de permissões nativas, navegações subsequentes e recursos de rede deve integrar qualquer ensaio antes de dados sensíveis.

Scripts, CSP e limites

CONFIRMADO: scripts de inicialização executam no frame principal e se repetem após navegação; scripts após load seguem ordem e podem definir saída. O README descreve limitações de eval sob CSP e mensagens reduzidas de erro em file e scripts de outra origem sem CORS. O método de injeção é ferramenta poderosa de instrumentação, mas não demonstra política imutável contra a própria página. O Lab não deve tratar resultado de JS remoto como prova incontestável de integridade.

Isolamento não comprovado

RELATADO: issue9 pede mundos de script isolados porque código de página e hooks compartilham contexto; issue6 descreve forja de resultados pela ponte com identificadores previsíveis. São relatos públicos abertos, sem reprodução ou exploração nesta pesquisa. A implementação consultada e esses relatos impedem qualificar a ferramenta como fronteira robusta para código hostil. Um sandbox do motor e um canal confiável de observação são propriedades distintas, e nenhuma foi auditada integralmente aqui.

Desempenho e visibilidade

RELATADO: o README afirma desativação do throttling em todas as plataformas e página vista como visível mesmo com janela oculta. Isso é útil para animação e workers, mas pode consumir CPU continuamente e divergir de uma aba em background real. Não houve benchmark independente de temporizadores, energia ou GPU. Para QA, uma página oculta com viewport real não mostra ao Pai a experiência visual nem cobre redimensionamento, input nativo, foco e interação assistiva.

Licença, custo e manutenção

CONFIRMADO: a licença é MIT e a release v0.2 documenta mudança de exposição automática de variáveis WF para seleção explícita. O histórico registra evolução recente do contrato, inclusive riscos corrigidos segundo release notes. Uso pode exigir espaço e manutenção das bibliotecas do sistema ou imagem Docker, embora não haja assinatura identificada no repositório. Compatibilidade, auditoria de binários e suporte sustentado permanecem NÃO IDENTIFICADOS; a existência de release não garante esses itens.

Alternativas e pertinência ao Lab

Análise: Playwright, um navegador de QA e uma aplicação nativa baseada em webview são comparadores de funções, não substitutos perfeitamente equivalentes. webframe simplifica execução de páginas próprias e extração de console, enquanto uma ferramenta de browser oferece outros contratos de automação. No Lab, pode apoiar smoke tests sintéticos e investigação de WebView2. Não muda o gate de exibição real no browser in-app nem autoriza contornar bloqueios ou abrir perfis pessoais.

Próximos ensaios

Proposta: página local sintética que grava, restaura, lança erro, navega, usa timeout e retorna conteúdo conhecido. Comparar o contrato no Windows e Linux, verificar saída em falha de load, persistência com e sem modo privado, CPU oculta e cancelamento. Investigar issues de integridade antes de aceitar resultados de páginas não confiáveis. O ensaio deve usar variáveis falsas, nenhum cookie pessoal e orçamento de tempo limitado; todos os resultados funcionais continuam NÃO IDENTIFICADOS neste levantamento.

Produto e escopo

CONFIRMADO: trata-se de cliente de administração e consulta, não de um novo servidor de banco. O README anuncia workspace SQL, histórico, favoritos, grade virtualizada, diagrama ER, edição de estrutura e exportação. São funções com diferentes níveis de efeito: observar resultado, modificar uma célula e aplicar DDL não têm o mesmo risco. A simples abertura do cliente não seria um ensaio suficiente para aceitar todos esses contratos no Lab.

Arquitetura e protocolos

CONFIRMADO: React, CodeMirror, ReactFlow e Tauri compõem a interface; Rust concentra drivers e comandos. Há módulos para PostgreSQL, MySQL, SQLite, DuckDB, MongoDB, Redis, ClickHouse, LibSQL, MSSQL e Cassandra. A lista de treze produtos anunciados compartilha protocolos: AzureSQL usa TDS, ScyllaDB usa CQL e Turso usa pipeline HTTP. Quantidade de nomes não significa treze implementações independentes nem cobertura integral das variantes de autenticação e tipos.

Dependências e plataformas

CONFIRMADO: o README e Cargo manifestam drivers tokio-postgres, sqlx, tiberius, scylla, mongodb, redis, duckdb e reqwest. Existem pacotes para macOS, Windows e Linux e caminho de preview somente frontend. Esse preview não comprova conexão nativa: a abstração de repository admite ambientes com transporte diferente. O README também menciona sshpass para autenticação SSH por senha. Os requisitos de secret service, TLS e runtime precisam ser conferidos por sistema antes de uma avaliação funcional.

Persistência e segredos

CONFIRMADO: credentials.rs usa keyring e o serviço com.veloxdb.app para senhas por conexão e chave OpenRouter. Há funções de armazenar, recuperar e apagar credenciais. Isso comprova intenção de usar cofre nativo, mas não auditoria de permissões, disponibilidade do serviço ou ausência de cópias em logs e estado. O README anuncia restauração de abas, rascunhos e diagramas; localização e criptografia dos demais dados persistidos permanecem NÃO IDENTIFICADAS nesta amostra.

Conexões e transporte

RELATADO: a documentação oferece SSL/TLS, CA customizada e túneis SSH; os modos incluem desabilitar, preferir ou exigir. Não se deve chamar toda conexão de criptografada apenas porque o programa suporta TLS. O relato aberto64 descreve falha de conexão AzureSQL; não foi reproduzido. Um futuro teste precisaria diferenciar certificado inválido, hostname, autenticação, tipos numéricos, timeout e reconexão por motor, com servidores e credenciais sintéticos.

IA e fronteira de dados

CONFIRMADO: commands/veloxy.rs lê schema e chaves estrangeiras, monta prompt com nome de banco, engine, tarefa, histórico recente e contexto e chama endpoint chat/completions a partir da configuração OpenRouter. Há armazenamento da chave no keyring. Portanto a frase promocional sem cloud não pode ser generalizada ao caminho opcional de IA. Retenção no provider, roteamento para modelo e custo por token não foram identificados; prompt e esquema podem conter informações confidenciais mesmo sem linhas da tabela.

Lint e escrita sem confirmação

CONFIRMADO: lint.rs, no código consultado, concatena EXPLAIN ao SQL e chama simple_query no caminho PostgreSQL; SQLite usa EXPLAIN QUERY PLAN com sqlx. RELATADO: PR66 aberta descreve execução de instruções adicionais e caminhos Ask Veloxy sem confirmação, propondo correção. A presença da proposta não demonstra correção incorporada ao SHA. Não houve execução de SQL, tentativa de exploração ou auditoria completa. O achado impede recomendação de conexão com bases reais nesta fase.

UX e acessibilidade

RELATADO: o README anuncia atalhos, paleta, temas e internacionalização. A arquitetura com grid virtual e canvas oferece recursos úteis para volume e modelagem, mas a navegação por leitor de tela, seleção por teclado e associação de relações no diagrama não foi testada. Preview de migração é boa superfície de revisão, desde que a execução corresponda ao texto exibido. Não se inferiu que toda escrita exige confirmação nem que histórico restaura corretamente depois de falha.

Licença, custos e manutenção

CONFIRMADO: LICENSE é MIT e a release v0.4.1 descreve correções de MongoDB e Redis e endurecimento de engines. Há referências históricas a abeni16 em links internos do README, enquanto a URL fornecida resolve em veloxbase; o conteúdo deve ser ligado ao endereço atual e ao SHA. Não foi identificado preço obrigatório do cliente. Bancos gerenciados, provider de IA e operação têm custos próprios; a licença MIT não os torna gratuitos.

Alternativas e pertinência ao Lab

Análise: DBeaver, clientes oficiais e ferramentas de linha de comando são comparadores adequados por protocolo e operação, sem avaliação atual desses produtos aqui. Para o Lab, o valor imediato é o estudo da ponte React/Rust, dos formulários multi-engine, da prévia de DDL e da separação de cofres. A adoção exigiria primeiro resolver a fronteira de IA e validar escrita, cancelamento e recuperação. Este relatório não aprova substituir ferramentas de banco ou instalar o produto.

Próximos ensaios

Proposta: começar com container ou arquivo sintético descartável e usuário somente leitura; conferir persistência de senhas e rascunhos, desligar IA e medir tráfego. Verificar status e diff da PR66 antes de testar lint com múltiplas instruções em base descartável. Depois testar tipos, Unicode, transações, rollback, limite de linhas, TLS inválido e exportação. Só uma segunda etapa poderia considerar escrita deliberada. Nenhuma consulta de banco ou provider foi realizada nesta pesquisa.

Produto e escopo

CONFIRMADO: o projeto representa perfis GitHub como edifícios numa cidade 3D e oferece páginas de perfil, comparação, conquistas, itens cosméticos, kudos e cartões de compartilhamento. São funções descritas no README; a existência da interface pública não prova disponibilidade, desempenho ou exatidão dos dados em produção.

Arquitetura e tecnologia

CONFIRMADO: o README declara Next.js 16, Three.js via React Three Fiber/drei, Supabase (PostgreSQL, autenticação OAuth GitHub e RLS), Tailwind CSS e Vercel. Isso coloca o produto na categoria de aplicação web dependente de serviços externos, não de utilitário local independente. O commit consultado é 0be2a03bd18a0cb26e830a24cb9396c80c222426.

Identidade, dados e exclusão

CONFIRMADO no código consultado: a rota `src/app/api/auth/github/route.ts` inicia OAuth via Supabase e encaminha ao callback; o ramo de desenvolvimento usa login local. `src/app/api/account/delete/route.ts` exige usuário autenticado, localiza desenvolvedores reivindicados por esse usuário e chama exclusão da conta. SECURITY.md identifica tokens OAuth, políticas RLS, webhooks Stripe e endpoints CRON como superfícies sensíveis. Não foi auditado se cada dado derivado ou cópia é removido, nem a correção de políticas RLS.

Segurança e privacidade

ANÁLISE: o produto associa métricas públicas do GitHub a contas autenticadas e tem elementos sociais e de compra, ampliando a superfície além da visualização. SECURITY.md fornece canal privado e aponta áreas de atenção, mas é uma política declarada, não uma auditoria independente. Não foram verificados escopos OAuth, retenção, telemetria, controles administrativos, Stripe, RLS ou comportamento de remoção em ambiente real.

Métricas, licença e manutenção

CONFIRMADO no snapshot público de 2026-11-03: 5.972 stars, 296 forks, 18 issues abertas; linguagem predominante TypeScript; repositório não arquivado, branch `main`, último push 2026-10-26; sem releases publicadas na coleção consultada. GitHub define stars como marcações feitas por usuários e forks como cópias do repositório na rede; são indicadores de interesse e reutilização, não de qualidade. O GitHub identifica AGPL-3.0, confirmado pelo LICENSE. Vercel, Supabase, GitHub OAuth e pagamentos podem ter custos e termos próprios; o código não permite concluir custo operacional.

Pertinência ao Lab

ANÁLISE: útil como estudo de visualização de perfil e de formas lúdicas de expor contribuições. A combinação de cidade 3D, cartões e comparação pode inspirar superfícies demonstrativas, mas a persistência social, OAuth e pagamento são escopo substancialmente maior que um widget local. AGPL exige análise de compatibilidade antes de reutilizar ou distribuir modificações; este registro não é parecer jurídico nem recomendação de adoção.

Próximos ensaios e limites

PROPOSTA: se a pertinência for retomada, fazer revisão de licença e arquitetura, examinar consultas e políticas RLS, escopos OAuth, fluxo de exclusão, limites de API do GitHub, acessibilidade/teclado em canvas 3D e comportamento em dispositivos modestos. Usar dados sintéticos e sem credenciais pessoais. Pesquisa documental e leitura pontual apenas; não houve instalação, execução, teste visual, auditoria completa, avaliação de custo ou aceite.

Reivindicação de perfil e autorização

CONFIRMADO: `src/app/api/claim/route.ts` deriva o login do provedor de identidade do GitHub, limita a reivindicação a um edifício por usuário e atualiza apenas se o perfil ainda não estiver reivindicado; comentário descreve a condição como atômica para evitar corrida. Após reivindicar, o código insere evento no feed e agenda dados sociais do GitHub. Essa rota reduz um tipo de abuso de troca de nome, mas não substitui revisão das políticas de banco e privilégios usados pelo cliente administrativo.

Economia e efeitos de ações

CONFIRMADO: `src/app/api/arcade/shop/route.ts` requer autenticação, seleciona o edifício do usuário e lê catálogo, inventário e carteira; o comentário anuncia compra atômica (débito de PX e concessão de item). O repositório descreve moedas e troca opcional em variáveis de ambiente. Isso amplia consequências para além de renderização: saldo e posse precisam de invariantes transacionais, proteção contra repetição e trilha de auditoria. A leitura parcial do arquivo não confirma o fluxo completo de compra nem a situação de ativos digitais.

Configuração e dependências externas

CONFIRMADO: `.env.example` lista chave administrativa Supabase, GitHub token, segredo CRON, chave de administração do arcade, PartyKit/Cloudflare, Reown/WalletConnect, Alchemy e 0x, além de variáveis opcionais adicionais. Os nomes sinalizam fronteiras de confiança e possíveis provedores/serviços, não que todas as integrações estejam ativas na implantação pública. `package.json` declara Next.js, Supabase, React Three Fiber, Reown e bibliotecas de analytics. Segredos e custos devem ser inventariados por implantação; valores de exemplo não são credenciais reais.

Operação e modelo de serviço

ANÁLISE: o produto combina aplicação web, banco gerenciado, arquivos públicos de modelos, OAuth, workers de jogos e, opcionalmente, serviços de blockchain e pagamentos. Mesmo quando a interface é gratuita para visitante, manutenção depende de disponibilidade e limites dessas integrações. O rótulo ‘GitHub profile’ pode criar expectativa de que a cidade seja representação objetiva de toda contribuição; a documentação descreve proxies visuais como altura por contribuições e largura por repositórios, sem validação da definição ou atualização do dado nesta revisão.

Duas credenciais e duas fronteiras GitHub

ANÁLISE: `.env.example` chama GITHUB_TOKEN de token pessoal para chamadas à API, enquanto `/api/auth/github` usa OAuth por meio do Supabase para autenticar a pessoa que reivindica perfil. São funções distintas: token de servidor para coletar dados e sessão de usuário para autorização social. Essa separação é importante para revisar escopos mínimos, rotação, rate limit, armazenamento, logs e possibilidade de conta técnica; não foi verificado quais scopes são exigidos nem se a coleta busca dados privados. A autorização a perfis públicos e a coleta de dados de contribuição merecem política transparente de cache e remoção.

Domínio e núcleo

O README define núcleo para hosts, credenciais, usuários, permissões, compartilhamento e sessões. Funções de operação ficam em plugins ativáveis ou removíveis. A distinção importa porque comparar o produto com um simples terminal SSH esconde sua dimensão de identidade e inventário. Salvar todos os acessos em um painel facilita uso cotidiano, mas também faz desse painel uma dependência importante para administração e recuperação.

Arquitetura observada

O repositório possui frontend, backend TypeScript, desktop Electron, migrações e SDK de plugins. O manifesto descreve scripts de desenvolvimento e empacotamento; o código de conexão de banco distingue dialetos e configuração de URL. Essa organização mostra produto com estado e ciclo de migração, não apenas um frontend sem persistência. Não foi verificada a equivalência de recursos entre pacotes móveis, desktop e servidor nem a execução em qualquer plataforma.

SSH e extensibilidade

O terminal SSH oficial tem repositório próprio, assim como arquivos e outros plugins. O núcleo fornece acesso e contexto, mas uma capacidade instalada precisa ser avaliada na sua versão específica. Comunidade e registries adicionais ampliam opções e cadeia de confiança. Uma tela de catálogo não certifica revisão de código, permissões mínimas ou compatibilidade. Qualquer ensaio do Lab deve registrar núcleo, plugin e backend remoto, evitando atribuir problema de uma camada à outra.

Autenticação e sessões

A leitura de core-auth e da árvore confirma módulo próprio de autenticação, emissão de sessões, métodos de login e políticas. O README anuncia contas locais, revogação de sessões, dispositivos confiáveis, API keys e auditoria. A existência desses mecanismos é diferente de comprovar suas garantias em todas as rotas. Não foram testados expiração, logout simultâneo, revogação de token, recuperação de conta ou restrição de API por usuário.

Papéis e credenciais

O autor descreve níveis connect, view, edit e manage para hosts, pastas e credenciais e criptografia por usuário. Permitir conexão sem revelar um segredo é um objetivo operacional específico, que exige teste de exportação, logs e uso indireto. Um usuário autorizado a conectar pode executar ações remotas de grande alcance mesmo sem ler a senha. Separar permissão de painel de privilégio no sistema remoto continua indispensável.

Persistência e sincronização

O núcleo declara SQLite como padrão e suporte a PostgreSQL e MySQL; o módulo connect.ts implementa a fronteira de conexão. O README anuncia cópia offline da conta no desktop quando vinculado ao servidor. Isso multiplica superfícies persistentes e exige entender quais segredos e sessões permanecem em cada dispositivo. Backup somente do banco remoto pode não representar tudo; revogação no servidor precisa ser confrontada com comportamento offline e restauração.

Deploy e dependências

O exemplo oficial usa container, porta8080 e volume em /app/data. Rodar na mesma rede administrada é conveniente, mas uma falha dessa rede pode tornar o painel indisponível; o autor oferece VPS como alternativa. VPS muda residência de credenciais e tráfego e possui custo próprio. Nenhuma topologia foi escolhida nesta pesquisa. TLS, proxy, firewall e acesso de emergência são decisões de implantação, não consequências automáticas de usar Docker.

Segurança e cadeia de plugins

O risco relevante é concentração: hosts, chaves, compartilhamentos e sessão remota se encontram numa aplicação extensível. A licença e o código aberto permitem inspeção, mas não comprovam proteção contra vazamento ou plugin comprometido. O catálogo de variáveis ajuda inventariar opções, sem provar que uma instalação concreta está configurada corretamente. O ensaio deve começar sem credenciais reais e sem acesso à LAN de produção, com destino descartável e privilégio mínimo.

Licença e custo

LICENSE contém Apache2.0. O README declara ausência de planos pagos e financiamento por doações. Isso é modelo comercial informado pelo autor, não garantia eterna de disponibilidade. Operar requer host, atualização, armazenamento, backup e eventualmente VPS. Plugins e componentes têm suas próprias licenças e contratos a conferir antes de redistribuição. Nenhum cálculo de custo total ou parecer jurídico foi realizado nesta pesquisa.

Manutenção e releases

O commit consultado atualiza cask de26.11.0. A coleção de releases inclui26.11.1-beta.1 e26.11.0; a beta alerta sobre mudanças de banco e necessidade de backup. O release estável relata correções de escrita de banco e autenticação combinada. Essas notas mostram quais caminhos o mantenedor alterou, sem provar desempenho ou ausência de regressão. O objeto que entra em teste deve ser uma versão fixada, incluindo pins de plugins.

Alternativas e pertinência

SSH nativo com configuração de hosts preserva um caminho simples e auditável; Termix acrescenta interface, compartilhamento e organização. FileBrowser Quantum resolve gestão de arquivos por web, sem substituir terminal; krd controla desktop macOS pelo terminal e tem outra fronteira. A hipótese para o Lab é reduzir dispersão de acessos operacionais, desde que não transforme personalização em bloqueio do cliente nativo ou concentre credenciais sem recuperação comprovada.

Próximos ensaios

Criar host descartável com chaves temporárias e verificar conexão, host key, interrupção e reconexão. Testar os quatro níveis com dois usuários, vazamento por exportação e logs, revogação, modo offline e restauração de banco. Desativar plugin e conferir o que deixa de funcionar. Medir atualização e rollback entre versões fixadas. Usabilidade por teclado, idioma e erros também precisa de prova; nenhuma conexão ou instalação foi executada nesta pesquisa.

Domínio e fork

Quantum se apresenta como fork extenso do File Browser, com múltiplas fontes, usuários, preview, edição e compartilhamento. O nome do repositório não significa que seja intercambiável com o projeto original. A comparação oficial lista recursos e limitações, mas é material do fornecedor e pode ficar desatualizada. A unidade de avaliação deve ser esta distribuição e seu formato de configuração, sem importar automaticamente comandos ou migrações do upstream.

Arquitetura e dependências

backend/go.mod exige Go1.27 e inclui bibliotecas de OIDC, LDAP, WebAuthn, JWT, OTP, SQLite, bbolt, thumbnails e FFmpeg. A árvore separa frontend e backend e contém testes de rotas de autenticação e compartilhamento. Isso revela várias fronteiras além de listar diretórios: indexação, geração de prévias, identidade e metadados. A presença de uma dependência não comprova que todo recurso esteja habilitado nem com quais opções em uma instalação.

Fontes e mecanismo de acesso

O produto permite múltiplas fontes do filesystem, regras de inclusão e exclusão e acesso por caminho. Segundo o README, há busca indexada, tamanhos de pastas e atualizações em tempo real; busca no conteúdo não é anunciada como capacidade pronta. Isso ajuda distinguir localizar nome e metadado de pesquisar semanticamente documentos. O conjunto exposto é limitado tanto por configuração do app quanto pelo acesso do processo no sistema operacional.

Autenticação observada

AuthenticatePassword resolve nome de usuário, lê hash, aplica CheckPwd e rejeita tentativa de login por senha quando a conta usa outro método. Também verifica troca obrigatória e TOTP quando o usuário tem segredo e o fluxo não o desabilita. A existência do parâmetro disableOtp exige avaliar chamadores para qualquer conclusão sobre cobertura. Este trecho demonstra verificações concretas, sem provar proteção de todos os endpoints ou bypass inexistente.

Configuração inicial

O config.yaml consultado usa porta80, source /srv e senha habilitada, signup desativado e passkey desativada. O mínimo de senha do exemplo é5 caracteres. Esses são valores de um arquivo distribuído, não afirmações sobre todas as opções ou uma instalação real. Antes de montar diretórios no Lab, seria preciso delimitar raiz, permissões do processo e usuário, inclusive links simbólicos, mounts e arquivos temporários de prévia.

Compartilhamento e API

São anunciados links com validade, acesso anônimo ou por usuário, permissões de visualização, edição e upload, além de tokens longos e Swagger para usuários habilitados. Cada opção muda a ameaça e a recuperação: expirar link não apaga arquivo já baixado e negar escrita não impede exfiltração por leitura. API e WebDAV adicionam clientes e rotas que precisam reproduzir a política da interface, sem presumir equivalência por aparência.

Persistência e recuperação

Arquivos de usuário são distintos do banco de usuários, permissões, tokens, quotas e compartilhamentos. Dependências de SQLite e bbolt mostram histórico e caminhos de armazenamento, mas o layout completo de migração não foi auditado. Backup deve preservar arquivos e estado necessário para reconstituir acesso, com credenciais protegidas. Um gestor web não é sozinho uma estratégia de cópias, retenção ou recuperação após ransomware; também pode propagar uma ação destrutiva autorizada.

Segurança e manutenção

As releases2.0.2-stable e2.1.4-beta relatam correções em permissões de tokens, compartilhamentos, XSS e redaction de campos. São relatos versionados do mantenedor; não foi reproduzido qualquer problema, nem demonstrado seu estado em outra versão. O projeto anuncia remoção dos comandos de shell, reduzindo uma classe de funções expostas, mas arquivo malicioso, parser de mídia, token e configuração seguem relevantes. Nenhuma certificação de segurança resulta dessas notas.

Plataformas e UX

O autor anuncia binário standalone e Docker em Linux, Windows e macOS, interface responsiva e personalizável e previews de documentos e mídia. O mesmo pacote pode exigir ferramentas adicionais conforme o formato. Nenhuma renderização, acessibilidade, WebDAV ou funcionamento em NTFS foi testado aqui. Features visuais não provam preservação de conteúdo e permissões. Deve-se verificar nomes Unicode, arquivos grandes, upload interrompido e erro de acesso com dados sintéticos.

Licença e custo

O texto de LICENSE é Apache2.0. Gratuidade do código e ausência de plano do fornecedor não removem custos de discos, thumbnails, banda, TLS, backup e administração. Recursos externos de identidade ou edição colaborativa podem acrescentar contratos e processamento. Não foi estimado consumo para acervo real. Uso de previews e fontes exige conferir licença de dependências e direitos dos arquivos, sem extrapolar a licença do gerenciador.

Alternativas e Lab

Comparado a SFTP nativo, acrescenta acesso por navegador e compartilhamento delimitado. Termix tem foco em hosts e credenciais e delega arquivos a plugin; uma suíte de colaboração como Nextcloud tem objetivo mais amplo. A hipótese do Lab é publicar internamente um conjunto específico de artefatos com política explícita, sem expor o corpus inteiro. Não há decisão de adoção, substituição de storage ou migração de dados nesta pesquisa.

Próximos ensaios

Preparar árvore sintética com dois usuários, grupos, nomes adversariais, links, pasta fora da raiz e quota. Exercitar interface, API e WebDAV, incluindo link expirado, token revogado, upload interrompido, exclusão e restauração. Conferir quais metadados vazam em erro e se previews respeitam escopo. Fixar tag e verificar atualização com backup próprio. Nenhum arquivo do Lab foi montado ou publicado e nenhum serviço foi iniciado.

Domínio e dependência de Alma

O projeto se descreve como relay próprio para controlar Alma no desktop a partir do app móvel. O tráfego é roteado entre uma conexão WSS iniciada pelo desktop e conexões HTTPS/WSS do telefone; essa descrição limita o produto ao protocolo e aos clientes Alma. Não foi verificada compatibilidade com outros clientes.

O README contrasta hospedagem própria com relay hospedado `relay.alma.now`; isso expressa opção de topologia, não independência funcional do ecossistema Alma.

Arquitetura e deploy

README identifica edição Node e edição Cloudflare Worker com Durable Objects/SQLite e hibernação de WebSocket. Também documenta Docker com Caddy, Node sem Docker e Worker. Essas são instruções e arquitetura declarada; implantação e compatibilidade de versão não foram testadas.

Nginx deve encaminhar WebSocket e desativar buffering; exemplo define limite de corpo 128 MB. A existência de variantes não comprova paridade entre runtimes.

Identidade e segurança

O README declara que, sem chave, qualquer pessoa com o endereço pode abrir túneis, embora o código de conexão de 256 bits seja necessário para alcançar o desktop. Propõe chave compartilhada ou JWT individual com segredo de assinatura; rotação do segredo revoga todos os tokens conforme a documentação.

O autor afirma ECDH autenticado, AES-256-GCM, sigilo futuro e ausência de gravação de códigos/tráfego em disco/logs. O próprio README exige Alma 0.4.329+ para recusar requisições plaintext. São garantias do projeto e condicionais à configuração/versão, não auditoria independente; metadados de roteamento continuam relevantes.

Limites e configuração

Há limites configuráveis de corpo, buffers, agentes, requisições e sockets na edição Node; Workers tem limites distintos de corpo. TURN é externo no Worker e coturn compõe o perfil Docker opcional. Isso amplia a superfície operacional e pode exigir firewall, TLS e gestão de segredos.

Push exige chaves próprias de APNs/FCM; o README diz que relay próprio não consegue notificar o app iOS oficial. Essa limitação afeta a experiência mesmo quando a comunicação principal funciona.

Persistência, custo e licença

A documentação diz que relay não persiste dados em disco; a edição Workers usa SQLite-backed Durable Objects para estado de conexão. Isso não elimina necessidade de retenção de logs da plataforma, backups de configuração/secrets nem análise do estado efêmero gerenciado.

LICENSE é MIT. O custo marginal de Workers pode ser baixo segundo o autor; VPS, domínio, TLS, TURN, push e operação seguem dependentes de plano/região/volume. Não foram calculados custos atuais.

Protocolo e compatibilidade

shared.mjs declara protocolo 2; versão é negociada como menor entre a capacidade do desktop e a máxima do relay, e clientes sem anúncio ficam no protocolo 1. O código define tipos de frame binário e janela de crédito para streaming, indicando caminho de compatibilidade explícito para desktops antigos.

Node e Worker compartilham módulos, mas implementação é duplicada em runtimes diferentes; paridade funcional exige execução dos testes nas duas edições.

Roteamento e estado observado

Cabeçalho de index.mjs descreve token de roteamento derivado do connect code, armazenamento somente do hash, mantido em memória e sem gravação em disco. Worker organiza um Durable Object por hash de token e declara SQLite-backed DO sem writes; estado ainda depende do runtime para manter sockets e disponibilidade.

Alegações de não persistência referem-se ao estado da aplicação observado/documentado; não provam inexistência de logs em proxy/Cloudflare, telemetria de processo ou metadados de rede.

Limites de recursos por edição

.env.example declara limite Node MAX_BODY_MB=128, MAX_BUFFERED_MB=512, MAX_AGENTS=10000 e concorrência até 256 requests e sockets por desktop, com configuração zero podendo significar sem limite. São defaults/limites de exemplo, não dimensionamento recomendado.

Worker hardcode MAX_BODY 24 MB para protocolo 1 por limite de mensagem DO; README diferencia corpos maiores na versão 2. As cotas do plano Cloudflare e limites de proxy podem reduzir esses valores na prática.

Configuração de acesso e notificações

.env.example diz que todas as variáveis são opcionais salvo RELAY_DOMAIN quando usado Docker Compose com Caddy. Chave compartilhada ou secret JWT por usuário limitam registrar desktops, mas endereço público sem chave permite que terceiros consumam o relay; connect code mantém outra barreira para o desktop.

APNS/FCM precisam de chaves da equipe que assina o aplicativo. O relay não pode enviar notificações oficiais sem credenciais apropriadas. Segredos devem ser fornecidos por secret store, nunca em código ou logs.

Licença, manutenção e aderência

MIT permite uso/modificação sob seus termos. O SHA consultado contém commit de 2 Nov 2026 anunciando FCM/Android e versão 1.3.0; isso mostra mudança recente no escopo e incentiva pinagem de versão e revisão de migração.

Para Lab, serve como referência de relay para um protocolo remoto específico. Não assume a autenticação do Lab nem justifica abrir túnel para dados privados; a dependência em cliente Alma e opções de push limitam reutilização.

Ensaios posteriores

Revisar authorize/parseClientPath/turnCredentials, framing e verificações TLS; executar suíte declarada separadamente em Node e Worker com replay dos casos; verificar que token nunca aparece em logs e que proxy captura metadados; ensaiar revogação/expiração, overload, slow consumer, body limits, plaintext rejeitado pelo cliente, coturn e fallback APNs/FCM.

Nenhum teste, deploy, inspeção completa ou chamada a provedor foi feito nesta pesquisa.

Produto e escopo

README apresenta conjunto de mailbox customizada, regras de roteamento, calendário, booking público, drive e agentes de IA. A caracterização de alternativa ao Google Workspace é posicionamento do mantenedor; equivalência funcional, SLA e paridade não foram demonstrados.

O repository inclui documentação separada de providers, API e agente/MCP; isso indica superfície de integração ampla e fronteiras que precisam de avaliação independente.

Arquitetura e persistência

README declara Cloudflare D1 como padrão e opções PostgreSQL, MySQL, Turso/libSQL ou SQLite local; objetos em R2, Backblaze B2 ou AWS S3. Cloudflare Workers ou container Docker são os alvos de hospedagem anunciados.

A documentação de agentes descreve integração com e-mail e MCP, mas a existência de provider não comprova migração completa, consistência entre bancos ou comportamento sob falha. Cada backend precisa de suas próprias migrações e teste de restauração.

Identidade e permissões

Guia de deploy solicita token Cloudflare com permissões de email, DNS, routing e zone; recomenda separar token de deploy de segredo runtime. Mesmo token escopado tem poder relevante sobre conta/domínios e deve ser tratado como credencial crítica.

Administração, usuários, API keys, webhooks e logs de auditoria são recursos anunciados. Não foi auditada autorização em endpoints, segregação entre mailboxes, rotação/revogação ou conteúdo dos logs.

Agente, MCP e controle humano

README anuncia busca de email, redação de respostas e gerenciamento de eventos via agentes/MCP. Documento AGENTIC.md trata como requisito que todo envio originado por agente aguarde revisão e aprovação explícita do texto exato na interface; o arquivo distingue funcionalidades planejadas/aceitação de estado de implementação.

Esse gate humano descrito é relevante, mas não foi testado. MCP amplia exposição de conteúdo de mailbox a clientes externos; avaliar escopos, principal, revogação, exfiltração por prompt injection e logging antes de conectar qualquer agente.

Custo, licença e UX

O README sugere recebimento gratuito por Cloudflare e quotas gratuitas de provedores de envio; informa plano Worker pago para envio nativo e alerta sobre sandbox inicial do SES. São valores/condições declarados sujeitos a mudança; não são orçamento atual.

Projeto declara suporte a 34 idiomas e experiência de email/calendário/drive; não foram avaliados acessibilidade, localização real, deliverability, antispam, disponibilidade ou UX.

Fluxos de email e DNS

providers.md separa recebimento e envio por domínio entre Cloudflare, Resend e SES, incluindo webhook ou S3/SNS para inbound, e declara que DNS permanece no Cloudflare em todas as combinações. Selecionar provider difere de aplicar Setup, que efetivamente escreve registros.

API.md documenta gestão de domínios incluindo setup/cleanup de recursos Cloudflare e tratamento explícito de conflito MX com resposta 409 até a opção replaceMx. Isso é mudança externa que pode interromper entrega; DNS exige plano de reversão e controle humano.

Banco e cópias

docs/databases.md descreve D1 por padrão no Workers e SQLite local no self-host, com opções PostgreSQL/MySQL/Turso e drivers; autenticação libSQL tem variável separada. A configuração e driver inferidos pela URL não provam compatibilidade de toda migration.

Guia deployment informa backup e updates, mas ainda não testamos consistência de cópia/restauração nem como cada backend preserva anexos e relações. Banco, object storage e configurações precisam de recuperação coerente.

Controles do assistente e MCP

Email assistant doc diz que é necessário configurar provider de IA e que assistant pode ser desligado por admin; permissões são por mailbox selecionada. Auto-draft é desligado até habilitação, há reviewer e limite diário, e drafts devem ser revisados antes do envio.

O mesmo doc menciona logs de uso com total/estimativa de gasto, paginação por mailbox/folder, revisões de draft e endpoints MCP. Isso oferece limites úteis, mas a redação da documentação não prova enforcement em runtime; verificar chamadas legadas, autorização entre mailboxes e efetividade da aprovação.

Limites jurídicos e custo operacional

AGPL-3.0 inclui obrigações copyleft específicas para software de rede; uso e modificações devem ser analisados conforme distribuição/configuração concreta. A licença não concede direitos sobre emails, domínios, marcas, anexos ou modelos externos.

A rota envolve Cloudflare, provider de envio/recebimento e eventual provider de IA. Preços, quotas, subprocessadores e tratamento de dados variam; não são certificados aqui. Mensagens e anexos trazem dados pessoais/confidenciais e podem ser enviados a serviços escolhidos.

Aderência e ensaios

A suíte concentra comunicação externa, agenda, arquivos e agentes — domínios com retenções diferentes. Não presumir que adoção integral simplifica governança. Avaliar inicialmente ambiente isolado e dados sintéticos, sem domínio/email reais.

Ensaios: fixar release; revisar deployment, API auth, DB migrations, providers e MCP; simular MX conflict/rollback, entrega e bounces, scopes por mailbox, revoke, approval gate, backup/restore coerente, prompt injection e limites de custo. Nada foi instalado, configurado ou implantado.

Backup API observado

Em src/app/api/backups/route.ts, GET/PUT/POST chamam requireAdmin, que obtém usuário por cookie e `assertPrimaryAdmin`; GET lista configurações/backups, PUT valida configuração, POST cria backup manual e executa runner. Erro em GET/PUT vira 403, já POST converte exceções em 400.

Isso comprova um gate de role específico nesta rota, não a autorização de todos endpoints nem a proteção do destino de backup. Operação manual e settings são destrutivas/sensíveis; testar restore é imprescindível e não é provado pela execução do runner.

Domínio e modos de uso

README anuncia envio por link/QR, pareamento, descoberta LAN e dispositivos confiáveis, incluindo clientes nativos, CLI e web. Recebedor web não precisa instalar cliente, mas o autor recomenda app nativo para arquivos grandes.

Dispositivo trusted pode aceitar arquivos sem prompt segundo README; isso altera controle humano e risco de escrita silenciosa no destino e deve ser avaliado explicitamente.

Arquitetura observada e alegada

README descreve blobs endereçados por BLAKE3, transferência em chunks, tickets com identidade do endpoint/endereço/hash e transporte QUIC com TLS 1.3 via Iroh. Anuncia relays como fallback quando hole-punching falha; em tal caso relay carrega ciphertext, conforme alegação do projeto.

Commit consultado é mudança documental sobre limitações de descoberta de endereços em modo de desenvolvimento; mostra que topologia e diagnóstico dependem de configuração e que o README está em evolução. Não se inferiu comportamento do código a partir desse título.

Persistência e privacidade

README declara ausência de conta, tracking e armazenamento em cloud e descreve histórico local. Também usa serviços de relay/discovery e Pkarr para descoberta de endpoint; operador/ISP/serviço de lookup podem observar metadados de conexão ainda que payload seja cifrado.

Checksum BLAKE3 verifica integridade referida pelo protocolo, não autoria segura de arquivo, confiabilidade do remetente, malware ou legitimidade do conteúdo. O destinatário continua responsável por validar arquivo recebido.

Configuração e hosting

Software oferece relays e serviço DNS/discovery autohospedados, e combinações públicas/privadas. README aponta instruções em infra/; commit público recente menciona limites QUIC address discovery em dev mode. Autohospedar relay/discovery não elimina anúncio DNS, firewall, atualização ou necessidade de restringir rede.

Nomes de dispositivos, tickets, chaves e dispositivo trusted são fronteiras de segurança distintas. Rotação, exclusão, revogação, armazenamento de chaves e integração multiusuário não foram avaliados estáticamente nesta amostra.

Plataformas, UX e custo

README lista Windows, macOS, Linux, Android, CLI e web, e fornece resultados de transferências em centenas de GB e taxas acima de 100 MB/s. São resultados reportados pelo projeto e explicitamente condicionados a aparelho, rede e caminho; não são benchmark independente.

Código AGPL-3.0. Sem conta/limite de uso é alegação do autor; custos de relay próprio, banda, storage temporário, build/signing e distribuição persistem. Não houve avaliação de acessibilidade ou experiência real.

Persistência local e credenciais

PRIVACY.md, atualizado pelo autor em Aug 1 2026, informa que desktop guarda segredo Iroh no credential store do sistema (Keychain, Windows Credential Manager, Linux Secret Service). README fala em histórico local; a política lista mais detalhes do que página principal.

Política é documento do fornecedor e não prova efetivo storage em cada plataforma. Backup e migração de chave podem alterar identidade do endpoint e confiança de pareamento; testar revogação e restauração segura.

Topologia pública e self-host

infra/README separa relay de discovery: autohospedar somente relay mantém lookup público; autohospedar somente discovery mantém forwarding por relay público; projeto chama stack totalmente própria a configuração de ambos.

Isto corrige a simplificação de ‘sem cloud’: mesmo sem guardar arquivo em cloud, conexão default usa infraestrutura pública do projeto Iroh. Opção self-host não foi implantada nem medida.

Licença e requisitos de build observados

src-tauri/Cargo.toml identifica versão 0.7.2, AGPL-3.0-only, edition 2021, rust-version 1.91, Tauri 2.10.1, iroh 1.3.0 e iroh-blobs 0.103.1. Isso é manifesto do frontend desktop, não necessariamente versão do aplicativo inteiro.

AGPL-3.0 aparece também no GitHub. Build inclui Rust/Node/Tauri, vários plugins e targets; manifest pontual não prova paridade de licença de todos assets/dependências.

Política de privacidade e ameaças

PRIVACY.md afirma sem telemetry/tracking, transferências E2E e storage de chaves local. A política descreve classes de dados a terceiros, mas não substitui inspeção de tráfego, logs de servidores públicos, relay/discovery e update mechanism.

SECURITY.md oferece reporte privado e inclui app, engine, WASM e infra no escopo; bibliotecas terceiros ficam fora e seguem upstream. SLA de reconhecimento/fix é compromisso anunciado, não garantia de resposta observada.

Aderência e ensaios

Pode servir transferência pontual entre dispositivos, mas não é sincronização, backup com retenção, catálogo relacional ou arquivo central. Auto-accept e links externos exigem política no Lab; nenhuma adoção foi decidida.

Ensaios: fixar release; validar chaves pareadas por canal independente, revogação, arquivos malformados, web receiver, rotação relay/discovery, interrupção, metadados diretos e indiretos, browser limits, e auto-accept. Revisar privacy policy contra tráfego real, sem conteúdo privado. Nenhum teste funcional executado.

Produto e rotas de rede

README descreve browse, ls, download, upload e mount, incluindo export de Docs/Sheets/Slides. Ele separa transferências/Drive API (IP escaneado) de login/account verification (rede normal) e fallback para refresh de token; mount usa rede normal via rclone.

A seleção automática começa tentando relay conhecido 183.56.143.147 que não pertence ao Google; o README diz que relay encaminha TLS sem poder ler conteúdo, mas observa IP do usuário e host Google em parte dos casos. `--google-only` ou GDIRECT_GOOGLE_ONLY=1 evita endpoint terceiro e força apenas frontends Google identificados pela lista do projeto. Esta opção é relevante para privacidade/política de saída e pode falhar em regiões onde esses endereços não respondem.

Código e dependências observadas

Cargo.toml no commit fixado declara Rust edition 2024, GPL-2.0-or-later, rusqlite bundled, reqwest blocking com rustls/system-proxy, clap e serde. libaria2 é fixada/empacotada segundo nome do projeto e documentação; não foi examinada cadeia de build integral.

main.rs declara `--ip`, `--sni`, `--no-sni` e `--ca-cert`; comentário do CLI diz que certificado segue verificado ao usar SNI alternativo/ausente. Isso é um mecanismo observado, não garantia de ausência de bypass em todos caminhos.

OAuth e estado local

README exige OAuth Desktop client do próprio usuário, browser no mesmo computador para callback local e Drive API habilitada. `src/auth.rs` define scope `https://www.googleapis.com/auth/drive`; é um escopo amplo de Drive e não foi visto escopo restrito por pasta.

README localiza credenciais, IPs escaneados e settings em SQLite sob dados do usuário por sistema. Logout remove token salvo e preserva IPs; isso não prova exclusão segura de WAL/backup ou revogação no Google. Não foi feito login.

Transferência e integridade

README relata downloads retomáveis e verificados contra MD5 informado pelo Drive; uploads criam novos arquivos em vez de sobrescrever arquivo de mesmo nome. MD5 aqui é checagem de integridade operacional, não atestado criptográfico de origem ou proteção contra conteúdo malicioso.

Mount usa cache local com meta aproximada de 5 GiB que pode exceder se houver arquivos abertos/não enviados; unmount preserva itens pendentes. Assim, a conclusão de cópia depende do estado de sincronização indicado pela ferramenta e de recuperação do cache.

Instalação e plataformas

Há binários pré-compilados declarados para macOS 15+, Linux x86_64/glibc recente e Windows x86_64; ARM Linux, musl e sistemas antigos exigem build. Mount adiciona rclone e em algumas plataformas FUSE3 ou WinFsp via gerenciador de pacotes, potencialmente com elevação.

O README instrui instalação por scripts remotos e `curl|bash`/PowerShell; isso é superfície de supply chain. Não baixei nem executei instalador; recomenda-se inspecionar script e verificar assinatura/hash do release antes de qualquer uso.

Licença, custo e adequação

Licença GPL-2.0-or-later registrada em Cargo.toml e metadado GitHub. Serviço usa conta Google e quota/termos Google; custo/limite dependem da conta e não foram avaliados. O app não é storage, backup versionado nem provedor independente do Google Drive.

Pode ser instrumento para transferência individual ou acesso a Drive; não deve se tornar canal de backup corporativo sem revisão de OAuth, cache, logs, quotas, políticas Google, verificação de arquivo e estado após falha.

Parsing e armazenamento de credenciais

`src/auth.rs` define estrutura Credentials com client_id, client_secret e refresh_token; comentário declara que somente esses campos são guardados e token_uri/credential source importados são ignorados. O manifesto mostra SQLite bundled como mecanismo local.

Amostra não revela encryption-at-rest nem política de permissões de arquivo; segredo persistente requer proteção do usuário/OS. Sem auditar implementação de store, não afirmamos plaintext/ciphertext.

Persistência e proteção local

README localiza SQLite de estado sob diretório de dados do usuário e inclui credenciais, endpoints escaneados e ajustes. Não foi observada criptografia em repouso do banco; ausência de evidência de criptografia não prova ausência, então o estado deve ser protegido pelo OS/account e backup.

Logout remove credenciais mas mantém IPs escaneados, segundo README. Excluir arquivo SQLite, portabilidade para outra máquina e perda de cache requerem procedimento próprio; não há backup/restore completo declarado.

Compatibilidade e operação

Binários cobrem Windows x86_64 e macOS 15+ ARM/Intel, Linux x86_64 glibc 2.35+; mount adiciona rclone e FUSE/WinFsp, podendo pedir administrador. Sistemas Apple Silicon cobertos; Linux ARM64 exige build.

A versão tem release recente 0.9.0 indicada no commit de Homebrew em 26 Oct. Isso é manutenção observada em repositório, não suporte garantido. Google OAuth browser login dificulta host headless e precisa do mesmo computador no callback local.

Próximos ensaios

Fixar release e revisar instaladores e hashes; auditar transport/auth/store e scope real; testar export/MD5, resume, cancelamento e reauth em Drive sintético; simular cache não enviado e re-mount; validar proxy, TLS, logs e retirada de credenciais.

Pesquisa documental e amostra do código OAuth; não houve login, transferência, mount, instalação ou teste de segurança.

Produto e fluxo

README descreve agendar gravações em guia de sete dias, assistir live TV e gravações no browser, pausar/retroceder live até 30 minutos e mover gravações para estrutura Show/Season/Episode ou data de exibição.

Integra TVHeadend como backend de sintonia e players (Plex/Jellyfin/Kodi) como consumidores; não substitui tuner, EPG ou servidor de mídia.

Arquitetura observada

package.json na versão 2.6.2 identifica aplicação Node ESM privada/publicada como container, com Express, Vue, SQLite via better-sqlite3 e Knex migrations; scripts executam migrações ao iniciar. Transformers.js está presente em dependências, mas a amostra não estabelece recurso, modelo ou chamada concreta.

Testes Node são declarados e configurados para bloquear tráfego de saída em parte dos suites. Configuração real, cobertura e sucesso de CI não foram inspecionados; scripts no manifesto não provam que testes passaram.

Identidade, exposição e segurança

README usa badge `LAN only`/sem autenticação; essa é informação crítica para fronteira de rede. Não deve ser publicado na internet ou em rede compartilhada sem controle externo e validação do comportamento atual.

O README inclui seção security e requisitos de Docker/host sempre ligado; controles concretos de CSRF, sessões, upload, permissões, proxy e ameaças não foram revisados no código. O projeto declara tuner e media services na LAN.

Configuração e dependências operacionais

Pré-requisitos oficiais incluem tuner compatível, Docker Compose v2 e host ligado; USB DVB depende de driver no host. Para tuner de rede, o README descreve Linux como alvo de Docker e avisa que Docker Desktop/OrbStack em Mac não descobrem tuner automaticamente; Windows é declarado não testado e script não roda nele.

Instalador curl baixa compose e escreve .env e sobe serviços de TVHeadend/Freetvarr. Isso é uma ação com efeitos reais; não foi executado. Montagens, UID/GID, gravação simultânea, atualizações e limites de disco precisam de revisão antes de dados reais.

Persistência e recuperação

O fluxo altera e renomeia arquivos de gravação e pode solicitar scan do Plex. Estado SQLite/config e biblioteca de vídeo são domínios separados; backup somente do banco ou somente da pasta de gravações pode não restaurar referências/metadata.

A seção de migração e a existência de banco SQLite foram verificadas, mas não o esquema nem uma restauração. Considerar retenção, gravação incompleta, colisão de nome, disco cheio e recuperação de metadados.

Licença, custo e maturidade

package.json declara GPL-3.0-or-later; GitHub identifica GPL-3.0. Plex, tuners e hardware têm custos próprios e alguns recursos opcionais dependem de Plex Pass ou comskip; custo de energia, armazenamento, EPG e manutenção não foi calculado.

Página pública mostra release v2.6.2 e commit de merge dessa versão em 2 Nov 2026; é sinal de atividade recente, não avaliação de qualidade ou suporte. Estrelas e badges são snapshots.

UX, integração e Lab

Interface browser para TV/telefone e ingestão de programa da grade favorecem uso doméstico; nenhum teste de acessibilidade, responsividade ou compatibilidade com decoder foi feito.

Para Lab, valor é indireto: fluxo de gravação e ingestão local. Não é componente de dados/identidade nem deve compartilhar storage com arquivo governado sem separar volumes e permissões.

Modelo de ameaça explicitado pelo autor

SECURITY.md diz explicitamente que é serviço sem login para LAN doméstica confiável, que qualquer cliente que alcance a porta pode ler configuração e mudar opções, e proíbe exposição à internet. Cita CSRF, rate limit, CSP, noindex, ausência de CORS, SameSite Strict e custom header.

O autor lista configuração revelada por `/api/settings`: host/usuário TVHeadend, URL Plex e caminhos; senha TVHeadend é armazenada em texto simples no SQLite, embora não devolvida pela API. Este é fato documental de risco que exige tratar banco e rede como sensíveis, sem afirmar exploração.

Integrações e superfície de rede

SECURITY.md chama `plex_url` de vetor de request server-side: rotas de Plex aceitam URL caller-supplied e funcionam como oracle de status HTTP limitado na LAN. O documento explica que bloquear ranges privados inviabiliza descoberta de Plex na LAN; é um trade-off intencional, não prova de vulnerabilidade externa.

Compose de exemplo mapeia diretórios de config/dados e permite serviço Plex profile opcional; arquivos de Sonarr/Radarr podem ser lidos para obter API keys. Essas chaves e paths elevam o requisito de acesso mínimo aos volumes.

Ensaios posteriores

Fixar release e revisar compose, porta/Host, proxy, volume, credenciais em SQLite, endpoint settings, CSRF e rotas caller-supplied; verificar permissões de mounts e que nenhum segredo é exposto. Proteger em VLAN/LAN confiável e confirmar bloqueio de acesso externo.

Em fixtures: simular gravação incompleta, disco cheio, rename e import; exercitar EPG, tuner, Plex opcional e backup/restore do banco + recordings. Nenhum container foi baixado ou iniciado; pesquisa não é validação funcional.

Domínio e componentes

README define este repositório como backend Java e separa web app de navegador, Manager para ver dispositivos e Client para enviar a localização de dispositivos móveis. Logo, este item sozinho não é o produto completo de experiência/cliente.

O uso inclui rastrear veículos, ativos ou pessoas, com relatórios, geofences, alarmes e mensagens. Esses domínios podem produzir decisões sobre indivíduos e têm consequências de privacidade e segurança física.

Arquitetura e protocolos

build.gradle configura Java source/target 21, Gradle, protobuf, enforcer de bytecode, Checkstyle e resolução por Maven Central. README atribui ao servidor suporte a mais de 200 protocolos GPS e 2000 modelos; é alegação do projeto e não foi validada com dispositivos.

OpenAPI 3.1 declara versão 6.17.0, API REST e endpoints de demo/assinatura. Isso oferece contrato de integração mas não substitui autorização por objeto nem política de rate limit.

Persistência e topologia

README afirma compatibilidade com bancos SQL principais e Quick Start usa Docker Compose com MySQL. Há database schema no repo; opções de banco, migrações, backup e upgrades precisam ser verificadas para versão fixada.

Modo gerenciado oficial também existe, mas implica terceiro e condições comerciais próprias. Self-hosting desloca ao operador rede, TLS, atualização, backup, sincronização de relógios e disponibilidade.

Identidade e segurança

README cita administração de conta/dispositivo, API REST e notificações; não foi revisado código de auth/ACL, ingestão de posição, exposição de portas nem mecanismos de retenção. Demonstração pública não é ambiente apropriado para telemetria privada.

Localização precisa pode identificar rotinas residenciais, trabalho e relações. Antes do uso real, limitar operador e dispositivos, auditar quem vê históricos/exportações, validar retenção/apagamento e proteger canais de protocolo e API.

Licença, custos e operação

LICENSE.txt e metadado GitHub indicam Apache License 2.0. O README diz self-host gratuito; infraestrutura, mapas/geocoding, SMS/email, armazenamento, banda e operação geram custos próprios. Managed hosting é comercial; preços atuais não foram levantados.

Atividade GitHub mostra commit de 3 Nov 2026 relacionado a decodificar respostas de comandos Teltonika sobre UDP; isto documenta manutenção de protocolo recente, sem demonstrar estabilidade de release.

UX e aderência ao Lab

Dashboard browser, geofences e relatórios são adequados a frota/ativos instrumentados, mas requerem dispositivos GPS/clients capazes. Sem necessidade explícita de rastreamento, não há aderência presumida ao Lab.

Se houver uso de dispositivo pessoal, gravar somente dados minimizados, em janela e com propósito explícito. O software não fornece por si só fundamento legal ou governança de dados.

Autenticação API observada em documentação

API docs oficiais descrevem autenticação por sessão cookie, HTTP Authorization e Bearer token. Para websocket `/api/socket`, a página cita somente sessão cookie; token obtém sessão via `/api/session?token=...`.

Configurar token em query pode expô-lo em logs/proxies; preferir canal e mecanismo documentados para cada cliente e conferir logs. Não foi testado nenhum endpoint.

Papéis e autorização por objeto

User Management oficial descreve papéis Administrator/Manager/User, limites e objetos atribuídos; Permissions and Groups liga usuário a dispositivos/grupos. Admin tem acesso total, Manager gere usuários atribuídos e objetos que possui; User acessa objetos designados sob limites.

Isso mostra modelo de controle além de login, mas não valida isolamento entre tenants nem configuração adequada. Regras de objeto precisam ser testadas contra API, WebSocket, export e relatório.

Arquitetura de tempo real

Documentação de arquitetura diz que websocket envia posição mais recente inicial e atualizações; ConnectionManager filtra pelas permissões de dispositivo. APIs REST aplicam autenticação/permissão conforme essa mesma documentação.

Afirmação informa desenho esperado; não substitui auditoria do código. Socket de tempo real e exportações podem vazar localização se filtros forem inconsistentes.

Privacidade e implicação operacional

O produto ingere posições via protocolos de dispositivos móveis/GPS e expõe histórico, relatórios e eventos. Geolocalização em série pode revelar hábitos e locais sensíveis; restringir resolução, retenção, acesso, exports, logs e operadores pelo caso de uso.

Desativação do serviço pode deixar device tentando reenviar backlog conforme protocolo/firmware. Backlog e clock drift devem entrar no ensaio de exclusão e retenção; a documentação consultada não determina comportamento universal de cada modelo.

Ensaios posteriores

Fixar release e protocolos; usar simulador e dados falsos; testar roles/object permissions em REST e WebSocket, rotas de export, API token em logs, revoke, backlog, timestamp out-of-order, precisão, carga, SQL backup/restore, TLS, portas e retenção.

Nenhum serviço, app ou dispositivo foi executado/instalado nesta pesquisa.

Produto e arquitetura declarada

README descreve fluxo ScreenCaptureKit → Kitty graphics escape → terminal, com teclado/mouse enviados por stdin e CGEvent. Isso usa SSH já existente, sem VNC, codec ou porta adicional segundo autor; segurança da sessão depende da configuração SSH/host.

Modo `--window`/mirror visual e `krd ax` headless são capacidades distintas: só o primeiro requer permissão Screen Recording; AX precisa Accessibility. Captura visual e automação trazem dados da tela e ações do usuário para o terminal remoto.

Compatibilidade e permissões

README exige macOS 14+ e terminal Kitty graphics (rex, Ghostty, kitty, WezTerm). Lista Screen Recording e Accessibility como permissões únicas para captura/entrada. Terminal.app não implementa o protocolo gráfico apontado.

Requisitos de permissão significam que instalação/uso podem expor conteúdo de tela e enviar input ao Mac; escopo, revogação e consentimento devem ser verificados no host efetivo. Nenhuma máquina macOS foi usada nesta pesquisa.

Instalador e integridade

README instrui script shell remoto, que baixa release universal Apple Silicon/Intel, verifica checksum, assina localmente com identidade estável e instala em `~/bin/krd`; também oferece versão pinada e build source. São instruções do mantenedor, não foram executadas.

Hash detecta divergência do artefato esperado se canal de hash for confiável; não substitui assinatura verificável de release nem revisão do script. Antes de uso, inspecionar script no SHA fixado e origem de checksum.

Estado do projeto e limitações de UX

README explicitamente diz Work in progress e comportamento sujeito a mudança. Lista recursos estáveis e rough/not yet, incluindo vídeo com movimento de cor, múltiplos displays numa imagem e metas FPS adaptativas; detalhes são autorrelato.

Interfaces exigem terminal com protocolo gráfico e operação de teclado específica. `krd ax` estrutura saída legível/JSON e sanitiza ESC em título segundo README; isso não é garantia de filtragem de todos dados privados nem de segurança de ações automatizadas.

Build e dependência opcional

Package.swift começa com Swift tools 5.9 e documenta um artefato libghostty-vt opcional via variável KRD_VT_XCFRAMEWORK apenas para teste headless. O comentário explicita que ausência do artefato não deve bloquear build/test padrão; isso é decisão de engenharia descrita no manifest.

O caminho condicional e targets subsequentes não foram lidos por completo nem compilados. Xcode/Swift version de build no README (Xcode 16 no branch main) e versão mínima do sistema devem ser reconciliadas para release concreta.

Segurança, privacidade e rede

Dados da tela, títulos de janelas, texto selecionado e input são sensíveis; SSH protege transporte conforme configuração, mas host remoto/terminal ainda recebe a representação visual e os comandos. Avaliar persistência de logs/debug, clipboard bridge e estado terminal.

A ausência de porta adicional não significa ausência de relay/forwarding SSH ou de risco de clipboard/terminal escape. O README diz que textos são sanitizados em `krd ax`, e que imagem usa Kitty escapes; comportamento de escape e ações deve ser revisto no parser e nos terminais suportados.

Licença e aderência ao Lab

LICENSE é MIT. Requer plataforma Apple Silicon/macOS, terminal gráfico e permissões; sem hardware Mac não há caminho para usar como desktop remoto no Lab Windows. Seu headless AX pode ser útil em automação de UI macOS, mas exige consentimento e separação de ações/inspeção.

Não é solução de VDI, compartilhamento multiusuário ou suporte geral a desktop remoto; nenhuma adoção recomendada sem caso Mac explícito.

Procedimento de deploy e superfície de confiança

DEPLOY.md diz que o binário não inicia serviço sozinho: é copiado, duas permissões são aprovadas e rodado de uma sessão SSH; fechar sessão termina. Target requer Remote Login já habilitado, o deploy script não o ativa.

Script resolve latest release por padrão e oferece `--version`; revisão recomenda pinagem de release para reprodutibilidade. Checksum SHA-256 é verificação contra artefato publicado, não origem independente se binário e checksum vêm do mesmo canal.

Cobertura de testes declarada

TESTING.md separa testes mecânicos (bytes/layout) de comportamento de terminal e ScreenCaptureKit, incluindo `swift test`, selftest sem permissões, pipeline sintético e calibração no terminal. Isso é desenho de validação explícito, não evidência de que esses gates passaram para versão avaliada.

Docs relatam teste de PTY que simula handshake de terminal e dumps de termcaps em Ghostty 1.4.0 e Apple Terminal; seus resultados são afirmações no documento e não foram reproduzidos.

Ensaios e limites de adoção

Em Mac laboratório e dados sintéticos: pin release, auditar installer/checksum, validar prompts de Screen Recording/Accessibility e revogação; testar terminais reais, resize/SSH interrompido, clipboard in/out, titles com ESC, `krd ax` com falhas/readback, logs/debug e sessão terminada.

Sem Mac, o produto não tem aplicação direta ao ambiente Windows do Lab. Nenhuma instalação, captura, execução AX ou teste SSH foi realizado.

Produto e plataforma

README descreve aplicação macOS para virtualizar sistemas em Apple Silicon, com foco em testar versões/macOS betas. Requisitos declarados: Apple Silicon Mac e macOS 13 ou posterior como host.

A proposta é um utilitário gráfico local; não anuncia host headless Linux/Windows, cluster, migração live ou administração remota.

Guest, imagens e instalação

Wizard seleciona restore images disponibilizadas por Apple, IPSW local/URL, Linux ISO local/URL e distro Linux listada. Download automático depende de endpoints externos e disponibilidade de imagens; URL customizada expande a origem de conteúdo.

README alerta que macOS Golden Gate beta em host macOS 26 exige VirtualBuddy 2.2 beta 2+ e device support files recentes, salvo Xcode 27 beta instalado. Beta compatibility muda rapidamente e precisa ser verificada por versão.

Recursos de VM e estado

Checklist anuncia boot de macOS 12/13 e alguns Linux ARM, modo Recovery, redes, file sharing, clipboard, configuração de hardware e save/restore de estado de VM. Não é prova de cobertura universal de guest, performance ou consistência.

Dica de APFS clone usa cópia de VM em biblioteca para criar ambiente limpo com pouco espaço segundo o autor. Clone não substitui backup independente; corrupção/erro de volume pode afetar cópias no mesmo container/storage.

Guest helpers e limites de compatibilidade

VirtualBuddyGuest fornece clipboard e montagem automática de pastas em guest macOS 14+; guest app legado em macOS 13 monta pastas mas não tem clipboard; Guest não é suportado em macOS 12 ou anterior, embora VM macOS 12 possa funcionar sem esse helper.

O README exige separar capacidade de virtualizar guest de capacidade do Guest helper. Discussão de 2024 confirma encerramento de suporte do helper para macOS 12, mas está fora da janela principal de estado atual; foi preferido o README contemporâneo.

Build, release e assinatura

README solicita Xcode 16 para build em `main` e configuração manual de bundle ID prefix/signing team em targets VirtualBuddy e Guest. Releases oferecem binários e Homebrew Cask, e existe apoio financeiro opcional ao autor.

Isso implica dependência da cadeia Apple/Xcode, assinatura e entitlement. Não foram analisados project settings, atualizações automáticas, notarização ou scripts de release nesta amostra.

Manutenção observada

Commit mais recente consultado em 3 Nov 2026 intitula-se Guest appearance sync service (#803), indicando atividade no helper; título isolado não permite avaliar mudanças nem regressões.

Discussões públicas recentes mostram perguntas sobre estabilidade/rollout 2.2 beta e comportamento em beta/guest. Isso é evidência de questões abertas de manutenção/compatibilidade reportadas, não comprovação de defeito generalizado.

Dados compartilhados, segurança e persistência

VMs podem receber pastas compartilhadas host↔guest e clipboard. Essas pontes permitem movimentação bidirecional de dados e podem atravessar isolamento esperado; habilitar apenas em VMs confiáveis e com pasta dedicada.

Snapshots/estado e APFS clone são mecanismos locais. Revisar onde biblioteca VM, discos, chaves e imagens ficam, permissões, retenção e cópia externa. Não foram inspecionados sandboxing, hypervisor entitlements, logs ou criptografia dos discos.

Licença e custos

LICENSE permissiva BSD de duas cláusulas com aviso e disclaimer. Aplicativo é gratuito para download segundo README, com Gumroad/sponsor voluntários; hardware Mac, armazenamento e licenças/uso de imagens/serviços Apple são custos externos.

Preço/termos de hardware, imagens beta e conta Apple não foram pesquisados nesta tarefa; licença do app não se estende a guest OS ou conteúdo baixado.

Aderência ao Lab e alternativas

Útil apenas quando o Lab precisa de teste local de software macOS em máquina Apple Silicon. Não oferece caminho em Windows atual do workspace sem hardware Mac e não resolve infraestrutura geral, backups nem isolamento multi-tenant.

Alternativas são Virtualization.framework tooling/UTM/Parallels, mas comparação/licenças/compatibilidade não foi feita; não inferir superioridade a partir do README.

Ensaios posteriores

Em Mac de laboratório, fixar release e macOS host; provisionar guest descartável sem credenciais reais; testar suspend/resume, clone, restore, disco cheio, clipboard/pastas, rede bridged e helper por versões; validar assinaturas, entitlements, atualizações e documentação de beta.

Nenhum VM/imagem foi baixado, instalado, iniciado ou testado nesta pesquisa.

Produto e escopo

CONFIRMADO como descrição do repositório: CRM focado em vendas e atendimento pelo WhatsApp, com agentes de IA, automação, integrações e uso por múltiplas organizações. O README promove alternativas a produtos comerciais e contém instruções de instalação em VPS. São declarações do mantenedor, não prova de paridade funcional ou de operação segura em produção.

Arquitetura, integração e automação

CONFIRMADO: o README declara Next.js 16, TypeScript, Supabase/PostgreSQL/Auth/Storage, integração WhatsApp via WAHA e kit Docker/VPS. O endpoint `app/api/mcp/route.ts` implementa transporte MCP Streamable HTTP, cria servidor/transporte por requisição e autentica bearer tokens em `api_tokens`; o comentário declara que plaintext do bearer não é logado. O comentário é intenção documentada no código, não auditoria de logs abrangente.

Identidade, controles e privacidade

CONFIRMADO: o código inclui política de MFA, autenticação e separação multi-tenant; SECURITY.md lista risco de vazamento entre tenants, RBAC, dados de contato/conversas/mídia e segredos como áreas de reporte. O endpoint MCP valida token bearer. Não examinei todas as políticas RLS, rotas, integrações WhatsApp, webhooks, permissões ou fluxos de remoção/exportação de dados. A autodescrição LGPD não equivale a avaliação jurídica nem demonstra conformidade.

Operação e implantação

RELATADO pelo README: o caminho recomendado instala app, integração WhatsApp e banco em VPS via kit de instalação, com runbook de produção e parceria comercial com HostGator. Self-hosting transfere ao operador tarefas de atualização, backup, TLS, firewall, monitoramento, restauração, gestão de segredos e incidentes. Não foi conferida a sequência de scripts, requisitos mínimos, exposição de portas, política de backup ou custo atual da VPS.

Licença, custo e manutenção

CONFIRMADO no snapshot público de 2026-11-03: MIT, TypeScript, 5.106 stars, 1.453 forks e 374 issues abertas; não arquivado, branch main; atividade no mesmo dia. GitHub define stars como marcações de usuários e forks como cópias no grafo do repositório; esses números medem interesse/reuso, não qualidade. Releases públicas não retornaram itens na primeira consulta. LICENSE contém MIT. Issues abertas são contador do repositório, não defeitos confirmados. Custos de VPS, provedores de IA, WhatsApp/WAHA, serviços externos e manutenção não são cobertos pela licença.

Relevância e limites para o Lab

ANÁLISE: referência potencial para integração MCP, automações orientadas a negócio e separação multi-tenant, mas o domínio trata dados pessoais, mensagens, mídia e comunicação externa. A superfície funcional e a carga de operação são muito maiores que um componente local. A adoção exigiria decisão explícita de produto, modelagem de dados, avaliação de risco e testes em ambiente sintético; esta pesquisa não recomenda conectar contas, canais ou dados reais.

Ensaios propostos

PROPOSTA: antes de qualquer piloto, revisar migrations e RLS por tenant; testar autorização horizontal, MFA, recuperação e revogação de bearer; mapear dados enviados a modelos e retenção; simular webhooks duplicados, falhas do WhatsApp e retries; conferir backup/restauração, atualização e hardening de VPS; revisar licença de dependências e termos dos providers. Ensaios somente com identidades, mensagens e contatos sintéticos. Nenhum teste foi executado nesta pesquisa.

Instalação e schema de banco

RELATADO com destaque no README para quem contribui: migrations 0001–0009 e 0013 seriam stubs `SELECT 1`; o schema real estaria em `supabase/baseline.sql`, que o instalador de VPS aplica. O README avisa que `supabase db push` pode terminar sem erro e deixar o banco vazio, e que extensão `vector`, `citext` e `pg_trgm` precisa ser ativada antes em um Supabase novo. Isso constitui risco de bootstrap e documentação operacional que precisa ser seguido; não foi reproduzido, e a instrução do projeto pode mudar no branch.

Integrações de IA e canais

RELATADO pelo README: stack de IA usa Vercel AI SDK e pode integrar OpenRouter, Requesty, Anthropic, OpenAI e Google; o instalador pergunta provider e a interface permite trocar depois. Integrações de canal incluem WAHA e Meta Cloud API, além de Nuvemshop. A escolha concreta, transferência de histórico/contexto, retenção, subprocessadores, guardrails, custo e requisitos de canal dependem da configuração de cada tenant. O endpoint MCP consulta capacidade organizacional; não foi demonstrado quais ferramentas ficam habilitadas por padrão.

Filas, webhooks e reprocessamento

RELATADO: README diz que eventos entram em `event_log` e são consumidos por uma rota cron periódica; triggers do banco não chamam HTTP diretamente. Automações nasceriam pausadas até revisão, registram atividade e podem ser reenviadas manualmente quando uma chamada externa falha. Sem o cron, automações podem existir sem rodar. O padrão é útil, mas duplicação, ordem, idempotência, dead letters, vazamento de segredo em URL de webhook e consequências de reenvio precisam de ensaios.

Superfície funcional e risco de configuração

ANÁLISE: a tabela de telas inclui inbox, funil, agentes, RAG, memória, conectores, métricas, billing, audit log e solicitações LGPD; o que parece um CRM simples inclui uma plataforma de automação e administração. Essa amplitude eleva custo de configuração, atualização e governança. O caminho HostGator é promovido como principal, mas projeto também lista outras VPS/provedores e uma rota local de desenvolvimento; requisitos e custo devem ser calculados para a arquitetura realmente selecionada.

Gate de qualidade declarado

RELATADO: README enumera checks para typecheck, lint, unit tests, shell tests, invariants em Postgres efêmero, E2E e verificação de imagens, e afirma que branch protection exige determinados checks. O próprio documento alerta que a quantidade/contexto muda e manda medir o estado atual. A existência de suíte e de regra declarada não comprova que CI estava verde no SHA, que cobertura é completa ou que self-host tem paridade; não executei nem consultei workflow status.

Produto e escopo

CONFIRMADO pelo README: calendário e tarefas em visualizações semana, mês, ano, timeline e tabela; oferece planejamento de tarefas, disponibilidade, subtarefas, dependências, anexos, notificações, convidados e respostas. O aviso do próprio README classifica o produto como inicial e sujeito a breaking changes antes de 1.0.

Sincronização e dados

RELATADO: calendários podem ficar no próprio Mitra ou sincronizar bidirecionalmente com CalDAV, Google Calendar, Apple Calendar, Notion, Todoist e Tempo; feeds publicados são descritos como somente leitura. O compose fixa volume persistente em `~/mitra:/app/data`. A pesquisa não testou consistência, conflitos, exclusões remotas, criptografia, cópias de segurança ou recuperação dos conectores.

MCP e permissões

CONFIRMADO na documentação oficial de conectores: MCP pode ler e modificar os calendários e ações chegam ao provedor como ações do usuário. Com login, tokens têm permissão read-only ou read-and-write e apenas fingerprint é mantido pelo Mitra; token é mostrado uma única vez e pode ser revogado. Sem login, o servidor é de usuário único sem token: qualquer pessoa que consiga alcançar a URL pode usar a API. A recomendação explícita é manter servidor sem autenticação privado.

Implantação, custo e operação

CONFIRMADO: distribuição Docker Compose para um container, com porta 3000 e volume persistente; README descreve um pequeno container e banco próprio. Isso não inclui host, domínio, TLS, backup externo, monitoramento ou gestão de credenciais dos conectores. Custo de hospedagem e providers de calendário não foi cotado; a existência de código aberto não prova operação sem custos.

Licença e estado

CONFIRMADO no snapshot público de 2026-11-03: 146 stars, 8 forks, 10 issues abertas; TypeScript; não arquivado; branch main; último push 2026-10-29. GitHub define stars como marcações feitas por usuários e forks como cópias no grafo do repositório; issues abertas são o contador público e não defeitos confirmados. LICENSE/package declaram AGPL-3.0-only. Releases, docs e imagem em GHCR são apontadas no README; contagem/estado de releases não foi auditada nesta consulta. Métricas não indicam estabilidade nem segurança.

Aderência ao Lab

ANÁLISE: a combinação de agenda, tarefas, planejamento e protocolo MCP pode servir de referência para um assistente pessoal com ações rastreáveis. O risco central é a autoridade dada ao conector: token gravável pode alterar compromissos e propagar alterações aos provedores. O caso sem autenticação é especialmente inadequado para endpoint exposto. A licença AGPL também requer análise antes de incorporar ou disponibilizar serviço modificado em rede.

Ensaios propostos e limites

PROPOSTA: em instância descartável, testar autenticação, escopo read-only vs read-write, revogação, autorização sem login, idempotência de alterações, timezone/DST, conflitos e propagação entre conectores; verificar backup e restauração do volume e comportamento de falhas parciais. Usar calendários e contas sintéticas. Não houve execução, sincronização, avaliação de acessibilidade, revisão integral do código ou validação jurídica.

Escopo efetivo dos tokens

CONFIRMADO na documentação e leitura pontual: token tem nome reconhecível, escopo read ou read-write, e o segredo é mostrado uma vez ao criá-lo. Código de middleware calcula hash do bearer recebido e localiza token/usuário, recusa token inválido ou revogado e registra uso; código MCP oferece às ferramentas somente operações de leitura quando escopo não permite escrita. Isso indica controle granular intencional, mas não comprova resistência a vazamento de token, validade, rate limit, isolamento entre calendários ou cobertura completa das ferramentas.

Conteúdo de calendário como entrada não confiável

ANÁLISE ancorada em orientação do próprio servidor: instruções MCP pedem chamar `get_context` antes, que informa hora atual, fuso da casa e calendários; também dizem que entradas podem vir de calendários editáveis por outras pessoas e devem ser tratadas como dados, não instruções. Isso reconhece risco de conteúdo malicioso/injeção indireta para agente conectado. Não foi verificado se todas as ferramentas preservam essa fronteira nem se clientes MCP honram a instrução.

Versão e maturidade do pacote

CONFIRMADO: README alerta que o projeto está em movimento antes de 1.0; o package.json fixado no SHA consultado marca versão 0.7.1 e licença AGPL-3.0-only. Os scripts incluem testes, lint, typecheck e build; a existência dos comandos não comprova seu êxito neste SHA. A imagem `latest` é recomendada no compose, com comentários oferecendo tags major/minor/patch e pin exato, mas nenhum método de update ou digest foi ensaiado nesta pesquisa.

Backup e restauração

ANÁLISE: o README afirma que tudo fica no diretório `~/mitra` na configuração inicial, de modo que respaldar esse diretório respaldaria os dados. Isso só vale para esse perfil simples; contas conectadas, tokens, configurações, arquivos adicionais ou volumes externos em configurações avançadas podem exigir artefatos diferentes. Replicar o diretório enquanto o banco está em escrita pode produzir cópia inconsistente. Exigir backup coordenado e ensaio de restauração, migração e reconexão dos providers antes de armazenar calendário importante.

Produto e domínio

CONFIRMADO: o README descreve workspace visual para pessoas que fazem filmes e fotografia, reunindo referências, storyboards, shot lists e revisão com cliente num canvas infinito self-hosted. Lista notas, imagens, arquivos, links, tarefas, paletas, colunas, setas e organização visual. A descrição caracteriza o escopo pretendido, não demonstra adequação a fluxos profissionais.

Maturidade e continuidade

RELATADO pelo mantenedor: estágio inicial, em direção à versão 1.0; releases pré-1.0 podem mudar entre versões menores e ainda não são recomendadas para trabalho que não pode ser perdido. O aviso é especialmente relevante para projetos audiovisuais com produção e revisão de cliente. Não foi confirmada existência de releases estáveis, SLA, compatibilidade de migração ou plano de suporte.

Arquitetura e operação

CONFIRMADO: há Dockerfile e compose.yaml no repositório; o README apresenta implantação self-hosted e documentação de upgrades. O tree contém um monorepo com apps de servidor, mobile e clipper de navegador. Esta estrutura sugere mais de uma superfície de cliente, mas não foram validados o contrato completo entre elas, requisitos, volume, autenticação entre componentes nem compatibilidade de versões. Nenhum container foi executado.

Decisões sobre dados e recursos

CONFIRMADO: o repositório mantém decisões numeradas para modelo de dados, autenticação, arquivos/mídia, colaboração, edição em servidor, storyboards/busca, revisão e compartilhamento. Isso dá rastreabilidade arquitetural e merece leitura antes de uma prova de conceito. O nome de uma decisão não prova que seu contrato esteja corretamente implementado; não foram revisadas as rotas e migrações que a executam.

Licenciamento

CONFIRMADO: a decisão 0007 escolhe AGPL-3.0-only para Inkadra e lista licenças permitidas para dependências de produção; CI executa `pnpm check:licenses`. A decisão 0008 trata licenças por componente, e a badge do README resume AGPL-3.0/MPL-2.0. Isso indica que componentes auxiliares podem ter termos distintos; cada pacote deve ser examinado antes de reutilização. Não é análise jurídica.

Segurança e reporte

RELATADO: SECURITY.md pede reporte privado de vulnerabilidades e informa que até 1.0 apenas a release mais recente recebe correções. O processo e a janela de suporte dependem da manutenção do projeto. Não foram avaliados controles de upload, links externos, autorização multiusuário, isolamento entre clientes, retenção de arquivos ou gestão de credenciais.

Métricas e manutenção

CONFIRMADO no snapshot público 2026-11-03: 9 stars, 1 fork, 8 issues abertas, TypeScript, repositório não arquivado, branch main; último push foi 2026-11-03. GitHub define stars como marcações de usuários e forks como cópias do repositório; contagem de issues abertas não confirma bugs. O GitHub associa AGPL-3.0. A documentação aponta pipeline de CI e publicação de release, mas não se interpretam contagens como prova de adoção, segurança ou estabilidade. Não examinei as issues uma a uma.

Acessibilidade e colaboração

ANÁLISE: canvas infinito e organização espacial podem ajudar leitura visual e comentários de cliente, mas não foram testados zoom, teclado, leitor de tela, navegação sem arraste, sincronização concorrente ou histórico de revisão. Para uso audiovisual real, confiabilidade de mídia, resolução, direitos e recuperação após exclusão são critérios centrais não respondidos pelo README.

Pertinência ao Lab

ANÁLISE: vale observar a organização de referências e cenas, e a maneira como o projeto registra decisões de arquitetura e segmenta licenças. A implantação própria pode preservar controle sobre arquivos, mas também transfere operação e backup ao Lab. A fase inicial e a licença AGPL tornam inadequado inferir prontidão para dados de cliente ou incorporação direta ao Blog. Nenhuma adoção é recomendada por este relatório.

Próximos ensaios e limites

PROPOSTA: criar instância descartável com imagens sintéticas; ensaiar importação, miniaturas, upload/download, concorrência, autorização de convidado, compartilhamento externo, exportação, exclusão e recuperação de backup; percorrer upgrades entre versões e restauração. Validar teclado, leitor de tela e viewport móvel. Rever security advisories e dependências, e mapear dados transmitidos pelo clipper. Aqui houve leitura documental e de decisões, sem execução, instalação, teste visual, análise completa do código ou aceite.

Mídia, metadados e retenção

RELATADO em decisão de arquitetura aceita: o sistema prevê upload tus em blocos de até 50 MiB, armazenamento local ou S3, checksum, detecção de tipo por bytes, orientação EXIF, thumbnails WebP e remoção de uploads incompletos após 24h. A mesma decisão observa que metadados de câmera podem revelar localização residencial e define que thumbnails não carreguem metadados. São controles projetados, não comprovadamente implementados/testados. Arquivos originais continuam sensíveis, especialmente no self-host e em buckets compartilhados.

Autorização e colaboração planejadas

RELATADO em decisão 0011 aceita: papéis owner/editor/commenter/viewer podem valer para projeto e board, com herança e concessão por subárvore; espectadores/comentadores teriam conexões read-only e o servidor colaborativo revalidaria permissões em intervalos de até 30 segundos. A decisão 0013 sobre comentários, aprovações, links de convidado e versões está marcada Proposed, não Accepted. Não converter decisões em prova de implementação; a seção de projeto está evoluindo e os contratos precisam ser confirmados no código e em testes antes de confiar documentos de cliente.

Objeto e cobertura pretendida

CONFIRMADO: o projeto reúne atos constitucionais e normas federais, estaduais/distritais, regulatórias, municipais e tratados; o plano inclui jurisprudência vinculante. A organização é por esfera, tipo e ano e pretende permitir navegação em texto simples. A cobertura efetivamente disponível é menor que o objetivo declarado, e a própria documentação identifica lacunas.

Formato dos documentos

CONFIRMADO: o README exemplifica cabeçalho YAML com título, UF, tipo, número, datas, ementa, situação, revogação, versão textual, publicação, URN, fonte e, quando aplicável, arquivo PDF; depois vem o corpo em Markdown. Um exemplo é a Constituição na raiz, cujo cabeçalho informa origem Planalto, data de obtenção e limites da compilação. A presença de metadados facilita rastreabilidade, mas não certifica fidelidade sem comparar com origem.

Coleta, conversão e proveniência

CONFIRMADO: o README relata conversões automáticas e OCR para documentos escaneados, indica links de fonte no cabeçalho e descreve que fontes integrais e recibos podem ser versionados com origem, captura e SHA-256. Também declara que `_fonte/` contém originais comprimidos e fica fora do versionamento. `scripts/plano.py` é descrito como fonte única do escopo; `scripts/progresso.py` lê esse plano, conta arquivos e audita pastas fora do plano. Isso documenta um mecanismo de cobertura e proveniência, mas não demonstra que cada captura permaneça acessível ou que o OCR esteja correto.

Integridade e métricas do acervo

RELATADO nos artefatos consultados: README descreve base histórica inicial de 323.849 normas; `PROGRESSO.md`, gerado em 28/10/2026, informa 1.201.847 documentos no acervo medido e cerca de 1,09 milhão frente a metas contadas/estimadas, com 7.637 pendências de integralidade excluídas até validação. O mesmo relatório alerta que volume não prova integralidade ou qualidade. As contagens têm data e universos distintos; não devem ser comparadas como se medissem a mesma unidade. O README informa 133,8 GB no diretório local em 1/11/2026, enquanto dados originais e índices não estão todos no Git.

Limites jurídicos e qualidade

RELATADO: o projeto avisa que textos não substituem Diário Oficial e que conversões/OCR devem ser conferidas na origem. `scripts/plano.py` esclarece que certas metas são estimativas de dimensionamento e só devem virar número real com índice da fonte, tratamento de duplicatas e recortes. Situação vigente, redações compiladas, revogações, datas de eficácia, regras de transição e anexos exigem consulta à publicação oficial e, em caso de uso jurídico, análise qualificada. Esta pesquisa não verificou atualidade nem correção de qualquer norma.

Reprodução e auditoria

CONFIRMADO: a documentação descreve scripts retomáveis, ferramenta de progresso e auditorias da base inicial; informa que o progresso pode ser conferido sem gravar. As auditorias registram hashes das dependências de cada lote e recomendam replay no commit que publicou o lote. Os originais e índices fora do Git são uma dependência de reprodução; sem eles, histórico versionado sozinho pode não permitir reconstruir toda a coleta. Nenhum script foi executado nesta pesquisa.

Licença, financiamento e infraestrutura

CONFIRMADO: `LICENSE` aplica MIT ao código de `scripts/` e afirma que textos de normas públicas não são objeto de proteção autoral segundo o artigo citado pelo mantenedor. A licença do código foi lida; qualquer exceção de fonte/arquivo deve ser avaliada à parte. A API de metadados do GitHub reporta `NOASSERTION`, então não se deve apresentar repositório inteiro como categorizado MIT pelo GitHub. README exibe pedido de apoio via Pix e informa necessidade de espaço para acervo/OCR. O projeto declara não ter financiamento suficiente para infraestrutura; isso é relato do mantenedor, não auditoria financeira.

Estado e métricas do GitHub

CONFIRMADO no snapshot público de 2026-11-03: 2.414 stars, 404 forks, 22 issues abertas, branch main, não arquivado; GitHub não identifica linguagem predominante. GitHub define stars como marcações feitas por usuários e forks como cópias no grafo do repositório; o contador de issues abertas não qualifica defeitos. O tamanho informado pela API é 8.582.635 KB e o repositório foi atualizado em 2/11. Métricas medem interesse/cópias e atividade, não qualidade jurídica. A busca de releases não foi concluída; estado de versões não identificado.

Pertinência ao Lab

ANÁLISE: é um exemplo útil de catálogo documental com fonte por item, metadados estruturados, indicadores de lacuna e conversão reprodutível. O aviso sobre OCR e autoridade da fonte oficial é uma boa prática para dados que podem afetar decisões. A escala do acervo, originais externos ao Git e possível fluxo de contribuição/revisão exigem armazenamento, checksums, validação e governança específicos; o formato Markdown não substitui esses controles.

Ensaios propostos e limites

PROPOSTA: selecionar amostra estratificada por esfera, tipo, idade, HTML/PDF e OCR; comparar campo a campo com publicação oficial e preservar hashes/recibo; reexecutar auditorias no SHA correspondente; medir duplicatas, anexos ausentes, revogações, vigência e qualidade de OCR; verificar restauração dos artefatos excluídos do Git. Se usado para consulta do Lab, mostrar sempre data de obtenção, fonte oficial e status de validação e evitar aconselhamento jurídico. Nenhuma comparação normativa, execução de scripts, varredura de todo o acervo ou parecer legal ocorreu nesta pesquisa.

Produto e escopo

CONFIRMADO: o projeto disponibiliza endpoints brasileiros agrupados por domínio e versão; o README lista dados como CEP, CNPJ, bancos e câmbio e o repositório contém diretórios de API, serviços, documentação OpenAPI e testes. A existência de endpoint não garante a mesma cobertura para todos os estados/provedores, nem substitui fonte oficial para decisão cadastral ou legal.

Arquitetura e protocolo

CONFIRMADO: endpoints são handlers HTTP sob `pages/api`, delegando a services; `GET /api/cnpj/v1/[cnpj]` encaminha ao service e responde com status e dados. A documentação estabelece estrutura handler/service/teste e OpenAPI 3.0. Metadados do pacote declaram Node 24.x e Next.js 12.x, com outras dependências; versão declarada não foi comparada a requisitos do deploy atual.

Provedor e degradação

CONFIRMADO no código do SHA consultado: `services/cnpj.js` envia requisição para `minhareceita.org/{cnpj}` via Axios, define timeout de 5 segundos e usa AbortController para limitar conexão e requisição. Falhas 5xx, ausência de resposta ou abortamento são convertidos em `ServiceUnavailableError`; o handler marca `Cache-Control: no-store` neste caso. Esse contrato mostra dependência externa e tratamento delimitado, não confirma disponibilidade, correção dos dados, rate limits ou comportamento sob carga.

Cache e atualidade

CONFIRMADO: middleware `middlewares/cache.js` documenta `max-age=0`, `s-maxage` do proxy e `stale-while-revalidate` público. O comentário descreve cache de um dia para algumas respostas como exemplo de decisão antiga e menciona invalidação no deploy. Política concreta é chamada por endpoint; o trecho não prova que todo dado esteja atualizado nem que a fonte original corrija erros. O cache de informações cadastrais precisa considerar data de referência, origem, TTL e indisponibilidade.

Confiabilidade e observabilidade

ANÁLISE: uma API agregadora uniformiza contratos e erros, mas pode esconder diferenças de fonte, cobertura, data, normalização e limites. Os testes de contrato listados no repositório são uma pista de governança; a presença de testes não equivale à execução atual nem a validação de dados upstream. É importante preservar proveniência por endpoint, tornar ausência de dados diferente de resposta vazia e expor falha de fornecedor sem atribuí-la ao consumidor.

Licença e sustentabilidade

CONFIRMADO: licença MIT em LICENSE. O guia de endpoints afirma que o projeto é open source e sem financiamento e proíbe dependência de banco próprio, storage ou serviço pago; a hospedagem declarada usa Vercel. O README inclui links de comunidade/apoio. São decisões e declarações do projeto; não houve auditoria de financiamento, orçamento, contrato de host ou continuidade do domínio.

Manutenção e métricas

CONFIRMADO no snapshot público 2026-11-03: 11.460 stars, 803 forks, 101 issues abertas, JavaScript, branch main e repositório não arquivado; push em 3/11. GitHub define stars como marcação de interesse e forks como cópias do repo; issues abertas são contador, não diagnóstico de defeitos. GitHub reconhece MIT. A API e o projeto existem desde 2020. Atividade não prova estabilidade de cada endpoint. A busca de releases não foi examinada em detalhe e suporte por versão não foi identificado nesta amostra.

Aderência ao Lab

ANÁLISE: pode reduzir trabalho de integração com fontes brasileiras, mas acrescenta uma camada intermediária e fonte upstream cujo status pode mudar. Para fluxo de alto impacto, registrar URL oficial, data/hora, provedor retornado, status de cache, TTL e fallback; validar em amostra com a fonte original. Um contrato simples de API não torna dado oficial ou autoritativo.

Próximos ensaios

PROPOSTA: para endpoint escolhido, conferir OpenAPI, validação de entrada, rate limiting, cache, origem upstream, uso de dados pessoais, termos do provedor, timeout/retry e tratamento de respostas obsoletas; comparar resultados com fonte oficial em casos válidos, inválidos, inexistentes e indisponíveis; executar testes de contrato do SHA e atualizar matriz de versões/runtime antes de integrar. Não chamar endpoint nem processar CPF/CNPJ real nesta pesquisa.

Limites da pesquisa

A análise é documental e estática, centrada em CNPJ e no guia de contribuição. Não houve requisição HTTP, validação de payload, teste de carga, revisão de todos os endpoints, auditoria de disponibilidade, segurança, privacidade, atualidade, custo de infraestrutura ou aceitação humana. Os totais do GitHub são retrato temporal.

Contrato de resposta e testes declarados

CONFIRMADO: `tests/cnpj-v1.test.js` declara testes para CORS aberto, consulta de empresa conhecida, CNPJ válido não encontrado e entrada inválida com respostas 404/400. O caso de sucesso espera razão social específica. O próprio cabeçalho classifica o arquivo como E2E e utiliza `global.SERVER_URL`; isso implica dependência do ambiente de teste e/ou resposta upstream. A presença de teste não demonstra que tenha sido executado no SHA nem que todos os resultados upstream estejam sob controle do projeto.

Fontes de dados públicas não são necessariamente oficiais

ANÁLISE: o guia pede fonte pública, gratuita, estável, mantida e documentada; é uma triagem de produto útil, mas esses critérios não significam que a fonte seja órgão oficial ou que os dados tenham garantias de atualização. Exemplo do CNPJ consulta `minhareceita.org`, não a Receita Federal diretamente. Para resultado de negócio, distinguir agregador/provedor, autoridade originária, data de atualização e limites de uso. Não foi consultada a fonte upstream nem feita avaliação contratual.

Produto e conteúdo

CONFIRMADO: o README descreve guia interativo de ESP32-S3 com 32 labs, simuladores, placa 3D, pinout, leitura guiada do firmware e documentação do chip. Lições cobrem setup, display, Wi-Fi, RFID/NFC, BLE, áudio e sensores previstos. A lista mistura conteúdo pronto e planejado; não se interpreta a contagem como 32 exercícios funcionais validados neste relatório.

Arquitetura e distribuição

CONFIRMADO: React 19, TypeScript estrito, Vite, React Router com rotas hash, TanStack Query, Zod, i18next e Three.js. Arquitetura explica lições como dados, simuladores como widgets carregados sob demanda, validação do JSON na borda e bundle estático capaz de hospedar em subpastas. Build pode ser feito com assets pré-compilados, mas isso não prova funcionamento em cada hospedagem.

Separação guia e firmware

CONFIRMADO: o código de firmware real vem do repositório irmão `agharsallah/esp-labs` durante o build; `FIRMWARE_DIR` seleciona o checkout. O README informa que lessons, simuladores e bench log continuam sem esse checkout, enquanto leitor de código fica sem fonte. A cópia distribuída pode incorporar código derivado de outro repo; a licença do firmware, avisos e correspondência de versões precisam ser verificados junto ao repo irmão antes de redistribuir. Não houve esse exame jurídico.

Persistência, conta e telemetria

CONFIRMADO no código e SECURITY.md: aplicação não declara servidor próprio ou contas; progresso e preferências persistem no navegador via `localStorage`, com leituras/escritas protegidas contra exceções e degradação sem persistência. `VercelInsights.tsx` monta Web Analytics e Speed Insights somente em builds Vercel e remapeia URL hash; portanto, instâncias locais não carregam esses componentes, mas a hospedada coleta métricas via Vercel. A política de segurança caracteriza dados como locais; essa declaração deve ser lida com a exceção explícita da telemetria de hospedagem.

Experimentos e limites pedagógicos

ANÁLISE: simulador de serial e tour de código podem tornar observável uma lição sem placa conectada, mas a simulação não valida temporização, tensão, comportamento elétrico, firmware compilado ou periféricos físicos. O guia também descreve comandos a gravar no hardware; quem seguir instruções deve conferir a revisão da placa e datasheet. README lembra que layout dos pinos é específico de DevKitC-1 e que rótulos da placa prevalecem.

Acessibilidade e internacionalização

CONFIRMADO: documentação i18n lista 11 idiomas (inglês, francês, espanhol, italiano, alemão, polonês, turco, chinês simplificado e tradicional, japonês e árabe RTL), com overlays JSON, chaves tipadas e validação de catálogos. README declara suporte a telefone, tema claro/escuro e reduced motion. São contratos/alegações do projeto; navegação com teclado, leitor de tela, tradução real e qualidade RTL não foram testadas visualmente.

Segurança e dependências

RELATADO: SECURITY.md classifica a aplicação como site estático sem servidor e oferece reporte privado; riscos incluem execução de script a partir de lição, tradução ou parâmetro `?lang=`, segredo vazado e dependência comprometida. O pacote fixa versões de muitas dependências e declara Node >=24.14/pnpm 11.10.0; fixação reduz deriva involuntária, mas não prova ausência de vulnerabilidades nem manutenção das versões. Não foi feita auditoria da cadeia de suprimento.

Licença, hosting e operação

CONFIRMADO: LICENSE MIT para este repositório. README descreve Vercel e deploy prebuilt porque a etapa de bundle do leitor depende do checkout externo; deploy Git-triggered está desativado no `vercel.json`. Conta, login, projeto Vercel, analytics e velocidade podem gerar termos/custos próprios. Componentes de firmware e fontes de datasheet precisam ser tratados em separado do MIT da aplicação web.

Manutenção e métricas

CONFIRMADO no snapshot REST público de 2026-11-03: 645 stars, 95 forks, 2 issues abertas, TypeScript, repositório ativo e não arquivado; o commit de código consultado é d716cc7890732bcd04887a2d5822912fb2d59aff, com atualização de documentação em 30/10. GitHub define stars como bookmarks/marcações de usuários e forks como cópias do repo; issue count não confirma bugs. Resultado indexado retornou 190/31, mas a página HTML direta do perfil ordenado por estrelas e a REST API consultadas na mesma data corroboram 645/95; trato o crawl como cache antigo, sem reconstruir série histórica. Nenhum release foi encontrado na consulta da API.

Aderência ao Lab

ANÁLISE: bom exemplo de documentação didática em forma de aplicação estática, com conteúdo modular, validação de dados e dados de progresso locais. Para o Lab, o padrão transferível é a separação entre domínio/lessons, widget visual e transporte de dados, não uma dependência de Vercel nem a simulação como prova de hardware. Possíveis adaptações requerem avaliar licenças e direitos do firmware/documentação.

Ensaios propostos

PROPOSTA: conferir uma lição com placa física correspondente e datasheet; comparar saída real e simulada; interromper/iniciar monitor serial; verificar armazenamento e privacidade do navegador; executar build com e sem repo irmão e reconciliar conteúdo e licença; testar idiomas/RTL, 390px, reduced motion, teclado e leitor de tela; em Vercel, medir chamadas e payloads de analytics. Essas provas não foram feitas.

Limites da pesquisa

Somente documentação e leitura estática pontual foram consultadas. Não houve instalação, build, execução, simulação, conexão física, telemetria de rede, QA de acessibilidade, auditoria de licença do firmware, inspeção da conta Vercel ou reprodução de métricas divergentes. Stars/forks são snapshots e não evidência de qualidade técnica.

Natureza do item

CONFIRMADO: a referência do manifesto aponta para a página de perfil do usuário com aba de repositórios classificada por estrelas; não aponta para repositório. Este relatório descreve um catálogo público de projetos e não herda nem substitui o registro específico de `agharsallah/esp-labs-web` (#37).

Métricas de perfil

CONFIRMADO no endpoint público de usuário em 2026-11-03: login `agharsallah`, 63 repositórios públicos, 41 seguidores e 8 seguidos; o perfil indica criação em 2016. Followers/seguindo são contagens no snapshot, sujeitas a mudança. Não inferir atividade, reputação, localização ou identidade fora desses campos públicos.

Ordem por estrelas e projetos de topo

CONFIRMADO na página HTML solicitada: lista ordenada por stars coloca esp-labs-web (645), opus-video (49), esp-labs (18), framio (4), seo-engine-skills (3), depois bookshelf, papers-hackathon, All-Data e tunihack (2 cada), entre outros. A página mostra estrelas e alguns forks; contagens ausentes na extração não foram tratadas como zero. GitHub define stars como marcadores/bookmarks que expressam interesse aproximado e forks como cópias derivadas do projeto; nenhuma métrica avalia qualidade, manutenção, segurança ou uso real.

Padrões temáticos visíveis

ANÁLISE limitada às descrições e metadados públicos: há projetos recentes de ESP32/IoT e web educacional, um app Android, utilitários de vídeo, exemplos de modelos/agentes e repositórios de dados/visualização, além de projetos legados. Essa diversidade temática não demonstra relação entre projetos, estado de suporte ou stack comum. Os repositórios devem ser avaliados separadamente antes de qualquer comparação técnica.

Atividade e continuidade

CONFIRMADO: a lista pública contém múltiplos repos com pushes em 2026-10/11 e outros cuja última atualização remonta a 2016–2018; o intervalo reflete um portfólio misto, não uma política formal de manutenção. O endpoint retornou 63 entradas. Não foi auditado se cada repo arquiva, tem releases, issue response, CI verde ou roadmap atual.

Linguagens e campos

CONFIRMADO no inventário API atual: linguagens majoritárias reportadas incluem JavaScript (32), Python (6), CSS (6) e HTML (4), com C#, C++, Kotlin e TypeScript em uma entrada cada; 11 entradas sem linguagem identificada pelo GitHub. A métrica de linguagem representa classificação automática por arquivos do GitHub, não domínio de expertise nem proporção precisa de esforço.

Significado das stars, forks e seguidores

CONFIRMADO pela documentação GitHub: stars funcionam como marcadores e sinal de interesse aproximado; forks indicam cópias derivadas no GitHub, e followers contam contas que seguem o perfil. São sinais de descoberta e participação, mas não critérios de confiabilidade. Contagem no perfil não deve ser somada como usuários únicos nem tratada como tráfego, adoção comercial ou avaliação de código.

Pertinência ao Lab

ANÁLISE: o perfil ajuda a localizar linhas públicas de trabalho ligadas ao tema ESP32 e produtos educacionais, que são detalhados em registros próprios. Seu valor é contextualizar a procedência e a vizinhança do repo, não servir como evidência de qualidade de cada projeto. Estrelas no perfil não justificam preferência ou adoção.

Limites de fonte e ordenação

A ordenação foi conferida na página HTML autenticada como pública; a API listagem `/users/{user}/repos` aceita outros critérios e não documenta `stargazers` como sort. Uma chamada API com esse query param não deve ser usada isoladamente para provar ranking. Resultados indexados por mecanismos de busca podem estar defasados; para o mesmo repo esp-labs-web, um crawl anterior mostrava 190 stars e 31 forks, enquanto página/API consultadas agora mostraram 645/95. A discrepância foi resolvida para o snapshot presente pela página direta, sem reconstruir a série histórica.

Próximos passos e limites éticos

PROPOSTA: quando a análise de um projeto específico importar, abrir o registro correspondente do manifesto, fixar SHA, licença, README, código relevante, releases/issues e métricas em data própria. Para atualizar o perfil, capturar a lista diretamente e anotar filtros/paginação; não inferir dados privados, biografia, identidade civil além do nome de exibição, intenção ou vínculo entre autores. Nenhum projeto foi executado e não foi feita avaliação de pessoa.

Objeto e escopo declarado

RELATADO pelo repositório: três partes principais — PDF cronológico, fontes citadas espelhadas em traduções de domínio público quando disponíveis, e leitor web pesquisável. O dossiê declara 175 entradas biográficas, 100 conexões escriturísticas, 238 referências numeradas e corte de pesquisa em 26/10/2026. O título de ‘all historical evidence’ é branding; o tamanho finito da seleção e o corte temporal não demonstram exaustividade.

Composição do arquivo

CONFIRMADO no README e catalog.json: dez coleções — dossiê, Escrituras, evangelhos fora do cânone, Padres da Igreja, testemunhos antigos, documentos legais/administrativos, arqueologia/artefatos, declarações institucionais, registro de evangelhos e fichas de referências. As contagens listadas somam 335 documentos, incluindo 238 fichas. A categoria documental inclui gêneros, épocas e objetivos diferentes; não se deve tratar cada item como evidência histórica independente ou equivalente.

Mecanismo de referência

CONFIRMADO: README diz que destinos de links foram retirados do PDF e as coleções `refs.json`, `links.json` e `links-report.md` os registram e associam a entradas espelhadas. Uma ficha (A01) identifica a referência NASSCAL/e-Clavis, o uso que o dossiê declara fazer e onde é citada. Assim a estrutura ajuda a rastrear a cadeia de alegação; a ficha continua sendo resumo do autor, não validação independente do conteúdo citado.

Interface e arquitetura

CONFIRMADO: leitor é HTML/CSS/JavaScript estático sem dependências, carrega um catálogo JSON e documentos por demanda, oferece navegação por coleções, busca e rotas hash. O código usa uma função de escape para texto que será inserido no DOM e mantém preferência de tema em localStorage. README declara painel de leitura, cartões de preview, lista de fontes filtrável e fallback `404.html` para caminhos profundos. Leitura do código não comprova segurança de todo conteúdo, uso offline, acessibilidade ou comportamento em navegadores reais.

Qualidade historiográfica e separação de alegações

ANÁLISE: a documentação distingue alegação do dossiê e identificação da referência, mas não fornece neste recorte um protocolo acadêmico completo de seleção, crítica textual, datação, autenticidade, transmissão manuscrita, divergências de tradução e consenso por especialista. Fontes literárias, religiosas, legais e arqueológicas exigem contextos próprios. O fato de uma inscrição, texto antigo ou página moderna aparecer na coleção não prova a interpretação histórica apresentada pelo dossiê. Esta pesquisa não confirma nem refuta afirmações teológicas ou históricas sobre Jesus.

Traduções, direitos e proveniência

README afirma que traduções de domínio público são espelhadas quando disponíveis; catalog.json atribui explicitamente a World English Bible a condição de domínio público e menciona traduções do século XIX em parte de Padres da Igreja. O repositório não tem licença reconhecida pelos metadados GitHub. Direitos de tradução moderna, imagens, PDF, textos editoriais, dados incorporados e conteúdo de terceiros precisam ser identificados por item; ausência de licença repo não autoriza reutilização integral. Não foi feito clearance de direitos.

Maturidade, atualização e métricas

CONFIRMADO no snapshot público 2026-11-03: 238 stars, 13 forks, nenhuma issue aberta, Python como linguagem reportada, branch main, não arquivado; último push 27/10 e atualização de metadados 2/11. GitHub define stars como marcações/bookmarks de usuários e forks como cópias derivadas do repositório; a ausência de issues abertas não avalia qualidade. A API reporta licença `null`; não encontrei release na consulta. Como o repo surgiu no fim de outubro e o corte do dossiê é de 26/10, são dados muito recentes. Métricas não certificam qualidade editorial, autoria das fontes, manutenção ou revisão por pares.

Pertinência ao Lab

ANÁLISE: tecnicamente, é um exemplo de corpus estruturado, cards navegáveis e ligações entre texto de síntese e evidência. O padrão transferível para o Lab é explicitar que conclusão cada fonte suporta e manter rotas rastreáveis; o conteúdo específico é controverso e requer contexto especializado. Evitar apresentar a coleção como índice neutro, universal ou validado por consenso sem revisão historiográfica independente.

Ensaios propostos

PROPOSTA: escolher amostra estratificada de fontes pagãs, cristãs, manuscritos, arqueologia e fontes modernas; abrir cada documento de origem, verificar edição/tradução, datação e cadeia de referência; comparar citação do PDF com trecho fonte e registrar suporte, limite e desacordo acadêmico. Checar reconciliação dos 238 destinos por script, inventário de direitos, proveniência dos espelhos, sanitização/renderização, teclado/leitor de tela e links profundos. Nenhum desses ensaios ou revisão por historiador foi feito.

Limites da pesquisa

A avaliação é documental e técnica, baseada em README, catálogo, uma ficha de referência e amostra da aplicação JS no SHA. Não foram lidos os 335 documentos, os 238 itens ou o PDF integral; nenhuma fonte externa primária foi cotejada e não houve avaliação por especialista, instalação, QA, teste de segurança, análise de acessibilidade, conferência de direitos ou aceite.

Categorias de evidência heterogêneas

ANÁLISE: o catálogo inclui evangelhos canônicos e não canônicos, autores cristãos antigos, testemunhos não cristãos, atos administrativos, inscrições, artefatos e posicionamentos institucionais modernos. Esses itens não têm a mesma distância temporal, tipo de testemunho ou pergunta que conseguem responder. Fontes devocionais ou teológicas podem documentar crenças e comunidades, mas não se convertem automaticamente em testemunho independente; objetos arqueológicos precisam de contexto de escavação e cadeia de custódia. O leitor web organiza navegação, não equaliza valor probatório.

Padrão de revisão acadêmica não identificado

NÃO IDENTIFICADO na amostra consultada: declaração de revisão por pares, conselho editorial, autores/especialistas responsáveis por cada domínio, protocolo de crítica textual ou tabela de consenso/divergência. Essa ausência na amostra não prova que não exista em outra parte do projeto, mas impede tratar o dossiê como produto academicamente revisado sem evidência adicional. Para uma versão comparativa, separar: texto literal, identificação/edição, proposição do dossiê, avaliações acadêmicas publicadas e grau de concordância.