# 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.