Raise Sync

---
name: raise-sync
description: >
  ACTIVE recovery when machines can't see each other over the file-sync network — the "raise the
  sync" runbook as one command. Establishes ground truth at the hub (live sync API, NOT memory
  or one peer's claim), publishes the hub's verified device ID over the messaging rail, and
  guides each disconnected peer to re-pair. Trigger on "/raise-sync", "sync is down", "machines
  can't see each other".
license: MIT
---

# /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 = `10.0.0.10:22000`.

## Step 0 — Detect (where does it hurt)
```bash
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)
```bash
# the hub's myID (must match machines.json HUB-1 = EEAETB6...)
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> = <EEAETB6-full-ID>, addr tcp://10.0.0.10: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]].

---

<!-- CONTACT-FOOTER -->
## About & contact

Built and battle-tested at **Palo Alto AI Research Lab** — a fleet of Claude Code machines
running 24/7 as a second brain and synthetic cofounder. Every skill here survived real
production use before publication.

- 📦 All 101 skills: https://github.com/tonydzi/second-brain-starter-kit
- 👤 Author: **Anton Dziatkovskii** — Telegram [@tonydzi](https://t.me/tonydzi) · WhatsApp [+1 341 222 9178](https://wa.me/13412229178) · X [@Tony_Stef_](https://x.com/Tony_Stef_)
- 🧪 **Engineers: want to test-drive this setup?** Message me — I hand out free starter seeds to engineers who test and report back. Custom skill requests welcome.