Keep unprefixed usernames for Discord target resolution

This normalization rewrites any parsed non-empty target to kind:id, so inputs like jane become channel:jane before send. In src/discord/send.shared.ts (parseAndResolveRecipient), username-to-userID directory lookup is only attempted for raw likely-username inputs, so adding channel: here bypasses that path and regresses DM-by-username behavior into a channel-id send/failure path.

Useful? React with 👍 / 👎.

The resolveTarget hook runs at delivery-time resolution, before sendText/sendMedia. The downstream parseAndResolveRecipient in send.shared.ts uses resolveDiscordTarget (the async version) which does directory username lookup via isLikelyUsername. So a username like jane that hits our resolveTarget as channel:jane will still get properly resolved to a user ID in the send path.

That said, the re-prefixing here is intentional: resolveTarget validates early so callers get a clear error at resolution time rather than a cryptic failure at send time. The send path does its own resolution regardless.

Avoid session fallback on non-ambiguous target parse errors

The catch block treats every parseDiscordTarget failure as an ambiguous numeric ID and falls back to the last session target; however parseDiscordTarget also throws for invalid @... user syntax (for example @bob). In that case, if a prior Discord session target exists, an explicitly malformed recipient can be silently redirected to stale context instead of failing, which can misdeliver messages to the wrong recipient.

Useful? React with 👍 / 👎.

Good catch — fixed in d236f7e. The catch block now checks isAmbiguousNumeric = /^\d+$/.test(trimmed) and only falls back to session context for bare numeric IDs. Other parse errors (like @bob failing the ensureTargetId digit check) now propagate the original error directly instead of silently falling back.

Explicit target silently replaced by session fallback

When a caller explicitly provides a bare numeric ID (e.g. to: "123456"), parseDiscordTarget throws the ambiguity error as expected. The catch block then silently discards that explicit target and substitutes the main session's last delivery context instead — potentially delivering the message to a completely different user or channel than the one the caller intended.

The caller receives { ok: true, to: "<session-fallback-value>" } with no indication that their input was ignored. This is particularly dangerous because the ambiguity error message is already correct ("Use user:123456 for DMs or channel:123456 for channel messages") — the session fallback overrides what should be an actionable error.

The PR description states the session fallback is intended for implicit/heartbeat flows (no explicit to). For cases where an explicit to was provided but is ambiguous, the error should be surfaced rather than silently swapped out:

    } catch {
      // Bare numeric ID — ambiguous. Only try the session fallback when no
      // explicit target was provided (implicit/heartbeat flows).
      if (mode === "implicit" || mode === "heartbeat") {
        const fallback = resolveDiscordTargetFromSession(cfg);
        if (fallback) {
          return { ok: true, to: fallback };
        }
      }
      return {
        ok: false,
        error: new Error(
          `Ambiguous Discord recipient "${trimmed}". Use "user:${trimmed}" for DMs or "channel:${trimmed}" for channel messages.`,
        ),
      };
    }

This is a comment left during a code review.
Path: src/channels/plugins/outbound/discord.ts
Line: 139-150

Comment:
**Explicit target silently replaced by session fallback**

When a caller explicitly provides a bare numeric ID (e.g. `to: "123456"`), `parseDiscordTarget` throws the ambiguity error as expected. The `catch` block then silently discards that explicit target and substitutes the main session's last delivery context instead — potentially delivering the message to a completely different user or channel than the one the caller intended.

The caller receives `{ ok: true, to: "<session-fallback-value>" }` with no indication that their input was ignored. This is particularly dangerous because the ambiguity error message is _already correct_ ("Use `user:123456` for DMs or `channel:123456` for channel messages") — the session fallback overrides what should be an actionable error.

The PR description states the session fallback is intended for *implicit/heartbeat* flows (no explicit `to`). For cases where an explicit `to` _was_ provided but is ambiguous, the error should be surfaced rather than silently swapped out:

```typescript
    } catch {
      // Bare numeric ID — ambiguous. Only try the session fallback when no
      // explicit target was provided (implicit/heartbeat flows).
      if (mode === "implicit" || mode === "heartbeat") {
        const fallback = resolveDiscordTargetFromSession(cfg);
        if (fallback) {
          return { ok: true, to: fallback };
        }
      }
      return {
        ok: false,
        error: new Error(
          `Ambiguous Discord recipient "${trimmed}". Use "user:${trimmed}" for DMs or "channel:${trimmed}" for channel messages.`,
        ),
      };
    }
```

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

Fixed in d236f7e — same root cause as the Codex comment above. The catch block now narrows to bare numeric IDs only (/^\d+$/), so @bob or other explicit-but-invalid targets surface the original parse error instead of silently substituting the session fallback.

Unreachable fallthrough returns unvalidated target

This return statement is dead code. For any non-empty trimmed string, parseDiscordTarget either returns a truthy MessagingTarget (handled by the if (parsed) branch, which always returns) or throws an Error (handled by the catch block). There is no code path in which parseDiscordTarget returns a falsy value for a non-empty input.

The danger is that if parseDiscordTarget's contract ever changes to return undefined for some inputs, this line would silently return the original, un-validated trimmed string — bypassing the validation this PR is designed to enforce. The intent can be made explicit:

This is a comment left during a code review.
Path: src/channels/plugins/outbound/discord.ts
Line: 152

Comment:
**Unreachable fallthrough returns unvalidated target**

This `return` statement is dead code. For any non-empty `trimmed` string, `parseDiscordTarget` either returns a truthy `MessagingTarget` (handled by the `if (parsed)` branch, which always returns) or throws an `Error` (handled by the `catch` block). There is no code path in which `parseDiscordTarget` returns a falsy value for a non-empty input.

The danger is that if `parseDiscordTarget`'s contract ever changes to return `undefined` for some inputs, this line would silently return the original, un-validated `trimmed` string — bypassing the validation this PR is designed to enforce. The intent can be made explicit:

```suggestion
    return { ok: false, error: new Error(`Unexpected: parseDiscordTarget returned undefined for "${trimmed}"`) };
```

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

Correct — this was dead code. Fixed in d236f7e: moved the fallthrough return inside the try block with a clarifying comment that parseDiscordTarget only returns undefined for empty input (already handled above).

Restrict ambiguous-ID fallback to implicit modes

This fallback runs even when mode is explicit, so a user-supplied bare numeric recipient can be silently replaced with the last Discord session target instead of failing fast. In the direct send path, resolveOutboundTarget defaults to explicit mode, so inputs like --to 123456 can be redirected to stale deliveryContext.to whenever session context exists, causing misdelivery rather than prompting for user:/channel: disambiguation.

Useful? React with 👍 / 👎.

Good catch — fixed in 3244983. Session fallback for ambiguous bare numeric IDs is now gated on mode === "implicit" || mode === "heartbeat". Explicit sends (--to 123456) fail fast with the disambiguation error instead of silently falling back to stale deliveryContext.to.

Resolve fallback session key from configured main scope

The session fallback is hardcoded to agentId: "main" for both key and store-path resolution, which misses valid session state when the installation uses session.scope: "global" or a non-main default agent. In those supported configurations, the canonical main key is derived from config (not always agent:main:main), so this new fallback path quietly fails and implicit/heartbeat Discord target recovery does not work.

Useful? React with 👍 / 👎.

Good catch — fixed in 752ca52. Now uses resolveMainSessionKey(cfg) which respects session.scope: "global" and picks the configured default agent instead of hardcoding "main". Also dropped the unnecessary { agentId: "main" } from resolveStorePath.

Keep unprefixed Discord usernames for directory resolution

Reformatting every parsed target to kind:id turns plain usernames like jane into channel:jane before delivery, which bypasses Discord username-to-user lookup and regresses DM-by-username sends. Fresh evidence: parseAndResolveRecipient relies on resolveDiscordTarget to do directory lookup for likely usernames, but channel:* is treated as an explicit channel target and skips that lookup path, so previously valid unprefixed usernames now fail or route incorrectly.

Useful? React with 👍 / 👎.

Derive fallback session store path from main-session agent

This fallback reads from resolveStorePath(cfg.session?.store) without an agent id, which resolves to the main agent store even when the configured main session key belongs to another agent (for example agent:ops:main) or when the store path is agent-templated. Fresh evidence: Discord session writes use agent-scoped store paths in processDiscordMessage (resolveStorePath(..., { agentId: route.agentId })), so this read can hit a different file and silently miss the delivery context, breaking implicit/heartbeat fallback in supported multi-agent setups.

Useful? React with 👍 / 👎.

Wire new Discord target resolver into adapter flow

resolveDiscordTargetFromSession is introduced here, but nothing in this adapter calls it and resolveTarget still delegates to normalizeDiscordOutboundTarget, so the new session-based fallback/validation path never executes. In practice, implicit/heartbeat sends and bare numeric IDs continue using the old normalization behavior, meaning this commit does not actually apply the new Discord target resolution logic it adds.

Useful? React with 👍 / 👎.