coulomb/the-custodian
5
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

Record founder choice of T16 option A; align the 1.3 owner packet and add the key-cape request

Browse source 
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-10-17 11:40:09 +02:00
parent f06f6144a8
commit 33ba28a0ff
3 changed files with 73 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

31
docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/README.md
View file

@ -1,9 +1,17 @@
# Owner review: oidc-browser-relying-party@1.3 successor candidate (NK-WP-0048-T16)
Requested 2026-10-17 by the founder. **Start only after coordinator review r4**
(`../nk48-adapters-1.2-review/coordinator-review-r4.json`) approves net-kingdom
`1920b13` with no open findings. If r4 rejects anything, these requests are re-frozen
at the fixing revision.
Requested 2026-10-17 by the founder. **The founder chose option A** of the T16
owner-review packet `../nk48-t16-owner-review/README.md`: a 1.3 successor revision
with execution descriptors for all seven steps. These requests are A's concrete form.
They replace that packet's frozen input (1.2 at `ff8f597`) with the 1.3 candidate at
`1920b13`. Its per-owner duties, its "Carried into this review" list (items 1–6) and
its "Not in T16" section still apply. Every owner accepts each carried item that
touches its steps as a known limit, or turns it into a task.
Coordinator review r4 (`../nk48-adapters-1.2-review/coordinator-review-r4.json`)
approved `1920b13` with no findings. Its observation O6 matters for every owner: no
descriptor encodes the type version, so the 1.3 binding comes from the acknowledged
type's map together with the case pin.
Admission in Warden (`ops-warden a45cf47`, `case_run.Executor.admit`) requires, for
each step, the type's `execution_descriptors` to contain that exact descriptor
@ -24,6 +32,7 @@ authenticated path.
| railiance-platform | [railiance-platform.md](railiance-platform.md) | mint-secret and deliver-secret; mint semantics (question 2) |
| railiance-apps | [railiance-apps.md](railiance-apps.md) | deliver-consumer-secret and hand-over |
| ops-warden | [ops-warden.md](ops-warden.md) | the 1.3 parameter pin (question 1), catalog routing for all seven lanes, question 3 |
| key-cape | [key-cape.md](key-cape.md) | the pinned config-checker artifact and its native custody |
## Common frozen target
@ -34,6 +43,20 @@ authenticated path.
sha256 `64355c314891f7fc951a14e55c197609e892e73628acd43a535974382136961b`
- the open questions are in the 1.3 `README.md`, under "Known limits"
## Reproducing the tests
Extract into a directory **named `net-kingdom`**, because the package tests look up
`<parent>/net-kingdom/capabilities/` (r4 observation O1):
```bash
mkdir -p "$SCRATCH/net-kingdom" "$SCRATCH/ow"
git -C ~/net-kingdom archive 1920b13 | tar -x -C "$SCRATCH/net-kingdom"
git -C ~/ops-warden archive a45cf47 src | tar -x -C "$SCRATCH/ow"
```
Then follow the commands in `../nk48-adapters-1.2-review/README-r4.md`, using
`$SCRATCH/net-kingdom` for `$SCRATCH/nk`.
## How to run each review
One fresh Claude Code session per owner, started in that owner's repository (for

25
docs/changes/netkingdom-target-2026-10-17/nk48-1.3-owner-review/key-cape.md Normal file
View file

@ -0,0 +1,25 @@
# key-cape owner review (1.3 candidate)
Read [README.md](README.md) first. You own the issuer and the offline config checker
that the register-client descriptor pins.
## What the descriptors pin from you
The register-client descriptor and its source digest bind the config-checker
artifact `sha256:be37738fe1c08259fb4f9ca0daf0f9301bfffc237e5bb38435525dfbf11ccff5`
(`keycape check-config`). It was built reproducibly from key-cape `3c71226` in
net-kingdom T17/T18 (see `workplans/NK-WP-0048-security-case-types.md`, T17). T17 and
T18 left native executable storage and custody to T16.
## Questions
- Is `be37738f…` the checker build you stand behind for registration, or does a newer
key-cape revision need a rebuild? If it does, the descriptor changes and 1.3 is
re-frozen.
- Where does the pinned binary live natively, who holds custody of it, and how is its
digest proved at run time, before the attended registration executes it?
- The register-client step edits KeyCape's live client registry and requires a
restart (`restart_required`). Confirm the attended quiet-window restart and
readiness procedure in `docs/operations.md` applies, or name what is missing.
Write `owner-review-key-cape.json`.

21
docs/changes/netkingdom-target-2026-10-17/nk48-t16-owner-review/founder-option-decision.md Normal file
View file

@ -0,0 +1,21 @@
# Founder decision on the T16 option: A (2026-10-17)
The founder chose **option A** of this packet: a successor type revision (1.3) with
`execution_descriptors` for all seven steps. Recorded at the founder's instruction in
the key-cape authoring session.
The concrete candidate is net-kingdom `1920b13`,
`security-case-type-revisions/1.3/oidc-browser-relying-party/`. Coordinator review r4
approved it as a proposed source candidate
(`../nk48-adapters-1.2-review/coordinator-review-r4.json`, no findings). The per-owner
requests for A are in `../nk48-1.3-owner-review/`. That packet carries this packet's
per-owner duties, carried items 1–6 and "Not in T16" section, with the frozen input
moved from 1.2 at `ff8f597` to 1.3 at `1920b13`.
One correction to option B as written here: "not a major change" does not hold
mechanically. At ops-warden `a45cf47`, `Executor.admit` admits a step only when its
descriptor digest is in the acknowledged type's `execution_descriptors`, and 1.2 has
none. So even a mint-only pin would need a new type revision. Option B was not chosen.
This choice is not the 1.3 acknowledgment. That still follows through a Decision Memo
and informed-decision after the owner reviews.