Files
felhom.eu/documentation
admin 772956d214 docs(R-116): CLOSED — proven live; capability row F to PROVEN-LIVE; R-120 filed
The events leg the previous commit reported as not-reached is now done. The operator
relayed the claim code (the only route: bcrypt-hashed hub-side, emailed only), the
two storage paths were registered through the real POST /api/storage/register, and
the cycle ran on the fresh box:

  07:20:04  backup_target_absent   (error)  Cel meghajto   <- TARGET, specific
  07:22:34  backup_target_restored (info)   Cel meghajto   <- its matching pair
  07:24:04  storage_disconnected   (error)  Adat meghajto  <- NON-target, generic
  07:25:34  storage_reconnected    (info)   Adat meghajto

All four at the hub; gate fired in 3 s. Two matched pairs, correctly discriminated
-- and discrimination is proven NON-trivially for the first time, since both prior
runs had the target itself emit the generic event. Over-correction passes on a
positive observable, with two RETURNED lines proving the gate was ticking.

00-capability-map row F: PARTIAL -> PROVEN-LIVE with the evidence and the caveat.

R-120 filed: the golden bakes controller 0.185.1, which PREDATES R-114 + R-112, so
a freshly installed box shows the customer the WRONG absent-target message --
observed live on the drill box: the generic "the backup is on the same disk as the
system" copy (false; the target is a drive that vanished) plus an offer of the other
drive as the remedy. That is E2D 5.3's exact payload, still reachable on any new
install. R-115's class one layer up -- R-111 closed by re-baking the golden, 0.186.0
then shipped, the golden did not move, and the gap reopened silently; this time the
stale artifact carries a customer-facing falsehood in exactly the state R-116 now
alarms about correctly.

Teardown recorded for all three layers, hub layer gate-blocked with the command.
2026-07-30 09:34:08 +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.