This is a comment left during a code review.
Path: src/auto-reply/reply/queue-policy.ts
Line: 15-17

Comment:
**Fast-lane bypass precedes heartbeat drop check**

`forceRunNowWhenActive` is checked before `isHeartbeat`, so a heartbeat message that qualifies as a fast-lane candidate (e.g. if its body happens to match `FAST_LANE_QUICK_MESSAGE_PATTERN`) would return `"run-now"` instead of `"drop"`. In `get-reply-run.ts` there is no `!isHeartbeat` guard on `shouldUseFastLane`, only a `shouldFollowup` guard — but `shouldFollowup` can be `true` in `"collect"` mode even for heartbeats, leaving the heartbeat drop path unreachable for any fast-lane candidate.

The `isHeartbeat` → `"drop"` branch is a safety valve for stale pings; bypassing it via `forceRunNowWhenActive` is unintended.

```suggestion
  if (!params.isActive) {
    return "run-now";
  }
  if (params.isHeartbeat) {
    return "drop";
  }
  if (params.forceRunNowWhenActive) {
    return "run-now";
  }
```

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

---

This is a comment left during a code review.
Path: src/auto-reply/reply/get-reply-run.ts
Line: 607-634

Comment:
**Fast-lane completion can prematurely drain the shared followup queue**

When the fast-lane run completes it calls `finalizeWithFollowup(result, queueKey, runFollowupTurn)` using the same `queueKey` as the still-active main run. `finalizeWithFollowup` → `scheduleFollowupDrain` will start processing any items already enqueued under that key if the queue is not yet in a `draining` state — which it won't be, because the main run hasn't finished yet.

The result is that queued followup messages that were safely held until the main run completed can now be dispatched to the embedded runner while the main run is still live, creating two concurrent sessions on the same key.

A minimal mitigation would be to skip scheduling the drain when the caller knows the main run is still active, e.g. by passing `isRunActive` into `finalizeWithFollowup` for the fast-lane path, or by using a separate queue key for the transient run so its drain does not touch the primary lane.

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

---

This is a comment left during a code review.
Path: src/auto-reply/reply/get-reply-run.ts
Line: 62-63

Comment:
**`"what time is it"` phrase seems out of place in the pattern**

The regex bundles generic conversational affirmations/cancellations (`yes`, `no`, `ok`, `cancel`, `stop`, etc.) with the oddly specific question `what time is it\??`. It appears to be a test phrase that was accidentally left in the production pattern. If intentional, a comment explaining why this one question warrants fast-lane treatment would help; if not, it should be removed.

```suggestion
const FAST_LANE_QUICK_MESSAGE_PATTERN =
  /^(?:yes|no|ok|okay|sure|thanks|thx|got it|cancel|stop|never mind|nevermind)$/i;
```

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

---

This is a comment left during a code review.
Path: src/auto-reply/reply/get-reply-run.ts
Line: 614-619

Comment:
**Transient session transcript files are never cleaned up**

`transientSessionFile` resolves to a `fastlane-<uuid>-topic-<...>.jsonl` file in the sessions directory. There is no TTL, post-run cleanup, or sweep mechanism for these files. In high-traffic Discord channels where many short messages arrive during long turns, these orphaned transcript files will accumulate on disk indefinitely.

Consider deleting the transient transcript after the fast-lane run finishes (in a `finally` block), or marking it with a prefix/suffix that a periodic pruning job can target.

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