ahmido/TenantAtlas
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity
9e435ea91f
TenantAtlas/specs/362-sync-capture-backup-operation-semantics/tasks.md
ahmido 548a37c888 feat: implement sync capture backup operation semantics (#433) 
Implemented sync capture backup operation semantics as requested.

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #433
2026-06-07 01:19:08 +00:00

26 KiB
Raw Blame History

Tasks: Spec 362 - Sync, Capture, and Backup Operation Semantics

Input: /Users/ahmeddarrazi/Documents/projects/wt-plattform/specs/362-sync-capture-backup-operation-semantics/spec.md, plan.md, and checklists/requirements.md
Prerequisites: spec.md and plan.md
Tests: REQUIRED (Pest). Keep proof bounded to Unit + Feature + one explicit Browser smoke.
Operations: Reuse current OperationRun lifecycle ownership. No new run status column, no new queue family, no new schema, and no destructive cleanup.
RBAC: Reuse current workspace-first OperationRun access plus existing inventory, baseline snapshot, and backup-set policies. No new capability strings and no cross-scope artifact resolution.
Shared Pattern Reuse: Reuse OperationRunService, OperationRun::reconciliation(), OperationRunLinks, ArtifactTruthPresenter, GovernanceRunDiagnosticSummaryBuilder, and the current operations/detail surfaces. Introduce only bounded selected-family adapters plus at most one small derived partial-success helper in ReconciliationResult.
Filament / Panel Guardrails: Filament remains v5 on Livewire v4. Provider registration stays in apps/platform/bootstrap/providers.php. No new panel, global-search change, or asset strategy is allowed.
Organization: Tasks are grouped by user story so inventory sync, baseline capture, backup schedule execution, and explicit unsupported-family handling remain independently reviewable.

Repo Baseline At Prep Time

  • Branch: 362-sync-capture-backup-operation-semantics
  • HEAD: 252cd451 feat: implement report evidence reconciliation (#432)
  • git status --short --branch before Spec 362 prep: clean on platform-dev; Spec Kit created this feature branch and copied the spec/plan templates
  • Merged adapter baseline: 840c9bd2 refactor: rename ManagedEnvironment context badge to Environment context (#431) and 252cd451 feat: implement report evidence reconciliation (#432) remain the immediate adapter-registry baseline
  • Relevant runtime surfaces:
    • apps/platform/app/Services/OperationRunService.php
    • apps/platform/app/Services/Operations/OperationLifecycleReconciler.php
    • apps/platform/app/Services/AdapterRunReconciler.php
    • apps/platform/app/Support/Operations/Reconciliation/OperationRunReconciliationRegistry.php
    • apps/platform/app/Support/Operations/Reconciliation/ReconciliationResult.php
    • apps/platform/app/Support/OperationCatalog.php
    • apps/platform/app/Support/OperationRunType.php
    • apps/platform/app/Support/OperationRunLinks.php
    • apps/platform/app/Support/OpsUx/GovernanceRunDiagnosticSummaryBuilder.php
    • apps/platform/app/Support/Ui/GovernanceArtifactTruth/ArtifactTruthPresenter.php
    • apps/platform/app/Services/Inventory/InventorySyncService.php
    • apps/platform/app/Support/Inventory/InventoryCoverage.php
    • apps/platform/app/Services/Baselines/BaselineCaptureService.php
    • apps/platform/app/Jobs/CaptureBaselineSnapshotJob.php
    • apps/platform/app/Services/BackupScheduling/BackupScheduleDispatcher.php
    • apps/platform/app/Jobs/RunBackupScheduleJob.php
    • apps/platform/app/Console/Commands/TenantpilotReconcileBackupScheduleOperationRuns.php
    • apps/platform/app/Models/OperationRun.php
    • apps/platform/app/Models/InventoryItem.php
    • apps/platform/app/Models/BaselineSnapshot.php
    • apps/platform/app/Models/BackupSet.php
    • apps/platform/app/Models/BackupItem.php
    • apps/platform/app/Filament/Pages/Monitoring/Operations.php
    • apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php
    • apps/platform/app/Filament/Pages/InventoryCoverage.php
    • apps/platform/app/Filament/Resources/InventoryItemResource.php
    • apps/platform/app/Filament/Resources/BaselineSnapshotResource.php
    • apps/platform/app/Filament/Resources/BackupSetResource.php
  • Completed-spec context only: Specs 358, 359, 360, and 361 are baseline context and must not be reopened during Spec 362 prep
  • Scope guardrail: policy.sync, backup_set.update, restore, review-compose, evidence snapshot, review-pack, and generic report families stay explicit context or defers only

Test Governance Checklist

  • Lane assignment is named and is the narrowest sufficient proof for the changed behavior.
  • New or changed tests stay in the smallest honest family, and the Browser addition remains explicit.
  • Shared helpers, factories, seeds, fixtures, and context defaults stay cheap by default; any widening is isolated or documented.
  • Planned validation commands cover the change without widening into unrelated lane cost.
  • The declared monitoring/detail surface profile is explicit.
  • Any material budget, baseline, trend, or escalation note is recorded in the active feature close-out.

Phase 1: Setup (Repo Truth Inventory)

Purpose: confirm the current registry baseline, the selected proof seams, and the explicit unsupported-family boundary before runtime edits begin.

  • T001 Re-read spec.md, plan.md, checklists/requirements.md, .specify/memory/constitution.md, docs/ai-coding-rules.md, docs/architecture-guidelines.md, docs/testing-guidelines.md, docs/security-guidelines.md, docs/filament-guidelines.md, and specs/358-operationrun-queue-truth-foundation/{spec,plan,tasks}.md plus specs/359-operationrun-reconciliation-adapter-framework-review-compose-adapter/{spec,plan,tasks}.md, specs/360-operationrun-canonical-cutover-cleanup/{spec,plan,tasks}.md, and specs/361-report-evidence-reconciliation/{spec,plan,tasks}.md together before touching runtime code.
  • T002 [P] Confirm the current adapter and write seams in apps/platform/app/Services/AdapterRunReconciler.php, apps/platform/app/Services/OperationRunService.php, apps/platform/app/Services/Operations/OperationLifecycleReconciler.php, apps/platform/app/Models/OperationRun.php, apps/platform/app/Support/Operations/Reconciliation/OperationRunReconciliationRegistry.php, and apps/platform/app/Support/Operations/Reconciliation/ReconciliationResult.php.
  • T003 [P] Confirm the current proof seams for inventory.sync, baseline.capture, and backup.schedule.execute in apps/platform/app/Services/Inventory/InventorySyncService.php, apps/platform/app/Support/Inventory/InventoryCoverage.php, apps/platform/app/Services/Baselines/BaselineCaptureService.php, apps/platform/app/Jobs/CaptureBaselineSnapshotJob.php, apps/platform/app/Services/BackupScheduling/BackupScheduleDispatcher.php, apps/platform/app/Jobs/RunBackupScheduleJob.php, apps/platform/app/Console/Commands/TenantpilotReconcileBackupScheduleOperationRuns.php, and the related Eloquent models.
  • T004 [P] Confirm the current canonical operation types and explicit unsupported-family boundary in apps/platform/app/Support/OperationCatalog.php, apps/platform/app/Support/OperationRunType.php, apps/platform/tests/Unit/Support/Operations/Reconciliation/Spec360CanonicalAdapterRegistryTest.php, and the current run-start paths for inventory.sync, baseline.capture, backup.schedule.execute, policy.sync, and backup_set.update.
  • T005 Confirm that no new schema, no new panel/provider path, no new asset registration, no new global-search contract, and no new provider-boundary work are required; if any of those are needed, stop and update the spec/plan instead of widening scope silently.

Phase 2: Foundational (Blocking Selected-Family Reconciliation Contract)

Purpose: settle the bounded partial-success and selected-family registry shape before story-specific adapter work begins.

Critical: no user-story runtime work should begin until this phase is complete.

  • T006 [P] Add failing Unit coverage in apps/platform/tests/Unit/Support/Operations/Reconciliation/Spec362SelectedFamilyRegistryResolutionTest.php for adapter resolution of inventory.sync, baseline.capture, backup.schedule.execute, and explicit unsupported handling for policy.sync and backup_set.update.
  • T007 [P] Add failing Unit coverage in apps/platform/tests/Unit/Support/Operations/Reconciliation/Spec362SelectedFamilyProofRulesTest.php for scope checks, complete-versus-partial proof, blocked-versus-partial precedence when usable output exists, blocked-versus-failed distinction, ambiguous candidate rejection, and fail-closed wrong-scope behavior.
  • T008 [P] Extend apps/platform/tests/Unit/Support/Operations/Reconciliation/Spec359ReconciliationResultTest.php or add a bounded Spec 362 companion file to prove partially_succeeded can be expressed through ReconciliationResult without introducing a new outcome family.
  • T009 Add InventorySyncReconciliationAdapter, BaselineCaptureReconciliationAdapter, and BackupScheduleExecutionReconciliationAdapter under apps/platform/app/Support/Operations/Reconciliation/ and register them in OperationRunReconciliationRegistry.
  • T010 Confirmed no additional partial-success helper is required because ReconciliationResult already expresses OperationRunOutcome::PartiallySucceeded cleanly.
  • T011 Update or add Unit coverage proving that selected-family adapters never mutate InventoryItem, BaselineSnapshot, BackupSet, or BackupItem, that all lifecycle writes still go through OperationRunService, that context.reconciliation keeps the canonical adapter or reason or previous-state or related-artifact shape, and that rerunning reconciliation remains idempotent.
  • T011A [P] Extend apps/platform/tests/Feature/MonitoringOperationsTest.php or add the smallest focused Spec 362 companion file so the changed Operations hub/detail render path stays DB-only and never invokes GraphClientInterface for selected-family reconciliation fallout.

Checkpoint: the registry is ready for selected sync/capture/backup extensions, partial success is bounded, and weaker families remain explicit.

Phase 3: User Story 1 - Trust inventory sync outcomes (Priority: P1)

Goal: inventory.sync runs can finalize truthfully from current coverage and failure proof instead of collapsing into stale ambiguity or false success.

Independent Test: run focused Unit and Feature coverage showing that a queued/running/stale inventory-sync run finalizes as succeeded only for full proof, partially succeeded only for usable incomplete proof, blocked only for meaningful precondition proof, and never succeeds from wrong-scope evidence.

Tests for User Story 1

  • T012 [P] [US1] Add apps/platform/tests/Feature/Operations/Spec362InventorySyncReconciliationTest.php covering full success, partial success, blocked, wrong-scope rejection, and ambiguous-proof rejection.
  • T013 [P] [US1] Extend apps/platform/tests/Feature/Inventory/InventorySyncServiceTest.php and apps/platform/tests/Feature/Inventory/RunInventorySyncJobTest.php only as needed to prove current-scope coverage semantics, recorded failure categories, and no drift in the existing inventory sync job path.
  • T014 [P] [US1] Extend monitoring/detail presentation coverage in apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php, apps/platform/tests/Feature/Filament/OperationRunEnterpriseDetailPageTest.php, or a focused Spec 362 companion file so reconciled inventory-sync outcomes stay calm, diagnostic-secondary, and scope-safe.

Implementation for User Story 1

  • T015 [US1] Implement InventorySyncReconciliationAdapter under apps/platform/app/Support/Operations/Reconciliation/ using existing context.inventory.coverage, InventoryCoverage, InventoryItem::last_seen_operation_run_id, and current failure-category truth.
  • T016 [US1] Reuse apps/platform/app/Services/Inventory/InventorySyncService.php and apps/platform/app/Services/OperationRunService.php without adding a new inventory lifecycle or persistence layer.
  • T017 [US1] Update the current operations/detail presentation seams in apps/platform/app/Support/OpsUx/GovernanceRunDiagnosticSummaryBuilder.php, apps/platform/app/Support/Ui/GovernanceArtifactTruth/ArtifactTruthPresenter.php, apps/platform/app/Filament/Pages/Monitoring/Operations.php, apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php, apps/platform/app/Filament/Pages/InventoryCoverage.php, and apps/platform/app/Filament/Resources/InventoryItemResource.php only as needed so reconciled inventory runs explain usable coverage without duplicate default-visible truth.

Checkpoint: inventory-sync runs reconcile safely from current coverage truth and never overclaim success for partial, wrong-scope, or ambiguous evidence.

Phase 4: User Story 2 - Trust baseline capture outcomes (Priority: P1)

Goal: baseline.capture runs can distinguish complete capture, gap-limited capture, and blocked capture from current snapshot and gap proof.

Independent Test: run focused Unit and Feature coverage showing that a queued/running/stale baseline-capture run finalizes as succeeded only for a current-scope gap-free snapshot, partially succeeded only for a usable snapshot with gaps or fallback proof, and blocked or failed when safe proof is absent.

Tests for User Story 2

  • T018 [P] [US2] Add apps/platform/tests/Feature/Operations/Spec362BaselineCaptureReconciliationTest.php covering gap-free success, partial success with capture gaps, blocked preconditions, and fail-closed no-snapshot or wrong-scope cases.
  • T019 [P] [US2] Extend apps/platform/tests/Feature/Baselines/BaselineCaptureTest.php, apps/platform/tests/Feature/Baselines/BaselineCaptureGapClassificationTest.php, and apps/platform/tests/Feature/Baselines/BaselineCaptureAmbiguousMatchGapTest.php only as needed to prove current gap truth and no drift in the existing capture path.
  • T020 [P] [US2] Extend operator-facing fallout coverage in apps/platform/tests/Feature/Filament/BaselineCaptureResultExplanationSurfaceTest.php, apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php, or a focused Spec 362 companion file so reconciled baseline outcomes stay calm, gap-aware, and diagnostic-secondary.

Implementation for User Story 2

  • T021 [US2] Implement BaselineCaptureReconciliationAdapter under apps/platform/app/Support/Operations/Reconciliation/ using existing baseline_snapshot_id, gap summaries, capture summary counts, and current baseline scope truth.
  • T022 [US2] Reuse apps/platform/app/Services/Baselines/BaselineCaptureService.php, apps/platform/app/Jobs/CaptureBaselineSnapshotJob.php, and apps/platform/app/Services/OperationRunService.php without adding a new baseline lifecycle or persistence layer.
  • T023 [US2] Update the current operations/detail presentation seams in apps/platform/app/Support/OpsUx/GovernanceRunDiagnosticSummaryBuilder.php, apps/platform/app/Support/Ui/GovernanceArtifactTruth/ArtifactTruthPresenter.php, apps/platform/app/Filament/Pages/Monitoring/Operations.php, apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php, apps/platform/app/Filament/Resources/BaselineSnapshotResource.php, and apps/platform/app/Filament/Resources/BaselineSnapshotResource/Pages/ViewBaselineSnapshot.php only as needed so reconciled baseline runs explain capture completeness without flattening partial and blocked states together.

Checkpoint: baseline-capture runs reconcile safely from current snapshot and gap truth and never overclaim fidelity when capture is incomplete.

Phase 5: User Story 3 - Trust backup schedule execution outcomes (Priority: P1)

Goal: backup.schedule.execute runs can distinguish complete backup, partial backup, and blocked backup from current backup-set proof instead of generic stale failure.

Independent Test: run focused Unit and Feature coverage showing that a queued/running/stale backup-schedule run finalizes as succeeded only for complete current-scope backup proof, partially succeeded only for usable incomplete backup proof, and blocked or failed when safe proof is absent.

Tests for User Story 3

  • T024 [P] [US3] Add apps/platform/tests/Feature/Operations/Spec362BackupScheduleExecutionReconciliationTest.php covering full success, partial success, blocked, wrong-scope rejection, and no-backup-set rejection.
  • T025 [P] [US3] Extend apps/platform/tests/Feature/BackupScheduling/RunBackupScheduleJobTest.php and apps/platform/tests/Feature/Console/ReconcileBackupScheduleOperationRunsCommandTest.php only as needed to prove backup summary-count truth, current backup-set linkage, and no drift in the existing backup scheduling path.
  • T026 [P] [US3] Extend operator-facing fallout coverage in apps/platform/tests/Feature/Filament/BackupSetEnterpriseDetailPageTest.php, apps/platform/tests/Feature/Filament/BackupSetRelatedNavigationTest.php, apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php, or a focused Spec 362 companion file so reconciled backup outcomes stay calm, link safely, and keep raw diagnostics secondary.

Implementation for User Story 3

  • T027 [US3] Implement BackupScheduleExecutionReconciliationAdapter under apps/platform/app/Support/Operations/Reconciliation/ using existing backup_schedule_id, backup_set_id, backup summary counts, and current backup-set scope truth.
  • T028 [US3] Reuse apps/platform/app/Services/BackupScheduling/BackupScheduleDispatcher.php, apps/platform/app/Jobs/RunBackupScheduleJob.php, apps/platform/app/Console/Commands/TenantpilotReconcileBackupScheduleOperationRuns.php, and apps/platform/app/Services/OperationRunService.php without adding a new backup lifecycle or persistence layer.
  • T029 [US3] Update the current operations/detail presentation seams in apps/platform/app/Support/OperationRunLinks.php, apps/platform/app/Support/OpsUx/GovernanceRunDiagnosticSummaryBuilder.php, apps/platform/app/Support/Ui/GovernanceArtifactTruth/ArtifactTruthPresenter.php, apps/platform/app/Filament/Pages/Monitoring/Operations.php, apps/platform/app/Filament/Pages/Operations/TenantlessOperationRunViewer.php, apps/platform/app/Filament/Resources/BackupSetResource.php, and apps/platform/app/Filament/Resources/BackupSetResource/Pages/ViewBackupSet.php only as needed so reconciled backup runs explain usable backup proof without exposing low-level storage detail by default.

Checkpoint: backup-schedule runs reconcile safely from current backup-set truth and never overclaim success when backup output is partial or ambiguous.

Phase 6: User Story 4 - Keep weaker sync and backup families honest (Priority: P2)

Goal: weaker or ambiguous families such as policy.sync and backup_set.update stay explicit and unsupported in this slice so the registry does not drift into heuristic success.

Independent Test: run focused Unit and Feature coverage showing that policy.sync and backup_set.update remain unresolved or diagnostic-first because Spec 362 keeps selected-family truth bounded.

Tests for User Story 4

  • T030 [P] [US4] Add focused Unit or Feature coverage in apps/platform/tests/Feature/Operations/Spec362UnsupportedSyncBackupFamiliesTest.php proving that policy.sync and backup_set.update remain outside the Spec 362 adapter registry and do not auto-succeed from adjacent inventory or backup artifacts.
  • T031 [P] [US4] Add or extend operations-detail coverage in apps/platform/tests/Feature/Operations/TenantlessOperationRunViewerTest.php or a focused Spec 362 file so unsupported sync/backup families remain attention-first, keep one dominant default next action, and do not expose raw/support evidence in the default-visible layer for ordinary operators.

Implementation for User Story 4

  • T032 [US4] Verify that policy.sync, backup_set.update, restore, review-compose, evidence snapshot, review-pack, and generic report families remain excluded from the Spec 362 selected-family registry path and record named follow-up candidates instead of widening this package.
  • T033 [US4] No generic sync/backup helper should be introduced; selected-family proof stays local to the new adapters and weaker families stay on existing operations diagnostics and current host-gated disclosure paths.
  • T034 [US4] Ensure unsupported-family wording on current operations surfaces stays calm, explicit, and fail-closed without implying that nearby inventory, snapshot, or backup artifacts completed a different run automatically.

Checkpoint: the feature improves truth where repo proof is strong and explicitly refuses false success where proof is weaker.

Phase 7: Polish & Validation

  • T035 [P] Refresh spec.md, plan.md, and checklists/requirements.md only if implementation proves a thinner touched-file boundary or requires a narrower explicit defer around policy.sync, backup_set.update, or any remaining Spec 360 prerequisite.
  • T036 [P] Run the primary in-scope Unit and Feature gate:
    • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Unit/Support/Operations/Reconciliation/Spec362SelectedFamilyRegistryResolutionTest.php tests/Unit/Support/Operations/Reconciliation/Spec362SelectedFamilyProofRulesTest.php tests/Unit/Support/Operations/Reconciliation/Spec359ReconciliationResultTest.php tests/Feature/Operations/Spec362*
  • T037 [P] Run the bounded contextual regressions:
    • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Feature/MonitoringOperationsTest.php tests/Feature/Inventory/InventorySyncServiceTest.php tests/Feature/Inventory/RunInventorySyncJobTest.php tests/Feature/Baselines/BaselineCaptureTest.php tests/Feature/Baselines/BaselineCaptureGapClassificationTest.php tests/Feature/Baselines/BaselineCaptureAmbiguousMatchGapTest.php tests/Feature/BackupScheduling/RunBackupScheduleJobTest.php tests/Feature/Console/ReconcileBackupScheduleOperationRunsCommandTest.php
  • T038 [P] Run the primary browser smoke and verify the changed Operations surfaces still show one dominant next action, keep duplicate visible decision truth out of the default layer, and keep deeper diagnostics behind explicit reveal paths:
    • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec362SyncCaptureBackupSemanticsSmokeTest.php
  • T039 [P] Run the bounded contextual browser smoke only if visible copy or related-link behavior changes on current host surfaces:
    • cd apps/platform && ./vendor/bin/sail php vendor/bin/pest tests/Browser/Spec360OperationRunCanonicalCutoverSmokeTest.php tests/Browser/Spec328OperationsHubProductizationSmokeTest.php tests/Browser/Spec177InventoryCoverageTruthSmokeTest.php
  • T040 [P] Run cd apps/platform && ./vendor/bin/sail bin pint --dirty --format agent.
  • T041 [P] Run git diff --check.
  • T042 [P] Record the final selected families reconciled, the explicit unsupported-family decision, validation results, no-migration status, no-asset status, and the final Guardrail / Smoke Coverage note in the active feature close-out.

Close-Out Notes

  • Supported selected families must end as exactly: inventory.sync, baseline.capture, and backup.schedule.execute.
  • Explicit unsupported-family decision must remain: policy.sync, backup_set.update, restore, review-compose, evidence snapshot, review-pack, and generic report families stay outside Spec 362 unless a later spec proves stronger causal truth.
  • No migration status should remain: no schema or persisted-truth changes are expected.
  • No asset / panel status should remain: no Filament panel/provider/global-search/asset changes are expected; Laravel 12 provider registration remains in apps/platform/bootstrap/providers.php, and Filament stays on v5 with Livewire v4.
  • Render-locality proof should remain explicit: changed Operations hub/detail behavior must keep the existing DB-only render guarantee, and any touched proof host surface must extend the smallest existing no-Graph render guard before merge.
  • Guardrail / Smoke Coverage should stay bounded to Unit + Feature + one Browser smoke over the existing Operations hub/detail family plus current proof/detail surfaces only when required by visible fallout.

Dependencies & Execution Order

Phase Dependencies

  • Setup (Phase 1): no dependencies
  • Foundational (Phase 2): depends on Setup and blocks all story work
  • US1 (Phase 3): depends on Foundational completion
  • US2 (Phase 4): depends on Foundational completion; can land after US1 or in parallel once shared proof rules settle
  • US3 (Phase 5): depends on Foundational completion; can land after US1 or US2 once the partial-success helper and selected-family registry shape are stable
  • US4 (Phase 6): depends on US1 through US3 because the unsupported-family boundary should be validated against the final in-scope adapter set
  • Polish (Phase 7): depends on all desired user stories

Parallel Opportunities

  • T002, T003, and T004 can run in parallel.
  • T006, T007, and T008 can run in parallel.
  • T012, T013, and T014 can run in parallel.
  • T018, T019, and T020 can run in parallel.
  • T024, T025, and T026 can run in parallel.
  • T030 and T031 can run in parallel.
  • T036 through T041 can run in parallel once implementation stabilizes, but the primary merge gate should be read out separately from contextual regressions.

Implementation Strategy

  1. Freeze the current registry and proof-model baseline first.
  2. Land the bounded partial-success and selected-family registry shape before family-specific runtime edits.
  3. Land inventory-sync reconciliation first because its proof path is the strongest current sync family.
  4. Land baseline-capture reconciliation second because snapshot-and-gap truth is already repo-real.
  5. Land backup-schedule reconciliation third because its proof path already exposes backup-set identity and summary counts.
  6. Finish by locking fail-closed behavior for weaker sync/backup families and recording any explicit defer.

Non-Goals / Must-Not-Do

  • NT001 Do not add a new OperationRun status column, boolean, or separate reconciliation table.
  • NT002 Do not add a new queue/job family, a generic sync/backup engine, or a second operator-center UI.
  • NT003 Do not mutate InventoryItem, BaselineSnapshot, BackupSet, or BackupItem from adapters.
  • NT004 Do not widen scope into policy.sync, backup_set.update, restore, review-compose, evidence snapshot, review-pack, or generic report semantics in this feature.
  • NT005 Do not add compatibility shims, new panel/provider registration, global-search behavior, or asset strategy only to preserve pre-production historical behavior.