SLP_Software/slp-modular-cms
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases Wiki Activity
Files
88770c5bd0694849c591d87dcebcc0bdaf984176
slp-modular-cms/aidlc-docs/features/local-dev-master-slave-setup/construction/plans/unit-2-frontend-dual-instance-tooling-code-generation-plan.md
T
SluijsensandClaude Sonnet 5 0447993181 Completes local-dev-master-slave-setup: dual-instance frontend tooling, module-capability gating, and master/slave protocol self-healing fixes 
Frontend (Unit 2 completion): dual dev-server tooling (pnpm dev:slave,
pnpm dev:all), per-instance browser tab titles, and a backend
capability check (SystemController + useSystemCapabilities +
ModuleGuard) so a Master-only page is hidden on a slave instance
instead of assuming every backend has every module.

Master/slave protocol fixes surfaced by actually running master and
slave side by side locally:
- Deactivating a CMS instance (Inactive) now releases the slave's
  master gate instead of leaving it stuck on its last pushed status.
- The periodic integrity check now also re-pushes status to every
  reachable slave (previously URL-verification only) and runs once
  immediately on startup.
- Added the originally-specified (but never implemented) slave-pull
  path: a slave now periodically polls its own status from the master
  (GET /api/v1/SlaveStatus) and fails open to Available if the master
  is unreachable for too long, complementing the existing push.
- The slave's own Settings page can no longer "successfully" change
  local availability while the master controls it; it's now locked
  with an explanatory banner and the backend rejects the write with
  409 instead of silently no-op'ing it.
- CMS instance status badges now match the dashboard's color/icon
  styling instead of a plain grey badge.

Also corrected the master-cms-module design docs to match this
as-built behavior, and flagged (without a full rewrite) a larger,
pre-existing divergence between its inception-stage application
design and what construction actually built.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-07-04 19:53:52 +02:00

3.1 KiB
Raw Blame History

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 existing frontend/.gitignore *.local pattern — verified via git 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-mode VITE_API_BASE_URL example

  • Step 2 — dev:slave npm script

    • Modify frontend/package.json: add "dev:slave": "vite --mode slave --port 5174" to the scripts section. Vite's mode-based env loading will load .env.slave.local when run with --mode slave (Vite loads .env.[mode].local in addition to .env.local; since both files would apply, and .env.local takes precedence per Vite's env-file priority for the same key when both exist for a mode, name the slave file .env.slave.local specifically — this file only loads when --mode slave is passed, so there is no conflict with the default .env.local used by pnpm dev)

  • 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:
      1. Starting the master backend (dotnet run --project src/SlpModularCms.Api --launch-profile https)
      2. Starting the slave backend (dotnet run --project src/SlpModularCms.Api.Slave --launch-profile https), noting it needs its own appsettings.local.json (from appsettings.local.json.example) with a separate local database
      3. Starting the master frontend (pnpm dev, port 5173) and, optionally, the slave frontend (pnpm dev:slave, port 5174)
      4. 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
      5. Cross-reference to this feature's requirements doc for anyone wanting the full rationale

  • Step 4 — Documentation summary

    • Create aidlc-docs/features/local-dev-master-slave-setup/construction/unit-2-frontend-dual-instance-tooling/code/summary.md documenting what was created/modified

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.
Reference in New Issue View Git Blame Copy Permalink