Skip to content

Separate application composition from dashboard feature - #52

Merged
rd-code-23 merged 1 commit into
mainfrom
refactor/application-structure
Aug 24, 2026
Merged

rd-code-23 merged 1 commit into
mainfrom
refactor/application-structure

Conversation

@rd-code-23

Copy link
Copy Markdown
Owner

Problem

Application-wide composition was stored under features/dashboard, even though the shell, identity, and access boundary are shared by every protected route. This made the dashboard feature appear responsible for routines, history, settings, authentication access, and the overall application frame.

The same folder also contained SectionLanding, a generic abstraction used only to render temporary headings for unfinished routes.

What changed

  • Added apps/web/src/app/ for application-wide composition.
  • Moved ApplicationShell and its test into src/app.
  • Moved ApplicationIdentity into src/app.
  • Renamed DashboardAccessBoundary to ApplicationAccessBoundary and moved it and its test into src/app.
  • Updated all affected imports and test names.
  • Removed the premature SectionLanding abstraction.
  • Made the routines, history, and settings routes own their temporary headings directly.
  • Documented the boundary between app/ and features/ in AGENTS.md.

Resulting ownership

src/app/ contains application-wide composition: the protected shell, access boundary, and identity shared across routed features.

src/features/dashboard/ now contains only the dashboard landing page and its focused test. Other product capabilities remain under their own feature folders as they are implemented.

Why this design

application is not a product feature, so placing it under features/application would still blur the meaning of the feature directory. A top-level app/ folder communicates that these modules compose and govern the protected React application rather than implement one user-facing capability.

The access boundary is also renamed because it protects the entire _app route tree, not only /dashboard.

Removing SectionLanding avoids preserving an abstraction whose only job was sharing one heading. The temporary duplication will disappear as each real feature page is implemented, and each route now clearly owns its placeholder.

Behavior

This is an organization-only refactor. Authentication resolution, guest access, profile exit, navigation, dashboard introduction, and responsive behavior are unchanged.

Verification

  • pnpm --filter @goforlift/web typecheck
  • pnpm --filter @goforlift/web test -- --reporter=dot — 21 tests passed
  • pnpm --filter @goforlift/web lint
  • Prettier checks for changed files
  • git diff --check

@rd-code-23
rd-code-23 merged commit 86c0f70 into main Aug 24, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant