Two unchecked items from the README status list that were buildable in-repo
rather than blocked on hardware.
hosts/llm-host/ — Phase 3's LLM machine:
- Auto-detects gpu vs cpu tier (nvidia-smi must both exist AND succeed; a
leftover driver package on a machine whose card was pulled satisfies only
the first and would fail later at container start).
- Runs Ollama as a pinned container rather than curl|sh into a root shell,
matching how everything else here is deployed. Deliberately does NOT install
the GPU driver — the most hardware/kernel-specific step on that box.
- Sets OLLAMA_HOST=0.0.0.0 inside the container. Ollama binds loopback by
default, which in Docker means the published port forwards to nothing and
every caller sees a connection refused indistinguishable from "the host is
off" — and since every consumer here is built to tolerate exactly that, it
degrades silently. Same class of bug as chores' 127.0.0.1 env values.
- Takes a position on Ollama contention (open decision #4's resource half):
MAX_LOADED_MODELS=1 so a 14B text model and a vision model swap predictably
instead of thrashing VRAM or OOM-ing mid-request, NUM_PARALLEL=1 for
predictable Assist latency, KEEP_ALIVE=30m so a household that talks to
Assist a few times an hour isn't paying model-load cost every time.
- Documents that Ollama has NO authentication and its API can delete models,
not just generate — added to network-integration.md's port table, since the
network is the entire boundary.
docs/caldav-integration.md — Phase 8's notes:
- The four independent clients and their directions (digest-engine read-only,
chores' busy-check read-only, trash-calendar create-only under a UID-prefix
ownership invariant, HA's own bridge).
- Why they share one Nextcloud app password, and the two costs: rotation
touches three env files plus HA and fails quietly, and the read-only
invariant is a CODE property, not a permission boundary — an app password
can't be scoped read-only or per-calendar, so the server would not catch a
regression that started writing.
- The two traps worth knowing before debugging them: unexpanded recurrence
reporting a meeting on the day it was created, and CALDAV_VERIFY_TLS=false.
Neither has been run — no Debian machine, no GPU, no live Nextcloud. The script
is syntax-checked and its generated compose validated as YAML for both tiers;
that is the whole of the testing, and both READMEs say so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Records the networking decision behind Phase 6b's arrival notifications so it
doesn't get re-derived later.
ntfy stays LAN-only: identity -> ntfy is a container-to-container call that never
reaches OPNsense, and remote delivery rides a WireGuard split tunnel routing only
the smart-home VLAN. No DMZ, no port forward, no certificates, no inter-VLAN rule.
Both alternatives were weighed and rejected, with reasons recorded:
- DMZ + port forward buys only "notifications without the VPN connected," at the
cost of a public listener, TLS upkeep, and mandatory ntfy auth — an exposed
topic leaks "the house is empty right now".
- DMZ + NAT reflection does avoid a new inter-VLAN rule (the smart-home VLAN's
existing outbound-WAN allow already covers traffic to your own public IP), but
makes a purely internal path depend on the ISP and external DNS being up, so
two devices metres apart stop talking during a WAN outage. CGNAT breaks it
outright, and the rule it avoids was the safe direction anyway.
New §2.1 covers the split tunnel itself, including the trap that motivated it:
AllowedIPs must be the actual VLAN prefix, never 192.168.0.0/16, which collides
with typical café/hotel LANs and breaks the phone's connectivity there. Plus
always-on VPN yes / lockdown no, and no DNS= so queries aren't pulled home.
The household uses no Apple devices, which removes the only forcing function for
exposure (ntfy's iOS app needs APNs and therefore an upstream relay). Open
decision #37 closes as a household decision; the Apple case is kept as a
footnote in case that ever changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Phase 19: trash-calendar (Kennelbach ICS -> CalDAV) and transit (GTFS
departures + OpenTripPlanner-backed voice route planning, slow walking
speed assumed). Phase 20: Tapo camera integration via identity's new
Frigate face-recognition presence signal, and chores, a presence/
calendar-driven household task nudger ("I don't care who does it, as
long as it gets done") with a passive fairness tally, litter culprit
attribution, and per-person chore_exempt/chore_reminder_style settings
on identity.
Also: the HA integrations + hardware-monitoring catalogs, Music
Assistant wiring, docs/network-integration.md (OPNsense VLAN
segmentation, no WAN port-forwards), the ESPHome BLE-proxy firmware,
and RuView CSI-presence integration (github.com/ruvnet/ruview) with
household automations for sleep/distress/concurrent-vitals/bathroom-
occupancy — all flagged with their real unverified assumptions and
open decisions. Fixed two real port collisions surfaced while wiring
this in (OTP vs. zigbee2mqtt on 8080, Music Assistant vs. pantry-vision
on 8095).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01K6CrKjW3yVptUnjG35HjC1
Amir Alexander Abdelbaki