fix: harden internal beta execution trust
This commit is contained in:
zhukang
@@ -54,6 +54,7 @@
|
||||
|
||||
- Core frozen MVP workflows are complete end to end.
|
||||
- Recovery-first behavior is visible in both Smart Clean and Apps flows.
|
||||
- Physical on-disk restore is currently limited to recovery items that carry a supported restore path; older or unstructured records may still be model-only restore.
|
||||
- Settings and permission refresh flows are functional.
|
||||
- The app now defaults to `简体中文` and supports switching to `English` through persisted settings.
|
||||
|
||||
@@ -85,6 +86,7 @@
|
||||
## Conditions
|
||||
|
||||
- Internal beta / trusted-user beta can proceed with the current ad hoc-signed local artifacts.
|
||||
- Recovery and execution copy must stay explicit about supported restore paths and unsupported cleanup targets during internal beta.
|
||||
- Public beta or broad external distribution must wait until signing and notarization credentials are available and the release packaging path is re-run.
|
||||
|
||||
## Follow-up Actions
|
||||
|
||||
@@ -54,7 +54,7 @@
|
||||
|
||||
## Current Blockers
|
||||
|
||||
- `Smart Clean` execute now supports a real Trash-based path for structured safe targets, and those targets can be physically restored. Full disk-backed coverage is still incomplete, and unsupported targets fail closed. See `Docs/Execution/Execution-Chain-Audit-2026-03-09.md`.
|
||||
- `Smart Clean` execute now supports a real Trash-based path for structured safe targets, and those targets can be physically restored when recovery mappings are present. Full disk-backed coverage is still incomplete, and unsupported targets fail closed. See `Docs/Execution/Execution-Chain-Audit-2026-03-09.md`.
|
||||
- Silent fallback from XPC to the scaffold worker can mask execution-path failures in user-facing flows. See `Docs/Execution/Execution-Chain-Audit-2026-03-09.md`.
|
||||
- Public signed distribution is still blocked by missing Apple release credentials:
|
||||
- `Developer ID Application`
|
||||
|
||||
370
Docs/Execution/Implementation-Plan-ATL-201-202-205-2026-03-12.md
Normal file
370
Docs/Execution/Implementation-Plan-ATL-201-202-205-2026-03-12.md
Normal file
@@ -0,0 +1,370 @@
|
||||
# ATL-201 / ATL-202 / ATL-205 Implementation Plan
|
||||
|
||||
> **For Codex:** Execute this plan task-by-task. Keep changes small, verify each layer narrowly first, and commit frequently.
|
||||
|
||||
**Goal:** Remove release-facing silent scaffold fallback, expose explicit execution-unavailable failures in the app UI, and narrow bilingual execution/recovery copy so Atlas only claims behavior it can actually prove today.
|
||||
|
||||
**Architecture:** Keep the worker fallback capability available only as an explicit development override, but make the default app path fail closed. Surface worker rejection reasons through the application layer as user-facing localized errors, then render those errors in `Smart Clean` as a danger-state callout instead of a quiet summary string. Tighten copy in the app and release-facing docs so “recoverable” and “restore” only describe the currently shipped behavior.
|
||||
|
||||
**Tech Stack:** Swift 6, SwiftUI, Swift Package Manager tests, package-scoped localization resources, Markdown docs.
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Lock Release-Facing Worker Fallback Behind Explicit Development Mode
|
||||
|
||||
**Files:**
|
||||
- Modify: `Apps/AtlasApp/Sources/AtlasApp/AtlasAppModel.swift`
|
||||
- Modify: `Packages/AtlasInfrastructure/Sources/AtlasInfrastructure/AtlasXPCTransport.swift`
|
||||
- Test: `Packages/AtlasInfrastructure/Tests/AtlasInfrastructureTests/AtlasXPCTransportTests.swift`
|
||||
- Test: `Apps/AtlasApp/Tests/AtlasAppTests/AtlasAppModelTests.swift`
|
||||
|
||||
**Step 1: Write the failing transport tests**
|
||||
|
||||
Add tests in `Packages/AtlasInfrastructure/Tests/AtlasInfrastructureTests/AtlasXPCTransportTests.swift` that cover:
|
||||
|
||||
- release/default mode does **not** fall back when XPC rejects `executionUnavailable`
|
||||
- explicit development mode still can fall back when `allowFallback == true`
|
||||
|
||||
Use the existing rejected-result fixture style:
|
||||
|
||||
```swift
|
||||
let rejected = AtlasWorkerCommandResult(
|
||||
request: request,
|
||||
response: AtlasResponseEnvelope(
|
||||
requestID: request.id,
|
||||
response: .rejected(code: .executionUnavailable, reason: "simulated packaged worker failure")
|
||||
),
|
||||
events: [],
|
||||
snapshot: AtlasScaffoldWorkspace.snapshot(),
|
||||
previewPlan: nil
|
||||
)
|
||||
```
|
||||
|
||||
**Step 2: Run the transport tests to verify the current fallback behavior**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages --filter AtlasXPCTransportTests
|
||||
```
|
||||
|
||||
Expected:
|
||||
|
||||
- one new test fails because the current app-facing setup still allows fallback when XPC rejects `executionUnavailable`
|
||||
|
||||
**Step 3: Make fallback opt-in for development only**
|
||||
|
||||
In `Packages/AtlasInfrastructure/Sources/AtlasInfrastructure/AtlasXPCTransport.swift` and `Apps/AtlasApp/Sources/AtlasApp/AtlasAppModel.swift`:
|
||||
|
||||
- keep `AtlasPreferredWorkerService` capable of fallback for explicit dev usage
|
||||
- stop hardcoding `allowFallback: true` in `AtlasAppModel`
|
||||
- derive fallback permission from an explicit development-only env path, for example:
|
||||
|
||||
```swift
|
||||
let allowScaffoldFallback = ProcessInfo.processInfo.environment["ATLAS_ALLOW_SCAFFOLD_FALLBACK"] == "1"
|
||||
```
|
||||
|
||||
- pass that value into `AtlasPreferredWorkerService(...)`
|
||||
|
||||
The key result is:
|
||||
|
||||
- installed/release-facing app path fails closed by default
|
||||
- developers can still opt in locally with an env var
|
||||
|
||||
**Step 4: Add an app-model test for the default worker policy**
|
||||
|
||||
In `Apps/AtlasApp/Tests/AtlasAppTests/AtlasAppModelTests.swift`, add a focused test around a worker rejection path using an injected fake worker or a small helper constructor so the app model no longer assumes fallback-enabled behavior in default/release configuration.
|
||||
|
||||
Target behavior:
|
||||
|
||||
```swift
|
||||
XCTAssertFalse(model.canExecuteCurrentSmartCleanPlan)
|
||||
XCTAssertTrue(model.latestScanSummary.contains("unavailable"))
|
||||
```
|
||||
|
||||
**Step 5: Run tests and verify**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages --filter AtlasXPCTransportTests
|
||||
swift test --package-path Apps --filter AtlasAppModelTests
|
||||
```
|
||||
|
||||
Expected:
|
||||
|
||||
- transport tests pass
|
||||
- app-model tests still pass with the new fail-closed default
|
||||
|
||||
**Step 6: Commit**
|
||||
|
||||
```bash
|
||||
git add Packages/AtlasInfrastructure/Sources/AtlasInfrastructure/AtlasXPCTransport.swift Apps/AtlasApp/Sources/AtlasApp/AtlasAppModel.swift Packages/AtlasInfrastructure/Tests/AtlasInfrastructureTests/AtlasXPCTransportTests.swift Apps/AtlasApp/Tests/AtlasAppTests/AtlasAppModelTests.swift
|
||||
git commit -m "fix: gate scaffold fallback behind dev mode"
|
||||
```
|
||||
|
||||
### Task 2: Surface Explicit Execution-Unavailable Failure States in Smart Clean
|
||||
|
||||
**Files:**
|
||||
- Modify: `Packages/AtlasApplication/Sources/AtlasApplication/AtlasApplication.swift`
|
||||
- Modify: `Packages/AtlasDomain/Sources/AtlasDomain/Resources/en.lproj/Localizable.strings`
|
||||
- Modify: `Packages/AtlasDomain/Sources/AtlasDomain/Resources/zh-Hans.lproj/Localizable.strings`
|
||||
- Modify: `Apps/AtlasApp/Sources/AtlasApp/AtlasAppModel.swift`
|
||||
- Modify: `Apps/AtlasApp/Sources/AtlasApp/AppShellView.swift`
|
||||
- Modify: `Packages/AtlasFeaturesSmartClean/Sources/AtlasFeaturesSmartClean/SmartCleanFeatureView.swift`
|
||||
- Test: `Packages/AtlasApplication/Tests/AtlasApplicationTests/AtlasApplicationTests.swift`
|
||||
- Test: `Apps/AtlasApp/Tests/AtlasAppTests/AtlasAppModelTests.swift`
|
||||
|
||||
**Step 1: Write the failing application-layer tests**
|
||||
|
||||
Add tests in `Packages/AtlasApplication/Tests/AtlasApplicationTests/AtlasApplicationTests.swift` for:
|
||||
|
||||
- `executionUnavailable` rejection maps to a user-facing localized error
|
||||
- `helperUnavailable` rejection maps to a user-facing localized error
|
||||
|
||||
Use the existing `FakeWorker` and a rejected response:
|
||||
|
||||
```swift
|
||||
let result = AtlasWorkerCommandResult(
|
||||
request: request,
|
||||
response: AtlasResponseEnvelope(
|
||||
requestID: request.id,
|
||||
response: .rejected(code: .executionUnavailable, reason: "XPC worker offline")
|
||||
),
|
||||
events: [],
|
||||
snapshot: AtlasScaffoldWorkspace.snapshot(),
|
||||
previewPlan: nil
|
||||
)
|
||||
```
|
||||
|
||||
Assert on `error.localizedDescription`.
|
||||
|
||||
**Step 2: Run the application tests to verify they fail**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages --filter AtlasApplicationTests
|
||||
```
|
||||
|
||||
Expected:
|
||||
|
||||
- new rejection-mapping tests fail because `AtlasWorkspaceControllerError` still uses the generic `application.error.workerRejected`
|
||||
|
||||
**Step 3: Add code-specific user-facing error strings**
|
||||
|
||||
In `Packages/AtlasApplication/Sources/AtlasApplication/AtlasApplication.swift`, replace the one-size-fits-all rejection mapping with explicit cases:
|
||||
|
||||
```swift
|
||||
case let .rejected(code, reason):
|
||||
switch code {
|
||||
case .executionUnavailable:
|
||||
return AtlasL10n.string("application.error.executionUnavailable", reason)
|
||||
case .helperUnavailable:
|
||||
return AtlasL10n.string("application.error.helperUnavailable", reason)
|
||||
default:
|
||||
return AtlasL10n.string("application.error.workerRejected", code.rawValue, reason)
|
||||
}
|
||||
```
|
||||
|
||||
Add matching bilingual keys in both `.strings` files.
|
||||
|
||||
**Step 4: Write the failing app-model/UI-state tests**
|
||||
|
||||
In `Apps/AtlasApp/Tests/AtlasAppTests/AtlasAppModelTests.swift`, add tests that verify:
|
||||
|
||||
- executing a plan with `executionUnavailable` leaves the plan non-busy
|
||||
- the model stores an explicit Smart Clean execution issue
|
||||
- the summary and/or issue text is specific, not a silent generic fallback success
|
||||
|
||||
Introduce a small fake worker actor in the test file if needed:
|
||||
|
||||
```swift
|
||||
private actor RejectingWorker: AtlasWorkerServing {
|
||||
func submit(_ request: AtlasRequestEnvelope) async throws -> AtlasWorkerCommandResult { ... }
|
||||
}
|
||||
```
|
||||
|
||||
**Step 5: Implement explicit Smart Clean failure state**
|
||||
|
||||
In `Apps/AtlasApp/Sources/AtlasApp/AtlasAppModel.swift`:
|
||||
|
||||
- add a dedicated published property such as:
|
||||
|
||||
```swift
|
||||
@Published private(set) var smartCleanExecutionIssue: String?
|
||||
```
|
||||
|
||||
- clear it before a new scan / preview / execute attempt
|
||||
- set it when `executeCurrentPlan()` catches `executionUnavailable` or `helperUnavailable`
|
||||
|
||||
In `Apps/AtlasApp/Sources/AtlasApp/AppShellView.swift`, pass the new issue through to `SmartCleanFeatureView`.
|
||||
|
||||
In `Packages/AtlasFeaturesSmartClean/Sources/AtlasFeaturesSmartClean/SmartCleanFeatureView.swift`:
|
||||
|
||||
- add an optional `executionIssue: String?`
|
||||
- render a danger-tone callout or status state when this value exists
|
||||
- prefer this explicit issue over a normal “ready” or cached-plan state
|
||||
|
||||
The UI target is:
|
||||
|
||||
- a failed real execution attempt is visually obvious
|
||||
- the user sees “unavailable” or “helper unavailable”, not just a stale summary string
|
||||
|
||||
**Step 6: Run tests and verify**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages --filter AtlasApplicationTests
|
||||
swift test --package-path Apps --filter AtlasAppModelTests
|
||||
```
|
||||
|
||||
Expected:
|
||||
|
||||
- rejection mapping tests pass
|
||||
- app-model tests show explicit failure-state behavior
|
||||
|
||||
**Step 7: Commit**
|
||||
|
||||
```bash
|
||||
git add Packages/AtlasApplication/Sources/AtlasApplication/AtlasApplication.swift Packages/AtlasDomain/Sources/AtlasDomain/Resources/en.lproj/Localizable.strings Packages/AtlasDomain/Sources/AtlasDomain/Resources/zh-Hans.lproj/Localizable.strings Apps/AtlasApp/Sources/AtlasApp/AtlasAppModel.swift Apps/AtlasApp/Sources/AtlasApp/AppShellView.swift Packages/AtlasFeaturesSmartClean/Sources/AtlasFeaturesSmartClean/SmartCleanFeatureView.swift Packages/AtlasApplication/Tests/AtlasApplicationTests/AtlasApplicationTests.swift Apps/AtlasApp/Tests/AtlasAppTests/AtlasAppModelTests.swift
|
||||
git commit -m "fix: expose explicit smart clean execution failures"
|
||||
```
|
||||
|
||||
### Task 3: Narrow Bilingual Execution and Recovery Copy to Shipped Behavior
|
||||
|
||||
**Files:**
|
||||
- Modify: `Packages/AtlasDomain/Sources/AtlasDomain/Resources/en.lproj/Localizable.strings`
|
||||
- Modify: `Packages/AtlasDomain/Sources/AtlasDomain/Resources/zh-Hans.lproj/Localizable.strings`
|
||||
- Modify: `README.md`
|
||||
- Modify: `README.zh-CN.md`
|
||||
- Modify: `Docs/HELP_CENTER_OUTLINE.md`
|
||||
- Modify: `Docs/Execution/Current-Status-2026-03-07.md`
|
||||
- Modify: `Docs/Execution/Beta-Gate-Review.md`
|
||||
- Modify: `Docs/Execution/Smart-Clean-Execution-Coverage-2026-03-09.md`
|
||||
|
||||
**Step 1: Write the copy audit checklist directly into the diff**
|
||||
|
||||
Before editing text, create a short checklist in your working notes and verify every claim against current behavior:
|
||||
|
||||
- does this line claim physical restore for all recoverable items?
|
||||
- does this line imply History/Recovery always means on-disk restore?
|
||||
- does this line distinguish “supported restore path” from “model-only restore”?
|
||||
- does this line imply direct execution for unsupported Smart Clean items?
|
||||
|
||||
**Step 2: Tighten in-app copy first**
|
||||
|
||||
Update the localized strings most likely to overclaim current behavior:
|
||||
|
||||
- `smartclean.execution.coverage.full.detail`
|
||||
- `smartclean.preview.callout.safe.detail`
|
||||
- `application.recovery.completed`
|
||||
- `infrastructure.restore.summary.one`
|
||||
- `infrastructure.restore.summary.other`
|
||||
- `history.callout.recovery.detail`
|
||||
- `history.detail.recovery.callout.available.detail`
|
||||
- `history.restore.hint`
|
||||
|
||||
The wording rule is:
|
||||
|
||||
- say “when supported” or “when a restore path is available” where true
|
||||
- avoid implying every recoverable item restores physically
|
||||
- avoid implying every Smart Clean item is directly executable
|
||||
|
||||
**Step 3: Tighten release-facing docs**
|
||||
|
||||
Update:
|
||||
|
||||
- `README.md`
|
||||
- `README.zh-CN.md`
|
||||
- `Docs/HELP_CENTER_OUTLINE.md`
|
||||
- `Docs/Execution/Current-Status-2026-03-07.md`
|
||||
- `Docs/Execution/Beta-Gate-Review.md`
|
||||
- `Docs/Execution/Smart-Clean-Execution-Coverage-2026-03-09.md`
|
||||
|
||||
Specific goals:
|
||||
|
||||
- README should keep “recovery-first” as a principle without implying universal physical restore
|
||||
- `Current-Status` and `Beta-Gate-Review` must match the current subset reality
|
||||
- help content should explicitly include the case where restore cannot return a file physically
|
||||
|
||||
**Step 4: Run the narrowest verification**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages --filter AtlasApplicationTests
|
||||
swift test --package-path Apps --filter AtlasAppModelTests
|
||||
```
|
||||
|
||||
Then manually verify:
|
||||
|
||||
- Smart Clean empty/ready/error copy still reads correctly in both Chinese and English
|
||||
- History / Recovery copy still makes sense after narrowing restore claims
|
||||
|
||||
Expected:
|
||||
|
||||
- tests stay green
|
||||
- docs and UI no longer overclaim physical restore or execution breadth
|
||||
|
||||
**Step 5: Commit**
|
||||
|
||||
```bash
|
||||
git add Packages/AtlasDomain/Sources/AtlasDomain/Resources/en.lproj/Localizable.strings Packages/AtlasDomain/Sources/AtlasDomain/Resources/zh-Hans.lproj/Localizable.strings README.md README.zh-CN.md Docs/HELP_CENTER_OUTLINE.md Docs/Execution/Current-Status-2026-03-07.md Docs/Execution/Beta-Gate-Review.md Docs/Execution/Smart-Clean-Execution-Coverage-2026-03-09.md
|
||||
git commit -m "docs: narrow execution and recovery claims"
|
||||
```
|
||||
|
||||
### Task 4: Final Verification and Handoff
|
||||
|
||||
**Files:**
|
||||
- Review only: `Docs/Execution/Beta-Acceptance-Checklist.md`
|
||||
- Review only: `Docs/Execution/Execution-Chain-Audit-2026-03-09.md`
|
||||
- Review only: `Docs/ROADMAP.md`
|
||||
- Review only: `Docs/Backlog.md`
|
||||
|
||||
**Step 1: Run focused regression commands**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages --filter AtlasXPCTransportTests
|
||||
swift test --package-path Packages --filter AtlasApplicationTests
|
||||
swift test --package-path Apps --filter AtlasAppModelTests
|
||||
```
|
||||
|
||||
Expected:
|
||||
|
||||
- all targeted tests pass
|
||||
|
||||
**Step 2: Run broader package and app tests if the focused tests are green**
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
swift test --package-path Packages
|
||||
swift test --package-path Apps
|
||||
```
|
||||
|
||||
Expected:
|
||||
|
||||
- no regressions in package or app test suites
|
||||
|
||||
**Step 3: Manual product verification**
|
||||
|
||||
Verify on the latest local packaged or debug build:
|
||||
|
||||
1. Force an execution-unavailable path and confirm Smart Clean shows a visible danger-state failure.
|
||||
2. Confirm no silent fallback success path is visible in normal app mode.
|
||||
3. Confirm Smart Clean still executes supported safe targets.
|
||||
4. Confirm Recovery/History wording no longer implies guaranteed physical restore for every item.
|
||||
|
||||
**Step 4: Handoff notes**
|
||||
|
||||
Record:
|
||||
|
||||
- what was changed
|
||||
- which files changed
|
||||
- which tests passed
|
||||
- whether physical restore remains partial after copy hardening
|
||||
- whether signed-release work is still blocked by missing credentials
|
||||
153
Docs/Execution/Release-Roadmap-2026-03-12.md
Normal file
153
Docs/Execution/Release-Roadmap-2026-03-12.md
Normal file
@@ -0,0 +1,153 @@
|
||||
# Internal Beta Hardening and Conditional Release Roadmap — 2026-03-12
|
||||
|
||||
## Product Conclusion
|
||||
|
||||
Atlas for Mac should not optimize around public beta dates right now. The correct near-term program is `internal beta hardening`: execution truthfulness first, recovery credibility second, signed public distribution later when Apple release credentials exist.
|
||||
|
||||
This plan assumes:
|
||||
|
||||
- the frozen MVP module list does not change
|
||||
- direct distribution remains the eventual release route
|
||||
- no public beta or GA milestone is active until signing credentials are available
|
||||
|
||||
## Starting Evidence
|
||||
|
||||
- `Docs/Execution/Current-Status-2026-03-07.md` marks Atlas as internal-beta ready.
|
||||
- `Docs/Execution/Beta-Gate-Review.md` passes the beta candidate gate with conditions.
|
||||
- `Docs/Execution/Execution-Chain-Audit-2026-03-09.md` identifies the two biggest trust gaps:
|
||||
- silent fallback from XPC to scaffold worker
|
||||
- partial real execution and non-physical restore behavior
|
||||
- `Docs/Execution/Release-Signing.md` shows public distribution is blocked by missing Apple release credentials on the current machine.
|
||||
|
||||
## Active Phase Plan
|
||||
|
||||
### Phase 1: Internal Beta Hardening
|
||||
|
||||
- Dates: `2026-03-16` to `2026-03-28`
|
||||
- Outcome: a truthful internal-beta build that no longer overclaims execution or recovery capability
|
||||
|
||||
#### Workstreams
|
||||
|
||||
- `System Agent`
|
||||
- remove or development-gate silent XPC fallback in release-facing flows
|
||||
- surface explicit user-facing errors when real worker execution is unavailable
|
||||
- `QA Agent`
|
||||
- rerun clean-machine validation for first launch, language switching, and install flow
|
||||
- rerun `Smart Clean` and `Apps` end-to-end manual flows against packaged artifacts
|
||||
- `UX Agent` + `Docs Agent`
|
||||
- tighten copy where `Recovery` or `Smart Clean` implies broader on-disk behavior than shipped
|
||||
|
||||
#### Exit Gate
|
||||
|
||||
- latest packaged build passes internal beta checklist again
|
||||
- unsupported execution paths are visible and honest
|
||||
- recovery language matches the current shipped restore model
|
||||
|
||||
### Phase 2: Smart Clean Execution Credibility
|
||||
|
||||
- Dates: `2026-03-31` to `2026-04-18`
|
||||
- Outcome: highest-value safe cleanup paths have proven real side effects
|
||||
|
||||
#### Workstreams
|
||||
|
||||
- `System Agent` + `Core Agent`
|
||||
- expand real `Smart Clean` execute coverage for top safe target classes
|
||||
- carry executable structured targets through the worker path
|
||||
- route privileged cleanup through the helper boundary where necessary
|
||||
- `QA Agent`
|
||||
- add stronger `scan -> execute -> rescan` contract coverage
|
||||
- verify history and completion states only claim real success
|
||||
- `Mac App Agent`
|
||||
- align completion and failure states with true execution outcomes
|
||||
|
||||
#### Exit Gate
|
||||
|
||||
- supported cleanup paths show real post-execution scan improvement
|
||||
- unsupported paths fail clearly
|
||||
- history only claims completion when the filesystem side effect happened
|
||||
|
||||
### Phase 3: Recovery Credibility
|
||||
|
||||
- Dates: `2026-04-21` to `2026-05-09`
|
||||
- Outcome: Atlas's recovery promise is either physically true for file-backed actions or explicitly narrowed before release planning resumes
|
||||
|
||||
#### Workstreams
|
||||
|
||||
- `System Agent`
|
||||
- implement physical restore for file-backed recoverable actions where safe
|
||||
- or freeze a narrower recovery contract if physical restore cannot be landed safely
|
||||
- `QA Agent`
|
||||
- validate restore behavior on real file-backed test cases
|
||||
- `Docs Agent` + `Product Agent`
|
||||
- freeze README, release-note, and in-app recovery wording only after behavior is confirmed
|
||||
|
||||
#### Exit Gate
|
||||
|
||||
- file-backed recoverable actions either restore physically or are no longer described as if they do
|
||||
- QA evidence exists for shipped restore behavior
|
||||
- recovery claims are consistent across docs and product copy
|
||||
|
||||
## Conditional Release Plan
|
||||
|
||||
This branch is dormant until Apple release credentials exist.
|
||||
|
||||
### Conditional Phase A: Signed Public Beta Candidate
|
||||
|
||||
- Trigger:
|
||||
- `Developer ID Application`
|
||||
- `Developer ID Installer`
|
||||
- `ATLAS_NOTARY_PROFILE`
|
||||
- Workstreams:
|
||||
- run `./scripts/atlas/signing-preflight.sh`
|
||||
- rerun signed packaging
|
||||
- validate signed install behavior on a clean machine
|
||||
- prepare public beta notes and known limitations
|
||||
- Exit Gate:
|
||||
- signed and notarized artifacts exist
|
||||
- clean-machine install verification passes
|
||||
|
||||
### Conditional Phase B: Public Beta Learn Loop
|
||||
|
||||
- Trigger:
|
||||
- Conditional Phase A complete
|
||||
- Workstreams:
|
||||
- run a small hardware-diverse trusted beta cohort
|
||||
- triage install, permission, execution, and restore regressions
|
||||
- close P0 issues before any GA candidate is named
|
||||
- Exit Gate:
|
||||
- no public-beta P0 remains open
|
||||
- primary workflows are validated across more than one machine profile
|
||||
|
||||
### Conditional Phase C: GA Candidate and Launch
|
||||
|
||||
- Trigger:
|
||||
- Conditional Phase B complete
|
||||
- Workstreams:
|
||||
- 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 Gate:
|
||||
- no open P0 release blocker
|
||||
- signed packaging, install validation, and release docs are complete
|
||||
- `v1.0` is published
|
||||
|
||||
## Workstream Priorities
|
||||
|
||||
### Priority 1: Execution Truthfulness
|
||||
|
||||
Atlas cannot afford a release where `Smart Clean` appears to succeed while only Atlas state changes. Silent fallback removal, explicit execution failures, and `scan -> execute -> rescan` proof are the current highest-value work.
|
||||
|
||||
### Priority 2: Recovery Credibility
|
||||
|
||||
`Recovery` is part of Atlas's core trust story. Before broad release planning resumes, Atlas must either ship physical restore for file-backed recoverable actions or narrow its promise to the behavior that actually exists.
|
||||
|
||||
### Priority 3: Signed Distribution When Unblocked
|
||||
|
||||
Signing and notarization matter, but they are not the active critical path until credentials exist. When the credentials arrive, Gatekeeper-safe installation becomes a release gate, not a background task.
|
||||
|
||||
## Decision Rules
|
||||
|
||||
- Do not add P1 modules during this roadmap window.
|
||||
- Do not call the current branch `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 validated.
|
||||
@@ -124,6 +124,7 @@ Use these statements consistently in user-facing communication:
|
||||
- `Smart Clean runs real cleanup only for supported items in the current plan.`
|
||||
- `Unsupported items stay review-only until Atlas can execute them safely.`
|
||||
- `Recoverable items can be restored when a recovery path is available.`
|
||||
- `Some recoverable items restore on disk, while older or unstructured records restore Atlas state only.`
|
||||
- `If Atlas cannot prove the cleanup step, it should fail instead of claiming success.`
|
||||
|
||||
Avoid saying:
|
||||
|
||||
Reference in New Issue
Block a user