docs(cluster-infrastructure): resolve ClusterInfrastructure-001 — document that the Host owns the Akka bootstrap

This commit is contained in:
Joseph Doherty
2026-05-16 20:12:24 -04:00
parent 2ba5d5d578
commit cac8aebe9f
3 changed files with 37 additions and 6 deletions

View File

@@ -8,7 +8,7 @@
| Last reviewed | 2026-05-16 |
| Reviewer | claude-agent |
| Commit reviewed | `9c60592` |
| Open findings | 8 |
| Open findings | 7 |
## Summary
@@ -52,7 +52,7 @@ adequately for what exists.
|--|--|
| Severity | High |
| Category | Design-document adherence |
| Status | Open |
| Status | Resolved |
| Location | `src/ScadaLink.ClusterInfrastructure/ServiceCollectionExtensions.cs:9`, `src/ScadaLink.ClusterInfrastructure/ServiceCollectionExtensions.cs:16` |
**Description**
@@ -123,9 +123,20 @@ of two substantial decisions, both requiring the user:
shared `ClusterOptions` contract. That fix is a design-doc edit, also outside this
module's permitted edit scope.
Either path is a deliberate architecture decision, not a bug fix, so per
REVIEW-PROCESS.md §2 this finding is left **Open** and surfaced for the user to decide.
No code change was made. Module test suite verified green (3 passed) at re-triage time.
Either path is a deliberate architecture decision, not a bug fix. The decision was
surfaced to the user, who chose **option 2 — accept the current placement**: the Akka
bootstrap stays in the Host (the single deployable binary that performs all actor-system
bring-up), and the design docs are corrected to record the true ownership.
**Resolved** — fixing commit `<pending>`, date 2026-05-16. The finding was a design-doc
drift, not missing behaviour. `docs/requirements/Component-ClusterInfrastructure.md` now
carries an "Implementation Note — Code Placement" section stating that the
`ScadaLink.ClusterInfrastructure` project owns the `ClusterOptions` configuration model
while `ScadaLink.Host` owns the Akka bootstrap, HOCON generation, split-brain-resolver
wiring, `CoordinatedShutdown` integration, and active-node health checks. The README
component table (row 13) was updated to match. No code change was required — the
documented cluster behaviour already exists and is exercised; only the doc's
module-ownership claim was wrong. Module test suite green (3 passed).
### ClusterInfrastructure-002 — No-op DI extension methods report success while doing nothing