--- pageType: source id: source.2026-04-10 title: 2026 04 10 sourceType: local-file sourcePath: /home/node/.openclaw/workspace/memory/2026-04-10.md ingestedAt: 2026-04-10T15:43:24.102Z updatedAt: 2026-04-10T15:43:24.102Z status: active --- # 2026 04 10 ## Source - Type: `local-file` - Path: `/home/node/.openclaw/workspace/memory/2026-04-10.md` - Bytes: 10904 - Updated: 2026-04-10T15:43:24.102Z ## Content ````text # 2026-04-10 — Настройка Memory Wiki + QMD ## Что делали Полный аудит и реконфигурация системы памяти OpenClaw. Сессия ~5 часов (07:05–12:57 UTC) через webchat. --- ## Memory Wiki (memory-wiki plugin) ### Диагноз bridge mode Обнаружили что `openclaw wiki bridge import` всегда возвращает 0 артефактов. Провели глубокое расследование: - Bridge mode требует что memory-core зарегистрировал capability через `api.registerMemoryCapability()` - `listActiveMemoryPublicArtifacts()` читает из `memoryPluginState` в `memory-state-BqTSwHeB.js` - **Root cause:** OpenClaw использует jiti vm-контексты для изоляции плагинов. memory-core и memory-wiki загружаются в разных jiti-контекстах → их `memoryPluginState` — разные объекты → capability не видна - CLI-команда дополнительно запускается в новом процессе без gateway-контекста - **Вывод:** bridge mode в 2026.4.9 для bundled plugins не работает — архитектурная проблема, не баг конфига ### Что настроили в openclaw.json ```json // plugins.entries.memory-wiki.config: "bridge": { "enabled": true, "readMemoryArtifacts": true, "indexDailyNotes": true, "indexMemoryRoot": true, "indexDreamReports": true, // добавлено "followMemoryEvents": true // добавлено }, "context": { "includeCompiledDigestPrompt": true // добавлено — wiki digest в промптах } // agents.list[main].tools.allow — добавлены: "wiki_status", "wiki_search", "wiki_get", "wiki_apply", "wiki_lint" ``` ### Текущий статус wiki - Vault: `/home/node/.openclaw/wiki/main` - Mode: bridge (формально), фактически работает через manual ingest - Sources: 6 (MEMORY.md, PROJECT.md файлы) - Entities/Concepts/Syntheses: 0 (не наполнено) - `openclaw wiki compile` и `openclaw wiki lint` работают - `wiki_*` инструменты добавлены в allowed tools main агента --- ## QMD — установка и настройка ### Конфиг (добавлен корневой ключ `memory` в openclaw.json) ```json "memory": { "backend": "qmd", "qmd": { "command": "/home/node/.local/bin/qmd", "paths": [ { "name": "tasks", "path": "~/.openclaw/workspace/tasks", "pattern": "**/*.md" }, { "name": "skills", "path": "~/.openclaw/workspace/skills", "pattern": "**/*.md" } ], "sessions": { "enabled": true } } } ``` Ключевой момент: `memory` — корневой ключ, НЕ под `agents.defaults`. `agents.defaults.memory` — невалидный ключ (проверено). ### Проблема с коллекциями QMD создавал `memory-root-main` с паттерном `**/*.md`, хотя OpenClaw ожидает `MEMORY.md`. Затем не мог создать `memory-alt-main` для того же пути. **Фикс:** вручную добавить `memory-alt-main` в `~/.openclaw/agents/main/qmd/xdg-config/qmd/index.yml`: ```yaml memory-alt-main: path: /home/node/.openclaw/workspace pattern: "memory.md" ``` После этого удалить sqlite и переиндексировать: ```bash rm ~/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite* openclaw memory index --force ``` ### Эмбеддинги - Модель: `embeddinggemma-300M-Q8_0.gguf` (~328MB, скачана) - Только CPU, без GPU → embed одного батча занимает 30+ минут - OpenClaw таймаутит на 120 сек и помечает Vector: unavailable, но фоновый процесс продолжает - После завершения: Vector: ready автоматически ### Итоговые коллекции (main агент) | Коллекция | Путь | Документов | |---|---|---| | memory-root-main | workspace/ | 159 | | sessions-main | agents/main/qmd/sessions/ | 111 | | tasks-main | workspace/tasks/ | 104 | | memory-dir-main | workspace/memory/ | 33 | | skills-main | workspace/skills/ | 10 | | memory-alt-main | workspace/ (memory.md) | 0 (Linux, нет файла) | Итого: 417 документов, 448+ векторов (>100% — чанкинг больших файлов) ### Статус всех агентов - main: Vector ready ✅ - dev: Vector ready ✅ - legal: Vector ready ✅ - feda: Vector ready ✅ ### Тест поиска (результат) ``` openclaw memory search --query "vprok интернет заказы relay" → 0.96 tasks/internet-orders/project.md ✅ memory_search (через инструмент) "vprok интернет заказы relay" → provider: qmd, score: 0.96 ✅ ``` --- ## Итог дня ### До - builtin SQLite, 33 файла, 101 чанк - Только BM25 + vector (OpenAI API) - Нет sessions, нет tasks/, нет skills/ - Нет wiki инструментов ### После - QMD sidecar, 417 документов, 448+ векторов - BM25 + Gemma-300M (локально) + reranking - Sessions, tasks/, skills/ проиндексированы - wiki_* инструменты подключены - includeCompiledDigestPrompt включён ### Открытые вопросы - Bridge mode не работает (jiti-изоляция) — ждём фикса в OpenClaw или переходим на unsafe-local - Wiki не наполнена (0 entities/concepts) — следующий шаг - Dreaming отключён — можно включить - embed медленный на CPU — при следующем полном сбросе индекса ждать 30-60 мин --- ## Сессия вечер: Прозрачный прокси (Wi-Fi + HA Telegram) — 13:00–15:00 UTC ### Задача #1: Wi-Fi homenet-vpn (192.168.4.0/24) через VLESS tproxy **Статус:** НЕ ЗАВЕРШЕНА. TCP через tproxy не работает. **Причина проблемы:** - Ключевой конфликт: `flow: "xtls-rprx-vision"` несовместим с redirect/tproxy mode на принятых сокетах - Без flow — VLESS не соединяется (сервер требует xtls-rprx-vision) - С flow — Xray падает `failed to set IP_TRANSPARENT` для redirect mode - **Итог:** tproxy redirect mode + xtls-rprx-vision = incompatible **Текущее состояние iptables на vpn-srv:** - `TV_REDIRECT` в nat PREROUTING — REDIRECT src 192.168.4.0/24 tcp → port 12345 - `REDSOCKS_HA` в nat PREROUTING — REDIRECT src 192.168.2.0/24 tcp → port 12350 (redsocks → SOCKS5 1080) - `MASQUERADE` для 192.168.2.0/24 и 192.168.4.0/24 в POSTROUTING **Xray config текущий:** - flow: `xtls-rprx-vision` (ВОССТАНОВЛЕН) - loglevel: debug - tproxy-in: port 12345, mode redirect - HTTP proxy: 8888, SOCKS5: 1080 **Что работает:** HTTP proxy (8888) и SOCKS5 (1080) через Xray → VLESS → работают (проверено curl 200) --- ### Задача #2: HA Telegram через SOCKS5 прокси **HA:** `ha.homenet542.keenetic.pro`, IP 192.168.2.139, HAOS 17.1, gateway → Keenetic (192.168.2.1) **SSH доступ к HA:** через vpn-srv → HA SSH add-on ``` ssh -i /tmp/ha_key -o StrictHostKeyChecking=no root@192.168.2.139 ``` (ha_ssh_key скопирован на vpn-srv как /tmp/ha_key) **Что сделали:** - Добавили в `/homeassistant/configuration.yaml` блок telegram_bot с `proxy_url: socks5://192.168.2.200:1080` - Удалили UI-configured config entry (01K6SDHYX559FSXC1M25ATSSYE) - Перезапустили HA Core - `notify.telegram_notifier` появился, `telegram_bot/send_message` → HTTP 200 ✅ **Бот:** `ha542_bot`, token: `8251509944:AAGkRr_5ZIIQNd4XrlI5QI9DYZS8JUPhcxY` **❗ ЗАМЕЧАНИЕ Славы (голосовое, 14:44 UTC):** - Через прокси должен ходить ТОЛЬКО Telegram, не весь трафик HA - Прокси для Telegram настраивается через UI интеграции в HA (не через кастомные компоненты) - Нужно найти proxy_url настройку в UI telegram_bot интеграции - Текущая YAML-конфигурация может быть корректной (proxy_url только для telegram_bot), но нужно проверить **Статус на 15:00 UTC:** Telegram работает через SOCKS5, но Слава указал что подход должен быть через UI. Нужно уточнить. --- ### SSH доступ к инфраструктуре (актуально) - **vpn-srv:** `ssh -i /home/node/.openclaw/ha_ssh_key -o StrictHostKeyChecking=no -p 3322 vpn@185.130.212.192` - **HA (через vpn-srv):** `ssh -i /tmp/ha_key root@192.168.2.139` (с vpn-srv) - **mva154:** `ssh -i /home/node/.openclaw/ha_ssh_key slin@82.22.50.71` ### Конфиги - Xray: `/etc/xray/config.json` (bak5 = последний бэкап до удаления flow, bak3/bak4 старые) - iptables: `/etc/iptables/rules.v4` (outdated — не пересохранены после сегодняшних изменений!) - HA config: `/homeassistant/configuration.yaml` (бэкап: `.bak-20260410-XXXXXX`) ### TODO - [ ] Сохранить текущие iptables rules.v4 (сегодняшние изменения не сохранены!) - [ ] Проверить как настраивается proxy в UI telegram_bot интеграции - [ ] Либо оставить YAML-config с proxy_url (только Telegram через прокси), либо вернуть UI с proxy - [ ] Задача Wi-Fi tproxy для 192.168.4.0/24 — остаётся незакрытой --- ## Задача #2 ЗАВЕРШЕНА — 15:25 UTC **HA Telegram через VLESS работает!** Слава подтвердил получение сообщений. **Финальная конфигурация:** - UI-интеграция telegram_bot с `proxy_url: socks5://192.168.2.200:1080` - Только Telegram через прокси, остальное напрямую - Config entry ID: `01KNVZDDM3ZNJS1WX309K7E1EN` - Notify entity: `notify.telegram_bot_8251509944_126472752` **Задокументировано в:** `tasks/proxy-vm/PROJECT.md` **Задача #1** (Wi-Fi transparent proxy) продолжится когда Слава вернётся домой. ```` ## Notes ## Related - No related pages yet.