SellPL
f05836f528
The parity contract from CLAUDE.md section 7 now exists: 42 cases across 11 scenario groups, with a runner that asserts every case and a coverage check that asserts every mandatory scenario is claimed. **A design change, and why.** ADR-16 originally specified JSON tables, justified by "serde_json will already be in the tree". That was wrong — `rusqlite` does not pull `serde` by default and `uniffi` has not landed, so nothing provided it, and `serde` is not a section 3 dependency (rule 0.3). The tables are therefore a Rust builder DSL: the same declarations, but a typo in a field name is a compile error rather than a test that silently asserts the wrong thing. For a document whose entire job is to be a contract, compile-time checking beats diffability. Converting to JSON later is mechanical if serde is approved. **Two engine bugs the tables caught, both real:** 1. **Overnight windows woke the daemon immediately.** `time_window_boundary` computed the end as `end - minute` and clamped at zero. For a 22:00–06:00 window active at 23:00, "06:00 today" is in the past, so the boundary became *now* — and the daemon would wake, re-evaluate, get the same answer, and wake again, forever. Not a missed block, but a busy loop burning the section 5 idle budget. Fixed by detecting the late half of an overnight window and crossing midnight properly. 2. **An inactive schedule woke a day early.** The next-start search iterated day offsets to test membership but computed the delta as `start - minute` only, wrapping by 1440 without advancing the day. A Monday–Friday schedule evaluated on Saturday reported Monday's start as 21 hours away — Sunday 09:00, a day not in the set. The block still fired, because the next evaluation recomputed it, but the daemon woke a day early for nothing. Fixed by folding the day offset into the delta. **Four of my own table cases were wrong too**, which is the other half of why they are worth having: a UTC+5 offset is 15:00 local and therefore *inside* 09:00–17:00 (I had asserted outside); the same for the DST cases. The engine was right and the test was wrong in all four. **Coverage bookkeeping is checked, not promised.** `coverage::Location` records whether a scenario is covered by a table or by a code fixture — clock tampering and the 24-hour cap are about the passage of time and a bound across lock levels, not a decision at an instant, so they cannot be expressed as data. Both directions fail: an uncovered scenario is an error, and so is a `covers` tag that is not on the mandatory list, which is how a case quietly stops testing what its name claims. **`BlockReason` now carries its target.** A schedule may name twenty targets and they do not all become blocked — some are paused, some belong to a condition that is not currently active, some are on the never-block list. Without carrying which target a reason is about, two blocked apps under one schedule produce two identical reasons and the UI has to re-derive the pairing, which is exactly the drift `BlockReason` exists to prevent. The tables could not assert per-app attribution without it. **The DST gap is recorded, not papered over.** `CivilTime` is an epoch plus an offset with no timezone database behind it, so the tables pin that a fixed local window stays fixed as the offset moves — including across a DST transition — but cannot express a spring-forward time that does not exist or a fall-back time that is ambiguous. Those are section 7 cases that are genuinely not covered, and LIMITATIONS.md now says so. Co-Authored-By: Claude Code <noreply@anthropic.com>
43 lines
1.8 KiB
Rust
43 lines
1.8 KiB
Rust
//! Cross-platform scenario tests (CLAUDE.md section 7).
|
|
//!
|
|
//! This crate holds the **golden decision tables**: declarative schedules,
|
|
//! inputs, and expected decisions that are run against the core engine.
|
|
//!
|
|
//! # Why this is a contract, not a test suite
|
|
//!
|
|
//! Unit tests check the engine against itself. These check that *every platform*
|
|
//! agrees with the engine. Android, Linux and Windows each map their own app
|
|
//! identity — package name, desktop-file id, exe path — onto a
|
|
//! [`blocker_core::model::Target`], and every case here runs through that mapping
|
|
//! too. If Linux resolves Discord to a different target than Android does, a case
|
|
//! fails at build time instead of becoming a bug report from whichever platform
|
|
//! nobody was testing that week.
|
|
//!
|
|
//! # The rule that keeps it honest
|
|
//!
|
|
//! **A case is added before the engine changes.** A table written after the code
|
|
//! records current behaviour and can never catch a regression — it would be a
|
|
//! transcript, not a specification. Reviewing a PR that changes engine behaviour
|
|
//! therefore means checking that a case was added or updated in the same commit.
|
|
//!
|
|
//! # Layout
|
|
//!
|
|
//! - [`golden`] — the case format, the harness, and the builder DSL
|
|
//! - [`tables`] — the cases themselves, grouped by scenario
|
|
//! - [`coverage`] — which CLAUDE.md scenario each case claims, and the check that
|
|
//! nothing went uncovered
|
|
//! - [`purity`] — a mechanical check that the core has not gained I/O, plus the
|
|
//! clock-tampering fixtures that cannot be expressed as data
|
|
//!
|
|
//! [`purity`] is `cfg(test)` because its checks are `#[test]` functions in this
|
|
//! library's unit-test build, not library API. They run under `cargo test`.
|
|
|
|
pub mod coverage;
|
|
pub mod golden;
|
|
pub mod tables;
|
|
|
|
#[cfg(test)]
|
|
mod purity;
|
|
#[cfg(test)]
|
|
mod run;
|