Neues, unabhängig versioniertes Go-Modulcommon/. Dieser PR legt nur das Modul an, kein bestehendes Modul wird geändert (außer PRODUKTARCHITEKTUR.md) — risikolos mergebar. Die Verbraucher-Module werden in Folge-PRs umgestellt.
Pakete: apierror, auditclient, httpclient, httpharden, loadtest, migrate, policyclient, svcauth, tenantregistryclient, testdb (jeweils nur dort aufgenommen, wo der Code ohne Kommentare/Importpfade byte-gleich über Module hinweg ist)
common/go.mod mit pgx v5.9.2 (für migrate, testdb), go.sum, go mod tidy ohne Änderung
.gitea/workflows/common-tag.yml: nach Merge in main mit Änderung unter common/ Build/Vet/Test, dann nächster Patch-Tag common/v0.X.Y (Start v0.1.0)
common/README.md: Einbindung (GOPRIVATE, Read-only-Token in .netrc), Versionierung, Regeln
Wächtertest httpclient prüft nur noch common selbst; die Verbraucher brauchen ihren eigenen Guard (Teil der Umstellungs-PRs)
Entscheidungen (mit dir geklärt)
pgx in common; Module bauen teils einzeln (Docker nur Modul-Ordner, eigene Repos, Partner-Builds) → Tags statt replace; Read-only-Deploy-Token in .netrc je Build-Ort; Tag per CI; Semver v0.x, Module aktualisieren einzeln; pflichttestgate parametrisiert in eigenem PR.
Verifikation (Host 131, frisches Wurfverzeichnis)
gofmt sauber, go build, go vet, go test ./... in common grün (apierror, auditclient, httpclient, httpharden, policyclient, svcauth, tenantregistryclient). migrate und testdb haben keine Tests.
Nicht getestet / offen vor dem Merge
common-tag.yml nie gelaufen. Annahmen: Runner darf Tags pushen (Gitea-Token mit Schreibrecht im Checkout), actions/setup-go auf dem Host-Runner liefert Go 1.25. Beim ersten Merge Lauf beobachten.
Build-Orte (131, 204, Runner, Docker) brauchen GOPRIVATE + Read-only-Token, bevor Verbraucher umgestellt werden.
go.sum der Verbraucher entsteht erst nach dem ersten Tag.
Ersetzt #376/#377 (dort `replace => ../common`, bricht Einzel-Builds).
## Änderung
Neues, **unabhängig versioniertes Go-Modul** `common/`. Dieser PR legt nur das Modul an, **kein bestehendes Modul wird geändert** (außer `PRODUKTARCHITEKTUR.md`) — risikolos mergebar. Die Verbraucher-Module werden in Folge-PRs umgestellt.
- Pakete: `apierror`, `auditclient`, `httpclient`, `httpharden`, `loadtest`, `migrate`, `policyclient`, `svcauth`, `tenantregistryclient`, `testdb` (jeweils nur dort aufgenommen, wo der Code ohne Kommentare/Importpfade byte-gleich über Module hinweg ist)
- `common/go.mod` mit `pgx v5.9.2` (für `migrate`, `testdb`), `go.sum`, `go mod tidy` ohne Änderung
- `.gitea/workflows/common-tag.yml`: nach Merge in `main` mit Änderung unter `common/` Build/Vet/Test, dann nächster Patch-Tag `common/v0.X.Y` (Start `v0.1.0`)
- `common/README.md`: Einbindung (`GOPRIVATE`, Read-only-Token in `.netrc`), Versionierung, Regeln
- Wächtertest `httpclient` prüft nur noch `common` selbst; die Verbraucher brauchen ihren eigenen Guard (Teil der Umstellungs-PRs)
## Entscheidungen (mit dir geklärt)
pgx in `common`; Module bauen teils einzeln (Docker nur Modul-Ordner, eigene Repos, Partner-Builds) → Tags statt `replace`; Read-only-Deploy-Token in `.netrc` je Build-Ort; Tag per CI; Semver `v0.x`, Module aktualisieren einzeln; `pflichttestgate` parametrisiert in eigenem PR.
## Verifikation (Host 131, frisches Wurfverzeichnis)
`gofmt` sauber, `go build`, `go vet`, `go test ./...` in `common` grün (apierror, auditclient, httpclient, httpharden, policyclient, svcauth, tenantregistryclient). `migrate` und `testdb` haben keine Tests.
## Nicht getestet / offen vor dem Merge
- **`common-tag.yml` nie gelaufen.** Annahmen: Runner darf Tags pushen (Gitea-Token mit Schreibrecht im Checkout), `actions/setup-go` auf dem Host-Runner liefert Go 1.25. Beim ersten Merge Lauf beobachten.
- Build-Orte (131, 204, Runner, Docker) brauchen `GOPRIVATE` + Read-only-Token, bevor Verbraucher umgestellt werden.
- `go.sum` der Verbraucher entsteht erst nach dem ersten Tag.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Pakete: apierror, auditclient, httpclient, httpharden, loadtest, migrate,
policyclient, svcauth, tenantregistryclient, testdb. Code stammt aus den
bisher byte-gleichen Modulkopien (ohne Kommentare/Importpfade verglichen).
migrate/testdb brauchen pgx v5.9.2.
Auslieferung per Git-Tag common/vX.Y.Z (Workflow common-tag.yml, setzt nach
Merge in main den naechsten Patch-Tag nach Build/Vet/Test). Kein replace,
damit Module einzeln baubar bleiben. Verbraucher werden in Folge-PRs
umgestellt.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ersetzt #376/#377 (dort
replace => ../common, bricht Einzel-Builds).Änderung
Neues, unabhängig versioniertes Go-Modul
common/. Dieser PR legt nur das Modul an, kein bestehendes Modul wird geändert (außerPRODUKTARCHITEKTUR.md) — risikolos mergebar. Die Verbraucher-Module werden in Folge-PRs umgestellt.apierror,auditclient,httpclient,httpharden,loadtest,migrate,policyclient,svcauth,tenantregistryclient,testdb(jeweils nur dort aufgenommen, wo der Code ohne Kommentare/Importpfade byte-gleich über Module hinweg ist)common/go.modmitpgx v5.9.2(fürmigrate,testdb),go.sum,go mod tidyohne Änderung.gitea/workflows/common-tag.yml: nach Merge inmainmit Änderung untercommon/Build/Vet/Test, dann nächster Patch-Tagcommon/v0.X.Y(Startv0.1.0)common/README.md: Einbindung (GOPRIVATE, Read-only-Token in.netrc), Versionierung, Regelnhttpclientprüft nur nochcommonselbst; die Verbraucher brauchen ihren eigenen Guard (Teil der Umstellungs-PRs)Entscheidungen (mit dir geklärt)
pgx in
common; Module bauen teils einzeln (Docker nur Modul-Ordner, eigene Repos, Partner-Builds) → Tags stattreplace; Read-only-Deploy-Token in.netrcje Build-Ort; Tag per CI; Semverv0.x, Module aktualisieren einzeln;pflichttestgateparametrisiert in eigenem PR.Verifikation (Host 131, frisches Wurfverzeichnis)
gofmtsauber,go build,go vet,go test ./...incommongrün (apierror, auditclient, httpclient, httpharden, policyclient, svcauth, tenantregistryclient).migrateundtestdbhaben keine Tests.Nicht getestet / offen vor dem Merge
common-tag.ymlnie gelaufen. Annahmen: Runner darf Tags pushen (Gitea-Token mit Schreibrecht im Checkout),actions/setup-goauf dem Host-Runner liefert Go 1.25. Beim ersten Merge Lauf beobachten.GOPRIVATE+ Read-only-Token, bevor Verbraucher umgestellt werden.go.sumder Verbraucher entsteht erst nach dem ersten Tag.🤖 Generated with Claude Code