Source directory named 'deploy' is silently skipped as build output, so the graph returns the wrong definition

[SQLBImhugh]

Environment: v0.10.2, Windows 11, daemon mode, --mode fast and --mode full both affected.

Symptom

A directory named deploy is skipped as build output even when it contains git-tracked source that is not ignored by .gitignore. It is reported under not_indexed.dirs, alongside genuine build artifacts like dist and node_modules.

In my repo, frontend/src/components/deploy/ holds 11 tracked React/TypeScript files — StepCard.tsx, DeploymentHero.tsx, StepIcon.tsx, statusInfo.ts, TerminalBanner.tsx, SuspectedBugBanner.tsx, state.ts, types.ts — none of them ignored. git check-ignore -v returns nothing for the path and git ls-files lists every file.

Minimal reproducer

Two byte-identical files whose only difference is the parent directory name:

src/components/deploy/statusInfo.ts
src/components/widgets/statusInfo.ts

Both containing:

export function statusInfo(s: string) {
  return { variant: s === "ok" ? "green" : "red" }
}

git init && git add -A && git commit -m init
codebase-memory-mcp cli index_repository --repo-path <repo> --mode fast

Result:

nodes=8  not_indexed_dirs=.git,src/components/deploy

codebase-memory-mcp cli search_graph --project <p> --name-pattern statusInfo
total: 3
  ...src.components.widgets (src/components/widgets/statusInfo.ts)
  ...src.components.widgets.statusInfo (src/components/widgets/statusInfo.ts)
  ...src.components.widgets.statusInfo.ts (src/components/widgets/statusInfo.ts)

Only the widgets copy is indexed. Identical content, identical extension, both tracked — the directory name alone decides.

Why this is worse than a missing file

The graph does not go quiet; it answers confidently and wrongly.

My repo's design guide names frontend/src/components/deploy/statusInfo.ts:6 STATUS_INFO as the single canonical status→badge map, and explicitly warns against per-component status→color maps. With deploy/ skipped, search_graph(name_pattern="statusInfo") returned exactly three hits — the three local wrappers in Admin.tsx, Dashboard.tsx and AdminAutorunnerRunsTab.tsx — and not the canonical definition.

So an agent asking "where is statusInfo defined?" is pointed at the precise anti-pattern the codebase forbids, with no signal that anything is missing. A silently-skipped source directory is indistinguishable from one that genuinely has no canonical definition.

not_indexed is documented as "excluded by design", which is accurate for dist/node_modules but misleading here — nothing in the user's configuration asked for this exclusion.

Workaround (confirmed)

.cbmignore negation lifts it:

!frontend/src/components/deploy/

Re-indexing then picks the directory up: on the reproducer nodes went 8 → 12 and excluded dropped to just .git; on the real repo 41,747 → 41,828 nodes, and STATUS_INFO/statusInfo/StepCard/DeploymentHero all resolve correctly (3 → 7 hits for the same query).

So the mechanism to override exists and works well — the issue is purely that the default fires on a source directory.

Suggested fixes

In rough order of value:

1. Do not skip a directory that contains tracked, non-ignored source files. A cheap guard: if the directory is inside a git work tree and git ls-files reports content under it, index it regardless of name. This is the general fix — the same false positive will hit any repo with src/.../deploy/, and likely src/.../build/, src/.../target/, src/.../out/ as components.
2. Restrict the name heuristic to repo-root-level directories. ./deploy/ is plausibly build output; src/components/deploy/ almost never is.
3. Separate "excluded by your config" from "excluded by our heuristic" in index_status / check_index_coverage. Right now both land in not_indexed with reason: gitignore-style framing. A distinct reason such as heuristic:build-dir-name would make this discoverable instead of silent — I only found it because a symbol I knew existed was absent from the graph.

Happy to test a patch; the reproducer above is two files and deterministic.

[DeusData]

@SQLBImhugh, thank you for the byte-identical reproducer and for checking both Git tracking and the .cbmignore override. Confirmed against current main.

src/discover/discover.c places deploy in ALWAYS_SKIP_DIRS, and cbm_should_skip_dir() applies that basename list at every depth before the walker descends. The list is unconditional even in FULL mode; there is no root-depth or tracked-source check. That is why src/components/deploy is skipped solely because of its name while the identical widgets tree is indexed.

This is a bug, not an intentional repository exclusion, and I have marked it priority/high because it can produce a confident wrong definition rather than an obvious error. Your negated .cbmignore entry is the correct temporary workaround. No further reporter action is needed; the deterministic two-file fixture is sufficient for a reproduce-first fix. Thank you for making the false-positive mechanism unambiguous.

[PS-NaMaN]

Proposed fix — happy to implement if you'd like to assign this to me @DeusData

I dug into the code and confirmed the root cause. In src/discover/discover.c:

1. ALWAYS_SKIP_DIRS[] contains deploy/deployed, and FAST_SKIP_DIRS[] contains build, out, bin, etc.
2. cbm_should_skip_dir() matches only the directory basename, so src/components/deploy/ is pruned the same as a root-level deploy/ — and unlike .gitignore/.cbmignore (which the walk honors, including the existing Please make ALWAYS_SKIP_DIRS configurable by user #500 .cbmignore negation escape hatch), this hardcoded heuristic has no "is this actually tracked source?" check.

Proposed fix: never let the name heuristic prune a directory that git actually tracks.

1. Add a small helper in src/git/git_context.c — cbm_git_has_tracked_files(repo_path, rel_path) — reusing the existing git_capture()/cbm_popen() pattern and cbm_validate_shell_path_arg() validation. It runs git ls-files --

   ; a non-empty result means tracked content. Any failure (not a real repo, invalid path chars, git error) returns "not tracked", so the heuristic skip stands — fail-safe in the recoverable direction.

2. In discover.c, thread the already-resolved is_git_repo/repo_path from discover_impl() into the walk, and in should_skip_directory(): when a dir matches the built-in name skip AND it is not a safety-core dir (.git, node_modules, .worktrees, .claude-worktrees stay non-negotiable) AND the existing .cbmignore negation didn't already unskip — if the repo is a real git work tree and git ls-files reports content under the dir, don't skip by name; fall through so .gitignore/.cbmignore still decide. Otherwise skip exactly as today.
   This fixes the general case at any depth (including a root-level deploy/ with tracked source), while keeping genuinely gitignored build dirs excluded, and keeps the existing test suite green (current discover tests all use non-git fixtures, so the guard is simply inactive there).