Completes Operations phase: Monitoring Setup and Production Readiness Validation

Confirms existing tag-based Sentry alerting and domain-based UptimeRobot/
Umami monitoring already cover the Offerings module and the Api.SlpSoftware
cutover with no new configuration. Closes the SECURITY-13 audit-trail open
item and records the final production-readiness traceability, completing
the slpsoftware-api feature's AI-DLC lifecycle.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FWyStNL2ZsjrS7FLd7xvvN

aidlc-docs/features/slpsoftware-api/operations/production-readiness/production-readiness-validation.md

@@ -0,0 +1,106 @@
+# Production Readiness Validation — slpsoftware-api
+
+Final Operations-phase gate. Validates the feature against its own Requirements Analysis artifacts
+(traceability, not re-litigation) plus what actually running in production requires beyond passing
+tests.
+
+## 1. Functional Requirements Traceability
+
+| FR | Status | Evidence |
+|---|---|---|
+| FR-1 New Client Project `Api.SlpSoftware` | ✅ Done | Unit 1, merged into `feature/slpsoftware-api` |
+| FR-2 Module Composition (Identity/Availability/Master/Offerings) | ✅ Done | `Api.SlpSoftware.csproj` project references |
+| FR-3 Shared Hosting Pipeline Extraction (`CmsHost`) | ✅ Done | `SlpModularCms.Core.Hosting.CmsHost`, used by both `Api` and `Api.SlpSoftware` |
+| FR-4/FR-5 `Offerings` module + admin CRUD | ✅ Done | Unit 2, `SlpModularCms.Modules.Offerings` |
+| FR-6 Public `GET /api/v1/offerings` | ✅ Done | `OfferingsController.GetOfferings`, `[AllowAnonymous]` |
+| FR-7 Admin CRUD + reorder, `AdminOnly` | ✅ Done | `OfferingsController`'s remaining actions |
+| FR-8 Reference content documented | ✅ Done | `requirements.md`'s reference-content table (3 packages); entering it into the running system is an explicit user-owned manual step (Scope Boundaries) |
+| FR-9 CI/CD retarget (cutover) | ✅ Done (repo side) | `continuous_integration.yaml` retargeted; **host-side systemd edit still pending — see § 4** |
+
+## 2. Non-Functional Requirements
+
+| NFR | Status | Evidence |
+|---|---|---|
+| NFR-1 No nginx changes | ✅ Confirmed | D-6; verified at Deployment Setup — proxy forwards to a port, not an executable |
+| NFR-2 Module test coverage | ✅ Met | 38 tests in `Modules.Offerings.Tests` covering entity/context, repository, service (all 4 business rules), controller (routes/auth) |
+| NFR-3 Long-term reusability (no SlpSoftware-specific baking-in) | ✅ Confirmed | Module named `Offerings` (D-9), no hardcoded tenant/site assumptions in entity/service/controller |
+| NFR-4 Property-based testing not required | ✅ N/A by design | D-12, example-based tests only throughout |
+
+## 3. User Story Coverage
+
+All 12 user stories (US-01–US-12) implemented and covered by tests: US-01/02/03 (public list,
+featured highlight, empty-state resilience), US-04–US-07 (create/edit/delete, including
+last-remaining-offering deletion), US-08/US-09 (drag-and-drop and button-based reorder), US-10
+(featured exclusivity), US-11 (validation feedback), US-12 (`AdminOnly` role gate).
+
+## 4. Security Compliance — Final Status
+
+All 15 rules from `requirements.md`'s Security Compliance table are **Addressed**, **Pre-existing/
+unchanged**, or **N/A**, with one item to formally close:
+
+**SECURITY-13 (Software and data integrity) — RESOLVED.** Requirements Analysis logged this as an
+open item pending Functional/NFR Design. Resolution: `Offering.LastModifiedByUserId` +
+`CreatedAt`/`UpdatedAt` (NFR-OFF-03) provide a minimal "who + when" audit trail on every
+create/update/delete. Explicitly **not** a full before/after audit-log table — that remains a known,
+accepted scope boundary (documented in `nfr-requirements.md`), not a gap discovered late.
+
+No other Security Compliance item changed status during Construction or Operations.
+
+## 5. Build, Test, and Code Quality
+
+- Backend: full solution build succeeded; **414/414 tests passing** across 6 test projects, no
+  regressions (verified at the feature-wide Build and Test stage, re-confirmed after two live-testing
+  bug fixes during Unit 2's post-completion review — record-validation targeting and the drag overlay
+  fix — neither of which touched test-covered logic paths differently than already tested).
+- Frontend: `pnpm build` succeeded, `pnpm lint` clean, **254/254 tests passing** across 41 files.
+- Migration safety (rollback plan's D-26 requirement — forward-compatible, non-destructive): the
+  `InitialCreate` migration for `OfferingsDbContext` is a single `CREATE TABLE` with no `ALTER` on
+  any existing table — trivially satisfies this by construction. A rollback to a pre-Offerings
+  release simply leaves the `OfferingsOfferings` table unused, never touched destructively.
+
+## 6. Deployment Readiness
+
+Repo-side: complete (Deployment Setup stage). **Two items require action outside this repository
+before the cutover is live**:
+
+1. **Host action (blocking for production traffic, not for CI)**: edit
+   `~/.config/systemd/user/slpsoftware-test.service` and `slpsoftware-production.service` on
+   pi-main, changing `ExecStart`'s target from `SlpModularCms.Api.dll` to
+   `SlpModularCms.Api.SlpSoftware.dll` (exact steps: `deployment-instructions.md` § 1.6, restated in
+   `operations/deployment/deployment-instructions.md`). Until this is done, a successful CI deploy
+   uploads the new build correctly, but the running service keeps executing the old `Api.dll` from
+   that release directory.
+2. **Content entry (not blocking, user's own task)**: the three reference offerings (FR-8's table)
+   need to be entered through the new admin UI once live — no auto-seed exists by design (D-5).
+
+## 7. Monitoring Readiness
+
+Confirmed at the Monitoring Setup stage: no new Sentry alert rules, UptimeRobot monitors, or Umami
+entries needed. Existing tag-based/domain-based monitoring already covers the new rate-limit policy,
+the new `AdminOnly` endpoints, and the cutover itself (see `operations/monitoring/monitoring-instructions.md`).
+
+## 8. Rollback Readiness
+
+`gitea-deployment-workflow`'s existing `rollback-plan.md` applies unchanged: fast rollback via the
+`current` symlink (no rebuild), rebuild-and-redeploy for anything older, database restore from the
+pre-deploy backup. None of its mechanisms are `.dll`-name-specific, so the D-15 cutover doesn't
+require a rollback-plan update, and a rollback of this feature's first production deploy would land
+back on the old `Api.dll` release exactly as any other rollback would.
+
+## 9. Known, Accepted Limitations (Not Defects)
+
+- No HTTP caching on the public endpoint (NFR-OFF-02, Q2=B) — deliberate, revisit if traffic ever
+  makes it worth it.
+- No full audit-log table for Offerings mutations (SECURITY-13's resolution scope, § 4 above).
+- Sequential (non-transactional) single-row saves remain outside the three multi-row operations'
+  transaction boundary — intentional per NFR Design Pattern 1's scope.
+- `SlpModularCms.Api`'s own pipeline regression tests (`Api.Tests`, NFR-CS-01) don't separately cover
+  `Api.SlpSoftware` — accepted trade-off from Unit 1, unchanged by this feature.
+
+## 10. Verdict
+
+**Ready for production, contingent on completing the one host-side action in § 6.1.** All
+functional and non-functional requirements are implemented and traced; all tests pass; security
+compliance is fully addressed with its one open item formally resolved; monitoring and rollback
+require no changes. This is a documentation/traceability gate — it does not re-run any build or test
+already verified at the Build and Test stage.