[lamchun1110]

What

Fixes #10312.

getSettings() in src/lib/db/settings.ts set debugMode: true in the defaults object, so any fresh install (or one missing the persisted debugMode key) ran in debug mode — contradicting the docs, which describe Debug Mode as an Advanced, opt-in toggle. This flooded new production installs with debug-level logs and buried real warnings.

Change

• Flip the default from true to false in the getSettings() defaults object (neighbor opt-in flag logToolSources already defaults to false).
• No migration needed: installs that already persisted debugMode: true keep it — only the missing-key path changes.

Tests

Added tests/unit/db-settings-debug-mode-default-10312.test.ts:

1. Empty store → debugMode === false (fresh install is not in debug)
2. Persisted debugMode: true is preserved after the default flip
3. Persisted debugMode: false stays false

Verified locally: new test file passes (3/3), existing settings test files pass (db-settings-extended, db-settings-split, settings-api, check-pack-boot — 79/79), and npm run lint is clean.

Changelog fragment

Added under changelog.d/fixes/ with this PR's number.

[diegosouzapw]

Thanks for the fix, Jacky — this is a clean, minimal patch for a real production issue.

I reviewed the change and reran your test coverage in an isolated environment:

• tests/unit/db-settings-debug-mode-default-10312.test.ts — 3/3 pass (fresh install → false, persisted true preserved, persisted false preserved).
• db-settings-extended.test.ts + db-settings-split.test.ts — 53/53 pass, no regressions in neighboring settings behavior.

The fix itself (src/lib/db/settings.ts) is exactly the surgical one-line change the issue called for, with a clear comment explaining the opt-in/missing-key semantics, and the changelog fragment is correctly formatted. No migration needed, no security or cross-layer surface touched — this is merge-ready as-is.

One small unrelated note for the future (not blocking this PR): DebugModeCard.tsx seeds its local toggle state with useState(true) before the settings fetch resolves, so it will briefly render as "on" (though disabled) for a moment on load. Not something this PR needs to fix — just flagging it as a possible follow-up.

Nice catch and nice test discipline.

[diegosouzapw]

Validated in local merge-train .claude/worktrees/merge-train-20260816-000002-suite.log on devbox-vm-06-dev002 @ 8be62df65f61cc4cf29cdc3e6bc38173ffafa4e3 (FAST gates green: static + changed tests + vitest; daily full-suite run still required). Merged under the batch merge-train protocol (merge-gates §7). ⚠️ base-red inherited: #10523 (ServiceSupervisor order-dependent test, not touched by this batch).