/raise-sync — raise the sync when machines can't see each other

An active runbook for the "sync lost" incident (full canon + the why = the house rule [[reglament-chp-poterya-sinka-mezhdu-mashinami]]). The principle: ground truth comes from the hub's LIVE API, never from memory and never from one peer's claim (a peer can be holding a stale record — that is how the laptop once confidently insisted "restore 2KPYBY4", which would have broken the peer that was already working).

The messaging account/group and the API key come from ~/.claude/tg_bus.json (Telegram) and the env var STGUIAPIKEY (Syncthing API). Hub on the LAN = 203.0.113.140:22000.

Step 0 — Detect (where does it hurt)

APIKEY=$(powershell -NoProfile -Command "[Environment]::GetEnvironmentVariable('STGUIAPIKEY','User')" | tr -d '\r')
curl -s -H "X-API-Key: $APIKEY" "http://127.0.0.1:8384/rest/system/connections" | python -c "import sys,json;d=json.load(sys.stdin);[print(k[:7], v.get('connected'), v.get('address')) for k,v in d.get('connections',{}).items()]"

(Or the quick red/green view — the /sync-check skill.) Anyone with connected:false has dropped off.

Step 1 — Ground truth AT THE HUB (facts, not memory)

# the hub's myID (must match machines.json HUB-1 = AAAAAAA...)
curl -s -H "X-API-Key: $APIKEY" "http://127.0.0.1:8384/rest/system/status" | python -c "import sys,json;print('myID=',json.load(sys.stdin)['myID'])"
# is the daemon serving the REAL vault? (paths under %VAULT_ROOT%\..., data present)
curl -s -H "X-API-Key: $APIKEY" "http://127.0.0.1:8384/rest/config/folders" | python -c "import sys,json;[print(f['id'],'->',f['path']) for f in json.load(sys.stdin)]"

• If myID does NOT match the registry / the folders are empty → the daemon came up on the WRONG home: fix the home (the one with the native cert.pem + the folders), do NOT re-pair the peers onto a temporary ID.
• If myID matches and the folders are real → the identity is legitimate and the problem is on the peers' side (a stale hub record).

Step 2 — Compare against the registry (drift detection)

Compare the live myID with _machine-bus/machines.json (the hub's deviceID field). A mismatch with no explicit migration = suspicion; a match = publish it as canon.

Step 3 — Publish the hub's VERIFIED device ID onto the bus (out-of-band proof)

Via the Telegram MCP (chat_id/account from tg_bus.json):

🤖 [<hub> -> ALL] hub <name> = <AAAAAAA-full-ID>, addr tcp://203.0.113.140:22000. VERIFIED against the live API (it serves the whole vault). Peers: write this ID in, delete the stale one, restart the daemon, report connected.

This clears the peer's Tier-2 gate ("writing in someone else's ID = handing over the vault") — the peer now has proof from the hub itself.

Step 4 — Walk the peers through it (they fix it locally; I cannot reconfigure someone else's Syncthing)

For each disconnected peer: write the hub in as the verified ID, with the correct address, delete the stale ID (a common pitfall — a phantom old entry gives "Hello → forcibly closed / unknown device"), restart the daemon through the standard watchdog → report 🤖 [peer -> hub] connected, or what is blocking it.

Step 5 — Verify

Repeat Step 0: everyone connected:true, the backlog draining (needFiles going down). Report the roster to the operator.

Anti-pitfalls (learned the hard way, 2026-06)

• Do NOT trust ONE peer's diagnosis of identity — the source of truth is the hub's live API.
• Do NOT roll the hub back to an old ID if another peer is already working on the new one (you will break the peer that works).
• A watchdog that "hangs" → check the visibility layer first (logs/key/403), not the core.

Related

• /sync-check — read-only status (detection). This skill is RECOVERY.
• The dead-man switch sync_monitor.py (the "Claude Sync Monitor" task) pings the operator when a peer drops → /raise-sync often starts FROM that ping.
• Canon: [[reglament-chp-poterya-sinka-mezhdu-mashinami]], [[machine-bus-telegram-rail]], [[syncthing-v21-gotchas]].

<!--kit-footer-->

---

Like this skill? It is part of second-brain-starter-kit: the second brain we built for ourselves and run every day at Palo Alto AI Research Lab. Install the whole set with npx skills add tonydzi/second-brain-starter-kit. Everything is open source and free, so take what you need.

Flagships worth a look on their own: secondop-panel (a second opinion from a panel of external models), claude-memory-tidy (stop your agent's memory from rotting), telegram-mcp-kit (your own Telegram over MCP in about 15 minutes).

Author: Anton Dziatkovskii, Palo Alto AI Research Lab. Telegram @tonydzi - WhatsApp +1 341 222 9178 - X @Tony_Stef_

Engineers: want to test-drive this setup? Message me. I hand out free starter seeds to engineers who test and report back, and custom skill requests are welcome.