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>
33 lines
2.1 KiB
Markdown
33 lines
2.1 KiB
Markdown
# Build Instructions — Local Dev Master/Slave Setup
|
|
|
|
## Prerequisites
|
|
- **Build Tool**: .NET 10 SDK
|
|
- **Dependencies**: NuGet packages restore automatically on build (no new external dependencies introduced by this feature)
|
|
- **Environment Variables**: None required to build (runtime config is via `appsettings.local.json`, see below)
|
|
- **System Requirements**: Same as the rest of the repository — no new system requirements
|
|
|
|
## Build Steps
|
|
|
|
### 1. Restore & Build
|
|
```powershell
|
|
dotnet build SlpModularCms.sln
|
|
```
|
|
|
|
### 2. Verify Build Success
|
|
- **Expected Output**: `Build succeeded.` with 0 errors (NuGet advisory warnings for `Microsoft.OpenApi` and a few `NU1510`/prune warnings are pre-existing and unrelated to this feature).
|
|
- **Build Artifacts**: `src/SlpModularCms.Api/bin/`, `src/SlpModularCms.Api.Slave/bin/` (new), plus all existing project outputs.
|
|
- **Common Warnings**: NU1903 (Microsoft.OpenApi advisory) and NU1510 (package pruning) appear across multiple projects — pre-existing, not introduced by this feature.
|
|
|
|
### Actual Result (this session)
|
|
Ran `dotnet build SlpModularCms.sln` — **Build succeeded**, 0 errors.
|
|
|
|
## Troubleshooting
|
|
|
|
### Build Fails with `CS0246` in `SlpModularCms.Core/Hosting/*.cs`
|
|
- **Cause**: `SlpModularCms.Core` is a plain `Microsoft.NET.Sdk` project (not `Sdk.Web`), so ASP.NET Core implicit usings (`Microsoft.Extensions.DependencyInjection`, `Microsoft.Extensions.Configuration`, `Microsoft.AspNetCore.Builder`, `Microsoft.AspNetCore.Http`) aren't automatically available like they are in `SlpModularCms.Api`.
|
|
- **Solution**: Already fixed during Code Generation — explicit `using` statements were added to `ServiceCollectionExtensions.cs`. If this recurs after further edits, add the missing explicit `using`.
|
|
|
|
### `SlpModularCms.Api.Slave` fails to start with a SQL connection error
|
|
- **Cause**: Missing `src/SlpModularCms.Api.Slave/appsettings.local.json` (gitignored, must be created locally per developer).
|
|
- **Solution**: Copy `appsettings.local.json.example` to `appsettings.local.json` and fill in your local SQL Server credentials, using a **different** `Database=` name than the master instance (e.g. `SlpModularCmsSlave`).
|