ActionItem now carries optional targetPaths so plan.execute can use plan-carried targets instead of reconstructing execution intent from findings. This improves execution reliability and enables proper restore mappings for recovery items. - Add targetPaths field to ActionItem domain model - Update plan execution to prefer plan-carried targets with finding fallback - Expand safe cache path fragments for direct-trash execution - Add gate review documentation for ATL-211/212/215 - Bump protocol version to 0.3.0
3.0 KiB
3.0 KiB
Execution Credibility Gate Review
Gate
Smart Clean Execution Credibility
Review Date
2026-03-12
Scope Reviewed
ATL-211additional safe-target execution coverageATL-212structured executable targets through the worker pathATL-215execution credibility gate review
Readiness Checklist
- Required P0 tasks complete
- Docs updated
- Risks reviewed
- Open questions below threshold
- Next-stage inputs available
Evidence Reviewed
Docs/Execution/Execution-Chain-Audit-2026-03-09.mdDocs/Execution/Smart-Clean-Execution-Coverage-2026-03-09.mdPackages/AtlasInfrastructure/Tests/AtlasInfrastructureTests/AtlasInfrastructureTests.swiftPackages/AtlasProtocol/Tests/AtlasProtocolTests/AtlasProtocolTests.swiftPackages/AtlasApplication/Tests/AtlasApplicationTests/AtlasApplicationTests.swift
Automated Validation Summary
swift test --package-path Packages— passswift test --package-path Apps— pass
Gate Assessment
ATL-212 Structured Target Contract
- Smart Clean
ActionItempayloads now carry structuredtargetPaths. plan.executenow prefers plan-carried targets instead of reconstructing destructive intent from the snapshot alone.- Recovery items can now use restore mappings to preserve the real original path even when execution was driven by plan-carried targets.
ATL-211 Coverage Increment
- This slice keeps the previously shipped safe direct-trash subset and does not expand execution into
Library/Containers. - File-backed contract tests prove
scan -> execute -> rescanimprovement for:~/Library/Caches/*~/Library/pnpm/store/*
Truthfulness Check
- History summaries still derive from the actual worker task result.
- Smart Clean only records recovery entries when a real Trash move happened or a restore mapping exists.
- Unsupported or review-only targets remain fail-closed or skipped as review-only instead of being claimed as cleaned.
Remaining Limits
Library/Containerscleanup is still unsupported in the direct-trash path because the worker does not yet mirror the upstream protected-container filters.Group Containerscleanup is still unsupported in the direct-trash path.- Broader
Systemcleanup and aggregated dry-run-only findings still fail closed unless they resolve to the supported structured targets. - This change did not add a new packaged-app manual verification pass; the evidence here is test-backed.
Decision
Pass with Conditions
Conditions
- Release-facing copy must continue to distinguish supported vs unsupported Smart Clean paths.
- External release validation should still rerun manual packaged
scan -> execute -> rescanflows for the supported target classes.
Follow-up Actions
- Only add container cleanup support after the worker can enforce the same protected-container rules as the upstream cleanup runtime.
- Evaluate the next safe Smart Clean increment only if it preserves explicit restore semantics and fail-closed behavior.