This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/message-handler.ts
Line: 215-229

Comment:
**Duplicated `StoredConversationReference` construction**

`pairingRef` is a near-verbatim copy of `conversationRef` built later at lines 344–359, with the only structural difference being the absence of `teamId`. For DMs (the only path that can reach `access.decision === "pairing"`), `teamId` is always `undefined`, so the two objects are functionally equivalent — but the duplication creates a maintenance hazard: if new fields are ever added to `StoredConversationReference`, this second construction site is easy to miss.

Consider extracting a shared helper, e.g.:

```ts
function buildConversationRef(
  activity: ...,
  from: ...,
  conversationId: string,
  conversationType: string,
  teamId?: string,
): StoredConversationReference {
  const agent = activity.recipient;
  return {
    activityId: activity.id,
    user: { id: from.id, name: from.name, aadObjectId: from.aadObjectId },
    agent,
    bot: agent ? { id: agent.id, name: agent.name } : undefined,
    conversation: {
      id: conversationId,
      conversationType,
      tenantId: activity.conversation?.tenantId,
    },
    teamId,
    channelId: activity.channelId,
    serviceUrl: activity.serviceUrl,
    locale: activity.locale,
  };
}
```

Both the pairing block and the happy-path block could then call this helper, eliminating the drift risk.

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

---

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/message-handler.authz.test.ts
Line: 156-212

Comment:
**Test manually re-creates `deps` instead of using shared `createDeps` helper**

The new test duplicates ~50 lines of boilerplate that `createDeps` already encapsulates (runtime mock, `conversationStore`, `pollStore`, `log`, etc.). The only real differences from `createDeps` are:

1. A custom `upsertPairingRequest` spy (instead of `vi.fn(async () => null)`).
2. `readAllowFromStore` returning `[]` instead of `["attacker-aad"]`.

Both could be covered by extending `createDeps` with optional overrides:

```ts
const { conversationStore, deps } = createDeps(
  {
    channels: { msteams: { dmPolicy: "pairing", allowFrom: [] } },
  } as OpenClawConfig,
  { upsertPairingRequestReturnValue: { id: "user-aad", channel: "msteams" }, storeAllowFrom: [] }
);
```

This keeps the test file DRY and makes the intent of each test clearer.

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