apps/meteor/app/api/server/v1/email-inbox.ts (1)

79-82: Consider simplifying the maxRetries extraction.

Since isEmailInbox validates the body and the EmailInboxProps type already defines maxRetries?: number in imap, the type assertions here are verbose. A simpler approach would leverage the validated type directly.

✨ Suggested simplification

-		const maxRetries =
-			'maxRetries' in body.imap && typeof (body.imap as { maxRetries?: number }).maxRetries === 'number'
-				? (body.imap as { maxRetries: number }).maxRetries
-				: 5;
+		const maxRetries = body.imap.maxRetries ?? 5;

🤖 Prompt for AI Agents

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

In `@apps/meteor/app/api/server/v1/email-inbox.ts` around lines 79 - 82, The
current verbose extraction of maxRetries can be simplified: since isEmailInbox
validates the request and EmailInboxProps declares imap.maxRetries as optional,
remove the type assertions and conditional checks and instead read maxRetries
directly from body.imap using optional chaining and a fallback (default) of 5;
update the assignment for the maxRetries variable (referencing maxRetries and
body.imap) to use this simpler pattern and drop the unnecessary casts.

apps/meteor/app/api/server/v1/calendar.ts (1)

17-25: Empty schema definition for data property.

The data: {} schema is effectively a no-op validation that allows any value. For proper validation, define the array structure:

Suggested schema improvement

 const successWithDataSchema = ajv.compile<{ data: ICalendarEvent[] }>({
 	type: 'object',
 	properties: {
-		data: {},
+		data: {
+			type: 'array',
+			items: { $ref: '#/components/schemas/ICalendarEvent' },
+		},
 		success: { type: 'boolean', enum: [true] },
 	},
 	required: ['data', 'success'],
 	additionalProperties: false,
 });

🤖 Prompt for AI Agents

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

In `@apps/meteor/app/api/server/v1/calendar.ts` around lines 17 - 25, The
successWithDataSchema currently uses an empty schema for the data property which
allows any value; update the data property in successWithDataSchema to a proper
array schema (type: "array") whose items validate ICalendarEvent shape (either
inline with items: { type: "object", properties: { ... } , required: [...] }
matching ICalendarEvent fields or by referencing a defined schema/$ref for
ICalendarEvent), so the compiled schema enforces that data is an array of valid
ICalendarEvent objects and still requires success: true and no
additionalProperties.

apps/meteor/app/api/server/v1/integrations.ts (1)

225-271: Consider adding block scope to switch cases for safer variable declarations.

The const outgoingId (line 241) and const incomingId (line 262) declarations inside switch cases without block scope could lead to potential variable access issues if the code is modified in the future. While the current logic with early returns prevents this, adding blocks is a defensive pattern.

♻️ Optional: Add block scope to switch cases

 switch (bodyParams.type) {
-  case 'webhook-outgoing':
+  case 'webhook-outgoing': {
     if (!bodyParams.target_url && !bodyParams.integrationId) {
       return API.v1.failure('An integrationId or target_url needs to be provided.');
     }
     // ... existing code ...
     const outgoingId = integration._id;
     await deleteOutgoingIntegration(outgoingId, this.userId);
     return API.v1.success({
       integration,
     });
-  case 'webhook-incoming':
+  }
+  case 'webhook-incoming': {
     // ... existing code ...
     const incomingId = integration._id;
     await deleteIncomingIntegration(incomingId, this.userId);
     return API.v1.success({
       integration,
     });
+  }
   default:
     return API.v1.failure('Invalid integration type.');
 }

🤖 Prompt for AI Agents

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

In `@apps/meteor/app/api/server/v1/integrations.ts` around lines 225 - 271, The
switch cases declare consts outgoingId and incomingId without block braces which
risks name collisions if cases are later modified; wrap the 'webhook-outgoing'
and 'webhook-incoming' case bodies in their own block scopes (add { ... } around
each case body) so the declarations for outgoingId/incomingId and the calls to
Integrations.findOne, deleteOutgoingIntegration, and deleteIncomingIntegration
are confined to their respective blocks and cannot leak or collide.

apps/meteor/client/views/directory/tabs/users/UsersTable/UsersTable.tsx (1)

120-120: Improve REST type definitions to eliminate the double cast workaround.

The double cast as unknown as Serialized<IDirectoryUserResult> is a workaround for incomplete REST typing. The endpoint correctly supports type='users' filtering via useDirectoryQuery(..., 'users', workspace), which ensures only user results are returned. However, the REST type definition returns a union (IDirectoryUserResult | IDirectoryChannelResult)[] regardless of the type parameter.

Consider updating /v1/directory endpoint typing to support type-narrowed return types, so the return type is IDirectoryUserResult[] when type='users' is passed, eliminating the need for the cast.

🤖 Prompt for AI Agents

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

In `@apps/meteor/client/views/directory/tabs/users/UsersTable/UsersTable.tsx` at
line 120, The code uses a double-cast in UsersTable.tsx (user={user as unknown
as Serialized<IDirectoryUserResult>}) because the /v1/directory REST types
always return a union; fix by updating the directory endpoint typing (e.g., the
useDirectoryQuery hook or its underlying API client) to be
type-narrowing/overloaded so when called with type='users' it returns
Serialized<IDirectoryUserResult[]>, or add a generic type parameter to
useDirectoryQuery that infers the return as IDirectoryUserResult[]; after
updating the endpoint/useDirectoryQuery signature, remove the double-cast in
UsersTable.tsx and use the correct typed user value directly.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

docs/api-endpoint-migration.md (1)

424-426: Add a language identifier to the fenced code block.

The error message example should have a language identifier (e.g., text or plaintext) to satisfy markdown linting rules and improve readability.

📝 Suggested fix

-```
+```text
 must match exactly one schema in oneOf (passingSchemas: 0,1)

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

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

In @docs/api-endpoint-migration.md around lines 424 - 426, The fenced code block
containing the error message "must match exactly one schema in oneOf
(passingSchemas: 0,1)" lacks a language identifier; update that code fence to
include a language specifier (for example change the opening totext or

linting/formatting rules.

apps/meteor/app/api/server/v1/moderation.ts (1)

363-373: Consider separating historical report emails from current user emails.

The endpoint overwrites user.emails (fetched from the Users collection at line 349) with emails collected from historical reports (lines 365-372). This conflates current user data with historical snapshots captured when reports were filed.

If the goal is to show emails as they were when reports were created, store them in a separate field like reportedEmails instead. This clarifies the API contract: consumers can then distinguish between the user's current emails and historical emails from reports.

Note: The type definition includes a comment "we're assuming neither Room Info or User Info changes," suggesting this design is intentional but represents a known limitation.

🤖 Prompt for AI Agents

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

In `@apps/meteor/app/api/server/v1/moderation.ts` around lines 363 - 373, The code
currently overwrites user.emails with emails extracted from reports (see the
emailSet variable and the reports.forEach block), which mixes historical report
snapshots with current user data; instead, collect those report emails into a
new field (e.g., reportedEmails) on the returned user object rather than
assigning to user.emails — leave user.emails untouched, set user.reportedEmails
= Array.from(emailSet.values()) (or similar) so consumers can distinguish
current emails from historical report emails.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

docs/api-endpoint-migration.md (2)

510-535: 🛠️ Refactor suggestion | 🟠 Major

Clarify augmentation scope in "What augmentation enables" section.

Similar to line 454, the comment and list here imply augmentations make routes visible to all SDK consumers, but this is only accurate for code compiled within the same TypeScript project. The "Client SDK" bullet point may be misleading for independently-compiled packages like packages/ddp-client.

Consider adding a note after the list clarifying that augmentation benefits apply to code compiled in the same context as the augmentation (e.g., within apps/meteor), and that independently-compiled packages like ddp-client will not see these augmentations unless TypeScript project references are configured. Based on learnings: In the RocketChat/Rocket.Chat monorepo, packages/ddp-client and apps/meteor do not use TypeScript project references, so module augmentations in apps/meteor are not visible when compiling packages/ddp-client in isolation.

🤖 Prompt for AI Agents

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

In `@docs/api-endpoint-migration.md` around lines 510 - 535, Add a clarifying note
after the "What augmentation enables" list stating that the module augmentation
via declare module '@rocket.chat/rest-typings' (and types extracted with
ExtractRoutesFromAPI/typeof myEndpoints) only takes effect for code compiled
within the same TypeScript project/compilation context (so useEndpoint and
api.get typed benefits apply only to consumers built together), and explicitly
call out that independently-compiled packages like packages/ddp-client will not
see these augmentations unless TypeScript project references or equivalent
cross-package type sharing is configured.

---

454-454: 🛠️ Refactor suggestion | 🟠 Major

Narrow the scope claim about augmentation visibility.

The phrase "across the entire codebase (SDK, client, tests)" overstates the reach of module augmentations declared in apps/meteor. These augmentations are only visible to code compiled in the same TypeScript project context. Based on learnings: In the RocketChat/Rocket.Chat monorepo, packages/ddp-client and apps/meteor do not use TypeScript project references, so module augmentations in apps/meteor are not visible when compiling packages/ddp-client in isolation.

Consider rephrasing to clarify that augmentations make routes typed for consumers that share the same compilation context (e.g., code within apps/meteor and packages compiled alongside it), but not for independently-compiled packages like ddp-client.

🤖 Prompt for AI Agents

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

In `@docs/api-endpoint-migration.md` at line 454, Update the sentence that claims
augmentations apply "across the entire codebase (SDK, client, tests)" to narrow
the scope: state that module augmentations (when chaining migrated endpoints,
storing result, and using ExtractRoutesFromAPI to augment the Endpoints
interface in rest-typings) only apply to consumers compiled in the same
TypeScript project/context (e.g., code within apps/meteor or packages compiled
together) and are not visible to independently compiled packages like
packages/ddp-client in the RocketChat monorepo that lack project references;
adjust the example wording to mention apps/meteor explicitly as the augmentation
declaration location and note the limitation for independently-built packages.

apps/meteor/app/api/server/v1/misc.ts (2)

603-613: ⚠️ Potential issue | 🟠 Major

The 429 contract is still unreachable in both method-call handlers.

The rate-limit Meteor.Error is thrown inside the try, but both catch blocks immediately normalize it to API.v1.failure(...), so callers still get the generic 400 payload instead of 429. Once that case is preserved, method.callAnon/:method also needs a 429 response mapping.

Also applies to: 639-659, 671-719

🤖 Prompt for AI Agents

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

In `@apps/meteor/app/api/server/v1/misc.ts` around lines 603 - 613, The 429 schema
is unreachable because rate-limit Meteor.Error thrown inside the try is being
normalized to API.v1.failure in the catch blocks for the method handlers; update
the catch logic in the method.call/:method and method.callAnon/:method handlers
to detect the rate-limit Meteor.Error (check for the Meteor.Error instance and
its rate-limit identifying fields, e.g. error code/string or numeric 429) and
preserve it by either rethrowing it or by returning a response with HTTP status
429 (rather than the generic 400), and ensure you add the same 429 response
mapping to the method.callAnon/:method responses block so the OpenAPI contract
matches the runtime behavior.

---

333-373: ⚠️ Potential issue | 🟠 Major

Keep optional spotlight fields out of required.

Line 351 makes name and statusText mandatory, but spotlight user hits can legitimately omit those fields. This schema will reject valid responses when test-mode response validation is enabled.

🤖 Prompt for AI Agents

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

In `@apps/meteor/app/api/server/v1/misc.ts` around lines 333 - 373, The
spotlightResponseSchema currently marks user fields "name" and "statusText" as
required which rejects valid spotlight hits; update the users item schema in
spotlightResponseSchema by removing "name" and "statusText" from the required
array (leave only the truly mandatory fields such as "_id" and "username", and
optionally "status" if you want to keep it required) so optional spotlight
fields are not enforced during validation.

docs/api-endpoint-migration.md (1)

424-426: Add language specifier to fenced code block.

The error message example should have a language specifier for consistency.

📝 Proposed fix

-```
+```text
 must match exactly one schema in oneOf (passingSchemas: 0,1)

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

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

In @docs/api-endpoint-migration.md around lines 424 - 426, The fenced code block
containing the error message "must match exactly one schema in oneOf
(passingSchemas: 0,1)" needs a language specifier added to the opening
backticks; update the block in the docs to use a labeled fence (for example
change totext) so the snippet is consistently highlighted as plain text.

</details>

</blockquote></details>
<details>
<summary>apps/meteor/app/api/server/v1/moderation.ts (1)</summary><blockquote>

`24-29`: **Please move the repeated AJV workaround note out of the implementation.**

The same TODO block is repeated five times here. A single linked issue or helper-level note would keep this migration diff smaller.

As per coding guidelines `Avoid code comments in the implementation`.


Also applies to: 62-67, 118-123, 151-156, 506-511

<details>
<summary>🤖 Prompt for AI Agents</summary>

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

In `@apps/meteor/app/api/server/v1/moderation.ts` around lines 24 - 29, Move the
repeated AJV workaround TODO about IModerationAudit.ts/Date|string out of the
implementation and into a single shared location (e.g., file header comment or a
dedicated migration/README helper) and replace each inline block with a short
one-line pointer to that single note; specifically, consolidate the comment that
explains the ts union causing AJV oneOf failures (mentions IModerationAudit, ts,
AJV, and the relaxed inline schema workaround) and remove the duplicate blocks
sprinkled through the implementation so only a single linked explanation
remains.
```

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>🤖 Prompt for all review comments with AI agents</summary>

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

Inline comments:
In @apps/meteor/app/api/server/v1/misc.ts:

• Around line 808-839: The code pushes a list of setting IDs into settingsIds
  but never includes 'Cloud_Workspace_Access_Token_Expires_At', so the
  auditSettingOperation branch that resets it (using Settings.resetValueById) is
  never executed; fix this by adding the exact string
  'Cloud_Workspace_Access_Token_Expires_At' to the settingsIds array where the
  other Cloud_Workspace_* IDs are pushed (so the existing map over settingsIds
  will call auditSettingOperation for it), keeping the existing special-case
  handling for 'uniqueID' and the Date(0) reset branch intact.

In @apps/meteor/app/api/server/v1/moderation.ts:

• Around line 405-425: The code only deletes the first page of reported messages
  because it uses getPaginationItems to set count/offset but then hides reports
  for the whole user; fix by retrieving and deleting all reported messages for the
  user before hiding reports. Replace the paginated fetch with a full fetch (use
  ModerationReports.findReportedMessagesByReportedUserId with offset 0 and count
  equal to totalCount or iterate the returned cursor until exhausted) so messages
  = await cursor.toArray() contains every reported message for userId, then call
  deleteReportedMessages(messages.map(m => m.message), moderator) and finally
  ModerationReports.hideMessageReportsByUserId(userId, this.userId,
  sanitizedReason, 'DELETE Messages').
• Around line 295-319: The current flow paginates raw report rows (cursor from
  ModerationReports.findReportedMessagesByReportedUserId) then deduplicates by
  report.message._id, which can return fewer unique messages than requested and
  misreport count; change the logic to perform deduplication before applying
  offset/count: retrieve all matching report rows (or modify
  ModerationReports.findReportedMessagesByReportedUserId to return distinct
  message-level results), build uniqueMessages by message._id first, then apply
  offset/count slicing to uniqueMessages, and ensure the returned count uses
  messages.length (uniqueMessages after slicing) while leaving total as the total
  unique message count; update usages of cursor, reports, uniqueMessages and the
  API.v1.success payload accordingly.

---

Duplicate comments:
In @apps/meteor/app/api/server/v1/misc.ts:

• Around line 603-613: The 429 schema is unreachable because rate-limit
  Meteor.Error thrown inside the try is being normalized to API.v1.failure in the
  catch blocks for the method handlers; update the catch logic in the
  method.call/:method and method.callAnon/:method handlers to detect the
  rate-limit Meteor.Error (check for the Meteor.Error instance and its rate-limit
  identifying fields, e.g. error code/string or numeric 429) and preserve it by
  either rethrowing it or by returning a response with HTTP status 429 (rather
  than the generic 400), and ensure you add the same 429 response mapping to the
  method.callAnon/:method responses block so the OpenAPI contract matches the
  runtime behavior.
• Around line 333-373: The spotlightResponseSchema currently marks user fields
  "name" and "statusText" as required which rejects valid spotlight hits; update
  the users item schema in spotlightResponseSchema by removing "name" and
  "statusText" from the required array (leave only the truly mandatory fields such
  as "_id" and "username", and optionally "status" if you want to keep it
  required) so optional spotlight fields are not enforced during validation.

In @docs/api-endpoint-migration.md:

• Around line 510-535: Add a clarifying note after the "What augmentation
  enables" list stating that the module augmentation via declare module
  '@rocket.chat/rest-typings' (and types extracted with
  ExtractRoutesFromAPI/typeof myEndpoints) only takes effect for code compiled
  within the same TypeScript project/compilation context (so useEndpoint and
  api.get typed benefits apply only to consumers built together), and explicitly
  call out that independently-compiled packages like packages/ddp-client will not
  see these augmentations unless TypeScript project references or equivalent
  cross-package type sharing is configured.
• Line 454: Update the sentence that claims augmentations apply "across the
  entire codebase (SDK, client, tests)" to narrow the scope: state that module
  augmentations (when chaining migrated endpoints, storing result, and using
  ExtractRoutesFromAPI to augment the Endpoints interface in rest-typings) only
  apply to consumers compiled in the same TypeScript project/context (e.g., code
  within apps/meteor or packages compiled together) and are not visible to
  independently compiled packages like packages/ddp-client in the RocketChat
  monorepo that lack project references; adjust the example wording to mention
  apps/meteor explicitly as the augmentation declaration location and note the
  limitation for independently-built packages.

---

Nitpick comments:
In @apps/meteor/app/api/server/v1/moderation.ts:

• Around line 24-29: Move the repeated AJV workaround TODO about
  IModerationAudit.ts/Date|string out of the implementation and into a single
  shared location (e.g., file header comment or a dedicated migration/README
  helper) and replace each inline block with a short one-line pointer to that
  single note; specifically, consolidate the comment that explains the ts union
  causing AJV oneOf failures (mentions IModerationAudit, ts, AJV, and the relaxed
  inline schema workaround) and remove the duplicate blocks sprinkled through the
  implementation so only a single linked explanation remains.

In @docs/api-endpoint-migration.md:

• Around line 424-426: The fenced code block containing the error message "must
  match exactly one schema in oneOf (passingSchemas: 0,1)" needs a language
  specifier added to the opening backticks; update the block in the docs to use a
  labeled fence (for example change totext) so the snippet is consistently
  highlighted as plain text.

</details>

<details>
<summary>🪄 Autofix (Beta)</summary>

Fix all unresolved CodeRabbit comments on this PR:

- [ ] <!-- {"checkboxId": "4b0d0e0a-96d7-4f10-b296-3a18ea78f0b9"} --> Push a commit to this branch (recommended)
- [ ] <!-- {"checkboxId": "ff5b1114-7d8c-49e6-8ac1-43f82af23a33"} --> Create a new PR with the fixes

</details>

---

<details>
<summary>ℹ️ Review info</summary>

<details>
<summary>⚙️ Run configuration</summary>

**Configuration used**: Organization UI

**Review profile**: CHILL

**Plan**: Pro

**Run ID**: `b477090a-a644-499a-a0a0-94a038249396`

</details>

<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between f5de26e3721a1870579ed3ebee8acd0012f30b8d and d0257b4f4c4c950a3138337cb8efb85c8570032f.

</details>

<details>
<summary>📒 Files selected for processing (9)</summary>

* `apps/meteor/app/api/server/definition.ts`
* `apps/meteor/app/api/server/v1/import.ts`
* `apps/meteor/app/api/server/v1/misc.ts`
* `apps/meteor/app/api/server/v1/moderation.ts`
* `docs/api-endpoint-migration.md`
* `packages/core-typings/src/Ajv.ts`
* `packages/http-router/src/Router.spec.ts`
* `packages/http-router/src/Router.ts`
* `packages/models/src/models/ModerationReports.ts`

</details>

<details>
<summary>🚧 Files skipped from review as they are similar to previous changes (3)</summary>

* packages/models/src/models/ModerationReports.ts
* packages/http-router/src/Router.ts
* packages/http-router/src/Router.spec.ts

</details>

</details>

<details>
<summary>📜 Review details</summary>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)</summary>

* GitHub Check: 📦 Build Packages
* GitHub Check: CodeQL-Build
* GitHub Check: CodeQL-Build

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>📓 Path-based instructions (1)</summary>

<details>
<summary>**/*.{ts,tsx,js}</summary>


**📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)**

> `**/*.{ts,tsx,js}`: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
> Avoid code comments in the implementation

Files:
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `packages/core-typings/src/Ajv.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `apps/meteor/app/api/server/definition.ts`

</details>

</details><details>
<summary>🧠 Learnings (18)</summary>

<details>
<summary>📓 Common learnings</summary>

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
```

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39414
File: apps/meteor/app/api/server/v1/rooms.ts:1241-1297
Timestamp: 2026-03-10T08:13:52.153Z
Learning: In the RocketChat/Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1/rooms.ts, the pattern `ajv.compile<void>({...})` is intentionally used for the 200 response schema even when the endpoint returns `{ success: true }`. This is an established convention across all migrated endpoints (rooms.leave, rooms.favorite, rooms.delete, rooms.muteUser, rooms.unmuteUser). Do not flag this as a type mismatch during reviews of these migration PRs.
```

```
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:18.785Z
Learning: In Rocket.Chat PR reviews, maintain strict scope boundaries—when a PR is focused on a specific endpoint (e.g., rooms.favorite), avoid reviewing or suggesting changes to other endpoints that were incidentally refactored (e.g., rooms.invite) unless explicitly requested by maintainers.
```

</details>
<details>
<summary>📚 Learning: 2026-02-24T19:09:01.522Z</summary>

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:01.522Z
Learning: In Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1, avoid introducing logic changes. Only perform scope-tight changes that preserve behavior; style-only cleanups (e.g., removing inline comments) may be deferred to follow-ups to keep the migration PR focused.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `apps/meteor/app/api/server/v1/misc.ts`

</details>
<details>
<summary>📚 Learning: 2026-03-10T08:13:52.153Z</summary>

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39414
File: apps/meteor/app/api/server/v1/rooms.ts:1241-1297
Timestamp: 2026-03-10T08:13:52.153Z
Learning: In the RocketChat/Rocket.Chat OpenAPI migration PRs for endpoints under apps/meteor/app/api/server/v1/rooms.ts, the pattern `ajv.compile<void>({...})` is intentionally used for the 200 response schema even when the endpoint returns `{ success: true }`. This is an established convention across all migrated endpoints (rooms.leave, rooms.favorite, rooms.delete, rooms.muteUser, rooms.unmuteUser). Do not flag this as a type mismatch during reviews of these migration PRs.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `packages/core-typings/src/Ajv.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-01-26T18:26:01.279Z</summary>

```
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 38227
File: apps/meteor/app/api/server/router.ts:44-49
Timestamp: 2026-01-26T18:26:01.279Z
Learning: In apps/meteor/app/api/server/router.ts, when retrieving bodyParams and queryParams from the Hono context via c.get(), do not add defensive defaults (e.g., ?? {}). The code should fail fast if these parameters are missing, as endpoint handlers expect them to be present and breaking here helps surface parsing problems rather than hiding them.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-01-17T01:51:47.764Z</summary>

```
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 38219
File: packages/core-typings/src/cloud/Announcement.ts:5-6
Timestamp: 2026-01-17T01:51:47.764Z
Learning: In packages/core-typings/src/cloud/Announcement.ts, the AnnouncementSchema.createdBy field intentionally overrides IBannerSchema.createdBy (object with _id and optional username) with a string enum ['cloud', 'system'] to match existing runtime behavior. This is documented as technical debt with a FIXME comment at apps/meteor/app/cloud/server/functions/syncWorkspace/handleCommsSync.ts:53 and should not be flagged as an error until the runtime behavior is corrected.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `packages/core-typings/src/Ajv.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-02-25T20:10:16.987Z</summary>

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38913
File: packages/ddp-client/src/legacy/types/SDKLegacy.ts:34-34
Timestamp: 2026-02-25T20:10:16.987Z
Learning: In the RocketChat/Rocket.Chat monorepo, packages/ddp-client and apps/meteor do not use TypeScript project references. Module augmentations in apps/meteor (e.g., declare module 'rocket.chat/rest-typings') are not visible when compiling packages/ddp-client in isolation, which is why legacy SDK methods that depend on OperationResult types for OpenAPI-migrated endpoints must remain commented out.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `apps/meteor/app/api/server/definition.ts`
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-02-23T17:53:06.802Z</summary>

```
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:06.802Z
Learning: During PR reviews that touch endpoint files under apps/meteor/app/api/server/v1, enforce strict scope: if a PR targets a specific endpoint (e.g., rooms.favorite), do not propose changes to unrelated endpoints (e.g., rooms.invite) unless maintainers explicitly request them. Focus feedback on the touched endpoint's behavior, API surface, and related tests; avoid broad cross-endpoint changes in the same PR unless requested.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `apps/meteor/app/api/server/v1/misc.ts`

</details>
<details>
<summary>📚 Learning: 2026-02-26T19:25:44.063Z</summary>

```
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In the Rocket.Chat repository, do not reference Biome lint rules in code review feedback. Biome is not used even if biome.json exists; only reference Biome rules if there is explicit, project-wide usage documented. For TypeScript files, review lint implications without Biome guidance unless the project enables Biome rules.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `packages/core-typings/src/Ajv.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `apps/meteor/app/api/server/definition.ts`

</details>
<details>
<summary>📚 Learning: 2026-02-26T19:25:44.063Z</summary>

```
Learnt from: gabriellsh
Repo: RocketChat/Rocket.Chat PR: 38778
File: packages/ui-voip/src/providers/useMediaSession.ts:192-192
Timestamp: 2026-02-26T19:25:44.063Z
Learning: In this repository (RocketChat/Rocket.Chat), Biome lint rules are not used even if a biome.json exists. When reviewing TypeScript files (e.g., packages/ui-voip/src/providers/useMediaSession.ts), ensure lint suggestions do not reference Biome-specific rules. Rely on general ESLint/TypeScript lint rules and project conventions instead.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/import.ts`
- `apps/meteor/app/api/server/v1/moderation.ts`
- `packages/core-typings/src/Ajv.ts`
- `apps/meteor/app/api/server/v1/misc.ts`
- `apps/meteor/app/api/server/definition.ts`

</details>
<details>
<summary>📚 Learning: 2026-03-03T11:11:48.541Z</summary>

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 39230
File: apps/meteor/app/api/server/v1/chat.ts:214-222
Timestamp: 2026-03-03T11:11:48.541Z
Learning: In apps/meteor/server/lib/moderation/reportMessage.ts, the reportMessage function validates that description is not empty or whitespace-only with `if (!description.trim())`. When migrating the chat.reportMessage endpoint to OpenAPI, adding minLength validation to the schema preserves this existing behavior.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/moderation.ts`
- `apps/meteor/app/api/server/v1/misc.ts`

</details>
<details>
<summary>📚 Learning: 2026-02-24T19:36:55.089Z</summary>

```
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 38493
File: apps/meteor/tests/e2e/page-objects/fragments/home-content.ts:60-82
Timestamp: 2026-02-24T19:36:55.089Z
Learning: In RocketChat/Rocket.Chat e2e tests (apps/meteor/tests/e2e/page-objects/fragments/home-content.ts), thread message preview listitems do not have aria-roledescription="message", so lastThreadMessagePreview locator cannot be scoped to messageListItems (which filters for aria-roledescription="message"). It should remain scoped to page.getByRole('listitem') or mainMessageList.getByRole('listitem').
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/moderation.ts`
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-03-11T16:46:50.707Z</summary>

```
Learnt from: ricardogarim
Repo: RocketChat/Rocket.Chat PR: 39535
File: apps/meteor/app/apps/server/bridges/livechat.ts:249-249
Timestamp: 2026-03-11T16:46:50.707Z
Learning: In `apps/meteor/app/apps/server/bridges/livechat.ts`, `createVisitor()` intentionally does not propagate `externalIds` to `registerData`. This is by design: the method is deprecated (JSDoc: `deprecated Use createAndReturnVisitor instead. Note: This method does not support externalIds.`) to push callers toward `createAndReturnVisitor()`, which does support `externalIds`. Do not flag the missing `externalIds` field in `createVisitor()` as a bug.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/misc.ts`

</details>
<details>
<summary>📚 Learning: 2025-10-06T20:32:23.658Z</summary>

```
Learnt from: d-gubert
Repo: RocketChat/Rocket.Chat PR: 37152
File: packages/apps-engine/tests/test-data/utilities.ts:557-573
Timestamp: 2025-10-06T20:32:23.658Z
Learning: In packages/apps-engine/tests/test-data/utilities.ts, the field name `isSubscripbedViaBundle` in the `IMarketplaceSubscriptionInfo` type should not be flagged as a typo, as it may match the upstream API's field name.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/misc.ts`
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2025-10-16T21:09:51.816Z</summary>

```
Learnt from: cardoso
Repo: RocketChat/Rocket.Chat PR: 36942
File: apps/meteor/client/lib/e2ee/keychain.ts:148-156
Timestamp: 2025-10-16T21:09:51.816Z
Learning: In the RocketChat/Rocket.Chat repository, only platforms with native crypto.randomUUID() support are targeted, so fallback implementations for crypto.randomUUID() are not required in E2EE or cryptographic code.
```

**Applied to files:**
- `apps/meteor/app/api/server/v1/misc.ts`

</details>
<details>
<summary>📚 Learning: 2026-02-24T19:09:09.561Z</summary>

```
Learnt from: ahmed-n-abdeltwab
Repo: RocketChat/Rocket.Chat PR: 38974
File: apps/meteor/app/api/server/v1/im.ts:220-221
Timestamp: 2026-02-24T19:09:09.561Z
Learning: In RocketChat/Rocket.Chat OpenAPI migration PRs for apps/meteor/app/api/server/v1 endpoints, maintainers prefer to avoid any logic changes; style-only cleanups (like removing inline comments) may be deferred to follow-ups to keep scope tight.
```

**Applied to files:**
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-02-23T17:53:18.785Z</summary>

```
Learnt from: ggazzo
Repo: RocketChat/Rocket.Chat PR: 35995
File: apps/meteor/app/api/server/v1/rooms.ts:1107-1112
Timestamp: 2026-02-23T17:53:18.785Z
Learning: In Rocket.Chat PR reviews, maintain strict scope boundaries—when a PR is focused on a specific endpoint (e.g., rooms.favorite), avoid reviewing or suggesting changes to other endpoints that were incidentally refactored (e.g., rooms.invite) unless explicitly requested by maintainers.
```

**Applied to files:**
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2025-12-10T21:00:54.909Z</summary>

```
Learnt from: KevLehman
Repo: RocketChat/Rocket.Chat PR: 37091
File: ee/packages/abac/jest.config.ts:4-7
Timestamp: 2025-12-10T21:00:54.909Z
Learning: Rocket.Chat monorepo: Jest testMatch pattern '<rootDir>/src/**/*.spec.(ts|js|mjs)' is valid in this repo and used across multiple packages (e.g., packages/tools, ee/packages/omnichannel-services). Do not flag it as invalid in future reviews.
```

**Applied to files:**
- `docs/api-endpoint-migration.md`

</details>
<details>
<summary>📚 Learning: 2026-03-04T14:16:49.202Z</summary>

```
Learnt from: tassoevan
Repo: RocketChat/Rocket.Chat PR: 39304
File: packages/ui-contexts/src/ActionManagerContext.ts:26-26
Timestamp: 2026-03-04T14:16:49.202Z
Learning: In `packages/ui-contexts/src/ActionManagerContext.ts` (TypeScript, RocketChat/Rocket.Chat), the `disposeView` method in `IActionManager` uses an intentionally explicit union `UiKit.ModalView['id'] | UiKit.BannerView['viewId'] | UiKit.ContextualBarView['id']` to document which view types are accepted, even though all constituents resolve to the same primitive. The inline `// eslint-disable-next-line typescript-eslint/no-duplicate-type-constituents` comment is intentional and should not be flagged or removed.
```

**Applied to files:**
- `docs/api-endpoint-migration.md`

</details>

</details><details>
<summary>🪛 markdownlint-cli2 (0.21.0)</summary>

<details>
<summary>docs/api-endpoint-migration.md</summary>

[warning] 424-424: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

</details>

</details>

</details>

<details>
<summary>🔇 Additional comments (6)</summary><blockquote>

<details>
<summary>packages/core-typings/src/Ajv.ts (1)</summary><blockquote>

`3-52`: **LGTM!**

The expansion of the `typia.json.schemas` union to include additional types (IBanner, ICalendarEvent, IEmailInbox, IImport, IRole, IRoom, IDirectoryChannelResult, IUser, IDirectoryUserResult, VideoConference, VideoConferenceInstructions, VideoConferenceCapabilities, Cloud-related types, and moderation types) correctly follows the existing pattern. The parenthesized union structure ensures typia generates individual JSON schemas for each constituent type, which will be properly consumed by the ajv registration and OpenAPI spec generation.

</blockquote></details>
<details>
<summary>docs/api-endpoint-migration.md (5)</summary><blockquote>

`1-127`: **Clear introduction and well-structured examples.**

The "Why" section effectively motivates the migration, and the before/after examples provide excellent context for understanding the pattern change.

---

`128-231`: **Comprehensive step-by-step migration guide.**

The progression from identifying HTTP methods through creating response schemas is logical and well-documented with clear examples.

---

`536-559`: **Clear guidance on handling multiple HTTP methods.**

The example effectively shows how to split combined route registrations into separate, explicit method calls with their own validation schemas.

---

`560-598`: **Valuable test migration guidance.**

The documentation of `errorType` changes and error message format differences will be essential for updating tests during endpoint migrations.

---

`599-627`: **Helpful reference section for migration work.**

The tracking script and reference file table provide practical resources for developers performing migrations.

</blockquote></details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->