# Changelog

## 2026-06-23 — gokapi reproducible headless setup (fixes public "maintenance mode")
- **gokapi**: was stuck in "maintenance mode" on the public URL since first deploy — Gokapi's one-time
  `/setup` wizard was never completed, and (verified against the docs + the v1.9.6 binary) **no Gokapi
  version supports env-var headless setup** for admin credentials. Worse, the unconfigured `/setup` was
  publicly reachable = an unauthenticated admin-takeover window.
  - Fix: the compose `entrypoint` now seeds a `config.json` on first boot (admin user, this app's public
    URL `https://${SUBDOMAIN}.${DOMAIN}/`, local storage, Encryption Level 0 so it restarts without a
    prompt) with `Password`/`SaltAdmin`/`SaltFiles` cleared, then runs Gokapi's documented
    `--deployment-password` one-shot to set the **felhom-generated** admin password **before** the
    server starts serving. The admin account is claimed at first boot → `/setup` is never exposed.
  - `.felhom.yml`: new `GOKAPI_PASSWORD` deploy field (`type: password`, `generate: password:24`,
    shown to the customer, locked after deploy). Admin username is `admin`.
  - Seed is pinned to Gokapi **v1.9.6** (`ConfigVersion 21`) — re-capture the seed if the image is bumped.
  - Live-validated on guest 9201: fresh remove+redeploy → headless auto-config, public login works, no
    maintenance page, admin claimed at first boot (browser-verified login).

## 2026-06-22 — gitea healthcheck fix (unattended test campaign)
- **gitea**: healthcheck probe repointed `/api/v1/version` → `/api/healthz` (docker HC + controller
  `.felhom.yml` probe), `start_period` 30s → 90s.
  - Surfaced during the Phase-2 deploy sweep: a fresh gitea reported `unhealthy` because
    `/api/v1/version` returns 404 until the install wizard / INSTALL_LOCK completes, while the
    container was serving fine on :3000 (`/api/healthz` → 200). Same class as the komga fix.

## 2026-06-22 — komga healthcheck fix (unattended test campaign)
- **komga**: healthcheck probe repointed `/api/v1/actuator/health` → `/actuator/health`.
  - Root cause: komga's Spring Boot actuator endpoint is served unauthenticated at `/actuator/health`
    (HTTP 200), while everything under the `/api/v1` prefix is auth-gated — so the old probe got
    HTTP 401, `curl -f` exited 22, and the container reported `unhealthy` despite serving normally
    on :25600. Diagnosed live on guest 9201 (probe matrix: `/`, `/actuator/health`,
    `/api/v1/oauth2/providers`, `/login` all 200; `/api/v1/actuator/health` → 401).
  - The `gotson/komga:1.20.0` image ships `curl` (verified), so the probe tool is unchanged.