# REPORT — most recent implementation

## felhom-controller v0.143.0 — guest RAM resize UI (R-24) — 2026-07-17

**Baseline:** v0.142.0 (`f900c83`) → **v0.143.0** (`3286c7f`, pushed). **MinAgent: 0.90.0** (couples to
felhom-agent v0.90.0's `/guest/memory`). Deployed + LIVE-validated on the nested demo guest.

### What shipped

The customer sees the guest's current memory + the allowed range on the **Rendszer** settings page and
resizes it. The controller only proxies + maps the agent's machine `code` to Hungarian — the **agent**
(felhom-agent v0.90.0) enforces every bound and applies the change live (no reboot). Memory only.

- **agentapi (`internal/agentapi/client.go`):** `GuestMemory` (GET) + `ResizeMemory` (POST). A ruled 412
  surfaces `*MemoryRefusedError` (machine code + fresh bounds); a pre-0.90 agent 404s → typed `*StatusError`.
- **Capability (`internal/agentapi/features.go`):** `FeatureGuestMemoryResize` + `featureMinAgent` **0.90.0**
  + a `featureProbes` row. The probe TYPE-ASSERTS the one method it needs (`GuestMemory`), so the shared
  `SupportProber`/`netAgent` seams and their fakes are untouched (minimal-coupling choice — see Observations).
- **UI (`internal/web/system_memory_handlers.go` new; `templates/settings_system.html`):** a "Szerver
  memória (RAM)" card; `POST /api/system/memory/resize` (mounted `/api/system/` in main.go) → capability
  gate (SupportUnknown passes) → agent → response flash. JS confirm ONLY on a shrink. Code→Hungarian map;
  agent-outdated hides the control (+"rendszerfrissítése szükséges" note); agent-unreachable falls back to
  the guest's own `/proc/meminfo` (control disabled, honest note; the page never 500s).

### Tests

- agentapi: GuestMemory decode + 404-typed; ResizeMemory success + refusal-code (`*MemoryRefusedError`);
  capability table (0.89→No / 0.90→Yes via the version fast-path; probe 404→No / ok→Yes).
- web handler: success maps to the Hungarian old→new line; below_usage_floor maps + **the agent's English
  never leaks**; agent_outdated gate refuses with ResizeMemory NEVER called.
- Gates: `template_id_gate` + `emoji_gate` OK. `go build/vet/test` all pass (23 packages).

### Deploy + LIVE validation

Built + pushed `felhom-controller:0.143.0`; deployed to BOTH demo guests (guest 9201 on felhom-pve AND the
nested guest 9201 inside `demo-vm-felhom-4846bc`) — both `Up … (healthy)`.

**LIVE end-to-end through the REAL controller endpoint** (login → CSRF → POST) on the nested demo guest —
the exact pipeline the settings page drives (no server logic skipped; method: authenticated curl to the
controller container, browser bridge unavailable):

```
GET  /api/system/memory → {"allocated_mb":2890,"usage_mb":181,"host_total_mb":3914,"min_mb":2048,"max_mb":1866,"floor_mb":2048,"running":true}
POST /api/system/memory/resize {memory_mb:5000} → {"code":"above_max"}  "A megengedett maximum 1866 MB (a gazdagép tartaléka miatt)."
POST /api/system/memory/resize {memory_mb:1024} → {"code":"below_min"}  "A minimális memória 2048 MB."
```

The full chain is proven live: controller auth → capability gate resolving **SupportYes via the
X-Felhom-Agent-Version=0.90.0 header** → agentapi → agent enforcement → machine code → Hungarian mapping
(the agent's English is not shown). The lxcfs ripple (guest `/proc/meminfo` follows a real resize) is
Phase-0-proven at the agent layer.

### NOT yet live-validated

- A **successful** resize through the bounded endpoint could not be shown on the tiny 4 GB nested host: its
  bounds are degenerate (`max_mb 1866 < current 2890`) so every target is correctly refused. The successful
  live cgroup apply (2890→3146→2890, no reboot) is Phase-0-proven at the agent layer (agent REPORT §2). On a
  normal-sized customer box a grow/shrink will succeed — folds into the rehearsal (S6 gains the resize touch).
- Full browser click-through of the card (the bridge attaches only to sessions started after it connected).

### Observations

- The `featureProbes` type-assertion (vs. widening the shared `SupportProber`) keeps the memory feature from
  coupling `netAgent` and every unrelated prober/fake to the memory surface. A prober that can't be asked →
  a non-404 error → SupportUnknown (fail-open), never a false "supported".
- The `memAgent` seam carries `NetVerifyStatus` + `AgentVersion` purely to satisfy the shared SupportProber /
  version fast-path (production `*agentapi.Client` has them anyway) — the one small wart of reusing the cache.