wiki/sources/2026-04-10.md

pageType, id, title, sourceType, sourcePath, ingestedAt, updatedAt, status

pageType	id	title	sourceType	sourcePath	ingestedAt	updatedAt	status
source	source.2026-04-10	2026 04 10	local-file	/home/node/.openclaw/workspace/memory/2026-04-10.md	2026-04-10T15:43:24.102Z	2026-04-10T15:43:24.102Z	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

# 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.