felhom-controller/REPORT.md

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.