Registro de treino de página única, com persistência em SQLite no servidor (Val Town), em vez de localStorage.
main.ts— endpoint HTTP: serve o app e expõe as APIs REST do banco.frontend.html— interface (HTML/JS), idêntica ao app original.
| Método | Rota | Descrição |
|---|---|---|
| POST | /api/sessions | Salva uma sessão {dia, data, timestamp, exercicios} |
| GET | /api/sessions?day=A | Lista as sessões de um dia |
| POST | /api/last | Salva o último registro de um exercício {exId, kg, reps, data} |
| GET | /api/last/:exId | Lê o último registro de um exercício |
| GET | /api/status | Contagem de sessões e "últimos" (painel técnico) |
As chaves sessao:DIA:timestamp e ultimo:exId que antes viviam no localStorage agora são persistidas nas tabelas sessions e lasts do SQLite. O frontend chama esses endpoints via fetch. O visual, os cinco dias (A–E), o foco muscular, a edição de sessões, a data editável e a exportação/importação de texto (reserva manual) foram mantidos exatamente como no original.
Um cron diário (backup-cron.ts) tira um instantâneo completo do banco (sessions + lasts) e grava no blob do projeto como backup/snapshot-<ISO>.json, mantendo os 30 mais recentes (retenção automática).
- Criar snapshot:
backup.ts→runBackup() - Listar snapshots:
restore.ts→listSnapshots() - Restaurar:
restore.ts→restoreFromBackup(<key>)— repõe sessions e lasts no SQLite. ⚠️ Sobrescreve; só usar em emergência.
O backup é puramente aditivo: ele só lê o banco e grava um snapshot novo; nunca altera as tabelas existentes. O registro atual nunca é perdido por causa do backup.
Agendamento: 40 4 * * * UTC (≈ 01:40 Brasília), próximo em 2026-08-28 04:40 UTC.
backup.ts— lógica de snapshotbackup-cron.ts— cron diário que chamarunBackup()restore.ts— recuperação a partir de um snapshot