Greptile Summary

This PR pursues startup-time and memory improvements by converting several heavy static imports into lazy dynamic imports behind *.runtime.ts shim modules, splitting utility modules (e.g. tts-config, abort-primitives, context-cache) from their heavy runtime dependencies, and inlining a handful of simple one-liner helpers to avoid pulling in large dependency graphs. The measured RSS reductions for dispatch-from-config (~163 MB) and commands-core (~299 MB) are significant.

Key observations:

• shouldSuppressReasoningPayload is correctly inlined as payload.isReasoning === true — the original function was a single-line wrapper with no additional logic.
• resolveTtsConfig(cfg).mode ?? "final" is correctly replaced by resolveConfiguredTtsMode(cfg) — the semantics are identical.
• The local normalizeDiscordChatType in session-key-normalization.ts produces identical output to the SDK's normalizeChatType for all known Discord chat types.
• normalizeCommandBodyLite in commands-context.ts omits the getTextAliasMap() alias-resolution step that the original normalizeCommandBody performed. This silently changes the contract of commandBodyNormalized: slash-command aliases registered via the command registry will no longer be resolved before reaching command handlers. Whether this affects real commands depends on what aliases are currently registered, but it creates a latent maintenance hazard.
• parseActivationCommand in group-activation.ts previously truncated multi-line input to the first line before matching; the inline regex replacement no longer does so, which could silently misparse edge-case multi-line activation config values.
• The PR notes that the full check gate was intentionally bypassed due to unrelated local formatting issues — the two targeted test suites (dispatch-from-config, commands-core) were verified independently.

Confidence Score: 4/5

• Safe to merge with one targeted fix: normalizeCommandBodyLite should either restore alias resolution or explicitly document the intentional behavior change.
• The lazy-loading refactor is well-structured and the core correctness of each substitution (TTS mode, reasoning suppression, Discord chat-type normalisation) has been verified. The main concern is normalizeCommandBodyLite silently dropping alias resolution, which could break command aliases in ways that are hard to test statically. The multi-line activation-command gap is a minor edge case. The targeted test suites pass, and the memory/startup wins are real and well-measured.
• src/auto-reply/reply/commands-context.ts (alias resolution gap in normalizeCommandBodyLite) and src/auto-reply/group-activation.ts (multi-line input handling).

This is a comment left during a code review.
Path: src/auto-reply/reply/commands-context.ts
Line: 781-805

Comment:
**`normalizeCommandBodyLite` silently drops text-alias resolution**

The original `normalizeCommandBody` from `commands-registry` performs a final lookup in `getTextAliasMap()` to canonicalize registered aliases (e.g. resolving `/h` → `/help`, or any plugin-registered alias). `normalizeCommandBodyLite` omits this step entirely.

As a result, `commandBodyNormalized` in `CommandContext` now carries the raw (un-aliased) command body. Every command handler in `handleCommands` that matches against the canonical form will silently miss invocations sent via an alias. Since the alias table is populated at runtime (including plugin commands), this regression is hard to catch in static tests.

If the intent is to keep the alias lookup lazy, the resolution should happen inside `handleCommands` after `loadCommandHandlersRuntime()` has been awaited — or a dedicated `loadCommandNormalizationRuntime()` shim should be called at the start of `buildCommandContext`.

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/group-activation.ts
Line: 299-302

Comment:
**Multi-line activation commands no longer truncated to first line**

`normalizeCommandBody` extracted `singleLine` before colon-normalisation, so a value like `/activation:always\nsome trailing text` was correctly reduced to `/activation always` and then matched. The replacement regex operates on the raw `trimmed` string; because `.` does not match `\n` and `$` anchors to end-of-string (no `m` flag), it won't transform a command whose colon appears on the first line of a multi-line string. The subsequent `/activation` match regex also fails because `$` won't match mid-string.

In practice, activation commands are unlikely to be multi-line, but the behavioural gap is worth noting if any integration passes a multi-line config value here.

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

_{Reviews (1): Last reviewed commit: "perf(inbound): trim dispatch and command..." | Re-trigger Greptile}