Refuse a fractional or absurd cadence number at write time, not at dispatch

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code

[os-warren]

Fixes#82

due_offset_days, lead_days and grace_days declared no numeric constraints, and the engine's number validator enforces min / max / scaleonly when they are declared. So due_offset_days: 1.5 saved clean, passed pnpm validate, rendered fine in the duty form — and then failed days later inside the nightly batch, recorded as invalid_cadence against the job rather than against the duty holding the bad value. Same failure shape as #24, one field over.

The two open choices, as decided on the card

1. scale: 0, not a sixth hand-written validation. AGENTS.md rule 9 — scale is the platform's own declarative answer to exactly this, and it does something a rule cannot: the form renders a whole-number input, so prevention comes before the error message.

The card left open whether the platform's refusal is readable enough to stand alone. Measured before deciding, on a real booted engine:

ValidationError: Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)
code: VALIDATION_FAILED
fields[0]: { field: 'due_offset_days', code: 'max_scale',
label: 'Offset (days, 0 = anchor day)',
constraint: { scale: 0, actual: 1 } }

It names the field by its own label, the limit, and what arrived. The bounds read the same way — Grace (days) must be ≤ 14, Lead time (days) must be ≥ 0. That is already product voice, so nothing is layered on top of it; a rule restating a declared bound is two sources of truth for one limit, and the hand-written one is always the one that drifts. test/cadence-number-constraints.test.ts pins the absence of such a rule, not just the presence of the keys.

2. Bounds, as proposed:-366..366 on due_offset_days; lead_days and grace_days keep min: 0 and gain a max.

"Same declaration" is not "same behaviour" — what each field actually did

Measured one duty at a time, against the real engine and the real CEL evaluator, on 17.2.0. The three do not share a failure mode:

field	fractional value	what actually happened
due_offset_days	1.5	Throws.dueDateFor refuses it, planForDuty catches it as invalid_cadence, the run reports degraded and the duty produces no tasks. dueOffsetDays must be a whole number of days, received 1.5
lead_days	2.5	Throws — but one function over, and the message is wrong about the value. The first consumer is visibleFromFor, reached through addCalendarDays, which negates its argument. So the operator reads leadDays must be a whole number of days, received -2.5 for a duty on which nobody ever typed a negative number.
grace_days	2.5	Throws nowhere. Ever. It never reaches the period engine at all — its only evaluating reader is the overdue escalation's CEL gate, which wraps it in int(). Measured: int(2.5) == 2, int(2.9) == 2. A duty declaring 2.5 days of grace escalates on precisely the day one declaring 2 does, silently, forever.

The absurd-value half is the same story: due_offset_days: 9e9 was accepted, and the card's guess that period.ts's MIN_YEAR/MAX_YEAR guard would eventually catch it is not what happens — measured, the civil arithmetic goes to NaN first and the refusal is dueDate must be a YYYY-MM-DD calendar date, received 0NaN-NaN-NaN, which names neither the field nor anything the author typed.

Why grace_days stops at 14 and not 366

Not symmetry, and not taste. The overdue escalation fires on due_date + grace_days + 1, and its sweep looks back OVERDUE_LOOKBACK_DAYS = 15 days. Any grace of 15 or more puts day one outside the swept window and the escalation never fires — the same silent inertness this card is about, one flow over. 14 is the largest grace the product can currently honour, so it is the only ceiling under which every accepted value works.

test/reminders.test.ts already carried the coupling and a deliberate tripwire (expect(graceMax, 'grace_days grew a max — re-read the coupling above').toBeUndefined()). It was written for this moment: the coupling has been read, and that half is inverted rather than deleted — it now asserts the max is declared and islookback - 1, so removing it puts the silent case back and turns the suite red.

This exposed a live instance in our own demo data.demo-catalog.ts shipped "Contractor induction refresh" with graceDays: 21, whose escalation had therefore never once fired. It is now 14. Measured, with the old value restored: the seed loader refuses it outright — [SeedLoader] Failed to write duly_catalog_item record #11 (name=Contractor induction refresh): Grace (days) must be ≤ 14, and again for the duty the history seed derives from it. The loud version of what used to be silence.

Whether the product wants a longer grace is a real question, and a lookback change is the price — filed as #89 for triage rather than decided here.

duly_catalog_item gets the same box, to the digit

applyCatalogHandler copies all three values onto every duty it creates, through engine.insert, which validates. A catalog item carrying 1.5 is therefore not a quiet inconsistency: it is an apply that refuses partway through, having already created duties for the first N people, with a refusal naming duly_duty rather than the catalog item the value actually lives on. Stopping it where the value is authored is the difference between one loud refusal on the row being edited and a half-finished fan-out.

Tests

test/cadence-number-constraints.test.ts (new, 26 cases) boots a real engine, because a structural assertion (Duty.fields.x.scale === 0) proves a key is present, not that anything enforces it:

• every field × both objects: 1.5 refused, asserted by envelope (code: 'VALIDATION_FAILED' plus fields[0].{field, code: 'max_scale', constraint}) — never by the bare fact that it threw, which would pass on any error at all;
• max + 1 and min - 1 refused as max_value / min_value with the declared constraint echoed;
• the update path refused too, not just insert — duly_catalog_item has no recurring_needs_frequency-equivalent validation #65's lesson was a rule that held on insert and did nothing on update;
• the corners that must still be accepted (-366, 366, lead 366, grace 14, zeroes), because a bound that refuses a legal value is as wrong as one that admits an illegal one;
• and the half that makes the bounds a contract rather than a guess: every corner of the declared box — 7 frequencies × 2 anchors × 2 zones × offset and lead extremes — planned through planDispatch with zeroinvalid_cadence. The declared box sits inside what the period engine can compute, so the defect is closed rather than moved.

Reverse-verified (both restored under a trap, files confirmed byte-identical afterwards):

• removed the three scale: 0 lines → 7 red, including all three write refusals and the update path (predicted direction: red);
• removed max: 14 → test/reminders.test.ts red with duly_duty.grace_days declares max undefined, which needs a lookback of at least NaN days; the sweep looks back 15.

Gates

All four green on d79440c, from a clean tree with dist/ removed first:

pnpm validate exit 0 ✓ Validation passed (542ms)
pnpm typecheck exit 0
pnpm test exit 0 Test Files 23 passed (23) · Tests 599 passed (599)
pnpm build exit 0 ✓ Build complete · Artifact: dist/objectstack.json (278.6 KB)

Exit codes captured directly, not through a pipe. The one validate warning is hierarchy-security — AGENTS.md §7 names it as this checkout's expected state.

No changeset: this repo has no changeset mechanism (no .changeset/, no @changesets/* dependency, no script, no mention in AGENTS.md). The four gates are the whole contract.

Related: #24 (same defect class, timezone), #89 (the grace ceiling as a product question), #52 (grace_days and the analytics surfaces). None of those three is addressed here.

---

Generated by Claude Code

[os-warren]

Reviewed — merging. This card was dispatched with one instruction, and that instruction is where all the value came out.

I told you not to assume lead_days and grace_days behave like due_offset_days just because they share a declaration. They do not, and the differences are not cosmetic:

field	2.5 / 1.5 does what
due_offset_days	throws in dueDateFor → invalid_cadence, run degraded
lead_days	throws one function over, in visibleFromFor via addCalendarDays, which negates — so the message names -2.5, a value nobody typed
grace_days	throws nowhere at all. Its only evaluating reader is the escalation's CEL gate, which wraps it in int(), and int(2.5) == 2 — so it silently escalates on the day a grace of 2 would, forever

The third row is the one that matters. That is not a late failure, it is not a failure at all: a configured value quietly becoming a different value, permanently, with no signal anywhere. It is the worst case in the family and it was invisible until someone measured each field separately instead of reasoning from the shared declaration.

The 14 ceiling is right, and I checked the derivation rather than taking it

reminders.flow.ts: the escalation fires on due_date + grace_days + 1, and its sweep uses withinDays: -OVERDUE_LOOKBACK_DAYS with OVERDUE_LOOKBACK_DAYS = 15. So a grace of 15 or more puts day one outside the window the sweep ever looks at, and the task is never escalated — silently. max: 14 is exactly the largest value this product can honour, not a taste call, and test/reminders.test.ts holding the two numbers together is what keeps it that way.

And it found a live instance in our own demo data.Contractor induction refresh shipped with graceDays: 21, so its escalation had never once fired. Ablation (3) — restoring 21 and watching the seed loader refuse with "Grace (days) must be at most 14" — is what turned a code comment into a measurement. A constraint that immediately catches a real defect in the data you already shipped is the best evidence a constraint can have.

Other things worth recording

• My sub-premise was wrong and you said so.due_offset_days: 9e9 is not caught by period.ts's MIN_YEAR/MAX_YEAR guard — the civil arithmetic reaches NaN first and the refusal reads received 0NaN-NaN-NaN. The bounds are more load-bearing than my card claimed.
• scale: 0 alone, no rule layered on top — after measuring that the platform's own refusal is already product voice ("Offset (days, 0 = anchor day) must have at most 0 decimal places (got 1)"). That is the order I asked for: measure, then decide, rather than assuming the platform message is poor.
• Mirroring duly_catalog_item to the digit because applyCatalogHandler copies all three onto every duty through engine.insert, which validates — so a fractional value on the catalog row is an apply that refuses partway through a fan-out, naming duly_duty rather than the row the value actually lives on. Good reasoning about where the error surfaces, not just whether it does.
• The corner sweep — 7 frequencies × 2 anchors × 2 zones × offset/lead extremes planned through planDispatch with zero invalid_cadence — is what makes the bounds a contract rather than a guess. Without it, -366..366 would be a number someone liked.
• Ablation attempt (3)'s first run matched zero lines, was caught by the grep count, and produced no reading rather than a false green. Re-anchored and re-run.

Gates, re-run by me on the head merged with current main (this branch predates #87 and #88): validate 0, typecheck 0, test 0 — Test Files 25 passed, Tests 632 passed — build 0. The demo seed still loads with the corrected graceDays.

#89 is the right question to have split out, and it is genuinely distinct from #52: this is about the value's ceiling, #52 is about grace_days being unreadable by the analytics surfaces at all.

---

Generated by Claude Code