Biblioteca de leitura
Crie um cartão de histórico sem guardar segredos
Mantenha um histórico útil de consultas sobre quantização, separando credenciais, condições enviadas, observações das respostas e anotações do leitor.
Liste entradas públicas que podem ser repetidas
O cartão deve refletir o contrato dos filtros. No caderno proposto, registre os q, subreddit, author, kind, from, to, min_score, limit e page usados. Exemplo: q=quantization, subreddit=LocalLLaMA, limit=3, page=1. Preserve as datas enviadas como YYYY-MM-DD UTC. As entradas explicam condições, não provam o retorno de uma discussão específica; repeti-las não garante a mesma resposta mais tarde.
Trate essas entradas como campos sem credenciais, não como informações automaticamente inofensivas. Uma consulta pode nomear projeto privado; uma nota pode identificar alguém sem intenção de divulgá-lo. Decida o que guardar ou exportar, em vez de copiar o objeto inteiro. Exclua cabeçalhos de autenticação. Se salvar a resposta localmente, separe-a da consulta e registre quando veio; do contrário, um link de repetição pode parecer cópia arquivada do resultado original.
Separe o armazenamento de segredos
O backend que chama precisa acessar a chave guardada para enviar X-API-Key ou Authorization: Bearer. Um hash unidirecional não fornece essa credencial. Guarde a chave utilizável no armazenamento de segredos do servidor, fora de código do navegador, URLs, exportações e diagnósticos. O serviço guarda hash e prefixo para autenticar: é outra função. A chave completa aparece uma vez no cadastro ou regeneração, que invalida imediatamente a anterior. O histórico não deve virar cópia acidental da chave.
Diferencie a conta do leitor no aplicativo, a sessão do operador e a chave para recuperar dados. Chaves e saldos são específicos do tenant; mudar o host não valida chave de outro. Excluir credenciais reduz uma via de exposição, sem proteger consultas e notas contra todo problema de navegador ou acesso. Examine suas próprias decisões de armazenamento e compartilhamento. Não anuncie o cartão proposto como limite de segurança comprovado ou função de histórico fornecida pelo arquivo.
Guarde notas de interpretação
Separe observações de conclusões. Um cartão poderia informar três registros exibidos, um sem corpo utilizável e condições de memória ainda desconhecidas. É anotação ilustrativa, não resultado observado. Se guardar pagination.total, guarde pagination.relation e sinais de continuação e janela necessários. Limite inferior não é contagem exata. Nenhum desses campos mede relevância nem frequência do problema.
Permita explicar brevemente por que a referência foi mantida. Identifique o texto como nota do leitor, preserve a identidade disponível da fonte e não misture com citações. Campos podem faltar; referências a pais não completam a conversa. Reabrir resposta salva não precisa chamar a API, mas atualizar explicitamente é outra recuperação. Atualização bem-sucedida custa um crédito, inclusive vazia. Preserve separadamente uma atualização falha ou incerta, sem substituir a observação antiga por cartão vazio sem rótulo.
Revise os limites de retenção
Defina exclusão, exportação e expiração antes de apresentar histórico persistente. Remover o cartão apaga o que sua implementação guarda; não remove registro do arquivo, não fecha conta do serviço nem muda seus pagamentos. Limpar o navegador, perder o dispositivo ou ter restrições de armazenamento pode remover o histórico. Se oferecer sincronização ou cópias, descreva e teste como funções separadas. Não são endpoints do arquivo e este artigo não estabelece que estejam implementadas.
O serviço não define aqui prazo fixo de retenção de dados da conta; isso não promete acesso permanente ao arquivo. Uma consulta salva pode continuar compreensível se a fonte sumir, desde que diferencie observação antiga de recuperação nova. Revise segredos e notas sensíveis antes de exportar e deixe escolher o que reter. O produto útil é um registro rastreável de decisão, não garantia de validade indefinida dos dados, interpretação ou link.
