fix(OPENFRAM-007-3): CU-86akn96pf NotificationDataFetcher re-implements principal-resolution logic that CurrentPrincipalSupport already centralizes

[flamingo]

Closes findings from rule OPENFRAM-007-3 — NotificationDataFetcher re-implements principal-resolution logic that CurrentPrincipalSupport already centralizes.

Draft — this is a starting point, not a finished change. The fix required judgment, so read it before trusting it.

#	Fix confidence	Finding	Location
1	🔴 35 low — review closely	NotificationDataFetcher re-implements principal-resolution logic that CurrentPrincipalSupport already centralizes	openframe-api-service-core/src/main/java/com/openframe/api/datafetcher/NotificationDataFetcher.java:135

What changed — and what was deliberately left — is explained per finding as inline review comments on the lines each finding touched.

---

Run: https://product-hub.flamingo.so/admin/code-review
Run id: 9a25c19f-a499-4571-bb37-da3cba9b8394

Merging this PR is recorded as acceptance of the rule that produced it;
closing it unmerged is recorded as rejection. Both feed rule health, so
closing a wrong suggestion is useful rather than merely tidy.

ClickUp task: CU-86akn96pf OpenFrame lib batch review findings sweep (7 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

1 finding(s) fixed in this draft — 1 explained inline on the diff; 1 low-confidence hunk(s) need close review before merging.

[flamingo]

🦩 🟠 NotificationDataFetcher re-implements principal-resolution logic that CurrentPrincipalSupport already centralizes

In NotificationDataFetcher, removed the private currentPrincipal()/currentRecipient() JWT-extraction methods and replaced principal acquisition with @AuthenticationPrincipal AuthPrincipal parameters on every query/mutation (matching the pattern used by PresenceDataFetcher/NotificationSettingsDataFetcher), and delegated human-user resolution to an injected CurrentPrincipalSupport.requireHumanUserId(principal) call in the new currentRecipient(AuthPrincipal) helper, keeping only the AGENT/machine_id branch local since that path is specific to this fetcher. This is UNVERIFIED against the actual CurrentPrincipalSupport class signature (I could not see its source, so the method name/parameter shape requireHumanUserId(AuthPrincipal) is inferred from the finding text referencing "CurrentPrincipalSupport.requireHumanUserId"); if its actual signature differs (e.g., it takes no argument and resolves from SecurityContextHolder itself, or throws a different exception, or the AGENT branch should also be delegated to it), this will fail to compile and needs adjustment to match the real API. A complete fix requires confirming CurrentPrincipalSupport's exact method signatures from PresenceDataFetcher/NotificationSettingsDataFetcher and aligning this file's calls and constructor injection accordingly.

🤖 Prompt for AI agents

In openframe-api-service-core/src/main/java/com/openframe/api/datafetcher/NotificationDataFetcher.java around line 135, review and complete this code-review fix: NotificationDataFetcher re-implements principal-resolution logic that CurrentPrincipalSupport already centralizes.
What the draft fix changed: In `NotificationDataFetcher`, removed the private `currentPrincipal()`/`currentRecipient()` JWT-extraction methods and replaced principal acquisition with `@AuthenticationPrincipal AuthPrincipal` parameters on every query/mutation (matching the pattern used by `PresenceDataFetcher`/`NotificationSettingsDataFetcher`), and delegated human-user resolution to an injected `CurrentPrincipalSupport.requireHumanUserId(principal)` call in the new `currentRecipient(AuthPrincipal)` helper, keeping only the AGENT/machine_id branch local since that path is specific to this fetcher. This is UNVERIFIED against the actual `CurrentPrincipalSupport` class signature (I could not see its source, so the method name/parameter shape `requireHumanUserId(AuthPrincipal)` is inferred from the finding text referencing "CurrentPrincipalSupport.requireHumanUserId"); if its actual signature differs (e.g., it takes no argument and resolves from `SecurityContextHolder` itself, or throws a different exception, or the AGENT branch should also be delegated to it), this will fail to compile and needs adjustment to match the real API. A complete fix requires confirming `CurrentPrincipalSupport`'s exact method signatures from `PresenceDataFetcher`/`NotificationSettingsDataFetcher` and aligning this file's calls and constructor injection accordingly.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

fix confidence: 🔴 35 low — review closely — react 👍/👎 to teach the reviewer