From 1614f257b6c37bdd05c920934be8952874293bcc Mon Sep 17 00:00:00 2001 From: tegwick Date: Thu, 10 Sep 2026 16:34:38 +0200 Subject: [PATCH] docs(T07): origin is live; registration ready to submit MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 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 --- docs/keycape-client-registration.md | 19 +++++++---- ...ounding-specs-and-approver-ui-ownership.md | 32 +++++++++++++------ 2 files changed, 36 insertions(+), 15 deletions(-) diff --git a/docs/keycape-client-registration.md b/docs/keycape-client-registration.md index 7f0902e..304059b 100644 --- a/docs/keycape-client-registration.md +++ b/docs/keycape-client-registration.md @@ -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` | diff --git a/workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md b/workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md index 88f1fb1..54ced71 100644 --- a/workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md +++ b/workplans/INFD-WP-0001-founding-specs-and-approver-ui-ownership.md @@ -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.