tegwick
50367d0d78
Everything except the host is now fixed: client_id informed-decision-approver, callback path /auth/callback, authorization-code + S256 PKCE public client, scopes [openid, approval:read, approval:approve], the expected token shape, and the assurance shape cited from key-cape's contract rather than restated so it cannot drift. Section 5 declares the tenant provenance rather than assuming it. Nothing populates domain.User.Tenant for approver users, so declaring tenant:platform reaches the token by the gap route by construction rather than by accident. GH-DEC-2026-013 was explicit that a tenant the directory does not carry must not be declared unless we are prepared to say so in the record — so it is said, with the two consequences: the claim is stored with its provenance, and it is never used as the act-scope. Deliberately NOT submitted. The origin needs a DNS A record, an Ingress manifest and a certificate, which is work in railiance-apps rather than here. decide.coulomb.social is proposed and consistent with the estate's existing Traefik/TLS-per-host pattern, but proposing a plausible hostname is not the same as owning one, and submitting a redirect for a host that does not resolve is the exact failure approval-engine avoided by refusing to invent these strings. T07 stays progress with the deployment dependency named and owned elsewhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01V3W1dQG7GFFM9d94jFx7iR Assistant: claude-code Assistant-Model: opus Assistant-Process: 1565372@bnt-lap001 Assistant-Session: 16bb2f25-b34c-49ef-8e94-5fec3567a568 |
||
|---|---|---|
| docs | ||
| history/20260909-initial-exploration | ||
| informed_decision | ||
| intakes | ||
| schemas | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| GOAL.md | ||
| INTENT.md | ||
| layer.yaml | ||
| Makefile | ||
| pep-stance.yaml | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
informed-decision
User interface for executive decisions, modelled as a sign-and-return book — the German Umlaufmappe / Zeichnungsbuch, made cryptographic.
A Decision Memo carries a question, the context needed to answer it, the requested act, and a binding between identity, what was shown, and what was bound. The promise is not "the file was signed" but "this person, in this role, was shown this view, and bound this act."
One object model from a ten-second login (L0) to a multi-party instrument (L5).
Where to start
| File | What it is |
|---|---|
INTENT.md |
Why this repository exists and what it must never become |
GOAL.md |
The current stage, its invariants, and its definition of done |
workplans/ |
Current work |
history/20260909-initial-exploration/ |
Founding exploration — schema, state transitions, canonicalization, vectors |
Stage 1
Own the browser-facing approver UI that approval-engine deliberately does
not contain, and answer in writing who owns it. approval-engine is a
bearer-token resource server with no browser client; key-cape
(KEY-WP-0013-T02) is waiting on a client_id and callback URI that no
component has claimed. This repository claims them.
See GOAL.md.
Boundaries
This repository renders questions and records answers. It does not decide
(access-engine), does not own the approval object (approval-engine), does
not author approval doctrine (gate-house), does not authenticate anyone
(key-cape), and does not archive the trail (audit-core).