app-catalog-felhom.eu/REPORT.md

REPORT — sparkyfitness finalized: image-inspected healthchecks + probe-container naming (2026-07-03)

Class: template finalization + live validation (no version scheme; push = deploy). Baseline: main @ 15cdf7b → c7490f7. Companion: the NEW felhom-app-catalog skill (felhom.eu — this task was its first worked example; see that repo's REPORT for the skill half).

What changed

• templates/sparkyfitness/docker-compose.yml:
  • Both VERIFY-BEFORE-FINALIZE markers RESOLVED by inspecting the actual images on the demo box (the skill's core rule — never guess):
    • frontend codewithcj/sparkyfitness:v0.17.2 (Alpine/nginx): has /usr/bin/wget (and curl; no node/python3) → the drafted BusyBox-wget --spider :80/ probe kept, marker replaced with the inspection provenance.
    • server codewithcj/sparkyfitness_server:v0.17.2: has node v24.17.0 (and wget+curl) → node-exec GET :3010/api/health kept (checks the real status, not mere reachability); /api/health proven live: {"status":"UP"}.
  • Frontend container_name renamed sparkyfitness-frontend → sparkyfitness: the controller-side probe dials the container named exactly like the stack (fallback = FIRST prefix match — could be the DB). New REUSE.md §2 row records the convention.
  • Both image tags reconfirmed to resolve (docker manifest inspect).
• templates/sparkyfitness/.felhom.yml: mem-sum arithmetic comment added (db 512 + server 1024 + frontend 256 = 1792M — matches the existing value; nothing corrected).
• REUSE.md §2: NEW "Probe-container naming" row (verified against felhom-controller/internal/stacks/healthprobe.go findProbeContainer).

Live validation (demo guest 9201; method stated per claim)

SparkyFitness was already running from the draft (deployed 4 h earlier, 3× healthy). Applying the finalized template used the REAL dashboard UI via the browser bridge: "Sablonok frissítése" (sync confirmed by the guest's stacks file gaining the rename, zero VERIFY markers), then the card's "Frissítés". Result:

• Only the renamed frontend was recreated — sparkyfitness … Up 21 seconds (healthy); server + db stayed Up 4 hours → the two data_key secrets (API_ENCRYPTION_KEY, BETTER_AUTH_SECRET) were NOT regenerated (deployed app.yaml/.env untouched, exactly the data_key contract).
• Docker health: 3/3 healthy. Controller-side probe (via GET /api/stacks/sparkyfitness, the same data the UI polls): healthy: true — http :80/ → 200 (6ms) against the renamed container.
• sparky.demo-felhom.eu answers 200 via Traefik in-guest (Host-header curl).
• Kept deployed on demo (7.3 option A — expendable box, real catalog app). The data_key secrets exist only in the deployed app.yaml, never committed.

Notes / observations (not acted on)

• Pre-rename, the controller probe was ALSO green — the prefix fallback happened to pick the frontend. The rename converts luck into the deterministic convention.
• paperless-ngx's container names match neither the exact nor the prefix rule of its stack name — its controller-side probe likely never runs. Candidate follow-up, not touched.
• BusyBox ash command -v silently ignores all but its first argument — inspect one tool per run (now in the skill).
• App-count drift recorded in the felhom.eu REPORT (53 templates vs website "45+" / category sum 49).