deploy log: OAuth app via API, Sveltia pointed at machine Gitea, editor-cycle latency measured (12s/21s)

deploy/DEPLOY-LOG.md

@@ -118,25 +118,54 @@ editor → Sveltia (/admin, static) → commit → Gitea :3000 (container, SQLit
 - Red journal entries from the netavark restart loop (history, not a live fault).
 - Disk: 11 G → 9.6 G free (images ~590 MB + repo/content). RAM available ~1.3 G.
 
+### 5. Pipeline proven end-to-end on the machine (2026-07-28)
+- Pushed `46ec5e2` to the machine's Gitea (incremental bundle, 6 KB — this is
+  what ongoing syncs cost, vs the 78 MB one-off bootstrap).
+- **The poller published it automatically in 26 s end-to-end** (push →
+  visible), of which the build itself was 21 s. That is the demo's publish
+  latency: **~30 s worst case** on 2 vCPU (vs 44 s for the very first build
+  which included `npm ci`). Cold-cache builds only happen when the lockfile
+  changes.
+- Verified after publish: `/` 200, `/admin/` 200 (Sveltia), an article page
+  200; neighbours untouched (Strapi 204, Outline 200); RAM available 1.2 G,
+  disk free 9.0 G.
+
+### 6. Sveltia wired to the machine + editor cycle proven (2026-07-28)
+- **OAuth app created via API, no UI clicking**: temp `write:user` token from
+  `gitea admin user generate-access-token` (CLI in container) → POST
+  `/user/applications/oauth2` → temp token deleted (needed basic auth from
+  `initial-admin.txt`; token-auth DELETE returns 401). App: "Sveltia CMS
+  (demo)", `client_id cf1c44ac-ebe6-4a97-bf2f-f7f26ef1126c`, PKCE
+  (`confidential_client=false`), redirect_uris: `http://localhost:18080/admin/`
+  and `http://localhost:8080/admin/`.
+- **Found & fixed**: `public/admin/config.yml` still pointed at the MAC's Gitea
+  (`localhost:3010` + old app_id) — CMS login on the machine could never work.
+  Switched to `localhost:3000` + machine app_id (`bc02012`). localhost:3000 is
+  valid both on the machine and through the tunnel (same-port trick).
+- **Editor cycle simulated exactly like Sveltia does it** (Gitea contents API):
+  create article via API → **live on the portal in 12 s**; delete via API →
+  **gone in 21 s**. Repo left clean (`29385a5`). Earlier full-push rebuild:
+  16 s build. Publish latency ≈ **10–30 s** depending on poll-tick alignment.
+- Tunnel run from the Mac with keepalive (`-o ServerAliveInterval=30`), portal
+  mapped to **18080** locally (user request: non-default port), Gitea kept at
+  **3000** (must match ROOT_URL). First tunnel died after idle — keepalive fixed.
+- Push token scope confirmed minimal (`write:repository` only) — cannot manage
+  users/apps; file format is `<name>:<40-hex>` (grep the hex out).
+
 ## TODO (next agent starts here)
 
-1. **Commit the last local fix** (`build.sh`: `--ignore-scripts` + npm cache)
+1. ~~Commit the `--ignore-scripts` fix and mirror to the machine~~ — DONE
-   to the local Gitea repo, then mirror it to the machine's Gitea so the
+   (`46ec5e2`, and it doubled as the live pipeline test above).
-   machine's copy of the repo matches. NOTE: `build.sh` currently lives in
+2. ~~Measure incremental publish latency on the machine~~ — DONE: **26 s
-   the same repo as the content; pushing to the machine repo re-triggers a
+   end-to-end**, build 21 s.
-   build (that is fine and is a good live test of the pipeline).
+3. ~~Verify the loop through `ssh -L`~~ — mostly DONE: tunnel
-2. **Measure an incremental rebuild on the machine** (push a trivial content
+   `-L 18080:localhost:8080 -L 3000:localhost:3000` (with ServerAlive
-   change → time from commit to visible change). Expect ~10–20 s total.
+   keepalive) verified with real content. **Remaining: the user clicks
-   Record the number here; it is the "publish latency" figure for the demo.
+   "Sign in with Gitea" at `http://localhost:18080/admin/`** and edits an
-3. **Verify the whole loop through `ssh -L`** with the user watching:
+   article in the browser — the only step that needs a human + browser
-   `ssh -L 8080:localhost:8080 -L 3000:localhost:3000 strapi-experimental.cyfronet`
+   (PKCE login). Credentials: `initial-admin.txt` on the machine.
-   → portal at `http://localhost:8080`, Gitea at `http://localhost:3000`.
+4. ~~Sveltia OAuth app~~ — DONE via API (see §6). Config committed and
-   Note: forwarding the SAME port numbers keeps Gitea's `ROOT_URL` valid,
+   auto-published. Only the browser login test remains (see 3).
-   so Sveltia's OAuth login can be tested end-to-end before any vhost exists.
-4. **Sveltia OAuth app**: create in Gitea UI (Settings → Applications), PKCE,
-   redirect to the portal `/admin/`; put URL + client id in
-   `public/admin/config.yml`; commit → auto-publishes. Then test a real edit
-   from the browser (the demo's money shot).
 5. **Message to Hubert** (only after we have seen it working):
    - two ingress vhosts → `192.168.10.15:8080` (portal) and `:3000` (gitea),
      same mechanism as `strapi.isl-dev…:1337`;