Increase platform abstraction cohesion
This commit is contained in:
53
INSTALL.md
53
INSTALL.md
@@ -200,8 +200,61 @@ Query memory backend:
|
||||
podman exec ur_gia /venv/bin/python manage.py memory_search_query --user-id 1 --query "reply style"
|
||||
```
|
||||
|
||||
Generate proposed memories from recent inbound messages:
|
||||
|
||||
```bash
|
||||
podman exec ur_gia /venv/bin/python manage.py memory_suggest_from_messages --user-id 1 --limit-messages 300 --max-items 30
|
||||
```
|
||||
|
||||
Run memory hygiene (expiry decay + contradiction queueing):
|
||||
|
||||
```bash
|
||||
podman exec ur_gia /venv/bin/python manage.py memory_hygiene --user-id 1
|
||||
```
|
||||
|
||||
Performance defaults now applied in GIA:
|
||||
|
||||
- Batched Manticore reindex writes (`REPLACE ... VALUES (...)` in chunks) for lower ingest latency.
|
||||
- Cached table-ensure checks to avoid `CREATE TABLE IF NOT EXISTS` overhead on every query.
|
||||
- Runtime table maintenance available through MCP (`FLUSH RAMCHUNK`, `OPTIMIZE TABLE`) for steady query responsiveness.
|
||||
|
||||
### F) MCP server for task + memory tooling (VS Code)
|
||||
|
||||
The workspace includes an MCP config at `/code/xf/.vscode/mcp.json` for server `manticore`.
|
||||
|
||||
It launches inside the running `ur_gia` container and forces:
|
||||
|
||||
- `MEMORY_SEARCH_BACKEND=manticore`
|
||||
|
||||
`MANTICORE_HTTP_URL` is read from the container environment (`stack.env` / app settings).
|
||||
|
||||
Start requirements first:
|
||||
|
||||
```bash
|
||||
make run
|
||||
./utilities/memory/manage_manticore_container.sh up
|
||||
```
|
||||
|
||||
Then approve/enable the `manticore` MCP server in VS Code when prompted.
|
||||
|
||||
Optional ultra-light Rust MCP worker:
|
||||
|
||||
```bash
|
||||
cd /code/xf/GIA
|
||||
make mcp-rust-build
|
||||
```
|
||||
|
||||
Then enable `manticore-rust-worker` in `/code/xf/.vscode/mcp.json`.
|
||||
It is intentionally `disabled: true` by default so the existing Python MCP server remains the baseline.
|
||||
|
||||
### C) Signal or WhatsApp send failures
|
||||
|
||||
- Verify account/link status in service pages.
|
||||
- Verify `ur` service is running.
|
||||
- Inspect `ur` logs for transport-specific errors.
|
||||
|
||||
### G) XMPP reconnect loop in logs
|
||||
|
||||
- Confirm `XMPP_ADDRESS`, `XMPP_JID`, `XMPP_PORT`, and `XMPP_SECRET` are populated in `stack.env`.
|
||||
- `XMPP_PORT` is parsed as an integer in settings; invalid values can cause repeated reconnect failures.
|
||||
- The runtime now uses a single reconnect loop with exponential backoff to avoid overlapping reconnect churn.
|
||||
|
||||
Reference in New Issue
Block a user