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>
2.7 KiB
2.7 KiB
Build and Test Summary — Local Dev Master/Slave Setup
Build Status
- Build Tool: .NET 10 SDK (
dotnet build) - Build Status: ✅ Success
- Build Artifacts:
src/SlpModularCms.Api.Slave/bin/(new), plus unchanged outputs for all existing projects - Build Time: ~5 seconds (incremental)
Test Execution Summary
Unit Tests
- Total Tests: 193 (54 + 60 + 37 + 42 across
Core.Tests,Modules.Availability.Tests,Modules.Identity.Tests,Modules.Master.Tests) - Passed: 193
- Failed: 0
- Coverage: Unchanged from before this feature (no new business logic; relocated code retains its existing tests)
- Status: ✅ Pass
Integration Tests
- Test Scenarios: 2 (module isolation; end-to-end master/slave connection via existing Add CMS Instance flow)
- Passed: 1 (module isolation — verified via manual
dotnet runof both hosts, confirmed via log output: master loads 3 modules, slave loads exactly 2, Master excluded) - Failed: 0
- Not Run: 1 (end-to-end connection scenario — requires a local SQL Server instance; no container runtime available in this sandboxed session. Documented as a manual step for the developer in
integration-test-instructions.mdand the rootREADME.mdrunbook.) - Status: ⚠️ Partial — the scenario this feature actually changes (module isolation) is fully verified; the scenario exercising the pre-existing, unmodified master/slave protocol requires manual follow-up.
Performance Tests
- Status: N/A — this feature is local developer tooling with no performance requirements (NFR-3, local-only scope).
Additional Tests
- Contract Tests: N/A — no API contracts changed
- Security Tests: N/A — no new attack surface;
appsettings.local.jsonsecrets-hygiene pattern (NFR-4) followed and verified viagit check-ignore - E2E Tests: See Integration Tests Scenario 2 above
Overall Status
- Build: ✅ Success
- All Automated Tests: ✅ Pass (193/193)
- Manual Follow-up Required: Yes — developer should run the end-to-end connection test (root
README.md, "Lokaal Master + Slave Draaien (Dev)") at least once with a real local SQL Server to confirm the full workflow before relying on it. - Ready for Operations: Yes (Operations is a placeholder for this project; no deployment/monitoring work applicable to local dev tooling)
Next Steps
- Developer runs the manual end-to-end verification (Scenario 2) locally to close out the one remaining unverified item.
- Feature is otherwise complete:
SlpModularCms.Api.Slaveexists and correctly excludes the Master module,SlpModularCms.Core.Hostingavoids code duplication between the two hosts, frontend tooling and documentation are in place.