raise-sync · diff
git:20260908.2ec1bf8 to v1.0.0
30 added, 49 removed. Audit B to B.
---
name: raise-sync
- description: >-
- Recover a fleet whose machines cannot see each other over the file-sync network: establish
- ground truth at the hub from the live sync API rather than memory or one peer's claim, publish
- the hub's verified device id over the messaging rail, and walk each disconnected peer through
- re-pairing. Triggers: "/raise-sync", "sync is down", "machines cannot see each other".
- license: MIT
+ description: "ACTIVE recovery when machines can't see each other over Syncthing — the “raise the sync“ runbook as one command. Trigger on “/raise-sync“, “подними синк“, “синк лёг“, “компы не видят друг друга“, “восстанови связь машин“, “raise the sync“, “sync down“, “fix the sync“, “re-pair the hub“"
+ version: 1.0.0
---
- # /raise-sync — raise the sync when machines can't see each other
+ # /raise-sync — поднять синк, когда машины не видят друг друга
- 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).
+ Активный runbook на ЧП «потеря синка» (полный канон + почему = Библия [[reglament-chp-poterya-sinka-mezhdu-mashinami]]). Принцип: **истину устанавливаем по ЖИВОМУ API хаба, а не по памяти и не по словам одного пира** (пир может держать устаревшую запись — так ноут однажды уверенно звал «верни 2KPYBY4», что сломало бы [коллега]).
- 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`.
+ Аккаунт/группа шины и ключ — из `~/.claude/tg_bus.json` (Telegram) и env `STGUIAPIKEY` (Syncthing API). Хаб LAN = `192.168.1.140:22000`.
- ## Step 0 — Detect (where does it hurt)
+ ## Шаг 0 — Детект (где болит)
```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.
+ (Или быстрый красный/зелёный — скилл `/sync-check`.) Кто `connected:false` = отвалился.
- ## Step 1 — Ground truth AT THE HUB (facts, not memory)
+ ## Шаг 1 — Истина НА ХАБЕ (факты, не память)
```bash
- # the hub's myID (must match machines.json HUB-1 = EEAETB6...)
+ # myID хаба (должен совпасть с machines.json [машина флота] = 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).
+ - Если `myID` НЕ совпадает с реестром / папки пустые → демон поднят на ЧУЖОМ home: **чини home (тот, где родной cert.pem + папки), НЕ пере-паривай пиров на временный ID.**
+ - Если `myID` совпадает и папки реальные → личность легитимна, проблема на стороне пиров (устаревшая запись хаба).
- ## 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.
+ ## Шаг 2 — Сверка с реестром (детект дрейфа)
+ Сравни live `myID` с `[шина]/machines.json` (поле `deviceID` хаба). Расходится без явной миграции = подозрение; совпадает = публикуем как канон.
- ## 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`):
+ ## Шаг 3 — Опубликуй VERIFIED Device ID хаба в шину (out-of-band пруф)
+ Через Telegram-MCP (`chat_id`/`account` из `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.
+ 🤖 [<хаб> -> ALL] hub <имя> = <EEAETB6-полный-ID>, addr tcp://192.168.1.140:22000. VERIFIED живым API (серверит весь волт). Пиры: впишите этот ID, удалите устаревший, рестарт демона, рапорт 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-->
-
- ---
+ Это снимает Tier-2-гейт пира («вписать чужой ID = отдать волт») — пир получил доказательство со стороны самого хаба.
- **Like this skill?** It is one of 100 in [second-brain-starter-kit](https://github.com/tonydzi/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.
+ ## Шаг 4 — Веди пиров (они чинят у себя; я не могу реконфигурить чужой Syncthing)
+ Каждому disconnected: впиши хаб = verified ID, верный адрес, **удали устаревший ID** (частая грабля — фантомный старый → «Hello → forcibly closed / unknown device»), рестарт демона штатным сторожем → рапорт `🤖 [пир -> хаб] connected` или что мешает.
- Flagships worth a look on their own: [secondop-panel](https://github.com/tonydzi/secondop-panel) (a second opinion from a panel of external models), [claude-memory-tidy](https://github.com/tonydzi/claude-memory-tidy) (stop your agent's memory from rotting), [telegram-mcp-kit](https://github.com/tonydzi/telegram-mcp-kit) (your own Telegram over MCP in about 15 minutes).
+ ## Шаг 5 — Проверь
+ Повтори Шаг 0: все `connected:true`, бэклог качается (`needFiles` падает). Доложи Антону состав.
- Author: **Anton Dziatkovskii**, Palo Alto AI Research Lab. Telegram [@tonydzi](https://t.me/tonydzi) - WhatsApp [+1 341 222 9178](https://wa.me/13412229178) - X [@Tony_Stef_](https://x.com/Tony_Stef_)
+ ## Анти-грабли (выучено кровью 2026-06)
+ - НЕ верь ОДНОМУ пиру в диагнозе идентичности — источник истины = живой API хаба.
+ - НЕ откатывай хаб на старый ID, если другой пир уже работает на новом (сломаешь работающего).
+ - Сторож с «зависанием» → сперва проверь слой видимости (логи/ключ/403), а не ядро.
- **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.
+ ## Связанное
+ - `/sync-check` — read-only статус (детект). Этот скилл — РЕКАВЕРИ.
+ - Dead-man-switch `sync_monitor.py` (задача «Claude Sync Monitor») пингует Антона при отвале пира → часто `/raise-sync` стартует ПО его пингу.
+ - Канон: [[reglament-chp-poterya-sinka-mezhdu-mashinami]], [[machine-bus-telegram-rail]], [[syncthing-v21-gotchas]].