Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@apps/backend/prisma/migrations/20260327000000_add_ai_conversations/migration.sql`:
- Around line 2-11: The AiConversation table is missing a foreign-key constraint
on projectId which allows orphaned conversations; update the migration SQL to
add a foreign key constraint on "projectId" referencing the primary key of the
Project table (e.g., "Project"."id") with ON DELETE CASCADE, and then update the
Prisma schema to add the corresponding relation fields (e.g., in the
AiConversation model add an explicit relation to Project and mark projectId as
the foreign key) so Prisma migrations and runtime enforce cascade deletes; apply
the same change for the other similar table(s) referenced (lines 30-31) to keep
behavior consistent.

In `@apps/backend/prisma/schema.prisma`:
- Around line 1105-1113: The AiMessage model currently relies on createdAt for
ordering which is nondeterministic for batch inserts (createMany()); add an
explicit integer position field to AiMessage (e.g., position Int) and create a
composite index on (conversationId, position) to preserve stable ordering, then
update any insertion code that uses createMany() or individual message inserts
to set position according to the input array order (ensuring position increments
per conversation) and change queries that used orderBy: { createdAt: "asc" } to
orderBy: { position: "asc" } (keep conversationId and createdAt untouched aside
from indexing).

In
`@apps/backend/src/app/api/latest/internal/ai-conversations/`[conversationId]/messages/route.tsx:
- Around line 46-61: The current handler calls getOwnedConversation then deletes
messages and separately calls createMany, which can leave the conversation empty
on failure and doesn't update AiConversation.updatedAt; wrap the deleteMany +
optional createMany + an update to touch the parent conversation (update
AiConversation.updatedAt for params.conversationId) inside a single Prisma
transaction (use globalPrismaClient.$transaction) so the delete/insert/update
are atomic and the parent conversation's updatedAt is updated even when messages
array is empty; keep getOwnedConversation as the authorization check before the
transaction and reference params.conversationId,
globalPrismaClient.aiMessage.deleteMany,
globalPrismaClient.aiMessage.createMany, and
globalPrismaClient.aiConversation.update (or the appropriate model name) when
implementing.

In `@apps/backend/src/app/api/latest/internal/ai-conversations/route.tsx`:
- Around line 97-114: The code creates an aiConversation and then calls
globalPrismaClient.aiMessage.createMany separately, which can leave a dangling
conversation if message insertion fails; change this to an atomic operation by
either wrapping both calls in a Prisma transaction (use
globalPrismaClient.$transaction([ ... ]) to create the conversation and create
messages) or perform a nested create in the aiConversation.create call (include
the relation field and use messages: { create: body.messages.map(m => ({ role:
m.role, content: m.content })) } so messages are created as part of the same
write). Update the handler to use one of these approaches instead of separate
aiConversation.create and aiMessage.createMany calls.
- Around line 77-85: The request body schema's messages array uses yupString()
for role and yupMixed() for content, causing downstream casts (e.g., the
"msg.content as object" usage); update the body: yupObject(...) messages schema
so role is constrained with
yupString().oneOf(["user","assistant","system"]).defined() and content is
validated as the exact persisted message object shape (replace yupMixed() with a
yupObject(...) that matches the stored message fields), and apply the identical
tightened schema to the sibling PUT handler in
[conversationId]/messages/route.tsx so callers and handlers no longer need
runtime type casts.

In `@apps/dashboard/src/components/commands/ai-chat-shared.tsx`:
- Around line 408-412: The getToolInvocations function uses a double cast (as
unknown as ToolInvocationPart) which bypasses TypeScript safety; replace this
with a proper type guard or runtime validation: add a predicate like
isToolInvocationPart(part): part is ToolInvocationPart (checking required
properties/shape of ToolInvocationPart) and use message.parts.filter((part):
part is ToolInvocationPart => part.type.startsWith("tool-") &&
isToolInvocationPart(part)) then return the filtered array directly; reference
getToolInvocations, UIMessage, and ToolInvocationPart when adding the guard.

In `@apps/dashboard/src/components/stack-companion/ai-chat-widget.tsx`:
- Around line 185-201: The effect that fetches the latest conversation (inside
useEffect) omits projectId from its dependency array, causing stale
conversations when the user switches projects; update the dependency list to
include projectId (and any other used values like currentUser or
runAsynchronously if not stable) so the effect re-runs on project change,
ensuring listConversations/currentUser/getConversation, setViewMode, and
setConversationKey operate against the correct project; alternatively ensure the
component remounts on project change, but the simplest fix is to add projectId
to the useEffect dependencies.
- Around line 352-368: The save block using runAsynchronously currently lets
errors from createConversation or replaceConversationMessages fail silently;
update the inner async to catch errors (surround the await calls for
replaceConversationMessages/createConversation with try/catch), call a
user-visible notifier (e.g., runAsynchronouslyWithAlert or the app's toast/alert
mechanism) inside the catch with a clear message including the error, still set
isSavingRef.current = false in finally, and keep the existing logic that sets
conversationIdRef.current and calls onConversationCreated(result.id) only on
success.
- Around line 191-195: The code in initialMessages maps conv.messages using
unsafe casts for msg.role and msg.content; update the
ConversationDetail.messages type to reflect the real API shape (role: "user" |
"assistant" and content: UIMessage["parts"]) or add runtime validation before
mapping (validate msg.role is "user"|"assistant" and that msg.content conforms
to UIMessage["parts"]) and only then construct initialMessages from
conv.messages to avoid unsafe casts in the initialMessages mapping.

In `@apps/dashboard/src/hooks/use-ai-conversations.ts`:
- Around line 67-73: The code interpolates conversationId directly into request
paths (see getConversation, updateConversationTitle,
replaceConversationMessages, deleteConversation), which risks path traversal if
an attacker supplies malicious input; fix by validating or encoding the id
before using it in the URL: either enforce a strict format (e.g., UUID regex)
and throw on invalid values, or always URL-encode conversationId with
encodeURIComponent() and use the encoded value in apiFetch; apply the same
validation/encoding pattern consistently across the listed functions.

---

Nitpick comments:
In `@apps/dashboard/src/components/commands/ai-chat-shared.tsx`:
- Around line 188-190: The code currently force-casts invocation.input and
invocation.output to specific shapes (see invocation, input, queryArg, result)
which is unsafe; update usages to validate types before access by checking that
invocation?.input is an object and invocation?.output is an object with expected
keys (e.g., typeof input.query === "string" before assigning queryArg and
checking typeof result.success === "boolean" or Array.isArray(result.result)
before using them), replace direct assumptions with optional chaining and safe
guards, and add a small fallback/default values when fields are missing so
consumer code using queryArg, result.success, result.result, and result.rowCount
won’t throw if the SDK shape changes.
- Around line 18-22: The handleCopy handler schedules a setTimeout to reset
copied state which may run after the component unmounts; modify handleCopy and
the component to store the timeout id in a ref (e.g., timeoutRef) and clear it
in a useEffect cleanup to avoid calling setCopied on an unmounted component:
when calling setTimeout in handleCopy save the returned id to
timeoutRef.current, and in a useEffect return a cleanup that calls
clearTimeout(timeoutRef.current) and resets timeoutRef.current to null; also
clear any existing timeout before setting a new one in handleCopy to prevent
overlaps.

In `@apps/dashboard/src/components/stack-companion/ai-chat-widget.tsx`:
- Around line 564-568: The last-assistant detection logic (currently computed in
the isLastAssistant const using message.role, index, arr and the end-user check)
is hard to read—extract this into a small helper function (e.g.,
isLastAssistantAtIndex(messages, index) or computeIsLastAssistant) and use that
helper in place of the inline expression; inside the helper add a one-line
comment explaining the rule (treat the final assistant as not-last if the very
last message is a user), then update the displayContent line to use the new
helper while keeping existing dependencies like messageContent and aiLoading
unchanged.

In `@apps/dashboard/src/hooks/use-ai-conversations.ts`:
- Around line 41-43: The error thrown when response.ok is false in
use-ai-conversations.ts only includes the status code; update the failure path
in the function that performs the fetch (e.g., the fetch call inside
useAIConversations or fetchAIConversations) to read the response body
(preferably via response.text() or response.json() guarded in a try/catch),
include a truncated/limited portion of that body in the error message along with
the status (e.g., `AI conversations API error: ${response.status} -
${bodySnippet}`), and fall back to a safe message if reading the body fails to
avoid masking the original error.