Filed unassigned, from the work on #82. Not a defect — a product question that #82 made visible rather than created.
What #82 changed
duly_duty.grace_days and duly_catalog_item.grace_days now declare max: 14. That number is not a taste call: the overdue escalation fires on due_date + grace_days + 1, and its sweep (OVERDUE_LOOKBACK_DAYS in src/flows/reminders.flow.ts) looks back 15 days. A grace of 15 or more puts day one outside the swept window, so the escalation never fires — silently, with nothing anywhere reporting it. 14 is therefore the largest grace the product can currently honour, and the ceiling makes every accepted value one that actually works.
What that was hiding
src/data/demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21. Measured: its escalation had never once fired, for exactly this reason. #82 changed it to 14, and the seed loader now refuses the old value outright (measured — [SeedLoader] Failed to write duly_catalog_item record #11 … Grace (days) must be ≤ 14), which is the loud version of what used to be silence.
That one demo row is the evidence that 14 may be narrower than someone intended: whoever authored a 21-day grace on an annual contractor duty presumably meant it.
The question
Does the product want a grace longer than 14 days?
- No — 14 stands, and this issue closes as answered. Annual duties with a long grace are the only plausible case, and "we escalate at two weeks past due whatever the duty says" is a defensible product line.
- Yes — then
OVERDUE_LOOKBACK_DAYS moves with it, and that is the trade the flow's own doc names: in range mode the claim scope is the sweep day, so a longer lookback re-launches the escalation flow once a day for every task in a longer window, most of them ending at end without notifying. A 30-day grace doubles that ledger traffic. The bound is cheap; the lookback is not.
Whichever way it goes, the two numbers must move together — test/reminders.test.ts ("the lookback still covers the largest grace a duty can declare") reads both and fails if either moves alone.
Not the same as #52
#52 is about grace_days being unreadable by the analytics surfaces (completed_at <= due_date + duty.grace_days, objectstack#14104). This one is about the ceiling on the value itself, decided by the escalation sweep. Worth noting for #52's benefit, measured while here: the escalation's CEL gate is today the one and only evaluating reader of grace_days in the app.
Related: #82, #52. Neither is closed by this.
Generated by Claude Code
Filed unassigned, from the work on #82. Not a defect — a product question that #82 made visible rather than created.
What #82 changed
duly_duty.grace_daysandduly_catalog_item.grace_daysnow declaremax: 14. That number is not a taste call: the overdue escalation fires ondue_date + grace_days + 1, and its sweep (OVERDUE_LOOKBACK_DAYSinsrc/flows/reminders.flow.ts) looks back 15 days. A grace of 15 or more puts day one outside the swept window, so the escalation never fires — silently, with nothing anywhere reporting it. 14 is therefore the largest grace the product can currently honour, and the ceiling makes every accepted value one that actually works.What that was hiding
src/data/demo-catalog.tsshipped "Contractor induction refresh" withgraceDays: 21. Measured: its escalation had never once fired, for exactly this reason. #82 changed it to 14, and the seed loader now refuses the old value outright (measured —[SeedLoader] Failed to write duly_catalog_item record #11 … Grace (days) must be ≤ 14), which is the loud version of what used to be silence.That one demo row is the evidence that 14 may be narrower than someone intended: whoever authored a 21-day grace on an annual contractor duty presumably meant it.
The question
Does the product want a grace longer than 14 days?
OVERDUE_LOOKBACK_DAYSmoves with it, and that is the trade the flow's own doc names: in range mode the claim scope is the sweep day, so a longer lookback re-launches the escalation flow once a day for every task in a longer window, most of them ending atendwithout notifying. A 30-day grace doubles that ledger traffic. The bound is cheap; the lookback is not.Whichever way it goes, the two numbers must move together —
test/reminders.test.ts("the lookback still covers the largest grace a duty can declare") reads both and fails if either moves alone.Not the same as #52
#52 is about
grace_daysbeing unreadable by the analytics surfaces (completed_at <= due_date + duty.grace_days, objectstack#14104). This one is about the ceiling on the value itself, decided by the escalation sweep. Worth noting for #52's benefit, measured while here: the escalation's CEL gate is today the one and only evaluating reader ofgrace_daysin the app.Related: #82, #52. Neither is closed by this.
Generated by Claude Code