Протокол работы Claude с creator/obsidian-vault как долговременной
памятью через Gitea REST API.
Покрывает:
- структуру vault (claude/** — RW, остальное RO)
- frontmatter-конвенции (type, project, tags, created/updated,
relevance, confidence, private)
- протокол: когда искать, что читать, куда писать, что НЕ делать
- Gitea REST API шпаргалка (read/list/search/create/update/batch)
- gotchas trial-and-error (поле 'content' а не 'content_base64',
URL-encode путей, sha для PUT)
- формат коммит-сообщений (claude: …)
- правила именования, boundaries, private-флаг
The original setup guide covered connecting Altium directly to the
portal SQL server. That works but has three drawbacks under RU
conditions: ~60-second Altium startup over VPN, daily VPN dependency,
single point of failure at Mark Harris's hosting.
New section 11 documents the self-hosted alternative we just built and
verified end-to-end:
- Two independent mirrors:
- homework/altium-library: Gitea pull-mirror of issus/altium-library
with LFS (SchLib + PcbLib + STEP, ~6 GB)
- homework/celestial-mirror-db: MSSQL 2022 Express in Docker on
192.168.9.147, populated weekly by a pymssql-based sync job with
best-effort + row-count/schema fingerprint skip logic
- Results: Altium startup <1s (100x faster), VPN only needed once a
week for the sync runner, full control over the dataset
- Full deployment sequence (Gitea migrate API → docker compose up →
first manual full-sync → client DbLib rewrite)
- ConnectionString rewrite details (altium_reader user, LAN IP,
Encrypt=Optional/TrustServerCertificate=Yes for self-signed cert)
- MPN-to-view lookup strategies (Shift+C in Altium; dynamic SQL that
scans all 168 tables)
- Troubleshooting specific to the mirror stack