SluijsensandClaude Sonnet 5
0447993181
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>
42 lines
2.7 KiB
Markdown
42 lines
2.7 KiB
Markdown
# 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.
|