Files
felhom.eu/documentation
admin ceac5e0deb STATUS.md rebuilt (258 -> 85); R-245 re-filed as decided; R-246/247/248 filed
STATUS.md REBUILT FROM THE REGISTER, not trimmed. Its own header says one
screen; it had reached 258 lines, having been 83 four days ago.

The three named defects, all fixed:
  1. the "waiting on you" list asked the operator to decide the RECOVERY
     SCREEN, built and shipped 2026-08-05, and to approve an orphaned-backup
     deletion the register records as DONE the same day;
  2. a stray line reading only "- **Nothing.**" sat mid-list;
  3. the DooPlex infrastructure work was mixed in with the product's.

Infrastructure is now under ITS OWN HEADING rather than dropped, and the
reason is stated on the page: these are real asks that need the operator, but
they concern the machine this is built on, not what a customer receives.
Dropping them would lose real work; mixing them is why the page stopped being
readable.

The 100-line "what shipped recently" log is gone. That is what the per-repo
CHANGELOGs and the register are for, and restating it here is what made the
page grow back.

R-245 RE-FILED as a decision taken, not a question pending. It sat as
WAITING-ON-OPERATOR for a day with nothing actually pending - it was settled
on 2026-08-07. It keeps the whole reasoning and now carries the condition that
would REOPEN it, which the reasoning already named: QUOTA, old set-aside
history blocking new backups. A condition, not a calendar.

AUDIT OF EVERY WAITING-ON-OPERATOR ROW, parsing the state column exactly
rather than grepping for the phrase (which over-matches rows that merely
mention it): exactly ONE row carried it - R-245 - and it was a settled
decision. So zero rows were genuinely waiting, and the drift was caught while
it was still a single row.

R-246/R-247/R-248 file the read-only stale-blob spike's findings. R-242
updated: it recurred within a day, and shape (b) is now built - with the vouch
half explicitly still open on that row rather than being papered over.
2026-08-07 12:59:52 +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.