fix(spec): record the shipped IANA time-zone narrowing in the ADR-0087 ledger

`#16296` gave `sys_job.timezone` and `sys_report_schedule.timezone` the
`valueDomain: 'iana_time_zone'` declaration — a write-time narrowing that
shipped with no breaking-change marker, so the repo's detector classified it
non-breaking and asked for no ADR-0087 disposition.

The ledger now carries a `semantic` entry for it, protocol 18, stating what
narrowed and the one-line fix per offending row. Nothing is re-released and
nothing is ratified in silence.

⚠️ The ruling named TWO narrowings. The second, `#14238`, is NOT one: its diff
is 535 insertions and 0 deletions across 11 files — two nullable columns ADDED,
carrying the value domain from their first release — and its own changeset says
so in writing ("A NON-BREAKING ADDITION ... ADR-0087's registries have no
additive entry kind"). A row claiming it narrowed something would be false data
in the one ledger this mechanism keeps true, which ADR-0087 refuses by name. The
finding is reported to the seat rather than written into the ledger.

Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ef78bLdybu3AffehKkhfk

Author: claude

.changeset/16421-clause2-direction-arm.md

@@ -0,0 +1,30 @@
+---
+'@objectstack/spec': patch
+---
+
+fix(spec): record the shipped `sys_job` / `sys_report_schedule` IANA narrowing in the ADR-0087 ledger (#16421)
+
+Clause-②: no
+
+`#16296` gave `sys_job.timezone` and `sys_report_schedule.timezone` the
+`valueDomain: 'iana_time_zone'` declaration. That is a write-time narrowing — a
+string these columns used to accept is now refused with the ADR-0114 field code
+`value_domain` — and it shipped with no breaking-change marker at all, so the
+repo's own detector classified it non-breaking and asked for no ADR-0087
+disposition. Measured on the shipped changeset, not inferred.
+
+The ledger now carries a `semantic` entry for it
+(`platform-timezone-columns-iana-domain-refused`, protocol 18). Nothing is
+re-released and nothing is ratified in silence: the entry states what narrowed,
+the one-line fix per offending row (write the canonical zone id, or clear the
+column), and the fact that a stored non-member is still readable and still
+returned unchanged — it fails only on the row's next write. For
+`sys_report_schedule` that refusal is the point: a non-member zone was silently
+discarding the cron expression and falling back to `interval_minutes` forever.
+
+No authorable key, export, config field or stored shape moves, and no DDL is
+planned — this is a record of a change that already shipped, published so that
+`objectstack migrate meta`'s consumers can read it.
+
+Maintainer ruling, director summon #17, decision batch #2 item 1, option B,
+quoted verbatim and untranslated: 「同意」.

packages/spec/src/migrations/entries/semantic/18.platform-timezone-columns-iana-domain-refused.ts

@@ -0,0 +1,59 @@
+// Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
+
+import type { SemanticMigration } from '../../types.js';
+
+export const entry: SemanticMigration = {
+  id: 'platform-timezone-columns-iana-domain-refused',
+  surface:
+    'The two platform audit time-zone columns — `sys_job.timezone` and '
+    + '`sys_report_schedule.timezone` — carrying a string that is not a member of the '
+    + 'IANA time-zone database (`Asia/Shangai`, `Europe/Munich`, `UTC+8`, `PST`).',
+  replacement:
+    'The canonical IANA zone id the deployment meant, written in the spelling the tzdb '
+    + 'uses: `Asia/Shanghai`, `Europe/Berlin`, `America/Los_Angeles`. `UTC` is a member '
+    + 'and is admitted — membership is the shared `Intl.DateTimeFormat` probe, never the '
+    + '`Intl.supportedValuesOf(\'timeZone\')` enumeration, which omits `UTC` and would '
+    + 'refuse the one fallback this contract names. ⚠️ A non-member is RE-AUTHORED, never '
+    + 'repaired on the deployment\'s behalf: the correct zone behind a typo is a fact only '
+    + 'the deployment holds, which is what makes this entry semantic rather than a D2 '
+    + 'conversion.',
+  reason:
+    '#16296 gave both columns `valueDomain: \'iana_time_zone\'`, which had been declared '
+    + 'on `sys_business_unit.timezone` / `sys_organization.timezone` since #14238. It is a '
+    + 'WRITE-TIME narrowing of the `min`/`max`/`maxLength` transition-gate class: a value '
+    + 'already stored outside the domain is never re-read against it, no DDL is planned, '
+    + 'and `objectstack migrate meta` has nothing to rewrite — the changeset that shipped '
+    + 'it says so in those words, and this entry does not contradict it. What the '
+    + 'changeset had no way to carry is that a deployment holding such a value now has '
+    + 'WORK TO DO: the next write of that row is refused with the ADR-0114 field code '
+    + '`value_domain`, and until then `sys_report_schedule.timezone` keeps doing the thing '
+    + 'the narrowing exists to stop — `ReportService.nextRunAt` hands a non-member zone to '
+    + 'croner, whose throw was caught and turned into a silent fall back to '
+    + '`interval_minutes`, so "every weekday 09:00 Asia/Shanghai" became "every 1440 '
+    + 'minutes, forever". Not a throw and not a fall back to UTC: the wrong instant, '
+    + 'permanently. ⛔ It went out with NO `**BREAKING**` marker, so the repo\'s own '
+    + 'breaking-change detector classified it non-breaking and asked for no ADR-0087 '
+    + 'disposition at all — measured on the shipped changeset. #16421 closed that hole '
+    + '(the declaration now carries a `(narrowing)` arm the gate reads instead of a prose '
+    + 'banner) and this row is the other half of the same ruling: the narrowing that '
+    + 'already shipped is RECORDED, ⛔ not re-released and ⛔ not ratified in silence. '
+    + 'Maintainer ruling, director summon #17, decision batch #2 item 1, option B, '
+    + 'verbatim and untranslated: 「同意」. The direct precedents for registering a change '
+    + 'no transform can apply are `schedule-flow-acting-organization-required` (protocol '
+    + '18) and `rest-requireauth-default-flip` (protocol 12) — behaviour-only, a '
+    + 'deployment judgement, registered anyway because the prescription is real.',
+  acceptanceCriteria:
+    'Every `sys_job.timezone` and `sys_report_schedule.timezone` value stored in the '
+    + 'deployment is an IANA member. The one-line fix per offending row: write the '
+    + 'canonical zone id (`UPDATE … SET timezone = \'Asia/Shanghai\'`), or clear the '
+    + 'column — `sys_report_schedule` documents a `UTC` default and `sys_job` has no '
+    + 'reader at all. Rows already holding a member parse and behave byte-identically to '
+    + 'before; rows holding none are readable, are returned unchanged, and fail only on '
+    + 'their next WRITE. A report schedule that was silently running on '
+    + '`interval_minutes` resumes its cron cadence once its zone is a member — that '
+    + 'resumption, not the absence of an error, is how the fix is verified. ⚠️ The two '
+    + 'columns\' `maxLength` (100 vs 64) and defaults (none vs `UTC`) are deliberately '
+    + 'still unconverged and are NOT part of this entry; no member is longer than 32 '
+    + 'characters on the current Node baseline, so neither bound admits anything the '
+    + 'domain does not.',
+};

packages/spec/src/migrations/registry.ts

@@ -9676,6 +9676,61 @@ const step18: MigrationStep = {
         + 'who was previously outside an `assignedProfiles` list and could nonetheless open the page '
         + 'is the pre-existing state, not a regression introduced by the removal.',
     },
+    {
+      id: 'platform-timezone-columns-iana-domain-refused',
+      surface:
+        'The two platform audit time-zone columns — `sys_job.timezone` and '
+        + '`sys_report_schedule.timezone` — carrying a string that is not a member of the '
+        + 'IANA time-zone database (`Asia/Shangai`, `Europe/Munich`, `UTC+8`, `PST`).',
+      replacement:
+        'The canonical IANA zone id the deployment meant, written in the spelling the tzdb '
+        + 'uses: `Asia/Shanghai`, `Europe/Berlin`, `America/Los_Angeles`. `UTC` is a member '
+        + 'and is admitted — membership is the shared `Intl.DateTimeFormat` probe, never the '
+        + '`Intl.supportedValuesOf(\'timeZone\')` enumeration, which omits `UTC` and would '
+        + 'refuse the one fallback this contract names. ⚠️ A non-member is RE-AUTHORED, never '
+        + 'repaired on the deployment\'s behalf: the correct zone behind a typo is a fact only '
+        + 'the deployment holds, which is what makes this entry semantic rather than a D2 '
+        + 'conversion.',
+      reason:
+        '#16296 gave both columns `valueDomain: \'iana_time_zone\'`, which had been declared '
+        + 'on `sys_business_unit.timezone` / `sys_organization.timezone` since #14238. It is a '
+        + 'WRITE-TIME narrowing of the `min`/`max`/`maxLength` transition-gate class: a value '
+        + 'already stored outside the domain is never re-read against it, no DDL is planned, '
+        + 'and `objectstack migrate meta` has nothing to rewrite — the changeset that shipped '
+        + 'it says so in those words, and this entry does not contradict it. What the '
+        + 'changeset had no way to carry is that a deployment holding such a value now has '
+        + 'WORK TO DO: the next write of that row is refused with the ADR-0114 field code '
+        + '`value_domain`, and until then `sys_report_schedule.timezone` keeps doing the thing '
+        + 'the narrowing exists to stop — `ReportService.nextRunAt` hands a non-member zone to '
+        + 'croner, whose throw was caught and turned into a silent fall back to '
+        + '`interval_minutes`, so "every weekday 09:00 Asia/Shanghai" became "every 1440 '
+        + 'minutes, forever". Not a throw and not a fall back to UTC: the wrong instant, '
+        + 'permanently. ⛔ It went out with NO `**BREAKING**` marker, so the repo\'s own '
+        + 'breaking-change detector classified it non-breaking and asked for no ADR-0087 '
+        + 'disposition at all — measured on the shipped changeset. #16421 closed that hole '
+        + '(the declaration now carries a `(narrowing)` arm the gate reads instead of a prose '
+        + 'banner) and this row is the other half of the same ruling: the narrowing that '
+        + 'already shipped is RECORDED, ⛔ not re-released and ⛔ not ratified in silence. '
+        + 'Maintainer ruling, director summon #17, decision batch #2 item 1, option B, '
+        + 'verbatim and untranslated: 「同意」. The direct precedents for registering a change '
+        + 'no transform can apply are `schedule-flow-acting-organization-required` (protocol '
+        + '18) and `rest-requireauth-default-flip` (protocol 12) — behaviour-only, a '
+        + 'deployment judgement, registered anyway because the prescription is real.',
+      acceptanceCriteria:
+        'Every `sys_job.timezone` and `sys_report_schedule.timezone` value stored in the '
+        + 'deployment is an IANA member. The one-line fix per offending row: write the '
+        + 'canonical zone id (`UPDATE … SET timezone = \'Asia/Shanghai\'`), or clear the '
+        + 'column — `sys_report_schedule` documents a `UTC` default and `sys_job` has no '
+        + 'reader at all. Rows already holding a member parse and behave byte-identically to '
+        + 'before; rows holding none are readable, are returned unchanged, and fail only on '
+        + 'their next WRITE. A report schedule that was silently running on '
+        + '`interval_minutes` resumes its cron cadence once its zone is a member — that '
+        + 'resumption, not the absence of an error, is how the fix is verified. ⚠️ The two '
+        + 'columns\' `maxLength` (100 vs 64) and defaults (none vs `UTC`) are deliberately '
+        + 'still unconverged and are NOT part of this entry; no member is longer than 32 '
+        + 'characters on the current Node baseline, so neither bound admits anything the '
+        + 'domain does not.',
+    },
     {
       id: 'plugin-auto-restart-never-reinitialised',
       surface: