mirror of
https://github.com/block/buzz.git
synced 2026-11-01 06:51:17 +00:00
4c2c84527f
Addresses all five blocking findings from am's and peon's reviews: am#1 / peon-P1#1: Move baseline provenance to a dedicated persona_baselines table keyed by coordinate. The old in-row columns were wiped on delete, causing an offline delete to park forever. The new table survives delete_retained_event, so the next boot sees baseline=Present + queued deletion → Gate C arbitration. stamp_baseline is now written at both boot (StampBaseline) and publish-confirm (mark_synced_and_stamp_baseline in flush_pending_events_at), killing the one-edit-later revert vector: after publishing v2, the baseline records v2, so a later boot with head=v3 sees queued==baseline and stays silent. am#2 / peon-P2#1: Separate user-intent writes from reconcile writes at the retention API. retain_user_intent_event clears publish_blocked unconditionally; retain_event (reconcile path) never touches the gate. All user-facing save and tombstone paths now call retain_user_intent_event, so an edit to a parked coordinate takes effect in-session without waiting for the next boot. peon-P1#3: A decision pass driven by LookupFailed or ScanIncomplete must not certify the scope Ready. run_decision_pass now returns a has_uncertain_gates flag; enforce_decision_pass returns Abandoned when it is set, dropping the claim and leaving the latch Unready for the 30s flush retry. A wifi-race boot costs seconds, not a whole muted session. The false 'next pass' comment in decision.rs is corrected. peon-P2#2: set_persona_shared and update_persona_and_publish no longer submit directly to the relay. Both route through publish_prepared_persona_via_flush, which calls retain_user_intent_event (gate cleared for user intent) then flush_pending_events_at (per-row publish_blocked re-read). The duplicated publish/mark-synced logic in sharing.rs is deleted; retention.rs:508's invariant is now total. P3 (non-blocking): Deferred paragraph in PR body updated to reflect the sharpened stakes of parked rows. Regression tests (a)-(e): one test per finding, each traversing the production seam it protects. Co-authored-by: Will Pfleger <pfleger.will@gmail.com> Signed-off-by: Will Pfleger <pfleger.will@gmail.com>