Summary

Add support for an optional per-call emoji override in log methods (debug, info, warn, error, log) so callers can specify an exact emoji for a specific log statement without relying on keyword-based auto-detection.

Problem

Currently, the log method signatures are:

debug(message: string, data?: LogData): void;
info(message: string, data?: LogData): void;
// ...etc

The emoji element is determined automatically via EmojiSelector keyword matching against the message text. This creates a duplicate emoji problem when the caller wants a specific emoji and embeds it in the message string — the formatter also auto-selects an emoji from keyword matching, resulting in output like:

[11:14AM][INFO][✅]: ✅ Config engine initialized
[11:14AM][INFO][🤖]: 🤖 Heartware initialized

The emoji appears twice: once from the auto-selected emoji element [✅] and once from the manually embedded emoji in the message ✅ Config engine initialized.

Callers currently have no way to:

1. Override the auto-selected emoji element for a specific log call
2. Suppress the emoji element for a single call without disabling it globally

Proposed Solution

Extend the log method signatures to accept an optional options object that includes an emoji field:

interface LogCallOptions {
  emoji?: string;  // Override the auto-detected emoji for this call
}

// Updated signatures (backwards compatible)
debug(message: string, data?: LogData, options?: LogCallOptions): void;
info(message: string, data?: LogData, options?: LogCallOptions): void;
warn(message: string, data?: LogData, options?: LogCallOptions): void;
error(message: string, data?: LogData, options?: LogCallOptions): void;
log(message: string, data?: LogData, options?: LogCallOptions): void;

Usage Example

// Before (duplicate emoji):
logger.info('✅ Database initialized');  
// Output: [11:14AM][INFO][✅]: ✅ Database initialized

// After (clean, override emoji element):
logger.info('Database initialized', undefined, { emoji: '✅' });
// Output: [11:14AM][INFO][✅]: Database initialized

This would allow callers to set a precise emoji for the log element without embedding it in the message content, eliminating the duplication issue.

Alternatives Considered

• Strip leading emoji from message text: Fragile, depends on emoji detection regex
• Disable emoji globally: Loses the useful visual context for all other messages
• Accept current behavior: Results in cluttered, redundant log output

Environment

• @wgtechlabs/log-engine: v2.3.0