# Triage brief for a helper (read-only)

## Fences — the brief's own, in full (you need almost none of them, but you carry them all)
- Forbidden: any ep0 change; any DooPlex change except the catalog push after its STOP (you make NO push and NO commit);
  a household box by hand; a `security_fix` step for a major version jump; turning off a check to make a test pass.
- No test traffic on demo-hp (its host or any guest: 9202, the bench 9401, Tester 1) until the line test has finished.
  YOU touch no machine at all: no ssh, no pct, no docker, no curl/POST to any box, hub, Gitea or registry write.
- Rules: secrets never printed or committed; no ep0 change; no branches; no commits; every finding a row, a fix or
  `NOT-A-FINDING: <reason>`. Never `docker system prune` or any Docker cleanup. Stay inside /mnt/5_hdd/felhom.eu/ and the
  scratchpad. Reading the web (GitHub pages, release notes, vendor docs) is allowed.
- Your job is READ and WRITE NOTES ONLY, into the scratchpad paths named below. Do not edit any repo file.

## Context
Felhom is a managed home server. Each catalog app runs from `app-catalog-felhom.eu/templates/<app>/` (docker-compose.yml
+ .felhom.yml). Last night a security watch listed upstream security notices for our pinned versions. You sort them.
Per app the data is in `<scratchpad>/tri/apps/<app>/data.json`: our pins, every GHSA notice in full (description, vulnerable
ranges in `vulns`, severity), and up to 60 recent GitHub releases (tag, date, body). Also `<scratchpad>/tri/items.json` (the
watch's own view, one item per pin, field `advisories`, including release-note hits whose id starts `release:`).

Exposure on a Felhom box: EVERY app gets a public HTTPS subdomain through a Cloudflare tunnel, so it is reachable from
the internet. Three template fields narrow that (read them in .felhom.yml):
- `family_gate: true` — a permanent door: only a household member signed in to the household gate reaches the app at all.
- `setup_gate: true` — closed to strangers ONLY until the first admin is created; after that the app is public behind its
  own login.
- `signup_block:` — traefik refuses the app's public sign-up path (strangers cannot create an account).
No gate field = the app's own login is the only door (or none). Some apps also have optional features off by default
(SSO, federation, mail import...): read the compose env to see whether a vulnerable feature is on in OUR template.

"Main version" = the FIRST number of the version (project rule; 0.20 -> 0.21 is the same main version 0). A step inside
the main version may go by the quick "security fix" lane ONLY if the release notes between our pin and the target show
no data conversion / migration of files, no removed config, no breaking change. Database schema migrations that the app
runs itself on start are normal and fine; a FILE layout change, a required manual step, a changed env var name, a new
required service, or a database ENGINE major change (postgres 15 -> 16 etc.) is NOT fine for the quick lane.

## What to decide per app
1. Each notice: REAL (it affects our pinned version, per its ranges or by reading) or NOT-A-FINDING + one-line reason
   (e.g. "affects only the desktop client we do not ship", "range ends below our pin", "it is about the project's own CI
   workflow, not the product", "a release-note hit that only mentions the word security"). For `release:` hits read the
   release body itself: is it a real security fix of the app (or of its runtime, e.g. Node.js security release bundled in
   the image)? Say which.
2. For each REAL notice: severity; needs a login? (none / any user / admin); reachable on a Felhom box with OUR template
   (consider the gates above and whether the vulnerable feature is enabled in our compose).
3. The fix: the SMALLEST released version that fixes every real notice; and the recommended TARGET = the newest stable
   release in the same main version that is >= that fix (stable only, no rc/beta). Give the exact image tag as it would
   appear in our compose (match our tag style: `v` prefix or not — check the registry tag naming from our current pin).
   If the app has TWO+ images (e.g. web + db, server + ml), give each one's target.
4. Main version same? yes/no. Breaking changes / migrations between our pin and the target, read from the release notes
   (list them, or "none found" with how many releases you read).
5. Lane: SECURITY_FIX (same main version, nothing breaking) / BIG_STEP (new main version, or breaking changes) /
   NO_FIX (a real notice with no fixed release) / NOT_A_FINDING (nothing real). An app can have both (e.g. SECURITY_FIX
   for some notices + NO_FIX for one) — say so.
6. A note for the watch's classifier if it flagged something it should not (one line, concrete), else "none".
7. For NO_FIX notices: what in our template would block it (gate, feature off), and 2 options for the operator with
   the cost and "if you do nothing".

## Output
Write `<scratchpad>/tri/apps/<app>/triage.md` per app (plain, compact; cite the release tags and GHSA ids you read). Then reply
with ONE markdown table, one row per app, columns:
| app | our pin(s) | real / total notices | worst real severity | login needed | reachable on a box | smallest fix | TARGET tag(s) | same main | breaking changes | lane | classifier note |
Keep the reply under 900 words. Be exact; when unsure, say "unsure: <why>" — never guess a version tag (check the
release list / registry tag pages).