Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3775@bnt-lap001
Assistant-Session: cfacb6a5-ad5b-4f79-ac67-053e3b0d34a3
Updated by fix-consistency on 2026-09-25:
- update .custodian-brief.md for railiance-apps
Assistant: grok
Assistant-Session: 01a0d25d-d358-7e13-b84a-d007fbb7e34f
Set flavor on open workplans from origin/prose/status. Copy existing
depends_on aliases only. Do not promote residuals.
Assistant: grok
Assistant-Session: 01a09dc1-b21e-77e1-919e-fcad2f82b267
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
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
