# REPORT — v0.119.0: storage-health coherence (F8) + mapped_uid validation (F4)

**Date:** 2026-07-12 · **Version:** controller v0.119.0 (from v0.118.0) · **MinAgent:** 0.81.0 (UNCHANGED)
· **Deployed:** guest 9201 (`0.119.0` healthy) · **Source:** `felhom.eu/documentation/audits/CAMPAIGN-3-2026-07-11.md`.

## §3 design fork — decision

Took the recommended **option B (controller-only)**: the share row reuses the shipped v0.117.0
consuming-namespace classifier (`system.ClassifyPathFS`) — the exact ground truth the stacks-page stub
badge already reads. No agent change, no new probing surface, and by construction the row and the
stacks badge can never disagree (single source). Option A (agent-side export-level probe) was not built.

## What shipped

- **F8 (MED) — one classification, two surfaces.** `networkStorageItems` now fuses the agent's health
  with the namespace classification via `fuseNetHealth`: a new `stub` state overrides a benign idle/ok
  when the consuming namespace sees local disk at `Where`; a whole-server `unreachable` still wins over
  stub; autofs-healthy / network / `unknown` leave the agent health intact (no manufactured fault, no
  force-mount). Row badge for `stub` = "Hibás — az alkalmazások nem a NAS-t látják". The share row and
  the stacks/dashboard badge now derive from ONE classifier.
- **F4 (LOW) — mapped_uid/gid range check at the door.** `handleNetStorageAdd` validates the container
  uid/gid (1..65533) after the `<=0` default, before the job — out of range → friendly Hungarian 400,
  nothing installed. Catches the campaign's `101000` (a host-side mapped value) that used to leak a raw
  `agent_error`.

## Tests + red-proofs (all green)

- F8 fusion table: idle+stub→stub (the contradiction resolved), ok+stub→stub, **idle+autofs→idle**
  (the over-eager autofs=stub mutant fails here), unreachable+stub→unreachable (server wins),
  idle+unknown→idle (no manufactured fault). End-to-end `networkStorageItems` stub fusion (companion:
  drop the fuse call → row shows raw agent health → fail).
- F4: uid 101000 → 400 + friendly message, agent never reached (companion: drop the check → reaches the
  agent → fail); 65534 → 400; 1000 / 65533 / 0-defaults pass the range check.

## Live validation (demo 9201, sim-NAS rails — exportfs only)

- **F8 the contradiction, killed:** baseline healthy → row `ok`, no stub badge. `exportfs -u` while idle
  + drop the mount → the SHARE ROW showed `health=stub` ("Hibás — az alkalmazások nem a NAS-t látják")
  AND the stacks page showed the stub badge (4) — the two surfaces AGREE (previously: row "Készenlét" +
  stacks stub = contradiction). `reachable:true` throughout (the server-level dial is still green — the
  exact F8 blindness, now correctly overridden). Re-export → row cleared back to `ok`/"Elérhető"
  (healthy idle NOT downgraded — the regression).
- **F4:** `mapped_uid:101000` → 400 + the friendly message, registry unchanged (no `c5uid`), no host
  unit/dir residue; `mapped_uid:1000` → 200, passed the range check (then failed later at the
  unreachable probe as designed, rolled back clean).

## NOT live-validated / standing items

- `unreachable`-wins live (a genuine server-down IP on a registered share) — unit-tested only; the F8
  live proof used the export-level cut (the actual finding).
- Task D remains queued: fix-3 boot-time app-start-failure alerting + the ring wrap/count revision
  (fix-6 6.5-min horizon under load).
- Peti's box (controller 0.113 / agentless-on-proxmox2) reaches 0.119 (+0.85/0.118) at his next train.
- No publish/floor movement; agent untouched (MinAgent 0.81.0).

## Box state at wrap

controller 0.119.0 healthy on 9201; nas-media healthy + `ok`; registry = nas-media only (no test
residue); all NAS apps healthy; NFS re-exported.