ahmido
3030dd9af2
Summary Kurz: Implementiert Feature 054 — canonical OperationRun-flow, Monitoring UI, dispatch-safety, notifications, dedupe, plus small UX safety clarifications (RBAC group search delegated; Restore group mapping DB-only). What Changed Core service: OperationRun lifecycle, dedupe and dispatch helpers — OperationRunService.php. Model + migration: OperationRun model and migration — OperationRun.php, 2026_01_16_180642_create_operation_runs_table.php. Notifications: queued + terminal DB notifications (initiator-only) — OperationRunQueued.php, OperationRunCompleted.php. Monitoring UI: Filament list/detail + Livewire pieces (DB-only render) — OperationRunResource.php and related pages/views. Start surfaces / Jobs: instrumented start surfaces, job middleware, and job updates to use canonical runs — multiple app/Jobs/* and app/Filament/* updates (see tests for full coverage). RBAC + Restore UX clarifications: RBAC group search is delegated-Graph-based and disabled without delegated token; Restore group mapping remains DB-only (directory cache) and helper text always visible — TenantResource.php, RestoreRunResource.php. Specs / Constitution: updated spec & quickstart and added one-line constitution guideline about Graph usage: spec.md quickstart.md constitution.md Tests & Verification Unit / Feature tests added/updated for run lifecycle, notifications, idempotency, and UI guards: see tests/Feature/* (notably OperationRunServiceTest, MonitoringOperationsTest, OperationRunNotificationTest, and various Filament feature tests). Full test run locally: ./vendor/bin/sail artisan test → 587 passed, 5 skipped. Migrations Adds create_operation_runs_table migration; run php artisan migrate in staging after review. Notes / Rationale Monitoring pages are explicitly DB-only at render time (no Graph calls). Start surfaces enqueue work only and return a “View run” link. Delegated Graph access is used only for explicit user actions (RBAC group search); restore mapping intentionally uses cached DB data only to avoid render-time Graph calls. Dispatch wrapper marks runs failed immediately if background dispatch throws synchronously to avoid misleading “queued” states. Upgrade / Deploy Considerations Run migrations: ./vendor/bin/sail artisan migrate. Background workers should be running to process queued jobs (recommended to monitor queue health during rollout). No secret or token persistence changes. PR checklist Tests updated/added for changed behavior Specs updated: 054-unify-runs-suitewide docs + quickstart Constitution note added (.specify) Pint formatting applied Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #63
121 lines
4.3 KiB
Markdown
121 lines
4.3 KiB
Markdown
# Feature Specification: [FEATURE NAME]
|
|
|
|
**Feature Branch**: `[###-feature-name]`
|
|
**Created**: [DATE]
|
|
**Status**: Draft
|
|
**Input**: User description: "$ARGUMENTS"
|
|
|
|
## User Scenarios & Testing *(mandatory)*
|
|
|
|
<!--
|
|
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
|
|
Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
|
|
you should still have a viable MVP (Minimum Viable Product) that delivers value.
|
|
|
|
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
|
|
Think of each story as a standalone slice of functionality that can be:
|
|
- Developed independently
|
|
- Tested independently
|
|
- Deployed independently
|
|
- Demonstrated to users independently
|
|
-->
|
|
|
|
### User Story 1 - [Brief Title] (Priority: P1)
|
|
|
|
[Describe this user journey in plain language]
|
|
|
|
**Why this priority**: [Explain the value and why it has this priority level]
|
|
|
|
**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
2. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
|
|
---
|
|
|
|
### User Story 2 - [Brief Title] (Priority: P2)
|
|
|
|
[Describe this user journey in plain language]
|
|
|
|
**Why this priority**: [Explain the value and why it has this priority level]
|
|
|
|
**Independent Test**: [Describe how this can be tested independently]
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
|
|
---
|
|
|
|
### User Story 3 - [Brief Title] (Priority: P3)
|
|
|
|
[Describe this user journey in plain language]
|
|
|
|
**Why this priority**: [Explain the value and why it has this priority level]
|
|
|
|
**Independent Test**: [Describe how this can be tested independently]
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** [initial state], **When** [action], **Then** [expected outcome]
|
|
|
|
---
|
|
|
|
[Add more user stories as needed, each with an assigned priority]
|
|
|
|
### Edge Cases
|
|
|
|
<!--
|
|
ACTION REQUIRED: The content in this section represents placeholders.
|
|
Fill them out with the right edge cases.
|
|
-->
|
|
|
|
- What happens when [boundary condition]?
|
|
- How does system handle [error scenario]?
|
|
|
|
## Requirements *(mandatory)*
|
|
|
|
**Constitution alignment (required):** If this feature introduces any Microsoft Graph calls, any write/change behavior,
|
|
or any long-running/queued/scheduled work, the spec MUST describe contract registry updates, safety gates
|
|
(preview/confirmation/audit), tenant isolation, run observability (`OperationRun` type/identity/visibility), and tests.
|
|
If security-relevant DB-only actions intentionally skip `OperationRun`, the spec MUST describe `AuditLog` entries.
|
|
|
|
<!--
|
|
ACTION REQUIRED: The content in this section represents placeholders.
|
|
Fill them out with the right functional requirements.
|
|
-->
|
|
|
|
### Functional Requirements
|
|
|
|
- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
|
|
- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]
|
|
- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
|
|
- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
|
|
- **FR-005**: System MUST [behavior, e.g., "log all security events"]
|
|
|
|
*Example of marking unclear requirements:*
|
|
|
|
- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
|
|
- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
|
|
|
|
### Key Entities *(include if feature involves data)*
|
|
|
|
- **[Entity 1]**: [What it represents, key attributes without implementation]
|
|
- **[Entity 2]**: [What it represents, relationships to other entities]
|
|
|
|
## Success Criteria *(mandatory)*
|
|
|
|
<!--
|
|
ACTION REQUIRED: Define measurable success criteria.
|
|
These must be technology-agnostic and measurable.
|
|
-->
|
|
|
|
### Measurable Outcomes
|
|
|
|
- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
|
|
- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
|
|
- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
|
|
- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]
|