Implemented OpenSpec and created and updated its artifacts
This commit is contained in:
53
openspec/specs/manage-time/spec.md
Normal file
53
openspec/specs/manage-time/spec.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# manage-time Specification
|
||||
|
||||
## Purpose
|
||||
|
||||
Let authorized users review and maintain weekly time entries with validated hours and explicit, traceable persistence.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Manage Time requires profile and session readiness
|
||||
Manage Time SHALL remain unavailable to `SALES_REP` users. For eligible users, its launcher SHALL remain disabled until SR session readiness, and data request entry points SHALL enforce the profile gate before loading time data.
|
||||
|
||||
#### Scenario: Restricted profile with a ready session
|
||||
- **WHEN** SR session preparation succeeds for a user with `SALES_REP`
|
||||
- **THEN** Manage Time remains hidden and opening it does not send its data requests
|
||||
|
||||
### Requirement: Week navigation preserves the user's work
|
||||
Manage Time SHALL restore its selected reference date, navigate in seven-day increments and retain local drafts while moving between weeks within the modal. Late responses for a different week or closed modal SHALL not replace active values.
|
||||
|
||||
#### Scenario: Navigate away and back
|
||||
- **WHEN** the user edits an unsaved week, navigates to another week and returns
|
||||
- **THEN** the earlier week's local edits remain available
|
||||
|
||||
### Requirement: Entry selections are dependent and searchable
|
||||
Service Request, Activity and Task Type selections SHALL support autocomplete. Activities SHALL correspond to the chosen SR, task types SHALL match Service or Non Service rows, and duplicate SR selection SHALL be rejected with row feedback.
|
||||
|
||||
#### Scenario: Duplicate SR
|
||||
- **WHEN** a user selects an SR already used by another row
|
||||
- **THEN** the previous selection is restored and the existing row is highlighted
|
||||
|
||||
### Requirement: Hours are validated before persistence
|
||||
Each entered daily hour value SHALL be numeric and within the inclusive range 0 through 24. The view SHALL show daily totals and reject invalid rows before any affected write.
|
||||
|
||||
#### Scenario: Invalid daily hours
|
||||
- **WHEN** a user attempts to save a row containing 25 hours for one day
|
||||
- **THEN** validation prevents that invalid time entry from being submitted
|
||||
|
||||
### Requirement: Save controls creation updates and deletions
|
||||
Save SHALL create new entries with POST, update changed persisted entries with PUT and apply queued persisted deletions with DELETE. Removing an unsaved row SHALL remain local. Writes SHALL use the required session and current-resource context.
|
||||
|
||||
#### Scenario: Persisted row is removed before Save
|
||||
- **WHEN** a user removes a persisted row without saving
|
||||
- **THEN** the deletion remains queued and no DELETE is sent yet
|
||||
|
||||
#### Scenario: Partial save failure
|
||||
- **WHEN** some entry operations succeed and another operation fails
|
||||
- **THEN** successful results remain reflected locally and unfinished work remains available for retry without duplicating confirmed writes
|
||||
|
||||
### Requirement: Loading and failures are local to the time view
|
||||
Manage Time SHALL display skeleton rows while loading and provide retry on data failure without discarding the user's current draft values.
|
||||
|
||||
#### Scenario: Week retrieval fails
|
||||
- **WHEN** the active week's request fails
|
||||
- **THEN** the modal exposes the failure and retry while protecting existing edits
|
||||
Reference in New Issue
Block a user