StoreManagement

Code map

Where things live, and the rule that decides where a new thing goes.

StoreManagement/ ├── app/ the Flutter app │ ├── lib/ │ │ ├── main.dart init Supabase + theme, run │ │ ├── app/ │ │ │ ├── app.dart MaterialApp.router │ │ │ ├── router.dart every route, and the legacy redirects │ │ │ ├── shell.dart rail + sections + pane; the 3 layouts │ │ │ └── nav.dart the three features, described once │ │ ├── core/ │ │ │ ├── app_refresh.dart invalidate everything, all 3 features │ │ │ └── cash/ │ │ │ └── computations.dart DailyCash arithmetic, pure │ │ └── features/ │ │ ├── auth/ login + change password │ │ ├── settings/ the cog at the foot of the rail │ │ ├── cash/ daily_entry, records, reports, staff │ │ ├── stock/ products, stock, audit, reports │ │ └── books/ accounts, journal, posting, ledger, reports │ ├── test/ 137 tests, mirroring lib/ │ ├── tool/ │ │ └── shell_preview.dart run the shell without credentials │ ├── android/ ios/ web/ platform targets │ └── pubspec.yaml ├── packages/ │ └── mblrc_shared/ theme, money, responsive helpers ├── supabase/ │ └── migrations/ 0000 … 0023, applied in order └── .github/workflows/deploy.yml test, build, ship to Cloudflare Pages

The rule

A file belongs to a feature unless two features need it. Then it moves to core/. If it needs no Flutter and no Supabase — pure arithmetic, formatting, models — it belongs somewhere it can be tested without pumping a widget.

Layer	Holds	Depends on
`features/<feature>/`	Pages, dialogs, that feature's providers and repositories	core, mblrc_shared, Supabase
`core/`	Anything two features need. Currently the refresher, plus DailyCash's arithmetic, which is core-adjacent for testing rather than sharing.	features (for provider handles only)
`app/`	Routing, the shell, the feature descriptions	features, mblrc_shared
`packages/mblrc_shared/`	Theme and palettes, peso formatting, responsive helpers, Supabase config, auth providers	Flutter only

Inside a feature

Each feature keeps the internal shape it had as a standalone app, which is why the merge was mostly file moves. A typical slice:

features/cash/ ├── daily_entry/ │ ├── daily_close_page.dart the screen │ ├── entry_dialogs.dart add/edit dialogs it opens │ ├── entry_models.dart plain Dart types │ ├── entry_repository.dart Supabase queries + the providers │ └── live_panel.dart a widget with enough logic to test alone ├── records/ the list pages, one per record type ├── reports/ monthly, daily, income, commission, gcash └── staff/

*_repository.dart and *_providers.dart are the only files that talk to Supabase. Pages read providers; they never build a query.

The shared package

File	What it gives you
`theme.dart`	Palettes, and buildTheme() — including the rail and bottom bar taking the accent colour rather than Material's default green.
`responsive.dart`	kNarrowWidth (620), kWideWidth (1000), isNarrow(), and the layout widgets that respond to them: PageHeader, FieldRow, StatCards, HorizontalTable.
`money.dart`	Peso formatting and the monospaced figure style used in every table.
`auth_providers.dart`	The Supabase client provider and the session stream the router listens to.
`brand_mark.dart`	The mblrc wordmark — the way back out to the main site.
`month_picker.dart`	The month selector every report page uses.

Why a package and not just a folder

It was a package because three separate applications needed to share it. With one app that reason is gone — but it also enforces a direction of dependency: mblrc_shared cannot import a feature, so nothing shop-specific can leak into it. That’s worth keeping.