Files
felhom.eu/documentation
admin 9657334fb7
gates / gates (push) Successful in 14s
R-241 FIXED: registers, capability map, STATUS, hub CHANGELOG v0.98.0
R-241 closed against controller v0.206.0 + hub v0.98.0, following the spike's
ruling rather than the obvious reading. The row records what the fix does AND
the two real bugs the tests caught rather than review - a missing t.Enabled
(caught by an EXISTING test) and a missing falling-edge sync that
reintroduced the very defect the epoch exists to fix.

R-243 UPDATED, not closed: the STATE it describes can no longer be entered
(the mint guard), and what replaces it is VISIBLE rather than silent - the box
declares awaiting_recovery_key and the customer is offered the screen. But the
ALARM GAP is untouched, for the same three reasons, so a box whose customer
never acts still stops backing up with no operator signal. The remaining work
is an operator-side signal for a box held past some age, deliberately not
bundled into R-241's fix.

R-245 NEW - WAITING-ON-OPERATOR, recorded and NOT built: should an undecided
customer be auto-abandoned after 30 days? The operator's proposal is recorded
WITH the reasoning against it, so the decision can be revisited properly: a
reinstall implies a person, so nobody is absent; a customer who cannot find
their code gets in touch, which is why the operator LEVERS were the thing
worth building; the cost is the customer's own storage allowance; and the real
harm is QUOTA, which is a condition, not a calendar. If it is ever built,
build it to trigger on the harm with a dated warning, never on a date alone.

The capability map's recovery-journey row STAYS FAIL. These are fixes, not a
walk - nothing here walked a customer end to end, and the row goes green only
when one completes with no operator intervention AND a byte-identical
sentinel. R-214, R-202 and R-240 are still open.

STATUS compressed rather than extended, per its own one-screen rule, and the
"rebuilding throws away the off-site history" line corrected: the cause is
fixed, so leaving it as a live defect would be false.

hub CHANGELOG v0.98.0 for the superseded-package purge.

Highest register ID moves R-244 -> R-245.
2026-08-07 12:13:09 +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.

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 05, slices 710). 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.