Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@backend/src/entities/table-schema/application/data-transfer-objects/generate-schema-change.dto.ts`:
- Around line 19-29: The DTO's `@ApiProperty` marks threadId as nullable but the
TypeScript declaration excludes null; update the property in
generate-schema-change.dto.ts so the TypeScript type allows null (e.g.,
threadId?: string | null) and keep the existing decorators (`@ApiProperty` with
nullable: true, `@IsOptional`(), `@IsUUID`()) so validation still skips
null/undefined and UUID validation runs for non-null values.

In
`@backend/src/entities/table-schema/application/data-transfer-objects/schema-change-batch-response.dto.ts`:
- Around line 21-22: The response DTO's description for the threadId field
incorrectly tells clients to pass it as a query param; update the docstring for
the threadId property in SchemaChangeBatchResponseDto (the DTO where threadId is
declared) to state that threadId should be returned by the server and included
in subsequent requests in the request body (not as a query param), e.g.,
"Present when the request used or created a chat thread. Include this threadId
in the request body of subsequent generate calls to continue the conversation
with full prior context."

In
`@backend/src/entities/table-schema/schema-change-chat/schema-change-chat-message/schema-change-chat-message.entity.ts`:
- Around line 22-23: The entity column for role currently allows null even
though saveMessage(...) requires a role; change the Column on
schema-change-chat-message.entity (the role property of type MessageRole) to be
non-nullable (nullable: false) and remove the default null so the DB enforces
presence; additionally add a migration to backfill or reject existing null rows
(e.g., set a sensible default role or fail migration) and apply the schema
change so the database constraint matches the saveMessage(...) contract.

In
`@backend/src/entities/table-schema/schema-change-chat/schema-change-chat/schema-change-chat.entity.ts`:
- Around line 21-22: The entity property "name" is declared as type string but
the Column decorator lacks nullable: true while createChatForUser writes name:
null; update the SchemaChangeChat entity by adding nullable: true to the `@Column`
on the name property (and/or adjust the TypeScript type to string | null) so the
DB mapping and the write path (createChatForUser) are consistent; ensure you
modify the Column decorator on the name field and the property type accordingly.

In
`@backend/src/entities/table-schema/use-cases/generate-schema-change.use-case.ts`:
- Around line 102-106: The call to generateAndUpdateChatName in the isNewChat
branch is fire-and-forget and can fail because GlobalDatabaseContext is
request-scoped and may be destroyed before the async work completes; either
await the call (await this.generateAndUpdateChatName(chat.id, userPrompt)) so
the request lifecycle keeps the DB context alive and handle errors with
try/catch + Sentry.captureException, or instead delegate the task to a
singleton/background worker (e.g., a ChatNameGenerationService.enqueue(chat.id,
userPrompt) or BackgroundJobService) that performs the DB write outside the
request scope; update the code that currently calls
this.generateAndUpdateChatName(...).catch(...) accordingly.
- Around line 173-189: The resolveChat method currently creates a new chat when
a threadId is supplied but not found/owned by the user; change it so that if a
non-null threadId is provided and findChatByIdAndUserId returns no chat, you
throw a BadRequestException instead of falling through to createChatForUser.
Keep the existing connection_id check (existing.connection_id !== connectionId)
and only call createChatForUser when threadId is null; update the logic in
resolveChat to detect the "threadId supplied but missing" case and raise an
error.

---

Nitpick comments:
In
`@backend/src/entities/table-schema/schema-change-chat/schema-change-chat-message/repository/schema-change-chat-message-repository.extension.ts`:
- Around line 13-19: The deleteMessagesForChat method uses the literal table
name 'schema_change_chat_message' which is fragile; change it to use the entity
class SchemaChangeChatMessageEntity to gain type safety and refactor resilience.
Update the query in deleteMessagesForChat to reference the entity (e.g., pass
SchemaChangeChatMessageEntity to createQueryBuilder or to .from) instead of the
string, keep the same where parameter (chatId) and .execute() call, and ensure
any import of SchemaChangeChatMessageEntity is added at the top of the file.

In
`@backend/src/entities/table-schema/use-cases/generate-schema-change.use-case.ts`:
- Around line 103-106: The call site uses a redundant .catch on the
fire-and-forget call to generateAndUpdateChatName(chat.id, userPrompt) even
though generateAndUpdateChatName already handles and Sentry-captures its own
errors; remove the trailing .catch((error) => { Sentry.captureException(error);
}) so the call becomes a plain fire-and-forget invocation, or if you intended
outer handling instead, change generateAndUpdateChatName to rethrow errors and
use await + .catch here—refer to generateAndUpdateChatName for the internal
try/catch and the caller where generateAndUpdateChatName(chat.id,
userPrompt).catch(...) is used.

In `@backend/src/migrations/1778767036234-AddSchemaChangeChatEntities.ts`:
- Around line 6-26: The migration creates schema_change_chat and
schema_change_chat_message and adds FKs but does not create indexes on the FK
columns; add CREATE INDEX statements for schema_change_chat(user_id),
schema_change_chat(connection_id) and schema_change_chat_message(chat_id) inside
the up() method (after the corresponding CREATE TABLE/ALTER TABLE statements)
and add corresponding DROP INDEX statements in the down() method to reverse the
change so deletes and common queries are not forced to do full-table scans;
reference the up() method and the tables schema_change_chat and
schema_change_chat_message and the columns user_id, connection_id, chat_id when
making the changes.