Skip to content

[Improvement] Document the intended architecture and module boundaries #1026

Description

@RUKAYAT-CODER

Overview

docs/ holds 50+ files including five ADRs, but there is no top-level architecture document explaining how app/, src/components/, components/, src/pages/, src/screens/ and src/navigation/ relate. The audit found six modules covering feature flags and experimentation, three error boundaries, two location services, two course-progress stores, two sync-conflict paths and three UI component directories — all symptoms of an undocumented structure where the natural response to needing something is to create a new module rather than find the existing one.

Specifications

Features:

  • An architecture document covering layers, directories and dependency direction
  • A stated rule for where new code goes
  • The duplicate-module issues linked as the concrete cleanup backlog

Tasks:

  • Write docs/ARCHITECTURE.md describing each top-level directory and its role
  • Document the intended dependency direction (components → hooks → services → store)
  • Record why app/, src/pages/ and src/screens/ all exist, or consolidate them
  • Add a dependency-cruiser or import-boundary lint rule enforcing the direction
  • Link the document from README.md and CONTRIBUTING.md

Impacted Files:

  • docs/
  • README.md
  • CONTRIBUTING.md
  • docs/adr/README.md

Acceptance Criteria

  • A contributor can tell where new code belongs from the document alone
  • Dependency direction is enforced automatically
  • The three page/screen directories are explained or consolidated

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions