Andrey Avtomonov fd18caa26a fix(cli): own a dedicated git repo at the project dir when nested in an enclosing repo (#282) ... GitService.initialize() used checkIsRepo(), which is true whenever the project dir sits anywhere inside a git working tree. So when a ktx project lived in a subdirectory of an enclosing repo, ktx skipped `git init` and silently adopted the enclosing repo as its store. Every ktx relative path assumes the project dir IS the working-tree root. During ingest, wiki/SL pages are written through a session worktree (whose root is the worktree dir, so the page is recorded at repo-relative `wiki/global/<key>.md`) and then squash-merged into the main worktree. With an adopted enclosing repo, the main worktree's root is the enclosing git root, so the merge wrote the page to `<gitRoot>/wiki/global/` — outside the project dir. reindex scans `<projectDir>/wiki/global/`, found nothing, and wiki_search silently returned empty (knowledge_pages = 0) even though ingest reported success. Detect the project dir's own root with checkIsRepo(IS_REPO_ROOT) and initialize a dedicated repo there unless the project dir is already a repo root. This keeps adopting a user-created repo when the project dir IS that repo's root, fixes the silent wiki/SL/memory divergence at its source for every writer, and stops ktx from committing its scaffold into the user's enclosing repo. Regression tests cover both layers: a project nested in an enclosing repo gets its own .git (and the enclosing repo stays untouched), and a wiki page written through a session worktree + squash-merge lands in the project dir and is discovered by reindex.		2026-06-09 23:37:24 +02:00
..
cli	fix(cli): own a dedicated git repo at the project dir when nested in an enclosing repo (#282)	2026-06-09 23:37:24 +02:00