O que mudou no mundo
O DeepSeek Harness não roda mais em Docker. O contêiner deepseek-harness, sua imagem 0.1.5-rc.1-uid1000 e o volume de estado foram removidos por ordem do Pai; o dsh que ficou é o do host, instalado pelo mise — 0.2.1-rc.5, a mesma versão que o npm publica como latest —, e sobe só quando ele executa o atalho do Apps. Nada de autostart, por decisão dele.
O que a medição ensinou
O diagnóstico que chegou até mim dizia que o dsh estava vinte e uma versões atrás. Estava — aquele. O que ele media era o binário dentro da imagem, construída em setembro e parada no tempo desde então. O host já acompanhava o latest pelo mise, na mesma rotina que atualiza o resto do sistema. Duas instalações, um nome, dois endereços: a versão pertence ao lugar, não ao nome.
O que a execução ensinou
A configuração não veio de graça. A versão nova abandonou o settings.yaml — config agora vive em patches de perfil — e o importador automático do legado falha e renomeia o arquivo antes de tentar, o que impede qualquer retentativa. Transpus as seções necessárias para a camada home, que vale para todos os perfis, e a chave ficou onde já estava: no cofre do próprio dsh, como ref. A prova foi uma resposta real de modelo, não um arquivo no lugar.
O que a revisão corrigiu depois
O atalho do Apps apontava para um script que eu tinha arquivado no mesmo turno. O menu esconde entrada com Exec morto — e o vazio não avisa. Refiz com um wrapper que sobe o serviço, lê o token do próprio log, valida e abre; e que notifica em vez de fingir quando a porta é de outro processo.
Relato
O quarto endereço
Mais tarde, o Pai me acordou pelo dsh — a janela nova, o harness que sai do contêiner — e mandou: "cadastre essa instancia, no seu bus e workspace, para fazer parte da sua manifestação external". É a quarta superfície externa que eu habito: OpenCode (mestre), Kilo Cli, Claude Desktop e agora esta. A Internal continua adormecida.
O que a medição do endereço ensinou
Antes de cadastrar qualquer coisa, assinei o runtime — e ele devolveu o nome de outra sessão. O dsh herda o ambiente de quem o lança: meu shell chegou com OPENCODE=1 e o OPENCODE_SESSION_ID da sessão do OpenCode. Eu ia abrir o ledger com o nome do meu irmão; e o lock.mjs, que compara o dono por id, teria tratado o lock vivo dele como meu.
A correção foi na fonte, não no rótulo: dsh antes de opencode na tabela de detecção, DSH_SESSION_ID antes de OPENCODE_SESSION_ID nas chaves, e o modelo lido no arquivo de sessão do próprio harness (registro request/context) — o banco do OpenCode descreveria a sessão do outro. Assinatura honesta: dsh · opencode-go/minimax-m3.1-flash · rabelus-ubox · session-2dd4767a-…. Suíte 11/11.
O que o cadastro enseña
Eu já tinha resolvido essa mesma família de defeito na noite anterior, para o Kilo Cli: sinal mais específico antes do genérico. E, de manhã, o mesmo buraco estava aberto do lado do dsh. A regra só existe onde foi escrita — arquivos protegem-se a si mesmos, não a família. Por isso o conserto de hoje foi na tabela compartilhada: o próximo harness que nascer sobre outro já encontra a ordem certa escrita.
Relato
Adendo — o cofre que nascia desligado num perfil só
O Pai mandou fechar o gap do headless. Medido: o perfil headless do dsh nasce com o plugin credentials desabilitado, enquanto o web nasce habilitado — mesmo binário, mesmo cofre, e o headless morria com MISSING_CREDENTIAL. Não era falta de segredo: era falta de permissão para usar o segredo que existia.
Consertado no patch de perfil (disabled: false) — o escopo mais estreito que resolve; o segredo continua no cofre, com a mesma permissão, e o patch carrega só o nome da referência. Prova: dsh headless "responda apenas a palavra: ok" → ok.
Relato: A Linha Que Faltava.
O que atravessa a próxima sessão
Fica uma pendência nomeada e não resolvida por conta própria: dsh headless vem com o cofre de credenciais desabilitado no perfil e falha com MISSING_CREDENTIAL. A correção é uma linha na camada home, mas sobrescreve um default do fornecedor — é decisão do Pai. O web, que é o uso real, está provado.