Quick checkpoint: per-room opt-out for auto-apply, and say so when a save was automatic#2
Conversation
…uto-applied saves say so The default Checkpoint button approves a blocker-free proposal without showing its content. This adds a room maintenance setting, quickCheckpointAutoApply (default true, preserving current behaviour; legacy settings files read as true), that routes the quick button to the normal manual preview instead — reusing the existing fast-path-blocked note so the user sees why. When auto-apply does run, the saved system message now says the checkpoint was applied automatically. If the preference cannot be read, the flow falls back to manual review — the safe direction is showing the proposal, not silently applying it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…rovenance receipt and can open its stored source conversation, Learn and Review history rows diff what changed, and the learning curve is clickable time travel that renders the whole memory view as of that moment; the checkpoint approval gate rejects drafts that could forge those receipts; room settings become a left-rail modal with a shared control language, one-step room delete, and a Windows folder picker that survives PowerShell argument quoting; quick checkpoints can be set per room to stop at the review gate instead of applying automatically (Settings, Memory pane), contributed by @blue-az in #2 and credited in the new changelog Unreleased section; CONTRIBUTING now explains the cherry-pick flow external PRs travel; docs drop their em-dashes Co-authored-by: Fernando Pastor Alonso <ferpastoralonso@gmail.com> Co-authored-by: blue-az <efehn2000@gmail.com>
|
Thanks for this — it's exactly the kind of contribution we hoped for, and it's landed: 61152d4, with you credited as co-author. A note on why this shows "closed" rather than "merged": exxperts development happens on an internal GitLab that is the source of truth, and this GitHub repo is a synced mirror — so external PRs get cherry-picked into GitLab (authorship preserved) and arrive here with the next sync rather than through the merge button. Your change is in main now, the changelog credits you, and CONTRIBUTING now documents this flow so it surprises nobody after you. One adaptation during the rebase: main had since gained elision-notice disclosure on the saved-checkpoint message, so your "saved automatically" wording now rides that newer structure — both disclosures coexist. Everything else applied as you wrote it, including the settings smoke extensions, and we kept your UI copy after testing it live. The fail-toward-review fallback and the disclosure wording were nice touches beyond the toggle itself. PRs welcome anytime. |
2 participants
Summary
The default Checkpoint button (as opposed to "Checkpoint with options…") drafts a compression proposal and, when nothing deterministic blocks it (no elision, no parse failure, no missing field), approves and saves it immediately without showing the content. That's a deliberate, useful convenience — but for a product whose core promise is "every memory write approved by you," some rooms may want the one-click button to still stop for a human look, and there was no way to keep the quick button while adding that review step back in.
This PR adds a room-level opt-out, following the exact pattern already established by
fastPathSecondApprovalfor the absorb/review flows:quickCheckpointAutoApplyin room maintenance settings (defaulttrue— existing behavior is unchanged unless a room explicitly opts out; settings files written before this field existed are read astrue, so no migration is needed).Nothing about the propose/approve server split, the checkpoint approval transaction, staleness checks, or archiving changes — this only adds a UI/preference gate in front of the existing quick-apply behavior.
Why
While auditing the checkpoint approval path, I found that
quickCheckpointBlockers(the gate in front of auto-apply) only checks for deterministic problems — transcript elision, parse failures, missing fields — not content fidelity against the transcript. That's a reasonable scope for an automatic gate (content fidelity isn't mechanically checkable), but it means the quick button can save a fluent, well-formed, entirely fabricated summary without any human ever seeing it, and content marked must-keep is protected from later pruning by Learn/Review Memory. This isn't a bug in the gate — the gate does exactly what it's documented to do — but rooms that want a human in the loop for every write had no way to get that from the one-click flow. This PR gives them one, opt-in, without touching the default.Test plan
npm run build— cleannpx tsc --noEmit -p apps/web-ui/tsconfig.json— cleannpm run smokes— 56/56 passing (full suite, CI parity)persistent-room-maintenance-settings-smoke.tsextended: default-on, round-trip, merge-preservation across other settings writes, legacy-settings-file migration (field absent → reads astrue), and boolean validation for the new field./scripts/exxperts-webagainst a live Claude Pro/Max profile:🤖 Generated with Claude Code