- Shipped
- 6 de setembro de 2026 às 18:24 UTC
- Author
- Kamo
- Commit
- 297c21f
ToolDock é montado em ToolProviders ABOVE AuthedChrome, deliberadamente, por isso nunca desmonta através de uma navegação -- o fato único que mantém o dactilografar vivo em cada janela de ferramentas. Não lidoProvider vive dentro de AuthedChrome, O que o torna um descendente da doca. Então useUnread() dentro de uma janela de ferramentas não joga. O Contexto Não- Lido é compilado com um padrão completo -- getUnread: () => 0, bySurface.sms: 0 -- e tudo construído sobre ele renderiza, parece correto, e relata zero para sempre. Dois ao vivo Consequências: - O novo crachá do softphone nunca teria aparecido. - SmsTool's markSmsRead call, adicionado especificamente para que o crachá SMS pudesse ir Para baixo assim como para cima, resolvido para o contexto padrão: um já resolvido Promete que não fez nada. A correção foi enviada e inerte. Novos smsUnreadStore + SmsUnreadSync são a mesma ponte ToolWindowUnreadSync e HexHeadUnreadSync já compila para a tira de tabulação e os hexheads: a loja de módulos livre de provedor lidos com usoSyncExternalStore, alimentado por um componente montado dentro AuthenticatedToolWrapper onde o provedor é real. Marcar- ler percorre o outro caminho como um CustomEvent, que é como cada dock-to-provider a mensagem já funciona. Ganhos de contexto não lidos `smsSessions' porque um leitor que tem de ENUMERAR não lido conversas não podem fazê-lo através do getUnread, que responde a uma chave de cada vez e precisa da identificação de que está a ser perguntado. O teste SmsTool estava a rodar o mecanismo quebrado -- ele ridicularizou o usoUnread e assevered markSmsRead foi chamado, que passa se o provedor é ou não acessível em tempo de execução. Ele agora dirige a loja e afirma o evento de saída, então falha se alguma coisa chegar ao contexto morto.