mobile-ai-agents 1.0.23

package/skills/android/memory-leak-investigation.md

@@ -0,0 +1,256 @@
+# Skill — /memory-leak-investigation
+
+**Platform:** Android  
+**Slash Command:** `/memory-leak-investigation`  
+**Composable With:** Android Code Reviewer, AXIOM, PERF, MOBILE-HARNESS
+
+---
+
+## Purpose
+
+Investigate Android memory leaks from LeakCanary traces, heap summaries, retained-object reports, or related Kotlin code. Trace the strong-reference path from a GC root to the retained object, identify the reference that outlives its intended lifecycle, propose the smallest ownership fix, and define repeatable verification.
+
+This skill is evidence-first. A retained object is not automatically the source of the leak, and replacing strong references with weak references is not a valid default fix.
+
+---
+
+## Input Format
+
+```text
+COMMAND: /memory-leak-investigation
+APP_VERSION: <version/build>
+ANDROID_VERSION: <version or unknown>
+DEVICE: <model or unknown>
+REPORT_SOURCE: <LeakCanary | heap dump | profiler | test | other>
+EXPECTED_LIFECYCLE:
+<when the retained object should become unreachable>
+REPRODUCTION:
+<steps that increase retained objects or memory>
+LEAK_TRACE:
+<complete GC-root-to-retained-object path or available heap summary>
+RELATED_CODE:
+<Activity, Fragment, ViewModel, adapter, callback, coroutine, observer, singleton, or SDK code>
+```
+
+---
+
+## Skill Prompt
+
+````text
+Investigate the Android memory leak using the supplied evidence.
+
+STEP 1 — VERIFY EVIDENCE
+- Confirm that the retained object, expected lifecycle, and strongest available reference path are present.
+- Distinguish a confirmed leak from temporary retention, cache behavior, or high allocation pressure.
+- If the trace is truncated or lacks the GC root/reference chain, mark confidence LOW and list the missing evidence.
+- Do not invent fields, object ownership, retained sizes, or lifecycle events.
+
+STEP 2 — READ THE REFERENCE PATH
+- Start at the GC root and follow every strong reference to the retained object.
+- Separate framework and collection implementation details from references controlled by app code.
+- Use LeakCanary's Leaking: YES/NO/UNKNOWN evidence to narrow suspect references.
+- Identify the first app-controlled reference that should have been cleared, replaced, unregistered, or scoped differently.
+- Explain why the retaining object outlives the retained object.
+
+STEP 3 — CLASSIFY THE LEAK
+Classify as one of:
+- Activity or Fragment instance
+- Fragment view or ViewBinding
+- RecyclerView adapter/listener
+- Context held by singleton/static object
+- Observer, callback, listener, or broadcast registration
+- Coroutine, Flow, Rx, executor, or delayed task
+- ViewModel or SavedState ownership
+- Dialog, Window, animation, drawable, or WebView
+- Service, receiver, worker, or SDK lifecycle
+- Native/JNI resource
+- Cache or collection without eviction
+- Unknown
+
+STEP 4 — CORRELATE WITH CODE
+Check for:
+- Fragment bindings or adapters surviving onDestroyView.
+- Anonymous callbacks, listeners, observers, or receivers that are never removed.
+- Singleton/static fields retaining Activity, Fragment, View, adapter, or callback instances.
+- applicationScope, GlobalScope, custom scopes, handlers, runnables, timers, or executors retaining UI owners.
+- Flow/Rx collection not bound to the correct lifecycle.
+- ViewModel retaining Views, Activities, Fragments, adapters, or short-lived Context objects.
+- Long-lived caches or maps without bounded eviction.
+- WebView, Dialog, Window, animation, drawable callback, or third-party SDK cleanup requirements.
+- Native resources that require close, release, recycle, unregister, or destroy.
+
+STEP 5 — PROPOSE THE SMALLEST OWNERSHIP FIX
+- Remove the proven strong-reference path or scope it to the correct lifecycle.
+- Prefer lifecycle-aware collection, explicit unregister/cleanup, bounded ownership, and application Context only when semantically correct.
+- Do not recommend WeakReference as a generic repair.
+- Do not clear unrelated state or add onDestroy cleanup without proving that lifecycle owns the reference.
+- Provide before/after Kotlin when source is available.
+
+STEP 6 — VERIFY
+Include:
+- Deterministic reproduction with repeated create/destroy cycles.
+- LeakCanary or heap-dump confirmation that the object becomes collectible.
+- Retained-object and memory trend checks after forced GC/idle periods.
+- Lifecycle regression tests or instrumentation where practical.
+- Rotation, back-stack, navigation, and process-recreation checks where relevant.
+
+Output normal Markdown. Do not wrap the full report in a code block.
+
+ANDROID MEMORY LEAK INVESTIGATION
+=================================
+Result: CONFIRMED | LIKELY | INCONCLUSIVE
+Confidence: HIGH | MEDIUM | LOW
+Leak Type:
+Retained Object:
+Expected Collection Point:
+
+Evidence Summary:
+| Evidence | Observation |
+|---|---|
+
+Reference Path:
+| From | Reference | To | Assessment |
+|---|---|---|---|
+
+Root Cause:
+<proven ownership/lifecycle chain, or what remains unknown>
+
+Fix:
+<smallest ownership fix>
+
+Updated Code:
+```kotlin
+<corrected code, or "Not available without related source">
+```
+
+Verification:
+- <step>
+
+Missing Evidence:
+- <item or "None">
+
+Next Action:
+<one concrete action>
+````
+
+---
+
+## Example
+
+### Input
+
+```text
+COMMAND: /memory-leak-investigation
+APP_VERSION: 3.2.0 (320)
+ANDROID_VERSION: 15
+DEVICE: Pixel 7
+REPORT_SOURCE: LeakCanary
+EXPECTED_LIFECYCLE:
+ProfileFragment view should be collectible after onDestroyView.
+REPRODUCTION:
+Open Profile, navigate back, repeat five times.
+LEAK_TRACE:
+┬───
+│ GC Root: System class
+├─ com.example.App instance
+│    ↓ App.profileAdapters
+├─ java.util.ArrayList instance
+│    ↓ ArrayList.elementData
+├─ com.example.profile.ProfileAdapter instance
+│    ↓ ProfileAdapter.onAvatarClick
+├─ com.example.profile.ProfileFragment$onViewCreated$1 instance
+│    ↓ ProfileFragment$onViewCreated$1.this$0
+╰→ com.example.profile.ProfileFragment instance
+     Leaking: YES
+RELATED_CODE:
+class App : Application() {
+    val profileAdapters = mutableListOf<ProfileAdapter>()
+}
+
+class ProfileFragment : Fragment(R.layout.profile) {
+    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
+        val adapter = ProfileAdapter { openAvatar() }
+        recyclerView.adapter = adapter
+        (requireContext().applicationContext as App).profileAdapters += adapter
+    }
+}
+```
+
+### Output
+
+````markdown
+ANDROID MEMORY LEAK INVESTIGATION
+=================================
+Result: CONFIRMED
+Confidence: HIGH
+Leak Type: Fragment retained by application-owned collection
+Retained Object: `ProfileFragment`
+Expected Collection Point: After `onDestroyView()` and Fragment removal
+
+Evidence Summary:
+| Evidence | Observation |
+|---|---|
+| GC root | Application-reachable system class path |
+| Long-lived owner | `App.profileAdapters` |
+| Callback | Adapter lambda captures `ProfileFragment` |
+| Retained object | LeakCanary marks `ProfileFragment` as leaking |
+
+Reference Path:
+| From | Reference | To | Assessment |
+|---|---|---|---|
+| `App` | `profileAdapters` | `ArrayList` | App-controlled, process-long ownership |
+| `ArrayList` | element | `ProfileAdapter` | Adapter survives Fragment lifecycle |
+| `ProfileAdapter` | `onAvatarClick` | Fragment lambda | Captures Fragment instance |
+| Lambda | `this$0` | `ProfileFragment` | Direct retaining reference |
+
+Root Cause:
+`App.profileAdapters` gives each adapter process-long lifetime. The adapter's click lambda captures `ProfileFragment`, so navigating away cannot make the Fragment unreachable.
+
+Fix:
+Do not store screen adapters in the Application. Keep the adapter owned by the Fragment view lifecycle and detach it in `onDestroyView()`.
+
+Updated Code:
+```kotlin
+class ProfileFragment : Fragment(R.layout.profile) {
+    private var adapter: ProfileAdapter? = null
+
+    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
+        adapter = ProfileAdapter { openAvatar() }
+        recyclerView.adapter = adapter
+    }
+
+    override fun onDestroyView() {
+        recyclerView.adapter = null
+        adapter = null
+        super.onDestroyView()
+    }
+}
+```
+
+Verification:
+- Open and close Profile ten times with LeakCanary enabled.
+- Confirm destroyed `ProfileFragment` instances are no longer retained.
+- Capture a heap dump after idle/GC and verify no path through `App.profileAdapters`.
+- Rotate and navigate rapidly to exercise view recreation.
+- Add a FragmentScenario test that destroys the Fragment view and checks adapter detachment.
+
+Missing Evidence:
+- None
+
+Next Action:
+Remove `App.profileAdapters`, detach the RecyclerView adapter in `onDestroyView()`, then repeat the LeakCanary reproduction.
+````
+
+---
+
+## Usage Notes
+
+- A leak trace is a strong-reference path, not a stack trace. Diagnose ownership from the GC root toward the retained object.
+- The leaking object is often the victim; the actionable defect is usually an earlier app-controlled reference in the path.
+- Pair with PERF when the symptom is memory growth without a confirmed retention path.
+- This skill supports issue #1; a dedicated memory leak agent can embed it and add heap-dump and LeakCanary examples.
+
+## Official References
+
+- [LeakCanary: Fixing a memory leak](https://square.github.io/leakcanary/fundamentals-fixing-a-memory-leak/)
+- [Android Developers: Memory management overview](https://developer.android.com/topic/performance/memory-overview)

package/skills/android/proguard-rules.md

@@ -0,0 +1,48 @@
+# Skill — /proguard-rules
+
+**Platform:** Android
+**Slash Command:** `/proguard-rules`
+
+---
+
+## Purpose
+
+Generates correct R8/ProGuard rules from a project's dependency list and code patterns. Eliminates the "copy from StackOverflow" anti-pattern. Explains why each rule is needed.
+
+---
+
+## Skill Prompt
+
+```
+Generate R8/ProGuard rules for the provided dependencies and code patterns.
+
+For each dependency or pattern listed, generate the minimal rules needed and explain why:
+
+COMMON DEPENDENCIES AND THEIR RULES:
+- Retrofit + Gson/Moshi: keep data classes used as JSON models
+- Room: keep entities, DAOs, and database class
+- Hilt/Dagger: keep @HiltAndroidApp, @AndroidEntryPoint, @Inject annotated classes
+- Kotlin serialization: keep @Serializable annotated classes
+- OkHttp: keep interceptors and custom authenticators
+- Firebase: usually handled by firebase-android-sdk aar — note which rules come from the AAR
+- Glide/Coil: custom transformations and targets
+- Reflection usage: any class loaded by Class.forName()
+- Sealed classes/interfaces used in when() expressions
+- Parcelable implementations
+
+RULE FORMAT:
+For each rule, output:
+```proguard
+# Reason: <why this rule is needed>
+-keep class <pattern> { <members>; }
+```
+
+VALIDATION CHECKLIST:
+After generating rules, check for:
+- [ ] No overly broad -keep class * rules
+- [ ] Data classes for network/database are explicitly kept
+- [ ] Enum classes used in serialization are kept
+- [ ] No rules that disable R8's full-mode optimizations unnecessarily
+
+Also note which dependencies already ship their own consumer ProGuard rules (via .pro files in the AAR) — those don't need manual rules.
+```

package/skills/cross-platform/accessibility-audit.md

@@ -0,0 +1,63 @@
+# Skill — /accessibility-audit
+
+**Platform:** Cross-Platform
+**Slash Command:** `/accessibility-audit`
+
+---
+
+## Purpose
+
+Reviews any mobile screen for WCAG 2.1 AA compliance and platform accessibility standards. Increasingly required by law (EU Accessibility Act 2025, ADA).
+
+---
+
+## Skill Prompt
+
+```
+Audit the provided mobile screen or component for accessibility:
+
+WCAG 2.1 AA REQUIREMENTS:
+1. PERCEIVABLE
+   - 1.1.1 Non-text content: all images, icons, and decorative elements have alt text
+     or are marked as decorative.
+   - 1.3.1 Info and relationships: screen reader can determine the purpose of all UI elements.
+   - 1.4.3 Contrast (minimum): text contrast ratio ≥ 4.5:1 (normal), ≥ 3:1 (large 18pt+).
+   - 1.4.11 Non-text contrast: interactive components have ≥ 3:1 against adjacent color.
+
+2. OPERABLE
+   - 2.1.1 Keyboard: all functionality available without pointing device (hardware keyboard on iPad/Android).
+   - 2.4.3 Focus order: focus sequence is logical and meaningful.
+   - 2.5.3 Label in name: visible label text included in accessible name.
+   - 2.5.5 Target size: interactive targets ≥ 44×44pt (iOS) or 48×48dp (Android).
+
+3. UNDERSTANDABLE
+   - 3.3.1 Error identification: form errors identified in text, not color alone.
+   - 3.3.2 Labels or instructions: form inputs have visible labels.
+
+4. ROBUST
+   - 4.1.2 Name, role, value: all components have correct accessibility roles.
+
+PLATFORM CHECKS:
+Android:
+- contentDescription on all ImageView and IconButton elements.
+- importantForAccessibility="no" on decorative elements.
+- TalkBack focus order matches visual order.
+- Custom view provides AccessibilityNodeInfoCompat.
+
+iOS:
+- accessibilityLabel on all images and icon buttons.
+- accessibilityTraits correct (.button, .header, .link, .selected).
+- accessibilityHint for non-obvious actions.
+- isAccessibilityElement = false for decorative views.
+
+Flutter:
+- Semantics widget with label, button, and excludeSemantics for decorative.
+- SemanticsHint for non-obvious interactions.
+
+React Native:
+- accessibilityLabel and accessibilityRole on all interactive elements.
+- accessibilityHint for non-obvious actions.
+- accessible={false} for decorative elements.
+
+For each issue: element, requirement violated, WCAG criterion, and concrete fix.
+```

package/skills/cross-platform/api-versioning.md

@@ -0,0 +1,59 @@
+# Skill — /api-versioning
+
+**Platform:** Cross-Platform
+**Slash Command:** `/api-versioning`
+
+---
+
+## Purpose
+
+API deprecation strategy and migration plan for mobile clients. Handles the "we have users on v1.2 who won't update" reality that backend engineers underestimate.
+
+---
+
+## Skill Prompt
+
+```
+Create an API versioning and deprecation strategy for the described API change:
+
+MOBILE CLIENT REALITY:
+Mobile clients cannot be force-updated. Users on old versions may remain on them for
+12–24 months. Any breaking API change must have a graceful degradation path.
+
+BREAKING vs NON-BREAKING CHANGES:
+Non-breaking (safe to ship):
+- Adding new optional fields to responses
+- Adding new optional request parameters
+- Adding new endpoints
+- Expanding enum values (with unknown value handling)
+
+Breaking (requires versioning):
+- Removing fields from responses
+- Changing field types
+- Renaming fields
+- Changing endpoint URLs
+- Making optional fields required
+- Removing enum values
+
+VERSIONING STRATEGIES:
+1. URL versioning: /v1/users, /v2/users — simple, explicit, but multiplies maintenance.
+2. Header versioning: API-Version: 2 — cleaner URLs, harder to test in browser.
+3. Query param: /users?version=2 — easy to test, pollutes URLs.
+4. Content negotiation: Accept: application/vnd.myapp.v2+json — RESTfully correct.
+
+MIGRATION PLAN FOR MOBILE:
+For each breaking change, provide:
+1. Transition period: run v1 and v2 in parallel for N months.
+2. Client detection: identify client version from User-Agent or app header.
+3. Feature flag: gate new behavior on client version ≥ X.
+4. Sunset date: minimum 6 months notice for mobile, 12 months recommended.
+5. Monitoring: track request distribution by client version before sunset.
+
+MOBILE CLIENT IMPLEMENTATION:
+- Handle unknown enum values gracefully (don't crash — use UNKNOWN sentinel).
+- Handle missing optional fields (use defaults, not force-unwrap).
+- Version the local data model separately from the API model.
+  Map API v1 and v2 responses to the same domain model in the repository layer.
+
+Output a complete migration plan with timeline and client-side implementation guide.
+```

package/skills/cross-platform/clean-code-audit.md

@@ -0,0 +1,239 @@
+# Skill — /clean-code-audit
+
+**Platform:** Android / iOS / Flutter / React Native  
+**Slash Command:** `/clean-code-audit`  
+**Composable With:** AXIOM, SWIFT, DART, BRIDGE, MOBILE-HARNESS, APPFORGE
+
+---
+
+## Purpose
+
+Audit a mobile app or feature for clean code, maintainable architecture, file organization, naming, dependency boundaries, and model separation. Use this before merge, during refactors, or inside MOBILE-HARNESS after implementation.
+
+This skill is stricter than a normal code review. It looks for structural problems that make the app hard to scale, test, or hand off.
+
+---
+
+## Input Format
+
+```text
+COMMAND: /clean-code-audit
+PLATFORM: <Android | iOS | Flutter | React Native>
+ARCHITECTURE: <MVVM | MVI | Clean Architecture | BLoC | Redux | other>
+SCOPE:
+<files, folders, feature name, or pasted tree>
+CODE:
+<paste code or provide file list>
+RULES:
+<optional project-specific rules>
+```
+
+---
+
+## Skill Prompt
+
+```text
+Run a strict clean-code and architecture audit for the provided mobile app scope.
+
+Check these areas:
+
+1. MODEL AND TYPE ORGANIZATION
+- Data models, DTOs, entities, UI models, state classes, events, and navigation models must be in separate files when reused or non-trivial.
+- Do not define reusable data classes, sealed classes, enums, DTOs, or interfaces inside ViewModels, Activities, Fragments, Composables, SwiftUI Views, React components, or BLoCs.
+- Nested types are allowed only when they are private, tiny, and used exclusively by the enclosing type.
+- API response models must not be reused directly as domain models or UI models.
+- Domain entities must not import platform UI, networking, database, or serialization frameworks.
+
+2. LAYER BOUNDARIES
+- Presentation depends on domain abstractions, not concrete data sources.
+- ViewModels/BLoCs/controllers must not construct repositories, Retrofit/Dio/URLSession clients, Room/CoreData databases, SQLite handles, or HTTP clients directly.
+- Domain/use-case layer must not import Android Context, SwiftUI/UIKit, Flutter widgets, React Native APIs, database annotations, or JSON serializers.
+- Data layer may depend on API/database models and maps them to domain models.
+- UI layer may map domain models to UI models, but formatting logic should live in mappers or presentation models, not scattered through views.
+
+3. FILE AND PACKAGE STRUCTURE
+- One primary production type per file unless the extra types are private implementation details.
+- Feature files should be grouped by layer or clear feature slice.
+- File names must match the main type or responsibility.
+- Avoid dumping unrelated classes into `Utils`, `Helpers`, `Common`, `Extensions`, or `Manager` files.
+- Generated files, platform config, and test fixtures must not be mixed with production logic.
+
+4. NAMING AND RESPONSIBILITY
+- Names must reveal role: `UserDto`, `UserEntity`, `UserUiModel`, `UserRepository`, `FetchUserUseCase`.
+- Avoid ambiguous suffixes: `Data`, `Info`, `Manager`, `Helper`, `Util`, `Handler` unless the responsibility is narrow and clear.
+- Classes should have one reason to change.
+- Functions should do one thing and stay readable without excessive comments.
+
+5. STATE AND MUTABILITY
+- Expose immutable state to UI.
+- Keep mutable collections and mutable state private.
+- Avoid global mutable singletons for app state.
+- Prefer explicit state models over loose booleans and nullable fields.
+- UI state, events, and side effects should be clearly separated.
+
+6. DEPENDENCY INJECTION AND TESTABILITY
+- Constructor inject dependencies where possible.
+- Avoid service locators in business logic.
+- Avoid static/global calls for time, UUID, dispatchers, schedulers, analytics, storage, or networking; wrap them behind interfaces when needed.
+- Use interfaces/protocols/abstract classes at boundaries that need tests or replacement.
+- Business logic should be testable without launching UI or real network/database.
+
+7. PLATFORM-SPECIFIC CHECKS
+- Android/Kotlin: no repository creation in ViewModel; no Context in domain; DTOs/entities/UI models split; no large Composable with embedded business logic; no public MutableStateFlow.
+- iOS/Swift: no networking/storage inside SwiftUI View; no ObservableObject doing everything; DTOs/domain/view models split; no force unwraps in model mapping.
+- Flutter/Dart: no API model inside Widget/BLoC file when reused; no BuildContext in domain/repository; no large widget with business logic; separate entity/model/state/event files for non-trivial features.
+- React Native/TypeScript: no API DTOs reused as component props when UI model differs; no fetch/storage directly inside render components; no large component containing reducers, API code, and presentation together.
+
+8. DEAD CODE AND DUPLICATION
+- Flag duplicate models, duplicate mappers, unused abstractions, stale TODOs, unreachable branches, and copied validation rules.
+- Flag premature abstractions that hide simple logic without reducing real duplication.
+
+Severity:
+- CRITICAL: boundary violation that blocks testing, risks data corruption, or creates hidden runtime coupling.
+- WARNING: maintainability, scaling, or readability issue likely to cause future defects.
+- INFO: small cleanup or naming improvement.
+
+Output exactly:
+
+Table formatting rules:
+- Output normal Markdown. Do not wrap the final report in a fenced code block.
+- Keep every table cell short, ideally under 8 words.
+- Do not put full paragraphs, stack traces, code blocks, or multi-sentence fixes inside table cells.
+- Put long evidence, explanation, and fixes in `Finding Details`.
+- Use stable IDs (`CCA-001`, `CCA-002`) to connect summary rows to detail sections.
+
+CLEAN CODE AUDIT REPORT
+=======================
+Platform:
+Scope:
+Architecture:
+Result: PASS | FAIL
+
+Summary:
+- <short summary>
+
+Findings Summary:
+| ID | Severity | Area | File | Issue | Fix Summary |
+|---|---|---|---|---|---|
+
+Finding Details:
+### CCA-001 — <short title>
+- Severity:
+- Rule:
+- Location:
+- Problem:
+- Why it matters:
+- Fix:
+- Suggested file move, if any:
+
+Model Separation:
+| Type | Current Location | Expected Location | Result |
+|---|---|---|---|
+
+Layer Boundary Check:
+| Layer | Violation | Result |
+|---|---|---|
+
+Refactor Plan:
+1. <highest impact fix>
+2. <next fix>
+3. <next fix>
+
+Merge Gate:
+PASS only if no CRITICAL findings remain.
+```
+
+---
+
+## Example
+
+### Input
+
+```kotlin
+@HiltViewModel
+class ProfileViewModel @Inject constructor() : ViewModel() {
+    data class ProfileResponse(val id: String, val name: String)
+
+    private val api = Retrofit.Builder()
+        .baseUrl("https://api.example.com")
+        .build()
+        .create(ProfileApi::class.java)
+
+    val state = MutableStateFlow(ProfileResponse("", ""))
+}
+```
+
+### Output
+
+```text
+CLEAN CODE AUDIT REPORT
+=======================
+Platform: Android
+Scope: ProfileViewModel
+Architecture: MVVM + Clean Architecture
+Result: FAIL
+
+Summary:
+- ProfileViewModel owns API construction, exposes mutable state, and defines a reusable DTO inside the ViewModel.
+
+Findings Summary:
+| ID | Severity | Area | File | Issue | Fix Summary |
+|---|---|---|---|---|---|
+| CCA-001 | CRITICAL | Layer Boundaries | ProfileViewModel | Constructs Retrofit directly | Inject repository/use case |
+| CCA-002 | WARNING | Model Organization | ProfileViewModel | Nested reusable DTO | Move DTO to data model file |
+| CCA-003 | CRITICAL | State | ProfileViewModel | Public MutableStateFlow | Expose immutable StateFlow |
+
+Finding Details:
+### CCA-001 — ViewModel constructs networking dependency
+- Severity: CRITICAL
+- Rule: Layer Boundaries
+- Location: ProfileViewModel
+- Problem: The ViewModel constructs Retrofit and creates ProfileApi directly.
+- Why it matters: Presentation is coupled to networking and cannot be tested without real infrastructure.
+- Fix: Inject a ProfileRepository or FetchProfileUseCase through Hilt.
+- Suggested file move, if any: None.
+
+### CCA-002 — Reusable DTO is nested inside ViewModel
+- Severity: WARNING
+- Rule: Model Organization
+- Location: ProfileViewModel.ProfileResponse
+- Problem: ProfileResponse is an API/data model but lives inside a presentation class.
+- Why it matters: The DTO cannot be reused cleanly and mixes API contract with UI state.
+- Fix: Move it to `data/remote/model/ProfileResponse.kt` and map it to a domain `Profile`.
+- Suggested file move, if any: `ProfileViewModel` → `data/remote/model/ProfileResponse.kt`.
+
+### CCA-003 — Mutable state exposed publicly
+- Severity: CRITICAL
+- Rule: State and Mutability
+- Location: ProfileViewModel.state
+- Problem: UI callers can mutate ViewModel state directly.
+- Why it matters: External mutation breaks unidirectional data flow and makes bugs hard to trace.
+- Fix: Keep `MutableStateFlow` private and expose `StateFlow`.
+- Suggested file move, if any: None.
+
+Model Separation:
+| Type | Current Location | Expected Location | Result |
+|---|---|---|---|
+| ProfileResponse | ProfileViewModel | data/remote/model/ProfileResponse.kt | FAIL |
+
+Layer Boundary Check:
+| Layer | Violation | Result |
+|---|---|---|
+| Presentation | Constructs Retrofit/API client | FAIL |
+
+Refactor Plan:
+1. Move ProfileResponse into the data remote model package.
+2. Add ProfileRepository and inject it into ProfileViewModel.
+3. Expose immutable StateFlow from the ViewModel.
+
+Merge Gate:
+PASS only if no CRITICAL findings remain.
+```
+
+---
+
+## Usage Notes
+
+- Pair with `/security-audit` for pre-release quality gates.
+- Pair with platform reviewers when code is platform-specific: AXIOM, SWIFT, DART, or BRIDGE.
+- Inside MOBILE-HARNESS, run this after implementation and before marking a task complete.