JetBlip Hub

Lexar NM620 1TB 2280 WeBuy PT €70 EM STOCK (verificado 2026-05-19). TLC NAND Gen3, 3300/2400 MB/s. Entrega ao domicílio, 5 anos garantia CeX. Busca exaustiva 2026-05-19 (sem filtro allStock, todas as páginas lidas): 1 resultado de 32 NVMe em stock — única opção 1TB disponível. 2TB: 1 opção a €240 (descartado). Histórico: Crucial P1 eBay.de €97,88 descartado, €27,88 mais caro. Falha anterior: filtro allStock WeBuy PT dá falsos negativos (ver RULES #12).

Pick: Samsung PM991A €15 EM STOCK (2026-05-19). Form factor 2280 — cabe no Argon NEO 5 (suporta 2230/2242/2260/2280). Não é 2230 como estava no plano original, mas é compatível.

Context 2026-05-19 — RPi5 já tem microSD 256GB A1 (100 MB/s):
O problema do microSD em servidor não é a velocidade sequencial — é o endurance e os IOPS de escrita aleatória. SQLite faz writes aleatórios constantes (WAL journal), e os microSDs não são dimensionados para isso. A1 é “Application Performance class 1” — mínimo para apps móveis, não para servidor com 8 serviços. Corrupção de SD card em RPi servers é extremamente comum e bem documentada.

Ainda vale comprar o NVMe €15?
• Sim — €15 é basicamente gratuito como seguro. Protege os dados SQLite até o M920q estar operacional.
• A janela de risco é semanas (tempo até M920q chegar + setup Proxmox + migração). Nesse período, o SD A1 pode corromper-se sob carga.
• Após migração para M920q, RPi5 fica como fallback leve — aí o SD A1 é adequado (sem SQLite constante).
• Veredicto: compra o NVMe €15. Não compra o Argon NEO 5 €42 sem ponderar (ver tarefa argon2).

Comprado 2026-05-19. Pedido #548899 WeBuy PT €67,50. Em trânsito via CTT.

Aguarda módulo #2 antes de instalar — os dois SO-DIMM devem ser instalados em simultâneo para activar dual-channel no M920q. Ver tarefa RAM #2 abaixo.

M920q suporta DDR4 SO-DIMM 2666MHz. 2 módulos para dual-channel. Módulo #1 (€67,50) já em trânsito CTT. WeBuy PT sem stock. Alternativas verificadas 2026-05-19 — ambas enviam para PT: Crucial 32GB (privado, sem devoluções) €105 + €10,49 envio; Micron PC4-3200AA (comercial, 30d devolução) €149 + €22 envio.

Verificado 2026-05-19: €42,39 Amazon.de (ASIN B0CVLBKZZX). Suporta M.2 2230/2242/2260/2280. Instalar PM991A 256GB dentro antes de fechar.

Reconsiderar 2026-05-19 — RPi5 já tem microSD + M920q a caminho:
Com o M920q a chegar, o RPi5 vai ser fallback secundario. O Argon NEO 5 a €42,39 é premium para um dispositivo secundário.

Opções:
• Opção A — Manter plano (Argon €42 + NVMe €15 = €57): RPi5 bem embalado, cooling integrado, NVMe boot. Justificado se quiseres o RPi5 como dispositivo permanente e bem cuidado a longo prazo.
• Opção B — Só M.2 HAT barato (~€10-15) + NVMe €15 = ~€25-30: Raspberry Pi M.2 HAT+ oficial (~€12 Farnell) ou terceiros (Amazon.de). Sem case novo — fica no case actual ou sem case. Conectividade PCIe igual.
• Opção C — Skip (só microSD até migração): Aceitar o risco SD card durante a janela de transição (semanas). Após migração, RPi5 como fallback leve — aí SD A1 é adequado.

Recomendação: Opção B se queres proteção mínima sem gastar muito. Opção C se M920q chegar em <4 semanas e confiares no backup geo-redundante (R2).

Aguardar RAM #2 antes de comprar. Pick i7-8700T (6c/12t, TDP 35W). Ver guia completo em serveru.html.

Pick recomendado: Waveshare UPS HAT (E) €45,73 — mais barato, 4×21700 ext. (mais autonomia), I2C monitoring.

Comparação (preços Amazon.es 2026-05-02):
• Waveshare €45,73 + 4×Samsung 21700 ~€16 = ~€62 total, maior capacidade.
• PiSugar €59,99: bateria integrada, zero config extra, mais simples.
• Geekworm X1205 €63,03: 9-18V DC input — só se alimentares de UPS de router.
• UGREEN 130W €53,10: powerbank passthrough — bom se precisares também de carregar T580.

Todos suportam shutdown seguro antes de bateria morrer. Research completo: 20260414-rpi5-ups-powerbank.md

1. Abrir Argon NEO 5 (4 parafusos na base).
2. Inserir PM991A no slot M.2 2280 com ângulo 30°, pressionar e aparafusar.
3. Fechar enclosure.
4. Ligar cabo flat ao RPi5 (conector PCIe FFC).
5. Ligar Argon NEO 5 ao RPi5 pelos GPIO.

Opção 1 — rpi-imager: Gravar Ubuntu 24.04 ARM64 directamente no NVMe via adaptador USB temporário.

Opção 2 — raspi-config: sudo raspi-config → Advanced Options → Boot Order → NVMe/USB Boot.

Verificar: lsblk deve mostrar /dev/nvme0n1.

PiSugar 3 Plus:
sudo curl https://cdn.pisugar.com/release/pisugar-power-manager.sh | bash
Web UI em http://<ip>:3000 — configurar threshold de carga e shutdown automático.

Waveshare UPS HAT (E):
Comunicação I2C. apt install python3-smbus. Ler registos I2C para V/A/%. Configurar systemd service para shutdown -h now quando bateria <5%. Ver wiki oficial para script Python de exemplo.

UGREEN 130W (powerbank passthrough):
Sem software necessário — ligar RPi5 à porta C do powerbank, powerbank à parede. Falta de luz → RPi5 continua. Verificar: desligar da parede e confirmar que RPi5 não reinicia.

Opção 1 (fresh — recomendado): Ubuntu 24.04 no NVMe + correr blip-init-rpi + restaurar SQLite DBs de backup.

Opção 2 (rsync): sudo rsync -axv / /mnt/nvme/ e ajustar /boot/cmdline.txt para apontar ao NVMe.

systemctl status blip-ask blip-ehr blip-prefs blip-receipts jet-scan blip-trash blip-jot labs

Testar: my.jetblip.com → todos os endpoints respondem?

Porquê é urgente: SQLite DBs (habits/medical/notes/prefs) estão só no RPi5. Casa incendiar = dados perdem-se. GitHub já cobre código — o que falta são os dados.

Arquitectura em camadas:
• Camada 1 — Código: já no GitHub ✓ (geo-redundante)
• Camada 2 — Configs (nginx/systemd/cloudflared): commit para git privado
• Camada 3 — Dados SQLite: restic → Cloudflare R2
• Camada 4 — VMs Proxmox: vzdump + restic → R2

Setup (RPi5 como orquestrador):
apt install restic
restic -r r2:BUCKET/rpi5 init

Script diário (3h):
restic backup /home/*/apps/*/data/*.sqlite /etc/nginx/sites-enabled/ /etc/systemd/system/blip-*.service --repo r2:BUCKET/rpi5

systemd timer: OnCalendar=03:00 + ping healthchecks.io após sucesso.

Custo: R2 free até 10GB/mês → provavelmente gratis para sempre (SQLite DBs tipicamente <500MB).

Tailscale warm standby (bónus): Quando laptop em França está online, RPi5 faz rsync automático via Tailscale: rsync -avz /data/sqlite/ 100.x.x.x:/backup/rpi5/ — recovery imediato sem precisar aceder à cloud.

Recovery (fogo/roubo): Qualquer máquina com internet → restic -r r2:BUCKET/rpi5 restore latest --target /tmp/restore → todos os dados em ~10 min.

Dispositivo local cold standby (layer adicional):
Ter um dispositivo local que liga, faz backup e desliga automaticamente é válido como Camada 2.
• O que protege: ransomware (dispositivo offline = imune a ataques), deleção acidental, corrupção
• O que NÃO protege: incêndio/roubo/inundação — mesmo edifício = mesmo risco → R2 cloud continua obrigatório
• Como implementar: Smart plug Schuko com API HTTP local — Shelly Plug M Gen3 €12,99 Amazon.de ↗ (verificado 2026-05-19, em stock, envia PT) → RPi5 envia power-on via REST API local (GET http://<ip>/rpc/Switch.Set?id=0&on=true) após backup R2 concluído → rsync para disco USB externo → RPi5 envia shutdown ao dispositivo → RPi5 envia power-off ao plug (on=false) após 5 min
• Nota: Shelly Plug M/S Gen3 = tomada Schuko (liga/desliga qualquer dispositivo). Não confundir com Shelly 1PM = relé inline para interior de caixa eléctrica.
• Ideal para: disco externo USB ou old RPi sempre desligado em casa
• Air-gap de facto: 99% do tempo offline = superficie de ataque práticamente zero

Stack de backup final — 3 layers recomendadas:
• Layer 1 — Cloudflare R2 (geo-redundante, sobrevive a incêndio, qualquer país, free 10GB)
• Layer 2 — Cold standby local (rápido, air-gapped, sem depêndencia de internet)
• Layer 3 — Tailscale rsync para laptop em França (warm standby quando online)
Recovery: <10 min via cold standby local — OU <15 min via R2 de qualquer lugar do mundo.

1. Parafuso inferior → levantar tampa.
2. Dois slots SO-DIMM visíveis. Inserir com ângulo 45°, pressionar até clickar.
3. Colocar nos dois slots para dual-channel (módulos idênticos).

Verificar: dmidecode --type memory após boot.

Tampa inferior removida (mesmo passo da RAM).
Slot M.2 2280 NVMe na placa.
Inserir NVMe com ângulo 30°, aparafusar parafuso M2.

Verificar no Proxmox: lsblk → nvme0n1 1TB disponível.

Slots de armazenamento M920q:
• M.2 2280 NVMe PCIe Gen3 ×4 — Lexar NM620 1TB aqui (primário Proxmox)
• Baia 2.5″ SATA — livre para SSD/HDD 2.5″ adicional
• USB3 ports — Toshiba HDWD220 2TB via enclosure externo (ver tarefa m920q-hdd abaixo)

Armazenamento PC grande — verificado 2026-05-19 (Get-PhysicalDisk):
• Kingston A2000 500GB NVMe (SA2000M8500G, PCIe Gen3 ×4, 2200/2000 MB/s) — atenção: alguns lotes usam QLC NAND (não anunciado pela Kingston). Bom para PC de secretaria (maioritariamente leituras); abaixo do Lexar NM620 TLC para servidor com VMs e Ollama.
• Toshiba HDWD220 2TB HDD (3.5″ SATA) — não cabe internamente no M920q mas funciona perfeitamente via USB3 enclosure externo (ELUTENG B0FSJJ91QW €15,99).

Configuração ótima (verificada): M920q: Lexar NM620 1TB NVMe (boot/VMs, TLC, 3300 MB/s) + Toshiba 2TB via USB3 enclosure fora da caixa (modelos Ollama, datasets, backups locais). PC grande: Kingston A2000 500GB NVMe mantido (suficiente para Windows + jogos).

Alternativa — swap PC grande → M920q (análise 2026-05-19):
Ideia: comprar Lexar 1TB para o PC grande, mover Kingston 500GB para o M920q em vez de comprar NVMe separado.

Constraint verificado: ASUS PRIME B365M-A tem só 1 slot M.2 → Lexar não adiciona ao Kingston, substitui. Requer clonagem.

Plano do swap (se escolheres esta opção):
1. Comprar Lexar NM620 1TB
2. Clonar Kingston 500GB → Lexar 1TB — Macrium Reflect Free (Windows, gratuito, clonagem sector a sector)
3. Verificar boot no Lexar antes de remover Kingston
4. Trocar M.2 no PC grande: remover Kingston, instalar Lexar 1TB
5. Kingston 500GB vai para o slot M.2 2280 do M920q (boot/VMs Proxmox)
6. Toshiba 2TB via ELUTENG USB3 enclosure (ver tarefa m920q-hdd)

Balanço do swap:
✓ PC grande: 500GB → 1TB (upgrade de capacidade sem custo extra de armazenamento)
✓ Reutilização de hardware existente — sem compra NVMe separado para M920q
✓ Kingston A2000 Gen3 NVMe adequado para Proxmox homelab (2200/2000 MB/s)
✗ Lexar NM620 TLC (melhor endurance para escritas) fica no desktop; Kingston potencialmente QLC fica no servidor — ao contrário do óptimo técnico
✗ 500GB mais apertado que 1TB para VMs; mitigação: Ollama models ficam na Toshiba 2TB via USB3 → 500GB dedicado a Proxmox + VMs é suficiente para homelab modesto

Veredito: Swap válido e económico para homelab. Setup “tecnicamente óptimo” = Lexar 1TB TLC no M920q (servidor). Swap = aceitar QLC no servidor em troca de eliminar compra separada e ganhar capacidade no PC grande. Para o volume de escritas de um homelab, a diferença é práticamente imperceptível.

Gravar ISO em USB com Rufus. Boot USB no M920q (F12 para menu). Instalar Proxmox no NVMe 1TB. Configurar rede bridged (vmbr0).

Opção A — LXC (recomendado): Container Debian 12 privilegiado + Docker. Mais leve.

Opção B — VM Ubuntu 24.04: Melhor isolamento, melhor para GPU futura.

Pick: LXC para blip-*, VM para Ollama.

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.2:3b
ollama run llama3.2:3b

i7-8700T: 8-12 tok/s (3B), 3-5 tok/s (8B). Ver benchmarks em serveru.html.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --authkey=<key>

Verificar: tailscale status → RPi5 + PC Windows + M920q todos ligados.

Ordem recomendada:
1. blip-ask → 2. blip-prefs + blip-receipts → 3. blip-ehr → 4. jet-scan + blip-trash → 5. labs.

RPi5 mantém tudo activo durante 1 semana como fallback. Actualizar cloudflared tunnel para M920q no final.

O que é e porquê: O HDD Toshiba HDWD220 2TB do PC grande (3.5″ SATA) não cabe internamente no M920q Tiny (só aceita 2.5″). Mas um enclosure USB3 resolve: o disco fica fora da caixa, ligado por USB3, e o M920q vê um disco externo normal.

O que é útil neste disco:
• Armazenar modelos Ollama grandes (LLaMA 13B = 8GB, 34B = 20GB) sem ocupar o NVMe 1TB
• Backups locais das SQLite DBs (segundo nível antes do Cloudflare R2)
• Datasets de treino, ISOs, snapshots Proxmox

O que NÃO fazer: Não colocar VM images no HDD externo — HDD SATA via USB tem latência demasiada para Proxmox (I/O aleatório lento). VMs ficam no NVMe 1TB.

Setup: Ligar ao USB3 do M920q. Formatar: mkfs.ext4 /dev/sda1. Montar em /mnt/bulk via /etc/fstab com UUID. Configurar Ollama: OLLAMA_MODELS=/mnt/bulk/ollama/models.

Single Rust binary, zero deps. Proxy entre terminal e Claude Code.

Descarregar binário da página de releases → adicionar ao PATH.
Uso: rtk claude <prompt>

Resultado: -60-90% token usage em comandos dev comuns.

Liga Claude Code, Cursor, Cline a providers gratuitos (Claude/GPT/Gemini). Auto-fallback + RTK -40% tokens adicional.

Instalar depois de rtk estar funcional. Configurar providers por ordem de preferência.

Pre-indexes código em grafo local para Claude Code. Menos tool calls, menos tokens, 100% local.

Por repo: npx codegraph index
Adicionar ao CLAUDE.md de cada repo relevante.

MCP server de code search. Indexa todo o codebase para qualquer agente.

npm install -g @zilliz/claude-context
Adicionar ao .claude/settings.json como MCP server.

Colecta métricas (CPU, RAM, disco, rede) e logs. Instalar no M920q + RPi5.
Configurar: /etc/telegraf/telegraf.conf → inputs: cpu, mem, disk, net, systemd_units.

Landing para blip-brain (AI Ops / rules engine).
Stack: React 19 + Vite 8 + Tailwind v4 + Framer Motion.
Actualmente template genérico.

Próximos passos: definir conteúdo blip-brain → design CRT-theme → deploy blip.jetblip.com.

Landing pessoal jeremytrindade.com.
Stack: React + TypeScript + Vite (template genérico).
Conteúdo: Jeremy Trinity da Trindade, plano de longo prazo executado em paralelo.
Referência visual: editorial, clean, tipografia forte.

Portfolio profissional operador.
Stack: React + TypeScript + Vite + métricas live + estética CRT-green dark.

Próximos passos: ligar métricas reais (repos, commits, services up) → hospedar em trinity.jetblip.com.

GitHub → blip-research → Settings → Danger Zone → Change visibility → Make private.

Claude não pode fazer isto (acção proibida por segurança). Fazer manualmente.

Actualizar blip-research/CLAUDE.md com:
• Current version + hardware atual
• NVMe e RAM comprados
• Ollama running + modelo
• Estado de compra actualizado

Fazer no fim de cada compra ou setup major.

blip-rules tem regras privadas (paths internos, IPs, etc.). blip-rules-oss = versão sanitizada para partilha.

Passos: 1. Auditar blip-rules linha a linha. 2. Extrair regras sem info sensível. 3. Publicar em blip-rules-oss.

Manter jet-uni actualizado com deadlines e progresso. Verificar assignments pendentes semanalmente.

RNCP40356 = diplôme niveau 6 (Licence) en France. Acompanhar progresso: documentos submetidos, validações pendentes, próxima sessão.

53 empresas FR+USA para estratégia L-1B. Actualizar: adicionar novas, remover fechadas ou irrelevantes, verificar estado de cada candidatura.