chore: remove stray deb and sync memory

memory/2026-03-30.md

@@ -18,4 +18,46 @@
 - Merged old openclaw workspace from /mnt/data/old-openclaw/.openclaw/workspace.
 - Compared files: all memory-related files (MEMORY.md, memory/*.md, SOUL.md, USER.md, AGENTS.md, TOOLS.md, IDENTITY.md) were identical.
 - HEARTBEAT.md differed: old version contained only two comment lines; appended those lines as historical note to current HEARTBEAT.md.
-- No other actions required; workspace is synchronized.
+- No other actions required; workspace is synchronized.
+## 2026-03-30 Memory Flush (continued)
+
+- In Telegram group topic 289 (代码沙盒), user asked to fix git remote and push workspace repo to self-hosted Gitea.
+- Confirmed `.git/config` initially had no remote configured.
+- User’s Gitea SSH endpoint: `ssh://git@gitea.leexxx.com:61222/sinlee/openclaw-sync.git`.
+- A lot of early debugging was confounded by wrong local name resolution and environment mismatch:
+  - I initially saw `gitea.leexxx.com -> 198.18.9.204`.
+  - User later found they had mistakenly edited `/etc/host` instead of `/etc/hosts` on their side.
+  - After correction, intended mapping is `142.171.86.167 gitea.leexxx.com`.
+- Generated a new dedicated SSH public key for Gitea after user requested rotating key; user added it successfully in Gitea.
+- Server-side Docker/Gitea inspection from user showed:
+  - Container `gitea` published `61222->22/tcp` and `61000->3000/tcp`.
+  - Environment had a likely misconfig: `GITEA__server__SSH_PORT=2222` while external SSH port is `61222`; also one typo-like domain entry `GITEA__server__DOMAIN=gitea.leexxxx.com`.
+  - I advised user to align SSH/DOMAIN config and restart container.
+- Follow-up diagnostics from user proved Gitea SSH service itself is alive:
+  - `ssh -vT git@127.0.0.1 -p 61222` on the server completed key exchange and reached publickey auth.
+  - `docker logs gitea` showed `Server listening on :: port 22` and `Server listening on 0.0.0.0 port 22`.
+  - Logs also showed at least one successful authentication event from `142.171.86.167`: `Accepted publickey for git ...`, followed by internal `GET /api/internal/serv/none/2 200 OK` and disconnect.
+- Current state by end of conversation:
+  - SSH path is still unstable / not fully resolved for actual git push.
+  - We have not completed `git push` yet.
+  - Most likely remaining work: either test explicit `git-upload-pack` / `git-receive-pack` over SSH, or switch to HTTPS push with a fresh confirmed-valid Gitea token.
+- Important lesson: when Gitea SSH debugging shows `Accepted publickey` in server logs, distinguish plain `ssh -T` success from actual repository command success; don’t overfocus on repo path too early. Also verify actual `/etc/hosts` vs `/etc/host` and environment-visible name resolution sooner.
+
+## 2026-03-30 Memory Flush (continued)
+
+- Continued Gitea SSH troubleshooting in Telegram group topic 289.
+- User discovered mapped port `61222` was effectively the wrong path for reliable external SSH access; switching to `8022` worked for connectivity after user changed Gitea Docker config to stop using default OpenSSH path.
+- Important distinction observed:
+  - `61222` presented `remote software version OpenSSH_9.3` and behaved inconsistently.
+  - `8022` presented `remote software version Go`, matching Gitea's built-in SSH server.
+- New OpenClaw SSH key fingerprint used for tests: `SHA256:foswmV5bz4uCONXnoED3V86noD+efomTWwRjxjPQUPM` (`openclaw-sync@lee-gitea-20260330`).
+- Gitea logs initially showed this key as unknown on 8022 (`Unknown public key ... foswmV5...`), then user deleted/re-added SSH key in Gitea web UI.
+- After re-adding, SSH auth to `ssh://git@gitea.leexxx.com:8022/sinlee/openclaw-sync.git` succeeded (`Hi there, sinlee! You've successfully authenticated ...`).
+- Repository existence/path confirmed in Gitea UI: `sinlee/openclaw-sync` with clone URL `ssh://git@gitea.leexxx.com:8022/sinlee/openclaw-sync.git`.
+- Detailed Gitea logs during push showed:
+  - successful internal routing for `GET /api/internal/serv/command/6/sinlee/openclaw-sync?mode=2&verb=git-receive-pack`
+  - followed by `modules/ssh/ssh.go:136:func2() [E] Failed to write stdout to session. EOF`
+- Strong evidence that authentication and repo resolution are correct; remaining failure is in push streaming/session lifecycle, not permissions.
+- Client-side observation from my side: push transferred about 87 MB over ~59 seconds before process ended with SIGKILL, suggesting execution timeout / client-side session kill rather than a clean Git rejection from Gitea.
+- Current recommended approach: retry `git push` with a much longer execution timeout; if it still fails, inspect for large initial pack / session timeout issues rather than SSH key problems.
+- At last user message, user explicitly asked to continue and I began a long-timeout push attempt; final result was not yet known before compaction.

memory/heartbeat-state.json

@@ -1,7 +1,21 @@
 {
   "lastChecks": {
-    "system": 1774862675,
+    "system": 1774867856,
-    "health": 1774753106
+    "health": 1774753106,
+    "heartbeat_monitor": 1774875089
   },
-  "lastProactiveHealthSummary": 1774859157
+  "lastProactiveHealthSummary": 1774859157,
+  "lastTaskRun": {
+    "time": "2026-03-30T18:51:00+08:00",
+    "script": "/home/sinlee/monitor.sh",
+    "result": "CPU=10.7 MEM=28.6 DISK=5 LOAD=16h UPTIME=38m"
+  },
+  "lastCheck": 1774871484,
+  "lastResult": {
+    "timestamp": 1774875089,
+    "cpu": null,
+    "memory": null,
+    "exitCode": 0,
+    "output": "CPU=10.3 MEM=28.1 DISK=5 LOAD=18h UPTIME=38m"
+  }
 }