An earlier version said the origin unblocks KEY-WP-0013-T02, 'blocked since
2026-09-08'. Both halves are wrong. T02 is done, and so is T05 -- the task that
actually held the human registration. key-cape published the contract shape from
its side and closed a follow-up informed-decision prompted (KEY-WP-0030).
Nothing there waits on this host.
The error came from repeating informed-decision's workplan prose of 2026-09-09
without checking the source repo. The origin work stands on its own: T07's
acceptance requires a real origin regardless of who else is waiting.
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
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
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
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.
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.
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.
Materialize offsite Secret from OpenBao, deploy per-cluster CronJobs,
generalize multi-cluster logical backup + status health for Option A,
seed encrypted uploads and restore-drill evidence; workplan finished.
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.
Document OpenBao/warden paths for the offsite backup lane and flag the sealed
Vault blocker. Point production Makefile targets at CoulombCore, auto-discover
CNPG clusters in backup status, add apps-pg pg_dump dry-run tooling, and
record Core Hub Helm cutover findings (live gitea image, adopt required).
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.
Found while smoke-testing the REUSE-WP-0019-T01/T02 deploy: GET
/v1/federated works (200) but the exact-path /health rule 404s at the
Traefik edge, shadowed by the catch-all / rule to reuse-surface-landing.
Confirmed pod/service-level health is fine (direct port-forward works,
readiness/liveness probes pass, pod is 1/1 Ready) -- this is an ingress
routing config issue affecting external monitoring only, not the API
itself. Not fixed here; needs a Traefik router priority annotation on
charts/reuse-surface/templates/ingress.yaml, a deliberate change to shared
production ingress outside this task's scope.
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.
