Add the ttg-ops plugin: six skills for the forge estate

The marketplace held only MCP servers so far. These are skills for the
work that keeps costing manual effort and quietly breaking:

- ttg-publish-module — releasing a library, and verifying from a clean
  external project that the release is actually fetchable. Encodes the
  trap that cost the most: Gitea redirects old repo paths, but not Go
  module paths, so a repo can be reachable while `go get` fails.
- ttg-move-repo — moving a repo and following it through every place
  that names it, including the ones redirects do not cover.
- ttg-new-repo — creating one in the right org and registering it, so
  it cannot end up absent from the clone list the way batocera-store did.
- ttg-ci-enroll — wiring a repo into the build, and the usual failure
  where the config exists but the repo was never registered.
- ttg-audit-forge — the drift check between forge, clone list, wiki,
  catalog and CI.
- ttg-update-docs — README, wiki page and the public site (Vue page plus
  both locale files) after a change.

The rules stay in REPO_REFACT.md, WIKI_CONNECTION.md and
ECOSYSTEM_PLAN.md; the skills read them instead of carrying a second
copy that drifts.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-16 11:07:39 +02:00
co-authored by Claude Opus 5
parent e25cc494d2
commit 4192fc366e
9 changed files with 405 additions and 2 deletions
@@ -0,0 +1,52 @@
---
name: ttg-ci-enroll
description: Wire a TTG repo into the Woodpecker build and prove the pipeline actually runs — the one-line platform config, the builder image, registration, and the catalog entry it publishes to. Use when a repo should start building, or when a build is not running even though the config is in place ("kösd be a CI-be", "nem fut a build", "enroll CI").
allowed-tools: Bash, Read, Edit, Write, Grep, Glob
---
# ttg-ci-enroll
Egy repo bekötése a buildbe. A leggyakoribb hiba nem a konfig hiánya, hanem hogy **a konfig megvan, de a repo nincs regisztrálva** — ilyenkor semmi nem történik, és nincs hibaüzenet sem.
## Hogyan épül fel a build
A repo `.woodpecker.yaml`-ja egyetlen sor:
```yaml
# The CI pipeline is served by the update server: GET /build/config?platform=ebitengine
platform: ebitengine
```
A tényleges pipeline-t a WarpEngine **config-extension** szolgáltatása állítja elő (`/build/config`), a builder image-eket pedig a `services/teletypegames` `apps/api/config/initializers/warp_engine.rb`-je sorolja fel (`c.ci_platforms`). Ezért egy image-bump egyetlen sor ott, nem hét repóban.
Támogatott platformok: `c64`, `tic80`, `ebitengine`, `love`, `godot`, `bevy`, `phaser`.
## Lépések
1. **Platform-konfig.** Ha nincs, hozd létre a `.woodpecker.yaml`-t a fenti egy sorral. **Figyelj a kiterjesztésre:** mindkettő él a vadonban (`.woodpecker.yaml` és `.woodpecker.yml`), keresd mindkettőt, mielőtt hiányzónak nyilvánítod. Új repóhoz a `.yaml` a preferált.
2. **Toolchain.** A platform `build/<platform>-tools` repója adja a Makefile-mintát (`example-makefile.make`) és a builder image Dockerfile-ját. Új projekt Makefile-ja innen induljon, ne másolásból.
3. **Go projekt esetén `GOPRIVATE`.** Ha a repo saját modulra (`engines/…`) támaszkodik, a Makefile-ban legyen `export GOPRIVATE = git.teletypegames.org` — a saját modulјaink nincsenek a proxy.golang.org-on. Ha `replace ... => ../<repo>` direktíva van a `go.mod`-ban, **az CI-ben biztosan bukik** (testvérkönyvtárat vár): adasd ki a függőséget rendes verzióval a `ttg-publish-module` skillel, és dobd el a replace-t.
4. **Regisztráció a Woodpeckerben.** A repo aktiválása a Woodpecker felületén történik; a WarpEngine oldali nyilvántartás ebből szinkronizálódik.
5. **Ellenőrzés.** Mit tud a rendszer:
```sh
curl -s https://teletypegames.org/api/ci/pipelines
```
A sorokban `repo_owner`, `repo_name`, `platform`, `active`, `last_pipeline_status`. Amíg a repo nincs a listában, nem fut rá build.
## Ha „be van kötve", mégsem fut
Ellenőrizendő sorrendben:
- **Tényleg a listában van?** A `/api/ci/pipelines` a mérce, nem a repóban lévő fájl.
- **Elavult tulajdonos.** A tábla `repo_owner`-je org-váltás után a régi orgot mutathatja, amíg a szinkron nem futott. A szinkron `woodpecker_repo_id`-ra kulcsol és a távoli adatból frissíti a tulajdonost, tehát magától rendbe jön — de addig félrevezet.
- **Tag-esemény.** Ha a pipeline `when: event: tag`-re van kötve (publikáló lépések), a sima push nem indítja. Nézd meg, hogy a repón engedélyezett-e a tag-build.
- **Secret jogok.** A publikáló lépések tokenjének `package:write` kell, és org-váltás után a leírásában szereplő cél is elavulhat.
- **`last_pipeline_status`.** A `failure`/`error` érték már önmagában irány — ne a konfigot kezdd el javítgatni, előbb nézd meg, mi bukott.
## A végén
Ha a bekötés új platformot tesz élővé, az `ECOSYSTEM_PLAN.md` platform-lefedettségi táblázatában javítsd az „Aktív CI" oszlopot.