Adds the Offerings module and retargets the CI/CD pipeline to Api.SlpSoftware

Implements Unit 2 "Offerings" (backend module, admin CRUD UI with
drag-and-drop reordering, public GET /api/v1/offerings endpoint) and
executes the feature's D-15 CI/CD cutover, switching the deploy
pipeline's build/publish target from SlpModularCms.Api to
SlpModularCms.Api.SlpSoftware.

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

aidlc-docs/features/slpsoftware-api/audit.md

@@ -575,3 +575,327 @@
 **Context**: Real bug fix, and a boundary call: `.gitea/workflows/continuous_integration.yaml` is nominally owned by the `gitea-deployment-workflow` feature, but this specific change (making the `backend-test` gate pass for a test project this feature introduced) is Construction/Build-and-Test correctness for `slpsoftware-api`, not a deploy-target retarget (D-15, still deferred to Operations) -- judged in-scope to fix directly rather than blocking the PR on a separate feature's process.
 
 ---
+
+## CI Fix, Round 2: `services:` Block Didn't Actually Work — Diagnosed From Real Logs, Not Re-Guessed
+
+**Timestamp**: 2026-08-02T12:15:00Z
+
+**User Input**: N/A — proactively monitored the pushed fix's CI run via the Gitea API (polling with scheduled wakeups) rather than waiting to be asked.
+
+**AI Response**: "The `services:` block fix from the previous entry did NOT actually work — `backend-test` failed again with the exact same 'Access denied ... using password: YES' error. Rather than re-guessing, fetched the real job log via the Gitea API (`/repos/.../actions/jobs/{id}/logs`) and found the actual cause: this runner (`raspberry-pi-arm64`, self-hosted) runs job AND service containers in Docker host-network mode ('--network and --net in the options will be ignored' appears verbatim in the log), so the `ports: - 3306:3306` mapping was silently ignored — the mariadb:11 service ended up bound directly to the host's own port 3306, which something else on this runner already answers on, rejecting our password because it was never the container we just started. Replaced the `services:` block with an explicit `docker run` step publishing on host port 3307 instead (avoiding the collision entirely) plus a readiness-wait loop, and updated the connection string env var to match. Verified the whole thing locally before pushing again: first attempt at the readiness check used `mysqladmin ping`, which doesn't exist in the `mariadb:11` image (confirmed via `podman exec` — only `mariadb-admin` and `healthcheck.sh` are present); fixed the command name, then confirmed all 4 `Api.Tests` pass end-to-end against a container on port 3307 exactly as CI will use it, before committing."
+
+**Context**: Second-round CI fix, verified against real job logs and a local reproduction rather than trusting the first, unverified guess. Awaiting the user pushing this commit so CI reruns.
+
+---
+
+## CI Fix Confirmed Green — Unit 1 Code Generation Approved
+
+**Timestamp**: 2026-08-02T12:10:00Z
+
+**User Input**: "alles slaagt dus ga verder" (after monitoring the Gitea Actions run for commit b6e9c07 to completion via the API: `backend-test` succeeded in 7m35s, all 372 tests passed — 82 Availability, 57 Master, 196 Core, 37 Identity, 4 new Api.Tests)
+
+**AI Response**: "Unit 1 'SlpSoftware Client Setup' Code Generation approved, CI green on the feature branch. Proceeding to Unit 2 'Offerings'."
+
+**Context**: Construction, Unit 1 Code Generation stage complete and approved (including the CI fix round-trip). Proceeding to Unit 2 'Offerings' per-unit loop, starting with Functional Design.
+
+---
+
+## Construction — Unit 2 "Offerings" Functional Design: Plan Created
+
+**Timestamp**: 2026-08-02T12:20:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Investigated before drafting questions: read the existing `frontend/src/features/cms/` folder (Master-module admin UI) as the closest structural precedent for an admin list+CRUD screen in this codebase, and checked `frontend/package.json` for a drag-and-drop library — none exists, meaning US-08 (drag-and-drop reorder) would introduce a genuinely new frontend dependency, not something already available. Created `construction/plans/offerings-functional-design-plan.md` (checklist only, per functional-design.md's rule that plans and questions live in separate files) and a dedicated `construction/plans/offerings-fd-questions.md` with 5 questions: whether to add a new drag-and-drop dependency now or ship button-based reorder only for v1, whether to follow the existing cms-feature's list+modal page pattern, concrete validation length bounds for SECURITY-05 (none had been set numerically yet), whether to confirm before delete given soft-delete has no exposed restore UI, and the UI trigger for the featured flag (form toggle vs. list-row action)."
+
+**Context**: Construction, Unit 2, Functional Design stage, Steps 1-5. Awaiting user answers.
+
+---
+
+## Construction — Unit 2 Functional Design: Answers Received
+
+**Timestamp**: 2026-08-02T12:30:00Z
+
+**User Input**: "ik heb de vragen beantwoord" (offerings-fd-questions.md: Q1=A both drag-and-drop and buttons; Q2=X custom — separate pages/routes (effectively option B), reasoning that the CMS is master-only tooling not meant for reuse across other sites so cross-feature UI consistency matters less; Q3=A validation bounds as proposed; Q4=A confirm before delete; Q5="kan A en B beide?" — can it be both A and B)
+
+**AI Response**: "Q2 and Q5 needed resolution, not re-asking. Q2's custom answer is a clear, actionable decision (separate create/edit pages, not modals) with stated reasoning — no ambiguity. Q5 is a direct question back, not a vague answer — resolved it: yes, both can coexist, because the 'featured' flag is just a field on the existing Create/Update flow (per application-design/component-methods.md), so a quick star-icon action in the list row can reuse the same Update call with the row's already-loaded data (only the Featured field changed) — no new backend endpoint or business logic needed, the exclusivity enforcement in the service layer already covers either UI entry point identically. Proceeding to generate all 4 Functional Design artifacts with these 5 resolved decisions."
+
+**Context**: Construction, Unit 2, Functional Design stage, Step 6-7. No follow-up questions needed. Proceeding to artifact generation.
+
+---
+
+## Construction — Unit 2 Functional Design: Artifacts Generated
+
+**Timestamp**: 2026-08-02T12:40:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved plan)
+
+**AI Response**: "Generated `domain-entities.md` (Offering entity with 12 fields incl. added CreatedAt/UpdatedAt audit timestamps, partially closing the SECURITY-13 open item from requirements.md; two DTO projections), `business-rules.md` (4 Mermaid decision-flow rules: featured exclusivity, soft-delete-never-blocked, reorder boundaries, field validation), `business-logic-model.md` (5 sequence diagrams: create/update, delete-with-confirmation, drag-and-drop reorder, button reorder, list-row featured toggle), and `frontend-components.md` (new `features/offerings/` folder mirroring the existing `features/cms/` pattern, component hierarchy diagram, per-component props/state/API calls, service hooks table). Marked all 5 plan steps complete. Updated aidlc-state.md."
+
+**Context**: Construction, Unit 2, Functional Design stage, Step 8. Presenting standardized 2-option completion message; awaiting approval before NFR Requirements.
+
+---
+
+## Diagram Readability Fix (Round 3) + Frontend Terminology Fix
+
+**Timestamp**: 2026-08-02T12:45:00Z
+
+**User Input**: "De mermaid-diagrammen waren altijd zo goed. Nu maak je weer diagrammen die slecht leesbaar zijn... Zorg dat die bij lichte kleuren donkere teksten hebben en bij donkere achtergronden lichte teksten hebben" + (mid-turn) "in `frontend-components.md` staan Services, maar zijn dat geen hooks die ik daar zie staan zoals useOfferings()?"
+
+**AI Response**: "New hypothesis, more surgical than the previous attempt: the earlier deployment-architecture.md fix round had reverted a `themeVariables` init directive entirely because it broke arrow visibility, but that break most likely came specifically from the `lineColor` override, not the text-color variables. Re-added a `%%{init: {'themeVariables': {...}}}%%` directive to every `graph TD`/`graph LR` diagram in this feature's docs, this time setting ONLY `primaryTextColor`/`textColor`/`tertiaryTextColor` to black and deliberately NOT touching `lineColor` — applied to `business-rules.md` (4 diagrams), `domain-entities.md`, `frontend-components.md`, `unit-of-work-dependency.md`, and `deployment-architecture.md` (2 diagrams, which already had `linkStyle` for arrows from the earlier round — left untouched). Also bumped every classDef to `stroke-width:2px` + `font-weight:bold` for extra contrast. Separately, fixed the 'Services' section heading in `frontend-components.md` — the user correctly noted the listed items are React Query hooks (`useOfferings()` etc.), not services; clarified the heading references the existing codebase's folder-naming convention (`features/cms/services/` already holds hooks, e.g. `useCmsInstances.ts`) while being explicit that the contents are hooks."
+
+**Context**: Diagram-rendering fix (experimental, not independently visually verified) applied consistently across all graph-type diagrams in this feature to date, plus a documentation terminology correction. Returning to the Unit 2 Functional Design completion gate.
+
+---
+
+## Diagram Readability Fix (Round 4) + Frontend Folder Convention Clarified
+
+**Timestamp**: 2026-08-02T12:55:00Z
+
+**User Input**: Shared a screenshot of the rendered `domain-entities.md` Entity Relationships diagram — node fills (light blue/orange) rendered correctly, but node label text rendered in a washed-out, low-contrast pale color despite `color:#000000` in classDef and the round-3 theme-init fix; edge labels (dark boxes with white text) rendered fine. Also, mid-turn: "Verder dacht ik dat we voor de front-end hadden gezegd dat hooks ook gewoon in de hooks map moest komen. Services zijn anders."
+
+**AI Response**: "The screenshot proves `fill`/`stroke` from classDef ARE respected by this renderer, but `color` is not — for either mechanism tried so far (classDef color property, themeVariables init). Rather than tweak the same losing mechanism a third time, switched to a fundamentally different, lower-risk approach: white (`#ffffff`) node fill with a thick (3px) colored border for category differentiation instead of colored fill — black bold text on pure white background is far less likely to be overridden into unreadable territory than black text on a pastel background, regardless of whatever theme mechanism is suppressing classDef's `color`. Applied consistently via `sed` across every classDef in `business-rules.md` (4 diagrams), `domain-entities.md`, `frontend-components.md`, `unit-of-work-dependency.md`, and `deployment-architecture.md` (2 diagrams) — verified via grep that no `fill:#ffffff` mismatches remain. Separately, investigated the frontend hooks/services question directly: listed every existing `features/*` folder — all 8 (auth, availability, cms, invitation, profile, setup, system, users) use `services/` for their feature-specific React Query hooks, none has a `hooks/` subfolder; a single top-level `frontend/src/hooks/` exists for generic, cross-feature hooks (currently just `useTheme.ts`). Concluded `frontend-components.md`'s use of `services/` for the Offerings feature's data-fetching hooks is consistent with the actual, current, universal convention — explained this distinction to the user rather than changing anything, since changing it would break from the established pattern."
+
+**Context**: Fourth diagram-rendering fix attempt (different strategy: white fill + border-only color-coding), plus a frontend-folder-convention clarification backed by directly inspecting every existing feature folder. Awaiting user confirmation on diagram readability.
+
+---
+
+## Diagrams Reverted; Hooks/Services Distinction Refined
+
+**Timestamp**: 2026-08-02T13:05:00Z
+
+**User Input**: "nee het is nu afgrijselijk! Laat de kleur van de blokken met rust... hoe het was was het beter, maar de tekst is gewoon te licht en altijd grijs" — then, separately: "over de hooks en services. features kunnen ook eigen hooks hebben. de algemene hooks folder is niet de enige mogelijkheid. in theorie zou alles wat in een feature zit ook als gedeelde/common object kunnen worden gebruikt"
+
+**AI Response**: "Reverted every classDef in business-rules.md, domain-entities.md, frontend-components.md, unit-of-work-dependency.md, and deployment-architecture.md from the white-fill experiment back to the exact prior pastel fill/stroke/width values via targeted sed per stroke-color mapping, verified via grep that no `fill:#ffffff` remained. Acknowledged plainly that none of the three attempted fixes (classDef color, theme-init, white fill) demonstrably fixed the actual gray-text problem, and asked which rendering tool the user uses rather than guessing a fourth cosmetic variant blindly. Separately, refined `frontend-components.md` per the user's correction: split the 'Hooks' section into `services/` (API-calling hooks, existing convention) and a new `hooks/` folder for feature-local non-API hooks — extracted the previously-inline dnd-kit drag-and-drop orchestration out of `OfferingsList` into a new `useOfferingsDnd` hook (`hooks/useOfferingsDnd.ts`), added it to the component hierarchy diagram, and rewrote the explanatory note to state that a feature's own `hooks/` folder is a legitimate option independent of both `services/` and the top-level `frontend/src/hooks/` — not a two-way 'shared vs. feature-specific' split."
+
+**Context**: Diagrams reverted to the pre-white-fill state pending the user's answer on their rendering tool. Frontend hook-location design refined per user feedback. Returning to the Unit 2 Functional Design completion gate once the user confirms.
+
+---
+
+## Mermaid Rendering Root Cause Confirmed (External Tool Bug) + Services/Hooks Naming Deferred
+
+**Timestamp**: 2026-08-02T13:15:00Z
+
+**User Input**: "Ik gebruik Rider met de mermaid extensie" — plus, separately, chose "Hernoem overal naar hooks (apart traject)" in response to an AskUserQuestion about the services/hooks folder-naming scope.
+
+**AI Response**: "Searched the web for known Rider/JetBrains Mermaid dark-theme text-color issues rather than guessing a fifth fix. Found confirmed, documented JetBrains YouTrack bugs (IJPL-97749, MERMAID-154, MERMAID-158): JetBrains' bundled Mermaid preview auto-brightens node text specifically in dark theme, overriding classDef color regardless of what the diagram source specifies — exactly matching the symptom (fill correct, text washed out). This is an external rendering bug, not fixable from the Mermaid source; stopped attempting further diagram-source color tweaks and suggested practical workarounds instead (light theme for the preview pane, or an external renderer like mermaid.live/Gitea's web preview). Also recorded the user's decision on the services/hooks folder naming: renaming `services/` to `hooks/` project-wide (all 8 existing feature folders) is explicitly deferred to a separate, later refactor track, not bundled into this feature — Offerings keeps using `services/` for its API-calling hooks for consistency with the current convention in the meantime. Saved both as project memories (`project_frontend_services_hooks_rename.md` already covers the deferred rename; the Rider bug finding is now on record here rather than as a separate memory, since it's a one-time diagnostic fact rather than an ongoing project fact)."
+
+**Context**: Diagram-source styling accepted as correct; the remaining readability gap is an external JetBrains bug, out of this session's control. Returning to the Unit 2 Functional Design completion gate.
+
+---
+
+## Construction — Unit 2 Functional Design Approved
+
+**Timestamp**: 2026-08-02T13:20:00Z
+
+**User Input**: "Continue to Next Stage"
+
+**AI Response**: "Functional Design approved for Unit 2. Proceeding to NFR Requirements."
+
+**Context**: Construction, Unit 2, Functional Design stage complete. Proceeding to NFR Requirements stage.
+
+---
+
+## Construction — Unit 2 NFR Requirements: Plan Created
+
+**Timestamp**: 2026-08-02T13:25:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Investigated before drafting: read `SecurityEvents.cs` and confirmed it's purpose-built for alertable anomalies (Warning-level, feeds Sentry alert rules per SECURITY-14) — decided a routine content-mutation event does not belong there (would pollute the alerting mechanism), so SECURITY-13's audit trail is better served by plain Information-level structured logging, not by extending that class. Also confirmed `AddCmsRateLimiting` already has an established per-endpoint named-policy pattern (`login`, `refresh`, `sentry-tunnel`) that a new `offerings` policy would follow identically. Created `construction/plans/offerings-nfr-requirements-plan.md` with 4 questions: which endpoints need rate limiting, whether to add HTTP caching headers to the public endpoint (explicitly invited by the hand-off doc), whether to close the remaining 'who' half of the SECURITY-13 open item with a `LastModifiedByUserId` field, and whether the existing ≥80% test coverage standard (from `master-cms-module`'s NFR-MASTER-05) applies here too."
+
+**Context**: Construction, Unit 2, NFR Requirements stage, Steps 1-5. Awaiting user answers.
+
+---
+
+## Construction — Unit 2 NFR Requirements: Answers Received
+
+**Timestamp**: 2026-08-02T13:30:00Z
+
+**User Input**: "ik heb de vragen beantwoord" (offerings-nfr-requirements-plan.md: Q1=A rate limit public GET only; Q2=B no HTTP caching; Q3=A add LastModifiedByUserId; Q4=A same ≥80% coverage standard)
+
+**AI Response**: "All 4 answers unambiguous. Proceeding to generate nfr-requirements.md and tech-stack-decisions.md."
+
+**Context**: Construction, Unit 2, NFR Requirements stage, Step 6-7. Proceeding to artifact generation.
+
+---
+
+## Construction — Unit 2 NFR Requirements: Artifacts Generated
+
+**Timestamp**: 2026-08-02T13:35:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Created `nfr-requirements.md` (NFR-OFF-01 rate limiting via new `offerings-public` policy on the public GET endpoint only; NFR-OFF-02 no HTTP caching, deliberate; NFR-OFF-03 `LastModifiedByUserId` closes SECURITY-13's 'who', with the `SecurityEvents` extension explicitly rejected and the reasoning documented; NFR-OFF-04 ≥80% coverage standard) and `tech-stack-decisions.md` (no new backend technology; `offerings-public` policy added to `AddCmsRateLimiting` via a new `RateLimiting:OfferingsPublic` config section, following the `Login`/`Refresh`/`SentryTunnel` naming convention). Also updated `domain-entities.md` earlier in this stage to add `LastModifiedByUserId` per Q3=A. Marked both checklist steps complete in `offerings-nfr-requirements-plan.md`, updated `aidlc-state.md` (Unit 2 NFR Requirements → Complete, Current Status → NFR Design next)."
+
+**Context**: Construction, Unit 2, NFR Requirements stage, Step 8. Presenting completion gate; awaiting user approval to proceed to NFR Design.
+
+---
+
+## Construction — Unit 2 NFR Design: Plan Created
+
+**Timestamp**: 2026-08-02T13:40:00Z
+
+**User Input**: "Continue to Next Stage"
+
+**AI Response**: "NFR Requirements approved. Investigated before drafting: confirmed rate-limiting attribute placement has a direct precedent (`[EnableRateLimiting(\"login\")]`/`[EnableRateLimiting(\"refresh\")]` on individual action methods in `AuthController`), so `[EnableRateLimiting(\"offerings-public\")]` on just the public GET action is decided directly, no question needed. Scalability/Performance categories marked N/A with rationale (small dataset, no caching, simple indexed queries). Found one genuine open item: `services.md` explicitly deferred the transactional-boundary decision for multi-row operations (featured-exclusivity swap, full reorder, adjacent swap) to Functional Design, but neither `business-logic-model.md` nor `business-rules.md` actually decided it — raised as Question 1 in `offerings-nfr-design-plan.md` rather than deciding silently, since it's a real data-integrity trade-off (single DB transaction vs. sequential saves)."
+
+**Context**: Construction, Unit 2, NFR Design stage, Steps 1-5. Awaiting user answer.
+
+---
+
+## Construction — Unit 2 NFR Design: Artifacts Generated
+
+**Timestamp**: 2026-08-02T13:45:00Z
+
+**User Input**: "ik heb de vraag beantwoord" (offerings-nfr-design-plan.md: Q1=A single DB transaction per multi-row operation)
+
+**AI Response**: "Created `nfr-design-patterns.md` (Pattern 1: explicit EF Core transaction wrapping `CreateAsync`/`UpdateAsync` featured-transitions, `ReorderAsync`, `MoveUpAsync`/`MoveDownAsync`; Pattern 2: `[EnableRateLimiting(\"offerings-public\")]` on the public GET action only; Pattern 3: structured `LogInformation` fields — `OfferingId`/`Action`/`LastModifiedByUserId`) and `logical-components.md` (transactional service methods, rate-limiting policy attachment, audit logging — all extensions of existing components, no new classes). Marked both checklist steps complete in `offerings-nfr-design-plan.md`, updated `aidlc-state.md` (Unit 2 NFR Design → Complete, Current Status → Infrastructure Design next)."
+
+**Context**: Construction, Unit 2, NFR Design stage, Step 6. Presenting completion gate; awaiting user approval to proceed to Infrastructure Design.
+
+---
+
+## Construction — Unit 2 Infrastructure Design: Skipped
+
+**Timestamp**: 2026-08-02T13:50:00Z
+
+**User Input**: "Continue to Next Stage"
+
+**AI Response**: "NFR Design approved. Assessed Infrastructure Design for Unit 2 against the preliminary assessment in `unit-of-work.md` ('likely SKIP — reuses the existing MariaDB / per-module-migration infrastructure with nothing new to map'): confirmed at this stage rather than blindly trusting the earlier prediction — `OfferingsDbContext` uses the same MariaDB instance/connection string as every other module (no new server, port, or deployment target), and its migrations follow the exact per-module pattern already established by `MasterDbContext`/`AvailabilityDbContext`. Skipped, logged rationale, proceeded directly to Code Generation planning."
+
+**Context**: Construction, Unit 2, Infrastructure Design stage. Skipped with rationale logged (matches the precedent set for Unit 1's Functional Design skip — no full completion message for a stage that didn't run). Proceeding to Code Generation.
+
+---
+
+## Construction — Unit 2 Code Generation: Plan Created (Planning)
+
+**Timestamp**: 2026-08-02T13:55:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Investigated the actual codebase before drafting the plan rather than assuming: read `MasterModule.cs`/`CmsInstanceRepository.cs`/`CmsInstanceService.cs`/`CmsInstanceController.cs`/`UsersController.cs`/`MasterDbContext.cs`/`AvailabilityDbContext.cs` for backend conventions (table-name prefixing per module, repository/service/controller shapes, how caller identity is resolved via claims), and `router.tsx`/`Sidebar.tsx`/`ModuleGuard.tsx`/`useCmsInstances.ts`/`useAddCmsInstance.ts`/`cms.ts` (schemas)/`api-client.ts` for frontend conventions (TanStack Router route objects with RoleGuard/ModuleGuard, the services/ hook shape, zod schema shape). Confirmed no existing DataAnnotations/FluentValidation precedent, no existing transaction-wrapping precedent (this unit introduces both, per NFR Design), and no dnd-kit dependency yet (per Functional Design Q1=A, to be added). Created `construction/plans/offerings-code-generation-plan.md` with an 18-step checklist covering: domain layer + DbContext (table `OfferingsOfferings`, JSON-mapped `Features`, soft-delete query filter), repository, transactional service, DataAnnotations-validated models + a custom features-length validator, controller (route/auth table per `component-methods.md`), module registration, the new `offerings-public` rate-limiting policy in Core's `AddCmsRateLimiting`, project/solution wiring, backend tests, and the full frontend feature (dnd-kit dependency, schema, services/ hooks, feature-local hooks/, components, pages, routing/nav/i18n, frontend tests), plus documentation and the always-execute Build and Test verification step."
+
+**Context**: Construction, Unit 2, Code Generation stage, Planning phase. Presenting plan for approval before Generation begins.
+
+---
+
+## Construction — Unit 2 Code Generation Plan Approved
+
+**Timestamp**: 2026-08-02T14:00:00Z
+
+**User Input**: "Approve Plan"
+
+**AI Response**: "Proceeding to Generation: `offerings-code-generation-plan.md` Steps 1-18, in order (backend first, then frontend, then build/test verification)."
+
+**Context**: Construction, Unit 2, Code Generation stage, Part 1 complete. Proceeding to Part 2 Generation.
+
+---
+
+## Construction — Unit 2 Code Generation: Backend Complete (Steps 1-9)
+
+**Timestamp**: 2026-08-02T15:30:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Generated the full `SlpModularCms.Modules.Offerings` backend: `Offering` entity + `OfferingsDbContext` (table `OfferingsOfferings`, JSON-converted `Features` with a `ValueComparer`, `HasQueryFilter` for soft delete), `IOfferingRepository`/`OfferingRepository` (incl. `GetPreviousAsync`/`GetNextAsync` neighbor lookups and a `BeginTransactionAsync` wrapper), `IOfferingsService`/`OfferingsService` (BR-OFF-01..04, explicit transactions per NFR Design Pattern 1, `LastModifiedByUserId`/audit logging per NFR-OFF-03), DTOs/requests with DataAnnotations + a custom `FeaturesValidationAttribute`, `OfferingsController` (route/auth table exactly per `component-methods.md`), `OfferingsModule`, the `offerings-public` rate-limiting policy in Core's `AddCmsRateLimiting` plus its `appsettings.json` section, project/solution wiring, and the EF Core `InitialCreate` migration (generated via `dotnet ef migrations add --project Modules.Offerings --startup-project Api.SlpSoftware`). Wrote 38 new tests (repository via EF Core InMemory, service via NSubstitute, controller) covering all four business rules plus the soft-delete query filter. One bug caught and fixed during test-writing: controller tests failed with `ArgumentNullException` on `User.FindFirstValue` because a bare `new OfferingsController(service)` has no `ControllerContext`/`HttpContext.User` — fixed by giving the test's `CreateSut()` a `ClaimsPrincipal` with a `NameIdentifier` claim, mirroring `UsersControllerTests`' existing pattern. Full solution build succeeded; full backend test suite green (414/414 across all test projects, no regressions)."
+
+**Context**: Construction, Unit 2, Code Generation stage, Steps 1-9 of `offerings-code-generation-plan.md` complete and verified (build + test green). Proceeding to the frontend (Steps 10-15).
+
+---
+
+## Construction — Unit 2 Code Generation: Complete (Steps 10-18)
+
+**Timestamp**: 2026-08-02T16:15:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Generated the full `frontend/src/features/offerings/` feature: added `@dnd-kit/core`/`@dnd-kit/sortable`/`@dnd-kit/utilities` (pnpm version mismatch between the global `pnpm` binary (10.33.2) and the store the repo's `node_modules` was linked with (v11) required running the install via `npx pnpm@11.18.0` instead — a local environment quirk, not a project change); `schemas/offering.ts` (zod, mirrors BR-OFF-04); all 7 `services/` API hooks plus `types.ts`; the feature-local `hooks/useOfferingsDnd.ts`; `OfferingsList`/`OfferingRow`/`DeleteOfferingDialog`/`OfferingForm` components and `OfferingsListPage`/`OfferingFormPage`; three routes in `router.tsx` (list/new/edit) behind `RoleGuard`+`ModuleGuard(\"Offerings\")`; a `Sidebar.tsx` nav entry; full `nav.offerings`/`offerings.*` i18n key sets in both `en`/`nl`; `features/offerings/mocks/handlers.ts` plus registration in `mocks/index.ts`, and added `'Offerings'` to the shared `system/mocks/handlers.ts` capabilities fixture so `ModuleGuard`-gated content renders in tests by default. Wrote 43 new frontend tests (schema, an `OfferingsListPage` integration suite, an `OfferingFormPage` suite) following the `features/cms` test-style precedent. Two issues caught and fixed during this stage: (1) `useFieldArray` doesn't type-check against a plain `string[]` field for the dynamic features list — switched to `useWatch`+`setValue`, verified by a clean `tsc -b` build; (2) `pnpm lint` flagged `react-hooks/set-state-in-effect` in `useOfferingsDnd`'s prop-sync logic — fixed by adjusting state during render (comparing against a stored previous-props reference) instead of inside a `useEffect`, per the React docs' recommended pattern. `pnpm build` succeeded, `pnpm lint` clean, `pnpm test` green (254/254 across 41 files, 43 new, no regressions). Created `construction/offerings/code/summary.md`. Backend was already verified green in the prior step (414/414). Marked `offerings-code-generation-plan.md`'s all 18 steps complete, updated `aidlc-state.md` (Unit 2 Code Generation → Complete, Current Status → feature-wide Build and Test next)."
+
+**Context**: Construction, Unit 2, Code Generation stage, Steps 10-18 of `offerings-code-generation-plan.md` complete and verified (build + lint + test green, both backend and frontend). Unit 2 "Offerings" Code Generation is now fully complete. Presenting completion gate; awaiting user approval to proceed to feature-wide Build and Test.
+
+---
+
+## Bug Fix — Record DataAnnotations Targeting Property Instead of Constructor Parameter
+
+**Timestamp**: 2026-08-02T16:30:00Z
+
+**User Input**: Pasted a live `POST /api/v1/offerings/admin` failure — `GlobalExceptionHandler` logged an unhandled `System.InvalidOperationException`: "Record type 'CreateOfferingRequest' has validation metadata defined on property 'CtaLabel' that will be ignored. 'CtaLabel' is a parameter in the record primary constructor and validation metadata must be associated with the constructor parameter," thrown from `ModelMetadata.ThrowIfRecordTypeHasValidationOnProperties()` during model validation.
+
+**AI Response**: "Root cause: `CreateOfferingRequest`/`UpdateOfferingRequest`/`ReorderOfferingsRequest` used `[property: Required, MaxLength(...)]`-style attributes on record primary-constructor parameters. ASP.NET Core's model-binding/validation metadata system (a runtime check added for record types) requires validation attributes to target the constructor parameter itself, not the compiler-generated property — `[property: ...]` explicitly routes them to the property, which the validator then flags and throws on rather than silently ignoring. Fixed by removing the `property:` target from every attribute in all three request records, so they land on the parameters as ASP.NET Core expects. Verified: `Modules.Offerings` project builds clean standalone, and the 38 `Modules.Offerings.Tests` still pass unchanged. Could not run a full solution build to verify `Api.SlpSoftware` picks up the fix, because the user's locally-running `Api.SlpSoftware.exe` process holds a lock on its own `Modules.Offerings.dll` output — user needs to stop and restart that process to load the fix."
+
+**Context**: Real bug in Unit 2's generated code, caught via live testing rather than assumption. Fixed directly per the project's fix-small-things-now convention; not filed as tech debt. Unit 2 Code Generation completion gate still stands once the user confirms the fix works after restarting the app.
+
+---
+
+## Bug Fix — CORS: Public SlpSoftware Website Origin Not Allowed
+
+**Timestamp**: 2026-08-02T16:40:00Z
+
+**User Input**: "Ik krijg een cors error als ik de data op probeer te halen met de website die draait op http://localhost:5173/"
+
+**AI Response**: "Checked `Api.SlpSoftware/appsettings.Development.json`'s `Cors:AllowedOrigins` — it only listed `localhost:5175` (this repo's admin frontend, per `pnpm dev:slpsoftware`), deliberately excluding 5173 per its own comment ('that's Api's own frontend dev port'). That comment was correct about *this* repo's Api project, but didn't account for the actual external SlpSoftware website (a separate workspace, `K:\Development\SlpSoftware\Projects\SlpSoftware`) coincidentally also running on Vite's default port 5173 when calling the anonymous `GET /api/v1/offerings` endpoint. Added `http://localhost:5173`/`https://localhost:5173` to the allowed origins, with a comment distinguishing the two same-numbered-but-different-origin dev servers so this isn't miscategorized as a duplicate/mistake again later. No code in the external website workspace was touched, per that workspace's read-only-for-this-feature constraint — only this repo's CORS config changed."
+
+**Context**: Real bug found via live testing — the public website is the actual consumer FR-6 was built for, so this is a legitimate integration gap, not a code-generation defect. Fixed directly. Returning to the Unit 2 Code Generation completion gate.
+
+---
+
+## UX Fix — Drag-and-Drop Reorder Caused Page Scrollbars to Appear
+
+**Timestamp**: 2026-08-02T16:50:00Z
+
+**User Input**: "ik zie scrollbalken tevoorschijn komen al sik ga slepen voor de volgorde. Kan je zorgen dat ik die scrollbalken niet te zien krijg?"
+
+**AI Response**: "Root cause: `OfferingRow` applied dnd-kit's `transform` directly to the actual `<tr>` being dragged (`CSS.Transform.toString(transform)` on the row's own `style`). Per the CSS Transforms spec, a transformed element's post-transform geometry contributes to its nearest scrolling ancestor's scrollable overflow — so dragging a row far enough temporarily grows the page's scrollable area, which is exactly the scrollbar flicker reported. This is standard, well-documented dnd-kit behavior when you skip `DragOverlay` and transform the sortable item in place. Fixed by introducing a `DragOverlay`: `useOfferingsDnd` now tracks `activeId`/`activeItem` and exposes a `handleDragStart`; `OfferingsList` renders a `<DragOverlay>` (a React portal, `position: fixed`, entirely outside document flow) showing a lightweight floating card (grip icon, title, price) for the item being dragged; `OfferingRow` now sets `opacity: 0` on itself via `isDragging` (from `useSortable`) instead of visually moving, since the overlay is what the user now sees following the cursor. Verified: `pnpm build`/`pnpm lint` clean, full test suite still green (254/254, no regressions)."
+
+**Context**: Real UX bug found via live testing/dragging, not a functional/business-rule defect (US-08's drag-and-drop behavior itself was already correct). Fixed directly per the project's fix-small-things-now convention. Returning to the Unit 2 Code Generation completion gate.
+
+---
+
+## Construction — Unit 2 "Offerings" Code Generation Approved
+
+**Timestamp**: 2026-08-02T16:55:00Z
+
+**User Input**: "OKee, ziet er goed uit, ga verder"
+
+**AI Response**: "Unit 2 'Offerings' Code Generation approved, including the three post-completion live-testing fixes (record DataAnnotations targeting, CORS for the public website origin, drag-and-drop scrollbar UX). Both units are now code-complete and individually verified green. Proceeding to feature-wide Build and Test — the always-execute stage that does one final combined pass across the whole feature before Operations."
+
+**Context**: Construction, Unit 2 Code Generation stage complete and approved. Proceeding to the feature-wide Build and Test stage.
+
+---
+
+## Feature-wide Build and Test — Complete
+
+**Timestamp**: 2026-08-02T17:05:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Ran one final combined verification pass across the whole feature (confirmed the user's locally-running `Api.SlpSoftware.exe` had been stopped, so the build could overwrite its output): `dotnet build SlpModularCms.sln` succeeded; `dotnet test SlpModularCms.sln` — 414/414 passing across all six test projects (`Core.Tests` 196, `Modules.Identity.Tests` 37, `Modules.Availability.Tests` 82, `Modules.Master.Tests` 57, `Modules.Offerings.Tests` 38, `Api.Tests` 4), no regressions. Frontend: `pnpm build` succeeded, `pnpm lint` clean, `pnpm test` — 254/254 passing across 41 files, no regressions. Both units (`SlpSoftware Client Setup`, `Offerings`) are now fully complete and verified together. Updated `aidlc-state.md`: Construction phase marked complete, Current Status → Operations phase next (Deployment Setup: retargeting `gitea-deployment-workflow`'s pipeline to `Api.SlpSoftware` per D-15's cutover decision)."
+
+**Context**: CONSTRUCTION phase complete for the `slpsoftware-api` feature. Presenting completion gate; awaiting user approval to proceed to the OPERATIONS phase, starting with Deployment Setup.
+
+---
+
+## Operations — Deployment Setup: Plan Created (No Questions)
+
+**Timestamp**: 2026-08-02T17:10:00Z
+
+**User Input**: "Continue to Next Stage"
+
+**AI Response**: "Read `continuous_integration.yaml`, `deploy-scp.yaml`, and `gitea-deployment-workflow`'s `deployment-instructions.md`/`rollback-plan.md` in full before drafting anything (D-7's 'extend, don't duplicate'). Found: `deploy-scp.yaml` and `rollback-plan.md` need zero changes (neither ever hardcodes an entry-point `.dll` name — both operate on the release-directory/symlink level or a `service_name` input string); `continuous_integration.yaml` hardcodes `SlpModularCms.Api` in exactly 6 lines, all inside `publish-test`/`publish-production`'s 'Build admin frontend' and 'Publish' steps (every other `Api` reference in that file is `Api.Tests`, correctly untouched — Unit 1's own regression suite, scoped to `Api` per NFR-CS-01, and `Api` itself stays as local dev host per D-8); `deployment-instructions.md` § 1.6's systemd `ExecStart` lines are host configuration that only this feature's documentation can update — actually applying the change to the Pi's already-running units is the user's own manual step. No nginx, database, or Gitea-variable changes needed (D-6, same customer/domain/service-names). Created `operations/plans/deployment-setup-plan.md` with this investigation and an explicit 'no questions this time' rationale — every decision this stage would normally ask about was already made in Requirements Analysis (D-6/D-7/D-8/D-15); this stage is mechanical execution of already-approved decisions, not new design."
+
+**Context**: Operations, Deployment Setup stage. No user answers needed — proceeding directly to execution per the plan's checklist.
+
+---
+
+## Operations — Deployment Setup: Complete
+
+**Timestamp**: 2026-08-02T17:20:00Z
+
+**User Input**: N/A (no new user input this step; proceeding per approved workflow)
+
+**AI Response**: "Executed all 4 checklist items: retargeted `continuous_integration.yaml`'s `publish-test`/`publish-production` jobs from `src/SlpModularCms.Api` to `src/SlpModularCms.Api.SlpSoftware` (6 lines, verified via `git diff` — a clean, minimal change touching only the two 'Build admin frontend'/'Publish' step pairs, `SlpModularCms.Api.Tests` references correctly left alone); updated `gitea-deployment-workflow`'s `deployment-instructions.md` § 1.6 systemd `ExecStart` documentation to `SlpModularCms.Api.SlpSoftware.dll`, with an explicit callout that this requires a manual edit on the Pi's already-existing units (directly answering the user's earlier open question about whether `slpsoftware-test.service`/`slpsoftware-production.service` need changes — yes); created `operations/deployment/deployment-instructions.md` as this feature's pointer/summary document per the 'extend, don't duplicate' relationship with `gitea-deployment-workflow`; verified via `grep` that no other file hardcodes `SlpModularCms.Api` as a deploy target (only `Api.Tests` and doc cross-references to `Api.csproj`'s own comment remain, both correctly unaffected). Drive-by fix: README.md's Projectstructuur section still said 'plus (later) de Offerings-module' — updated now that Offerings is actually done, and reworded the sentence to state the cutover as fact rather than a future plan."
+
+**Context**: Operations, Deployment Setup stage complete — all repo-side changes done and verified via diff/grep. The one remaining action (editing the Pi's two systemd unit files) is inherently the user's own manual step, documented clearly in both `deployment-instructions.md` locations. Presenting completion gate; awaiting user approval to proceed to Monitoring Setup.
+
+---