40 lines
1.4 KiB
Markdown
40 lines
1.4 KiB
Markdown
# Phase 1 Design: Data Model (No Schema Changes)
|
|
|
|
This feature does not introduce schema changes. It enforces consistent usage of existing entities.
|
|
|
|
## Entity: OperationRun (`operation_runs`)
|
|
|
|
**Ownership/scoping**:
|
|
|
|
- Tenant-scoped operational artifact.
|
|
- Initiator user is optional (system/scheduled runs).
|
|
|
|
**Key fields (existing)**:
|
|
|
|
- `id`
|
|
- `workspace_id` / `tenant_id` (scoping)
|
|
- `user_id` (initiator; nullable)
|
|
- `type` (operation type string)
|
|
- `status` (`queued`/`running`/`completed`)
|
|
- `outcome` (terminal outcome; nullable until completed)
|
|
- `started_at`, `completed_at`
|
|
- `summary_counts` (JSON/array of numeric-only whitelisted keys)
|
|
- `failure_summary` (sanitized bounded array)
|
|
- `context` (additional metadata; mutable)
|
|
|
|
**Invariants enforced by this feature**:
|
|
|
|
- All transitions of `status` and `outcome` happen through `OperationRunService::updateRun()`.
|
|
- The only operation-related DB notification is the terminal `OperationRunCompleted`, emitted when transitioning into `completed` and only when `user_id` exists.
|
|
|
|
## Entity: Database Notifications (`notifications`)
|
|
|
|
**Ownership/scoping**:
|
|
|
|
- User-scoped records (`notifiable_type=User`), used for persistent notification audit.
|
|
|
|
**Invariants enforced by this feature**:
|
|
|
|
- No queued/running state notifications are persisted.
|
|
- Exactly one terminal operation completion notification is persisted per OperationRun + initiator.
|