权限设置应该可以配置实效性，权限在一个时间段之内生效

[os-zhuang]

[os-zhuang]

Triage: needs-user-decision (feature — expands the public authoring surface, human floor per the standing adjudication boundary), domain:identity, type Feature. Original request quoted verbatim: 「权限设置应该可以配置实效性，权限在一个时间段之内生效」.

Context the ruling should weigh — the platform already owns a time-validity vocabulary for grants, partially live:

• ADR-0091 declares grant validity windows, and resolveUserAuthzGrants applies the window to sys_member-derived accessible_org_ids today ([finding] resolveUserAuthzGrants applies the ADR-0091 window to sys_member for accessible_org_ids only — the org-admin role projection is unfiltered #8802 measures the org-admin role projection as still unfiltered).
• The ADR-0091 D5 recertification columns are declared on both grant tables with no producer or reader ([finding] The ADR-0091 D5 recertification columns (last_certified_at / certified_by) are declared on both grant tables and nothing writes or reads them #9046).
• The ADR-0056 authz matrix has no row for the windows at all ([finding] The ADR-0056 D10 authz matrix has no row for the ADR-0091 grant validity windows either — a second instance of #8711's gap #8811).

So the open questions are scope (which permission artefacts get an effective-from/effective-until axis: permission-set assignments? sharing rules? object permissions?), shape (reuse the ADR-0091 window vocabulary vs minting a second time axis), and appetite.

Decision block (four-prism):

• Platform long-term coherence — reusing the ADR-0091 window shape on more grant surfaces converges one time axis; a new per-surface validity shape would be a second one to reconcile forever.
• Measured business pull — maintainer-filed request; no external user measurement on the card yet.
• AI-agent error-resistance — a declared window must be enforced at evaluation time on every surface where it is writable; [finding] The ADR-0091 D5 recertification columns (last_certified_at / certified_by) are declared on both grant tables and nothing writes or reads them #9046/[finding] resolveUserAuthzGrants applies the ADR-0091 window to sys_member for accessible_org_ids only — the org-admin role projection is unfiltered #8802 show the declared-but-partially-enforced state this feature would widen if shipped declaration-first. Enforce-with-declare, or don't declare.
• Startup scope discipline — new capability surface; the discipline is to scope to the narrowest artefact with real pull and land evaluation-side enforcement in the same change.

Recommendation: if approved, start with time-bounded permission-set assignments reusing the ADR-0091 window keys, enforcement measured in the same PR; defer the wider surfaces until something pulls.

This comment is from the triage seat Routine — session session_01GmAinGNjquRHcvG8mEStYe.

---

Generated by Claude Code

[os-zhuang]

Maintainer ruling (2026-08-17, recorded by PM session session_01NYgmGheCzM6NrHZN436Cxf). Verbatim: 「9272 放到 v18开发」(within the batch reply accepting the report's recommendations).

Ruled: approved in the narrowed form, scheduled for v18.

• Scope: time-bounded permission-set assignments only (effective-from / effective-until), reusing the ADR-0091 grant-validity-window vocabulary — ⛔ no second time axis. Wider surfaces (sharing rules, object permissions) wait for measured pull.
• Enforce-with-declare: the window is enforced at evaluation time in the same PR that declares it — never declaration-first (the ADR-0049 dead-surface shape).
• Precondition / same program: [finding] resolveUserAuthzGrants applies the ADR-0091 window to sys_member for accessible_org_ids only — the org-admin role projection is unfiltered #8802 (org-admin role projection still unfiltered by the existing windows) is fixed first or in the same batch, so the window axis is not widened while half-enforced.

Hold record (pm:on-hold, target:v18): Date 2026-08-17; decision made, scheduled at v18 by the maintainer. Named restart condition: the v18 planning window opens — this card re-queues with the scope above and carves (identity lane; the assignment-surface declaration is an accept-surface change ⇒ claude-fable-5 for that slice).

Labels flipped needs-user-decision → pm:on-hold + target:v18 in the same stroke.

---

Generated by Claude Code

[os-support-ai]

Half-state patrol disposition (H9) — the hold gets a machine-fireable exit, and a defect is recorded

domain:services seat, session session_0157mMVAq9fjGe2kaSD2aJC8, round 1.

Patrol anchor #9857 (swept 02:12:33Z) reports H9: pm:on-hold with no Restart-when: in either channel. Confirmed. Supplying the exit:

Restart-when: the v18 line opens for feature work — measured as: any target:v18 card in this repo has reached pm:dispatched, OR the v17 line has cut its final release. Then this card needs a written body (see below) before it can be graded or dispatched.

Restart-touch: packages/plugins/plugin-security/src/, packages/plugins/plugin-sharing/src/ — the permission-evaluation surface a time-bounded grant would land on.

Why a hold and not the decision inbox

target:v18 already records the appetite answer ("yes, on the v18 line"), which is a decision made — the definition of pm:on-hold, as against needs-user-decision for a decision still owed. ⛔ Not escalated.

⚠️ Recorded defect: this card has no body

The issue carries a title and nothing else — no problem statement, no scenario, no acceptance shape. The title (「权限设置应该可以配置实效性,权限在一个时间段之内生效」) names a real and common requirement (time-bounded permission grants: access that turns on at a date and expires at another — a contractor, a covering approver, a temporary auditor), but a one-line title is not dispatchable and not rulable:

• it does not say whether the window sits on the grant (this user's permission set expires) or on the permission set itself (this set is only live in Q4);
• it does not say what happens to work in flight when the window closes mid-session;
• it does not say whether expiry is evaluated at grant-read time or swept.

⇒ Whoever opens the v18 line on this card should write those three answers into the body first, or send it to the decision box. ⛔ It must not be dispatched as it stands: a dev would silently pick one of the three shapes, in code, where nobody reviews it as a decision.

⛔ Deliberately not rewriting the body myself — an execution seat does not author another filer's scope, and inventing a spec here would launder my guess into the record as if it were the requirement.

---

Generated by Claude Code

[objectstack-fleet]

Triage: hold released, pm:on-hold → pm:queue, graded priority:p2 · area:access. The card face below is written from the maintainer's ruling (5315732575), so the card is dispatchable

Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-07T13:27Z. ⛔ Not a claim, ⛔ not a dispatch.

Released on the maintainer's order in the triage seat's chat: 「你应该先解锁 v18 所有的卡片」, then 「同意」 to the plan. #15193 (the v18 gate) closed on that word (6037915987). The ruling record is #22050 6037890422, and the opening card is #22080 (Changesets pre mode).

• Restart condition (5421026689): "the v18 line opens for feature work … Then this card needs a written body before it can be graded or dispatched." The face below is that body, taken from the ruling. Two lines are derived from it rather than quoted, and are marked (derived): the in-flight answer and the ordering refusal both follow from enforcement at evaluation time. A claimant who reads them otherwise stops with needs_decision.
• The precondition is met. The ruling names [finding] resolveUserAuthzGrants applies the ADR-0091 window to sys_member for accessible_org_ids only — the org-admin role projection is unfiltered #8802 (the org-admin role projection unfiltered by the windows). [finding] resolveUserAuthzGrants applies the ADR-0091 window to sys_member for accessible_org_ids only — the org-admin role projection is unfiltered #8802 no longer resolves on this repository (404). The same defect is filed as sys_member's role projection ignores the ADR-0091 validity window while accessible_org_ids honours it — one row, two answers #10982 ("sys_member's role projection ignores the ADR-0091 validity window while accessible_org_ids honours it"), which is closed completed. The claimant confirms the window filter on main before the PR.

Card face (from the ruling, 「9272 放到 v18开发」)

• Scope: time-bounded permission-set assignments only (effective-from / effective-until), reusing ADR-0091's grant-validity-window vocabulary. ⛔ No second time axis. Sharing rules and object permissions wait for measured pull.
• The three questions the patrol asked:
  1. Where the window sits: on the assignment (the grant), not on the permission set.
  2. When expiry is evaluated: at every permission evaluation (read time), as the ruling's enforce-with-declare requires. ⛔ No sweep job.
  3. Work in flight (derived): the first evaluation after the window closes denies. No other session effect.
• Enforce-with-declare: the window is declared and enforced in one PR. ⛔ Never declaration-first.
• Pins:
  • an assignment before its effective-from grants nothing;
  • inside the window it grants;
  • after its effective-until it grants nothing at the next evaluation;
  • an assignment without a window is unchanged (control);
  • the declaring surface refuses effective-until earlier than effective-from (derived).
• Clause-②: yes (new fields on the assignment surface). A contract review is owed at the PR.
• The release state: a breaking change that lands before release(v18): enter Changesets pre mode on main (changeset pre enter next) with one major marker, so the first v18 prerelease is 18.0.0-next.0 — the opening ruled B on #22050 #22080 is graded minor, with its BREAKING banner and ADR-0087 disposition. After release(v18): enter Changesets pre mode on main (changeset pre enter next) with one major marker, so the first v18 prerelease is 18.0.0-next.0 — the opening ruled B on #22050 #22080 it is graded major. ⛔ chore: version packages #21988 is not merged.