SluijsensandClaude Sonnet 5
274946dbff
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>
1.2 KiB
1.2 KiB
Unit of Work Dependency Matrix — Local Dev Master/Slave Setup
| Unit | Depends On | Blocks |
|---|---|---|
| Unit 1 — Backend dual-instance hosting | Application Design (approved) | Unit 2 |
| Unit 2 — Frontend dual-instance tooling & runbook | Unit 1 (needs a working, running slave backend) | Build and Test (final manual verification) |
Rationale
- Unit 1 is the critical path: without
SlpModularCms.Api.Slaveactually building and running on its own ports/database, there is nothing for Unit 2's frontend config or runbook to point at or verify against. - Unit 2 has no reverse dependency — it does not require any change to Unit 1 once Unit 1 is complete.
- No parallelization opportunity given the small scope and single-developer nature of this feature (per Q2 = A, sequential execution was explicitly confirmed).
Update Strategy
- Update Approach: Sequential (Unit 1 then Unit 2)
- Critical Path: Unit 1
- Coordination Points: The slave backend's HTTPS URL (
https://localhost:7222) is the one piece of information Unit 2 needs from Unit 1's output. - Testing Checkpoints: After Unit 1 — verify both backends build/start independently. After Unit 2 — verify the full manual master/slave connection flow via the runbook.