[vas3a]

This pull request updates how reply-to addresses are handled for the "Let's Talk" sales reply flow. Instead of only the first address being used as reply-to and the rest being copied (cc), now every address in LETS_TALK_SALES_REPLY_TO is used as a reply-to. This ensures that when a prospect replies, their message goes to all configured addresses, and no one is copied separately. The change is reflected in documentation, configuration, implementation, and tests.

Sales Reply "Reply-To" Handling:

• All addresses in LETS_TALK_SALES_REPLY_TO are now used as reply-to addresses, so replies from prospects go to all of them; none are copied as cc. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

Implementation & Validation:

• The replyTo field now accepts a single email or an array of emails, and deduplicates them; if more than one, the array is passed as SendGrid's reply_to_list. [1] [2]
• Tests were updated and expanded to validate the new behavior, including deduplication and proper error handling for invalid addresses. [1] [2] [3] [4] [5]

Documentation:

• Documentation and ADRs were updated to explain the new reply-to behavior, including rationale and migration notes. [1] [2] [3] [4] [5]

These changes ensure that sales replies are handled consistently and as intended, with all configured addresses receiving replies directly.

https://topcoder.atlassian.net/browse/PM-6687

[Copilot]

🔵 Needs a closer look

The change depends on strict cross-service release ordering—requiring the updated email-service-v6 to be deployed first to avoid malformed list messages—which demands human deployment coordination that cannot be verified here.

No open issues 🎉

What changed in this PR

This PR changes the "Let's Talk" sales-reply flow so that every address in LETS_TALK_SALES_REPLY_TO is set as a reply-to (sent as SendGrid's reply_to_list when there are 2+ addresses), instead of the previous behavior where only the first address was the reply-to and the rest were copied (cc). This affects the email action contract, the sales flow settings, and the supporting documentation/ADR. It fits into the broader Let's Talk AI-classification-and-reply pipeline described in ADR 0001.

Changes:

• emailSettingsSchema.replyTo now accepts a single email or a 1–100 element array; the action lowercases and deduplicates, emitting a single string for one address and an array for several.
• The sales-reply flow passes the whole LETS_TALK_SALES_REPLY_TO list as replyTo and no longer sets cc.
• Documentation, ADR (new "Decision 7 revised" note), config comments, and tests were updated to match.

File	Description
src/​actions.ts	replyTo schema becomes a string/array union; computes a deduped, lowercased list and collapses a single entry to a string.
src/​lets-talk-flows.ts	Sales reply now sets replyTo to the full address list and drops the cc copies.
src/​config.ts	Updated doc comment on LETS_TALK_SALES_REPLY_TO.
test/​actions.test.ts	Adds tests for deduped list, single-address collapse, and invalid/empty array rejection.
test/​lets-talk.test.ts	Updates flow-settings expectations to the reply-to array (no cc).
README.md	Flow table updated to describe all addresses as reply-to.
docs/​emails/​README.md	SALES_LEAD note reflects every address as reply-to.
docs/​adr/​0001-...md	Records the revised Decision 7 and the email-service-v6 list capability.
.env.example	Comment updated for the new reply-to semantics.

I reviewed the implementation logic, validation, downstream payload construction, tests, and documentation. The change is internally consistent and well covered by tests, and I found no concrete code defects to flag. One operational consideration (the cross-service release ordering with email-service-v6) is documented in the ADR and has been noted for human attention.

_{Review effort: Balanced}