Patched the daily KB pulse and the daily KB follow-up drift scan together.
What shipped:
Skills/sail-kb-daily-pulse/build_report.py so the pulse now prints Backlog count as of: <run_utc> whenever live_backlog_count metadata is present.Skills/sail-kb-daily-pulse/SKILL.md to document that visible timestamp behavior as v3.2.1.~/.codex/automations/daily-sail-kb-follow-up-and-drift-scan/automation.toml so the follow-up run treats later same-day count changes as normal movement unless it can prove the earlier pulse was wrong, and so newer verified pages automatically downgrade stale blockers instead of surfacing them as current.Skills/tests/test_kb_followup_live_backlog.py for the visible backlog timestamp line.python3 -m unittest /Users/samaguiar/Documents/Projects/Skills/tests/test_kb_followup_live_backlog.py, 4 tests passed.The requested hardening pass is implemented and locally verified. No live destructive changes were made.
Let the next scheduled pulse and follow-up runs execute normally, then confirm the follow-up report stops flagging ordinary same-day backlog movement as a drift defect. If the stack still reports a mismatch, inspect whether the difference comes from real new entries after the pulse or from a stale historical page being compared without timestamp context.
The important files are Skills/sail-kb-daily-pulse/build_report.py, Skills/sail-kb-daily-pulse/SKILL.md, Skills/tests/test_kb_followup_live_backlog.py, and ~/.codex/automations/daily-sail-kb-follow-up-and-drift-scan/automation.toml. The user chose option A specifically to reduce false urgency from count mismatches and stale blockers. The expected next proof is tomorrow's scheduled output, not another speculative code pass.