reya/signed
1
0
Fork 0
Code Issues Pull Requests Actions 20 Releases Activity

signed_state: Simplify refresh coalescing and stop blocking the executor

Browse Source
This commit is contained in:
reya
2026-09-13 20:48:52 +07:00
parent 7aee19f3aa
commit 22b96c3546
5 changed files with 79 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/over-optimization-action-plan.md
+10 -5
View File
@@ -1,6 +1,6 @@
# Over-optimization and over-engineering action plan
- **Status:** phase 1 implemented; phases 2 and 3 still draft, for manual review
- **Status:** phases 1 and 2 implemented; phase 3 still draft, for manual review
- **Date:** 2026-09-13
- **Basis:** optimization inventory audit of branch `remove-ai-slop` (HEAD `534d572`)
- **Scope:** non-UI crates only — `signed_state`, `signed_git`, `signed_core`, `utils`,
@@ -123,6 +123,8 @@ Manual checks for phases 2 and 3 are in the validation section at the end.
scanning coalesces; inbox refresh after a sync does not double-run.
- **Size:** M. **Risk:** medium. The debounce timing of `CheckoutsStore` must not regress; the
timer is preserved exactly, only its flag moves.
- **Status:** done 2026-09-13 — `RefreshGate` is `running`/`dirty` only, `CheckoutsStore` owns
`debounce_pending`, and the one-line `inbox.rs` adaptation landed here.
### OV-04 — Replace the blocking sleep in the grasp push retry
@@ -140,6 +142,8 @@ Manual checks for phases 2 and 3 are in the validation section at the end.
- **Acceptance:** `cargo check -p signed_state`; a push that hits a transient denial still
retries with the same spacing.
- **Size:** S. **Risk:** low.
- **Status:** done 2026-09-13 — `push_staged_to_grasps` takes a `BackgroundExecutor` and awaits
`executor.timer(GRASP_RETRY_DELAY)`.
---
@@ -288,7 +292,8 @@ Renumbering, for traceability from the first review round:
## Open questions for the owner
1. OV-03: accept the two-flag `RefreshGate` plus a `CheckoutsStore`-owned debounce flag, or
keep the shared state machine as documentation-only?
2. OV-08: is an approximate (`20000+`) commit total acceptable for the badge contract?
3. OV-03: who owns the one mechanical `inbox.rs` edit — this plan or the UI effort?
1. OV-08: is an approximate (`20000+`) commit total acceptable for the badge contract?
OV-03's questions were settled during implementation: the gate keeps two flags (`running`,
`dirty`), `CheckoutsStore` owns `debounce_pending`, and the mechanical `inbox.rs` edit landed
in this phase.