Read through this — the three changes hang together well and the dispatcher-side handling is correct. One behavior-change tradeoff worth calling out explicitly for the maintainer, since it's the crux of the PR:

Removing "disk i/o error" from _WAL_INCOMPAT_MARKERS means a disk-I/O error during WAL setup is no longer auto-classified as 'WAL unsupported → silently fall back to DELETE'. It now flows to the raise on the unrelated-OperationalError path. The old inline comment framed disk-i/o as 'Flaky network FS during WAL setup' — so the previous behavior was: NFS/SMB users hitting a transient I/O blip during WAL init got a silent DELETE-mode downgrade and kept running. After this PR they get the error surfaced instead.

That's a defensible call (surface-over-mask — a transient I/O error genuinely isn't a WAL-capability signal, and masking it as 'WAL unsupported' hides a real FS problem), and you've backstopped it well: apply_wal_with_fallback now also propagates a failing DELETE fallback with an actionable log, and the gateway dispatcher's new _is_transient_board_disk_io_error path throttles the repeated tracebacks + resets on DB-change/success so a flaky board doesn't spam or crash the watcher. So the propagation has a catcher.

The only thing I'd want confirmed: for a user on a genuinely WAL-incapable mount that also surfaces as 'disk i/o error' (some FUSE/network setups conflate these), do they still end up in a working DELETE-mode session, or do they now hit the propagated raise on every init? If the latter, a brief note in the PR on the intended migration for those users would help. Logic itself looks sound.

Kanban t_c0d6fa7b reopened this after the 2026-05-26 recurrence.

Update:

• Existing PR reused and updated to current origin/main via branch fix-kanban-wal-fallback.
• disk I/O error remains outside WAL-incompat fallback markers so transient SQLite I/O failures are not silently downgraded to DELETE fallback.
• Dispatcher-side repeated transient disk-I/O tick failures are throttled per board DB fingerprint.

Verification:

• python -m pytest tests/test_hermes_state_wal_fallback.py::TestApplyWalWithFallback tests/hermes_cli/test_kanban_core_functionality.py::test_gateway_dispatcher_throttles_transient_disk_io_errors -o 'addopts=' -q -> 9 passed
• python -m pytest tests/test_hermes_state_wal_fallback.py tests/hermes_cli/test_kanban_core_functionality.py::test_gateway_dispatcher_disables_corrupt_board_without_traceback tests/hermes_cli/test_kanban_core_functionality.py::test_gateway_dispatcher_throttles_transient_disk_io_errors -o 'addopts=' -q -> 18 passed
• Added-line no-secrets diff scan -> clean
• gh pr checks -> no checks reported on this branch

Closing per project governance: this work must not be merged into NousResearch/hermes-agent or any upstream/third-party branch from our automation. Keep the branch only in nuch1011/hermes-agent for local/fork reference unless Christian explicitly requests an upstream contribution.