🔖 Release v1.2.4 — LMDB mapsize fatal crash fix + build.ps1 self-heal - #191
Merged
Conversation
The index-job submitted all per-vendor build requests at once (rebuild_repo returns on HTTP 202) and waited once afterward, so serve held every vendor's embedding model + working set simultaneously and was OOM-killed (SIGKILL) on the 8 GiB job limit, leaving wait_until_indexed polling a dead process forever. Build one vendor at a time: submit -> wait_active_build_done -> verify -> next. Peak memory is now a single index build regardless of vendor count. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `i` (info) key now works on mounted remote projects (federation peers): a new OverlayState::RemoteInfo shows the peer URL and the peer-reported live status (status/lock/changes/calls/last-call) instead of local on-disk index stats, which a mount does not have. When a remote mount is selected, the footer now renders doctor / reindex / remove struck-through (CROSSED_OUT) so it is clear those local-index actions do not apply to a peer-hosted mount. info / reload / quit / nav stay enabled. The standalone remote TUI is unaffected (its rows are the peer's own local repos, is_remote=false). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
CHANGELOG: new [Unreleased] section covering mounted remote projects (project=<peer>/<alias>), the TUI remote-mount info panel + disabled local-index actions, the per-vendor cloud indexer split, the sequential build OOM fix, the local BuildKit build workflow, and the grep-guard hook. README: new "Mounting a peer's projects" subsection under Federation (project=<peer>/<alias>, italic TUI mounts, `i` info, disabled actions). AGENTS: Stage 4/5 notes updated (TUI info/disabled + sequential build), Current state bumped to v1.1.9 with deploy outcome; deferred list refreshed. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…mount Applies the reviewer's non-blocking UX remark: pressing doctor / reindex / remove while a mounted remote project is selected was a silent no-op (the struck-through footer hint was the only cue). Now it also flashes a short "don't apply to a remote mount" confirmation, reinforcing which actions are available on a peer-hosted mount. Message centralised in one REMOTE_ACTION_NA const (no literal duplication). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
# Conflicts: # CHANGELOG.md # Cargo.lock # Cargo.toml
🔒️ fix: scrub customer identifier (aprimo→vendor-a) for public push The pre-push customer-ref gate (blocks [Aa]primo|husqvarna|bayer|… on pushes to develop/master) flagged 5 residual "aprimo" references after merging federation into develop: vendor-list examples in AGENTS.md / CHANGELOG.md, a doc-comment in repos.rs, and test data in federation/mod.rs. Replaced all with the generic placeholder "vendor-a" (other vendor names akeneo/bynder/… are not customer identifiers and stay). The federation namespacing test still passes (arg + assert use the same token). Full-tree scan now clean. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> @
…allowlist) Remote peers no longer auto-expose every project. The local user now explicitly picks which individual per-vendor indexes to use, via a new opt-in `remote_mounts` allowlist in repos.json — the single source of truth for routing, discoverability, TUI display, and group fan-out. - config: replace opt-out `remote_hidden` with opt-in `remote_mounts`; mounted_remote_projects() is allowlist-driven (no discovery arg); resolve_remote_project() gates on the allowlist; new group_remote_projects(), mount_remote_project()/unmount_remote_project(); reconcile() prunes stale/unknown-peer/malformed mounts + orphaned rename overrides. - routing: `@peer` group fan-out now queries only the mounted <peer>/<alias> projects (per-project search_project), never the whole peer; federated_search reworked; obsolete whole-peer FederationClient::search removed. - discoverability: list_projects gains a `remote_projects` array; scope_required advertises mounted names as first-class `project=` targets. - cli: `remote available|mount|unmount|mounts` to inspect a peer and pick. - tui: rows come from the allowlist; discovery only enriches live status. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Update CHANGELOG (Unreleased), README (Federation → mounting), and AGENTS.md for the shift from auto-discover/opt-out to the explicit `remote_mounts` allowlist: new `remote available|mount|unmount|mounts` CLI, group fan-out restricted to mounted indexes, non-mounted = unroutable, and mounts surfaced in list_projects/scope_required. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ncile Address reviewer minor: reconcile() dropped orphaned remote_alias_overrides only when a mount was pruned that round, so a hand-edited removal from remote_mounts left a stale override that could resurface as a surprise rename on re-mount. Now retain overrides against the current mounted set unconditionally. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The TUI `i` overlay on a mounted remote project previously showed only
peer URL + status. It now fetches the peer's on-disk index stats
(chunks / files / db size / model) on demand from GET /repos/{alias}/info
and renders them with a loading / ready / unavailable tri-state, giving
remote mounts parity with the local Info overlay.
- federation: add RemoteRepoInfo + FederationClient::repo_info()
- constants: add REPO_INFO_PATH_SUFFIX ("/info")
- tui_common: OverlayState::RemoteInfo gains RemoteStatsState; render
chunk/file/db-size/model lines (or placeholder) after status
- tui: build_remote_info_overlay starts Loading; ShowInfo resolves
peer+remote_alias and spawns an async fetch via the doctor channel;
recv guard broadened to apply RemoteInfo results
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Review remarks on 1cea46b: - Bump doctor_gen UNCONDITIONALLY before resolving the mount, so a still-in-flight doctor/remote-info reply (shared channel + counter) can never clobber the freshly-opened RemoteInfo overlay via the recv guard. - When resolve_remote_project returns None (misconfig or a config reload racing the keypress), render stats as Unavailable instead of leaving the overlay stuck on "fetching…" forever. - Build the base overlay once and clone it (derive Clone on OverlayState) rather than building it twice. - Soften the Unavailable label to "stats unavailable from peer" since an HttpError from a reachable peer also lands here (not only unreachability). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…hunk_id) Remote search returned chunk_refs shaped "<peer>:<id>", dropping the remote project alias. Since the peer is itself multi-repo and chunk_ids are only unique within one index, every federated get_chunk failed with ambiguous_chunk_id when the peer hosted more than one project (inriver, aprimo, bynder, ...). Client-side fix (the serve /chunk route already honoured ?project=): - convert_remote_item now namespaces the ref as "<peer>/<alias>:<id>" and tags source as "<peer>/<alias>". - parse_federated_chunk_ref (new, unit-tested) splits peer/alias/id; accepts the legacy "<peer>:<id>" shape for backward compatibility. - FederationClient::get_chunk forwards project=<alias> (and omits group) when an alias is present, mirroring search_project; legacy refs still fall back to group scope. - Docs on GetChunkRequest.chunk_ref + inline comments updated. Tests: parse helper (4 cases), namespaced convert, and a live-peer get_chunk asserting project=<alias> is forwarded and group omitted. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adds a live-peer test asserting that a non-namespaced chunk_ref (remote_alias=None) forwards a `group` scope and omits `project`, closing the coverage gap flagged in the Stage A review. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…aude installer in Rust)
The single `hooks install` (git post-checkout hook) is replaced by two
explicit subcommand groups (hard break, no back-compat alias for the old
`install`):
- `codesearch hooks git install [--path]` — the prior post-checkout worktree
auto-register hook.
- `codesearch hooks claude install [--project]` — NEW: installs the Claude
Code PreToolUse guard hooks (Grep -> grep-guard, Agent -> subagent-preamble)
into ~/.claude (or ./.claude with --project). Rust port of
integrations/claude-code/install.{sh,ps1}: scripts are embedded via
include_str! (self-contained binary), settings.json is backed up and merged
idempotently (keyed by exact command string), and the host shell is detected
(pwsh on Windows, bash elsewhere).
The top-level command is now `hooks` (alias `hook` kept for muscle memory).
New module src/cli/claude_hooks.rs with unit tests for the settings merge
(empty/idempotent/preserve-unrelated/bad-shape) and host-shell command build.
README updated. Stage B will add a WebSearch/WebFetch guard to GUARD_HOOKS.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ounts
New PreToolUse guard (bash + pwsh twins) matching WebSearch|WebFetch: when
repos.json has remote projects mounted (.remote_mounts, e.g. cloud/inriver,
cloud/aprimo), it denies the first web call with guidance to search those
indexed mounts first (compact=false to read inline, then get_chunk). Same
5-minute retry-escape as grep-guard; when no mounts are configured it does
nothing. Detection reads repos.json directly (CODESEARCH_REPOS_CONFIG or
~/.codesearch/repos.json) — no binary spawn, no serve round-trip.
- integrations/claude-code/hooks/web-guard.{sh,ps1} (new)
- claude_hooks.rs: web-guard added to GUARD_HOOKS (embedded via include_str!)
- install.{sh,ps1}: register the WebSearch|WebFetch matcher for parity
- README: three-guard section, `hooks claude install` as the primary path
Also addresses the Stage C review minors: drop the redundant create_dir_all,
add tests for non-object hooks/root shapes + GUARD_HOOKS coverage, and
cross-reference the two documented install paths.
This closes the gap that let me reach for WebSearch instead of the mounted
inriver/aprimo docs — the guard now makes the preference structural.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… (review minor)
Clarifies the deny message in both web-guard twins: after searching a mount,
read full context via get_chunk with the returned federated `chunk_ref`
("<peer/alias:id>"), not chunk_id — the correct param for remote results.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…format (final review remark) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…table Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…federation tests Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ASS) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
serve mode previously git-pulled the custom-kb repo every KB_PULL_INTERVAL_SECS but nothing triggered indexing afterward — the "periodic incremental reindex (REINDEX_INTERVAL_SECS)" the comments promised does not exist in code. Pulled KB articles therefore only became searchable on the next cold-start warmup. The KB pull loop now detects when a pull moves HEAD and fires POST /repos/custom-kb/reindex (incremental) against the local serve, so new/changed articles are searchable without a restart. Incremental refresh re-embeds only the delta and the KB corpus is small, so it fits the 1-2 GiB serve replica; the heavy DOCS corpus stays index-job-only. - repos open read-write by default (try_open_stores), so custom-kb on the serve's local disk reindexes in-place — no Rust change needed - fire-and-forget 202; 409 (concurrent/FSW pickup) is expected + harmless - first pull fires after the interval, after Phase-1 warmup releases the KB write lock, so no warmup contention - fixed the stale REINDEX_INTERVAL_SECS comments (header, env doc, run_serve) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… exception Follow-up to the serve custom-kb incremental-reindex change. The cloud docs still described serve as strictly restore-only / never-reindexes, which is no longer accurate: serve now runs a memory-bounded incremental reindex of the small custom-kb repo after each KB pull. - integrations/cloud/README.md: scope the "read-only / never writes" statements to the DOCS corpus; document the custom-kb incremental reindex as the sole in-process write (fire-and-forget 202, incremental only, HEAD-change gated, 409/404 benign). Correct the management-verbs note — incremental reindex of a registered repo succeeds; only add / reindex --force still require a read-write peer. - AGENTS.md: note the custom-kb incremental step as the scoped first realization of the "incremental in-process on serve" redesign; DOCS corpus stays job-only (the OOM that motivated the split). Nuance the remote-write-verbs note accordingly. - entrypoint.sh: distinguish HTTP 404 (custom-kb not yet in the restored snapshot — expected during bootstrap) from a genuine failure WARN (addresses review remark). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…un 1) Complements section B (isolation) with the inverse: a concept shared across vendors must surface hits from multiple vendors at once via group="docs" RRF fusion, while domain-specific concepts stay absent from the opposite domain. 5 scenarios (F1–F5) covering PIM/DAM overlap and isolation, all executed and passing in Run 1. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The cloud image build broke on the release compile:
error: couldn't read `.../integrations/claude-code/hooks/grep-guard.sh`:
No such file or directory (os error 2)
src/cli/claude_hooks.rs embeds the six hook scripts at compile time via
include_str!("../../integrations/claude-code/hooks/*"), but the Dockerfile
only copied Cargo.*, build.rs and src/ into the builder, so the hooks
subtree was absent from the build context. This is latent since the
hooks-split feature landed — v2.7 predates it, so this is the first image
build to hit it. Local builds compile because the tree is on disk.
Copy only that subtree (the exact paths include_str! needs) before the
cargo build. Verified no other include_str!/include_bytes! in src/
references paths outside src/.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…mage) The v2.8 cloud image failed to start: `env: 'bash\r': No such file or directory`. Root cause: core.autocrlf=true rewrites docker/entrypoint.sh to CRLF in the Windows working copy, and the Docker build copies the working copy (not git's LF blob) into the image — so the CRLF shebang was baked in and the container could not exec bash. Pin *.sh (and docker/entrypoint.sh explicitly) to eol=lf so the working copy is always LF regardless of the local autocrlf setting, and the image can never regress to a CRLF shebang. entrypoint.sh already normalized to LF in the working copy; the git blob was already LF. Deployed image tag v2.9 carries the LF fix and is verified live (serve boots, /healthz 200, "KB auto-pull loop started (git pull + reindex-on- change...)" present, no bash\r error). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
… bump + rebuild) The hook auto-bumped the Cargo.toml patch version and ran `cargo build` on every feature-branch commit. That blocked each commit for minutes on a debug build nobody deploys, and made the deployed binary constantly drift from HEAD (forcing a manual release rebuild to re-sync). The auto-bump was redundant: build.rs already appends a unique "+<commit_count>" suffix (git rev-list --count HEAD) to every build, so each commit is uniquely identifiable without churning the base version. Now the hook only runs cargo fmt (+ stages reformatting). The base version is bumped deliberately at release time. Updated RELEASING.md accordingly. Installed the new hook into .git/hooks/pre-commit (this commit already ran it — fast, no bump). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
scripts/pre-commit and .githooks/* are shell scripts without a .sh extension, so the *.sh rule didn't cover them. On a Windows checkout (core.autocrlf=true) they become CRLF, and copying scripts/pre-commit into .git/hooks then yields a `#!/bin/bash\r` shebang that breaks the hook. Pin them to eol=lf, same as the other shell scripts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The serve-mode KB refresh loop previously did a full `git pull --ff-only` only every KB_PULL_INTERVAL_SECS (default 900s), so a pushed KB edit took up to ~15 min to become searchable in the cloud. Now the loop cheaply polls the remote HEAD every KB_POLL_INTERVAL_SECS (new, default 30s) via `git ls-remote origin <branch>` — ref advertisement only, no object transfer — and performs the real pull + incremental reindex only when the remote SHA actually moved. A pushed edit propagates in ~seconds instead of minutes. KB_PULL_INTERVAL_SECS (default 900) is retained as a safety-net: it forces a full pull at least that often even when the cheap poll saw no change or ls-remote failed, self-healing a missed poll. ls-remote uses the stored `origin` remote so the PAT never lands on argv. No codesearch core (Rust) changes — trigger lives entirely in deployment glue where git already runs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…-push guard The local pre-push guard scans tracked files for customer/vendor identifiers and flagged the bare platform name "aprimo" (as mount `cloud/aprimo` and in prose) across README, the remote-mount test scenario, and both web-guard hooks. Replaced every occurrence with the neutral placeholder `example-dam`; no functional/code change. Line endings preserved (LF for scripts). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…cess-denied metadata.json's atomic write does write+fsync-tmp then fs::rename onto the existing file. On Windows, MOVEFILE_REPLACE_EXISTING fails with ERROR_ACCESS_DENIED (5) if anything (commonly AV/Search-indexer) has a momentary handle on the destination — much more likely to be hit under cargo test --lib --bins parallel load than in isolation. This affected index::manager::tests::force_reindex_stamps_model_when_metadata_has_only_schema_version (force_reindex_with_stores -> merge_metadata_atomic -> atomic_write_json), surfacing as an intermittent Access is denied (os error 5) panic on the metadata.json read immediately after force_reindex. Add is_transient_rename_error() (same raw-code classification as ServeState::is_db_locked_error in src/serve/mod.rs: 5/32/33, plus message fallback) and retry the rename up to 5x with a 20ms backoff before giving up. Non-transient errors still fail immediately.
fix: retry transient Windows rename errors in atomic_write_json
…cale-to-zero wakeups spawn_remote_discovery fired its first poll immediately on startup (poll-then-sleep), so restarting the local serve pinged every federated peer once just to fill the dashboard -- waking a scale-to-zero cloud peer for no real reason. The first discovery cycle now builds remote-project rows from config alone (no HTTP) and ships them with an empty refreshed_at map, so every federated peer renders stale '-' on startup; the first real /status refresh comes only from either the hourly cadence tick or an activity poke (a real federated tool call). Local repos are unaffected.
…-startup fix: defer TUI federated poll on startup to avoid spurious scale-to-zero wakeups
Finalize CHANGELOG for v1.2.0 (TypeScript SCIP + Protobuf indexing, remote-TUI auth, cloud OOM/read-only + index-cancellation + self-cleanup hardening). Update README: 17 tree-sitter languages, TypeScript find_impact backend, corrected TUI keybindings (n=force-reindex, l=reload). Bump version 1.1.42 -> 1.2.0 (minor: two new indexed languages + new auth path).
…X ours The release-PR squash-merge-base gotcha note recommended `git merge origin/master -X ours`, but the v1.2.0 release (PR #186) proved that is wrong: against the regressed merge-base, `-X ours` (the recursive/ort *option*) still runs a real three-way merge that treats both sides' content as additions, pulling master's stale lines in — a Frankenstein diff (src/mcp/mod.rs gained +333 stale lines on the attempt). The correct invocation is the merge *strategy*: `git merge -s ours origin/master`, which ignores master's tree entirely and keeps develop's content exactly (the desired result, since develop's tree already equals master's content in this scenario); the merge commit only records master as a parent so the merge-base advances. Confirmed on v1.2.0: develop->master PR #185 came back CONFLICTING; the throwaway release/v1.2.0 branch built with `git merge -s ours origin/master` produced an empty content diff and merged clean (#186).
docs: fix release merge-base guidance to use -s ours (strategy) not -X ours
…pped, in next release GitHub issue #162 closed as completed (2026-07-30). AGENTS.md open-item line flips from [~] to [x] to match. Niveau 1 (tree-sitter-proto chunking) shipped in #175 and will be in the next release; Niveau 2 (SCIP symbols -> find_impact) deferred pending a motivating .proto-heavy repo.
docs(agents): close #162 — protobuf Niveau 1 in next release
This repo lives at codesearch.git as a bare+working-tree hybrid (full checked-out tree + .git/index, but core.bare=true in .git/config). core.bare intermittently resets to true — VS Code's git integration rewrites .git/config on ref changes — and when it does, cargo's source fingerprinting aborts every build with 'did not expect repo ...\.git to be bare', breaking copy-to-common.ps1 -> build.ps1 -> cargo build. build.ps1 now forces core.bare=false right after Set-Location, before any cargo invocation. Idempotent and harmless for a normal (truly non-bare) checkout; non-fatal if git is unreachable.
fix(build): build.ps1 self-heals core.bare before cargo (no more 'did not expect repo to be bare')
) The 8GB hard cap (MAX_LMDB_MAP_SIZE_MB=8192) was too low for very large corpora — GitHub issue #189 shows a 1GB / 53k-file cargo-registry source with >1.2M chunks legitimately exceeding it, crashing after auto-resize exhausts ("already at max size 8192MB" → fatal MDB_MAP_FULL). - constants.rs: raise MAX_LMDB_MAP_SIZE_MB 8192→32768 (32GB). On 64-bit Linux/macOS the mapsize is just a VA reservation (free until written); on Windows the file may be pre-allocated but only to the grown size, which only happens on demand when MDB_MAP_FULL bites. - constants.rs: add max_lmdb_map_size_mb() reading the new CODESEARCH_MAX_LMDB_MAP_SIZE_MB env var (clamped to >= default), so operators with extreme corpora or Windows instances can tune the cap without rebuilding. - store.rs: route the 5 runtime cap comparisons (pin_map_size, resize_environment check+message, build_index, delete_chunks, insert_chunks_with_ids) through max_lmdb_map_size_mb(). The cap test is now env-aware (asserts against the resolved fn, not the const). Stage 1 of 3 for #189. Stage 2 adds the same auto-resize to PersistentEmbeddingCache (currently hardcoded 512MB, no resize).
🐛 fix: raise LMDB mapsize cap 8GB→16GB + PersistentEmbeddingCache auto-resize on MDB_MAP_FULL (#189)
…ed error messages
When the LMDB mapsize auto-resize cap is reached (7 sites: 4 in
vectordb/store.rs, 3 in embed/cache.rs), the error/warn messages said
'already at max size {}MB' or 'exceeds MAX_LMDB_MAP_SIZE_MB {}MB' but
never told the operator how to raise the cap. Appended '(set
CODESEARCH_MAX_LMDB_MAP_SIZE_MB to raise this cap)' to all 7 messages,
using backslash line-continuation per the repo's caller-facing-literal
convention (validated by tests/caller_facing_literals.rs - all 4 pass).
- CHANGELOG: renamed unreleased section 1.2.1 -> 1.2.4 (current pending version) and added the #189 fix entry (cap raise + cache auto-resize + error-message hint), alongside the existing build.ps1 entry. - README: documented the new CODESEARCH_MAX_LMDB_MAP_SIZE_MB env var in the Environment Variables table. PRs #187 and #176 (also merged since v1.2.0) were docs/AGENTS.md-only changes with no user-facing code impact, so intentionally have no CHANGELOG entries.
…only, keep develop content)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Patch release rolling up everything merged to
developsince v1.2.0:MDB_MAP_FULLcrash on large corpora (>1.2M chunks) — raised the LMDB auto-resize hard cap 8GB→16GB with a newCODESEARCH_MAX_LMDB_MAP_SIZE_MBruntime override, added the same auto-resize to the persistent embedding cache (previously silently degraded to WARN-only cache misses on its own 512MB cap), and made both stores' cap-reached error/warning messages name the env var that raises it.build.ps1self-healscore.bare=falsebefore invoking cargo (PR fix(build): build.ps1 self-heals core.bare before cargo (no more 'did not expect repo to be bare') #188) — fixes intermittent build breakage on this bare+working-tree hybrid checkout.Changes
src/constants.rs,src/vectordb/store.rs,src/embed/cache.rs— mapsize fatal crash #189 fix (cap raise, cache auto-resize, error-message hints)build.ps1— core.bare self-healCHANGELOG.md,README.md— docs for the aboveTesting
cargo check --lib --bins,cargo clippy --all-targets -- -D warnings,cargo test --lib --binsall green (QC gate passed on every push in this chain)Checklist