coulomb/informed-decision
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(T07): settle the approver origin as decisions.coulomb.social

Browse source 
The operator assigned decisions.coulomb.social, not the decide.coulomb.social
this workplan proposed. Redirect URIs match byte-exactly at /authorize, so the
proposal is corrected in place rather than reconciled after submission — a
one-character miss presents as a rejected approval, not as a registration
defect.

DNS resolves. The Ingress and certificate are written in railiance-apps
(manifests/informed-decision-ingress.yaml, dry-run clean) but not applied, so
T07 stays progress: DNS alone is not an origin, and a host that does not answer
over TLS fails the same way a wrong hostname does, only later.

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
This commit is contained in:
tegwick 2026-09-10 16:17:52 +02:00
parent 0838bf81fa
commit 4d33a59f5b
2 changed files with 41 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

27
workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md
View file

@ -380,13 +380,26 @@ not be declared unless we are prepared to say so in the record. We are, and it
is said there, along with the two consequences: the claim is stored with its
provenance, and it is never used as the act-scope.
**Not submitted, and the task stays `progress`.** The origin
(`decide.coulomb.social` proposed, consistent with the estate's existing
Traefik/TLS-per-host pattern) needs a DNS A record, an Ingress manifest and a
certificate — work in `railiance-apps`, not here. Submitting a redirect for a
host that does not resolve is the exact failure `approval-engine` avoided by
refusing to invent these strings in the first place, and choosing a plausible
hostname is not the same as owning one.
2026-09-10 — **origin assigned.** The operator assigned
`decisions.coulomb.social`, not the `decide.coulomb.social` this workplan
proposed. `docs/keycape-client-registration.md` §2 is corrected to the assigned
name; the proposal is not preserved anywhere a reader could mistake it for the
registration, because a redirect URI that is one character off fails closed at
`/authorize` and presents as a rejected login rather than a registration
defect. DNS resolves to the cluster address.
**Still not submitted, and the task stays `progress`.** What remains is the
Ingress manifest and an issued certificate — work in `railiance-apps`, not
here. The manifest is written there
(`manifests/informed-decision-ingress.yaml`, dry-run clean) but deliberately
not applied. DNS alone is not an origin: a host that resolves but does not
complete a TLS handshake fails the same way a wrong hostname does, only later
and less legibly. Submitting before the host actually answers would be the
same failure `approval-engine` avoided by refusing to invent these strings —
owning a name is not the same as the name working.
Superseded context: the origin was previously the sole blocker in its
unowned form — choosing a plausible hostname is not the same as owning one.
Superseded context: 2026-09-09: blocked on `INFD-IN-0002`. `key-cape` found that a human access
token cannot carry `tenant:platform` today — the tenant claim resolves from a