architecture

Android Architecture

This skill defines how to design and review architecture changes in LogFox Android modules.

When to use this skill

Use this skill when at least one is true:

• The task touches multiple related Android files or modules.
• A new feature/module is added or existing module boundaries are changed.
• State management, ViewModel flow, reducers, effect handlers, or navigation patterns are updated.
• A PR needs architecture compliance review.

Skip this skill for tiny isolated edits (for example: text change, one-off constant rename).

Fast workflow

1. Identify impacted modules (api, impl, presentation, and core).
2. Apply the non-negotiable rules in this file.
3. Load only the reference sections needed for the task:
   • references/CHECKLIST.md (quick compliance pass)
   • references/REFERENCE_INDEX.md (choose targeted rule groups)
4. Implement changes with minimal surface area while preserving boundaries.
5. Validate with the checklist before finalizing.

Non-negotiable rules

1. Use modified TEA: immutable State, Command, SideEffect, pure Reducer, asynchronous EffectHandler.
2. Store.send() must be called from Main thread.
3. Every feature has both State and ViewState; mapping happens inside ViewModel via ViewStateMapper.
4. UI is passive: Fragments/Composables render state and emit events only; no business logic in views.
5. presentation depends only on api; never depend on another module's impl (except :app).
6. Use cases expose operator fun invoke; failable operations return Result<T>.
7. Repository interfaces live in api; data sources and implementations stay internal in impl.
8. Hilt bindings return interfaces, not implementation types.
9. Use SideEffects for navigation and one-off UI actions.
10. One file contains one top-level type; file name matches type name.

Reference map

• Quick compliance checklist: references/CHECKLIST.md
• Rule-group index: references/REFERENCE_INDEX.md

Expected output when applying this skill

When you perform architecture work, report:

1. Which rules were applied.
2. Which modules and layers were changed.
3. Any deliberate deviation and why.
4. Remaining risks or follow-up refactors.

Edge-case guidance

• If existing code violates these rules and full refactor is out of scope, make the smallest safe change and document the gap.
• If two rules conflict, prefer dependency boundaries and thread-safety first, then naming/style.
• If a feature is hybrid (Fragment + Compose), keep a single source of truth in ViewModel and preserve passive UI on both sides.