# Why this directory exists, and the trap it carries

Gitea uses `.gitea/workflows` **if it exists**, and falls back to
`.github/workflows` only when it does not. It never merges them.

So adding one Gitea-only workflow here silently switches off CI — and therefore
auto-merge — for the whole repository on Gitea. There is no error and no run to
click on. It looks exactly like a runner that has not picked the job up, so you
wait, and waiting never fixes it.

**Every workflow that must run on Gitea has to be in this directory.**
`ci.yml` and `compat.yml` are kept byte-identical in both roots, and
`ci/workflows-in-sync.sh` fails if the two copies drift apart or if a workflow
appears in only one of them without a stated reason.

`release.yml` is the deliberate exception: a release workflow publishes to
whichever forge runs it, and the two copies publish to different places. The
Gitea one is the one that matters — that is where the update feed shops read
lives.

Two further rules learned the hard way:

- **No `concurrency:` block in a Gitea workflow.** It produces no run at all —
  not a failed one, not a cancelled one. Same shape of trap, same symptom.
- If a Gitea workflow produces no run, **suspect the file, not the runner**.