Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="scripts/analyze-weak-types.mjs">

<violation number="1" location="scripts/analyze-weak-types.mjs:46">
P2: `SCHEMA_WEAK_PATTERNS` is declared but never used, so array schemas without `items` are never detected.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/subscriptions.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/subscriptions.ts:26">
P2: `subscriptions.get` response schema incorrectly validates `remove` items as `ISubscription`, but runtime returns only deletion markers (`_id`, `_deletedAt`).</violation>
</file>

<file name="apps/meteor/app/api/server/v1/custom-user-status.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/custom-user-status.ts:164">
P1: Omitting `statusType` on update now clears it to `''` instead of leaving it unchanged.</violation>
</file>

<file name="apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts">

<violation number="1" location="apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts:179">
P1: Truthy-gating these fields prevents clearing `avatar`, `emoji`, or `alias` to empty strings; use presence checks instead of value truthiness.</violation>
</file>

<file name="scripts/list-weak-response-schemas.mjs">

<violation number="1" location="scripts/list-weak-response-schemas.mjs:16">
P2: Using `URL.pathname` directly can break file scanning on encoded filesystem paths.</violation>

<violation number="2" location="scripts/list-weak-response-schemas.mjs:93">
P2: `bare-object` matching is too broad and flags valid multiline object schemas as weak.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/misc.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/misc.ts:348">
P2: `statusText` is optional on users, so requiring it in the spotlight response schema can reject valid responses.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/channels.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/channels.ts:643">
P1: Using `new Date(0)` counts all historical messages since 1970 as unread for new subscriptions. Fall back to `subscription.ts` to count only messages since the user joined.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/moderation.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/moderation.ts:159">
P2: `createdAt` is validated as `string`, but this endpoint returns `IUser.createdAt` as a `Date`, causing response-schema validation to fail.</violation>
</file>

<file name="apps/meteor/client/lib/userData.ts">

<violation number="1" location="apps/meteor/client/lib/userData.ts:130">
P2: Do not default `email2fa.changedAt` to `new Date()` when the API omits it; this writes a fabricated "changed now" timestamp into user state.

(Based on your team's feedback about avoiding unsafe type assumptions and validating values before coercion.) [FEEDBACK_USED]</violation>
</file>

<file name="apps/meteor/app/api/server/v1/invites.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/invites.ts:63">
P2: `sendInvitationEmail` response schema was loosened with `additionalProperties: true`; this weakens response validation and can hide accidental extra fields.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/mailer.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/mailer.ts:33">
P2: Add a 403 response schema for the permission check on `mailer` so forbidden responses are documented and validated.</violation>
</file>

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

Inline comments:
In `@apps/meteor/app/api/server/v1/emoji-custom.ts`:
- Around line 27-38: The response schema emojiCustomAllResponseSchema currently
sets emojis: { type: 'array' } which doesn't validate array items; update the
schema passed to ajv.compile so the emojis property includes an items schema
(either items: { $ref: '<IEmojiCustom ref>' } if IEmojiCustom is registered with
AJV, or a concrete object schema matching IEmojiCustom) and keep
required/additionalProperties rules; ensure the updated shape still includes
success/count/offset/total and passes AJV compilation in the
emojiCustomAllResponseSchema declaration.

In `@apps/meteor/app/api/server/v1/integrations.ts`:
- Around line 36-38: The Typia schema generation currently only registers
IIntegration, but integrations.ts references IIncomingIntegration and
IOutgoingIntegration; open packages/core-typings/src/Ajv.ts and update the
typia.json.schemas(...) tuple to explicitly import and include
IIncomingIntegration and IOutgoingIntegration (following the pattern used for
IDirectoryChannelResult and IDirectoryUserResult) so those concrete refs are
emitted, or alternatively change the refs in integrations.ts to point to the
existing IIntegration schema name; ensure imports and the typia.json.schemas
call include the two constituent types (IIncomingIntegration,
IOutgoingIntegration) alongside IIntegration.

In `@apps/meteor/app/api/server/v1/push.ts`:
- Around line 235-306: The new GET routes 'push.get' and 'push.info' were added
but not included in the extracted route type, so update the module augmentation
that defines PushEndpoints to include these two routes with their expected
request/response shapes; locate the augmentation that declares PushEndpoints
(the same place that currently exposes 'push.token' and 'push.test') and add
entries for 'push.get' and 'push.info' matching the handlers (use the
pushGetResponseSchema shape for 'push.get' and pushInfoResponseSchema shape for
'push.info', and mark both as authRequired GET endpoints) so typed consumers see
the new routes.

In `@apps/meteor/app/api/server/v1/stats.ts`:
- Around line 98-117: The route API.v1.post handler for 'statistics.telemetry'
accepts an unvalidated body (this.bodyParams) and blindly casts/uses it in
function action; add a proper request body schema to the route options (e.g.,
statisticsTelemetryRequestSchema) that requires a params array of objects with
an eventName string and optional params object, enforce it in the route
definition alongside the existing response schemas, and update action to rely on
the validated shape (or defensively check each event contains eventName before
calling telemetryEvent) so telemetryEvent.call is never invoked with undefined
eventName.

In `@apps/meteor/app/api/server/v1/subscriptions.ts`:
- Around line 19-31: subscriptionsGetResponseSchema currently declares remove
items as full ISubscription docs but the TypeScript type expects tombstones
(Pick<ISubscription, '_id'> & {_deletedAt: Date}); update the schema for the
remove array inside subscriptionsGetResponseSchema so its items are an object
with only the tombstone shape (e.g. properties: { _id: { type: 'string' },
_deletedAt: { type: 'string', format: 'date-time' } } and required:
['_id','_deletedAt']) instead of referencing
'#/components/schemas/ISubscription', so Ajv validation matches the TypeScript
type.

In `@apps/meteor/app/authentication/server/startup/index.js`:
- Around line 214-218: Remove the raw console.log dumps that print full signup
payloads (the two console.log calls around beforeCreateUserCallback.run) and
replace them with either no logging or a redacted logger that only records safe
identifiers (e.g., user._id, user.emailHash or user.username, and a note that
callbacks ran) so sensitive fields (password hashes, OAuth tokens, emails in
plain text, approval state) are never written; update the code referencing
beforeCreateUserCallback, options, and user to use the redaction helper or
remove the logs, and apply the same change to the other occurrences mentioned
(the similar console.log uses at the other indicated locations).

In
`@apps/meteor/app/integrations/server/methods/incoming/updateIncomingIntegration.ts`:
- Around line 179-181: The current spread checks like ...(integration.avatar &&
{ avatar: integration.avatar }) use truthiness and prevent explicit clears
(e.g., avatar: ''), so change those guards to test for undefined/property
presence instead (e.g., use Object.prototype.hasOwnProperty.call(integration,
'avatar') or integration.avatar !== undefined) for avatar, emoji, alias and
script in the update logic (the spread object construction where
integration.avatar/emoji/alias/script are conditionally added); this preserves
omitted fields as no-ops but allows explicit empty-string clears to overwrite
stored values.

In `@scripts/analyze-weak-types.mjs`:
- Around line 45-58: The scan never runs the array pattern from
SCHEMA_WEAK_PATTERNS because only findWeakSchemaBlocks() is invoked; update the
schema-only scan to also execute the array check by either extending
findWeakSchemaBlocks() to apply all SCHEMA_WEAK_PATTERNS (including the array
rule) or adding and calling a dedicated matcher (e.g.,
findWeakSchemaArrayMatches or applyPatternMatches) that runs the second pattern;
ensure the main flow that handles the --schema-only flag calls the new/updated
function so the "{ type: 'array' } (no items)" case is reported.

In `@scripts/list-weak-response-schemas.mjs`:
- Around line 81-95: The 'bare-object' rule in WEAK_PATTERNS currently only
checks the current line in its test(line, context) and thus flags multi-line
schemas where "properties:" or "$ref"/combiners appear on subsequent lines;
update the test in the 'bare-object' entry to perform a lookahead using the
provided context (e.g., inspect subsequent lines/tokens from context for a small
window like the next 5-10 non-empty lines or until indentation/closing token)
and return false if any of properties, $ref, allOf, oneOf, or anyOf are found in
that lookahead; keep the original current-line checks but rely on this
multi-line scan to avoid false positives for standard multi-line object schemas.
- Around line 41-64: The chained-route regex is too broad and matches unrelated
calls like settings.get; update the third pattern in routePatterns inside
extractEndpoints to only match method calls that are part of router chains (e.g.
API.v1, variables ending with "Router"/"router", or common app/router names) by
changing the regex to require a router-like identifier before the dot (for
example using a non-capturing group like
(?:(?:API\.v1|\w*Router|\w*router|\bapp|\broutes))\.(get|post|put|delete)\(\s*['"`]([^'"`]+)['"`])
and adjust the match indexing logic in extractEndpoints accordingly so name
comes from match[2] and method from match[1].

---

Duplicate comments:
In `@apps/meteor/app/api/server/v1/stats.ts`:
- Around line 14-21: The response schema statisticsResponseSchema currently only
enforces success: true and thus ignores the IStats shape; update the Ajv schema
used in statisticsResponseSchema (or replace it) to fully describe the IStats
structure (all expected properties and types) and set additionalProperties:
false (or explicitly include any allowed extra fields) so compile<IStats>(...)
truly enforces the IStats contract; locate statisticsResponseSchema in stats.ts
and expand the properties object to match IStats (or generate the schema from
the TypeScript type) and then recompile with ajv.compile<IStats>.

---

Nitpick comments:
In `@apps/meteor/app/api/server/v1/custom-user-status.ts`:
- Around line 189-209: Add a request body schema to the
custom-user-status.delete route so AJV validates
this.bodyParams.customUserStatusId instead of relying on a manual runtime check:
define a request schema (e.g., customUserStatusDeleteRequestSchema) that
requires a non-empty customUserStatusId (string) and add it to the route options
under the body key of the API.v1.post call for 'custom-user-status.delete'; keep
the existing runtime call to deleteCustomUserStatus(this.userId,
customUserStatusId) unchanged but remove the manual presence check if you prefer
strict schema validation only.

In `@apps/meteor/client/lib/userData.ts`:
- Around line 126-133: The email2fa object construction is using new Date() as a
fallback for email2fa.changedAt which is inconsistent with other places that use
new Date(0) as a sentinel; update the fallback in the email2fa branch so
changedAt uses new Date(0) when missing (i.e., replace new Date() with new
Date(0)) to match the existing epoch sentinel behavior and ensure uniform
"unknown/never set" semantics across the code that reads changedAt.

In `@apps/meteor/tests/end-to-end/api/rooms.ts`:
- Around line 2381-2382: Remove the inline comment and express the intent by
replacing the comment + await sleep(300) with a clearly named helper call (e.g.,
await waitForNameUpdate()), implement that helper to encapsulate the waiting
strategy (for now it can call sleep(300) or, better, poll the name update
condition) and keep the existing sleep function name (sleep) only as the
underlying primitive; update any references in the test to call
waitForNameUpdate() instead of using an implementation comment before sleep.

In `@scripts/list-unmigrated-api-endpoints.mjs`:
- Around line 30-45: The scan() function currently emits one record per path
which undercounts multi-method handlers; modify scan() to either count verbs per
registration or explicitly label records as "registrations": for each match in
scan() (using the existing regex and extractPaths(match[2])), parse or extract
the handler verbs for that addRoute invocation and include them in the results
entries (e.g., add a verbs: [..] array or a registrations: true flag) so the
output reflects handler multiplicity; also update the downstream aggregation
logic that computes totals (the code that processes results into endpoints/Total
around the later block that iterates over results) to sum verb counts when
producing endpoint totals or to treat the output as registration counts when the
records are labeled, ensuring the final "Total" and endpoints output are
accurate and consistent.

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/meteor/app/api/server/v1/im.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/im.ts:313">
P2: `dm.setTopic` can return `topic: null` even though the declared 200 response schema only allows a string.</violation>
</file>

<file name="apps/meteor/app/api/server/v1/commands.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/commands.ts:125">
P2: When apps are not loaded, this branch now returns HTTP 200 instead of an “incomplete, retry later” status, which can make clients treat a partial command list as complete.</violation>
</file>

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/meteor/app/api/server/v1/rooms.ts">

<violation number="1" location="apps/meteor/app/api/server/v1/rooms.ts:630">
P1: Validate that `startingFromId` belongs to the requested room before including it in the response to prevent cross-room file metadata exposure.</violation>
</file>