slp-modular-cms/aidlc-docs/features/slpsoftware-api/aidlc-state.md

# AI-DLC State Tracking

## Project Information
- **Feature Name**: SlpSoftware Production API
- **Feature Slug**: slpsoftware-api
- **Project Type**: Brownfield
- **Start Date**: 2026-08-01T00:00:00Z
- **Current Stage**: CONSTRUCTION complete — both units done, feature-wide Build and Test green; ready for OPERATIONS phase
- **Branch**: feature/slpsoftware-api (PR #9 open against master)

## Workspace State
- **Existing Code**: Yes
- **Reverse Engineering Needed**: No — existing `_shared/reverse-engineering/` artifacts (2026-07-27) judged current enough for this feature's scope. The only more recent commit is a frontend-only folder restructure, unrelated to this feature.
- **Workspace Root**: K:\Development\Projects\SlpModularCms

## Reverse Engineering Status
- [x] Reverse Engineering — Reused existing artifacts, no rerun
- **Artifacts Location**: aidlc-docs/_shared/reverse-engineering/
- **Known staleness**: architecture.md still says "No CI/CD exists yet" — superseded by the (merged) `gitea-deployment-workflow` feature. Not relevant to this feature's own scope; verified the actual current `.gitea/workflows/*.yaml` directly instead of relying on that doc.

## Code Location Rules
- **Application Code**: Workspace root (NEVER in aidlc-docs/)
- **Feature Documentation**: aidlc-docs/features/slpsoftware-api/ only
- **Shared Artifacts**: aidlc-docs/_shared/
- **Structure patterns**: See code-generation.md Critical Rules; also `CLAUDE.md` / `AGENTS.md` solution-structure rules (Application/Modules, Tests/Modules, Clients)

## Language Configuration
- **Documentation Language**: English
- **Conversation Language**: User Language (Dutch)
- **Note**: Defaulted to Option A (matches every other feature in this workspace); not re-asked via question file. User may override at any time.

## External Reference (read-only, do not modify)
- **Workspace**: K:\Development\SlpSoftware\Projects\SlpSoftware
- **Handoff doc**: aidlc-docs/features/react-frontend/construction/react-frontend-app/functional-design/packages-api-handoff.md
- **Constraint**: This workspace is reference-only for this feature. No file in it may be created/edited/deleted unless the user explicitly asks.

## Extension Configuration
| Extension | Enabled | Decided At |
|---|---|---|
| Security Baseline | Yes | Requirements Analysis |
| Property-Based Testing | No | Requirements Analysis |

## Operations Configuration
- **Include Operations Phase**: Yes
- **Decided At**: Requirements Analysis
- **Note**: Per Q7, Operations phase for this feature includes retargeting the existing `gitea-deployment-workflow` CI/CD pipeline to `SlpModularCms.Api.SlpSoftware` (extend, do not duplicate) — see requirements.md NFR-Deploy section.

## Potential Conflicts (from Workspace Detection)
- **gitea-deployment-workflow** (status: 🟡 Operations, Production Readiness Validation still pending) — owns the CI/CD deploy pipeline (`.gitea/workflows/deploy-scp.yaml`, `continuous_integration.yaml`) and `operations/deployment/deployment-instructions.md`, all currently wired to `SlpModularCms.Api`. This feature's eventual deploy-retarget will need to touch that same pipeline. Resolution: coordinate at Workflow Planning / Operations time; do not duplicate that feature's Deployment Setup artifacts, extend them.
- **tech-debt-backlog** (status: 🔵 Inception) — touches `Modules.Master`, `Frontend`. Overlap is informational only; no action needed unless real conflicts surface during Code Generation.

## Execution Plan Summary
- **Total Stages**: 3 remaining Inception stages (Application Design, Units Planning, Units Generation), 6 Construction stages (per unit), 3 Operations stages
- **Stages to Execute**: Application Design, Units Planning, Units Generation, Functional Design (per unit), NFR Requirements (per unit), NFR Design (per unit), Infrastructure Design (per unit), Code Generation (always), Build and Test (always), Deployment Setup, Monitoring Setup, Production Readiness Validation
- **Stages to Skip**: None at the feature level — per-unit Construction stages will be individually assessed (e.g. Functional Design/Infrastructure Design likely skip for a pure hosting-extraction unit) once Units Generation defines the actual units. See `inception/plans/execution-plan.md` for full rationale.

## Stage Progress
### INCEPTION
- [x] Workspace Detection — Complete
- [x] Requirements Analysis — Complete
- [x] User Stories — Complete
- [x] Workflow Planning — Complete
- [x] Application Design — Complete
- [x] Units Planning — Complete
- [x] Units Generation — Complete (2 units: "SlpSoftware Client Setup", "Offerings")

### 🟢 CONSTRUCTION PHASE

#### Unit 1: SlpSoftware Client Setup
- [x] Functional Design — **SKIPPED** (no new data model/business rules — pure hosting-composition extraction)
- [x] NFR Requirements — Complete (new pipeline-level regression tests required; `CmsHostOptions` added, must never touch the Data Protection discriminator)
- [x] NFR Design — Complete (regression tests scoped to `Api` only; `CmsHostOptions` stays an empty placeholder for now)
- [x] Infrastructure Design — Complete (cutover target documented: same Pi/systemd units/ports/DB, only the deployed `.dll` changes at Operations time; `Api.SlpSoftware` gets its own isolated local dev database)
- [x] Code Generation — Complete and **approved** (build succeeded after 2 fixes; CI green after a further CI-only MariaDB fix; 372/372 tests passing across the whole solution)

#### Unit 2: Offerings
- [x] Functional Design — Complete (drag-and-drop + buttons for reorder; separate create/edit pages not modals; validation bounds set; delete confirmation; featured toggle available from both the form and the list row)
- [x] NFR Requirements — Complete (rate limiting on public GET only via new `offerings-public` policy; no HTTP caching; `LastModifiedByUserId` closes SECURITY-13's "who"; ≥80% coverage standard, same as `master-cms-module`)
- [x] NFR Design — Complete (multi-row operations transactional per-operation; rate-limiting attribute on public GET action only, following `AuthController` precedent; structured audit-log fields defined)
- [x] Infrastructure Design — **SKIPPED** (reuses existing MariaDB / per-module-migration infrastructure, nothing new to map — matches the preliminary assessment in `unit-of-work.md`; confirmed at this stage, no new deployment target/ports/services introduced)
- [x] Code Generation — Complete (backend: full `Modules.Offerings` module, 38 new tests, 414/414 solution-wide green; frontend: full `features/offerings` feature, 43 new tests, 254/254 suite-wide green, build+lint clean)

#### Feature-wide
- [x] Build and Test — Complete. Full solution: build succeeded, 414/414 tests passing. Frontend: `pnpm build` succeeded, `pnpm lint` clean, `pnpm test` 254/254 passing. No regressions.

### 🟡 OPERATIONS PHASE
- [x] Deployment Setup — Complete. `continuous_integration.yaml` retargeted to `Api.SlpSoftware` (D-15 cutover); `deploy-scp.yaml`/`rollback-plan.md` needed no changes; `deployment-instructions.md` § 1.6 updated with an explicit manual host-side action item for the user (edit the Pi's existing systemd units). No nginx/database/Gitea-variable changes (D-6).
- [ ] Monitoring Setup — EXECUTE
- [ ] Production Readiness Validation — EXECUTE (ALWAYS, once phase reached)

## Current Status
- **Lifecycle Phase**: OPERATIONS
- **Current Stage**: Deployment Setup — Complete (repo-side changes done; user still needs to manually update the Pi's two systemd unit files)
- **Next Stage**: Monitoring Setup, then Production Readiness Validation
- **Status**: Awaiting user approval to proceed