O Claude leu o código completo de jet-ops (o ops panel em my.jetblip.com/ops) e de blip-research (my.jetblip.com/blip-research/). Identificou o que o ops tem que o blip-research não tem, e filtrou o que não faz sentido para um price tracker (email, campanhas, contactos = irrelevante).
O que ficou são 12 funcionalidades candidatas, organizadas em 4 grupos por valor esperado. Cada card explica em detalhe o que é a funcionalidade e porquê pode ou não fazer sentido no contexto do blip-research.
Actualmente as notas do operador são uma lista de pedidos de texto livre — o Claude lê-os mas não há forma de saber se foram concluídos ou não. A fila de tarefas é diferente: cada pedido é um item discreto com estado (pendente → em progresso → concluído), e o Claude actualiza esse estado ao realizar a pesquisa.
No ops panel, o equivalente é o TodoAI: cards com título, estado, notas do Claude durante execução, e histórico de itens completados.
Hoje o operador escreve notas e não sabe se o Claude as processou. Não há tracking de "esta sessão de pesquisa está feita". Com uma fila de tarefas, ficaria claro o que está por fazer, em progresso, e concluído — sem precisar de ler logs ou contar observações manualmente.
É a diferença entre "escrever post-its que talvez sejam lidos" e "ter um sistema de trabalho partilhado com o Claude".
research_tasks), 3 rotas API (criar, actualizar estado, listar), secção no dashboard. O Claude precisaria de chamar POST /api/task/<id>/update ao concluir cada pesquisa. Estimativa: 3–4h de trabalho.
Uma pequena secção no dashboard que mostra: quando foi a última vez que o Claude leu o estado (via GET /api/state), quantas notas existiam nessa altura, e se há notas novas desde então que o Claude ainda não viu.
No ops panel existe algo equivalente: "Claude status" com o trigger state, última sincronização, tamanho da fila.
Hoje o operador não sabe se o Claude "viu" as notas que escreveu. Com este painel, é imediatamente visível se há notas por processar. Também resolve a ansiedade de "será que o Claude vai pesquisar isto?".
Implementação simples: o Claude escreve um POST /api/heartbeat cada vez que lê o state — o dashboard mostra o timestamp.
operator_notes ou nova tabela claude_sessions (id, accessed_at, notes_seen), uma rota POST simples, e HTML mínimo no dashboard. Estimativa: 1h.
Na página de detalhe de um item (ex: "RAM DDR5 8GB"), em vez de apenas mostrar uma tabela de observações, aparece um mini gráfico de linhas mostrando como o preço variou ao longo do tempo para cada fonte (Amazon.fr, PCComponentes, etc.).
Pode ser simples: SVG gerado no servidor ou cliente, sem dependências externas. Não precisa de ser perfeito — mesmo uma sparkline básica já é muito mais informativa que uma lista de números.
O blip-research já guarda observações ao longo do tempo. Mas mostrar 20 linhas numa tabela não revela padrões. Um gráfico simples mostra imediatamente: "este item está a cair de preço" ou "esteve em OOS 2 semanas e voltou mais caro".
Para o objectivo do Thierry (comprar quando o preço for bom), saber a tendência é tão importante como saber o preço actual.
GET /api/items/<id>. Estimativa: 2–3h para uma implementação limpa.
Uma nova página (ex: /blip-research/best) que mostra, para cada item com observações, o melhor preço actual (observação mais recente com availability=in_stock), de que fonte, e quando foi verificado.
É a resposta rápida à pergunta "onde está mais barato isto agora?" sem precisar de percorrer itens individualmente.
No contexto do Thierry (comprar uma lista de componentes específica), a pergunta mais frequente é "qual é o preço certo de compra agora?". Esta vista responde directamente sem navegar por items + sessões separadamente.
É também a "resposta de 30 segundos" quando alguém pergunta "já podemos comprar?".
SELECT DISTINCT ON (item_id) ... ORDER BY item_id, observed_at DESC WHERE availability='in_stock'. Nova rota Flask e template. Estimativa: 1–2h.
Na lista de observações recentes, em vez de mostrar apenas o preço, mostra também a variação face à observação anterior na mesma fonte: ↓ -8% ou ↑ +3%.
O blip-research já detecta price drops (secção "Descidas de preço" no dashboard), mas não mostra a variação inline nas tabelas.
A secção "Descidas de preço" no dashboard já cobre o caso de uso principal. O indicador inline seria melhorar algo que já existe, não adicionar funcionalidade nova. Vale a pena se o blip-research crescer para muitos itens; por agora, com ~22 itens, o valor marginal é baixo.
Um botão "Exportar CSV" na página de items ou na dashboard que gera um ficheiro com todas as observações: item, fonte, preço, moeda, disponibilidade, data, sessão, URL.
O GET /api/state já devolve os dados em JSON. Alguém com acesso à API pode converter facilmente. O CSV seria útil se o operador quisesse partilhar dados com alguém sem acesso técnico, ou fazer análise avançada em Excel. Mas no contexto actual (uso pessoal do Jeremy), a API JSON é suficiente.
Adicionar quando houver um caso de uso concreto — não por antecipação.
Actualmente, a lista de items tem pesquisa por texto e filtro por categoria. Os filtros avançados permitiriam: "mostra todos os items da sessão thierry-laptop-fw, com disponibilidade in_stock, preço entre €0 e €100, fontes Amazon.fr e Amazon.de".
Com 22 items actuais, os filtros simples (texto + categoria) são suficientes. Os filtros avançados fazem sentido quando o DB crescer para centenas de items em múltiplas sessões. Adiar até que a necessidade apareça concretamente.
A API já tem o suficiente para o Claude fazer queries complexas directamente em SQL — os filtros avançados são principalmente para o operador navegar na UI.
Clicar no preço de uma observação abre um campo de edição inline. Corrigir e pressionar Enter guarda a alteração via AJAX, sem recarregar a página. Útil quando o Claude regista um preço errado (ex: erro de parsing).
A filosofia do blip-research é que o Claude é quem escreve, o operador é quem lê. Edição manual quebra o princípio de "o DB é fonte de verdade do Claude". Preferível: se uma observação está errada, o Claude cria uma nova observação correcta em vez de editar a antiga (auditability).
Mas se o operador quiser mesmo poder corrigir: fácil de implementar. A decisão é mais de filosofia do que de complexidade.
Um botão "apagar" em cada observação que adiciona um campo deleted_at à linha. As observações apagadas ficam excluídas das queries normais mas podem ser recuperadas. Igual ao padrão que o blip-scan já usa.
Actualmente com 103 observações não há problema de dados sujos que justifique urgência. Mas se o Claude registar dados errados frequentemente, a capacidade de limpar sem abrir o SQLite directamente seria útil. É um bom padrão a ter — mas não urgente agora.
Botão "⏸ Pausar refresh" no header. Quando activo, o auto-refresh de 30s para. O operador pode analisar os dados sem que a página "salte" com novo conteúdo. No ops panel, esta funcionalidade pausa o refresh por 8 horas.
O blip-research já tem auto-refresh de 30s — mais lento que o ops (90s). Em 30s o scroll não "salta" tanto. Mas se o operador estiver a analisar dados em detalhe e o refresh incomodar, este botão resolve. É 10 linhas de JS — trivial de adicionar se acontecer ser irritante.
Uma indicação (badge, cor) para cada item/fonte que diz "último check há 7 dias — pode estar desactualizado". Útil para saber quando os dados já não são fiáveis e é altura de o Claude re-pesquisar.
O blip-research tem 103 observações em 3 sessões activas. Os dados são relativamente recentes. Esta funcionalidade torna-se útil quando há muitas sessões e o operador perde o controlo de "quando é que isto foi verificado por último". Para o Thierry (uma compra específica, não monitorização contínua), não é prioritário.
Adicionar quando o blip-research passar de research pontual para monitorização de longo prazo.
Multi-select nas listas de observações/items com operações em lote: apagar X observações de uma vez, mover para outra sessão, exportar só as seleccionadas. No ops panel, o equivalente é o batch de emails (mark read, categorize, etc.).
Com 103 observações e uso primariamente via Claude (não entrada manual massiva), as operações em massa não têm um caso de uso imediato. É uma funcionalidade que faz sentido para data cleanup quando o DB cresce para milhares de registos. A complexidade de UI é alta — multi-select com checkboxes, estado partilhado, confirmações — para um benefício que ainda não existe.