42 lines
1.7 KiB
Markdown
42 lines
1.7 KiB
Markdown
# Port Plan
|
|
|
|
## Goals
|
|
|
|
- Replace the custom FastAPI auth flow with Django sessions and `AUTH_USER_MODEL`
|
|
- Collapse the two legacy SQLite files into one relational schema owned by Django migrations
|
|
- Move domain logic out of route files into app models and services
|
|
- Replace the React monolith with a SvelteKit frontend structured by route and domain
|
|
- Prepare for `shadcn-svelte` instead of continuing with bespoke one-off UI patterns
|
|
|
|
## Target backend split
|
|
|
|
- `accounts`: user, role, permission, device, business-access concerns
|
|
- `core`: business, product, vendor, category master data
|
|
- `operations`: invoices, inventory, events, scheduling
|
|
- `reporting`: pre-aggregated dashboard tables and future ETL landing points
|
|
- `notifications`: reminders and inbox state
|
|
- `api`: thin JSON layer for the Svelte frontend
|
|
|
|
## Legacy migration strategy
|
|
|
|
1. Create Django migrations from the new model set.
|
|
2. Migrate the new database.
|
|
3. Run `import_legacy_data` to ingest the bundled legacy SQLite files in `data/legacy/`.
|
|
4. Rebuild auth credentials by forcing password resets for imported users.
|
|
5. Move ETL scripts into Django management commands later instead of repo-root scripts.
|
|
|
|
## Frontend direction
|
|
|
|
- SvelteKit routes mirror the existing user navigation
|
|
- app shell owns layout, not each page
|
|
- each large legacy page becomes a route plus smaller components
|
|
- fetch is centralized in `$lib/api/client.ts`
|
|
- visual primitives are compatible with `shadcn-svelte` conventions
|
|
|
|
## Known gaps
|
|
|
|
- Migrations were not generated, by design, because nothing heavy was run
|
|
- API coverage is partial; the high-risk domains are modeled first
|
|
- Scheduling and event recurrence still need dedicated service extraction
|
|
- ETL jobs have not been rewritten yet
|