Plugin always overrides collection via --collection flag, making .memsearch.toml project config ineffective for worktree setups

[caleb-reyes-op]

Problem

The @zilliz/memsearch-opencode plugin derives a per-project collection name via derive-collection.sh and always passes it as --collection <name> to every memsearch invocation. Since CLI flags have the highest priority in the config chain, any [milvus] collection setting in .memsearch.toml is silently overridden.

This makes it impossible to force a consistent collection name for a project via config — the plugin always wins.

Affected Use Case: Git Worktrees

A common pattern with tools like worktrunk is to share the primary repo's .memsearch/ directory across all worktrees via symlink:

# In wt.toml post-start hook:
ln -sfn {{ primary_worktree_path }}/.memsearch ./.memsearch

The intent: all worktrees write memory to the same daily .md files, and memory_search queries a single shared index.

The reality: derive-collection.sh hashes the worktree's path, not the symlink target. So:

• ~/Coding/web → ms_web_7a164b53
• ~/Coding/web__worktrees/wxp-1248 → ms_wxp_1248_01b271df
• ~/Coding/web__worktrees/wxp-1444 → ms_wxp_1444_1347ffe4

Each worktree captures to the shared .md files correctly, but indexes into and searches its own isolated Milvus collection. Memory from the main web session is invisible from any worktree session, and vice versa.

Expected Behavior

If .memsearch/.memsearch.toml (or .memsearch.toml) specifies [milvus] collection = "ms_web", the plugin should respect it instead of overriding it. The priority chain should be:

defaults → ~/.memsearch/config.toml → .memsearch.toml → (plugin-derived, only if no config override)

Or alternatively, derive-collection.sh should resolve symlinks before hashing — so that a worktree whose .memsearch is a symlink to ~/Coding/web/.memsearch would hash ~/Coding/web and converge on ms_web_7a164b53.

Workaround

Manually patch derive-collection.sh to resolve through the .memsearch symlink before hashing:

# After resolving PROJECT_DIR to absolute path:
memsearch_link="$PROJECT_DIR/.memsearch"
if [ -L "$memsearch_link" ]; then
  resolved="$(readlink -f "$memsearch_link")"
  PROJECT_DIR="$(dirname "$resolved")"
fi

This works but is fragile — it's overwritten on every plugin update.

Proposed Fix

Either:

1. In index.ts, before calling deriveCollectionName(projectDir), check if projectDir + '/.memsearch.toml' specifies a collection and use that instead.
2. In derive-collection.sh, resolve through any .memsearch symlink before hashing (as shown above).
3. Skip passing --collection entirely when a project-level .memsearch.toml exists with a [milvus].collection value — let the memsearch CLI pick it up naturally.

Option 3 seems cleanest as it respects the existing config priority chain without special-casing.