Revision 9 redeployed main-b035664 because the tag was never bumped, so the
T09 composed-index invalidation fix did not reach production. main-6cbc862 is
the CI build of that commit; manifest verified to resolve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
image.tag was "e3ae22e", a Gitea-era tag. charts/reuse-surface/values.yaml was
repointed to the Forgejo repository in 04be416, but no e3ae22e tag was ever
published there — CI only began pushing to Forgejo three hours after that
commit. Authenticated tags/list returns latest, main-b035664, main-bca7165,
main-f9d957a. So the release could not pull its image, making ImagePullBackOff
a present risk on any restart rather than one tied to the 2026-08-31 CoulombCore
retirement.
Pin main-b035664, verified to resolve (manifest 200). It is a CI build of
reuse-surface main and carries the compose hardening that stops a single
malformed member index from returning HTTP 500 for the whole federated index —
needed before evidence-binder can be re-enabled as a source.
Also ships REUSE-WP-0019 T04/T05/T06, closed as finished but never deployed.
Not applied. Deploy is the manual `make reuse-deploy`, which needs
KUBECONFIG for Railiance01.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
helm/core-hub-values.yaml was the last file still pulling from
gitea.coulomb.social. Both hostnames resolve, but to different machines -
gitea.coulomb.social to 92.205.130.254 (CoulombCore) and forgejo.coulomb.social
to 92.205.62.239 (Railiance01) - so this quietly deployed core-hub from the
frozen CoulombCore registry rather than failing loudly. Every other values file
in this repo, including charts/core-hub/values.yaml for the same app, already
used forgejo.
The tag is a render-time placeholder; deploys pass CORE_HUB_IMAGE_TAG=<sha>, so
the next core-hub rollout must confirm that sha is present on the Forgejo
registry before promoting.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adopt live Core Hub resources, align prod ConfigMap naming, default production
image registry to gitea, and install Helm release core-hub rev 1 (smoke passed).
Add apps-pg-backup and check-backup-lane-auth targets; document OIDC login
requirement now that OpenBao is unsealed.
Add runbook coverage for REUSE_SURFACE_TOKEN and
REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET in reuse-surface-env, plus an
idempotent make reuse-forgejo-webhook target that wires the coulomb org
push webhook to the hub receiver.
Image update for the forge-host-abstraction and hub-webhook work:
composed_at/stale tracking on GET /v1/federated, new POST
/v1/webhooks/forgejo receiver (fails closed to 503 until
REUSE_SURFACE_FORGEJO_WEBHOOK_SECRET is added to the reuse-surface-env
Secret -- deliberately not added yet, needs separate explicit
authorization for a production secret write), and the migrated
activity-core/state-hub Forgejo raw URLs already visible in the composed
index.
Live-verified post-deploy: /v1/federated (61 capabilities, composed_at/
stale fields present), /v1/repos, and a forced POST /v1/federated/compose
recompose all correct.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Use PROTOCOL=smtp+starttls with the EU relay (smtp.ionos.de). Port 587 with
implicit TLS on smtp.ionos.com failed TLS handshake; .com auth also fails for
EU mailboxes. Document OpenBao PASSWD field mapping in operator docs.
Add forgejo-mailer ExternalSecret, inject GITEA__mailer__PASSWD from the
synced Secret, remove mailer from SOPS overlay, and add ESO bootstrap targets.
Restores the newer local gitea-values.sops.yaml (2026-03-27) over the
upstream scaffold (2026-03-10). Adds database, cache, session, and queue
sections pointing to external PostgreSQL/Valkey (S3 platform services),
and disables bundled postgresql/redis/valkey sub-charts.
Also adds .sops.yaml encryption policy for railiance-apps.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Receive gitea-values.sops.yaml from railiance-cluster — S5 now
owns the Gitea deployment lifecycle per ADR-003 boundary rules.
Add gitea-deploy and gitea-status Makefile targets. Update
SCOPE.md to reflect boundary violation resolved.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
