From dd7bf9f40ea6a03fb8a4b9236d7bd9441c91e64c Mon Sep 17 00:00:00 2001 From: Ayla Croft Date: Sun, 20 Sep 2026 07:43:56 -0400 Subject: [PATCH 1/2] plan: slice 026's blocker lifted; slice 024 records that FIPS mode cannot verify Ed25519 history The external authority plane's coding agent answered on 2026-09-20: a queued-then-acknowledged receipt path does not change their side as long as the signed envelope passes through unmodified, and a reconciliation row on their side is available on request. 026's NOTES.md records the answer as its lift condition; the SLICE.md says it now waits only on 024. The same answer confirms that OTP's notsup in FIPS mode covers verification of EdDSA, so a FIPS build cannot verify an Ed25519 chain written earlier. 024's risks now say the standalone verifier runs on a stock OTP as well and reports that case as a named outcome, never as invalid. plan_check: PASS. Signed-off-by: Ayla Croft --- .../SLICE.md | 5 ++++ .../026-store-and-forward-receipts/NOTES.md | 23 +++++++++++++++++++ .../026-store-and-forward-receipts/SLICE.md | 4 ++++ 3 files changed, 32 insertions(+) create mode 100644 slices/026-store-and-forward-receipts/NOTES.md diff --git a/slices/024-effect-catalog-authority-modes-receipts/SLICE.md b/slices/024-effect-catalog-authority-modes-receipts/SLICE.md index ef5e531..4353d00 100644 --- a/slices/024-effect-catalog-authority-modes-receipts/SLICE.md +++ b/slices/024-effect-catalog-authority-modes-receipts/SLICE.md @@ -142,5 +142,10 @@ receipt metadata, and the signed bytes carry `seq`, `chain_scope`, `prev_hash`, - AC8's FIPS half cannot run on the developer machine (`crypto:info_fips()` returns `not_supported` there); it runs on slice 003's leg. If 003 has not landed when this slice reaches G3, the FIPS half is recorded as not measured, by name, and the slice does not close. +- OTP's `notsup` in FIPS mode covers verification of EdDSA as well as signing (answer from the external + plane's maintainers, 2026-09-20, matching OTP's own `pkey.c`). A FIPS build therefore cannot verify an Ed25519 + chain written before the deployment entered FIPS mode. The standalone verifier (AC7) must run on a stock + OTP as well as a FIPS one, and the FIPS-leg test for AC7 asserts that an Ed25519 chain is reported as + `verification unavailable on this build` (a named outcome), never as invalid. - P-384 signs slower than Ed25519 through OpenSSL and has no dedicated assembly path; the checkpoint window (amendment 5) absorbs it for query receipts, and the per-receipt cost for the other kinds is measured at G1. diff --git a/slices/026-store-and-forward-receipts/NOTES.md b/slices/026-store-and-forward-receipts/NOTES.md new file mode 100644 index 0000000..e45aec6 --- /dev/null +++ b/slices/026-store-and-forward-receipts/NOTES.md @@ -0,0 +1,23 @@ +# Slice 026: NOTES + +## Blocker lifted, 2026-09-20 + +The slice was blocked on one question to the external authority plane's maintainers: does a +queued-then-acknowledged `receipt/2` fit their adapter? Answered on the Sanction board on 2026-09-20 by that +project's coding agent, against their tree at `8bc693ee`. + +**Answer, as given:** store-and-forward does not change their side as long as the acknowledgement carries the +envelope the plane signed, unmodified. Their verifiers check the plane's signature over the envelope bytes +offline, so a queue can wrap, delay or re-deliver an envelope and cannot re-sign it or alter a leaf. If this slice +wants the plane to know an acknowledgement happened, that is a new inbound fact and a new receipt on their side, +in the shape of a reconciliation row they already have (`pending`, `matched`, `delayed`, `mismatch`), offered as +small work on request. + +**What this fixes for the design.** Amendment to the Goal: the queue carries envelopes byte for byte and never +re-signs; the merge compares chains and never rewrites a leaf, which the spec already said. The reconciliation +row is wanted, so that a disconnected site's receipts are matched on the plane's side and a `mismatch` is a +finding on both sides; it is requested at this slice's G1, not before, and its absence does not block the local +authority path (AC1 to AC4 run under `Local`). + +**Lift condition met:** the answer is recorded here. The slice stays `planned` until its dependency (024) is +approved; it is no longer blocked on an external answer. The ADR-0008 append is still owed when the slice opens. diff --git a/slices/026-store-and-forward-receipts/SLICE.md b/slices/026-store-and-forward-receipts/SLICE.md index c631fd2..bd8ad11 100644 --- a/slices/026-store-and-forward-receipts/SLICE.md +++ b/slices/026-store-and-forward-receipts/SLICE.md @@ -12,6 +12,10 @@ Added 2026-09-20. Blocked until the external authority plane's maintainers answe `receipt/2` fits their adapter; that question is routed through the owner and this slice does not open before the answer is recorded in NOTES.md. Opening it changes ADR-0008's contract and needs an appended decision there. +**Answered the same day; see NOTES.md.** The queue carries the plane's envelope unmodified and never re-signs it; +a reconciliation row on the plane's side is wanted and is requested at G1. The slice is no longer blocked on an +external answer; it waits on 024 as its dependency says. + ## Goal `receipt/2` gains a queued-then-acknowledged mode so that the local authority and an external adapter behave identically when the machine is offline: receipts are appended locally with a hybrid logical clock on every row, From 034bbea6b97873cf8fea05d7779da5b25e06370c Mon Sep 17 00:00:00 2001 From: Ayla Croft Date: Sun, 20 Sep 2026 07:45:02 -0400 Subject: [PATCH 2/2] plan: the 026 note names no platform; the name check refused the first wording The gate's name check (run 35508645049) found a platform name in slices/026-store-and-forward-receipts/NOTES.md line 6, outside the one README section where it is permitted. Reworded. trinity.names: OK. plan_check: PASS. Signed-off-by: Ayla Croft --- slices/026-store-and-forward-receipts/NOTES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/slices/026-store-and-forward-receipts/NOTES.md b/slices/026-store-and-forward-receipts/NOTES.md index e45aec6..7db408d 100644 --- a/slices/026-store-and-forward-receipts/NOTES.md +++ b/slices/026-store-and-forward-receipts/NOTES.md @@ -3,7 +3,7 @@ ## Blocker lifted, 2026-09-20 The slice was blocked on one question to the external authority plane's maintainers: does a -queued-then-acknowledged `receipt/2` fit their adapter? Answered on the Sanction board on 2026-09-20 by that +queued-then-acknowledged `receipt/2` fit their adapter? Answered on the shared cross-project board on 2026-09-20 by that project's coding agent, against their tree at `8bc693ee`. **Answer, as given:** store-and-forward does not change their side as long as the acknowledgement carries the