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>
This commit is contained in:
2026-07-04 02:07:35 +02:00
co-authored by Claude Sonnet 5
parent 8072025e0b
commit 274946dbff
36 changed files with 1380 additions and 14 deletions
@@ -0,0 +1,271 @@
# Audit Log — Local Dev Master/Slave Setup
## Initial Request — Feature Created
**Timestamp**: 2026-07-02T00:00:00Z
**User Input**: "Ik wil de tech-debt-backlog feature oppakken, maar ik wil ook nog iets erbij zetten zodat ik lokaal makkelijk een master en een slave cms kan laten draaien om de connectie tussen beide te kunnen testen"
**Follow-up clarification**: "Het is niet per se functioneel. Het is een run config die ik moet kunnen runnen op 2 verschillende poorten. De 1 met de master module en de andere niet. De slave moet allene het doel dienen de connectie op te zetten. De master moet de main CMS blijven waarin alle onderdelen gerunt en getest kunnen worden."
**AI Response**: "Besloten dit als aparte feature 'local-dev-master-slave-setup' te behandelen naast tech-debt-backlog, omdat het een losstaande dev-tooling/run-configuratie behoefte is (twee lokale instances op verschillende poorten — een met Modules.Master geladen, een zonder — om de master/slave connectie lokaal te kunnen testen) en geen tech-debt item. Taalvoorkeur: Engels voor documentatie, Nederlands voor gesprek."
**Context**: Feature aangemaakt; workspace detection uitgevoerd (brownfield, reverse-engineering artifacts uit `_shared/` hergebruikt). Volgende stap: Requirements Analysis.
---
## Conflict Detection
**Timestamp**: 2026-07-02T00:00:00Z
**User Input**: N/A (automated check)
**AI Response**: "⚠️ Potential Conflict Detected — feature 'local-dev-master-slave-setup' may affect components also touched by active feature 'tech-debt-backlog': shared component is Modules.Master. Resolution: developer handles at merge time; tech-debt-backlog's TD-001 (dead MasterModuleOptions properties) touches the same module this feature will add run configuration for — worth checking TD-001 isn't accidentally reintroduced when adding config for the second instance."
**Context**: Informational only, does not block progress.
---
## Requirements Analysis — Clarifying Questions Created
**Timestamp**: 2026-07-02T00:00:00Z
**User Input**: N/A (analysis step)
**AI Response**: "Investigated module loading (`ModuleOrchestrator.DiscoverModules` scans the build output folder for `SlpModularCms.Modules.*.dll` and loads every module found — no existing config toggle to exclude Master) and the existing Master/Slave connection mechanism (`Modules.Availability` already exposes the slave-side `MasterController`/`MasterAvailabilityService` used by any instance; `Modules.Master` is the master-side add-on with `CmsInstanceService`/`SlaveApiClient`). Created `inception/requirements/requirement-verification-questions.md` with 6 questions covering: module toggle mechanism, DB isolation, ports, launch method, frontend scope, and slave-registration approach — pre-filled with recommended answers (A) for the user to confirm or override."
**Context**: Requirements Analysis, Step 6 — awaiting user confirmation of clarifying questions before generating requirements.md.
---
## Requirements Analysis — Answers Received, Ambiguity Detected
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: "Ik heb de vragen beantwoord" — answers recorded in `requirement-verification-questions.md`: Q1=X (separate project sufficient for testing, but also wants a future production model of base API + drop-in module DLLs), Q2=A, Q3=A, Q4=A, Q5=B (frontend should also run against slave), Q6=A (manual, explicitly to test the Add CMS Instance UI flow).
**AI Response**: "Detected scope ambiguity in Q1 — it mixes a local-dev-only need (separate test host project without Modules.Master) with a much larger production packaging/deployment change (restructuring SlpModularCms.Api.csproj to not directly reference module projects, loading module DLLs from a drop-in folder at runtime). Created `requirement-verification-clarification-questions.md` asking whether to keep this feature scoped to local dev only (deferring the production plugin model to a future feature), expand scope to implement the production drop-in-DLL model now, or use the simpler config-driven Modules:Disabled toggle instead."
**Context**: Requirements Analysis, Step 6 — awaiting clarification before generating requirements.md. Other answers (Q2-Q6) accepted as-is, no further ambiguity detected there.
---
## Requirements Analysis — Clarification Resolved
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: "ik heb de vraag beantwoord" — Clarification Question 1 answered A: keep this feature scoped to local dev only (separate `SlpModularCms.Api.Slave` test host project, no `Modules.Master` reference); defer the "base API + drop-in module DLLs for production" idea to a future feature.
**AI Response**: "Scope confirmed. Proceeding to generate requirements.md with: separate slave host project, separate local databases per instance, master keeps existing ports (5284/7221) and slave gets 5285/7222, two `dotnet run --launch-profile` invocations to start both, frontend also configurable to point at the slave, and manual slave registration via the existing Add CMS Instance UI flow. The production drop-in-DLL plugin model is noted as explicitly out of scope / future work."
**Context**: Requirements Analysis, Step 6 gate passed — all ambiguities resolved. Proceeding to Step 7 (generate requirements.md).
---
## Requirements Analysis — Document Generated
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: N/A (generation step)
**AI Response**: "Generated `inception/requirements/requirements.md` with 4 functional requirements (slave-only host project `SlpModularCms.Api.Slave`, distinct launch/appsettings config per instance, frontend configurable against either instance, runbook documentation) and 4 non-functional requirements (no bootstrap-code duplication between host projects, DB isolation, local-only scope, secrets hygiene). Recorded the production drop-in-DLL plugin model as explicitly Out of Scope / future work per user's clarification answer."
**Context**: Requirements Analysis, Step 9 — presenting completion message, awaiting user approval before proceeding.
---
## Requirements Analysis — Approved
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: "Approve & Continue naar Workflow Planning"
**AI Response**: "Requirements approved. Proceeding to Workflow Planning."
**Context**: Requirements Analysis stage complete. Moving to Workflow Planning.
---
## Workflow Planning - Approval
**Timestamp**: 2026-07-03T00:00:00Z
**AI Prompt**: "Ready to proceed with this plan?"
**AI Response (plan summary)**: "Created `inception/plans/execution-plan.md`. Risk: Low. Recommended: EXECUTE Application Design (minimal — decide shared bootstrap extraction between master/slave hosts) and Units Generation (2 units: Unit 1 Backend dual-instance hosting, Unit 2 Frontend dual-instance tooling & runbook); SKIP User Stories and, per-unit, Functional Design / NFR Requirements / NFR Design / Infrastructure Design (no new business logic, NFRs already captured, no infrastructure involved). Code Generation and Build and Test always execute."
**User Response**: "Approve & Continue naar Workflow Planning" (approval for Workflow Planning stage received prior to plan presentation; awaiting explicit approval of this execution plan next)
**Status**: Plan created, awaiting user approval
**Context**: Workflow plan created with 4 stages to execute in Inception (Workflow Planning, Application Design, Units Generation) + Construction (2 units, Code Generation, Build and Test)
---
## Workflow Planning - Approved
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: "Approve & Continue naar Application Design"
**AI Response**: "Execution plan approved as proposed. Proceeding to Application Design."
**Context**: Workflow Planning stage complete. Moving to Application Design.
---
## Application Design — Plan Created
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: N/A (planning step)
**AI Response**: "Investigated `ModuleOrchestrator`/`ServiceCollectionExtensions`/`ApiPrefixConvention` — all public, all depend only on `SlpModularCms.Core.*` namespaces, none reference `Modules.Master`/`Modules.Identity`/`Modules.Availability` directly, confirming they can be extracted into a shared project. Created `inception/plans/application-design-plan.md` with 2 questions (extraction approach, shared project name/dependencies), pre-filled with recommended answers (A: new `SlpModularCms.Api.Hosting` class library referencing only `SlpModularCms.Core`, referenced by both host projects)."
**Context**: Application Design, Step 6 — awaiting user confirmation of plan questions before generating design artifacts.
---
## Application Design — Answers Received, Contradiction Detected
**Timestamp**: 2026-07-03T00:00:00Z
**User Input**: "Ik heb de vragen beantwoord, ga door" — Q1=C (MSBuild file-linking, wants "1 buildable project for production... no extra overhead for testing"), Q2=B (move shared code directly into existing `SlpModularCms.Core` project instead of a new project).
**AI Response**: "Detected that Q1 (file-linking) and Q2 (move into Core) are two different, mutually exclusive solutions to the same problem. Verified `SlpModularCms.Core.csproj` already has a `FrameworkReference` to `Microsoft.AspNetCore.App` plus JwtBearer/Identity EF packages, so moving the three classes into Core needs only two additional package references (`Asp.Versioning.Mvc`, `Microsoft.AspNetCore.OpenApi`) and no file-linking at all — B fully achieves the user's stated goal (one buildable copy, no overhead) better than C. Created `application-design-clarification-questions.md` asking the user to confirm B supersedes C."
**Context**: Application Design, Step 9 — awaiting clarification before generating design artifacts.
---
## Application Design — Contradiction Resolved
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: "Ja, A is correct, ga door"
**AI Response**: "Confirmed: move ModuleOrchestrator, ServiceCollectionExtensions, and ApiPrefixConvention into SlpModularCms.Core (new namespace SlpModularCms.Core.Hosting), adding Asp.Versioning.Mvc and Microsoft.AspNetCore.OpenApi package references to Core. No new shared project, no file-linking. Proceeding to generate application design artifacts."
**Context**: Application Design, Step 9 gate passed. Proceeding to Step 10 (generate design artifacts).
---
## Application Design — Artifacts Generated
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: N/A (generation step)
**AI Response**: "Generated components.md, component-methods.md, services.md, component-dependency.md, and consolidated application-design.md under inception/application-design/. Key decision: relocate ModuleOrchestrator/ServiceCollectionExtensions/ApiPrefixConvention into SlpModularCms.Core (new Core.Hosting namespace); SlpModularCms.Api.Slave added as a new host project referencing Core + Modules.Availability + Modules.Identity only. No new domain services; existing master/slave protocol reused unchanged."
**Context**: Application Design, Step 12 — presenting completion message, awaiting user approval before proceeding to Units Generation.
---
## Application Design — Approved
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: "Approve & Continue naar Units Generation"
**AI Response**: "Application design approved as proposed. Proceeding to Units Generation."
**Context**: Application Design stage complete. Moving to Units Generation.
---
## Units Generation — Plan Created
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: N/A (planning step)
**AI Response**: "Confirmed no dedicated test project exists for SlpModularCms.Api today (thin bootstrap code). Created inception/plans/unit-of-work-plan.md with 3 questions (confirm 2-unit split, confirm Unit 1 must be functionally complete before Unit 2 is meaningfully verified, confirm no dedicated test project needed for Api.Slave), pre-filled with recommended answers (A)."
**Context**: Units Generation, Part 1 Step 5 — awaiting user confirmation before generating unit artifacts.
---
## Units Generation — Plan Approved, Artifacts Generated
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: "Ik heb de vragen beantwoord" — all 3 questions confirmed A (2-unit split as proposed, sequential Unit 1 → Unit 2, no dedicated test project for Api.Slave), no ambiguities detected.
**AI Response**: "Generated unit-of-work.md (Unit 1: Backend dual-instance hosting; Unit 2: Frontend dual-instance tooling & runbook), unit-of-work-dependency.md (sequential, Unit 1 blocks Unit 2), and unit-of-work-story-map.md (requirements mapped directly to units since no user stories exist for this feature)."
**Context**: Units Generation, Part 2 complete. Presenting completion message, awaiting approval before Construction phase.
---
## Units Generation — Approved, Entering Construction Phase
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: "Approve & Continue naar Construction Phase"
**AI Response**: "Units generation approved. Inception phase complete. Entering Construction phase, starting with Unit 1 (Backend dual-instance hosting). Functional Design, NFR Requirements, NFR Design, and Infrastructure Design are all skipped per the approved execution plan (no new business logic, NFRs already captured, no infrastructure involved) — proceeding directly to Code Generation for Unit 1."
**Context**: Inception phase complete. Construction phase started.
---
## Code Generation Plan — Unit 1
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: N/A (planning step)
**AI Response**: "Verified `src/SlpModularCms.Api/appsettings.local.json` is gitignored (not tracked by git) via `git check-ignore`, confirming the existing secrets-hygiene pattern to replicate for the slave project. Created `construction/plans/unit-1-backend-dual-instance-hosting-code-generation-plan.md` with 6 steps: relocate bootstrap code into SlpModularCms.Core.Hosting, update SlpModularCms.Api to consume it, create SlpModularCms.Api.Slave project, add its config files (ports 5285/7222, separate DB, no MasterModule section), add to solution, write documentation summary."
**Context**: Code Generation Part 1 (Planning) for Unit 1 — awaiting user approval before generation.
---
## Code Generation Plan — Unit 1 — Approved
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: "Approve Plan"
**AI Response**: "Plan approved. Proceeding to Code Generation Part 2 (Generation) for Unit 1."
**Context**: Code Generation, Unit 1, Part 1 complete. Starting Part 2.
---
## Code Generation — Unit 1 — Complete
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: N/A (generation step)
**AI Response**: "Executed all 6 plan steps: relocated ModuleOrchestrator/ServiceCollectionExtensions/ApiPrefixConvention into SlpModularCms.Core.Hosting (needed extra usings for Microsoft.Extensions.Configuration/DependencyInjection/AspNetCore.Builder/Http since Core is a plain Sdk project, not Sdk.Web); updated SlpModularCms.Api/Program.cs; created SlpModularCms.Api.Slave project (Core + Modules.Availability + Modules.Identity only, no Master) with its own appsettings/launchSettings (5285/7222) and added it to SlpModularCms.sln. Discovered SlpModularCms.Modules.Identity.Tests referenced SlpModularCms.Api solely to test the two relocated classes — relocated those tests to Core.Tests/Hosting/ and dropped the now-unneeded Api ProjectReference. Verified: dotnet build succeeds; dotnet test passes all 4 existing suites unchanged (54+60+37+42); manually ran both hosts and confirmed via logs that master discovers 3 modules (Availability, Identity, Master) while slave discovers exactly 2 (Availability, Identity) — Master correctly excluded. Wrote construction/unit-1-backend-dual-instance-hosting/code/summary.md."
**Context**: Code Generation Part 2 complete for Unit 1. Presenting completion message, awaiting approval before Unit 2.
---
## Code Generation — Unit 1 — Approved
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: "Continue to Next Stage naar Unit 2"
**AI Response**: "Unit 1 approved. active-features.md already shows 🟢 Construction (updated at Units Generation approval), no further phase-transition update needed. Starting Unit 2 (Frontend dual-instance tooling & runbook) Code Generation planning."
**Context**: Unit 1 complete. Starting Unit 2.
---
## Code Generation Plan — Unit 2
**Timestamp**: 2026-07-04T00:00:00Z
**User Input**: N/A (planning step)
**AI Response**: "Verified via git check-ignore that frontend/.gitignore's existing *.local pattern already covers a new .env.slave.local file. Created construction/plans/unit-2-frontend-dual-instance-tooling-code-generation-plan.md with 4 steps: env files for slave mode, dev:slave npm script, runbook section in root README.md after 'Master CMS Module', documentation summary."
**Context**: Code Generation Part 1 (Planning) for Unit 2 — awaiting user approval before generation.
---