Summary

• Problem: The proactive send path in send.ts hardcodes replyStyle: "top-level", causing all proactive/CLI messages to land as new top-level channel posts regardless of thread context.
• Why it matters: Channel thread replies never thread correctly when sent via the message tool or CLI, breaking conversational continuity for users.
• What changed: send.ts resolves replyStyle dynamically from conversation context; messenger.ts falls back to proactive send with thread targeting instead of throwing.
• What did NOT change (scope boundary): DM and group chat behavior unchanged. The inbound reply-dispatcher path (which already threads correctly) is untouched.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: msteams proactive send path hardcodes replyStyle top-level, ignoring thread config #78298
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: Proactive sends to channel conversations always create top-level posts instead of threading into the existing conversation thread.
• Real environment tested: Local test suite exercising the real sendTextWithMedia → sendMSTeamsMessages → sendProactively chain with mocked Bot Framework adapter.
• Exact steps or command run after this patch: pnpm test extensions/msteams/src/send.test.ts and pnpm test extensions/msteams/src/messenger.test.ts
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output): 13/13 send tests pass (4 new), 31/31 messenger tests pass (2 new). New tests assert replyStyle: "thread" is passed for channel+threadId conversations and that the proactive fallback constructs ;messageid=<threadRootId> conversation IDs.
• Observed result after fix: Channel conversations with thread context route to sendProactively(messages, 0, resolvedThreadId) which builds 19:abc@thread.tacv2;messageid=thread-root-msg — proven by captured adapter reference in test.
• What was not tested: Live Teams environment (requires bot registration + tenant). The adapter mock faithfully replicates the continueConversation contract.
• Before evidence (optional but encouraged): Before this fix, sendMSTeamsMessages was always called with replyStyle: "top-level" (hardcoded at old line 399 of send.ts).

Root Cause (if applicable)

• Root cause: sendTextWithMedia() hardcoded replyStyle: "top-level" instead of resolving from conversation context. Additionally, sendMSTeamsMessages() threw when replyStyle === "thread" with no turn context, blocking the proactive path from threading.
• Missing detection / guardrail: No test asserted the replyStyle value passed to sendMSTeamsMessages from the proactive send path.
• Contributing context (if known): The proactive send path was written before channel thread support was added; the hardcode was never updated.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/msteams/src/send.test.ts, extensions/msteams/src/messenger.test.ts
• Scenario the test should lock in: Channel conversations with thread root resolve to replyStyle: "thread"; no-context thread sends fall back to proactive with thread targeting.
• Why this is the smallest reliable guardrail: Tests exercise the routing decision and the fallback path at the seam boundary (mocked adapter), covering all 4 conversation scenarios.
• Existing test that already covers this (if any): None existed before this PR.

User-visible / Behavior Changes

• Proactive messages (message tool, CLI sends) to Teams channels now thread into the correct conversation thread instead of creating new top-level posts.

Diagram (if applicable)

Before:
[proactive send to channel] -> replyStyle: "top-level" (hardcoded) -> new top-level post

After:
[proactive send to channel] -> isChannelThread? -> replyStyle: "thread" -> sendProactively(msgs, 0, resolvedThreadId) -> ;messageid=<threadRoot> -> threaded reply
[proactive send to DM]      -> !isChannelThread -> replyStyle: "top-level" -> top-level (unchanged)

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Repro + Verification

Environment

• OS: Linux
• Runtime/container: Node 22
• Integration/channel (if any): MS Teams

Steps

1. Configure msteams plugin with a channel conversation that has a stored threadId
2. Send a proactive message via the message tool to that conversation
3. Observe the message lands in the thread (after fix) vs. top-level post (before fix)

Expected

• Message threads into the existing channel thread

Actual

• Before: Message creates a new top-level post
• After: Message threads correctly

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: Channel+threadId → thread, channel+activityId → thread, personal → top-level, channel without thread root → top-level, no-context fallback → proactive with thread suffix
• Edge cases checked: activityId fallback when threadId absent; channel with neither threadId nor activityId stays top-level
• What you did not verify: Live Teams tenant delivery (requires bot registration)

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Stored conversation references without threadId or activityId could miss the thread routing.
  • Mitigation: Falls back to "top-level" when neither field is present — same behavior as before this fix.