TenantAtlas/specs/367-operationrun-actionability-system/repo-truth-map.md
ahmido 564da05096 feat: implement operation run actionability system (#439)
This PR introduces the Operation Run Actionability System.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #439
2026-06-08 13:34:25 +00:00

4.7 KiB

OperationRun Actionability Repo Truth Map

Date: 2026-06-08 Branch: 367-operationrun-actionability-system

Scope

Spec 367 adds read-time OperationRun actionability. It does not add persistence, migrations, Graph calls, queues, scheduler work, storage changes, Filament assets, panel providers, global search, or destructive actions.

Operation Policy Inventory

The actionability registry covers all known canonical types from OperationCatalog::canonicalInventory(). Aliases resolve through OperationCatalog::canonicalCode() and OperationCatalog::rawValuesForCanonical().

Provider connection current-state policy:

  • provider.connection.check

Repeatable later-success policy:

  • inventory.sync
  • policy.sync
  • policy.snapshot
  • policy.export
  • directory.groups.sync
  • directory.role_definitions.sync
  • compliance.snapshot
  • permission.posture.check
  • entra.admin_roles.scan
  • rbac.health_check
  • tenant.sync
  • assignments.fetch
  • alerts.evaluate
  • alerts.deliver
  • ops.reconcile_adapter_runs

Artifact-or-later-success policy:

  • baseline.capture
  • baseline.compare
  • tenant.evidence.snapshot.generate
  • environment.review.compose
  • environment.review_pack.generate
  • backup_set.update
  • backup.schedule.execute
  • backup.schedule.retention

Manual-review policy:

  • policy.delete
  • policy.restore
  • backup_set.archive
  • backup_set.restore
  • backup_set.delete
  • backup.schedule.purge
  • restore.execute
  • promotion.execute
  • assignments.restore
  • restore_run.delete
  • restore_run.restore
  • restore_run.force_delete
  • policy_version.prune
  • policy_version.restore
  • policy_version.force_delete

Unknown operation types fail closed as requires_manual_review.

Current-State Proof

Terminal problem gate:

  • Only completed runs with blocked, partially_succeeded, or failed outcomes, or lifecycle-reconciled terminal rows, are eligible for current follow-up.
  • Completed succeeded rows are not terminal problems, even when they carry reconciliation metadata.

Later success proof:

  • Must be a later completed successful OperationRun.
  • Must match workspace and managed environment.
  • Must match the policy family's context keys where either side has a value, such as provider_connection_id, provider, selection_hash, baseline_profile_id, backup_set_id, or backup_schedule_id.

Provider connection proof:

  • Uses the same provider_connection_id from OperationRun context.
  • Requires the ProviderConnection to match workspace and managed environment.
  • Requires is_enabled = true, consent_status = granted, and verification_status = healthy.

Artifact proof:

  • baseline.capture can resolve through a same-workspace complete BaselineSnapshot.
  • tenant.evidence.snapshot.generate can resolve through a same-scope active and complete EvidenceSnapshot.
  • environment.review.compose can resolve through a same-scope EnvironmentReview.
  • environment.review_pack.generate can resolve through a same-scope ready ReviewPack.
  • backup_set.update, backup.schedule.execute, and backup.schedule.retention can resolve through a same-scope completed BackupSet.

All evaluation is read-only and database-backed.

Consumer Map

Actionability-backed current follow-up:

  • OperationRun::currentTerminalFollowUp()
  • OperationRun::dashboardNeedsFollowUp()
  • OperationRun::requiresOperatorReview() for terminal follow-up rows
  • NeedsAttention
  • Operations current terminal follow-up tab and blocked stats
  • GovernanceInboxSectionBuilder operation follow-up section
  • WorkspaceOverviewBuilder operation follow-up counts
  • OperationUxPresenter decision truth, labels, notes, and actionability payload
  • OperationRunActionEligibility

Active-run only behavior:

  • ActiveRuns::shellVisibleQueryForTenantId() no longer treats terminal follow-up as active progress.

Remaining historical or compatibility usages:

  • terminalFollowUp() remains the historical terminal-candidate scope used internally by OperationRunActionabilityResolver.
  • dashboardNeedsFollowUp() remains as the compatibility entry point, now backed by current actionability.
  • problemClass() remains for tab routing, historical labeling, detail display, and active stale classification.
  • requiresDashboardFollowUp() remains a compatibility wrapper around requiresOperatorReview().
  • OperationRunResource, tenantless run detail, dashboard summary labels, and governance inbox entry presentation may still display historical problem class alongside the derived actionability result.

No Graph Boundary

Changed actionability and UI paths do not reference GraphClientInterface or call graph(). Current-state checks rely on local ProviderConnection, OperationRun, and artifact records.