Files
felhom.eu/documentation
admin f651b31a7a
gates / gates (push) Successful in 22s
golden 0.207.0 BAKED, PUBLISHED, ROUND-TRIP VERIFIED and VOUCHED — the currency gate goes green
Closes the delivery gap v0.207.0 opened this session. Until now the gate was
correctly red and a machine installed today would have received 0.206.0 — the
release written, tested and pushed, and not delivered.

Round trip is the evidence, not the build log: the published bytes were downloaded
back (656 879 192 B, sha256 20ec9602…22995, both identical to what the bake
reported) and ./etc/felhom-controller-image read OUT of the downloaded archive
says felhom-controller:0.207.0 — the delivered artifact naming the controller it
will start.

Acceptance markers were the ones R-233 re-captured from a real log: docker OK
(overlay2…) x1, including mount point rootfs AND mp0 x2 (there is no mp1 since
build-golden.sh v3.0.0), upload OK (HTTP 201) x1, excluding 0, FATAL 0.

The 404 pre-gate ran WITH a control so a 404 could not mean 'wrong URL': 0.206.0
-> 200, 0.207.0 -> 404.

The token never crossed a shell — copied file->file, read by a runner script
inside the VM; systemctl show grep for the value returned 0. The token-leak grep
on the COMMITTED log returned 0, and that 0 is evidence because a planted copy
returned 1 before being shredded.

Vouch was a three-field change with all three checked deliberately: MinAgent
0.127.0 read from the golden's controller CHANGELOG header, agent_version already
>= it, min_agent not above agent_version (not the R-216 shape). Verified by
re-reading the manifest rather than trusting the flash. The R-120 gate did not
refuse.

Drill VM restored to virgin; qemu confirmed exited with ps -eo comm, not a
self-matching pgrep -f.

R-242: the bake half is done and the --no-verify bypass declared earlier today is
now historical. Its remaining half is UNCHANGED — nothing gates the VOUCH itself,
so a baked-but-unvouched golden still passes the currency gate silently.
2026-08-07 20:59:37 +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.