fix(plugin): initialize file logging from the ESM bridge entry

[akushonkamen]

Fixes #2399

---

Summary

The two hand-copied bridge entries drifted apart when the standalone-logging
flag (initLogging) landed in dev-v2.0.25: the legacy CJS entry
(bridge.cts) passes initLogging: true to bootstrapMemoryCoreFull, but the
ESM entry (bridge.mts) — the entry bridge_client.py actually prefers —
does not. Result: every bridge started from a current build never constructs
the logger, so config.logging is silently inert end to end (console channel,
timezone, level, channels, and all file sinks under <home>/logs).

This PR adds the missing initLogging: true (plus the explanatory comment
already present in bridge.cts) and an integration regression that spawns
dist/bridge.mjs and asserts the file sinks appear.

Root cause

// before — bridge.mts (the actual entry: bridge_client.py resolves
// dist/bridge.mjs > dist/bridge.cjs > bridge.mts > bridge.cts)
const { core, config, home } = await bootstrapMemoryCoreFull({
  agent: args.agent,
  namespace: { agentKind: args.agent, profileId: "default" },
  autoRecovery: args.agent !== "hermes" || !args.daemon,
  pkgVersion,
  hostLlmBridge: args.daemon ? null : lazyHostLlmBridge,
  home: resolvedHome,
});                                // ← no initLogging

bootstrapMemoryCoreFull gates its only initLogger call on the option
(core/pipeline/memory-core.ts):

/**
 * When true, initialize the global logger from `config.logging` (…). The
 * standalone daemon (`bridge.cts`) owns its stdio and must set this; embedded
 * plugin hosts leave it false so the host keeps control of logging.
 */
initLogging?: boolean;
…
if (options.initLogging) {
  initLogger(config, home);
}

bridge.cts honors the contract (and comments it); bridge.mts was never
updated when the flag was introduced, and the option is optional/falsy-skip, so
nothing warns. The file transports (core/logger/index.ts →
FileRotatingTransport) are the only thing that creates <home>/logs, and
they are constructed eagerly inside initLogger — hence "no logs directory,
ever" from the packaged entry, exactly as reported.

Behavior-change notes

For existing users this restores the documented behavior rather than adding
overhead: after this change a packaged bridge actually produces the sinks that
config.logging already promises (default logging.file.enabled: true —
memos.log, error.log, audit.log, events.jsonl, llm.jsonl,
perf.jsonl under <home>/logs). Nothing else about logging changes:

• bridge.cts — already correct, untouched.
• The embedded host (adapters/deepseek-harness/index.ts, initLogging: false) is intentionally untouched — embedded hosts keeping control of
  logging is the documented design.
• The unrotated daemon-start.log mentioned in the issue is a separate code
  path outside initLogger and is out of scope here.

Tests

New regression case in
apps/memos-local-plugin/tests/integration/bridge-esm-entry.test.ts (the
existing #1736 harness: spawn dist/bridge.mjs, temporary home, grace-period
SIGTERM): after startup, logs/memos.log and logs/error.log must exist under
the runtime home. The transports open their files eagerly during initLogger,
so the assertion is deterministic. As in the #1736 case, an environment-level
missing-native-binding failure is tolerated (unrelated to this issue).

Red→green evidence:

• Red — unfixed main @ a7367d0, built, run by hand and via the new
  test:

  $ node dist/bridge.mjs --agent=hermes --no-viewer --home=<tmp>
  … bridge: stdio mode running without viewer (agent=hermes)   # starts fine
  $ ls <tmp>
  bridge-status.json  data  memos-local        # no logs/
  × expected a file sink at <tmp>/logs/memos.log after startup …
    expected false to be true
  Test Files  1 failed (1)
  Tests  1 failed | 1 passed (2)
  

• Green — same flow after the one-line fix (rebuilt):

  ✓ tests/integration/bridge-esm-entry.test.ts (2 tests) 555ms
  Test Files  1 passed (1)
  Tests  2 passed (2)
  $ ls <tmp>/logs
  audit.log  error.log  events.jsonl  llm.jsonl  memos.log  perf.jsonl
  $ head -1 <tmp>/logs/memos.log
  {"pid":…,"src":"ts","seq":1,"tz":"UTC","ts":…,"level":"warn","kind":"app",
   "channel":"core.pipeline.bootstrap", …}
  

Validation (all offline, no LLM key / Docker / Neo4j / Qdrant):

• npx vitest run tests/integration/bridge-esm-entry.test.ts — 2/2
• npx vitest run tests/unit/bridge-status.test.ts — 3/3
• npm run test:unit — 181 files, 1589 passed, 2 skipped (zero regressions)
• npm run lint (tsc -p tsconfig.json --noEmit) — clean

[Memtensor-AI]

🤖 Open Code Review

Target: PR #2465
Task: c68f0ef5eef74277
Base: main
Head: fix/bridge-esm-init-logging

✅ OpenCodeReview: Review skipped: no items were selected.

Generated by cloud-assistant via Open Code Review.

[Memtensor-AI]

⚠️ Automated Test Results: ENV ISSUE

The test environment encountered an issue that requires manual attention.

Details: Environment preparation failed before any gating tests executed. Failed scopes: memos_local_plugin
Branch: fix/bridge-esm-init-logging

[akushonkamen]

Heads-up on CI: the autotest bot reports the same ENV ISSUE here as on #2464 and #2466:

• Scope: memos_local_plugin — environment preparation failed before any gating tests executed, so this is an infra issue, not a code failure.
• It reproduces across all three open PRs, and on fix(plugin): stop clamping storage list queries to 500 rows #2464 the re-run on the new head (cd70df6) is also ENV ISSUE — so it does not look transient or PR-specific.
• Could a CI admin check the memos_local_plugin scope environment, or manually trigger a rerun once it's healthy? Happy to help debug the scope setup if needed.