@qwen-code /triage

Thanks for the PR, @tt-a1i!

Template: headings don't match .github/pull_request_template.md exactly — "Summary" / "Test plan" instead of "What this PR does" / "Why it's needed" / "Reviewer Test Plan", and the "Risk & Scope" / "Linked Issues" sections are missing. Content is all there though, so not blocking — but please use the template headings on future PRs so reviewers can scan quickly.

Direction: This is a textbook DRY fix. tools/memory-config.ts and memory/const.ts were independently holding the same module-level state (currentGeminiMdFilename), so callers importing from different paths could silently diverge. Re-exporting from memory/const.ts is the right call — single source of truth, no behavior change. Aligned with #4063.

Approach: Scope is minimal — one file reduced to re-exports, one test added for the shared-state invariant. Nothing to cut. The beforeEach reset in the test suite is a good hygiene addition since test order would otherwise matter.

Moving on to code review and testing. 🔍

— Qwen Code · qwen3.7-max

Code Review

Independent proposal before reading the diff: I'd replace the duplicated state in tools/memory-config.ts with re-exports from memory/const.ts, and add a test that imports from both paths and asserts shared state. Exactly what the PR does.

Reviewing the diff against this baseline:

• Correctness ✓ — all 5 previously-exported symbols (DEFAULT_CONTEXT_FILENAME, AGENT_CONTEXT_FILENAME, MEMORY_SECTION_HEADER, setGeminiMdFilename, getCurrentGeminiMdFilename, getAllGeminiMdFilenames) are re-exported from memory/const.ts. No API breakage for existing importers.
• No circular dependency — tools/memory-config.ts imports from ../memory/const.js; memory/const.ts has no import from tools/.
• Behavioral note: memory/const.ts's getCurrentGeminiMdFilename() has more robust empty-entry filtering than the old tools/memory-config.ts version (falls back to DEFAULT_CONTEXT_FILENAME when all entries are whitespace). This is a strict improvement — callers who previously got '' now get 'QWEN.md'.
• Test quality ✓ — the shared-state test verifies bidirectional reads/writes through both entry points and the beforeEach ensures isolation from the array test above.
• Prettier ✓, ESLint ✓, TypeScript build ✓ (no new warnings).

No blockers found.

Test Results

Non-user-visible refactoring — verified via unit tests (250 tests across all related test files):

$ cd packages/core && npx vitest run src/memory/const.test.ts src/memory/writeContextFile.test.ts src/config/config.test.ts

 RUN  v3.2.4 /home/runner/work/qwen-code/qwen-code/packages/core
      Coverage enabled with v8

 ✓ src/memory/const.test.ts (4 tests) 7ms
 ✓ src/memory/writeContextFile.test.ts (16 tests) 50ms
 ✓ src/config/config.test.ts (230 tests) 371ms

 Test Files  3 passed (3)
      Tests  250 passed (250)
   Start at  17:08:36
   Duration  7.14s (transform 2.49s, setup 82ms, collect 4.33s, tests 428ms, environment 1ms, prepare 399ms)

— Qwen Code · qwen3.7-max

This is a clean, focused PR that does exactly one thing and does it well.

My independent proposal (replace duplicated state with re-exports, add a shared-state test) matches the PR's approach — which means the author found the obvious right answer, not a clever workaround. That's the best signal you can get.

The behavioral improvement in getCurrentGeminiMdFilename() (whitespace-entry filtering from memory/const.ts replacing the simpler tools/memory-config.ts version) is a free correctness win that probably prevents a real edge case someone would have hit eventually.

All 250 related tests pass, build is clean, linting is clean. The template heading mismatch is minor and doesn't affect review quality.

Approving. ✅

— Qwen Code · qwen3.7-max

✅ Verification report — recommend merge

I built a real, runtime verification of this PR (esbuild-transpiled module A/B + a tmux real-process boot + the PR's own unit/lint suite), not just a diff read. Verdict: correct, low-risk de-duplication fix. The divergent-state bug is real at the module level; it is currently latent in production but tools/memory-config.ts is by-design a future import target, so this is sound preventive hardening with a genuine regression test.

TL;DR

What the bug was

memory/const.ts and tools/memory-config.ts each declared their own let currentGeminiMdFilename plus setter/getters. They were independent module-level state — mutating one never affected the other.

Evidence

1. Module-state A/B. I transpiled both branches' modules with esbuild into a tree where memory/const.js is byte-identical and only tools/memory-config.js differs, then drove the real production mutation (config.ts:1393 calls setGeminiMdFilename imported from ../memory/const.js) and read back through the lightweight entrypoint:

BEFORE (main, duplicate module)              AFTER (PR #5419, re-export)
  set 'CUSTOM_CONTEXT.md' via const setter     set 'CUSTOM_CONTEXT.md' via const setter
  tool.getCurrent() -> "QWEN.md"        FAIL    tool.getCurrent() -> "CUSTOM_CONTEXT.md"  PASS
  tool.getAll()     -> ["QWEN.md","AGENTS.md"]  tool.getAll()     -> ["CUSTOM_CONTEXT.md"] PASS
  (array case + reverse direction also FAIL)    (all PASS, both directions)
  => STATE DIVERGED ✘                           => STATE SHARED ✔

2. tmux real-process boot. Mirroring the real public surface (index.ts:191 → export * from './memory/const.js'), I loaded barrel + const + re-export in one Node process and mutated via the public API:

[before] loaded barrel+const+re-export with NO circular-import crash
  public setGeminiMdFilename('BARREL_SET.md') -> tool.getAll() = ["QWEN.md","AGENTS.md"]  => DIVERGED ✘
[after]  loaded barrel+const+re-export with NO circular-import crash
  public setGeminiMdFilename('BARREL_SET.md') -> tool.getAll() = ["BARREL_SET.md"]        => SHARED ✔

This also confirms the re-export introduces no circular import and the ESM live-binding works through the barrel — the only real structural risk of a re-export-only module.

Reachability — honest caveat for the merge decision

The divergence is real at the module level but latent in production today. No source file imports tools/memory-config.ts; the only reference anywhere is a now-vestigial vi.mock('../tools/memory-config', …) at config/config.test.ts:221 (the live mock is the ../memory/const.js one at line 215). Both the mutation path (config.ts:1393) and the package's public surface (index.ts:191) already resolve to memory/const.ts, so there is no user-facing bug right now.

It still matters: tools/memory-config.ts exists specifically as the lightweight entrypoint ("to avoid loading the full tool module when only the filename configuration is needed"). Any future code that imports it to read the configured context filename would silently get the stale QWEN.md/AGENTS.md default after a user set contextFileName. This PR removes that trap by collapsing to one source of truth, and the export surface is preserved exactly (the 6 original symbols; LOCAL_CONTEXT_FILENAME is intentionally not re-exported), so it is backward-compatible.

Optional non-blocking follow-up

vi.mock('../tools/memory-config', …) at packages/core/src/config/config.test.ts:221 is now dead (nothing under test imports that module). Removing it in a follow-up would fully close the duplication debt this PR targets.

修复前（main，重复模块）                       修复后（PR #5419，重导出）
  经 const setter 设置 'CUSTOM_CONTEXT.md'      经 const setter 设置 'CUSTOM_CONTEXT.md'
  tool.getCurrent() -> "QWEN.md"        失败     tool.getCurrent() -> "CUSTOM_CONTEXT.md"  通过
  tool.getAll()     -> ["QWEN.md","AGENTS.md"]   tool.getAll()     -> ["CUSTOM_CONTEXT.md"] 通过
  （数组写入 + 反向写入同样失败）                （全部通过，双向都通过）
  => 状态分裂 ✘                                  => 状态共享 ✔

[before] loaded barrel+const+re-export with NO circular-import crash
  public setGeminiMdFilename('BARREL_SET.md') -> tool.getAll() = ["QWEN.md","AGENTS.md"]  => DIVERGED ✘
[after]  loaded barrel+const+re-export with NO circular-import crash
  public setGeminiMdFilename('BARREL_SET.md') -> tool.getAll() = ["BARREL_SET.md"]        => SHARED ✔

_{Verified on a worktree at PR head 4975b279. Module A/B & tmux boot use esbuild-transpiled real modules sharing a byte-identical memory/const.js; unit tests via vitest run. The config.test.ts load failure is a pre-existing sandbox undici resolution issue (reproduces on main), unrelated to this PR.}