Files
felhom.eu/documentation
admin 6c450bca50
gates / gates (push) Successful in 22s
chaos night: the alarms were DELIVERED, and the first delete was correctly refused
The mailbox closes a gap the truth table could not: 17 alarms fired and all 17
were true, but that was the FEED. The mailbox shows they reached a person.
Round 11's full set arrived - storage_disconnected naming the drive, four
app_start_failed naming exactly the four apps whose data was on it, then
health_degraded. Round 6's whole_guest_backup_failed names the TIER. Round 1's
offbox_repo_orphaned was mailed within seconds of the run.

What is absent matters too: NO node_stale mail for tonight's box after round
9's outage, exactly as R-549 predicts - the gap was 29m59s against a 30-minute
threshold. One second the other way and this would be a page-out for a healthy,
self-repaired box.

Teardown layer 3 began with a DELIBERATE un-acknowledged delete, to see the
gate refuse: HTTP 409, 'Host is ONLINE - deletion is refused'. Gate one fired,
not the escrow gate - the box died inside the hub's 30-minute liveness window.
The record survived, verified by its own URL returning 200 rather than by
counting substrings on a list page (grep -c counts lines, not occurrences - my
'3 then 2' was my error, not a deletion).

The wait is the product's and not mine to shortcut: the acknowledged delete is
armed for 00:55Z behind a guard that will not post while the host reads ONLINE.
The fence says the hub is never changed, so a liveness gate is waited for.

Also recorded: the mailbox baseline proving no connect mail exists from tonight,
so the one quoted after the delete is provably new - the exact check the brief
said had been skipped before.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-09-17 02:40:38 +02:00
..

Felhom — Documentation

Felhom is a managed home-server service for Hungarian households, built on a three-component model over Proxmox:

  • Hub — operator backend on k3s (hub.felhom.eu). Repo: felhom.eu/hub/.
  • Host agent — one per Proxmox host; operator-tier; owns all Proxmox interaction. Repo: felhom-agent/.
  • In-guest controller — one per customer LXC; Docker-only; manages the customer's apps. Repo: felhom-controller/.

This directory is the central, code-verified documentation home for all three components plus the platform and the security-audit record.

Sections

Controller (in-guest) — controller/

The Docker-only app-domain controller. Full per-area docs grounded in current source (v0.59.0). → controller/README.md: module map, deploy & stack lifecycle, backup architecture, storage/monitoring/metrics, auth/hub/sync/integrations.

Where we stand — architecture/where-felhom-stands.*

The operator's one-page picture of what is proven, built, partial and missing.

Host agent & platform — architecture/, proxmox-platform.md

The operator-tier agent and the Proxmox platform.

Hub (operator backend) — architecture/05

Security audits & remediation — audits/

Spike & test findings — tests/

Per-slice spike/validation findings (phases 0–5, slices 7–10). See tests/.

Conventions

  • Code-verified, not memory-derived. Architectural claims here are checked against the actual current source; if a claim can't be verified it is omitted and flagged, not guessed.
  • Per-repo operational working files (CLAUDE.md, CONTEXT.md, CHANGELOG.md, BUGHUNT.md, REPORT.md, TASK.md) live in their own repos — they are operational, not published docs.
  • Authoritative versions at last refresh: controller v0.59.0, agent v0.29.1, hub v0.11.0.