Files

T

SluijsensandClaude Sonnet 5 274946dbff Adds SlpModularCms.Api.Slave for local master/slave dev testing (Unit 1)

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>

2026-07-04 02:07:35 +02:00

2.5 KiB

Raw Permalink Blame History

Unit of Work Plan — Local Dev Master/Slave Setup

Plan

Generate unit-of-work.md with unit definitions and responsibilities
Generate unit-of-work-dependency.md with dependency matrix between units
Generate unit-of-work-story-map.md mapping requirements (no user stories exist for this feature — User Stories stage was skipped) to units
Validate unit boundaries and dependencies

Context

No user stories exist for this feature (skipped as pure dev tooling). Units are mapped directly from the Functional Requirements in requirements.md and the components in application-design/. SlpModularCms.Api has no dedicated test project today (it's thin bootstrap code, exercised indirectly via module test suites and manual verification) — the same pattern is expected to apply to SlpModularCms.Api.Slave.

Questions

Question 1

Confirm the two-unit split proposed in the execution plan:

A) Unit 1 — Backend dual-instance hosting: relocate ModuleOrchestrator/ServiceCollectionExtensions/ApiPrefixConvention into SlpModularCms.Core.Hosting; add SlpModularCms.Api.Slave project (no Modules.Master reference); add both projects' launchSettings.json/appsettings*.json; add to solution. Unit 2 — Frontend dual-instance tooling & runbook: .env.slave.local support, dev:slave npm script, runbook documentation. B) Different split — describe after Answer: tag below. X) Other (please describe after Answer: tag below)

Question 2 (Dependencies)

Unit 2 (frontend) needs a running slave backend to be meaningfully tested against. Should Unit 2 still be generated even though Unit 1 must be functionally verified first?

A) Yes — generate Unit 1 fully (including a working build) before starting Unit 2's code, since Unit 2's manual verification depends on Unit 1 existing and running. B) Generate both units' code in parallel/independently, verify together at the end during Build and Test. X) Other (please describe after Answer: tag below)

Question 3 (Technical Considerations)

Does SlpModularCms.Api.Slave need its own dedicated test project (mirroring SlpModularCms.Api, which currently has none)?

A) No — no dedicated test project, consistent with SlpModularCms.Api today (thin bootstrap code covered indirectly by module test suites; this feature adds no new business logic to unit test). B) Yes — add a new SlpModularCms.Api.Slave.Tests project. X) Other (please describe after Answer: tag below)

2.5 KiB Raw Permalink Blame History