CleanMM/Docs/ROADMAP.md

# Roadmap

## Current Starting Point

- Date: `2026-03-12`
- Product state: `Frozen MVP complete`
- Validation state: `Internal beta passed with conditions on 2026-03-07`
- Immediate priorities:
  - turn `Apps` review-only evidence into verifiable and comparable uninstall evidence
  - expand `Smart Clean` safe coverage only on the next high-confidence roots
  - harden `Recovery` payload compatibility and restore evidence after execution boundaries stabilize
  - keep release-readiness work behind the product-path epics until signing materials exist
- Release-path blocker:
  - no Apple signing and notarization credentials are available on the current machine

## Roadmap Guardrails

- Keep scope inside the frozen MVP modules:
  - `Overview`
  - `Smart Clean`
  - `Apps`
  - `History`
  - `Recovery`
  - `Permissions`
  - `Settings`
- Do not pull `Storage treemap`, `Menu Bar`, or `Automation` into this roadmap.
- Respond to competitor pressure by deepening the frozen MVP flows rather than adding new surfaces for parity theater.
- Treat trust and recovery honesty as release-critical product work, not polish.
- Keep direct distribution as the only eventual release route.
- Do not plan around public beta dates until signing credentials exist.

## Competitive Strategy Overlay

- Primary breadth comparison pressure comes from `Mole` and `Tencent Lemon Cleaner`.
- Primary `Apps` comparison pressure comes from `Pearcleaner` and `Tencent Lemon Cleaner`.
- Atlas should compete as an `explainable, recovery-first Mac maintenance workspace`, not as a generic all-in-one cleaner.
- The roadmap response is:
  - preserve trust as the primary release gate
  - deepen the `Apps` module first where `Pearcleaner` and `Lemon` set expectations
  - then close the most visible `Smart Clean` safe-coverage gaps users compare against `Mole` and `Lemon`
  - harden `Recovery` only after execution boundaries and evidence models are stable
  - treat release readiness as the final convergence step because signing materials, not packaging mechanics, remain the public-release blocker
  - keep `Storage treemap`, `Menu Bar`, and `Automation` out of scope

## Active Milestones

### Milestone 1: Internal Beta Hardening

- Dates: `2026-03-16` to `2026-03-28`
- Goal: harden the current internal-beta build until user-visible execution and recovery claims are defensible.
- Focus:
  - remove or explicitly development-gate silent XPC fallback
  - show explicit failure states when real worker execution is unavailable
  - rerun bilingual manual QA on a clean machine
  - verify packaged first-launch behavior with a fresh state file
  - tighten README, in-app copy, and help content where recovery or execution is overstated
- Exit criteria:
  - internal beta checklist rerun against the latest packaged build
  - unsupported execution paths fail clearly instead of appearing successful
  - recovery wording matches the shipped restore behavior

### Milestone 2: Apps Evidence Execution

- Dates: `2026-03-31` to `2026-04-11`
- Goal: turn `Apps` review-only evidence from merely visible into verifiable, comparable, and recoverably consistent.
- Focus:
  - define the fixture app baseline for mainstream and developer-heavy uninstall scenarios
  - make preview, completion, and history reflect the same uninstall evidence model
  - define the restore-triggered app-footprint refresh strategy and stale-evidence handling
  - script the manual acceptance flow for uninstall evidence and restore verification
- Exit criteria:
  - supported fixture apps produce consistent evidence across preview, completion, and history
  - restore follows a defined footprint refresh path or shows explicit stale-evidence state
  - the `Apps` acceptance path is scriptable and repeatable

### Milestone 3: Smart Clean Safe Coverage Expansion

- Dates: `2026-04-14` to `2026-05-02`
- Goal: expand only the next batch of high-confidence safe cleanup roots and prove real side effects without widening into high-risk cleanup.
- Focus:
  - add the next safe roots outside app containers
  - stabilize the `review-only` vs `executable` boundary across scan, review, execute, completion, and history
  - strengthen the `scan -> execute -> rescan` evidence chain for the expanded safe roots
  - keep unsupported or high-risk paths explicitly non-executable
- Exit criteria:
  - newly supported safe roots show real post-execution rescan improvement
  - unsupported roots remain clearly marked as `review-only`
  - release-facing surfaces distinguish supported and unsupported execution scope without ambiguity

### Milestone 4: Recovery Payload Hardening

- Dates: `2026-05-05` to `2026-05-23`
- Goal: make recovery state structurally stable, backward-compatible, and historically trustworthy.
- Focus:
  - stabilize the recovery payload schema and versioning contract
  - add migration and compatibility handling for older workspace and history state files
  - deepen `History` detail evidence for restore payloads, conflicts, expiry, and partial restore outcomes
  - add regression coverage for conflict, expired payload, and partial-restore scenarios
- Exit criteria:
  - recovery payloads follow a stable versioned schema
  - older state files migrate cleanly or fail with explicit compatibility behavior
  - `History` detail can explain real restore evidence and degraded outcomes
  - regression coverage exists for the main restore edge cases

### Milestone 5: Release Readiness

- Dates: `2026-05-26` to `2026-06-13`
- Goal: turn the stabilized product path into a repeatable release candidate process, then switch to the signing chain when credentials exist.
- Focus:
  - make `full-acceptance` a routine gate on candidate builds
  - stabilize UI automation for trust-critical MVP flows
  - freeze packaging, install, and launch smoke checks as repeatable release scripts
  - switch from the pre-signing release chain to `Developer ID + notarization` once credentials become available
- Exit criteria:
  - `full-acceptance` runs routinely on candidate builds
  - trust-critical UI automation is stable enough for release gating
  - packaging, install, and launch smoke checks are repeatable
  - the signed chain either passes with credentials present or remains explicitly blocked only by missing credentials

## Conditional Release Branch

These milestones do not start until Milestone `5` is complete and Apple release credentials are available.

### Conditional Milestone A: Signed External Beta Candidate

- Trigger:
  - Milestones `1` through `5` are complete
  - `Developer ID Application` is available
  - `Developer ID Installer` is available
  - `ATLAS_NOTARY_PROFILE` is available
- Goal: produce a signed and notarized external beta candidate.
- Focus:
  - rerun the release scripts on the signed chain
  - validate signed `.app`, `.dmg`, and `.pkg` install paths on a clean machine
  - prepare external beta notes and known limitations
- Exit criteria:
  - signed and notarized artifacts install without bypass instructions
  - clean-machine install verification passes on the signed candidate

### Conditional Milestone B: External Beta Learn Loop

- Trigger:
  - Conditional Milestone A is complete
- Goal: run a small external beta only after the mainline product path is stable.
- Focus:
  - use a hardware-diverse trusted beta cohort
  - triage install, permission, execution, and restore regressions
  - close P0 issues before any GA candidate is named
- Exit criteria:
  - no external-beta P0 remains open
  - primary workflows are validated on more than one machine profile

### Conditional Milestone C: GA Candidate and Launch

- Trigger:
  - Conditional Milestone B is complete
- Goal: publish `v1.0` only after trust, recovery, and signed distribution all align.
- Focus:
  - rerun full acceptance and signed packaging on the GA candidate
  - freeze release notes, notices, acknowledgements, and checksums
  - validate launch candidate install and first-run flow on a clean machine
- Exit criteria:
  - no open P0 release blocker
  - signed packaging, install validation, and release docs are complete
  - `v1.0` artifacts are published

## Current Decision Rules

- Do not call the current workstream `public beta`.
- Do not claim broader cleanup coverage than the worker/helper path can prove.
- Do not claim physical recovery until file-backed restore is actually validated.
- Do not schedule a public release date before signing credentials exist.

## Not In This Roadmap

- `Storage treemap`
- `Menu Bar`
- `Automation`
- new non-MVP modules