# NFR Requirements Plan — Unit 2: slave-availability-extension ## Unit Context **Unit**: `slave-availability-extension` **Inputs**: domain-entities.md, business-logic-model.md, business-rules.md (Unit 2 FD) **Key NFR concerns**: ApiKey storage security, static cache thread safety, test coverage, logging --- ## Questions Answer each question by filling in your choice after the `[Answer]:` tag. --- ### Q1 — ApiKey Storage: How should the slave store the master's ApiKey? The `MasterRegistration.ApiKey` is used to validate subsequent master calls (BR-SLAVE-02/04/06). How should it be stored in the DB? A) **Plain text** — store as-is from the `X-Master-Api-Key` header. Simple; compare directly on each request. Acceptable given the key is an infrastructure credential (not user password) and the DB should be secured. B) **SHA-256 hash** — store `SHA256(apiKey)` and compare `SHA256(incoming)` on each request. No plain-text at rest; constant-time comparison prevents timing attacks. C) **ASP.NET Core Data Protection** — encrypt using `IDataProtectionProvider` (same pattern as `ApiKeyProtector` in Unit 1). Reversible; consistent with master-side pattern. D) Other [Answer]: C --- ### Q2 — Static Cache Thread Safety: How should `_masterIsAvailable` and `_masterDisableMessage` be protected? These static fields are read on every request (high frequency) and written only when the master pushes status (rare). What thread safety approach is appropriate? A) **`volatile` fields** — `private static volatile bool _masterIsAvailable = true` and `private static volatile string? _masterDisableMessage`. Sufficient for atomic single-field reads/writes in .NET; no lock overhead per request. Consistent with `PersistentAvailabilityService`'s existing circuit breaker pattern. B) **`lock` statement** — lock a `static readonly object _lock` around both reads and writes. Explicit and safe; slight overhead on every request read. C) Other [Answer]: A --- ### Q3 — Test Coverage: What should be excluded from coverage in this unit? Which components in Unit 2 should receive `[ExcludeFromCodeCoverage]`? A) **Module/wiring only** — only the `AvailabilityModule` changes (service registrations, migration call) and EF migration files. All service, controller, and middleware logic is covered. B) **Module + DTOs** — `AvailabilityModule` changes + DTO/request/response records + EF migration files. Consistent with Unit 1 pattern. C) Other [Answer]: B --- ### Q4 — Logging: What log levels apply to the new slave-side logic? A) **Minimal** — only Error for unexpected exceptions. Keep logs quiet since master calls are frequent background operations. B) **Structured per scenario** — follow the same table approach as Unit 1: - `Warning` — API key mismatch on any endpoint - `Warning` — master gate blocked a request (log path + disable message) - `Information` — master registered successfully (first registration) - `Information` — status update received (isAvailable value) - `Debug` — get-registered-url called C) Other [Answer]: B --- ## Execution Steps - [x] **Step 1** — Analyze answers; flag ambiguities - [x] **Step 2** — Generate `nfr-requirements.md` - [x] **Step 3** — Generate `tech-stack-decisions.md` - [ ] **Step 4** — Update `aidlc-state.md` - [ ] **Step 5** — Present completion message for approval --- *Artifact path*: `aidlc-docs/features/master-cms-module/construction/plans/slave-availability-extension-nfr-requirements-plan.md`