Merge release/3.2.3 into develop

[leeari95]

Summary by CodeRabbit

Release Notes: Version 3.2.3

• New Features

  • Added automatic local backup creation with manual restore capability
  • Added manual duplicate data cleanup option
  • Enhanced iCloud recovery with two-step confirmation and explicit data-overwrite warnings

• Improvements

  • Better protection against data loss during iCloud synchronization failures
  • Local backup metadata now visible in settings

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR implements a comprehensive local backup and recovery system to mitigate iCloud data loss. It introduces persistent local snapshots of user collections, a 10-minute recovery grace period, manual consolidation controls, enhanced centralized logging via Firebase/Crashlytics, and updated UI flows for snapshot-based restoration alongside improved iCloud recovery confirmations.

Changes

Cohort / File(s)	Summary
Configuration & Version Animal-Crossing-Wiki/Configurations/TargetVersion.xcconfig	Updated target version from 3.2.2 to 3.2.3.
Localization Strings Animal-Crossing-Wiki/Projects/App/Resources/en.lproj/Localizable.strings, Animal-Crossing-Wiki/Projects/App/Resources/ko.lproj/Localizable.strings	Expanded recovery/restore UI messaging; added labels for iCloud recovery (with local data overwrite warning), local backup detection/restoration flow, duplicate data cleanup, and confirmation prompts. Updated existing recovery strings to explicitly describe destructiveness and irreversibility.
Core Data Storage Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/CoreDataStorage.swift	Added recovery grace period tracking via UserDefaults (markRecoveryInitiated, clearRecoveryInitiated, isWithinRecoveryGracePeriod); refactored logging to use centralized Log API; modified UC creation during grace window; removed automatic post-import consolidation call; added manual consolidation entry point consolidateUserCollectionsManually; promoted orphan cleanup logging; extended logSyncDiagnostics with throttling parameter and Crashlytics snapshot integration.
Safety Snapshot Service Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/SafetySnapshot/SafetySnapshotService.swift	New service managing persistent local backup snapshots (local_safety_snapshot.plist). Provides snapshot lifecycle management via startObserving/stopObserving, debounced writes on context save/CloudKit import/remote change, metadata caching, and destructive restore flow with outcome reporting.
Snapshot Serialization Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/SafetySnapshot/UserCollectionSnapshot.swift	New model for snapshot data serialization/deserialization via NSKeyedArchiver. Implements dump(from:) to extract Core Data entities and apply(to:) to recreate them. Enforces version compatibility and handles missing user collection errors.
Logging Utility Animal-Crossing-Wiki/Projects/App/Sources/Utility/Log.swift	New centralized logging enum with 3-way fan-out: os_log, Firebase Crashlytics (non-fatal errors/breadcrumbs), and Analytics (with log-level filtering). Adds typed namespaces for events (Log.Event), parameters (Log.Param), Crashlytics keys (Log.Key), and snapshot telemetry via Log.Snapshot.
Presentation Layer Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Coordinator/DashboardCoordinator.swift, Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/ViewModels/AppSettingReactor.swift, Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Views/AppSettingView.swift	Updated recovery UI flows: added showLocalRestoreResult alert; extended reactor with new actions/mutations/state for manual consolidation and local backup metadata; added UI sections for backup info, duplicate cleanup, and local restore; wired activity indicators and metadata display bindings.
App Initialization Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift	Integrated SafetySnapshotService observation on app setup; added on-launch detection of missing collections with local backup present (prompts user for restore/wait choice); added restoration handling with UI feedback; added flushNow() call before background task to persist snapshots on suspend.
Documentation docs/features/icloud-sync.md, docs/iCloud-data-loss-fix-summary.md, docs/plans/local-backup-split.md	Documented iCloud recovery workflow with grace period and 2-step confirmation; added manual consolidation section; added Firebase telemetry integration details; added new non-developer summary of the data loss fix with scenario coverage table and QA checklist; added Stage 2 architecture design for dual-store persistence split.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant App as App Startup
    participant CoreData as CoreDataStorage
    participant Snapshot as SafetySnapshotService
    participant UI as Alert Controller

    App->>CoreData: Check hasEverHadUserCollection & isFreshInstall
    App->>Snapshot: readMetadata()
    Snapshot-->>App: Metadata (if snapshot exists)
    
    alt Snapshot found & data missing
        App->>UI: Show "Restore from local or wait for iCloud?"
        User->>UI: Choose restore or wait
        
        alt User chooses restore
            App->>Snapshot: restore(completion:)
            Snapshot->>CoreData: Load snapshot, wipe entities, apply data
            Snapshot->>CoreData: Save context
            Snapshot-->>App: RestoreOutcome.success(count)
            App->>UI: Show "Restore complete"
            App->>App: Refresh user collection
        else User chooses wait
            App->>CoreData: markRecoveryInitiated()
            App->>CoreData: Grace period active (10 min)
        end
    else Snapshot not found
        App->>App: Continue normal startup
    end

Loading

Estimated code review effort

🎯 5 (Critical) | ⏱️ ~110 minutes

Possibly related PRs

• #171: Modifies core recovery-related code paths and resources across CoreDataStorage, settings UI, and localization strings for iCloud recovery flows.
• #156: Modifies CoreDataStorage, SceneDelegate, localization, and iCloud sync workflows for consolidation and import handling.
• #174: Updates the same iCloud recovery/sync code paths, Core Data storage, and TARGET_VERSION configuration.

Suggested labels

feature, fix

Poem

🐰 A snapshot saved, a backup blessed,
Recovery grace puts minds at rest,
When iCloud clouds fade into night,
Local whispers bring data light,
Consolidate, restore, and thrive—
The warren's collections stay alive! ✨

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description is entirely empty with no content provided, failing to meet the repository's required template structure and content guidelines.	Add a comprehensive description following the template, including issue reference, work summary, work type classification, and completion checklist.
Docstring Coverage	⚠️ Warning	Docstring coverage is 39.13% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title accurately describes the merge operation from release/3.2.3 to develop branch, which aligns with the version bump in the changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch release/3.2.3

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift (1)

301-320: ⚠️ Potential issue | 🟠 Major

Start the background task before flushing the snapshot.

flushNow() performs synchronous snapshot dump/serialization/disk I/O, but it currently runs on the main thread before beginBackgroundTask; a slow snapshot can block background entry and leave no extended time for the write.

⏱️ Proposed ordering fix

     func sceneDidEnterBackground(_ scene: UIScene) {
         ToastManager.shared.dismiss()
-
-        // Stage 1.5: 백그라운드 진입 직전 pending 스냅샷을 강제 flush
-        SafetySnapshotService.shared.flushNow()
 
         // Extend execution time for pending CloudKit sync operations (import/export)
         var backgroundTaskID: UIBackgroundTaskIdentifier = .invalid
         let endTask = {
@@
         }
         backgroundTaskID = UIApplication.shared.beginBackgroundTask(expirationHandler: endTask)
+
+        // Stage 1.5: 백그라운드 진입 직전 pending 스냅샷을 강제 flush
+        DispatchQueue.global(qos: .utility).async {
+            SafetySnapshotService.shared.flushNow()
+        }
 
         DispatchQueue.main.asyncAfter(deadline: .now() + 30.0) {
             endTask()
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift` around lines
301 - 320, In sceneDidEnterBackground, start the background task before calling
SafetySnapshotService.shared.flushNow() so the synchronous disk I/O is covered
by the extended execution time: move the beginBackgroundTask(...) call (and
setting of backgroundTaskID and endTask closure) above the flushNow()
invocation, keep the endTask closure and the DispatchQueue.main.asyncAfter(...
+30s) termination logic intact, and ensure backgroundTaskID is ended via
UIApplication.shared.endBackgroundTask(backgroundTaskID) in the same endTask
closure after flush completes or on the timeout.

🧹 Nitpick comments (2)

Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Coordinator/DashboardCoordinator.swift (1)

162-170: Apply the SwiftLint conditional-return style.

Line 164 triggers conditional_returns_on_newline; expand the guard body.

🧹 Proposed lint fix

         DispatchQueue.main.async { [weak self] in
-            guard let currentVC = self?.rootViewController.visibleViewController else { return }
+            guard let currentVC = self?.rootViewController.visibleViewController else {
+                return
+            }
             let title = success ? "Restore complete".localized : "Restore failed".localized

As per coding guidelines, **/*.swift: SwiftLint 설정에 따라 린트 검사를 수행하고, 자동 수정 가능한 문제는 swiftlint --config .swiftlint.yml --fix로 처리.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Coordinator/DashboardCoordinator.swift`
around lines 162 - 170, The guard in showLocalRestoreResult is written as a
single-line conditional which triggers SwiftLint's
conditional_returns_on_newline; rewrite the guard binding to a multi-line form
so the else { return } is on its own line and then place the alert
creation/presentation code inside the scope that follows the guard (use the
existing currentVC constant from
self?.rootViewController.visibleViewController), e.g. expand the guard let
currentVC = self?.rootViewController.visibleViewController into a multi-line
guard and move the ensuing alert construction and currentVC.present(...) into
the guarded block.

Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/ViewModels/AppSettingReactor.swift (1)

81-134: Inconsistent [weak self] capture in chained flatMap closures.

In .recoverFromCloud, .consolidateManually, and .restoreLocalBackup, the outer flatMap uses [weak self] but the inner flatMap (that kicks off performRecovery() / performConsolidation() / performLocalRestore()) captures self implicitly (strong). Functionally fine because these operations are short-lived, but the mixed capture style is easy to misread as a leak, and any future refactor that moves these helpers elsewhere could regress into an actual cycle.

♻️ Proposed tweak for consistency

-                .flatMap { confirmed -> Observable<Mutation> in
-                    guard confirmed else { return .empty() }
+                .flatMap { [weak self] confirmed -> Observable<Mutation> in
+                    guard let self, confirmed else { return .empty() }
                     return Observable.concat(
                         .just(.setRecoveryInProgress(true)),
                         self.performRecovery()
                     )
                 }

Apply the same pattern to the .consolidateManually (line 103) and .restoreLocalBackup (line 127) chains.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/ViewModels/AppSettingReactor.swift`
around lines 81 - 134, The chained flatMap closures for .consolidateManually and
.restoreLocalBackup currently capture self strongly in the inner flatMap that
returns
Observable.concat(self.performConsolidation()/self.performLocalRestore()),
creating an inconsistent capture pattern versus .recoverFromCloud; update those
inner flatMap closures to use a weak self capture (e.g., flatMap { [weak self]
confirmed -> Observable<Mutation> in guard let self = self, confirmed else {
return .empty() } ... }) and call self.performConsolidation() /
self.performLocalRestore() so the capture style matches the .recoverFromCloud
chain and avoids accidental retains.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/SafetySnapshot/SafetySnapshotService.swift`:
- Around line 99-127: pendingWorkItem is read/written from multiple threads
causing races; funnel all accesses through the serial queue. Change
scheduleSnapshot() to perform the cancel, create the DispatchWorkItem, assign
pendingWorkItem and call queue.asyncAfter from inside queue.async (or
queue.async { ... }) so the assignment happens on queue; change flushNow() to
dispatch to queue (use queue.sync if you need synchronous flush) to cancel/clear
pendingWorkItem and then call writeSnapshotNow() on that queue; and change
stopObserving() to dispatch the pendingWorkItem cancel/clear to queue as well
(leave NotificationCenter removals on the caller thread if desired). Ensure all
references to pendingWorkItem, scheduleSnapshot(), flushNow(), stopObserving(),
and writeSnapshotNow() mutate state only on queue.

In `@Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift`:
- Around line 66-74: The current implementation of
offerSafetySnapshotRestoreIfNeeded() reads metadata then waits 2 seconds before
calling presentSafetySnapshotPrompt(metadata:), but CloudKit imports can
complete during that delay; update the closure to re-check the purge conditions
before presenting: inside the DispatchQueue.main.asyncAfter block, re-evaluate
CoreDataStorage.shared.hasEverHadUserCollection and
CoreDataStorage.shared.isFreshInstall() (and optionally re-read
SafetySnapshotService.shared.readMetadata()) and only call
presentSafetySnapshotPrompt(metadata:) if those checks still pass; keep the
initial early-return checks but add this secondary validation to avoid offering
a destructive restore over newly imported data.

In `@Animal-Crossing-Wiki/Projects/App/Sources/Utility/Log.swift`:
- Around line 88-138: The Analytics calls currently send free-form text
(Param.message in emit(level:symbol:osLogType:message:sendToAnalytics:) and
Param.reason in error(name:reason:userInfo:)), which must be removed; update
emit(...) so Analytics.logEvent("log_\(level)", parameters: []) or omit
parameters entirely (do not include Param.message), and update error(...) to
call Analytics.logEvent("log_error", parameters: [Param.errorName:
truncate(name)]) only (remove Param.reason), ensuring crashlytics.record and
os_log behavior remain unchanged.

In `@docs/features/icloud-sync.md`:
- Around line 227-262: Update the stale sentence that claims
consolidateUserCollections() runs automatically on app start/after import;
replace or delete it so the doc states automatic consolidation was removed and
consolidation now runs only via
CoreDataStorage.consolidateUserCollectionsManually(completion:), and mention
that previous automatic callers (CoreDataStorage.handleCloudKitEvent() import
path and SceneDelegate.setupApp()) were removed due to the bug.

In `@docs/iCloud-data-loss-fix-summary.md`:
- Around line 175-180: The release docs state the target version is `3.2.4` but
the build config `TargetVersion.xcconfig` sets TARGET_VERSION = 3.2.3 and the PR
branch is `release/3.2.3`; reconcile them by either updating the docs section
that lists "대상 버전" to `3.2.3` to match `TARGET_VERSION` and the branch, or
change `TARGET_VERSION` in `TargetVersion.xcconfig` to `3.2.4` (and ensure the
PR/branch is updated accordingly) so the documented target, the config variable
TARGET_VERSION, and the source branch (`release/3.2.3`) are consistent.

---

Outside diff comments:
In `@Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift`:
- Around line 301-320: In sceneDidEnterBackground, start the background task
before calling SafetySnapshotService.shared.flushNow() so the synchronous disk
I/O is covered by the extended execution time: move the beginBackgroundTask(...)
call (and setting of backgroundTaskID and endTask closure) above the flushNow()
invocation, keep the endTask closure and the DispatchQueue.main.asyncAfter(...
+30s) termination logic intact, and ensure backgroundTaskID is ended via
UIApplication.shared.endBackgroundTask(backgroundTaskID) in the same endTask
closure after flush completes or on the timeout.

---

Nitpick comments:
In
`@Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Coordinator/DashboardCoordinator.swift`:
- Around line 162-170: The guard in showLocalRestoreResult is written as a
single-line conditional which triggers SwiftLint's
conditional_returns_on_newline; rewrite the guard binding to a multi-line form
so the else { return } is on its own line and then place the alert
creation/presentation code inside the scope that follows the guard (use the
existing currentVC constant from
self?.rootViewController.visibleViewController), e.g. expand the guard let
currentVC = self?.rootViewController.visibleViewController into a multi-line
guard and move the ensuing alert construction and currentVC.present(...) into
the guarded block.

In
`@Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/ViewModels/AppSettingReactor.swift`:
- Around line 81-134: The chained flatMap closures for .consolidateManually and
.restoreLocalBackup currently capture self strongly in the inner flatMap that
returns
Observable.concat(self.performConsolidation()/self.performLocalRestore()),
creating an inconsistent capture pattern versus .recoverFromCloud; update those
inner flatMap closures to use a weak self capture (e.g., flatMap { [weak self]
confirmed -> Observable<Mutation> in guard let self = self, confirmed else {
return .empty() } ... }) and call self.performConsolidation() /
self.performLocalRestore() so the capture style matches the .recoverFromCloud
chain and avoids accidental retains.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 72d0453f-c98f-48bd-8103-2f4c36c0357a

📥 Commits

Reviewing files that changed from the base of the PR and between 1dccf7e and 65d8fe6.

📒 Files selected for processing (14)

• Animal-Crossing-Wiki/Configurations/TargetVersion.xcconfig
• Animal-Crossing-Wiki/Projects/App/Resources/en.lproj/Localizable.strings
• Animal-Crossing-Wiki/Projects/App/Resources/ko.lproj/Localizable.strings
• Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/CoreDataStorage.swift
• Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/SafetySnapshot/SafetySnapshotService.swift
• Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/SafetySnapshot/UserCollectionSnapshot.swift
• Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Coordinator/DashboardCoordinator.swift
• Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/ViewModels/AppSettingReactor.swift
• Animal-Crossing-Wiki/Projects/App/Sources/Presentation/Dashboard/Views/AppSettingView.swift
• Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift
• Animal-Crossing-Wiki/Projects/App/Sources/Utility/Log.swift
• docs/features/icloud-sync.md
• docs/iCloud-data-loss-fix-summary.md
• docs/plans/local-backup-split.md

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Data race on pendingWorkItem across threads.

pendingWorkItem is mutated from multiple threads without synchronization:

• scheduleSnapshot() is invoked inside NotificationCenter callbacks registered with queue: nil, so the closure runs on the posting thread (Core Data save → background context thread; CloudKit events → internal CloudKit thread). It does pendingWorkItem?.cancel() then pendingWorkItem = workItem.
• flushNow() is called from SceneDelegate (main thread) per the PR summary.
• stopObserving() also mutates it.
• The initial queue.async { self?.writeSnapshotNow() } at line 99 runs on queue but doesn't touch pendingWorkItem.

Concurrent cancel/assign from different threads is undefined behavior (torn writes, double-cancel, lost cancellation). Serialize via the existing queue (or a dedicated lock) for every access.

🔒 Proposed fix — funnel all state mutations through the serial queue

     private func scheduleSnapshot() {
-        pendingWorkItem?.cancel()
-        let workItem = DispatchWorkItem { [weak self] in
-            self?.writeSnapshotNow()
-        }
-        pendingWorkItem = workItem
-        queue.asyncAfter(deadline: .now() + Self.debounceSeconds, execute: workItem)
+        queue.async { [weak self] in
+            guard let self else { return }
+            self.pendingWorkItem?.cancel()
+            let workItem = DispatchWorkItem { [weak self] in
+                self?.writeSnapshotNow()
+            }
+            self.pendingWorkItem = workItem
+            self.queue.asyncAfter(deadline: .now() + Self.debounceSeconds, execute: workItem)
+        }
     }

     func flushNow() {
-        pendingWorkItem?.cancel()
-        pendingWorkItem = nil
-        writeSnapshotNow()
+        queue.sync {
+            self.pendingWorkItem?.cancel()
+            self.pendingWorkItem = nil
+        }
+        queue.async { [weak self] in self?.writeSnapshotNow() }
     }

stopObserving() should similarly dispatch the cancel onto queue.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/SafetySnapshot/SafetySnapshotService.swift`
around lines 99 - 127, pendingWorkItem is read/written from multiple threads
causing races; funnel all accesses through the serial queue. Change
scheduleSnapshot() to perform the cancel, create the DispatchWorkItem, assign
pendingWorkItem and call queue.asyncAfter from inside queue.async (or
queue.async { ... }) so the assignment happens on queue; change flushNow() to
dispatch to queue (use queue.sync if you need synchronous flush) to cancel/clear
pendingWorkItem and then call writeSnapshotNow() on that queue; and change
stopObserving() to dispatch the pendingWorkItem cancel/clear to queue as well
(leave NotificationCenter removals on the caller thread if desired). Ensure all
references to pendingWorkItem, scheduleSnapshot(), flushNow(), stopObserving(),
and writeSnapshotNow() mutate state only on queue.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Re-check the purge condition before showing the restore prompt.

CloudKit import can finish during the 2-second delay, making the local store non-empty; this prompt would still offer a destructive local restore over newly imported data.

🛡️ Proposed re-validation

         DispatchQueue.main.asyncAfter(deadline: .now() + 2) { [weak self] in
-            self?.presentSafetySnapshotPrompt(metadata: metadata)
+            guard CoreDataStorage.shared.hasEverHadUserCollection,
+                  CoreDataStorage.shared.isFreshInstall(),
+                  let latestMetadata = SafetySnapshotService.shared.readMetadata() else {
+                return
+            }
+            self?.presentSafetySnapshotPrompt(metadata: latestMetadata)
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Animal-Crossing-Wiki/Projects/App/Sources/SceneDelegate.swift` around lines
66 - 74, The current implementation of offerSafetySnapshotRestoreIfNeeded()
reads metadata then waits 2 seconds before calling
presentSafetySnapshotPrompt(metadata:), but CloudKit imports can complete during
that delay; update the closure to re-check the purge conditions before
presenting: inside the DispatchQueue.main.asyncAfter block, re-evaluate
CoreDataStorage.shared.hasEverHadUserCollection and
CoreDataStorage.shared.isFreshInstall() (and optionally re-read
SafetySnapshotService.shared.readMetadata()) and only call
presentSafetySnapshotPrompt(metadata:) if those checks still pass; keep the
initial early-return checks but add this secondary validation to avoid offering
a destructive restore over newly imported data.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Firebase Analytics iOS best practices for event parameters: PII, user-generated content, and high-cardinality free-form log messages

💡 Result:

Firebase Analytics iOS best practices for event parameters emphasize using recommended events and parameters for optimal reporting, registering custom parameters/dimensions, and avoiding issues with PII, user-generated content, and high-cardinality data. PII (Personally Identifiable Information): Do not log PII such as names, emails, phone numbers, or identifiers that can uniquely identify users in event parameters. Firebase collects device identifiers like IDFA (with consent) or app-instance ID automatically, but developers must ensure custom parameters exclude PII to comply with privacy regulations like GDPR/CCPA and avoid violations. Use anonymized or aggregated data instead. User-generated content: Avoid logging raw user-generated content (e.g., full text messages, usernames) as parameters due to PII risks and high cardinality. Truncate or hash if necessary, but prefer categorizing (e.g., "content_type": "image") over full content. Examples from docs show limited use like "name" or "full_text" only for non-sensitive recommended events. High-cardinality free-form log messages: Avoid high-cardinality parameters (>500 unique values/day, e.g., unique error messages, user IDs, paths) as they cause data sampling, "(other)" rows in reports, and hit row limits (50,000 cardinality limit). Use low-cardinality categorizations (e.g., "error_type": "network" instead of full message). For detailed logs/errors, use Firebase Crashlytics instead of Analytics events. General best practices: - Up to 25 parameters per event; names <=40 chars (alphanumeric + _, start with letter), values strings <=100 chars. - Use recommended parameters (e.g., value, currency) and register customs in console for reporting. - Prefix events logically (e.g., "home_event_select_book"). - Set user properties (up to 25) for stable attributes like "user_type", not high-cardinality or PII. - iOS-specific: Disable IDFV/IDFA collection via plist if needed; use setUserProperty for non-PII properties. Implement via Analytics.logEvent(name, parameters: [...]) in Swift.

Citations:

• 1: https://firebase.google.com/docs/analytics/ios/events
• 2: https://firebase.google.com/docs/analytics/events?platform=ios
• 3: https://firebase.google.com/docs/analytics/ios/user-properties
• 4: https://firebase.google.com/docs/analytics/events
• 5: https://groups.google.com/g/firebase-talk/c/D4_NjP4HDYk
• 6: https://stackoverflow.com/questions/63455259/effects-of-high-cardinality-google-analytics-event-label-fields
• 7: https://support.google.com/firebase/answer/6318039?hl=en
• 8: https://support.google.com/analytics/answer/11593727?hl=en
• 9: https://firebase.google.com./docs/analytics/configure-data-collection
• 10: https://firebase.google.com/docs/analytics/errors
• 11: https://support.google.com/analytics/answer/9019185?hl=en
• 12: https://www.firebase.com/terms/privacy-policy.html
• 13: https://firebase.google.com/support/privacy
• 14: https://support.google.com/analytics/answer/12226705?hl=en
• 15: https://blog.stackademic.com/mastering-firebase-analytics-in-android-track-events-with-correct-parameters-full-guide-best-a1198b321f32

---

🏁 Script executed:

# Check the full Log.swift file to see the complete context and confirm the snippet
cat -n Projects/App/Sources/Utility/Log.swift

Repository: leeari95/ACNH-wiki

Length of output: 132

---

🏁 Script executed:

fd -name "Log.swift" -type f

Repository: leeari95/ACNH-wiki

Length of output: 292

---

🏁 Script executed:

fd "Log.swift" --type f

Repository: leeari95/ACNH-wiki

Length of output: 121

---

🏁 Script executed:

cat -n Animal-Crossing-Wiki/Projects/App/Sources/Utility/Log.swift

Repository: leeari95/ACNH-wiki

Length of output: 9142

---

Don't send free-form log bodies to Firebase Analytics—they are high-cardinality and risk data quality issues.

Line 94 (emit()) and lines 136–137 (error()) send arbitrary message and reason strings to Analytics. These can include dynamic Core Data/CloudKit details or user-derived content, causing high-cardinality pollution (>500 unique values/day) and exceeding quotas. Firebase best practices mandate using Crashlytics for detailed diagnostics and keeping Analytics events to low-cardinality, stable identifiers. Truncation does not solve the cardinality problem.

Remove Param.message from emit() and Param.reason from error(); keep Param.errorName only as a stable error type identifier.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Animal-Crossing-Wiki/Projects/App/Sources/Utility/Log.swift` around lines 88
- 138, The Analytics calls currently send free-form text (Param.message in
emit(level:symbol:osLogType:message:sendToAnalytics:) and Param.reason in
error(name:reason:userInfo:)), which must be removed; update emit(...) so
Analytics.logEvent("log_\(level)", parameters: []) or omit parameters entirely
(do not include Param.message), and update error(...) to call
Analytics.logEvent("log_error", parameters: [Param.errorName: truncate(name)])
only (remove Param.reason), ensuring crashlytics.record and os_log behavior
remain unchanged.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify whether exit(0) / kill are invoked as part of the recovery flow
rg -nP --type=swift -C3 '\bexit\s*\(\s*0\s*\)'
rg -nP --type=swift -C3 'showRecoveryResultAlert\s*\('

Repository: leeari95/ACNH-wiki

Length of output: 3615

---

🏁 Script executed:

#!/bin/bash
# View the context around line 190 to verify the stale consolidation description
sed -n '185,195p' docs/features/icloud-sync.md

Repository: leeari95/ACNH-wiki

Length of output: 704

---

🏁 Script executed:

#!/bin/bash
# Check CoreDataStorage.swift around lines 410-411 for consolidation removal
sed -n '405,420p' Animal-Crossing-Wiki/Projects/App/Sources/CoreDataStorage/CoreDataStorage.swift

Repository: leeari95/ACNH-wiki

Length of output: 640

---

Remove stale automatic consolidation description at line 190.

The line still reads: "consolidateUserCollections() — 앱 시작/Import 완료 시 자동 실행 (5초 지연, DispatchWorkItem으로 중복 방지)". This contradicts the new 3.2.4 note and the Manual Consolidation section (lines 253–262) which correctly state that automatic calls were removed. CoreDataStorage.swift confirms the removal with the comment: "Import 후 자동 consolidation/orphan cleanup이 로컬 데이터를 삭제하는 버그로 제거됨". Update or delete this line to reflect manual-only invocation.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/features/icloud-sync.md` around lines 227 - 262, Update the stale
sentence that claims consolidateUserCollections() runs automatically on app
start/after import; replace or delete it so the doc states automatic
consolidation was removed and consolidation now runs only via
CoreDataStorage.consolidateUserCollectionsManually(completion:), and mention
that previous automatic callers (CoreDataStorage.handleCloudKitEvent() import
path and SceneDelegate.setupApp()) were removed due to the bug.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Align the documented release version with the actual target config.

This section says the target version is 3.2.4, but TargetVersion.xcconfig now sets TARGET_VERSION = 3.2.3 and the PR source branch is release/3.2.3. Please update either the docs or the version config before release.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/iCloud-data-loss-fix-summary.md` around lines 175 - 180, The release
docs state the target version is `3.2.4` but the build config
`TargetVersion.xcconfig` sets TARGET_VERSION = 3.2.3 and the PR branch is
`release/3.2.3`; reconcile them by either updating the docs section that lists
"대상 버전" to `3.2.3` to match `TARGET_VERSION` and the branch, or change
`TARGET_VERSION` in `TargetVersion.xcconfig` to `3.2.4` (and ensure the
PR/branch is updated accordingly) so the documented target, the config variable
TARGET_VERSION, and the source branch (`release/3.2.3`) are consistent.