docs: amend constitution to v2.10.0 with OperationRun start UX contract

.specify/memory/constitution.md

@@ -1,28 +1,30 @@
 <!--
 Sync Impact Report
 
-- Version change: 2.8.0 -> 2.9.0
+- Version change: 2.9.0 -> 2.10.0
 - Modified principles:
-  - Added provider-boundary guardrail set under First Provider Is Not
-    Platform Core (PROV-001 with sub-rules PROV-002 through PROV-005)
-  - Expanded Governance review expectations for provider-owned vs
-    platform-core boundaries
+  - Expanded Operations / Run Observability Standard so OperationRun
+    start UX is shared-contract-owned instead of surface-owned
+  - Expanded Governance review expectations for OperationRun-starting
+    features, explicit queued-notification policy, and bounded
+    exceptions
 - Added sections:
-  - First Provider Is Not Platform Core (PROV-001): keeps Microsoft as
-    the current first provider without allowing provider-specific
-    semantics to silently become platform-core truth; requires explicit
-    review of provider-owned vs platform-core seams and prefers bounded
-    extraction over speculative multi-provider frameworks
+  - OperationRun Start UX Contract (OPS-UX-START-001): centralizes
+    queued toast/link/event/message semantics, run/artifact deep links,
+    queued DB-notification policy, and tenant/workspace-safe operation
+    URL resolution behind one shared OperationRun UX layer
 - Removed sections: None
 - Templates requiring updates:
-  - .specify/templates/spec-template.md: add provider-boundary platform
-    core check ✅
-  - .specify/templates/plan-template.md: add provider-boundary planning
-    fields + constitution check ✅
-  - .specify/templates/tasks-template.md: add provider-boundary task
-    requirements ✅
-  - .specify/templates/checklist-template.md: add provider-boundary
-    review checks ✅
+- .specify/templates/spec-template.md: add OperationRun UX Impact
+    section + start-contract prompts ✅
+- .specify/templates/plan-template.md: add OperationRun UX Impact
+    planning section + constitution checks ✅
+- .specify/templates/tasks-template.md: add central start-UX reuse,
+    queued-notification policy, and exception tasks ✅
+- .specify/templates/checklist-template.md: add OperationRun start
+    UX review checks ✅
+- docs/product/standards/README.md: refresh constitution index for
+    the new ops-UX contract ✅
 - Commands checked:
   - N/A `.specify/templates/commands/*.md` directory is not present
 - Follow-up TODOs: None
@@ -307,24 +309,57 @@ ### Operations / Run Observability Standard
   even if implemented by multiple jobs/steps (“umbrella run”).
 - “Single-row” runs MUST still use consistent counters (e.g., `total=1`, `processed=0|1`) and outcome derived from success/failure.
 - Monitoring pages MUST be DB-only at render time (no external calls).
-- Start surfaces MUST NOT perform remote work inline; they only: authorize, create/reuse run (dedupe), enqueue work,
-  confirm + “View run”.
+- Start surfaces MUST NOT perform remote work inline and MUST NOT compose OperationRun start UX locally; they only:
+  authorize, create/reuse run (dedupe), enqueue work, and hand queued/start-state feedback to the shared
+  OperationRun Start UX Contract.
+
+### OperationRun Start UX Contract (OPS-UX-START-001)
+
+- OperationRun UX MUST be contract-driven, not surface-driven.
+- Any feature that creates, queues, deduplicates, resumes, blocks, completes, or links to an `OperationRun` MUST use
+  the central OperationRun Start UX Contract.
+- Filament Pages, Resources, Widgets, Livewire Components, Actions, and Services MUST NOT independently compose
+  OperationRun start UX from local pieces.
+- The shared OperationRun UX layer MUST own:
+  - local start notification / toast
+  - `Open operation` / `View run` link
+  - artifact link such as `View snapshot`, `View pack`, or `View restore`
+  - run-enqueued browser event
+  - queued DB-notification decision
+  - dedupe / already-available / already-running messaging
+  - blocked / failed-to-start messaging
+  - tenant/workspace-safe operation URL resolution
+- Feature surfaces MAY initiate `OperationRun`s, but they MUST NOT define their own OperationRun UX semantics.
+- `OperationRun` lifecycle state remains the canonical execution truth.
+- Queued DB notifications MUST remain explicit opt-in unless the active spec defines a different policy.
+- Terminal `OperationRun` notifications MUST be emitted through the central OperationRun lifecycle mechanism.
+- Any exception MUST include:
+  1. an explicit spec decision,
+  2. a documented architecture note,
+  3. a test or guard-test exception with rationale,
+  4. a follow-up migration decision if the exception is temporary.
+- New OperationRun-starting features MUST include an `OperationRun UX Impact` section in the active spec or plan.
 
 ### Operations UX — 3-Surface Feedback (OPS-UX-055) (NON-NEGOTIABLE)
 
-If a feature creates/reuses `OperationRun`, it MUST use exactly three feedback surfaces — no others:
+If a feature creates/reuses `OperationRun`, its default feedback contract is exactly three surfaces.
+Queued DB notifications are forbidden by default and MAY exist only when the active spec explicitly opts into them
+through the OperationRun Start UX Contract:
 
 1) Toast (intent only / queued-only)
 - A toast MAY be shown only when the run is accepted/queued (intent feedback).
 - The toast MUST use `OperationUxPresenter::queuedToast($operationType)->send()`.
 - Feature code MUST NOT craft ad-hoc operation toasts.
 - A dedicated dedupe message MUST use the presenter (e.g., `alreadyQueuedToast(...)`), not `Notification::make()`.
+- Queued toast copy, action links, artifact links, start-state browser events, and dedupe/start-failure messaging MUST be
+  produced by the shared OperationRun Start UX Contract, not by local surface code.
 
 2) Progress (active awareness only)
 - Live progress MUST exist only in:
   - the global active-ops widget, and
   - Monitoring → Operation Run Detail.
 - These surfaces MUST show only active runs (`queued|running`) and MUST never show terminal runs.
+- Running DB notifications are forbidden.
 - Determinate progress is allowed ONLY when `summary_counts.total` and `summary_counts.processed` are valid numeric values.
 - Determinate progress MUST be clamped to 0–100. Otherwise render indeterminate + elapsed time.
 - The widget MUST NOT show percentage text (optional `processed/total` is allowed).
@@ -365,6 +400,10 @@ ### Ops-UX regression guards are mandatory (OPS-UX-GUARD-001)
 
 The repo MUST include automated guards (Pest) that fail CI if:
 - any direct `OperationRun` status/outcome transition occurs outside `OperationRunService`,
+- feature code bypasses the central OperationRun Start UX Contract for queued/start-state operation UX where the repo's
+  guardable patterns can detect it,
+- feature code emits queued DB notifications for operations without explicit spec-driven opt-in through the shared
+  OperationRun UX layer,
 - jobs emit DB notifications for operation completion/abort (`OperationRunCompleted` is the single terminal notification),
 - deprecated legacy operation notification classes are referenced again.
 
@@ -1614,6 +1653,11 @@ ### Scope, Compliance, and Review Expectations
 - Runtime-changing or test-affecting specs and PRs MUST include testing/lane/runtime impact covering actual test-purpose classification, affected lanes, fixture/helper/factory/seed/context cost changes, any heavy-family expansion, expected budget/baseline/trend effect, escalation decisions, and the minimal validation commands.
 - Specs, plans, task lists, and review checklists MUST surface the test-governance questions needed to catch lane drift, hidden defaults, and runtime-cost escalation before merge.
 - Specs and PRs that touch shared provider/platform seams MUST classify the touched boundary as provider-owned or platform-core, keep provider-specific semantics out of platform-core contracts and vocabulary unless explicitly justified, and record whether any remaining hotspot is resolved in-feature or escalated as a follow-up spec.
+- Specs and PRs that create, queue, deduplicate, resume, block, complete, or deep-link to an `OperationRun` MUST reuse the
+  central OperationRun Start UX Contract, keep queued DB notifications explicit opt-in unless the active spec states a
+  different policy, route terminal notifications through the lifecycle mechanism, include an `OperationRun UX Impact`
+  section in the active spec or plan, and document any temporary exception with an architecture note, test rationale,
+  and migration decision.
 - Specs and PRs that change operator-facing surfaces MUST classify each
   affected surface under DECIDE-001 and justify any new Primary
   Decision Surface or workflow-first navigation change.
@@ -1631,4 +1675,4 @@ ### Versioning Policy (SemVer)
 - **MINOR**: new principle/section or materially expanded guidance.
 - **MAJOR**: removing/redefining principles in a backward-incompatible way.
 
-**Version**: 2.9.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-23
+**Version**: 2.10.0 | **Ratified**: 2026-01-03 | **Last Amended**: 2026-04-24

.specify/templates/checklist-template.md

@@ -32,6 +32,13 @@ ## Shared Pattern Reuse
 - [ ] CHK008 The change extends the shared path where it is sufficient, or the deviation is explicitly documented with product reason, preserved consistency, ownership cost, and spread-control.
 - [ ] CHK009 The change does not create a parallel operator-facing UX language for the same interaction class unless a bounded exception is recorded.
 
+## OperationRun Start UX Contract
+
+- [ ] CHK019 The change explicitly says whether it creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`, and the required `OperationRun UX Impact` section exists when applicable.
+- [ ] CHK020 Queued toast/link/artifact-link/browser-event/dedupe-or-blocked messaging and tenant/workspace-safe operation URL resolution are delegated to the shared OperationRun UX contract instead of local surface code.
+- [ ] CHK021 Any queued DB notification is explicit opt-in in the active spec or plan, running DB notifications remain absent, and terminal notifications still flow through the central lifecycle mechanism.
+- [ ] CHK022 Any exception records the explicit spec decision, architecture note, test or guard-test rationale, and temporary migration follow-up decision.
+
 ## Provider Boundary And Vocabulary
 
 - [ ] CHK010 The change states whether any touched shared seam is provider-owned, platform-core, or mixed, and provider-specific semantics do not silently spread into platform-core contracts, taxonomy, identifiers, compare semantics, or operator vocabulary.

.specify/templates/plan-template.md

@@ -54,6 +54,18 @@ ## Shared Pattern & System Fit
 - **Why the existing abstraction was sufficient or insufficient**: [Short explanation tied to current-release truth]
 - **Bounded deviation / spread control**: [none / describe the exception boundary and containment rule]
 
+## OperationRun UX Impact
+
+> **Fill when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`. Docs-only or template-only work may use concise `N/A`.**
+
+- **Touches OperationRun start/completion/link UX?**: [yes / no / N/A]
+- **Central contract reused**: [shared OperationRun UX layer / `N/A`]
+- **Delegated UX behaviors**: [queued toast / run link / artifact link / run-enqueued browser event / queued DB-notification decision / dedupe-or-blocked messaging / tenant/workspace-safe URL resolution / `N/A`]
+- **Surface-owned behavior kept local**: [initiation inputs only / none / short explanation]
+- **Queued DB-notification policy**: [explicit opt-in / spec override / `N/A`]
+- **Terminal notification path**: [central lifecycle mechanism / `N/A`]
+- **Exception path**: [none / spec decision + architecture note + test rationale + temporary migration follow-up]
+
 ## Provider Boundary & Portability Fit
 
 > **Fill when the feature touches shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth. Docs-only or template-only work may use concise `N/A`.**
@@ -79,7 +91,8 @@ ## Constitution Check
 - RBAC-UX: global search is tenant-scoped; non-members get no hints; inaccessible results are treated as not found (404 semantics)
 - Tenant isolation: all reads/writes tenant-scoped; cross-tenant views are explicit and access-checked
 - Run observability: long-running/remote/queued work creates/reuses `OperationRun`; start surfaces enqueue-only; Monitoring is DB-only; DB-only <2s actions may skip runs but security-relevant ones still audit-log; auth handshake exception OPS-EX-AUTH-001 allows synchronous outbound HTTP on `/auth/*` without `OperationRun`
-- Ops-UX 3-surface feedback: if `OperationRun` is used, feedback is exactly toast intent-only + progress surfaces + exactly-once terminal `OperationRunCompleted` (initiator-only); no queued/running DB notifications
+- OperationRun start UX: any feature that creates, queues, deduplicates, resumes, blocks, completes, or links `OperationRun` reuses the central OperationRun Start UX Contract; no local composition of queued toast/link/event/start-state messaging; `OperationRun UX Impact` is present in the active spec or plan
+- Ops-UX 3-surface feedback: if `OperationRun` is used, default feedback is toast intent-only + progress surfaces + exactly-once terminal `OperationRunCompleted` (initiator-only); queued DB notifications remain explicit opt-in through the shared start UX contract; running DB notifications stay disallowed
 - Ops-UX lifecycle: `OperationRun.status` / `OperationRun.outcome` transitions are service-owned (only via `OperationRunService`); context-only updates allowed outside
 - Ops-UX summary counts: `summary_counts` keys come from `OperationSummaryKeys::all()` and values are flat numeric-only
 - Ops-UX guards: CI has regression guards that fail with actionable output (file + snippet) when these patterns regress

.specify/templates/spec-template.md

@@ -47,6 +47,16 @@ ## Cross-Cutting / Shared Pattern Reuse *(mandatory when the feature touches not
 - **Consistency impact**: [What must stay aligned across interaction structure, copy, status semantics, actions, and deep links]
 - **Review focus**: [What reviewers must verify to prevent parallel local patterns]
 
+## OperationRun UX Impact *(mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an `OperationRun`; otherwise write `N/A - no OperationRun start or link semantics touched`)*
+
+- **Touches OperationRun start/completion/link UX?**: [yes/no]
+- **Shared OperationRun UX contract/layer reused**: [Name it or `N/A`]
+- **Delegated start/completion UX behaviors**: [queued toast / `Open operation` or `View run` link / artifact link / run-enqueued browser event / queued DB-notification decision / dedupe-or-blocked messaging / tenant/workspace-safe URL resolution / `N/A`]
+- **Local surface-owned behavior that remains**: [initiation inputs only / none / bounded explanation]
+- **Queued DB-notification policy**: [explicit opt-in / spec override / `N/A`]
+- **Terminal notification path**: [central lifecycle mechanism / `N/A`]
+- **Exception required?**: [none / explicit spec decision + architecture note + test or guard-test rationale + temporary migration follow-up]
+
 ## Provider Boundary / Platform Core Check *(mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write `N/A - no shared provider/platform boundary touched`)*
 
 - **Shared provider/platform boundary touched?**: [yes/no]
@@ -263,12 +273,21 @@ ## Requirements *(mandatory)*
 - and the exact minimal validation commands reviewers should run.
 
 **Constitution alignment (OPS-UX):** If this feature creates/reuses an `OperationRun`, the spec MUST:
-- explicitly state compliance with the Ops-UX 3-surface feedback contract (toast intent-only, progress surfaces, terminal DB notification),
+- explicitly state compliance with the default Ops-UX 3-surface feedback contract (toast intent-only, progress surfaces, terminal DB notification) and whether any queued DB notification is explicitly opted into,
 - state that `OperationRun.status` / `OperationRun.outcome` transitions are service-owned (only via `OperationRunService`),
 - describe how `summary_counts` keys/values comply with `OperationSummaryKeys::all()` and numeric-only rules,
 - clarify scheduled/system-run behavior (initiator null → no terminal DB notification; audit is via Monitoring),
 - list which regression guard tests are added/updated to keep these rules enforceable in CI.
 
+**Constitution alignment (OPS-UX-START-001):** If this feature creates, queues, deduplicates, resumes, blocks, completes, or links to an `OperationRun`, the spec MUST:
+- include the `OperationRun UX Impact` section,
+- name the shared OperationRun UX contract/layer being reused,
+- delegate queued toast/link/artifact-link/browser-event/queued-DB-notification/dedupe-or-blocked messaging/tenant-safe URL resolution to that shared path,
+- keep local surface code limited to initiation inputs and operation-specific data capture,
+- keep queued DB notifications explicit opt-in unless the spec intentionally defines a different policy,
+- route terminal notifications through the central lifecycle mechanism,
+- and document any exception with an explicit spec decision, architecture note, test or guard-test rationale, and temporary follow-up migration decision.
+
 **Constitution alignment (RBAC-UX):** If this feature introduces or changes authorization behavior, the spec MUST:
 - state which authorization plane(s) are involved (tenant/admin `/admin` + tenant-context `/admin/t/{tenant}/...` vs platform `/system`),
 - ensure any cross-plane access is deny-as-not-found (404),

.specify/templates/tasks-template.md

@@ -18,17 +18,22 @@ # Tasks: [FEATURE NAME]
 - record budget, baseline, or trend follow-up when runtime cost shifts materially,
 - and document whether the change resolves as `document-in-feature`, `follow-up-spec`, or `reject-or-split`.
 **Operations**: If this feature introduces long-running/remote/queued/scheduled work, include tasks to create/reuse and update a
-canonical `OperationRun`, and ensure “View run” links route to the canonical Monitoring hub.
+canonical `OperationRun`, and ensure “View run” links route to the canonical Monitoring hub through the shared OperationRun start UX path rather than local surface composition.
 If security-relevant DB-only actions skip `OperationRun`, include tasks for `AuditLog` entries (before/after + actor + tenant).
 Auth handshake exception (OPS-EX-AUTH-001): OIDC/SAML login handshakes may perform synchronous outbound HTTP on `/auth/*` endpoints
 without an `OperationRun`.
 If this feature creates/reuses an `OperationRun`, tasks MUST also include:
+- reusing the central OperationRun Start UX Contract instead of composing local queued toast/link/event/dedupe/blocked/start-failure semantics,
+- delegating `Open operation` / `View run`, artifact links, run-enqueued browser event, queued DB-notification policy, dedupe / already-available / already-running messaging, blocked / failed-to-start messaging, and tenant/workspace-safe URL resolution to the shared OperationRun UX layer,
 - enforcing the Ops-UX 3-surface feedback contract (toast intent-only via `OperationUxPresenter`, progress only in widget + run detail, terminal notification is `OperationRunCompleted` exactly-once, initiator-only),
-- ensuring no queued/running DB notifications exist anywhere for operations (no `sendToDatabase()` for queued/running/completion/abort in feature code),
+- keeping queued DB notifications explicit opt-in in the active spec unless a different policy is intentionally approved, and ensuring running DB notifications do not exist,
+- routing terminal notifications through the central lifecycle mechanism rather than feature-local notification code,
 - ensuring `OperationRun.status` / `OperationRun.outcome` transitions happen only via `OperationRunService`,
 - ensuring `summary_counts` keys come from `OperationSummaryKeys::all()` and values are flat numeric-only,
 - adding/updating Ops-UX regression guards (Pest) that fail CI with actionable output (file + snippet) when these patterns regress,
-- clarifying scheduled/system-run behavior (initiator null → no terminal DB notification; audit via Monitoring; tenant-wide alerting via Alerts system).
+- clarifying scheduled/system-run behavior (initiator null → no terminal DB notification; audit via Monitoring; tenant-wide alerting via Alerts system),
+- documenting any exception with an explicit spec decision, architecture note, test or guard-test rationale, and temporary migration follow-up decision,
+- and ensuring the active spec or plan contains an `OperationRun UX Impact` section.
 **RBAC**: If this feature introduces or changes authorization, tasks MUST include:
 - explicit Gate/Policy enforcement for all mutation endpoints/actions,
 - explicit 404 vs 403 semantics:

docs/product/standards/README.md

@@ -4,7 +4,7 @@ # Product Standards
 > Specs reference these standards; they do not redefine them.
 > Guard tests enforce critical constraints automatically.
 
-**Last reviewed**: 2026-04-12
+**Last reviewed**: 2026-04-24
 
 ---
 
@@ -42,7 +42,7 @@ ## Related Docs
 
 | Document | Location | Purpose |
 |---|---|---|
-| Constitution | `.specify/memory/constitution.md` | Permanent principles (PROP-001, BLOAT-001, UI-CONST-001, DECIDE-001, UI-SURF-001, ACTSURF-001, UI-HARD-001, UI-EX-001, HDR-001, OPSURF-001, UI-FIL-001, UX-001, Action Surface Contract, RBAC-UX) |
+| Constitution | `.specify/memory/constitution.md` | Permanent principles (PROP-001, BLOAT-001, OPS-UX-START-001, UI-CONST-001, DECIDE-001, UI-SURF-001, ACTSURF-001, UI-HARD-001, UI-EX-001, HDR-001, OPSURF-001, UI-FIL-001, UX-001, Action Surface Contract, RBAC-UX) |
 | Product Principles | `docs/product/principles.md` | High-level product decisions |
 | Table Rollout Audit | `docs/ui/filament-table-standard.md` | Rollout inventory and implementation state from Spec 125 |
 | Action Surface Contract | `docs/ui/action-surface-contract.md` | Original action surface reference (now governed by this standard) |