@@ -0,0 +1,16 @@
+---
+"@objectstack/plugin-security": major
+---
+
+`sys_user_permission_set` refuses an assignment whose validity window ends at or before it starts (ADR-0091 D1/D2)
+
+Clause-②: no (narrowing)
+
+<!-- adr-0087: not-required (no-migration-prescription) a refusal of one stored value combination on a data object; no metadata key, export or authorable surface moves, so `objectstack migrate meta` has nothing to rewrite -->
+
+**BREAKING**: an accept-set narrowing on the data door, shipped as `major` on the v18 line (`.changeset/pre.json` is open on `main` in `next` pre mode, so the release is `18.0.0-next.*`).
+
+- **What is refused.** A write that leaves an assignment with both `valid_from` and `valid_until` set and `valid_until` at or before `valid_from` is refused with `400 VALIDATION_FAILED`, a `rule_violation` at `valid_until`. The window is half-open, `[valid_from, valid_until)`, so such an assignment can never grant anything: the resolver drops it at every evaluation. Until this release it was stored without a word, so an administrator who mistyped a date got an assignment that silently granted nothing.
+- **Which writes are judged.** Every insert, from every writer, system writers included, single rows and batches alike. An update is judged by the stored row overlaid with the patch, and only when it moves a bound: by id, and for each matched row of a multi-row update. The refusal is a declared validation rule on the object, `validity_window_order`, so the engine runs it on every one of those write paths.
+- **What still lands, unchanged.** A window that ends after it starts, one bound alone (either one), and no window at all. An update that moves neither bound is not judged, so an assignment stored before this release with an inverted window does not block an unrelated edit; the write that repairs it is the only one that has to state a valid window.
+- **To fix a refused write**, set `valid_until` later than `valid_from`, or leave one of the two empty for an open-ended window.
@@ -0,0 +1,7 @@
+---
+"@objectstack/platform-objects": minor
+---
+
+The user page's "Permission Sets" list shows each assignment's validity window, `valid_from` and `valid_until` (ADR-0091 D1/D2)
+
+The resolver drops a `sys_user_permission_set` assignment outside its half-open `[valid_from, valid_until)` window at every evaluation, so a list that showed only the set presented an expired or not-yet-active assignment as a live grant. The two bounds now sit beside the set. The list's Add affordance still writes the user and the set only; the window is set by editing the assignment row.
@@ -0,0 +1,49 @@
+// Copyright (c) 2026 ObjectStack. Licensed under the Apache-2.0 license.
+
+/**
+ * [ADR-0091 D1/D2] The user page's "Permission Sets" list shows each
+ * assignment's validity window.
+ *
+ * The resolver drops a `sys_user_permission_set` row outside its half-open
+ * `[valid_from, valid_until)` window at every evaluation, so the two bounds
+ * decide whether a listed grant confers anything. A list showing only the set
+ * would present an expired or not-yet-active assignment as a live grant.
+ *
+ * Read from the shipped page metadata, through the spec's own contract for the
+ * block, so the pin fails if the columns go and if the block stops being one
+ * the contract accepts.
+ */
+
+import { describe, expect, it } from 'vitest';
+import { RecordRelatedListProps } from '@objectstack/spec/ui';
+import { SysUserDetailPage } from './sys-user.page.js';
+
+type Node = { type?: unknown; properties?: Record<string, unknown> } & Record<string, unknown>;
+
+function relatedListsOf(root: unknown, objectName: string): Record<string, unknown>[] {
+  const found: Record<string, unknown>[] = [];
+  const walk = (n: unknown): void => {
+    if (Array.isArray(n)) { n.forEach(walk); return; }
+    if (!n || typeof n !== 'object') return;
+    const node = n as Node;
+    if (node.type === 'record:related_list' && node.properties?.objectName === objectName) found.push(node.properties);
+    Object.values(node).forEach(walk);
+  };
+  walk(root);
+  return found;
+}
+
+describe('sys_user page — the permission-set assignments list', () => {
+  const lists = relatedListsOf(SysUserDetailPage, 'sys_user_permission_set');
+
+  it('is one related list, and the block contract accepts it', () => {
+    expect(lists).toHaveLength(1);
+    const parsed = RecordRelatedListProps.safeParse(lists[0]);
+    expect(parsed.success, JSON.stringify(parsed.error?.issues ?? [])).toBe(true);
+  });
+
+  it('lists valid_from and valid_until beside the set', () => {
+    const columns = lists[0]?.columns as unknown[];
+    expect(columns).toEqual(expect.arrayContaining(['permission_set_id', 'valid_from', 'valid_until']));
+  });
+});
@@ -212,6 +212,14 @@ export const SysUserDetailPage: Page = {
             // its id (linkField: 'permission_set_id'); server-side gates
             // (audience-anchor D5/D9, delegated-admin D12) surface their denial
             // reason in the Add dialog.
+            //
+            // [ADR-0091 D1/D2] `valid_from` / `valid_until` are listed because
+            // they decide whether the grant confers anything: the resolver drops
+            // an assignment outside its half-open window at every evaluation, so
+            // a row showing only the set would read as a live grant when it is
+            // not. The Add affordance writes the two link keys alone; the window
+            // is set by editing the assignment row, whose object refuses a
+            // window whose end is not after its start.
             label: { en: 'Permission Sets', 'zh-CN': '权限集', 'ja-JP': '権限セット', 'es-ES': 'Conjuntos de permisos' },
             icon: 'lock',
             children: [
@@ -220,7 +228,7 @@ export const SysUserDetailPage: Page = {
                 properties: {
                   objectName: 'sys_user_permission_set',
                   relationshipField: 'user_id',
-                  columns: ['permission_set_id', 'organization_id', 'granted_by', 'created_at'],
+                  columns: ['permission_set_id', 'organization_id', 'valid_from', 'valid_until', 'granted_by', 'created_at'],
                   sort: [{ field: 'created_at', order: 'desc' }],
                   limit: 25,
                   showViewAll: true,
 
@@ -1,7 +1,7 @@
 // Copyright (c) 2025 ObjectStack. Licensed under the Apache-2.0 license.
 
 import { ObjectSchema, Field } from '@objectstack/spec/data';
-import { F } from '@objectstack/spec';
+import { F, P } from '@objectstack/spec';
 
 /**
  * sys_user_permission_set — User ↔ PermissionSet assignment.
@@ -220,6 +220,45 @@ export const SysUserPermissionSet = ObjectSchema.create({
     }),
   },
 
+  // [ADR-0091 D1/D2] The validity window is half-open, `[valid_from,
+  // valid_until)`, so a window whose end is not after its start is EMPTY: the
+  // resolver drops the assignment at every evaluation and it grants nothing,
+  // ever. Stored without a word, a mistyped date became a grant that silently
+  // granted nothing; refusing it at the write tells the administrator.
+  //
+  // Declared, not a hook: the engine evaluates an object's validation rules on
+  // every write path — insert (single and batch) and update (by id, and per
+  // matched row of a multi-row update), for system and non-system writers
+  // alike — against the stored row overlaid with the patch.
+  //
+  // ⛔ A declared rule is an INVARIANT by default: it would refuse ANY edit to a
+  // row that already violates. The `previous` clause narrows it to the writes
+  // that make the window: an insert (`previous` is null there), or an update
+  // that moves a bound. An assignment stored before this rule existed with an
+  // inverted window keeps taking unrelated edits; the write that repairs it is
+  // the only one that has to state a valid window.
+  //
+  // `datetime()` compares instants, not spellings: two ISO strings for one
+  // instant (`…:00Z`, `…:00.000Z`) compare equal, which a string comparison
+  // would not. `cross_field` so the violation attaches to `valid_until`, where
+  // a form shows it.
+  validations: [
+    {
+      type: 'cross_field',
+      name: 'validity_window_order',
+      label: 'Validity window ends after it starts',
+      description:
+        '[ADR-0091 D1/D2] A grant is active in the half-open window [valid_from, valid_until), so a window that '
+        + 'ends at or before it starts grants nothing. Judged on insert, and on an update that moves a bound.',
+      fields: ['valid_until', 'valid_from'],
+      condition: P`(previous == null || record.valid_from != previous.valid_from || record.valid_until != previous.valid_until) && record.valid_from != null && record.valid_until != null && datetime(record.valid_until) <= datetime(record.valid_from)`,
+      severity: 'error',
+      message:
+        'Valid Until must be later than Valid From. The grant is active from Valid From up to, but not including, '
+        + 'Valid Until, so a window that ends at or before it starts grants nothing. Leave either one empty for an open-ended window.',
+    },
+  ],
+
   indexes: [
     { fields: ['user_id', 'permission_set_id', 'organization_id'], unique: 'global' },
     { fields: ['user_id'] },