admin
4f5784894e
gates / gates (push) Successful in 20s
Run 264 (650cc8a, a DOCUMENTATION-ONLY commit) failed between two greens of byte-identical gate code.
Not waved away as a flake, because this project's own record is that a "known flake" can be a true
positive.
MEASURED. Every other run this session: 18-34s, log present (HTTP 200). Run 264: 834s (07:12:40 ->
07:26:34 UTC) and GET /actions/jobs/264/logs returns HTTP 500 - "264.log.zst: file does not exist".
The act-runner pod never restarted (0 restarts, 5d17h), so the job hung and was reaped; the runner
did not die.
NOT A GATE FINDING, on four independent facts: the diff from the green before it is Markdown only;
the same content is green two commits later (265, 33s); the gate code is identical across 263/264/265;
and 260-262, which WERE real gate failures, each failed in under 35s WITH a log.
THE CAUSE OF THE HANG IS UNDETERMINED and is deliberately recorded as such. DooPlex was doing heavy
work in that window (139 MB kubectl cp, a go run compiling the whole hub module), which is a
plausible contention story - but 40 cores at load ~5 does not establish it, so it is filed as a
hypothesis rather than asserted as a cause.
THE FINDING THAT MATTERS IS SECOND-ORDER, and it is gates.yml's own purpose turned against it. The
workflow exists because "a detector nobody hears is the defect R-29 filed, rebuilt one layer up", and
its alarm mail says "The failing gate names itself in the run log." There is no run log. An operator
following that sentence finds nothing and cannot tell a reap from a conviction. Unverified and worse:
the alarm step is `if: failure()` and whether it ran at all for a reaped job is unknown - if it did
not, this was a red CI that alarmed nobody.
Fix shapes recorded, none built: surface duration + log-presence in the alarm; an explicit
timeout-minutes under the reap so it fails fast and loudly WITH a log; and one deliberate test of
whether the alarm fires on a reaped job, because until that runs, "CI alarms on failure" is an
assumption.
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.
architecture/01-topology-and-trust.md— topology & trust modelarchitecture/03-host-agent.md— the host agent (Go; v0.29.1)architecture/04-control-plane-authorization.md— signing, escrow, authzarchitecture/02-controller-module-map.md— historical v0.33 planning map; the live map iscontroller/module-map.mdproxmox-platform.md— Proxmox platform reference
Hub (operator backend) — architecture/05
architecture/05-hub-architecture.md— hub architecture (v0.11.0)
Security audits & remediation — audits/
audits/deep-sweep-2026-06-13.md— cross-repo deep audit (controller + agent) with remediation statusaudits/bughunt-reconcile-2026-06-13.md— reconciliation of the v0.30.3 BUGHUNT against current code + merged fix list
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.