Relocates ModuleOrchestrator, ServiceCollectionExtensions, and ApiPrefixConvention from SlpModularCms.Api into SlpModularCms.Core.Hosting so a new Master-less SlpModularCms.Api.Slave host project (ports 5285/7222) can share the same bootstrap code without duplicating it. This lets a developer run a master instance and a slave instance side by side locally to test the master/slave connection, without touching the existing master/slave protocol itself. Relocates the two orchestrator/convention test files from Modules.Identity.Tests to Core.Tests, dropping an incidental ProjectReference to SlpModularCms.Api that existed only for those tests. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.1 KiB
3.1 KiB
Code Generation Plan — Unit 2: Frontend Dual-Instance Tooling & Runbook
Unit Context
- Requirements covered: FR-3, FR-4, NFR-3, NFR-4 (see
inception/requirements/requirements.md) - Design source:
inception/application-design/component-dependency.md(data-flow diagram),unit-of-work.md - Dependencies: Unit 1 (Backend dual-instance hosting) — complete and verified (master discovers 3 modules, slave discovers 2, no Master)
- Blocks: Build and Test (final manual verification)
- Workspace root:
K:\Development\Projects\SlpModularCms
Steps
-
Step 1 — Frontend env files for slave mode
- Create
frontend/.env.slave.local(gitignored via existingfrontend/.gitignore*.localpattern — verified viagit check-ignore):VITE_API_BASE_URL=https://localhost:7222 - Modify
frontend/.env.example: add a second documented block showing the slave-mode value, alongside the existing master-modeVITE_API_BASE_URLexample
- Create
-
Step 2 —
dev:slavenpm script- Modify
frontend/package.json: add"dev:slave": "vite --mode slave --port 5174"to thescriptssection. Vite's mode-based env loading will load.env.slave.localwhen run with--mode slave(Vite loads.env.[mode].localin addition to.env.local; since both files would apply, and.env.localtakes precedence per Vite's env-file priority for the same key when both exist for a mode, name the slave file.env.slave.localspecifically — this file only loads when--mode slaveis passed, so there is no conflict with the default.env.localused bypnpm dev)
- Modify
-
Step 3 — Runbook documentation
- Modify root
README.md: add new section "Lokaal Master + Slave Draaien (Dev)" immediately after the existing "Master CMS Module" section, covering:- Starting the master backend (
dotnet run --project src/SlpModularCms.Api --launch-profile https) - Starting the slave backend (
dotnet run --project src/SlpModularCms.Api.Slave --launch-profile https), noting it needs its ownappsettings.local.json(fromappsettings.local.json.example) with a separate local database - Starting the master frontend (
pnpm dev, port 5173) and, optionally, the slave frontend (pnpm dev:slave, port 5174) - Using the existing "Add CMS Instance" dialog on the master frontend to register the slave (URL
https://localhost:7222) and confirm it shows as connected/healthy - Cross-reference to this feature's requirements doc for anyone wanting the full rationale
- Starting the master backend (
- Modify root
-
Step 4 — Documentation summary
- Create
aidlc-docs/features/local-dev-master-slave-setup/construction/unit-2-frontend-dual-instance-tooling/code/summary.mddocumenting what was created/modified
- Create
Notes
- No new tests for this unit — it's env/config/docs only, no testable logic.
- Final end-to-end manual verification (actually starting both instances with real local databases, registering the slave, confirming the connection) happens in Build and Test, since it requires a running local SQL Server/localdb the automated agent cannot fully provision headlessly.