a0a67eefab
User's Nextcloud rollout already hit the classic trap of unprivileged-LXC write attempts against an NFS share, so don't repeat that pattern for Nexa. Updated docs to: - Use SMB volumes mounted directly as docker volumes (driver: local, type: cifs) with explicit username/uid/gid — bypasses LXC uid-mapping entirely. Concrete YAML in docs/09 step 3 against //192.168.1.31/nexa/<volume>. - Keep the host-side /mnt/pve/unas NFS mount for admin-only use (rsync, manual snapshot copies). Don't bind-mount it into containers. - docs/12 #27 reordered to lead with SMB targets (qdrant, graphdb, tei-cache, snapshots) and only mention NFS for host admin. - CLAUDE.md storage block flipped to "SMB = default per-container storage; NFS = host-side admin only". - Also captured: deployments go through the Dockge UI (LXC is the Dockge flavor of helper-scripts), not raw `docker compose up`. - New optimization #30 about the local mail spool nag on the docker LXC ("You have new mail." at login).
6.0 KiB
6.0 KiB
Instructions for Claude (and other agents)
This file tells future automated runs what they need to know about this repo.
Repo conventions
- Documentation: all docs live in
/docs/and are numbered. Entry point isdocs/index.md. When you add a doc, give it the next freeNN-prefix and add a row to the index TOC. - Runtime artifacts: live in
nexa-core/(workflows, prompts, configs, scripts). Don't put.mddocumentation in there — link from/docs/instead. - Source-of-truth: if a doc duplicates content from
nexa-core/config/*.md, delete the duplicate. Single source of truth.
Real infrastructure (verified from screenshots, May 2026)
- Proxmox host
nucat192.168.1.20:8006(PVE 9.1.9, kernel 6.17.13-4-pve, EFI).- Hardware: 22 threads (Intel Core Ultra 7 155H, 1 socket), 62 GiB RAM, 1.64 TiB disk.
- Steady state: ~32 GiB used (≈24 GiB of which is ZFS ARC, tunable via
zfs_arc_max), CPU load <2.0, IO delay <0.05%. - LXC 102 dns (AdGuard) — internal DNS, rewrites for
*.nuclide.systems. - LXC 103 backrest — backup orchestration.
- LXC 104 docker — main docker host at
192.168.1.40, hostnamedocker, OS Debian 13. Unprivileged, provisioned from the Dockge flavor ofproxmox-helper-scripts— stacks are managed in the Dockge web UI, not rawdocker composeon disk. Allocated: 16 CPU, 31.25 GiB RAM (25% used), 8 GiB swap, 200 GiB boot disk (47.7% used). Storage on the UNAS (192.168.1.31) is reachable two ways: - NFS (Proxmox host-mounted at
/mnt/pve/unas, 19.4 TiB / 16.3 TiB free) — fine for host-side admin tasks and read-mostly mounts. - SMB — default for Nexa per-container volumes. The user already hit NFS+unprivileged-LXC write-permission issues with Nextcloud; don't repeat that. Mount SMB shares directly as docker volumes inside the stack with explicit
username=/uid=/gid=— sidesteps uid-mapping entirely. Intel iGPU passthrough is configured but currently broken — see docs/12 #26. - LXC 105 nextcloud — Nextcloud at
nc.nuclide.systems. - LXC 106 octoprint — currently Exited; flagged in docs/11.
- LXC 108 zoraxy — reverse proxy at
192.168.1.4:8000, TLS for*.nuclide.systems. - VM 100 haos — Home Assistant.
- Already-running services on docker host (don't redeploy):
- Memos
:5230, n8n:5678, LiteLLM:4000(UI LobeHub:3210), Qdrant (qdrant_scientific), ntfy:7998, Karakeep (legacy aliashoarder.nuclide.systems), Vaultwarden:11001, Pocket-ID:1411, Immich, Audiobookshelf, Paperless-ngx, Traccar, Prowlarr, plus MCP containers (crawl4ai-mcp,markitdown-mcp,papersearch-mcp).
- Memos
- Octoprint (LXC 106) is intentionally powered down most of the time. Phase-5 monitoring must skip names matching
octoprint*rather than alert on its Exited state. - Obsidian vault lives inside Nextcloud at
nc.nuclide.systems/Notizen/(multi-device sync via Nextcloud client). Nexa accesses it via WebDAV — read-only, no filesystem mount. Ignore list:.copilot/,.copilot-index/,.smart-env/,.caldav-sync/,assets/(visual queue, Phase 3.2),Templates/,BMO/,Excalidraw/. Index target:Notizen/**/*.md. - Nextcloud Tasks lists & calendars (German names, may grow over time):
Persönlich→ Personal context.DLR→ Work context (DLR is the user's employer).Einkaufsliste→ Shopping.Wunschliste→ Wishes. Lists are discovered by name at runtime (Qdrant_confignamespace cachesname → id). Never hardcode IDs. The discovery workflow runs daily and on cache-miss; new lists added in Nextcloud are honoured automatically next refresh.
- Mail = Nextcloud Mail, single account
fkrebs@nucli.de. No separate IMAP entry. TheWaitingfolder is a manual user signal — items there are skipped from digests. - Auth = Pocket-ID SSO is global at the Zoraxy layer. Don't add app-level basic-auth to Nexa surfaces; UIs inherit SSO. Machine-to-machine still uses API keys / app passwords.
- Decided for Nexa (don't re-litigate without user input):
- Vector store: reuse
qdrant_scientificwith collections suffixed by modality (nexa_knowledge_text,nexa_knowledge_visual). - Embeddings staged: Phase 3.1 TEI +
BAAI/bge-m3(text-only, 1024-dim). Phase 3.2 swap toinfinityand addjinaai/jina-clip-v2(768-dim, joint text+image space). All forward-compat fields (modality,media_uri,graph_iri,nexa:pendingVisualIndex) exist from 3.1 — adding the visual collection is additive. - Graph store: Ontotext GraphDB (SPARQL/RDF), Phase 3.4. RDF schema in docs/08 already includes
nexa:modality/nexa:mediaUri/nexa:vectorCollection/nexa:pendingVisualIndex. - Chat model: SAIA via LiteLLM virtual key.
- Vector store: reuse
When working on Nexa
- Read
docs/index.mdfirst — it's the navigator. - Open questions first. Before writing code or workflow JSON, scan
docs/11-open-questions.md. If your task touches an unanswered Q, stop and ask rather than picking a default. Append new blockers to that doc as[ ] Q-NN. - Optimization findings. When you spot infrastructure improvements, add them to
docs/12-optimization-opportunities.mdas a numbered bullet — don't just mention them in commit messages. - Never inline secrets in workflow JSON or
.envcommitted to git. Use n8n credentials, LiteLLM virtual keys, or (longer term) Vaultwarden. - Keep deployment minimal. The default answer to "do we need a new container?" is no — the existing stack covers most needs.
Branch policy
- This branch is
claude/organize-docs-deployment-7N4v2. Push only here unless told otherwise. - New work for an unrelated feature → new branch under
claude/<topic>.
Quick links
- docs/index.md
- docs/09-deployment.md — most-touched file during bring-up
- docs/11-open-questions.md — read before assuming defaults