plans: #436b approved at r5 1be535aca (dewey-0763); build carry N9 (restart after a revoke on an open rotation, 404 on delete by id is done) and N10 (serviceLeft a list); DESIGN.md unchanged; no code change

This commit is contained in:
jason.woltje committed 2026-10-20 18:36:07 -05:00
1 parent 1be535aca9
commit 3330c901b9
1 file changed
+10
+10
View File
@@ -0,0 +1,10 @@
# #436b build carry items
The design is approved at r5: 1be535aca, DESIGN.md sha256 68df02cdf890564c6ed0a5426204114389ba7eb0eea1cf04f1bf5938b6de45f4. Dewey gave the approval in dewey-0763 (verdict sha256 de52be1b…6b68). Section 7 is approved at fa5658941 by duckworth-0067 and is unchanged since. DESIGN.md stays as approved. The row's build takes the items below, and its BUILD.md cites this file.
- N9 (dewey-0763). Revoke writes `grant.revoked`, not a `grant.step`. A restart after a revoke on an open rotation therefore still sees a `commit` with no settle after it, and settles again: no file, `grant-lost`, a wrong message to Jason, and repeated deletes that come back 404 and go to `serviceLeft`. Two fixes:
- The section 5 restart row "`commit`, rotation, settle-pending" takes the held row's clause "with no `grant.revoked` after it".
- A 404 on a delete by id counts as done, not as a `serviceLeft` entry. That applies to revoke, sweep and the settle deletes.
- Add a test: revoke on an open rotation, then a restart. No settle runs, no Gitea call is made, and the restart sends no message about it.
- N10 (dewey-0763). `grant.revoked {serviceLeft}` can now hold two ids, so it is a list of ids everywhere. `sweep` reads it as one.
- duckworth-0067 N1 is in r4 (section 5, X-G15). Nothing more is carried for it.