Add thin-parity-lib-publish template + disposition of #10's 9 repos

README.md

@@ -13,15 +13,10 @@ s390x cross-build repos that share the "single build-and-publish step, inline
 Generated files carry a `GENERATED by oleks/ci-scripts — do not hand-edit`
 header; edit `manifest.yaml` and re-run `python3 generate.py` instead.
 
-Not every s390x/arm64 repo fits this template — some (`asyncpg`,
-`cryptography`, `fastuuid`, `lightningcss`, `nextjs-swc`, `rollup`,
-`onnxruntime`, `scikit-learn`, `scipy`) run a genuinely different "thin
-parity-lib publish" pipeline with per-repo Redis sccache wiring and a
-pipeline-doctor gate — those differences are load-bearing, not copy-paste
-drift, and were deliberately left un-templated (see the scope note atop
-`manifest.yaml`). `geesefs-s390x`, `sentry-cli-s390x`, `attic-client-s390x`,
-`angie-arm64`, `devpi-arm64`, and `mempalace` are bespoke pipelines (OCI image
-publish, binary builds, multi-file workflows) and are also out of scope.
+`geesefs-s390x`, `sentry-cli-s390x`, `attic-client-s390x`, `angie-arm64`,
+`devpi-arm64`, and `mempalace` are bespoke pipelines (OCI image publish,
+binary builds, multi-file workflows) and are out of scope for either
+template.
 
 Verify with:
 
@@ -30,6 +25,39 @@ python3 generate.py --check   # fails if any rendered file is stale
 woodpecker-cli lint <repo>/.woodpecker.yaml
 ```
 
+## thin-parity-lib-publish template (oleks/ci-scripts#10)
+
+The same `generate.py` also renders a second, genuinely different shape via
+`render_thin()` + the `thin_repos:` list in `manifest.yaml`: no inline attic
+accelerator, publish is a pure `nix run .#publish[-s390x]` front door,
+optionally gated by a `pipeline-doctor --strict` step first. Covers
+`asyncpg`, `cryptography`, `lightningcss`, `nextjs-swc`, `rollup`-s390x.
+
+Real per-repo variance parameterized (not papered over): `doctor` gate
+presence, `token_direct` (`REGISTRY_TOKEN` straight from secret vs.
+`CI_REGISTRY_TOKEN` + explicit remap), `publish_style` (`PUBLISH=1 nix run
+.#publish` vs. `nix run .#publish-s390x -- --publish`), `tags_full` (full
+clone with tags vs. shallow), and `dead_secrets` (some repos declare
+`ATTIC_TOKEN`/`REDIS_PASSWORD` but never reference them — preserved as-is,
+not this issue's scope to clean up).
+
+Excluded after re-audit, not forced:
+
+- `fastuuid-s390x` — declares `CI_REGISTRY_TOKEN` but has **no** `export
+  REGISTRY_TOKEN=...` remap before `PUBLISH=1 nix run .#publish`
+  (`cryptography-s390x`, the only other `CI_REGISTRY_TOKEN` user, does have
+  the remap). This looks like a real latent bug — publish would run with
+  `REGISTRY_TOKEN` unset. Flagged, not silently fixed via templating.
+- `onnxruntime-s390x` — same `CI_REGISTRY_TOKEN`-without-remap pattern as
+  `fastuuid-s390x`, and it's actually attic+redis shaped (single step) like
+  the `pypi-wheel-attic` family above, not this one. Left hand-maintained.
+- `scikit-learn-s390x`, `scipy-s390x` — attic+redis shaped like the
+  `pypi-wheel-attic` family, but their Redis setup writes exports to a file
+  via a heredoc that's never sourced elsewhere in the step, unlike
+  `tiktoken-s390x`'s direct-export style. Whether that heredoc form actually
+  does anything meaningful isn't confirmed; normalizing it to direct exports
+  would be a real behavior change, not a safe refactor. Left hand-maintained.
+
 ## Node-pinning convention (oleks/ci-scripts#5)
 
 Woodpecker agents advertise `custom_labels` of `{arch, worker}` (e.g.