The main Ingress is websecure-only per the forgejo pattern, so port 80 was
unrouted for this host and plain http:// returned Traefik's default 404. Adds a
redirectScheme Middleware plus a web-entrypoint Ingress, following the
reuse-surface pattern.
Pins router.priority: "1" on the redirect. cert-manager solves HTTP-01 by
creating a solver Ingress on this same host and entrypoint, so a catch-all "/"
redirect competes with it directly. Traefik would normally settle that by rule
length, but reuse-surface's 2026-07-07 report is exactly a case of a specific
rule losing to a catch-all when precedence was left implicit -- and here the
symptom would not be a visible 404 but a silently failed renewal ~60 days out,
surfacing as an expired certificate on the origin backing an OIDC redirect URI.
Verified by probe twice: with a solver-shaped Ingress present the challenge path
returns 200 (solver wins) while "/" still redirects; with it absent the redirect
correctly catches both. Probe was throwaway and is not committed; the runbook
carries the table to recreate it.
GET returns 301 and HEAD 308. That split is Traefik's own behaviour on this
cluster, not a defect here -- reuse.coulomb.social does the same.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
Updated by fix-consistency on 2026-09-10:
- update .custodian-brief.md for railiance-apps
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
Applied the origin manifests with operator approval. Placeholder pod 1/1,
cert-manager issued CN=decisions.coulomb.social from Let's Encrypt (valid to
2026-12-09), and https://decisions.coulomb.social/auth/callback returns 200 over
a verified chain.
This clears step 1 of INFD-WP-0001-T07's dependency table, which has blocked
key-cape's KEY-WP-0013-T02 since 2026-09-08.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
INFD-WP-0001-T07 has been blocked since 2026-09-08 on an OIDC redirect URI it
cannot publish without a real deployed origin, which in turn blocks key-cape's
KEY-WP-0013-T02. The operator assigned decisions.coulomb.social; DNS already
resolves to the cluster address.
Adds the Ingress + letsencrypt-prod certificate for the host and a placeholder
nginx backend, so the origin answers before the approver UI itself exists
(INFD-WP-0001-T08 is still gated on approval-engine and on intake INFD-IN-0003).
A redirect URI matches byte-exactly at /authorize, so a host that resolves but
does not complete a TLS handshake fails closed at first login and presents as a
rejected approval rather than a registration defect.
The Ingress carries one path rule on purpose: reuse-surface reported on
2026-07-07 that an Exact rule alongside a catch-all Prefix rule on the same host
was swallowed by the catch-all. That trap is worth avoiding on a host whose
entire purpose is exact-match redirect handling.
Dry-run clean against the live API; deliberately not applied.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EJbh7o7UWF4tQ5jxygnNGu
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2072522@bnt-lap001
Assistant-Session: 46173adf-7302-4ede-99d6-963b61359928
Completes the migration begun on 2026-08-25, which covered active workplans
only. The archived copies kept their historical identifiers, and three
repositories shared one number space — so their task identifiers collided,
blocking task-level projection reset for those workplans.
Numbering continues each repository's active sequence rather than restarting,
so no identifier is reused. Projection UUIDs are re-derived from the new
canonical ids.
Refs CUST-WP-0068, STATE-WP-0083-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
RAILIANCE-WP is a family name, not a repository (ADR-007, and the prefix
registry already lists it retired). Three repositories independently used one
number space for unrelated work — RAILIANCE-WP-0012 was openbao extraction here,
a cnpg backup in railiance-apps and a deploy-verify in railiance-cluster. This
repository also carried two files both numbered 0016.
Active workplans move to the successor prefix and are renumbered from 0001 in
historical order. Archived workplans keep their historical identifiers.
Projection UUIDs are re-derived from the new canonical ids. Records already
registered under the old identifiers leave orphaned hub rows behind; that debt
is recorded in CUST-WP-0068 and clears when ADR-012's reset-from-forge lands.
Refs CUST-WP-0068-T03
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.
Records central already holds were deliberately left untouched.
Refs CUST-WP-0068-T06
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
The remote row pointed at 127.0.0.1:18000, a reverse tunnel back to the
workstation. On railiance01 the State Hub runs in the cluster on that same
machine, so the request left the box and came back to reach a local service.
Refs CUST-WP-0067-T07
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
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>
/health returned nginx 404 through the ingress while the service answered 200
in-cluster. The ingress rule was correct on paper — /health Exact ->
reuse-surface:8000 alongside / Prefix -> reuse-surface-landing:8080 — but
Traefik derives router priority from the length of the generated rule string,
and Path(`/health`) and PathPrefix(`/`) are both 15 characters. The tie broke
toward the landing page. PathPrefix(`/v1`) is longer, which is why /v1 worked
and the fault looked like a /health-only bug.
traefik.ingress.kubernetes.io/router.priority applies per Ingress, not per
path, so the catch-all moves into its own Ingress with priority 1. Every API
route now outranks it regardless of rule length.
This is not cosmetic: make reuse-smoke curls /health and false-negatives on an
otherwise healthy release.
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>
Retires the shared prefix. Live plans move to the new prefix keeping their
running number; finished and archived files keep the old prefix as
historical record, per the ADR-007 option 2 migration ruling.
Hub UUIDs are unchanged, so reconciliation matches on
state_hub_workstream_id rather than filename and will update the slug in
place instead of registering duplicates.
Assigned in RMGR-WP-0004-T09.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CORE_HUB_IMAGE_REPOSITORY was the only one of four app image defaults still on
gitea.coulomb.social. It is passed as --set image.repository= when a tag is
supplied, so it overrides helm/core-hub-values.yaml at deploy time - fixing the
values file alone would have left the actual deploy path pointing at the frozen
CoulombCore registry.
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>
Forgejo has replaced Gitea as the forge. Updates SCOPE.md Current State,
AGENTS.md and .claude/rules/repo-identity.md, which still described Gitea as
the operational forge.
Deliberately NOT changed, because they are accurate rather than stale:
- migration and coexistence prose in docs/forgejo-on-railiance01.md,
docs/forge-source-of-truth-decision.md and the capability registry, where
Gitea is the thing being migrated from
- gitea-charts/gitea 12.5.0, the real Helm chart Forgejo deploys from
- gitea-db, a running CNPG cluster, and the gitea- prefixed doc filenames in
railiance-forge, which still exist under those names
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Builds SECRET_KEY, optional URL-encoded DATABASE_URL from app DB
credentials, and USER_ENGINE_PROXY_SECRET from user-engine-runtime.
Never prints values; Makefile dry-run and apply targets.
Maintainer decision, 2026-07-29: adopts TRSL V1C1 as this repo's
preliminary governing license, per target-revenue's
workplans/TREV-WP-0008-governance-and-pilot-rollout.md T05. Full
specialist legal review is deferred until out of beta (target-revenue
SCOPE.md §1). No Phase is yet declared for this repo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Mark workplan active with T01/T02 done, document topology, extend status
for activity-core mode, and wire Make targets to the platform multi-host
backup CLI. T03 remains operator-blocked on ESO token.
Capture post-WP-0015 posture (workstation SPOF) and register a workplan to
move unattended Option A + Forgejo backup automation to railiance01 via
activity-core without a laptop control plane.
Cluster egress blocks age installs (github + Alpine CDN). Declare
workstation-cron schedule ConfigMap as the unattended path and keep
Option A CronJobs suspended until a prebuilt image is available.
