CleanMM/Docs/Execution/Selective-Parity-Week-2026-03-23.md

Selective Parity Week — 2026-03-23

Context

Atlas now has a documented competitive strategy:

• keep MVP frozen
• preserve trust as the primary moat
• selectively close the most visible comparison gaps against Mole, Tencent Lemon Cleaner, and Pearcleaner

This week plan turns that strategy into the next development-ready execution window.

Related docs:

• Open-Source-Competitor-Research-2026-03-21.md
• Competitive-Strategy-Plan-2026-03-21.md
• ROADMAP.md

Planned Window

• 2026-03-23 to 2026-03-27

Goal

Prepare Atlas's next coding phase with a strict mainline order so development starts on the highest-pressure competitive surfaces first and does not drift into premature release work:

• EPIC-A Apps evidence execution against Pearcleaner and Lemon
• EPIC-B Smart Clean safe coverage expansion against Mole and Lemon
• EPIC-C Recovery payload hardening
• EPIC-D release readiness only after the product-path epics stabilize

Scope

Stay inside frozen MVP:

• Overview
• Smart Clean
• Apps
• History
• Recovery
• Permissions
• Settings

Do not expand into:

• Storage treemap
• Menu Bar
• Automation
• duplicate-file or similar-photo cleanup as new Atlas modules
• privacy-cleaning as a new standalone module

Sequencing Rule

Execute the next mainline epics in this order only:

1. EPIC-A Apps Evidence Execution
2. EPIC-B Smart Clean Safe Coverage Expansion
3. EPIC-C Recovery Payload Hardening
4. EPIC-D Release Readiness

Why this order:

• the clearest competitive comparison pressure is already concentrated in Apps and Smart Clean
• the release chain is mostly working in pre-signing form
• public release remains blocked by missing signing materials, not by packaging mechanics

Must Deliver

• A concrete fixture-backed baseline for EPIC-A uninstall evidence work
• One implementation-ready plan for the first Apps evidence coding slice
• A bounded target list for the next Smart Clean safe roots after Apps
• Updated acceptance criteria for Apps, Smart Clean, and Recovery
• Updated release-facing beta checklist so release work stays downstream of the product-path epics

Backlog Mapping

• ATL-251 Define the fixture app baseline for mainstream and developer-heavy uninstall scenarios
• ATL-252 Make Apps preview, completion, and history render the same uninstall evidence model end to end
• ATL-253 Define the restore-triggered app-footprint refresh policy and stale-evidence behavior after recovery
• ATL-254 Script the manual acceptance flow for uninstall evidence, restore, and post-restore refresh verification
• ATL-256 Define the next batch of high-confidence safe roots outside app containers and freeze the no-go boundaries
• ATL-257 Stabilize review-only vs executable boundary metadata and UI cues across scan, review, execute, completion, and history
• ATL-261 Freeze the recovery payload schema, versioning rules, and compatibility contract
• ATL-266 Make full-acceptance a routine gate on the candidate build instead of a one-off release exercise

Day Plan

• Day 1
  • freeze the EPIC-A -> EPIC-D execution order
  • finalize the fixture app baseline and non-go boundaries for the first Apps slice
• Day 2
  • define the cross-surface uninstall evidence model for preview, completion, and history
  • confirm restore-refresh expectations and acceptance criteria for Apps
• Day 3
  • write the detailed implementation plan for the first Apps coding slice
  • identify likely file-touch map and contract-test map
• Day 4
  • define the next Smart Clean safe roots and the review-only vs executable boundary rules
  • align roadmap, risks, and acceptance docs with the ordered epic sequence
• Day 5
  • hold an internal doc gate for development readiness
  • confirm the next coding session can begin with EPIC-A and without another sequencing pass

Owner Tasks

• Product Agent
  • keep parity work bounded to visible comparison pressure only
  • reject backlog inflation that does not strengthen the frozen MVP
• UX Agent
  • define visible trust cues for supported, unsupported, and review-only actions
  • keep Atlas's UI difference legible against broader cleaner tools
• Mac App Agent
  • identify concrete UI surfaces that must change in Smart Clean, Apps, History, and completion states
• Core Agent
  • define the preview taxonomy and structured evidence that the UI can actually render
• System Agent
  • define which additional safe cleanup classes are realistic next targets for Smart Clean
• QA Agent
  • define the fixture set, comparison scenarios, and contract-style checks
• Docs Agent
  • keep strategy, acceptance, roadmap, and release-check documents aligned

Validation Plan

Planning Validation

• every new task maps to existing MVP surfaces
• every new acceptance criterion is testable
• every parity goal has an explicit competitor reference and an explicit Atlas non-goal

Readiness Validation

• at least one implementation-ready plan exists for the next coding slice
• acceptance matrix and beta checklist reflect the new competitive gates
• no document implies that Atlas is reopening deferred scope

Exit Criteria

• selective parity work is expressed as tasks, acceptance, and validation rather than just strategy prose
• Smart Clean and Apps both have explicit competitor-driven targets
• next coding session can start on EPIC-A without another planning pass

Known Blockers

• signed public beta remains blocked by missing Apple release credentials
• Smart Clean breadth still has to stay subordinate to execution honesty
• Apps depth work must remain bounded by what Atlas can safely prove and recover
• release readiness still cannot close the public-distribution gap until Apple signing materials exist