← всі звіти · daily-wiki-sync-task.md

Щоденний sync спільної пам'яті LLM Wiki

Ціль: тримати wiki в ag-wiki у git-синхроні між Desktop Claude (write) і VPS Claude (read), щоб обидва бачили одну пам'ять.

Ролі:

Desktop Claude (Windows) — єдиний writer. Оновлює .md-сторінки, робить commit+push.
VPS Claude (/srv/wiki на 31.131.26.203) — reader. Після кожного push підтягує через git pull --rebase.

Canonical origin: https://github.com/serhiivereschak/ag-wiki

Крок 0: Підготовка

Підстав поточну дату у форматі YYYY-MM-DD (наприклад 2026-04-21). Далі по тексту позначено {{DATE}} — ти замінюєш на реальну дату, НЕ копіюєш літерально.

Крок 1: Підключити директорію

Використай request_cowork_directory для: D:\Users\Sergey.Vereschak.DELTAMEDICAL\Documents\ag-wiki

Якщо доступ вже попередньо виданий в allowlist — пропусти.

Крок 2: Pull-rebase перед початком роботи

Перш ніж редагувати щось — підтягни останній стан з GitHub (там можуть бути коміти з VPS або попередніх ручних edit'ів):

cd D:\Users\Sergey.Vereschak.DELTAMEDICAL\Documents\ag-wiki
git fetch origin
git pull --rebase origin main

Якщо rebase падає на конфліктах — зупинись, абортни (git rebase --abort) і повідом користувача з git status виводом. Не намагайся автоматично резолвити.

Крок 3: Зібрати джерела оновлень

Прочитай:

.claude/skills/**/SKILL.md — усі скіли (mtime покаже свіжі)
Поточну сесію Desktop Claude (увесь доступний контекст цієї розмови)
ag-wiki/open-tasks.md — щоб знати що треба закрити

Критерій «свіже»: SKILL.md mtime > дати у > Оновлено: … на відповідній wiki-сторінці. АБО у поточній сесії є нова інформація яка не існує в wiki.

Якщо жоден критерій не справджується — зроби early exit з повідомленням «nothing to sync today», НЕ створюй порожніх комітів.

Крок 4: Прочитати поточний wiki

Прочитай всі .md в ag-wiki (README.md, projects-overview.md, open-tasks.md, user-profile.md, tech-stack.md, та index.md в підпапках: lunar-hubble, ad-analytics, pediatric-news, zest-content, delta-medical, infrastructure, brand-threads, med-detective, arteggia-bot, case-builder-crew, resource-dashboard, скіли тощо).

Зрозумій що вже задокументовано. Не рерайт, а доповнення.

Крок 5: Оновити сторінки де реально є зміни

Для кожної сторінки де знайшов різницю:

Оновлюй тільки змінені секції — не перепиcуй всю сторінку
Додай/онови рядок: > Оновлено: {{DATE}} (замінивши {{DATE}} на реальну дату)
Якщо додаєш новий проект — додай рядок у projects-overview.md
Якщо закриваєш task — перенеси з open-tasks.md у sessions/{{DATE}}-sync.md під заголовком «Closed today»

Жодних нових сторінок без необхідності. Якщо існує сторінка з близькою тематикою — доповнюй її.

Крок 6: Idempotency guard

Перевір що ти реально щось змінив:

git status --porcelain

Якщо порожньо — exit з «nothing to commit», НЕ йди далі у Крок 7.

Крок 7: Safe git add (НЕ `-A`!)

Ніколи не використовуй git add -A або git add . — може захопити секрети або чернетки.

Явний паттерн:

git add '*.md'
git add '**/*.md'

Перевір staged:

git diff --cached --name-only

Якщо серед staged бачиш файли що НЕ .md (наприклад .env, .bak, token.txt) — стоп, абортни (git reset) і повідом користувача.

Крок 8: Commit

git diff --cached --quiet; if ($LASTEXITCODE -eq 1) { git commit -m "auto: wiki memory sync {{DATE}}" }

(Умовний commit — тільки якщо реально є staged changes.)

Крок 9: Push

git push origin main 2>&1 | Tee-Object -FilePath D:\Users\Sergey.Vereschak.DELTAMEDICAL\Documents\ag-wiki\.last-push.log

Якщо push впав:

Перевір лог .last-push.log
Типові причини: токен прострочений (rotate у GitHub PAT settings), конфлікт (хтось зробив commit у GitHub web UI або на VPS), rate limit
Повідом користувача конкретно що саме впало з витягом з логу

Крок 10: MANDATORY VPS pull (не optional!)

Це критично для спільної пам'яті — без цього VPS Claude продовжить бачити старий стан.

Через SSH на root@31.131.26.203:

cd /srv/wiki && git fetch origin && git pull --rebase origin main 2>&1
echo "VPS_PULL_EXIT=$?"

Якщо на VPS є локальні uncommitted зміни (може статись якщо VPS Claude щось записав, наприклад sessions/{{DATE}}-*.md):

Спочатку git add sessions/, git commit -m "auto: vps sessions {{DATE}}", git push
Тоді Desktop зробить новий pull-rebase і push знову
Повідом користувача про цей round-trip

Якщо SSH упав (network / ключ / firewall) — НЕ «пропусти», а запиши у лог і повідом. Без VPS pull задача вважається failed.

Крок 11: Успіх

Перевір всі 3 критерії:

✅ git log origin/main..main у Desktop — порожньо (push синхронний)
✅ На VPS git rev-parse HEAD == на Desktop git rev-parse HEAD
✅ Дата {{DATE}} з'являється в оновлених .md

Доповіди користувачу 1 рядком:

Скільки сторінок оновлено
Commit hash
Що VPS тепер синхронний

Критерії fail (treat as critical, сповісти користувача)

Rebase conflict — зупинись
Push failed — діагностуй причину
VPS pull failed — не ігноруй, зв'яжись з користувачем
git add захопив не-.md файли — abort
Виявив секрети у staged файлах — abort, повідом, НЕ коміть

Frequency

Рекомендую 1 раз на день о 23:00 Europe/Kyiv (кінець робочого дня). Якщо промо-активність — можна 2 рази (обід + вечір), але не частіше — wiki не повинна стати змаганням з реальним роботом.

Безпека

Токен GitHub у git remote get-url origin поточно видно у plain URL. Це ОК тимчасово, але варто перенести в ~/.git-credentials або в Windows Credential Manager для Desktop і в ~/.git-credentials для VPS. Ротація токена — кожні 90 днів, нагадай користувачу.