Reject a duly_duty timezone the host cannot resolve, at write time

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code

[os-warren]

Fixes#24

duly_duty.timezone was a bare Field.text, so Europe/Munich, CET+1, Asia/Shanghai (trailing space) and '' all saved clean, passed pnpm validate, and threw days later inside the nightly dispatcher — attributed to the job rather than to the record that carried the typo.

Where the check went, and why not the other two moments

The card names a failure at dispatch, which is neither of the moments a check can live at. Of the three available:

• Author time (pnpm validate) only ever sees metadata. Duties are records, typed into a form at run time, and the linter never sees one — an author-time check would be a check on a population that does not contain the defect. It is not needed as a second line either: a typo'd field default is caught by this guard on the first duty anyone creates.
• Write time is where a person types Europe/Munich and presses save. It covers the form, REST/OpenAPI/MCP, the catalog-apply action, and the seed path (skipTriggers suppresses record-change automation, not hooks). This is where the guard is.
• Dispatch time is where it fails today, and the engine's refusal there stays exactly as it is — a duty quietly resolving "the 5th of the month" in the wrong zone is a wrong due date nobody can see is wrong.

One membership oracle, shared with the engine

isResolvableTimeZone is added to src/functions/period.ts and delegates to that module's own formatterFor. This is the load-bearing design choice: a guard admitting a different set than the engine would be wrong in one of two directions — refuse a duty that dispatches fine, or pass one that still throws on dispatch night, which is the defect reintroduced behind a check that looks like it works. Sharing the constructor also shares its options (hourCycle: 'h23', era: 'short').

It is the Intl.DateTimeFormat probe and deliberately not Intl.supportedValuesOf('timeZone'). Measured on this container, Node v22.22.2:

Intl.supportedValuesOf('timeZone').length -> 418
includes 'UTC' -> false (duly_duty.timezone's own defaultValue)
includes 'GMT' -> false
includes 'Asia/Kolkata' -> false
includes 'US/Eastern' -> false
new Intl.DateTimeFormat('en-US', { timeZone: v }) -> resolves for all of them

A guard built on the enumerated list would refuse every duty created with the field default. This is also the definition @objectstack/spec publishes for its own iana_time_zone value domain: "membership is the Intl.DateTimeFormat probe … NOT Intl.supportedValuesOf".

The guard validates; it does not canonicalise. america/new_york is stored verbatim — rewriting a stored value would be changing data, not checking it.

Metadata-first (AGENTS.md rule 9): the platform cannot express this, filed upstream

Checked before writing any code. A script validation was the obvious home and cannot do it:

• CEL has no zone oracle. The whole stdlib registered in @objectstack/formula is now today daysFromNow daysAgo isBlank coalesce trim joinNonEmpty daysBetween addDays addMonths date datetime abs round floor ceil min max upper lower contains startsWith endsWith matches len isEmpty, and an app cannot register one. The only reachable spelling is a matches(record.timezone, …) regex, which either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that disagrees with the host's.
• valueDomain: 'iana_time_zone' exists in @objectstack/spec — but only on a settings Specifier. An object field has no equivalent, and FieldType has no timezone member.

Filed upstream as objectstack-ai/objectstack#14168, and a lifecycle hook is what validation.zod.ts itself prescribes meanwhile ("Custom handler → a beforeInsert / beforeUpdate lifecycle hook, the typed, supported extension point for arbitrary validation code").

⛔ Why the handler is a STRING, and the trap it avoids

The most important line in the diff, and the one most likely to be "cleaned up" later.

objectstack build lowers a self-contained inline handler into a metadata body, which runs in the QuickJS sandbox — and that sandbox has no Intl. Measured directly against the runtime's own sandbox (quickjs-emscripten 0.32.0, the variant AppPlugin wires through QuickJSScriptRunner):

typeof Intl -> undefined
typeof Date -> function
typeof JSON -> object

No HookBodyCapability grants it either (api.read | api.write | api.transaction | crypto.uuid | log). Since resolveHandler prefers body over handler whenever both exist, writing this guard as an inline handler would ship a hook that throws ReferenceError: Intl is not defined on every duty write and — with the onError: 'abort' a validation-shaped hook must declare — refuse every write to duly_duty, while all four gates stayed green, because tests run the raw function in Node.

The string ref keeps the probe in Node: nothing inline for the extractor to lower, so no body is emitted, and resolveHandler falls through to opts.functions[name] — the same path the dispatch job handler already takes. Confirmed in the built artifact:

duly_duty_timezone_guard | handler: "dulyValidateDutyTimezone" | hasBody: false
duly_task_lifecycle_stamps | handler: "duly_task_lifecycle_stamps" | hasBody: true

The contrast with the neighbouring task hook is the proof that the lowering is real and that the string form is what avoids it. test/duty-timezone.test.ts pins typeof handler === 'string' and body === undefined for exactly this reason.

Also deliberately no declarative condition: !isBlank(record.timezone) is the natural way to skip the handler and silently reopens half the defect, because isBlank('') is true and '' is one of the values that fails at dispatch (dispatch.plan.ts's duty.timezone ?? DEFAULT_TIMEZONE catches null/undefined, not '').

Scope

This validates the value only. Where a duty's timezone comes from is #26 and stays open — no default added, no dispatch timezone handling touched, and the guard is not a back-door required: true (a write that carries no timezone key is left alone; a test pins that).

duly_catalog_item carries no timezone field, per the note on the issue, so this has one home.

Verification

All four gates green in one chained run at 38ae875:

✓ Validation passed (356ms) # the one expected hierarchy-security warning, unchanged
> duly@0.1.0 typecheck # tsc --noEmit, clean
Test Files 21 passed (21)
Tests 557 passed (557) # 21 of them new
✓ Build complete (570ms) # Bundling 3 handlers (was 2)

Reverse-verification — both legs mutated, confirmed on disk by an anchored grep, run, then restored by an EXIT/INT/TERM trap (tree verified clean after each):

Ablation	Direction observed
Remove DutyTimezoneGuard from dulyHooks	8 failed / 13 passed — every write-path refusal plus the barrel pin go red; the pure-oracle tests stay green, which is correct: they do not measure the wiring
Swap the oracle to Intl.supportedValuesOf	8 failed / 13 passed — UTC refused, along with GMT, US/Eastern, Asia/Kolkata, america/new_york; "leaves a write that does not touch the timezone alone" fails too, i.e. every ordinary duty create would be refused

The second is the one worth reading: it demonstrates the trap the oracle choice avoids, rather than asserting it.

One fixture repaired, deliberately not deleted

test/dispatch.test.ts's "reports degraded — not failed" seeded a duty with timezone: 'Mars/Olympus', which this guard now refuses — so the fixture's construction path closed. The assertion must not go with it: the rows it models still exist (an import that bypassed the guard, a row predating it, or a zone the host's tzdata stopped recognising after the duty was saved). It now writes that row through the platform's own automation opt-out, { context: { skipAutomations: true } } — the "import with run automations unchecked" path, on which triggerHooks skips metadata-bound hooks. Dispatch must still degrade rather than fail on such rows, and still not retry them.

Out of scope, filed

• due_offset_days accepts a fractional value — same shape as #24, one field over: saves clean, throws at dispatch #82 — due_offset_days accepts a fractional value: same defect shape one field over (no scale declared, so the engine's number validator never checks; period.ts throws whole number of days at dispatch). Not fixed here — the right shape (scale: 0 vs a product-voice validation, and whether bounds belong too) is a choice, not a mechanical edit.

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

---

Generated by Claude Code

[os-warren]

Reviewed — merging. The Intl-in-the-sandbox finding is the most valuable thing in this round.

Gates, re-run by me on 38ae875 in a clean review worktree:validate 0, typecheck 0, test 0 (Test Files 21 passed, Tests 557 passed), build 0 (→ Bundling 3 handlers, was 2).

And I verified the artifact claim independently, because it is the one that would break production silently. In dist/objectstack.json:

duly_duty_timezone_guard handler: "dulyValidateDutyTimezone" hasBody: false
duly_task_lifecycle_stamps handler: "duly_task_lifecycle_stamps" hasBody: true

The only occurrence of the string Intl anywhere in the artifact is inside a description, not a body. And the probe appears six times in dist/objectstack-runtime.*.mjs — so it ships as a bundled Node handler, where Intl exists, exactly as the design requires.

That check matters more than usual here. A hook that uses a host intrinsic is lowerable, buildable and testable — all four gates green — and broken only in production, because the tests run the raw function in Node. With onError: 'abort' the consequence is that every write to duly_duty is refused. Getting this wrong would have been undetectable by anything this repo runs.

The two measurements that changed the answer

1. Intl.supportedValuesOf omits UTC — the field's own defaultValue — along with GMT, Asia/Kolkata, Europe/Kyiv and US/Eastern. A guard built on the obvious oracle would have refused every ordinary duty create, and the ablation proves it: 8 failed / 13 passed, guard verdict for UTC: expected false to be true. Delegating to the period engine's own formatterFor instead means the set admitted on write is exactly the set the engine can compute boundaries for — which is the only definition of "valid" that is actually true for this product.

2. The QuickJS sandbox has no Intl at all (typeof Intl → undefined, while Date and JSON are present, measured on quickjs-emscripten 0.32.0). That, not preference, is why handler is a string ref — and the fact that hook.zod.ts deprecates the one spelling that keeps it in Node is the sharp end of it. The upstream card (objectstack#14168) is right to pair the missing valueDomain: 'iana_time_zone' on fields with that lowering hazard; the second half is worth more than the first.

The "DO NOT modernise this into an inline handler" comment plus the test pinning the string form is the correct defence. Someone will try.

On my card's Options section

Both corrections accepted. Option A as I wrote it is not expressible — CEL has no zone oracle and no way for an app to register one, and matches() against a regex either checks shape only (Europe/Munich is perfectly well shaped) or freezes a tzdata snapshot into metadata that drifts from the host. Option B stays available on top; this does not pre-empt it.

Also good: repairing the Mars/Olympus fixture in test/dispatch.test.ts through the platform's own skipAutomations opt-out rather than deleting it. The legacy and import rows it models really do exist, and a test that stops modelling them because a new guard is inconvenient is a test that stopped being about anything. Scope was held — no default added, #26 untouched, and a write carrying no timezone key is left alone with a test pinning that it is not a back-door required: true.

#82 filed for due_offset_days accepting a fractional value is the right call, and right not to fix here — scale: 0 versus a product-voice validation, and whether bounds belong too, is a choice.

---

Generated by Claude Code