Lexi AI — settings & feedback (Phase 14, UN-115)

What it is

Per-user control over the Lexi suite (src/lexi-ai/settings/): six feature flags + notification preferences, plus a suggestion-feedback intake. Applicant-only, per-user /api/v1/*.

Endpoints

• GET /api/v1/users/{userId}/lexi-settings — 30/min. Returns {userId, featureFlags{resumeTailoring, atsScan, coverLetterGeneration, interviewCoaching, jobRecommendations, chat}, notificationPrefs{newMatchAlerts, weeklyDigest}}, merged over the defaults (all flags on; newMatchAlerts on, weeklyDigest off).
• PUT /api/v1/users/{userId}/lexi-settings — 60/min. Partial body {featureFlags?, notificationPrefs?}; merges the submitted keys over the resolved current and upserts the full maps (a partial PUT only changes what's sent). Non-boolean values → 422.
• POST /api/v1/lexi/feedback — 60/min. {suggestionType, suggestionRefId, suggestionRefType, rating('helpful'|'unhelpful'), comment?} → 201 {id, status:'recorded'} (a LexiSuggestionFeedback row linked to the suggestion for downstream tuning).

Why it's the control plane

The flags stored here are exactly what the shared LexiFeatureGuard (in src/lexi-ai/common/) reads: disabling, say, jobRecommendations immediately makes the job-discovery endpoints answer 403 feature disabled and removes the matching chat actions — one switch, enforced everywhere, because every other slice carries @RequireLexiFeature(flag). This settings slice itself carries no feature gate (it manages the flags — gating it would be circular).

Note: the downstream consumers of the flags/prefs — pausing the nightly score recompute for users who turned off recommendations, and the new-match-alert / weekly-digest notification jobs — are owned by the notification/scoring pipelines, not this slice.