# 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 - Unit 1 "SlpSoftware Client Setup" - Code Generation complete
- **Branch**: master (no feature branch created yet)

## 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 (build succeeded after 2 fixes; Core.Tests 196/196, new Api.Tests 4/4)

#### Unit 2: Offerings
- [ ] Functional Design
- [ ] NFR Requirements
- [ ] NFR Design
- [ ] Infrastructure Design
- [ ] Code Generation

#### Feature-wide
- [ ] Build and Test — EXECUTE (ALWAYS, after both units complete)

### 🟡 OPERATIONS PHASE
- [ ] Deployment Setup — EXECUTE
- [ ] Monitoring Setup — EXECUTE
- [ ] Production Readiness Validation — EXECUTE (ALWAYS, once phase reached)

## Current Status
- **Lifecycle Phase**: CONSTRUCTION
- **Current Stage**: Unit 1 "SlpSoftware Client Setup" — Code Generation complete
- **Next Stage**: Unit 2 "Offerings" (Functional Design → NFR Requirements → NFR Design → Infrastructure Design → Code Generation), then feature-wide Build and Test
- **Status**: Ready to proceed