This is a comment left during a code review.
Path: src/auto-reply/reply/inbound-meta.ts
Line: 127-160

Comment:
**Duplicated `hashSenderId` logic in `conversationInfo`**

The `senderId` variable (lines 173-174) centralises the hash-or-passthrough logic for `SenderId`, but it is declared *after* `conversationInfo` is built, so the same logic is duplicated inline twice:

1. `conversationInfo.sender_id` (lines 131-133) – inline hash
2. `conversationInfo.sender` (lines 139-141) – inline hash again

If the hashing strategy changes (e.g. a different prefix or algo), only line 174 would typically be updated, leaving the two inline copies stale and causing `conversationInfo.sender_id` / `conversationInfo.sender` to diverge from `senderInfo.id`.

Moving the two pre-computed variables (`senderE164`, `rawSenderId`, `senderId`) above the `conversationInfo` object would eliminate this duplication:

```ts
const senderE164 = options?.redactPII ? undefined : safeTrim(ctx.SenderE164);
const rawSenderId = safeTrim(ctx.SenderId);
const senderId = options?.redactPII && rawSenderId ? hashSenderId(rawSenderId) : rawSenderId;

const conversationInfo = {
  ...
  sender_id: shouldIncludeConversationInfo ? senderId : undefined,
  ...
  sender: shouldIncludeConversationInfo
    ? (safeTrim(ctx.SenderName) ??
       (options?.redactPII ? undefined : senderE164) ??
       senderId ??
       safeTrim(ctx.SenderUsername))
    : undefined,
```

This also removes the repeated `safeTrim(ctx.SenderId)` calls in the condition vs body throughout `conversationInfo`.

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: 500-505

Comment:
**Raw PII still stored in `followupRun` when `redactPII` is enabled**

The redaction only covers the strings injected into the LLM prompt. However, `followupRun.run` still carries the verbatim `senderId` and `senderE164` from `sessionCtx`:

```ts
senderId: sessionCtx.SenderId?.trim() || undefined,   // raw
senderE164: sessionCtx.SenderE164?.trim() || undefined, // raw phone number
```

If `runReplyAgent` enqueues or persists this object (e.g. to a queue file for deferred/steer runs), the original phone number and user ID will be written to disk even when the operator has opted in to PII redaction.

If the `followupRun` is never persisted — i.e. it is purely in-memory and only used for same-process routing — this is fine and the current scope ("redact from LLM context") is correctly maintained. But if it *is* serialised, these fields should either be omitted or replaced with their pseudonymised equivalents when `redactPIIOpts` is active. It would be worth a brief code comment here clarifying that the raw values are intentional for routing/auth and are never written to durable storage.

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/inbound-meta.ts
Line: 7-8

Comment:
**Unsalted hash makes phone-number pseudonyms reversible**

```ts
return createHash("sha256").update(value).digest("hex").slice(0, 12);
```

For `SenderE164` (phone numbers), the input space is small and well-structured (~15 decimal digits, ITU-T E.164). An attacker who obtains the hashed prompt logs can reverse every pseudonymised phone number by pre-computing hashes for all valid numbers — a lookup table of the entire global number space is feasible in seconds on modern hardware. The truncation to 12 hex chars makes collisions more likely but does not protect against this reversal.

The PR description explicitly calls this out as an intentional design trade-off ("Deterministic hash (no salt): same user always maps to same pseudonym, consistent across sessions"), which is reasonable for cross-session correlation. Just worth making sure operators are aware that `redactPII: true` provides pseudonymisation (unlinkability to an outside observer without the original data) rather than true anonymisation (irreversibility).

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