top of page
3DaysOfSwift-WebApp-80-tiny.png
Start
1
2
3
My Account

CFA Reference: Change and Review Gate

Formal CFA AI Toolkit for iOS Documentation · Reference 19 of 26

The change gate is a short design pass before implementation and a structural review before delivery. A change is not complete until it passes.

Definitions

  • Affected route: Screen View → Screen ViewModel → AppModel.shared feature → provider / storage, written for every screen in scope.
  • Ownership statement: “This type owns …” for each new or changed type.
  • Invariants: The 23 numbered rules preserved unless the developer explicitly asks to change the architecture.
  • Completion record: Before/after navigator map, feature inventory, concurrency inventory, build and tests at the final commit with manual behaviour regression, and a human architecture review.

Rules

  1. Read the project workflow first; visual defaults are not architecture invariants.
  2. Before implementing, write the affected route and an ownership statement, and confirm the responsibility is not already owned.
  3. Preserve invariants 1–23, including: private dedicated ViewModels (1), Feature suffix and no FeatureAPI protocol (7), separate data, state and errors (8), launch at the app delegate with one shared in-flight task cleared in defer (9), @ModelActor repositories (10), single persistence route (13), AppModel contents (14), SwiftDataManager and NetworkingManager (15), stable App.body (17), no storage gate (18), work-named methods (19), retained ViewModel tasks (22).
  4. Before delivery, review the changed source as one feature slice, check imports in every new or moved file, and confirm named test files exist.
  5. Build and run focused tests; report unavailable checks honestly, never as a pass.
  6. If any invariant fails, correct the plan before expanding the implementation.

Decision rules

  • When a new type is proposed, state what it owns; if something already owns it, do not add the type.
  • When the change touches persistence, fail the initial store open and check the root stays visible and the feature shows its error.
  • When an upgrade is in progress, do not say “complete” until the whole completion record exists for the whole app.
  • When any completion item is missing, name it and keep the work open.

Example

Route and ownership statement, using the gate's format and Habit Tracker's names

Screen View → Screen ViewModel → AppModel.shared feature → provider / storage

HabitsView → HabitsViewModel → AppModel.shared.habitsFeature → SwiftDataManager

This type owns …
- HabitsFeature owns the authoritative habit collection and persisted mutations.
- HabitsViewModel owns the Habits screen's presentation state.

Common mistakes

  • Treating the gate as paperwork after the code is written.
  • Reporting a pre-change test baseline as a pass.
  • Adding themes or a footer to an established app because a default exists.
  • Leaving abandoned files or duplicate owners behind.

Links

bottom of page