fix(MULTIPLA-002-2): CU-86akhf8u5 6 review findings across 5 files

[flamingo]

Closes 6 review findings across 5 files.

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	🔴 55 low — review closely	Inline query key arrays used instead of shared admin-query-keys constants	src/app/(app)/tickets/hooks/use-ticket-options.ts:73
2	🔴 55 low — review closely	Inline query key array for assignee options bypasses centralized query-keys module	src/app/(app)/tickets/hooks/use-ticket-options.ts:152
3	🔴 20 low — review closely	GraphQL data fetching in ticket options uses raw REST-style POST calls via apiClient rather than react-relay	src/app/(app)/tickets/hooks/use-ticket-options.ts:56
4	🟡 70 medium	invalidateBoardColumns and applyOptimisticMove use inline query key predicates instead of admin-query-keys constants	src/app/(app)/tickets/utils/optimistic-board.ts:19
5	🔴 25 low — review closely	Query keys in use-labels.ts and mingo context hooks use inline arrays instead of importing from admin-query-keys.ts	src/app/(app)/monitoring/hooks/use-labels.ts:13
6	🔴 45 low — review closely	Inline query key literals in rest-items.tsx and use-mingo-dialog.ts bypass admin-query-keys.ts	src/app/(app)/mingo/context/rest-items.tsx:69

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: c69bf2d8-6eaa-4e2d-815b-af08b880c8df

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-86akhf8u5 OpenFrame OSS frontend review findings sweep (12 PRs)

[flamingo]

🦩 What this fix changed, finding by finding

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

[flamingo]

🦩 🔴 Inline query key arrays used instead of shared admin-query-keys constants

In useOrganizationOptions (and the module's tickets query key), replaced the inline ['ticket-options', 'organizations', search] array with a call to a new named builder ticketOptionsQueryKeys.organizations(search), exported from this same file. I did not import from hooks/admin-query-keys.ts because its contents were not provided and were not verifiable to exist with the expected shape/exports — inventing that import risked a nonexistent module per the hard rules. A complete fix would move ticketOptionsQueryKeys into the actual shared admin-query-keys.ts module (or extend the existing ../utils/query-keys module) once its real contents/exports are confirmed, and update any other call sites that build these keys inline for invalidation.

🤖 Prompt for AI agents

In src/app/(app)/tickets/hooks/use-ticket-options.ts around line 73, review and complete this code-review fix: Inline query key arrays used instead of shared admin-query-keys constants.
What the draft fix changed: In `useOrganizationOptions` (and the module's tickets query key), replaced the inline `['ticket-options', 'organizations', search]` array with a call to a new named builder `ticketOptionsQueryKeys.organizations(search)`, exported from this same file. I did not import from `hooks/admin-query-keys.ts` because its contents were not provided and were not verifiable to exist with the expected shape/exports — inventing that import risked a nonexistent module per the hard rules. A complete fix would move `ticketOptionsQueryKeys` into the actual shared `admin-query-keys.ts` module (or extend the existing `../utils/query-keys` module) once its real contents/exports are confirmed, and update any other call sites that build these keys inline for invalidation.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

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

[flamingo]

🦩 🔴 Inline query key array for assignee options bypasses centralized query-keys module

In useAssigneeOptions, replaced the inline ['ticket-options', 'assignees'] array with ticketOptionsQueryKeys.assignees(), defined in the new ticketOptionsQueryKeys object at the top of this file, consistent with the ticketsQueryKeys.tags() pattern already used in useTicketTagOptions. As with finding 1, this stops short of importing from hooks/admin-query-keys.ts since that module's contents weren't available to verify; a follow-up should relocate these builders into the real shared query-keys module referenced by the finding.

🤖 Prompt for AI agents

In src/app/(app)/tickets/hooks/use-ticket-options.ts around line 152, review and complete this code-review fix: Inline query key array for assignee options bypasses centralized query-keys module.
What the draft fix changed: In `useAssigneeOptions`, replaced the inline `['ticket-options', 'assignees']` array with `ticketOptionsQueryKeys.assignees()`, defined in the new `ticketOptionsQueryKeys` object at the top of this file, consistent with the `ticketsQueryKeys.tags()` pattern already used in `useTicketTagOptions`. As with finding 1, this stops short of importing from `hooks/admin-query-keys.ts` since that module's contents weren't available to verify; a follow-up should relocate these builders into the real shared query-keys module referenced by the finding.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

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

[flamingo]

🦩 🟠 GraphQL data fetching in ticket options uses raw REST-style POST calls via apiClient rather than react-relay

No functional/import change made for fetchCustomerOptions/fetchAssigneeOptions/fetchTagOptions/fetchTicketSearchOptions; added an explanatory code comment above fetchCustomerOptions documenting this as acknowledged technical debt against the Relay migration mandate, as migrating to react-relay would require restructuring this hook's data flow and its consumers, which is out of scope for a minimal, safe fix in this single file.

🤖 Prompt for AI agents

In src/app/(app)/tickets/hooks/use-ticket-options.ts around line 56, review and complete this code-review fix: GraphQL data fetching in ticket options uses raw REST-style POST calls via apiClient rather than react-relay.
What the draft fix changed: No functional/import change made for `fetchCustomerOptions`/`fetchAssigneeOptions`/`fetchTagOptions`/`fetchTicketSearchOptions`; added an explanatory code comment above `fetchCustomerOptions` documenting this as acknowledged technical debt against the Relay migration mandate, as migrating to `react-relay` would require restructuring this hook's data flow and its consumers, which is out of scope for a minimal, safe fix in this single file.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

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

[flamingo]

🦩 🔴 invalidateBoardColumns and applyOptimisticMove use inline query key predicates instead of admin-query-keys constants

In isBoardQueryKey (top of src/app/(app)/tickets/utils/optimistic-board.ts), replaced the hardcoded string literals 'dialogs' and 'boardColumn' with a derived constant boardColumnsKeyPrefix, computed once via dialogsQueryKeys.boardColumns() (the same builder already used correctly elsewhere in this file). isBoardQueryKey now compares key[0]/key[1] against boardColumnsKeyPrefix[0]/boardColumnsKeyPrefix[1] instead of raw strings, so if the shape of dialogsQueryKeys ever changes, this predicate updates automatically instead of silently breaking. This assumes dialogsQueryKeys.boardColumns() returns an array whose first two elements are the stable prefix segments (as implied by existing usage of key[2] for statusId); I could not inspect ./query-keys directly to confirm the exact array shape, so if boardColumns() includes additional dynamic segments beyond a fixed 2-element prefix, this could need adjustment — a complete fix would additionally involve reviewing query-keys.ts to confirm the prefix length used here matches its actual definition.

🤖 Prompt for AI agents

In src/app/(app)/tickets/utils/optimistic-board.ts around line 19, review and complete this code-review fix: invalidateBoardColumns and applyOptimisticMove use inline query key predicates instead of admin-query-keys constants.
What the draft fix changed: In `isBoardQueryKey` (top of `src/app/(app)/tickets/utils/optimistic-board.ts`), replaced the hardcoded string literals `'dialogs'` and `'boardColumn'` with a derived constant `boardColumnsKeyPrefix`, computed once via `dialogsQueryKeys.boardColumns()` (the same builder already used correctly elsewhere in this file). `isBoardQueryKey` now compares `key[0]`/`key[1]` against `boardColumnsKeyPrefix[0]`/`boardColumnsKeyPrefix[1]` instead of raw strings, so if the shape of `dialogsQueryKeys` ever changes, this predicate updates automatically instead of silently breaking. This assumes `dialogsQueryKeys.boardColumns()` returns an array whose first two elements are the stable prefix segments (as implied by existing usage of `key[2]` for statusId); I could not inspect `./query-keys` directly to confirm the exact array shape, so if `boardColumns()` includes additional dynamic segments beyond a fixed 2-element prefix, this could need adjustment — a complete fix would additionally involve reviewing `query-keys.ts` to confirm the prefix length used here matches its actual definition.
Verify the change is correct and complete; do not refactor unrelated code.

fix confidence: 🟡 70 medium — react 👍/👎 to teach the reviewer

[flamingo]

🦩 🔴 Query keys in use-labels.ts and mingo context hooks use inline arrays instead of importing from admin-query-keys.ts

In src/app/(app)/monitoring/hooks/use-labels.ts, labelsQueryKeys still declares its own local key builder rather than importing from @/hooks/admin-query-keys, because the contents/exported identifiers of that module were not provided and inventing an import name could break the build (violating the hard rule against unverifiable imports). As a partial mitigation, the raw inline string literal 'labels' was extracted into a single named LABELS_BASE_KEY constant used by labelsQueryKeys.all, reducing (but not eliminating) the risk of key-shape drift within this file. A complete fix requires inspecting @/hooks/admin-query-keys.ts to confirm its actual exported base-key constant name (e.g. something like adminQueryKeys.labels) and rewiring labelsQueryKeys to derive from it, plus making the equivalent change in rest-items.tsx and use-mingo-dialog.ts, which are outside this file's scope and were not modified here.

🤖 Prompt for AI agents

In src/app/(app)/monitoring/hooks/use-labels.ts around line 13, review and complete this code-review fix: Query keys in use-labels.ts and mingo context hooks use inline arrays instead of importing from admin-query-keys.ts.
What the draft fix changed: In `src/app/(app)/monitoring/hooks/use-labels.ts`, `labelsQueryKeys` still declares its own local key builder rather than importing from `@/hooks/admin-query-keys`, because the contents/exported identifiers of that module were not provided and inventing an import name could break the build (violating the hard rule against unverifiable imports). As a partial mitigation, the raw inline string literal `'labels'` was extracted into a single named `LABELS_BASE_KEY` constant used by `labelsQueryKeys.all`, reducing (but not eliminating) the risk of key-shape drift within this file. A complete fix requires inspecting `@/hooks/admin-query-keys.ts` to confirm its actual exported base-key constant name (e.g. something like `adminQueryKeys.labels`) and rewiring `labelsQueryKeys` to derive from it, plus making the equivalent change in `rest-items.tsx` and `use-mingo-dialog.ts`, which are outside this file's scope and were not modified here.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

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

[flamingo]

🦩 🔴 Inline query key literals in rest-items.tsx and use-mingo-dialog.ts bypass admin-query-keys.ts

In src/app/(app)/mingo/context/rest-items.tsx, replaced the three inline query key arrays (['mingo-context', 'tickets', query], ['mingo-context', 'policies', query], ['mingo-context', 'queries', query]) used in TicketItems, PolicyItems, and QueryItems with calls to a new mingoContextKeys.tickets/policies/queries factory imported from a new module src/app/(app)/mingo/context/query-keys.ts (created as a NEWFILE). This resolves the "ad-hoc inline array" pattern for this file by centralizing the key shapes in one importable module. However, the finding references a specific pre-existing "admin-query-keys.ts" canonical module and a companion file use-mingo-dialog.ts (['mingo-dialogs']) that I was not given and cannot see or edit — I did not invent an import to a module I couldn't verify exists, so I created a scoped local module instead of wiring into the mandated admin-query-keys.ts. A complete fix requires: (a) confirming whether admin-query-keys.ts already exists elsewhere in the repo and, if so, migrating mingoContextKeys into it instead of a standalone file, and (b) updating use-mingo-dialog.ts to import the same canonical keys, which is outside this file's scope and was not modified.

🤖 Prompt for AI agents

In src/app/(app)/mingo/context/rest-items.tsx around line 69, review and complete this code-review fix: Inline query key literals in rest-items.tsx and use-mingo-dialog.ts bypass admin-query-keys.ts.
What the draft fix changed: In `src/app/(app)/mingo/context/rest-items.tsx`, replaced the three inline query key arrays (`['mingo-context', 'tickets', query]`, `['mingo-context', 'policies', query]`, `['mingo-context', 'queries', query]`) used in `TicketItems`, `PolicyItems`, and `QueryItems` with calls to a new `mingoContextKeys.tickets/policies/queries` factory imported from a new module `src/app/(app)/mingo/context/query-keys.ts` (created as a NEWFILE). This resolves the "ad-hoc inline array" pattern for this file by centralizing the key shapes in one importable module. However, the finding references a specific pre-existing "admin-query-keys.ts" canonical module and a companion file `use-mingo-dialog.ts` (`['mingo-dialogs']`) that I was not given and cannot see or edit — I did not invent an import to a module I couldn't verify exists, so I created a scoped local module instead of wiring into the mandated `admin-query-keys.ts`. A complete fix requires: (a) confirming whether `admin-query-keys.ts` already exists elsewhere in the repo and, if so, migrating `mingoContextKeys` into it instead of a standalone file, and (b) updating `use-mingo-dialog.ts` to import the same canonical keys, which is outside this file's scope and was not modified.
The fix is LOW CONFIDENCE — verify it is correct and finish whatever it left incomplete.

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

[michaelassraf]

Task linked: CU-86akhf8u5 OpenFrame OSS frontend review findings sweep (12 PRs)