Merge pull request #16 from ScriptKittyOS/plan/answers-2026-09-20

Signed-off-by: Ayla Croft <aylacroft@proton.me>

Author: HackTuah

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.

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 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
+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.

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,