ahmido
bda1d90fc4
Implements spec 094 (assignment fetch/restore observability hardening): - Adds OperationRun tracking for assignment fetch (during backup) and assignment restore (during restore execution) - Normalizes failure codes/reason_code and sanitizes failure messages - Ensures exactly one audit log entry per assignment restore execution - Enforces correct guard/membership vs capability semantics on affected admin surfaces - Switches assignment Graph services to depend on GraphClientInterface Also includes Postgres-only FK defense-in-depth check and a discoverable `composer test:pgsql` runner (scoped to the FK constraint test). Tests: - `vendor/bin/sail artisan test --compact` (passed) - `vendor/bin/sail composer test:pgsql` (passed) Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #113
51 lines
1.8 KiB
Markdown
51 lines
1.8 KiB
Markdown
# Data Model — 094 Assignment Operations Observability Hardening
|
|
|
|
This feature introduces **no new entities**. It strengthens how existing operational artifacts are created, deduplicated, and displayed.
|
|
|
|
## Entities (existing)
|
|
|
|
### OperationRun
|
|
|
|
Represents a single observable operation for Monitoring.
|
|
|
|
- Ownership:
|
|
- `workspace_id` required.
|
|
- `tenant_id` present for tenant-bound runs.
|
|
- Key fields:
|
|
- `type`: operation type identifier (string).
|
|
- `status`: queued/running/completed.
|
|
- `outcome`: pending/succeeded/failed/etc.
|
|
- `run_identity_hash`: stable identity used for active-run dedupe.
|
|
- `context`: structured details for Monitoring (inputs, progress, counters).
|
|
- `failures`: array of failure items with stable `code`, normalized `reason_code`, and sanitized `message`.
|
|
- Counter-like fields may be stored in `context` depending on existing conventions.
|
|
|
|
### AuditLog
|
|
|
|
Immutable audit record for security/ops-relevant mutations.
|
|
|
|
- Scope invariant: if `tenant_id` is present, `workspace_id` must also be present.
|
|
- This spec requires exactly one audit entry per assignment restore execution.
|
|
|
|
### RestoreRun
|
|
|
|
Represents a restore execution request and its lifecycle. Assignment restores are performed under an existing restore run.
|
|
|
|
### BackupItem
|
|
|
|
Represents an item within a backup set; assignment fetch/enrichment is performed for a specific backup item.
|
|
|
|
## Relationships (conceptual)
|
|
|
|
- One tenant has many operation runs.
|
|
- One restore run should be associated with one or more operation runs depending on orchestration; this spec requires that assignment restore execution is observable via at least one operation run.
|
|
- One backup item can have a related fetch/enrichment operation run.
|
|
|
|
## State transitions
|
|
|
|
### OperationRun lifecycle
|
|
|
|
- `queued` → `running` → `completed`
|
|
- Outcome set on completion to indicate success or failure.
|
|
|