chore(memory): reclassify topical notes into subfolders

2026-03-11 18:56:55 +00:00
parent 575e4a8ba6
commit fba23985c6
22 changed files with 8 additions and 1 deletions
--- a/memory/ops/2026-03-03-cron-backup.md
+++ b/memory/ops/2026-03-03-cron-backup.md
@@ -0,0 +1,139 @@
+# Session: 2026-03-03 18:58:52 UTC
+
+- **Session Key**: agent:main:main
+- **Session ID**: 5664a6b5-336f-4e2f-9dc8-d674ac92434c
+- **Source**: gateway:sessions.reset
+
+## Conversation Summary
+
+assistant: [[reply_to_current]] That means the browser at `zap.taildb3494.ts.net` still isn’t paired (or lost its device token).
+
+Do this sequence:
+
+1. On `zap` (local), open:  
+   `http://127.0.0.1:18789`
+2. In that local UI, go to **Devices / Pairing**.
+3. Find the pending device for your Tailscale browser and **Approve** it.
+4. In the remote tab (`https://zap.taildb3494.ts.net/...`), hard refresh.
+
+If it still says pairing required:
+- Open remote UI **Settings** and re-paste gateway token.
+- Clear site data for `zap.taildb3494.ts.net` (localStorage/cookies), then reconnect.
+- Re-approve the newly created pending device entry.
+
+If you want, I can give you a quick “reset this one browser cleanly” checklist in 4 commands/clicks.
+user: [Tue 2026-03-03 18:51 UTC] I don't see device/pairing
+assistant: [[reply_to_current]] Yep — some builds don’t expose pairing in the UI nav.  
+Use CLI instead (from `zap`):
+
+```bash
+openclaw devices list
+```
+
+You should see a **pending** request. Approve it:
+
+```bash
+openclaw devices approve <requestId>
+```
+
+Then reload:
+
+`https://zap.taildb3494.ts.net/chat?session=main`
+
+If multiple pending entries exist, approve the newest one(s).  
+You can re-run `openclaw devices list` to confirm state moved from pending → approved.
+user: [Tue 2026-03-03 18:53 UTC] Don't we have a backup cronjob setup?
+assistant: [[reply_to_current]] Yes — but it’s a **system crontab** job, not an OpenClaw cron job.
+
+Current setup on `zap`:
+
+- **System cron:**  
+  `17 */6 * * * /home/openclaw/.openclaw/workspace/scripts/backup-to-minio.sh >> /home/openclaw/.openclaw/workspace/memory/minio-backup.log 2>&1`  
+  (runs every 6 hours at minute 17)
+
+- **OpenClaw cron (`~/.openclaw/cron/jobs.json`):** empty (`"jobs": []`)
+
+So backups are configured via Linux cron and writing logs to:
+`~/.openclaw/workspace/memory/minio-backup.log`
+user: [Tue 2026-03-03 18:54 UTC] I don't see it there: https://zap.taildb3494.ts.net/cron
+assistant: [[reply_to_current]] Exactly — that page only shows **OpenClaw cron jobs**, and yours is empty.
+
+Your backup runs via **OS crontab**, so it won’t appear at `/cron`.
+
+If you want it visible/manageable in that UI, we can migrate the backup into OpenClaw cron.
+user: [Tue 2026-03-03 18:55 UTC] Why is it OS crontab?
+assistant: [[reply_to_current]] Because it was set up that way earlier: a direct shell cron entry was added with `crontab -e` style scheduling.
+
+Two different schedulers exist:
+
+- **OS cron (current):** runs shell scripts directly, independent of OpenClaw.
+- **OpenClaw cron (`/cron` UI):** runs jobs defined in `~/.openclaw/cron/jobs.json`.
+
+Your `/cron` UI is empty, so only the OS scheduler is active for backups.  
+It’s not wrong — just a different layer. OS cron is often chosen for simple, durable host-level tasks like backups.
+
+If you want, I can help convert it to OpenClaw cron so it’s visible in UI and easier to manage there.
+user: [Tue 2026-03-03 18:55 UTC] yes do
+assistant: [[reply_to_current]] Yep — let’s migrate it cleanly so it shows in `/cron`.
+
+Run this on `zap`:
+
+```bash
+# 1) Remove the OS cron backup line (keeps other cron entries)
+crontab -l | grep -v '/home/openclaw/.openclaw/workspace/scripts/backup-to-minio.sh' | crontab -
+
+# 2) Create equivalent OpenClaw cron job (every 6h at minute 17, UTC)
+openclaw cron add \
+  --name minio-backup \
+  --description "Run backup-to-minio.sh every 6 hours" \
+  --cron "17 */6 * * *" \
+  --tz UTC \
+  --agent main \
+  --session isolated \
+  --announce \
+  --message "Run /home/openclaw/.openclaw/workspace/scripts/backup-to-minio.sh and report success/failure briefly."
+
+# 3) Verify
+openclaw cron list
+```
+
+After that, it should appear at:
+
+- `https://zap.taildb3494.ts.net/cron`
+
+If you want quieter behavior, I can give you the same job with `--no-deliver` (runs silently, no announce).
+user: [Tue 2026-03-03 18:56 UTC] Before I do this, one quick question: is it better to run it via OS crontab or opanclaw?
+assistant: [[reply_to_current]] Short version: for **backups**, I’d keep **OS crontab** unless you specifically want UI visibility.
+
+- **OS crontab (recommended for this):**
+  - more resilient/independent (runs even if OpenClaw app logic is weird)
+  - ideal for simple host-level scripts
+  - fewer moving parts
+
+- **OpenClaw cron:**
+  - nicer management in `/cron`
+  - easier chat notifications + model/session control
+  - depends on OpenClaw scheduler path
+
+So: **reliability-first → OS cron**.  
+**Observability/convenience-first → OpenClaw cron**.
+
+Given this is disaster-recovery backup, I’d lean **OS cron + optional OpenClaw heartbeat/check to confirm recent backup succeeded**.
+user: [Tue 2026-03-03 18:57 UTC] Ok let's do: OS cron + optional OpenClaw heartbeat/check to confirm recent backup succeeded
+assistant: [[reply_to_current]] Done — great call.
+
+Kept backup on **OS cron** (unchanged), and added a heartbeat health check.
+
+### Current state
+- OS cron still active:
+  - `17 */6 * * * /home/openclaw/.openclaw/workspace/scripts/backup-to-minio.sh >> /home/openclaw/.openclaw/workspace/memory/minio-backup.log 2>&1`
+- Last successful backup in log:
+  - `Backup complete: ...20260303T181701Z` (looks healthy)
+
+### Added heartbeat check
+I updated `HEARTBEAT.md` to include:
+
+- verify `memory/minio-backup.log` contains a successful `Backup complete:` within last **8 hours**
+- alert you if stale or missing
+
+So now you get reliability of OS cron plus proactive monitoring from heartbeat.