Files
slp-modular-cms/aidlc-docs/features/local-dev-master-slave-setup/construction/build-and-test/build-and-test-summary.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

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 run of 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.md and the root README.md runbook.)
  • 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.json secrets-hygiene pattern (NFR-4) followed and verified via git 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.Slave exists and correctly excludes the Master module, SlpModularCms.Core.Hosting avoids code duplication between the two hosts, frontend tooling and documentation are in place.