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

docs(T07): origin is live; registration ready to submit

Browse source 
decisions.coulomb.social answers 200 over an issued Let's Encrypt certificate as
of 2026-09-10 14:32 UTC. The condition this document set for its own submission
— a real origin rather than a plausible one — is met.

T07 stays progress: the remaining acceptance criteria are that the contract
actually reaches key-cape and that a token issued against the registration is
accepted by approval-engine's verifier, which cannot be shown until
approval-engine is deployed.

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:34:38 +02:00
parent 4d33a59f5b
commit 1614f257b6
2 changed files with 36 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

19
docs/keycape-client-registration.md
View file

@ -51,11 +51,18 @@ than reconciled afterwards.
and an issued certificate. Manifest written 2026-09-10
(`manifests/informed-decision-ingress.yaml`); not yet applied.
**This document is submitted to `key-cape` once the host answers over TLS — not
before.** DNS alone is not the origin; an origin that does not complete a TLS
handshake fails the same way a wrong hostname does, only later. The path
component `/auth/callback` was fixed ahead of the host, so nothing else in this
registration moves.
**The host answers. This document is ready to submit.** 2026-09-10 14:32 UTC:
`railiance-apps` applied the Ingress and cert-manager issued a Let's Encrypt
certificate for `decisions.coulomb.social`;
`GET https://decisions.coulomb.social/auth/callback` returns `200` over a
verified chain. The condition this document set for its own submission —
that the origin be real rather than plausible — is met. The path component
`/auth/callback` was fixed ahead of the host, so nothing else in this
registration moved.
The path is currently served by a placeholder while
`INFD-WP-0001-T08` is built. That does not affect the registration: `key-cape`
matches the redirect URI as a string at `/authorize` and never fetches it.
---
@ -172,6 +179,6 @@ while it stands.
| # | Item | Owner |
| --- | --- | --- |
| 1 | ~~DNS A record~~ (done 2026-09-10) + Ingress + TLS for `decisions.coulomb.social` | `railiance-apps` / deployment |
| 1 | ~~DNS A record + Ingress + TLS for `decisions.coulomb.social`~~ — **done 2026-09-10**, cert issued, host answers 200 | `railiance-apps` / deployment |
| 2 | Submit this document to `key-cape`, closing `KEY-WP-0013-T02` | this repo, once 1 lands |
| 3 | Prove a token issued against the registration is accepted by `approval-engine` | `T08` |

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

@ -388,15 +388,29 @@ 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.
2026-09-10 14:32 UTC — **the origin is live.** `railiance-apps` applied
`manifests/informed-decision-origin.yaml` and
`manifests/informed-decision-ingress.yaml`; cert-manager issued a Let's Encrypt
certificate (`CN=decisions.coulomb.social`, valid to 2026-12-09) and
`GET https://decisions.coulomb.social/auth/callback` returns `200` over a
verified chain. The path is served by a placeholder until T08 ships, which does
not affect the registration — `key-cape` matches the redirect URI as a string at
`/authorize` and never fetches it. Evidence:
`railiance-apps/docs/informed-decision-origin.md`.
Every input this task owns is now fixed and real.
`docs/keycape-client-registration.md` is ready to submit. **The task stays
`progress` until the remaining acceptance criteria are met, which are not
document criteria:** the contract must actually reach `key-cape` citing
`KEY-WP-0013-T02` and `approval-engine`'s
`docs/keycape-service-registrations.md`, and a token issued against the
registration must be accepted by `approval-engine`'s verifier. That last one
cannot be demonstrated until `approval-engine` is deployed, so T07 will close
alongside, not before, the deployment T08 also waits on.
Superseded context: the origin was the sole blocker — DNS alone is not an
origin, and a host that resolves but does not complete a TLS handshake fails
the same way a wrong hostname does, only later and less legibly.
Superseded context: the origin was previously the sole blocker in its
unowned form — choosing a plausible hostname is not the same as owning one.