Completes master-cms-module: Build & Test, docs, and appsettings
Finishes the master-cms-module feature (Units 1-4): runs Build and Test across master-backend, slave-availability-extension and frontend-cms-page, fixes a missing Availability EF migration for MasterRegistration and a TanStack Query v5 mutation-callback type break, adds the missing MasterModule appsettings section, and documents the module in README.md. Also seeds a tech-debt-backlog feature to track dead config and pre-existing/introduced frontend lint findings for later cleanup.
This commit is contained in:
@@ -0,0 +1,49 @@
|
||||
# Tech Debt Backlog
|
||||
|
||||
Items discovered incidentally while working on other features. Not yet prioritized. Each item lists where it was found and what "done" looks like.
|
||||
|
||||
---
|
||||
|
||||
## TD-001: Dead config properties on `MasterModuleOptions`
|
||||
|
||||
**Found during**: `master-cms-module` — Build & Test / appsettings mapping (2026-07-01)
|
||||
|
||||
**Location**: `src/SlpModularCms.Modules.Master/Options/MasterModuleOptions.cs`
|
||||
|
||||
**Issue**: `CacheMinutes` and `ApiKey` are declared on the options POCO and were originally designed (per `aidlc-docs/features/master-cms-module/construction/master-backend/functional-design/domain-entities.md`) as slave-side settings for Unit 2 (slave-availability-extension) to consume. When Unit 2 was actually implemented, it used a different pattern instead — per-instance Data-Protection-encrypted API keys pushed from the Master, and a no-TTL in-memory cache (`REL-02` in the Availability NFR requirements) rather than a configurable `CacheMinutes`. As a result, neither property is read anywhere in the codebase.
|
||||
|
||||
**Done looks like**: Either remove both properties from `MasterModuleOptions` (and any corresponding appsettings documentation), or — if a future feature revives the pull/TTL model — wire them up for real. Confirm via `grep -rn "CacheMinutes\|Options.Value.ApiKey" src/` that nothing reads them before removing.
|
||||
|
||||
---
|
||||
|
||||
## TD-002: Pre-existing frontend lint errors (react-hooks plugin)
|
||||
|
||||
**Found during**: `master-cms-module` — Build & Test (2026-07-01), confirmed pre-existing via `git worktree` checkout of commit `c156107` (the commit immediately before this feature's frontend work) with a clean `npm install`
|
||||
|
||||
**Issues** (4 total — 4 errors, 0 warnings at that baseline):
|
||||
1. `frontend/src/components/ui/badge.tsx:32` — `react-refresh/only-export-components`: the file exports both a component and a non-component value (likely `badgeVariants`), breaking Fast Refresh. Fix: move the shared constant/function to a separate file.
|
||||
2. `frontend/src/components/users/InviteUserDialog.tsx` — two related findings in the same `useEffect`:
|
||||
- `react-hooks/set-state-in-effect`: `setStep(1)` (and sibling `setState` calls) run synchronously inside a `useEffect` that resets dialog state on close.
|
||||
- `react-hooks/immutability`: `reset()` (from `useForm`) is referenced in the effect body before its `const { reset } = useForm(...)` declaration further down the component — works today due to hoisting/closure timing but is flagged as fragile.
|
||||
3. `frontend/src/pages/SettingsPage.tsx:39` — `react-hooks/set-state-in-effect`: `setSelectedMode`/`setReason` run synchronously inside a `useEffect` that syncs local form state from a query result (`availability`).
|
||||
|
||||
**Done looks like**: Refactor each flagged effect per the React docs' "you might not need an effect" guidance (react.dev/learn/you-might-not-need-an-effect) — e.g. compute derived state during render, or move the reset logic into the `onOpenChange`/event handler instead of an effect. For `badge.tsx`, split the non-component export into its own module. Re-run `npm run lint` in `frontend/` until clean.
|
||||
|
||||
---
|
||||
|
||||
## TD-003: New lint findings introduced by `master-cms-module` Unit 3 (same pattern as TD-002)
|
||||
|
||||
**Found during**: `master-cms-module` — Build & Test (2026-07-01). These were introduced by this feature's own Unit 3 (frontend-cms-page) code, but deferred here per explicit user decision (2026-07-01: "Laat ze staan... gooi die dan ook in deze feature") rather than fixed in-flight, to avoid blocking Unit 4.
|
||||
|
||||
**Issues** (2 total — 1 error, 1 warning):
|
||||
1. `frontend/src/components/cms/AddCmsInstanceDialog.tsx:55` — `react-hooks/set-state-in-effect`: `setServerError(null)` (and sibling calls) run synchronously inside the dialog's close-reset `useEffect`. Same pattern as TD-002 item 2.
|
||||
2. `frontend/src/components/cms/SetStatusDialog.tsx:72` — `react-hooks/incompatible-library` (warning): `watch()` from `react-hook-form`'s `useForm()` is used directly; React Compiler can't safely memoize it, so compilation is skipped for this component/hook.
|
||||
|
||||
**Done looks like**: Same remediation approach as TD-002 item 2 for the `AddCmsInstanceDialog.tsx` finding. For `SetStatusDialog.tsx`, either accept the compiler skipping memoization for this component (likely fine, low-traffic dialog) or replace `watch('status')` with a subscription-based pattern (`useWatch`) if it becomes a proven perf issue.
|
||||
|
||||
---
|
||||
|
||||
## Notes
|
||||
|
||||
- None of these block functionality — `npm run build` and all test suites pass regardless.
|
||||
- TD-002 and TD-003 share the same underlying pattern (`setState` in a mount/close-reset effect) — worth fixing as one pass across all four files rather than one-by-one, once picked up.
|
||||
Reference in New Issue
Block a user