ahmido bda1d90fc4 Spec 094: Assignment ops observability hardening (#113 )

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

2026-02-15 14:08:14 +00:00

1.8 KiB

Raw Blame History

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.

1.8 KiB Raw Blame History