Missing runtime type validation for line numbers

parseMcporterResults (lower in this same file) carefully validates that start_line/end_line are actually numbers (typeof x === "number") before storing them. The search loop here skips that validation and accepts any non-undefined value directly from the QmdQueryResult entry.

parseQmdQueryResultArray does an unchecked as QmdQueryResult[] cast from JSON, so at runtime entry.start_line could be a string like "10" or even 0 / a negative number — all of which would pass the !== undefined guard and silently produce incorrect line numbers. Consider mirroring the same guards used in parseMcporterResults:

This is a comment left during a code review.
Path: src/memory/qmd-manager.ts
Line: 852-855

Comment:
**Missing runtime type validation for line numbers**

`parseMcporterResults` (lower in this same file) carefully validates that `start_line`/`end_line` are actually numbers (`typeof x === "number"`) before storing them. The search loop here skips that validation and accepts any non-`undefined` value directly from the `QmdQueryResult` entry.

`parseQmdQueryResultArray` does an unchecked `as QmdQueryResult[]` cast from JSON, so at runtime `entry.start_line` could be a string like `"10"` or even `0` / a negative number — all of which would pass the `!== undefined` guard and silently produce incorrect line numbers. Consider mirroring the same guards used in `parseMcporterResults`:

```suggestion
      if (
        typeof entry.start_line === "number" &&
        entry.start_line > 0 &&
        typeof entry.end_line === "number" &&
        entry.end_line > 0
      ) {
        startLine = entry.start_line;
        endLine = entry.end_line;
      } else {
```

How can I resolve this? If you propose a fix, please make it concise.

Concurrent close() calls with different finalText silently drops the second value

When a second concurrent caller passes a different finalText, the guard returns the in-flight promise created with the first caller's finalText. The second finalText is silently ignored. If this is intentional (e.g. only the first closer's text matters), it's worth documenting so future readers don't assume both values are merged.

This is a comment left during a code review.
Path: extensions/feishu/src/streaming-card.ts
Line: 332-337

Comment:
**Concurrent `close()` calls with different `finalText` silently drops the second value**

When a second concurrent caller passes a different `finalText`, the guard returns the in-flight promise created with the *first* caller's `finalText`. The second `finalText` is silently ignored. If this is intentional (e.g. only the first closer's text matters), it's worth documenting so future readers don't assume both values are merged.

```suggestion
    if (this.closePromise) {
      // NOTE: If concurrent callers pass different finalText values, only
      // the first caller's finalText is used. Subsequent callers share
      // the same close operation.
      return this.closePromise;
    }
```

How can I resolve this? If you propose a fix, please make it concise.

Avoid inheriting symlink mode on atomic writes

If the destination entry is a symlink, os.lstat(..., dir_fd=...) returns the symlink mode (commonly 0777), and that value is then copied to the temp file via os.fchmod before os.replace swaps in a regular file. In that case, writing through a symlink path can unexpectedly produce a world-writable/executable file, which is a permission regression from the previous default 0600 behavior. Mode inheritance should be limited to regular files (or explicitly skip symlink modes).

Useful? React with 👍 / 👎.

Check in-flight close promise before closed guard

close() sets this.closed = true before assigning this.closePromise, but subsequent calls check this.closed first and return immediately. In the common concurrent-close scenario (two callers invoking close() around the same time), the second caller gets undefined instead of the in-flight promise, so it can continue before the final card update/note/settings PATCH completes. Move the closePromise check ahead of the closed early return so repeated calls can reliably await shutdown.

Useful? React with 👍 / 👎.