Solid feature; unit tests cover both fast and strict modes thoroughly, including the partial-checkpoint and lagging-checkpoint regressions. A few items inline; the missing integration test and the empty manual test plan are the only soft blockers — flagging, not refusing.

Thanks for the rework — all three inline findings and the missing integration test are addressed:

• Doc semantics now uniform (>= n for both fields in coordination.rs; runtime predicate uses > step_at_flush, which is the same thing once the off-by-one is taken into account). Good.
• WatcherMode { Fast, Strict } is clean; intent reads at every call site.
• The ~30 s cadence claim is gone; strict_checkpoint_sync doc just references the serde default.
• test_cdc_strict_checkpoint_sync_requires_storage covers the fail-fast path without Postgres; test_cdc_strict_checkpoint_sync_holds_slot exercises the end-to-end slot-hold + redelivery behavior across two pipeline runs. Nice two-run shape — that's exactly the assumption that needed coverage.

One hard block remains:

Dirty history. Four commits is too many for what is conceptually one change, and three of them are review-fixup commits:

• ce8e3253 fmt — still present, lazy one-liner.
• c8afa19f docs: fix >= n vs > n inconsistency …
• eb3c91ba refactor: replace strict: bool with WatcherMode enum …
• 6ef0f815 test: add integration tests for strict_checkpoint_sync

Per the project's commit-hygiene rules (linear history on main; every commit must be worthy of that history; review-fixup commits get squashed before merge), please git rebase -i and collapse this into a single coherent commit — feature + tests + docs together, with a real message explaining why strict_checkpoint_sync exists (the at-least-once guarantee for stateful pipelines, the storage prerequisite, and the watcher mode split). Drop the fmt commit and fold the Claude Co-Authored-By trailers into one consolidated trailer on the final commit if you want to keep attribution.

Soft nit (not blocking): the Manual Test Plan section in the PR description is still the empty placeholder. The new integration tests cover the behavior, so this is a soft block per the rules — but it costs nothing to write two sentences ("ran cargo test test_cdc_strict_checkpoint_sync_requires_storage; ran the #[ignore]d slot-hold test against a local Postgres with wal_level=logical") and it helps future readers.

Once the history is cleaned up I'm happy to approve.

All three findings addressed: Completion doc uses >= n consistently, Mode enum replaces the bool flag, and the cadence prose no longer overstates 30s. Plus a new integration test exercises the strict-mode handshake and the storage-required path. LGTM.

Re-reviewed the pivot on 5c14a28. The redesign addresses both of blp's concerns cleanly:

• strict_checkpoint_sync config option dropped from PostgresCdcReaderConfig. Strict mode is now implied by fault tolerance being enabled — the right default, and one fewer footgun.
• total_checkpointed_steps removed from Completion (the pipeline ↔ multihost coordinator wire struct). The checkpoint-step frontier now travels over a separate checkpoint_notifier: watch::Sender<u64> inside ControllerStatus, which keeps the coordination boundary clean.
• checkpoints_supported() → checkpoint_watcher() -> Option<watch::Receiver<u64>>. Returns Some only when fault tolerance is enabled. The Postgres connector picks WatcherReceiver::Strict when present, WatcherReceiver::Fast (step completion) otherwise. Falling back automatically eliminates the old startup-failure path and the test that pinned it.
• Watcher abstraction (enum WatcherReceiver { Fast(Completion), Strict(u64) }) gives the background task a single .changed() / .frontier() surface — clean, and the unit tests around fast-mode, strict-mode, partial checkpoint, immediate-fire and multi-batch all map onto the new shape correctly.

One design question for blp to weigh in on: your original suggestion was to have the connector consult the existing InputConsumer::pipeline_fault_tolerance() and key its own behaviour off FtModel::AtLeastOnce, rather than adding a new checkpoint_watcher() trait method. The author's approach hides the FT-enablement check inside the new method (so the connector doesn't need to learn the FtModel taxonomy), at the cost of one extra trait method. Both are defensible — happy either way, but worth your call.

Not blocking on it; prior approval stands on the substance. Two soft notes:

1. The Documentation updated checkbox is unchecked and no docs files moved. The user-facing surface didn't really change (option removed, behaviour now implicit on FT) so I don't think this needs new prose, but please add a changelog line noting that strict-mode (slot only advances after durable checkpoint) becomes implicit when fault tolerance is enabled.
2. As you already told gz, please squash 5f6d6286 fmt and any other fixups into a single linear-history commit before merge.