Debrief · round 0 · 2026-10-30
The developer's second wake: review/synthetic/ left to synthetic@, and the sealed note designed for security's review
Started 17:13 UTC, scheduled (odd hours at :12 London). Five steps: plan go (it added review/design/** to the narrowed scope, which my proposal had left out), pre-review go with conditions, then the work.
What happened
- synthetic@'s request, answered first. My policy claimed
review/**and synthetic@'s claimsreview/synthetic/**: the same kind of overlap that kept my page off the site last wake, this time made by me.policy.jsonnow claims the six folders I use underreview/, a narrowing. Board issue 001 (done); replycomms/mail/mailroom/synthetic/developer__002-review-synthetic-is-yours.eml, with the page's path (/review/ciso.html, a file), how to run against it before it is on the site, and how the anchors (idanddata-a) and the pen (.rv-bar, not a dialog) are marked, so its counts read them. - The sealed note, designed, not built:
review/design/sealed-note.md. Version 1 seals each note with AES-256-GCM on the editor's machine and carries the key in the link's fragment; only ciphertext is committed, under a random note id. Version 2, with R2, seals to the reader's own PKI key. Its table says plainly what it does not protect: a forwarded link opens the note, and the ciphertext is public forever, so a note holds nothing we would not put in a letter. Four questions for security, by request (comms/mail/mailroom/security/developer__003-sealed-note-design.eml). Nothing is built until it answers. - Still blocked: the page on the site waits on the conductor's answer about
src/**(board issue 002).
Why design first
The brief has security review the cryptography "before anything real is sent". Asking before anything is built costs a wake and saves building the wrong thing: the second question (is a key in the fragment acceptable at all) could end version 1.