fix(ci): move workflow to .gitea/workflows — the server is Gitea, not Forgejo

The runner was alive all along (gitea/act_runner, ubuntu-latest label);
no run ever appeared because Gitea only reads .gitea/workflows/ (or
.github/workflows/) and ignores the .forgejo/ path the workflow shipped
under. The legacy repo's .gitea/workflows/check.yml was the clue.
References corrected (workflow header, TESTING.md, agent files); this
push doubles as the first live trigger of the workflow.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.gitea/workflows/check.yml

@@ -1,6 +1,6 @@
 # Nomarchy CI — the always-on net under direct-to-main pushes.
 #
-# Scope (deliberate): the EVAL tier only. The Forgejo runner behind this
+# Scope (deliberate): the EVAL tier only. The runner behind this Gitea
 # instance is act_runner + docker containers (the legacy repo's check.yml
 # ran 57 times on it) — no systemd, no /dev/kvm — so the checks.* VM
 # tests and full toplevel builds can't run here. `nix flake check
@@ -89,7 +89,7 @@ jobs:
   # CI. Needs a runner on a NixOS (or at least nix + /dev/kvm) host —
   # register one with a dedicated label, then uncomment and set runs-on
   # to that label. Do NOT enable this against a label that doesn't
-  # exist: Forgejo queues such jobs forever instead of failing.
+  # exist: Gitea queues such jobs forever instead of failing.
   #
   # vm-checks:
   #   runs-on: nix-kvm

agent/BACKLOG.md

@@ -22,16 +22,18 @@ next, in what order*.
 
 ## NOW
 
-### 20. Confirm the Forgejo runner is alive `[human]`
-The checks-on-push workflow (`.forgejo/workflows/check.yml`) shipped;
-the repo has `has_actions: true` and the legacy `check.yml` ran 57
-times on an act_runner, but whether that runner still exists is not
-API-visible without auth. Check the first run of the new workflow at
-https://git.bemagri.xyz/bernardo/Nomarchy/actions — if it sits queued,
-re-register an act_runner (docker, `ubuntu-latest` label). **Stretch:**
-a second runner on a NixOS host with `/dev/kvm` (label `nix-kvm`) —
-then uncomment the workflow's `vm-checks` job and the VM suite + real
-builds run in CI too (that upgrades half of item 14 for free).
+### 20. Confirm the first CI run goes green `[human]`
+~~Runner registration~~ — resolved: the runner was alive all along
+(gitea/act_runner via docker-compose, `ubuntu-latest` label); the
+workflow was in `.forgejo/workflows/`, which **Gitea** ignores — moved
+to `.gitea/workflows/`. Remaining: watch the first real run at
+https://git.bemagri.xyz/bernardo/Nomarchy/actions — the eval job's
+container recipe is inherited from the legacy repo but this flake's
+eval is new territory (memory headroom of the runner container is the
+likely failure mode; the legacy repo OOM'd on heavy evals). **Stretch
+(unchanged):** a second runner on a host with `/dev/kvm` + nix (label
+`nix-kvm`, host mode) unlocks the workflow's commented `vm-checks` job
+— the VM suite + real builds in CI (upgrades half of item 14 free).
 
 ### 3. Memory-pressure protection (no more frozen desktops)
 New. A workstation that compiles from source *will* hit memory

agent/JOURNAL.md

@@ -17,6 +17,21 @@ Template:
 
 ---
 
+## 2026-07-04 — CI fix: wrong workflow dir (correction to iteration #2)
+- **Task:** Bernardo reported no run despite an active runner + shared
+  his compose file: the server is **Gitea** (gitea/act_runner), not
+  Forgejo — I'd shipped the workflow to `.forgejo/workflows/`, which
+  Gitea never reads. The legacy repo's `.gitea/workflows/` path was the
+  clue I under-weighted.
+- **Did:** `git mv` → `.gitea/workflows/check.yml`; corrected the
+  Forgejo references in the workflow header, TESTING.md §1b, BACKLOG
+  item 20 (now: watch the first run; runner was never the problem);
+  MEMORY.md gains the Gitea-not-Forgejo line.
+- **Verified:** the push of this commit is itself the test — the run
+  must appear; monitoring.
+- **Pending:** first green run (item 20); runner-container memory
+  headroom is the watch-out.
+
 ## 2026-07-04 — CI checks-on-push shipped (loop iteration #2)
 - **Task:** BACKLOG NOW#2 — Forgejo Actions workflow.
 - **Did:** `.forgejo/workflows/check.yml` (push to main/v1 + dispatch):

agent/MEMORY.md

@@ -7,12 +7,15 @@ here the moment a debugging session teaches you something a future
 iteration would otherwise rediscover.
 
 ## Testing & VM recipes
-- CI (`.forgejo/workflows/check.yml`) is **eval-tier only**: the Forgejo
-  act_runner is a docker container (no systemd, no /dev/kvm). Container
-  gotchas are documented in the workflow header (single-user Nix +
-  nixbld users, `sandbox=false` for Stylix IFD, Nix pinned 2.31.5 vs
-  lazy-trees, no JS actions past node20) — learned over the legacy
-  repo's 57 runs; read them before touching the workflow.
+- CI (`.gitea/workflows/check.yml`) is **eval-tier only**: the act_runner
+  is a docker container (no systemd, no /dev/kvm). Container gotchas are
+  documented in the workflow header (single-user Nix + nixbld users,
+  `sandbox=false` for Stylix IFD, Nix pinned 2.31.5 vs lazy-trees, no JS
+  actions past node20) — learned over the legacy repo's 57 runs; read
+  them before touching the workflow.
+- The git server is **Gitea** (gitea/act_runner via docker-compose), NOT
+  Forgejo — workflows are read from `.gitea/workflows/` (or `.github/`),
+  never `.forgejo/workflows/` (a whole push cycle was lost to that).
 - Reusable headless VM harness: `checks.*` via runNixOSTest — existing
   examples to crib from: `distro-id` (boots + `switch-to-configuration
   dry-activate`), `hardware-toggles` (kernel cmdline/PAM assertions),

docs/TESTING.md

@@ -24,8 +24,8 @@ so template/wrapper drift fails fast too.
 
 ## 1b. CI (automatic on push)
 
-Every push to `main`/`v1` runs `.forgejo/workflows/check.yml`: the §1
-cheap checks (flake eval, Python + shell syntax) on the Forgejo instance.
+Every push to `main`/`v1` runs `.gitea/workflows/check.yml`: the §1
+cheap checks (flake eval, Python + shell syntax) on the Gitea instance.
 That's the **eval tier only** — the runner is a docker container without
 KVM, so the `checks.*` VM suite and real builds stay local (this file)
 until a KVM-capable runner is registered; the workflow carries a