Description

The new session analysis view assigns Tailwind utility classes such as w-full, p-3,
bg-[--gray-1], and focus:outline-none to the AI decisions accordion and its controls. Rendering
this panel reaches the new decision list, trigger, badges, links, and focus styling, introducing
prohibited Tailwind class usage across the changed UI.

Code

webapp/src/webapp/features/ai_session_analyzer/views/session_analysis.cljs[R82-88]

+    [:> (.-Root Accordion) {:type "single"
+                            :collapsible true
+                            :class "w-full p-3 bg-[--gray-1] rounded-md border border-[--gray-3]"}
+     [:> (.-Item Accordion) {:value "ai-decisions"
+                             :className "border-none"}
+      [:> (.-Header Accordion)
+       [:> (.-Trigger Accordion) {:className "group flex w-full items-center justify-between gap-3 text-left focus:outline-none focus-visible:ring focus-visible:ring-gray-500 focus-visible:ring-opacity-75"}

Relevance

●●● Strong

Changed UI directly violates the stated styling rule; similar CLJS styling cleanup was accepted.

PR-#1429

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The changed Reagent session analysis view adds multiple Tailwind utility class strings to the new AI
decisions accordion and its contents, including w-full, p-3, flex, focus:outline-none, and
text-gray-10.

Rule 1800957: Disallow Tailwind CSS class usage in React components (Mantine-only styling) webapp/src/webapp/features/ai_session_analyzer/views/session_analysis.cljs[82-109]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new AI decisions view uses Tailwind utility class strings in Reagent UI code, including layout, spacing, colors, and focus styles, while the project requires Mantine-only styling.

## Fix Focus Areas
- webapp/src/webapp/features/ai_session_analyzer/views/session_analysis.cljs[82-88]
- webapp/src/webapp/features/ai_session_analyzer/views/session_analysis.cljs[90-109]

## Recommended Fix
Replace the Tailwind utility classes with the project's approved Mantine component props, existing component styles, or scoped CSS module classes. Preserve the accordion layout, visible focus indicator, spacing, colors, and text wrapping without retaining Tailwind utility names.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

TestReviewViaHandoffMigrationRoundTrip starts pglite directly and manually migrates it instead
of using the shared migrated-database helper. The test still runs against a resumed database state,
so its independent lifecycle can diverge from the package-wide test setup and migration behavior.

Code

gateway/models/review_via_handoff_migration_test.go[R25-27]

+	inst, err := pglite.Start(ctx, t.TempDir())
+	require.NoError(t, err)
+	t.Cleanup(func() { inst.Close(ctx) })

Relevance

●●● Strong

Explicit helper rule and deterministic shared-lifecycle fix; migration tests should use the package
helper.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new migration test directly calls pglite.Start and performs manual migration setup, while the
checklist requires migrated embedded database tests to use pglitetest.StartMigrated(t) and the
package-level shared lifecycle.

Rule 3854809: Use pglitetest helpers for migrated embedded database tests gateway/models/review_via_handoff_migration_test.go[25-36]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`TestReviewViaHandoffMigrationRoundTrip` directly starts and closes an embedded database, bypassing the required `pglitetest` lifecycle for migrated database tests.

## Fix Focus Areas
- gateway/models/review_via_handoff_migration_test.go[25-36]

## Recommended Fix
Refactor the test setup to use the shared `pglitetest` package and its package-level `TestMain` lifecycle. Preserve the test's need to migrate to historical versions by using a supported helper or extending the shared test helper rather than constructing and migrating the embedded database directly in the test.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

TestReviewViaHandoffMigrationRoundTrip queries pg_indexes without a schema prefix while checking
the migrated review index. The resumed embedded database does not guarantee the migration search
path, so this catalog lookup relies on implicit resolution instead of explicitly targeting
pg_catalog.pg_indexes.

Code

gateway/models/review_via_handoff_migration_test.go[R84-85]

+		require.NoError(t, models.DB.Raw(`SELECT indexdef FROM pg_indexes
+			WHERE schemaname = 'private' AND indexname = 'index_reviews_sidecar_level_statement'`).Row().Scan(&indexDef))

Relevance

●●● Strong

Schema qualification is a deterministic SQL correctness fix explicitly required for resumed
embedded-database tests.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The added SQL query uses FROM pg_indexes without a schema prefix in a test that resumes an
embedded database; the checklist requires all non-default-schema tables and views in such tests to
be schema-qualified.

Rule 3854814: Schema-qualify SQL identifiers in tests using resumed embedded databases gateway/models/review_via_handoff_migration_test.go[84-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The resumed-database migration test references the `pg_indexes` view without an explicit schema qualification.

## Fix Focus Areas
- gateway/models/review_via_handoff_migration_test.go[84-85]

## Recommended Fix
Change the query to reference `pg_catalog.pg_indexes` explicitly while retaining the existing `schemaname` and `indexname` filters.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

EvaluateWith calls e.handoff(...) synchronously during evaluation, so the second model turn and
its takeCall() run before any later evaluator in the chain. The approval agent was built to wait
for those: requestAgentApproval defers through ec.RequestReview so its call runs only after
every later evaluator allowed. On a lane where a later guardrail or OPA rule denies a statement, the
hand-off still spends a max_calls or rate-limit slot and adds model latency. Once the budget runs
out, the hand-off fails safe to its most restrictive allowed action, or the lane denies statements
outright because it holds.

Code

sidecar/analyzer/evaluator.go[R601-606]

+	if action == ActionHandoff {
+		// risk_action stays ai-handoff; the decision and its reason ride
+		// beside it. A cached decision is reused, but a hold it selects
+		// still runs for this statement.
+		return e.applyHandoff(stmt, ec, notes, level, c, e.handoff(ctx, stmt, ec, level, c))
+	}

Relevance

●● Moderate

Recent evaluator precedents accept budget and concurrency fixes, but deferring handoff calls is
architectural and context-sensitive.

PR-#1892 PR-#1682

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

handoff calls takeCall and agentCall inline. The approval agent defers its call through
ec.RequestReview so it runs only after the later evaluators allowed. The hand-off path does not
defer, so later denials still cost a call. takeCall draws on the classification's shared budget.

sidecar/analyzer/handoff.go[255-276] sidecar/analyzer/approver.go[212-232] sidecar/analyzer/approver.go[342-362]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The hand-off agent's model call runs synchronously in `EvaluateWith`, before later evaluators. It spends `max_calls` and rate-limit budget even when a later rule denies the statement. The approval agent avoids this by deferring through `ec.RequestReview`.

## Fix Focus Areas
- sidecar/analyzer/evaluator.go[601-606]
- sidecar/analyzer/handoff.go[229-277]
- sidecar/analyzer/approver.go[217-232]

## Recommended Fix
When `ec != nil`, register the hand-off through `ec.RequestReview(policy.ReviewRequest{Resolve: ...})` so the model call and the `applyHandoff` result are produced only after the later evaluators allow. Fall back to the synchronous path only when there is no EvalContext. Keep the cache lookup before the deferral so a cache hit still costs nothing. If you keep the synchronous call on purpose, add a comment explaining why and note the budget cost in the README.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

PromptField renders the visible Your prompt text as a Text component while the textarea only
receives aria-label="Your prompt" and no associated label/id pair. Users who rely on the
required visible form label association cannot connect that prompt text to the focusable textarea
when the editor is opened.

Code

webapp_v2/src/pages/Features/AiSessionAnalyzer/components/PromptField.jsx[R22-45]

+          <Text size="sm">
+            <OptionalLabel>Your prompt</OptionalLabel>
+          </Text>
+          {!open && (
+            <Text size="xs" c="dimmed">
+              Uses the default prompt.
+            </Text>
+          )}
+        </Stack>
+        {open ? (
+          <Button variant="transparent" size="xs" px={0} leftSection={<Undo2 size={14} />} onClick={useDefault}>
+            Use default
+          </Button>
+        ) : (
+          <Button variant="transparent" size="xs" px={0} leftSection={<SquarePen size={14} />} onClick={() => setEditing(true)}>
+            Edit prompt
+          </Button>
+        )}
+      </Group>
+      {open && (
+        <Textarea
+          aria-label="Your prompt"
+          placeholder={placeholder}
+          description={helper}

Relevance

● Weak

A recent accessibility finding requiring visible label association was explicitly rejected in a
comparable UI context.

PR-#1961

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The newly added prompt field displays Your prompt inside a Mantine Text component, while the
interactive Textarea has no id and no visible label wrapper; it only sets aria-label. The
checklist requires each visible textarea to have an associated visible label or to be nested inside
one.

Rule 1800943: Associate each form input with a visible <label> element webapp_v2/src/pages/Features/AiSessionAnalyzer/components/PromptField.jsx[22-45] webapp_v2/src/pages/Features/AiSessionAnalyzer/components/PromptField.jsx[41-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The prompt textarea has only an `aria-label`; the visible `Your prompt` text is not a `<label>` associated with the control.

## Fix Focus Areas
- webapp_v2/src/pages/Features/AiSessionAnalyzer/components/PromptField.jsx[22-45]

## Recommended Fix
Give the textarea a stable `id` and render the visible `Your prompt` text through the component's visible label support or an explicit `<label htmlFor="...">`. Keep the label association intact for every rendered prompt field.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Dismiss ↗ | View ↗

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗