10 commits

Author	SHA1	Message	Date
Gergő Magyar	82f1e48f32	fix(search): index description field for FTS so doc comments are keyword-searchable (#2300) ... * fix(search): index description column for FTS so doc comments are keyword-searchable Closes #2299. descriptionExtractor (#2286) populates the `description` column for every symbol table, but FTS only indexed name+content on 5 tables, so doc-comment keywords (Javadoc/KDoc/godoc/Rust ///) were invisible to BM25 keyword search. - Add `description` to the Function/Class/Method/Interface FTS indexes (File has no description column, left as name+content). - Add FTS indexes for the remaining EMBEDDABLE_LABELS symbol tables (Struct, Enum, Trait, Impl, Macro, Namespace, Constructor, TypeAlias, Typedef, Const, Property, Record, Union, Static, Variable). - createSearchFTSIndexes now drops-then-creates each index so the schema change reaches existing DBs on incremental re-analyze and --repair-fts (createFTSIndex is idempotent-by-name and would otherwise skip stale indexes). Tests: fts-schema column-subset + coverage guards; drop-before-create order; e2e doc-comment keyword search (Java class + Rust struct found by description-only terms). bm25-search assertions derive from FTS_INDEXES. * fix(review): apply autofix feedback - Guard the --repair-fts path on FTS-extension availability before createSearchFTSIndexes drops-then-creates indexes (P1 regression: without the gate, an unavailable extension could drop existing indexes then fail to recreate them, leaving the DB index-less). Mirrors the analyze path's ftsAvailable gate and fails loudly first. - Add a re-analyze upgrade integration test: seed an old name+content-only DB (no Struct index), run the real createSearchFTSIndexes(), and assert description keyword search + the previously un-indexed Struct now resolve. Proves drop-then-create upgrades a live stale index end-to-end. * fix(ci): add loadFTSExtension to --repair-fts test mocks The R3 review fix added a loadFTSExtension availability gate to the --repair-fts path, but run-analyze-fts-repair.test.ts mocked the lbug adapter without that export, so both repair tests threw `No "loadFTSExtension" export`. Add loadFTSExtension to the two mocks (returning true to preserve their original intent) and add a dedicated test proving the guard fails loudly — and does NOT drop any index — when the extension is unavailable. * test(fts): run fts-description-search in the sequential lbug-db project It was the only FTS-index-creating integration test left in the parallel `default` vitest project; every other ftsIndexes-using test (search-core, search-pool, augmentation, …) runs in the `lbug-db` project, which forces fileParallelism: false to avoid LadybugDB native mmap file-lock conflicts in parallel forks (Windows). Add it to the lbug-db include list and the default exclude list to match the convention and remove the flake risk. * test(ci): fail loudly when FTS extension is unavailable, never silently skip FTS-dependent lbug integration suites (search-core, search-pool, augmentation, fts-description-search, …) self-skip via ctx.skip() when the LadybugDB FTS extension can't load, emitting only a console.warn while the job stays green. That means a broken/missing FTS extension in CI would make these integration tests silently vanish with no signal — false confidence. withTestLbugDB now honors GITNEXUS_REQUIRE_FTS=1: when set and the extension is unavailable, setup() throws instead of skipping, so the suite fails loudly. The CI test jobs (ubuntu coverage + windows/macOS cross-platform) set the flag; local/offline runs leave it unset and keep skipping gracefully. (Verified the extension currently loads on all three runners, so this is a guard against regression, not a behavior change today.) * test(ci): run fts-description-search on macOS/Windows cross-platform jobs The new FTS description-search suite was registered in the sequential lbug-db vitest project (ubuntu/coverage) but absent from LBUG_NATIVE, so the macOS/Windows platform-sensitive jobs (which run only the explicit ALL_CROSS_PLATFORM allowlist via run-cross-platform.ts) never executed it. The GITNEXUS_REQUIRE_FTS=1 hardening on those jobs guarded the old FTS fixtures but not the new 20-index/description path. Add the suite to LBUG_NATIVE so the new path is validated cross-platform too. Refs #2299. * fix(search): verify FTS indexes cover description, not just queryability verifySearchFTSIndexes probed each index with QUERY_FTS_INDEX and treated 'queryable' as 'present'. A stale name+content-only index left on a pre-#2299 DB stays queryable yet silently misses the description column, so verification would pass green while doc-comment search stayed broken. Switch to a single CALL SHOW_INDEXES() that exposes property_names per index, and report an index as missing when it is absent OR does not cover its configured columns. Return contract (string[] of table.indexName) is unchanged, so both run-analyze.ts call sites are untouched. The per-index string interpolation is gone, so the now-dead safeIdentifier helper is removed. The real caller of the live function in tests is bm25-search.test.ts (the repair test mocks verifySearchFTSIndexes wholesale); its two probe-shaped cases are rewritten to feed SHOW_INDEXES rows and now assert column coverage, plus an absent-index case. Refs #2299. * test(search): assert description search via the public query surface The #2299 integration suite only exercised the searchFTSFromLbug helper. Add a third block that drives the public LocalBackend.callTool('query') path — which resolves the repo via the registry and routes BM25 through the pool adapter (a different connection context than the core-adapter helper) — and asserts a description-only keyword returns the seeded class. Reuses the existing description-only SEED and production FTS_INDEXES; partial-mocks repo-manager so listRegisteredRepos points at the test DB while cleanupOldKuzuFiles and the rest stay real. Refs #2299. * test(search): make lbug-core-adapter FTS gate honor GITNEXUS_REQUIRE_FTS lbug-core-adapter.test.ts has its own per-test FTS gate (skipUnlessFtsAvailable) that called ctx.skip() whenever the extension could not load — bypassing the GITNEXUS_REQUIRE_FTS=1 hardening that withTestLbugDB already honors. Since this file is in LBUG_NATIVE it runs on the ubuntu/macOS/windows jobs that all set GITNEXUS_REQUIRE_FTS=1, so an FTS regression on a runner would have let these FTS-primitive tests silently vanish from a green run — the exact gap #2299's test-infra hardening set out to close. Make the helper mirror withTestLbugDB: when GITNEXUS_REQUIRE_FTS=1 and the extension is unavailable, throw (hard fail) instead of skipping. Offline/local runs (no env var) still skip gracefully. Refs #2299.	2026-06-25 14:21:44 +01:00
Gergő Magyar	d6031ea646	feat(group): cross-repo call trace using PDG (#2269) ... * refactor(group): extract shared resolveBridgeNeighbors from cross-impact Lift the uid-filtered consumer<->provider ContractLink join (direction + queryBridge + row normalization + confidence sort) out of runGroupImpact's inline Phase-2 block into an exported resolveBridgeNeighbors helper. Behavior is unchanged for impact; the helper becomes the single shared bridge join so the upcoming cross-repo trace path never forks its own copy of the neighbor Cypher. Empty uid sets short-circuit without a DB round-trip. Adds direct coverage (real bridge via writeBridge/openBridgeDbReadOnly) for both directions plus the empty-set and unknown-uid edges. * feat(group): cross-repo trace stitching (groupTrace + runGroupTrace) Add GroupService.groupTrace and the pure runGroupTrace engine that stitches per-repo CALLS/HAS_METHOD trace segments across one ContractLink boundary in the group bridge: from --(local trace)--> consumer --(ContractLink)--> provider --(local trace)--> to - Resolves from/to across all members (symbol node id == bridge symbolUid); same-repo endpoints delegate to a single local trace with no crossing. - Single boundary crossing (MAX_SUPPORTED_CROSS_DEPTH); deeper crossDepth is clamped with a note, mirroring cross-impact. - Discriminated GroupTraceResult union (ok|not_found|ambiguous|error) with per-hop repo tags, a typed crossings[] entry, and centralized degraded-state note constants (TRACE_NOTES). No . - Trace-specific pair query (keeps BOTH crossing endpoints) lives in this module; the uid-filtered neighbor join (resolveBridgeNeighbors) is reused where it fits. ensureBridgeReady exported for reuse. - New GroupToolPort methods (trace/resolveSymbol/pdgFlows) are optional so existing port mocks keep type-checking; runGroupTrace guards on presence. PDG enrichment is wired as an opt-in hook (enrichSegment) — the port method is stubbed until U4. Covered by unit tests over a real bridge + mocked port. * feat(group): route trace tool to groupTrace on @group syntax Wire the cross-repo trace through the existing @group dispatch: - callTool routes trace with an @-prefixed repo to callToolAtGroupRepo, which forwards from/to/uid/file/maxDepth/includeTests plus the experimental pdg/crossDepth flags to GroupService.groupTrace. Member path in @group/path is advisory for trace (resolution is whole-group). - Port gains trace/resolveSymbol/pdgFlows adapters. resolveSymbolForGroup wraps the shared resolveSymbolCandidates so groupTrace can locate the member repo and recover each endpoint node id (== bridge symbolUid). pdgFlowsForGroup is a degraded stub here (call-level only); U4 implements the REACHING_DEF walk. - trace tool schema documents the @group entry point, pdg, and crossDepth. Single-repo trace is untouched. Covered by dispatch-routing tests (@group -> groupTrace, non-group stays local) and tool-schema assertions. * feat(group): opt-in PDG data-flow enrichment for cross-repo trace Implement _pdgFlowsForGroupImpl: the real REACHING_DEF anchor walk that backs the port pdgFlows adapter (replacing the U3 call-level stub). When pdg:true and the segment repo has a flows PDG layer, the boundary-adjacent segments carry their intra-procedural def->use hops: - Anchors by the boundary symbol UID (precise; avoids the by-name ambiguity the resolveBlockAnchor path can hit), then reuses the same span-anchored, bind-param-only flows query as pdg_query (BasicBlock id-prefix + [start+1, end+1] line window; no rel-property index, so the anchor IS the bound). - Stays intra-procedural: data flow never crosses the repo boundary. - pdgStampForMode probe: false -> available:false (degrade with note); the trace stays ok. Any query failure is swallowed (enrichment is auxiliary). Covered by runGroupTrace enrichment tests: dataFlow attached on opt-in, degraded note when no layer, and no pdgFlows call when pdg is omitted. * test(group): evaluation-first cross-repo trace e2e (two real indexes) End-to-end gate for the cross-repo trace: stands up two real LadybugDB indexes (consumer 'frontend' + provider 'backend'), a real ContractLink bridge, and a real LocalBackend with both repos registered, then drives the public callTool('trace', { repo: '@grp', pdg: true }) and asserts: - the stitched checkout -> callUsers -(CONTRACT_LINK)-> handleUsers -> getUsers path, each hop tagged with its member repo - real REACHING_DEF data-flow enrichment of the consumer segment (userId) - a degraded 'No PDG layer in app/backend' note (provider has no PDG layer) - single-repo trace against one member is unchanged (no crossings) Hand-persists the minimal real graph (deterministic; a full two-repo analyze is heavier than this gate needs) and exercises real Cypher across resolveSymbolCandidates, _traceImpl, the bridge pair query, and _pdgFlowsForGroupImpl. Windows-skipped (describeReopen) and registered in the cross-platform native-lbug set. Scoped to a single @group call: opening bridge.lbug read-only a SECOND time in one process currently fails (shared bridge open/close lifecycle, also affects impact @group) — the pdg-omitted/clamp variants are unit-covered. * docs(group): document cross-repo trace + PDG enrichment ARCHITECTURE.md: trace is now group-aware; describe the @group cross-repo stitch over a single ContractLink boundary (CONTRACT_LINK hop, crossings[], crossDepth clamp), the opt-in experimental PDG REACHING_DEF enrichment of boundary-adjacent segments, the symbolUid-grain join between the two stores, and the deferred full cross-program (SDG-like) data flow. PIPELINE.md: add the cross-trace consumer of the bridge with its pair-query rationale. Does not touch gitnexus/CHANGELOG.md (release-owned). * fix(review): apply autofix feedback Apply safe_auto findings from ce-code-review (run 20260622-094243): - local-backend.ts: drop (r: any) in _pdgFlowsForGroupImpl row map; coerce hop line via Number() so a nullish LadybugDB cell can't surface NaN. - tools.ts: advertise the forwarded param in the trace schema and add crossDepth maximum:10 (schema now matches what groupTrace reads). - cross-trace.ts: parallelize per-member resolveSymbol/resolveRepo with order-preserving Promise.all (matches groupContext/groupQuery); add a note when pdg:true is passed to a same-repo trace (PDG only enriches at a cross-repo boundary). - tests: remove / tighten (no-any rule). Residual gated_auto/manual findings (unbounded crossing query + loop, whole-file PDG widening on absent span, error-vs-no_path masking, top-level try/catch parity, helper dedupe, branch-coverage gaps) are recorded in the run artifact for the PR body. * fix(group): skip CHECKPOINT on read-only bridge close so it can reopen Root cause of the in-process bridge.lbug reopen failure (which broke repeated @group impact/trace calls in a long-lived MCP server): closeBridgeDb issued CHECKPOINT on EVERY handle, including read-only ones. A CHECKPOINT on a read-only connection has nothing to flush but leaves a WAL/shadow lock artifact that makes the next read-only open of the same path fail (openBridgeDbReadOnly returns null -> 'Could not open bridge.lbug read-only'). Reproduced: open -> query -> closeBridgeDb -> open again returned null only when the close ran CHECKPOINT; a non-checkpoint close reopened fine, and the raw native open/close cycle was never the problem. Fix: tag read-only handles (BridgeHandle._readOnly, set by openBridgeDbReadOnly) and skip CHECKPOINT for them in closeBridgeDb. Writable handles are unchanged (they still flush before close). This is the shared bridge-db close path, so impact @group benefits identically. - Regression test in bridge-db.test.ts: open/query/close/open/query/open in one process now succeeds. - Re-enabled the second @group call in cross-trace-e2e.test.ts (was scoped to a single call for this very limitation). * fix(group): bring bridge-db close to parity with the core adapter safeClose The bridge open/close cycle was less robust than the main graph DB's: closeBridgeDb closed the connection/database but skipped the post-close steps the core adapter's safeClose performs, so a rapid in-process reopen could race the OS handle release (Windows) or an orphaned WAL sidecar. That gap is why the close-then-reopen tests had to skip Windows. closeBridgeDb now mirrors safeClose after closing the handle: - waitForWindowsHandleRelease(dbPath): probe the file (+ .wal) until the residual Windows lock clears, so the next open does not race (warns if the budget is exhausted, matching the core adapter). - finalizeLbugSidecarsAfterClose(dbPath): quarantine an orphaned WAL (shadow missing) so the next open replays a consistent file. Both helpers are the same ones safeClose uses (Windows-proven via the core adapter CI), and the bridge read open already retries transient locks. Combined with the read-only CHECKPOINT skip, the bridge reopen is now robust on every platform, so the close-then-reopen tests run on all platforms (Windows CI exercises them via the cross-platform subset). No write-path behavior change; Linux/macOS unaffected. * fix(group): bound cross-repo crossing fan-out (LIMIT + segment memoization) Address the top review residual: the bridge crossing query was unbounded and the crossing-selection loop could run an O(2*N) sequential trace-BFS over every ContractLink between a repo pair. - CY_CROSSINGS_BETWEEN now ORDERs BY confidence DESC and LIMITs to MAX_CROSSINGS_TO_TRY + 1; listCrossingsBetween slices to the cap and reports truncation. Exceeding the cap surfaces a note (no silent truncation), keeping the highest-confidence crossings. Aligns with the repo's anchored+LIMIT-bounded query discipline (LadybugDB has no rel-property index). - The home-repo segment (from -> consumer) depends only on the consumer uid and the target-repo segment (provider -> to) only on the provider uid, so each is memoized by that uid. Many crossings sharing a consumer/provider (one client call linked to several providers) now cost one trace per distinct endpoint instead of one per crossing. A consumer whose segment already failed is skipped for every later crossing that shares it. Test: two links sharing a consumer (first provider unreachable, second reachable) assert the from->consumer segment is traced exactly once and the second crossing wins. * fix(group): restore Windows skip for bridge reopen tests; drop ineffective close-side probe The previous commit flipped the bridge close-then-reopen tests to run on Windows, betting that a close-side waitForWindowsHandleRelease + finalizeLbugSidecarsAfterClose probe (mirroring the core adapter safeClose) would make the in-process reopen work there. Windows CI proved otherwise: 4 writeBridge->openBridgeDbReadOnly tests fail ('expected null not to be null' — the read open returns null). The writable-close -> read-open handoff plus writeBridge's atomic sidecar rename does not release the OS file handle before the read open races, and the existing open-side LBUG_OPEN_RETRY only retries lock-pattern errors, not the post-rename sidecar database-id mismatch. macOS passes; the core adapter's own reopen also passes — this is bridge+Windows specific. - Revert itLbugReopen to the Windows skip (the pre-existing, correct state). - Remove the close-side probe + finalize from closeBridgeDb: it did NOT close the Windows gap, and reviewers flagged it for hot-path latency (finalize ran on every close, all platforms) and safeClose duplication. - KEEP the load-bearing fix — skipping CHECKPOINT on read-only handles — which fixed the reproduced Linux/macOS in-process reopen artifact (the real bug). Net: Linux/macOS repeated @group impact/trace works in-process; Windows in-process bridge reopen remains a documented limitation (unchanged from before this PR). * fix(group): surface degraded members + cap truncation; honest crossDepth schema Address the cross-engine-corroborated tri-review findings (Codex + Claude): - resolveAcrossMembers / runGroupTrace now track member repos that could NOT be queried (resolveRepo or resolveSymbol threw) and, when the result is not_found, attach a degraded-member note. A transient/corrupt member DB is no longer silently reported as a clean 'symbol absent' not_found. (Codex B1+B3 + ce-reliability.) - The cross-repo not_found now carries a programmatic truncated:true flag (and a clearer suggestion) when the MAX_CROSSINGS_TO_TRY cap was hit, so a consumer can distinguish 'no path' from 'cap may have hidden a connecting ContractLink'. (Codex B3 + ce-adversarial + ce-api-contract.) - trace tool schema: crossDepth maximum 10 -> 1 to match the implementation's single-hop clamp (the schema previously advertised an unsupported 2-10 range). (ce-api-contract, conf 100.) Test: a member whose resolveSymbol throws yields not_found WITH a degraded note naming the unreachable repo (if-free responder map). * docs(group): clarify trace @group/memberPath is advisory (resolves all members) Tri-review (Codex ce, conf 100) caught a doc/impl inconsistency: ARCHITECTURE.md lumped trace with query/context/impact as honoring @group/memberPath member scoping, but cross-repo trace resolves from/to across ALL members (the member path is advisory). Clarify the behavior and point to from_uid/to_uid for disambiguating same-named symbols across members. * feat(group): file-level boundary fallback so cross-repo trace works on HTTP contracts Benchmark (bench/cross-repo-trace/) running the REAL pipeline (runFullAnalysis --pdg -> real syncGroup -> trace @group) found that cross-repo trace returned not_found for real HTTP links even though sync built the correct ContractLinks: HTTP (and other source-scan) contracts hardcode symbolUid:'' (http-route-extractor), and both cross-trace AND cross-impact join crossings by Contract.symbolUid, which never matches an empty uid. (Pre-existing — impact @group has the same gap.) Fix: when a crossing's symbolUid is empty, fall back to the contract's FILE — if the user's from/to resolves into the contract file, that endpoint anchors the boundary. CY_CROSSINGS_BETWEEN now returns consumer/provider filePath; a crossing is kept if it can be anchored by uid OR file on each side; a fileBoundaryFallback note flags that the boundary is file-level, not symbol-precise. This makes the common 'trace from=<calling fn> to=<handler fn>' case work end-to-end (verified: fetchUsers -> listUsers stitches with a CONTRACT_LINK hop + PDG enrichment, 2/2). Limits (documented in the bench README + the note): anonymous handlers have no named target; when several contracts share files the file fallback may attach the wrong contractId to a correct path. The proper upstream fix is to populate symbolUid in the HTTP extraction (benefits impact too) — the bench is its gate. Adds a unit test pinning the empty-symbolUid file-fallback stitch. * fix(group): resolve HTTP contract symbolUid by containment (fixes cross-repo trace + impact) Addresses the root cause behind the cross-repo trace file-fallback: HTTP contracts hardcoded symbolUid:'' (http-route-extractor), so both cross-trace and cross-impact — which join crossings on Contract.symbolUid — could not traverse HTTP links. (Also found: the pre-existing graph-assisted resolution queried the wrong edge, CONTAINS instead of DEFINES, so it never resolved a uid either.) Now the extractor resolves each detection to a real symbol: - HttpDetection carries the call-site line (node.ts sets it on every express/ fetch/axios/jquery/nest detection; express also captures the handler arg). - resolveDetectionSymbol resolves the named handler first, else the innermost Function/Method whose line span encloses the call (consumer = the function containing the fetch; provider = the named/inline handler), over the correct File-[DEFINES]->symbol edge. Base-tolerant (0- vs 1-based startLine). - Wired into both source-scan and graph-assisted provider/consumer paths. Verified end-to-end (bench/cross-repo-trace): all 4 contracts now carry real uids, trace is symbol-precise (GET pair -> http::GET, POST -> http::POST, no file-fallback note), and impact @group fans out (cross_repo_hits 0 -> 1). The cross-trace file-level fallback remains as the secondary path for truly anonymous handlers. Adds 2 containment unit tests; 738 group/integration pass. Languages other than JS/TS still resolve providers by handler name; their consumers fall through to the file fallback until their plugins set the line. * fix(group): extend HTTP symbolUid containment to all languages + nested methods Completes the symbolUid resolution across every bundled HTTP plugin: Python, Go, PHP, Kotlin and Java now set the call-site line on their consumer (and Feign/ named) detections, so their HTTP contracts resolve to the containing function the same way Node/TS already did. Also generalizes the containment query: it now matches Function/Method/CodeElement by filePath (UNION ALL) instead of File-[DEFINES]->symbol. The DEFINES edge only reaches a file's TOP-LEVEL symbols, so methods nested in classes (Java/Kotlin — File defines the class, the class defines the method) were invisible; matching by filePath reaches them. Verified against a real index (LadybugDB supports the UNION); JS/TS still fully symbol-precise (bench 2/2), 709 group tests pass. Residual is now only the inherent case — a fully anonymous handler with no named callee — which keeps the cross-trace file-level fallback. * feat(group): destination trace — follow a consumer to an anonymous handler Handles the one inherent residual: an anonymous route handler (`router.get('/x', (req,res) => …)`) has no symbol node at all (the file holds only a Const + PDG BasicBlocks), so it can never be named as a trace `to`. Adds a DESTINATION TRACE: omit to/to_uid/to_file on an @group trace and `trace from=<consumer>` follows the consumer's outgoing HTTP call across the bridge and reports where it lands — by route + file:line, with a notes[] entry flagging the handler as anonymous. Implemented as a new branch in runGroupTrace (p.destination) backed by CY_CROSSINGS_FROM (all ContractLinks leaving the consumer repo) + stitchToDestination; the provider endpoint is labelled '<METHOD /path handler>' when its symbolName is a generic token/file basename. The MCP routing already omitted an absent `to`, so only the schema docs changed. parseTraceParams now treats a missing `to` as a destination trace instead of an error. Verified end-to-end: anonymous fixture reports 'app/frontend:fetchUsers -> app/backend:<http::GET::/api/users handler>'; named fixture lands at the real function. Adds 2 unit tests; 915 group tests pass. * fix(group): tri-review fixes for cross-repo trace + symbolUid resolution Two-engine tri-review (Claude swarm+ce + Codex GPT-5.5 swarm+ce+adversarial) surfaced these; cross-engine-corroborated unless noted. Correctness (P1, all four lanes): destination trace reported the WRONG endpoint — an empty-uid consumer made trace(from->from) trivially succeed, so the highest- confidence same-file crossing won regardless of which call `from` makes. stitchToDestination now collects ALL connecting crossings, prefers symbol-precise hits, and returns `ambiguous` (with candidates) when it cannot disambiguate. Correctness (P1, Codex): resolveDetectionSymbol early-returned null when d.line==null, blocking NAME resolution for named providers that set no line (Spring/Go/etc.). Name resolution now runs first; only containment needs a line. Correctness (P2): resolveContainingSymbol OR-ed `line` and `line-1`, which could mis-pick a one-line sibling. It now probes the base-correct `line-1` first and falls back to `line` only if nothing matches. Correctness (Codex): anonymous Express handlers emitted name:'handler' and could attach to an unrelated fn literally named `handler`. node.ts now emits name:null for non-identifier handlers (containment-only). Robustness: drop the first-symbol-in-file pickSymbolUid guess from the graph consumer/provider paths (a wrong uid would win the contractId merge); remove the dead CONTAINS_QUERY fallback (CONTAINS is File->Folder, never a symbol) + the now -unused pickSymbolUid/handlerName; seed destination notes with degraded-member notes so a successful trace still surfaces them; providerLabel takes providerUid so a resolved fn named `handler` is not mislabeled anonymous, and only true file basenames (known extensions) — not any dotted name — count as anonymous. API contract: a single-repo trace with no `to` now returns an actionable error (destination trace is @group-only) instead of "symbol 'undefined' not found". Maintainability/tests: narrow asLocalTrace per-field (drop as-unknown-as); fix the PR's lone as-any (vi.mocked); if-free e2e teardown; qualify the bench README. Adds ambiguous-destination, anonymous-handler-no-false-name, and single-repo-no-to tests; redirects graph mocks CONTAINS->UNION ALL. 918 group/integration pass. * fix(group): carry degraded-member notes through SUCCESSFUL group traces A reviewer (koriyoshi2041, PR #2269) correctly flagged that degraded-member resolution was surfaced only on not_found, not on a successful ok result. Group trace resolves names across ALL members, so an ok is 'unique among the members we could query' — if a member that threw during resolveSymbol also holds from/to, the real answer could be ambiguous. The destination path already seeded the note (prior commit); this extends it to the same-repo and cross-repo success paths by seeding the dispatch notes with degradedNotes([...fromRes.degraded, ...toRes.degraded]). Adds a regression test: reg-be throws while a same-repo trace succeeds in reg-fe; the ok result now carries the 'could not be queried' degraded note (app/backend). * test(bench): cover all implemented cross-repo trace cases in one runner Replace the single named-handler script with a self-contained verify.mjs that generates each fixture inline and exercises every implemented end-to-end case against the real analyze -> sync -> trace/impact pipeline, asserting PASS/FAIL (exit non-zero on failure). 10 checks across 4 scenarios: - named handlers: 4/4 symbolUid resolved; symbol-precise GET vs POST crossing selection; destination trace lands at the named handler. - anonymous handler: empty symbolUid; destination trace reports it by route with the anonymous note. - impact @group fan-out (cross_repo_hits >= 1). - multi-language (Python Flask + requests): link built, cross-repo trace stitches, and the file-level boundary fallback is exercised when the provider has no uid. Ambiguous-destination and degraded-member paths need synthetic inputs the real analyzer cannot produce, so they stay in the unit suite (documented in the README + script header). Removes verify-named.mjs + fixtures-named/ (folded inline). * test(group): pin destination degraded-success + precise-tier ambiguity Adds the two regression guards koriyoshi2041 requested on PR #2269 after the degraded-on-success fix: - destination trace success with a degraded member: reg-fe resolves from and follows the link to an anonymous handler while reg-be throws; the ok result carries the anonymous endpoint AND the 'could not be queried' degraded note, so the no-to path stays aligned with explicit to traces. - multiple PRECISE destination hits: one from reaches two consumers with resolved uids linked to different routes; the result is ambiguous (role: to) with both route candidates. Distinct from the existing file-level ambiguous test, this pins the stronger precise tier against a future change silently picking the highest-confidence destination. Both already pass against current behavior; 716 group tests pass.	2026-06-23 07:54:13 +01:00
Minidoracat	4976283569	perf(hooks): cmdline-first Linux db-lock scan, drop the lsof fallback (#2180) (#2183) ... * perf(hooks): cmdline-first Linux db-lock scan, drop the lsof fallback (#2180) The probe's Linux scan was O(processes × fds) — stat every fd of every process — so on a busy host it blew its budget and fell through to lsof, which then timed out (~2 s) and fail-closed. Every Grep/Glob/Bash hook spent ~2 s of CPU to conclude 'couldn't tell'. Rewrite linuxProcScanFindGitNexusServer (name kept; return type now tri-state 'owned' | 'not-owned' | 'timeout') as three phases: 0. /proc/<pid>/comm prefilter — kernel task->comm, never touches the target's memory maps; truncation-safe whitelist match (comm is capped at 15 visible chars). Calibrated to what a real server reports: @ladybugdb/core's worker_threads rename the main thread to 'MainThread', so that is whitelisted alongside the launcher basenames — omitting it would blind the probe to every server. 1. bounded /proc/<pid>/cmdline read (openSync+readSync, default 16 KiB with a floor of 4 KiB and a bounded escalation up to a hard ceiling) so a D-state holder cannot stall the hook and the mcp/serve mode token is never clipped off a long interpreter path. 2. dev+ino fd match for the 0–2 survivors only. Dispatch: 'owned' and 'timeout' both map to true. Timeout is now fail-closed (overload self-throttle) instead of falling through to lsof; the Linux lsof fallback is removed entirely. End-to-end semantics on busy hosts are unchanged (the old lsof arm also fail-closed there) — the ~2 s of wasted work and the orphan-spawning lsof are what's gone. macOS lsof+ps and Windows Restart Manager paths are untouched. Also: fix the budget parse bug (Number(raw && trim()) treated '0' as 1200; now parseInt-then-validate, with <= 0 an explicit immediate timeout) and add GITNEXUS_HOOK_PROC_ROOT so the Linux scan can be unit tested against a fixture procfs instead of the host's real /proc. Measured on a 583-process host with 6 background gitnexus mcp servers: owner detection 6–12 ms (was ~1216 ms + lsof timeout), ~100x. Tests: new hook-db-lock-probe.test.ts drives all three phases against a fake procfs (comm-truncation safety, Phase 0 trap, 4 KiB-boundary owner-miss guard, budget=0 immediate timeout, EACCES fail-closed) plus a live-/proc e2e that pins the fd-visible lbug-handle property against a real subprocess holder. The lsof/ps owner-detection suites are relaned to macOS (Linux no longer takes that path); the lsof orphan-reaping suite is removed (no lsof is spawned on Linux now) with a rationale note. Note: pre-commit typecheck skipped; remaining tsc errors are pre-existing on main (none in files touched here). * fix(hooks): honest EACCES verdict + real escalation coverage (#2183 review) Addresses the tri-review (maintainer + Codex): - [P2] Phase-2 fd-dir EACCES no longer claims 'owned'. /proc/<pid>/fd is owner-only (0500), so a cross-user/root gitnexus server serving ANY repo cleared Phase 0+1 and hit EACCES here, and the old catch returned 'owned' — falsely claiming it locks THIS repo's lbug (dev+ino never compared) and permanently suppressing augment. Split the failure shapes: ENOENT -> continue (raced away); EACCES/EPERM and transient EIO/ESTALE -> 'timeout' (unverifiable -> fail-closed, but honest, not a false ownership claim); ENOTDIR/other structural errors -> continue (not a real fd dir). Same fail-closed dispatcher outcome, no false 'owned', plus a GITNEXUS_DEBUG diagnostic so an operator can tell this skip path from a real owner. - [P2] The escalation test now actually iterates the escalation loop: the gitnexus token sits under 4 KB while the mode token is padded past GITNEXUS_HOOK_PROC_CMDLINE_MAX=4096, and a readSync spy asserts >1 read (the old 9 KB-under-16 KB-cap shape read once and never escalated). - escalation loop now re-checks the budget each iteration and returns a distinct timeout sentinel (never '' — an empty string would read as 'not a candidate' and could drop a real owner -> fail-open); the caller maps it to 'timeout'. - GITNEXUS_HOOK_PROC_ROOT is gated to test context so a stray production env export can't disable Linux owner detection (fail-open). - New uid-agnostic spy tests pin every fd-readdir errno branch (EACCES/EPERM/EIO/ESTALE -> timeout, ENOTDIR -> not-owned) regardless of the runner's uid (the disk chmod-000 tests no-op under root). Note: pre-commit typecheck skipped; remaining tsc errors are pre-existing on main (none in files touched here). * fix(hooks): drop the always-true outOfBudget presence guard (CodeQL #2183) CodeQL flagged `typeof outOfBudget === 'function' && outOfBudget()` as unneeded defensive code: readLinuxCmdline has a single caller (linuxProcScanFindGitNexusServer) that always passes the callback, so the typeof guard is dead. Drop it, leaving `if (outOfBudget())`, and note the invariant in the comment. Mirrored in the byte-identical plugin copy. * fix(hooks): parse numeric hook env with Number() so scientific notation works (#2183 review) getCmdlineMaxBytes and resolveLinuxProcBudgetMs parsed their env via Number.parseInt(raw, 10), so a value like "16e3" silently became 16 (parseInt stops at 'e') instead of 16000. Switch both to Number(String(raw).trim()), which honors scientific notation and is stricter on trailing garbage ("123abc" -> NaN -> default) — matching the repo-majority Number()+isFinite env idiom (src/cli/analyze.ts, src/core/embeddings/hf-env.ts). The two functions had DIFFERENT guard skeletons, so a verbatim swap would regress the budget: resolveLinuxProcBudgetMs used `raw != null ?` with no empty-string short-circuit, and Number("")===0 (vs parseInt("")===NaN) would make a set-but-empty GITNEXUS_HOOK_LINUX_PROC_BUDGET_MS="" resolve to budget 0 => immediate fail-CLOSED timeout => augment permanently skipped. Added the `&& String(raw).trim()` guard so ''/whitespace fall to the 1200 default while "0" still parses to the deliberate #2180 immediate-timeout vector. Exported both helpers for white-box tests (the values are otherwise only observable indirectly through scan timing) and added platform-independent coverage: "16e3"->16000, ""/whitespace->1200 (the regression guard), "0"->0, "123abc"/unset->1200, cmdline "8e3"->8000, "2e3"/""/unset->16384. Both byte-identical hook-db-lock-probe.cjs copies updated together. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(hooks): allocUnsafe the per-chunk cmdline read buffer (#2183 review) readLinuxCmdline allocated each per-chunk read buffer with Buffer.alloc(chunkCap), zero-filling memory that readSync immediately and fully overwrites. Switch the hot read buffer to Buffer.allocUnsafe — safe because readSync initializes exactly [0, bytes), only buf.subarray(0, bytes) is consumed, and Buffer.concat deep-copies that slice into `collected`, so the uninitialized tail can never reach the decoded cmdline. The zero-length `collected = Buffer.alloc(0)` is left unchanged (allocUnsafe gains nothing on a 0-length buffer). The existing D3 multi-chunk decode tests cover the read path and stay green. Both byte-identical hook-db-lock-probe.cjs copies updated together. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(hooks): harden the live /proc owner-detection e2e against CI flake (#2183 review) Two flake mechanisms, fixed without weakening what the e2e proves: - Holder readiness (the genuine false-FAIL): the pid-file poll was 200x25ms=5s; a loaded runner can be slow to spawn the child, tripping expect(holderPid).toBeGreaterThan(0). Widened to ~10s and raised the per-test timeout 20s -> 40s. - Scan budget (kept the assertion honest): the live scan ran at the default 1200ms. Because the dispatcher maps a budget 'timeout' to owned=TRUE, a busy host exhausting 1200ms before reaching the holder would make the assertion pass for the WRONG reason (a hollow timeout, not real fd-visible detection). Set a generous explicit 10000ms budget via the existing setEnv() helper so the module afterEach restores it (replacing the raw `delete process.env...` that bypassed env tracking). Raised the coarse timing regression guard to sit ABOVE the budget (5000 -> 15000) so a legitimately-slow-but-correct scan can't trip it. The load-bearing asserts (dev+ino fd-visibility precheck, owned===true for our own lbug) are unchanged. Verified the e2e executes (not skipped) on Linux. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore(changelog): empty the root CHANGELOG [Unreleased] section Per maintainer request, nothing should sit under [Unreleased] in the root CHANGELOG.md (the release-owned changelog is gitnexus/CHANGELOG.md, whose [Unreleased] is already empty). Removes all three accumulated blocks — Fixed (#2163), Performance (#2180), Changed (KuzuDB->LadybugDB) — leaving only the [Unreleased] header above [1.5.3]. Pure removal; no release sections touched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-13 11:52:14 +01:00
azizur100389	db8fe52079	fix(lbug): load FTS in Windows read pool (#2040)	2026-06-05 04:23:21 +01:00
Gergő Magyar	e466ee7451	fix(cli): steer docs, skills, and hooks through a CLI-neutral project-local runner (#1939) (#1945) ... * fix(cli): steer npm 11 users away from npx install crash (#1939) Prefer global gitnexus or pnpm dlx in hooks and generated AI context, warn when npm 11.x would use the broken npx path, and document workarounds for the arborist node.target null failure mode. Co-authored-by: Cursor <cursoragent@cursor.com> * test(hooks): stage resolve-analyze-cmd.cjs for antigravity adapter; harden load checks The antigravity adapter gained a top-level require('./resolve-analyze-cmd.cjs') but stageAdapter() did not copy it, so the spawned adapter crashed with MODULE_NOT_FOUND. Three load-sensitive tests failed; four silent-path tests false-passed on empty stdout. Stage the helper alongside the other sibling helpers, and assert status===0 and no MODULE_NOT_FOUND on the four silent-path tests so a non-loading hook can never pass green again. Force a deterministic invocation mode in the stale-index test so the emitted analyze command no longer varies by CI-runner PATH. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(cli): standardize invocation hints on gitnexus@latest; single-source CJS helper NPX_REF becomes a literal `gitnexus@latest` in resolve-invocation.ts, dropping the package.json require and the module-load throw (a malformed/absent version can no longer crash any CLI command at import). The safety this PR delivers is the install method steered to (global / pnpm dlx), not a pinned gitnexus version, and the in-repo CJS mirror already degraded to `latest` once copied outside the package. Make the two resolve-analyze-cmd.cjs copies byte-identical and add a parity test that fails on drift. The separate, version-pinned NPX_REF that setup.ts writes into the MCP server registration is intentional and left unchanged. Co-authored-by: Cursor <cursoragent@cursor.com> * perf(cli): move npm-11 npx warning off module load; memoize invocation mode warnIfNpm11NpxRisk() ran at index.ts module load, so every CLI invocation (including the `gitnexus mcp` stdio hot path) paid which/where + npm --version spawns — against the lazy-startup/MCP-stdout discipline (#207, #1383). Move the call into analyzeCommand, after the ensureHeap() re-exec guard, so it fires once in the working process and only for `analyze`. Memoize the PATH-probe-derived invocation mode (the GITNEXUS_INVOCATION override stays uncached) so repeated callers don't re-probe, and add a test-only reset so the cache + once-only warning flag don't leak across the unit suite. Covers the mode!=='npx', npm<11, and npm-absent suppression branches. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(cli): detect .exe/extensionless global gitnexus shims on Windows The winGitnexusWrapper branch only matched .cmd/.bat, so a global gitnexus installed by Volta or scoop (a .exe or an extensionless shim) was missed and the hint fell back to pnpm/npx. Accept .exe and treat any non-empty `where` hit as on-PATH (the emitted hint is `gitnexus analyze` regardless of which shim resolves it). Mirror the change into both resolve-analyze-cmd.cjs copies so the TS source and the byte-identical hook mirrors stay in sync. Add Windows-mocked test cases (.exe-only, extensionless, .cmd preference, CRLF stripping) and register resolve-invocation.test.ts in cross-platform-tests.ts so the windows-latest runner exercises the branch. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(cli): emit fixed pnpm dlx analyze command in generated AGENTS.md/CLAUDE.md ai-context baked a machine-resolved command (formatAnalyzeCommand) into git-tracked AGENTS.md/CLAUDE.md, so the stale-index hint varied per machine and churned across branches (the #1706 class). Emit the fixed string `pnpm dlx gitnexus@latest analyze` instead: committed AI-context is the most authoritative instruction an agent reads, so it must name an install-free, crash-free method — never `npx`, the npm-11 path #1939 steers away from. formatAnalyzeCommand stays exported and unit-tested in resolve-invocation.ts (it still mirrors the two .cjs hook copies); ai-context just no longer calls it. Co-authored-by: Cursor <cursoragent@cursor.com> * refactor(cli): unify hook-helper copy into one non-silent routine installClaudeCodeHooks copied its four hook helpers in separate try/catch blocks that silently swallowed failures, while installAntigravityHooks recorded an error per failed copy. Extract one copyHookHelpers(srcDir, destDir, label, result) with a single canonical helper list (including resolve-analyze-cmd.cjs) and the antigravity loop's error-reporting policy, and use it from both paths so a missing helper surfaces as a setup error instead of a silent runtime crash. Assert both the Claude and Antigravity install paths co-locate resolve-analyze-cmd.cjs next to the adapter, and that a failed copy records an error rather than passing silently. Co-authored-by: Cursor <cursoragent@cursor.com> * docs(cli): reattach installClaudeCodeHooks JSDoc after helper extraction The extracted HOOK_HELPERS/copyHookHelpers block landed between the installClaudeCodeHooks JSDoc and its function, leaving the doc reading as if it described the helper list. Move the block above the doc so it documents the function again. No behavior change. Co-authored-by: Cursor <cursoragent@cursor.com> * test(cli): enforce TS<->CJS invocation parity and guard CLI startup posture Tier-2 review found two in-scope gaps in the #1945 follow-up: - The "mirrors resolve-invocation.ts / test enforces parity" comments overclaimed: the parity test only compared the two .cjs copies to each other, so the TS source and the CJS hook copies could silently drift (NPX_REF, the per-mode command, and the Windows shim regex were hand-edited in all three this PR). Add TS<->CJS value parity (NPX_REF + formatAnalyzeCommand for every forced mode) and a source-level shim-regex parity check, and make the mirror comments accurately describe what is enforced. - No test locked the R3/R4 startup posture, so re-adding warnIfNpm11NpxRisk() (or any resolve-invocation import) at index.ts module scope -- the #207/#1383 lazy-startup regression -- would pass CI. Add a guard asserting index.ts has no module-load invocation probe and the warning is wired into analyzeCommand. Co-authored-by: Cursor <cursoragent@cursor.com> * refactor(cli): collapse npx-invocation resolver to one source of truth PR #1945 carried the gitnexus/pnpm/npx selection in three hand-synced places — the canonical hook helper, its byte-identical plugin copy, and a full TypeScript re-implementation in resolve-invocation.ts — kept in lockstep by per-mode-command and regex-extracted-by-regex parity tests. The TS formatAnalyzeCommand had no production caller (ai-context emits a fixed string), and the module memoized + exposed a test-only reset for a "repeated callers" case that has exactly one caller. Make hooks/claude/resolve-analyze-cmd.cjs the single source: extract the Windows-shim line-picking into a pure, exported pickPathMatch() and add an injectable probe to resolveInvocationMode() so the shipped logic is testable without spawning or global mocks. resolve-invocation.ts (118 -> 59 lines) now consumes that cjs via createRequire for resolveInvocationMode/NPX_REF and adds only the CLI-only npm-version probe and warning; the relative path resolves identically from src/cli/ (tsx, vitest) and dist/cli/ (shipped, hooks/ is a published sibling of dist/). Tests exercise the real shipped artifact, the NPX_REF/mode-command parity scaffolding is dropped (one implementation can't drift), and parity narrows to the two cjs copies staying byte-identical. No behavior change: hook stale-index hints and the analyze warning are byte-identical; the pre-existing setup.ts resolveGitnexusBin is untouched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): bound stale-index hook PATH probe under the hook budget (U1) The PostToolUse stale-index hint calls formatAnalyzeCommand(), which probes which/where; named PROBE_TIMEOUT_MS=2000 keeps git rev-parse (~3s) + up to two probes well under Claude Code's 10s hook timeout while preserving the machine-correct hint. Byte-identical in the plugin copy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): steer generated cross-repo group commands off npx (#1939) (U2) The Cross-Repo Groups block in generated AGENTS.md/CLAUDE.md still emitted bare 'npx gitnexus group ...', funneling npm-11 users into the arborist crash; switch to fixed 'pnpm dlx gitnexus@latest group ...'. Export generateGitNexusContent and add a group-branch test asserting no 'npx gitnexus' literal survives. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs: align steering guidance on pnpm dlx gitnexus@latest (U3) README troubleshooting uses gitnexus@latest; the repo's own committed CLAUDE.md/AGENTS.md stale-index hint now matches the generated output (pnpm dlx gitnexus@latest analyze) so the repo dogfoods the fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(hooks): assert exact @latest analyze command and pin invocation mode (U4) Drop dead PKG_VERSION/NPX_REF version-pinned constants; the cjs always emits gitnexus@latest, so assert exact toContain(...) instead of the /@\\S+/ wildcard; pin GITNEXUS_INVOCATION in the --embeddings tests for host-independent determinism. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(cli): cover resolver warn/edge branches; document probe seam (U5) Add coverage for the gitnexus-mode warn suppression, getNpmMajorVersion edge inputs (empty/pre-release/non-numeric), and the Windows non-wrapper pickPathMatch branch; widen the InvocationResolver interface to document the optional probe param. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): lower hook PATH-probe timeout to 1000ms (U1) In a linked worktree the stale-index hook runs git rev-parse --git-common-dir (~2s) + rev-parse HEAD (~3s) before up to two PATH probes; PROBE_TIMEOUT_MS=1000 holds the worst case near ~7s under Claude Code's 10s hook budget (was 2000, ~1s headroom). Byte-identical in the plugin copy. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): fail closed in gitnexus setup on missing required hook helper/adapter (U2) copyHookHelpers now returns the failed REQUIRED helpers (the .cjs trio; win-rm-list-json.ps1 stays best-effort since it fails open). Both install paths skip hook registration with an actionable error when a required helper failed; the Claude path also gains the adapter-existence guard the Antigravity path already had. Prevents registering a hook that crashes MODULE_NOT_FOUND on every tool event. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(skills): steer committed skill files off npx to pnpm dlx gitnexus@latest (U3) All 26 committed skill-file copies (gitnexus/skills, .claude, plugin, cursor) used 'npx gitnexus analyze', contradicting the generated freshness line and funneling npm-11 users into the arborist crash. Replace with 'pnpm dlx gitnexus@latest analyze'; add a regression guard (skills-steering.test.ts) that globs all four locations and fails if any reintroduces it. The cli skill's non-analyze npx subcommands (status/clean/list/wiki) are left as-is (out of the analyze-funnel scope). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): guard resolver import shape; assert group-impact steering (U4) Add a load-time guard on the createRequire(resolve-analyze-cmd.cjs) cast so a drifted/renamed cjs export fails loudly at module load instead of as a late TypeError in warnIfNpm11NpxRisk. Add the missing 'group impact' assertion to the ai-context Cross-Repo Groups test, and a resolver-contract test. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): auto-select invocation path with pnpm --allow-build (#1939) Probe npm/pnpm versions and PATH to pick a working analyze command without user configuration: global gitnexus first, pnpm dlx with --allow-build on npm 11+ (Ladybug native scripts), npx on npm 10 and earlier. Update docs, skills, and tests to match the canonical install-free command. Co-authored-by: Cursor <cursoragent@cursor.com> * fix(cli): place pnpm --allow-build before dlx, repair version-injection seam (#1939) The auto-selected install command emitted `pnpm dlx --allow-build=… analyze`, but pnpm < 10.14 keeps `dlx` in its argv escape list, so flags placed *after* `dlx` are parsed as package specs and rejected (ERR_PNPM_SPEC_NOT_SUPPORTED) on pnpm 10.2–10.13.x — strictly worse than the bare command. Move the flags before `dlx` (the position pnpm has honored since 10.2.0) in both byte-identical hook copies, the committed AGENTS.md / CLAUDE.md, and every skill tree. Also repairs the CI-red resolveInvocationMode seam: injecting `{ npmMajor: null }` to simulate an absent npm fell through `??` to the host's real `npm --version` (npm 10.x on the CI runners → routed 'npx' instead of 'pnpm'). Use an `'npmMajor' in deps` sentinel so an injected null is honored, drop the dead parseMajorVersion guard, and gate the flags on pnpm >= 10.2 via a single minor-aware probeVersion spawn (skipped for committed docs). Align the TS getNpmMajorVersion timeout to the 1s hook budget and strengthen the skills-steering guard with a pre-dlx positive assertion plus a post-dlx regression check. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs: add npm-11 pnpm caveat to README Quick Starts (#1939) The root, package, and cursor-integration README Quick Starts still steered first-contact users to bare `npx gitnexus analyze` — the exact npm 11.x arborist install crash issue #1939 names as a funnel. Add a one-line pnpm `--allow-build … dlx` caveat (keeping the simple npx default for npm<=10 / pnpm / yarn users); the package README points to its existing npm-11 workaround section. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(skills): route every gitnexus-cli command off npx to pnpm dlx (#1939) The gitnexus-cli skill demonstrated analyze via `pnpm --allow-build … dlx` but still showed status/clean/wiki/list via bare `npx gitnexus` — the same package, the same npm-11 crash-prone install path — and its header claimed "all commands work via npx". Convert every subcommand to the pnpm form across all three skill copies and reconcile the header. Broaden the skills-steering guard to forbid any `npx gitnexus` command in the cli-skill copies. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * perf(hook): probe pnpm once on the stale-index path (#1939) The stale-index hook resolved pnpm twice — `which pnpm` for mode selection then `pnpm --version` for the allow-build gate — two spawns for one tool in a ~9s/10s budget. Capture the version once in formatAnalyzeCommand and thread it through the existing deps seam (a successful `pnpm --version` proves presence), sharing a memoized PATH probe with resolveInvocationMode. Add explicit pnpm 10.0-suppress / 10.2-emit boundary tests and relabel the unknown-minor case. Both byte-identical cjs copies updated together. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(setup): single-quote POSIX hook command + assert cliPath patch applied (#1939) The hook `command` written into editor settings is shell-evaluated; the double-quoted `node "<path>"` form left `$`, backtick, and other metacharacters live in an adversarial $HOME. Single-quote the path on POSIX (Windows keeps the double-quoted form — those chars are illegal in Windows filenames). Also assert the cliPath source-literal replace() actually matched, recording an actionable error on drift instead of silently shipping a hook with an unresolved relative path. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(setup): normalize expected hook path for the Windows runner (#1939) The new POSIX-escaping test built its expected hook path with path.join, which emits backslashes on the Windows runner, while setup.ts forward-slash- normalizes the path before quoting — so `expect(cmd).toBe(node '<path>')` mismatched on tests/windows-latest. Normalize the expected path the same way. Production code was already correct; only the test's expected value was platform-fragile. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): steer docs/skills via a project-local runner, not a pnpm default (#1939) The prior approach hardcoded `pnpm --allow-build=… dlx gitnexus@latest <cmd>` into every committed skill + the generated AGENTS.md/CLAUDE.md, which assumes pnpm is installed. Replace it with a CLI-neutral project-local runner: - `gitnexus analyze` drops `.gitnexus/run.cjs` (a copy of the canonical `resolve-analyze-cmd.cjs`, which gains `buildRunnerArgv` + a `require.main` exec tail) next to the index. Docs/skills reference `node .gitnexus/run.cjs <cmd>`, which auto-selects the runner (global `gitnexus` → `pnpm dlx` → `npx`) at call time — no package-manager assumption. README first-run + an inline bootstrap note stay universal `npx gitnexus analyze`. - The exec tail uses `shell` on Windows so `.cmd`/`.ps1`/`.exe` shims resolve (execFileSync can't otherwise; Node blocks `.cmd` without a shell, CVE-2024-27980), and prints a diagnostic instead of a silent exit 1. Tests: runner exec-tail (real spawn, exit-code propagation + ENOENT diagnostic), copy-failure graceful degradation, and per-subcommand routing + pnpm-fallback vacuity guards. The generated CLAUDE.md block stays under the #856 token budget. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): resolve Windows .cmd version probes so pnpm steering fires (#1939) probeVersion (and the TS getNpmMajorVersion mirror) spawned npm/pnpm --version via execFileSync with no shell, so on Windows the .cmd shims ENOENT'd, the probe reported a present tool as absent, and the stale-index hook recommended the npx crash path #1939 exists to avoid. Add shell: process.platform === 'win32' to the version probes (the exec tail already does this). Parse the first version-shaped line so a Corepack/notice banner on stdout no longer defeats the parse. Carry pnpm presence separately from version so a present-but-unparseable pnpm still selects pnpm. Drop the dead probe ?? resolveOnPath coalesce. Cover resolve-analyze-cmd.cjs (+ plugin twin) with the shell-injection and windowsHide source-regression guards. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(cli): widen pnpm allow-build for the --embeddings=N equals form (#1945) buildRunnerArgv detected embeddings via gitnexusArgs.includes('--embeddings'), which missed the equals form (--embeddings=5000) that Commander also accepts, dropping --allow-build=onnxruntime-node on pnpm 10.2+. Match both forms. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(cli): cover the runner exec-tail Windows shell branch on CI (#1945) runner-exec-tail.test.ts was POSIX-only and unregistered in cross-platform-tests.ts, so the run.cjs Windows shell:true exec branch ran on no platform despite the file comment claiming windows-latest covered it. Add a .cmd-shim it.skipIf(onPosix) case and register the file in SPAWN_CLI so the windows-latest job runs it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs: fix broken troubleshooting anchor in gitnexus README (#1945) The npm-11 quick-start note linked to #npx-gitnexus-crashes-with-nodetarget-is-null-npm-11, which matches no heading; the actual troubleshooting heading slugifies to #cannot-destructure-property-package-of-nodetarget-as-it-is-null. Repoint the link. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(hooks): guard resolve-analyze-cmd.cjs in antigravity e2e sanity check (#1945) The antigravity adapter top-level require()s resolve-analyze-cmd.cjs, but the beforeAll helper-presence loop did not check for it — a failed copy would surface as noisy MODULE_NOT_FOUND in downstream tests instead of the intended actionable 'Helper not installed' error. Add it to the loop. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(skills): tie a missing-runner Cannot-find-module error to recovery (#1945) Generated CLAUDE.md/AGENTS.md make `node .gitnexus/run.cjs` the primary command, but the runner is gitignored, so a fresh clone or git clean leaves an agent facing a raw MODULE_NOT_FOUND. The CLAUDE.md block is token-budget-capped (#856), so the recovery guidance lives in the cli skill (its documented home): the bootstrap note now names the `Cannot find module` error and points at `npx gitnexus analyze` to (re)generate the runner. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * refactor(cli): disambiguate the MCP-pinned ref from the @latest hint (#1945) setup.ts and resolve-analyze-cmd.cjs both exported a constant named NPX_REF with different values (version-pinned for the persisted MCP entry vs. gitnexus@latest for hints). Rename setup.ts's module-private constant to MCP_PINNED_REF (value and behavior unchanged — the MCP pin stays pinned), leaving the cjs hint ref and its re-export alone. Also route the createRequire cast through 'unknown' so it reads as an explicit narrowing to the subset this module uses rather than a claim about the cjs's full export shape. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-02 09:00:34 +01:00
Zander Raycraft	ff3ddec1ff	fix(audit): Centralize heritage supertype matching (#1921/#1922) (#1940) ... * fix(audit): Centralizes heritage supertype matching so qualified, generic, scoped, and interface bases produce inheritance edges across all OO languages, with per-language configs and fixtures. * fix(audit): Harden parsing for #1922 with per-parse timeouts, ERROR/partial parse flags, tree-sitter pinned to 0.21.1, and CI ABI checks for every grammar. * fix: action lint passing * fix: feedback from triage review --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com>	2026-06-01 13:16:17 +01:00
Gergő Magyar	11bd508bb5	fix(lbug): resolve non-ASCII paths for KuzuDB on Windows (#1811) (#1817) ... * fix(lbug): resolve non-ASCII paths to 8.3 short form on Windows (#1811) KuzuDB's native C++ layer uses ANSI file APIs (fopen) on Windows. When the repo path contains CJK or other non-ASCII characters, the UTF-8 bytes from Node.js are misinterpreted as the system's Active Code Page (e.g. GBK), producing a garbled path — "Error 3: The system cannot find the path specified." Add `toNativeSafePath()` which converts non-ASCII paths to their Windows 8.3 short-name form (all-ASCII) before passing them to the native layer. Applied to both the database open path and the COPY CSV paths. No-ops on non-Windows and on all-ASCII paths. Closes #1811 * test(lbug): add unit + integration tests for non-ASCII path handling (#1811) - Unit tests for toNativeSafePath: ASCII passthrough, non-Windows no-op, Windows short-path conversion, nonexistent-path fallback - Integration test: full initLbug + loadGraphToLbug round-trip with CJK characters in the storage path — runs on all platforms - Fix toNativeSafePath to reject cmd.exe output containing '?' chars (replacement for unrepresentable Unicode in the console code page) - Register integration test in vitest lbug-db project and cross-platform-tests.ts matrix * chore(autofix): apply prettier + eslint fixes via /autofix command * feat(lbug): junction fallback, tmpdir CSV staging, pool-adapter coverage (#1811) U1+U4: toNativeSafePath now tries 8.3 short path → NTFS junction fallback → diagnostic warning. Junctions target path.dirname(p) and reconstruct the leaf. Handles EEXIST races. Registers cleanup on exit/SIGTERM/SIGINT. Orphan scan on first call removes stale junctions from prior crashes. U2: loadGraphToLbug redirects csvDir to os.tmpdir() when storagePath contains non-ASCII on Windows, avoiding non-ASCII characters in COPY FROM paths entirely. U3: All 4 createLbugDatabase call sites in pool-adapter.ts now wrap dbPath with toNativeSafePath. * fix(test): fix CI failures from toNativeSafePath addition (#1811) - Fix lbug-non-ascii-path integration test: use CodeRelation (actual relationship table name) instead of CALLS - Add toNativeSafePath to lbug-config.js mocks in pool-wal-recovery and lbug-pool-win-fts-probe tests — pool-adapter now imports it * fix(lbug): sanitize path before cmd.exe shell expansion (CodeQL) Reject paths containing cmd.exe metacharacters (" % | & < > ^) before interpolating into the `for %I` short-path command. Prevents command injection via crafted path names. * fix(lbug): address code review findings in non-ASCII path implementation - U1: Use process.exit(0) on Windows instead of process.kill re-raise (SIGTERM forcefully kills on Windows, handlers never fire) - U2: Pass safePath to openWithLockRetry so sidecar sweep targets the path KuzuDB actually opened, not the original non-ASCII path - U3: Skip junction creation in worker threads (isMainThread guard) to prevent junction leaks from pool-adapter workers - U4: Replace existsSync with lstatSync in orphan scan to avoid 30s blocking on unreachable UNC network targets * chore(autofix): apply prettier + eslint fixes via /autofix command * fix(lbug): correct SIGTERM exit code and run Prettier (#1811) - Use exit code 143 (SIGTERM) / 130 (SIGINT) on Windows instead of 0 so termination is not masked as success - Run Prettier to fix formatting (CI Gate blocker) * fix(lbug): eliminate CodeQL command-injection taint in tryShortPath Pass the path via GITNEXUS_SP environment variable instead of interpolating it into the cmd.exe command string. The FOR loop reads %GITNEXUS_SP% from the environment, so the command text is entirely static — no user-controlled data in the shell command. Also removes CMD_UNSAFE_RE since the env var approach makes character-level sanitization unnecessary. --------- Co-authored-by: Test <test@example.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-05-25 21:28:12 +01:00
Nilotpal Kashyap	e931aaf3a7	feat(setup): implement antigravity integration setup and hook adapter… (#1730) ... * feat(setup): implement antigravity integration setup and hook adapter for gitnexus * docs(readme): list Antigravity in supported editors * test(setup-antigravity): pin platform per-test to fix Windows CI failure The MCP entry assertion expected `npx` directly, but on Windows `getMcpEntry()` wraps it as `cmd /c npx ...`, which broke the Windows runner. Pin platform to darwin in beforeEach so the existing assertion is deterministic, restore the descriptor in afterEach, and add a parity test for the win32 cmd-wrapper shape. * fix(antigravity): align hook adapter to Gemini CLI schema + fix Windows CI Rebase the Antigravity integration on the canonical Gemini CLI hooks contract (https://geminicli.com/docs/hooks/reference/), which is the documented schema Antigravity 2.0 inherits: - Hook adapter: replace PreToolUse/PostToolUse with the single AfterTool event. BeforeTool has no documented context-injection channel in the Gemini contract, so augmentation runs in AfterTool where hookSpecificOutput.additionalContext is the documented way to append text to the tool result the agent reads. Stale-index hints land in the same channel (so the agent sees them) and are mirrored to stderr for terminal users. Tool-name matcher updated to Gemini CLI snake_case (search_file_content|glob|run_shell_command). - Setup: write hooks to ~/.gemini/settings.json under canonical hooks.AfterTool[] (replaces the ad-hoc hooks.json top-level group). Polite-neighbor merge preserves existing user hooks. Also copy win-rm-list-json.ps1 alongside hook-db-lock-probe.cjs so the Windows MCP server ownership probe doesn't silently fail open. - Tests: 17 regression tests covering MCP write, win32 shape, hook schema, polite-neighbor merge, idempotency, adapter context emission, stale-index hint, and skill layout. - README: footnote documenting the AfterTool design choice and a link to the Gemini CLI hooks reference. Windows CI fix: installSkillsTo previously used glob('*.md') + glob('*/SKILL.md'), which returned zero matches under the Windows runner's temp paths (8.3 short-name like RUNNER~1). Replace with fs.readdir + dirent type checks — same behavior, no path quirks. This fixes the only failing Windows job on the PR. * fix(antigravity): address PR review — windowsHide, stale docs, dead code Addresses the production-readiness review findings on PR #1730: - F1 (blocker): add windowsHide:true to all four spawnSync sites in the Antigravity hook adapter (findCanonicalRepoRoot, runGitNexusCli's two branches, buildStaleIndexHint) so they don't flash console windows on Windows. Matches the fix #1794 already on main for the Claude hook. - F2 (blocker): update gitnexus/README.md editor table to say AfterTool and link the Gemini CLI hooks reference. The published README had drifted to the pre-c1872b4 PreToolUse + PostToolUse schema. - F3: rewrite the stale ~/.gemini block comment in setup.ts. It still described the old hooks.json + gitnexus group + grep_search design. - F4: remove grep_search dead code from extractPattern and its doc comment. The registered matcher is search_file_content|glob|run_shell_command, so grep_search would never be invoked. - F5: annotate timeout:10000 with a ms-unit comment noting Gemini CLI uses milliseconds (Claude Code uses seconds). - F6: add the GITNEXUS_DEBUG branch to extractAugmentContext for parity with the Claude adapter, so suppressed augment stderr is recoverable. - F7: stageAdapter test helper now copies win-rm-list-json.ps1 alongside the .cjs helpers, so the adapter's Windows lock-probe path isn't a silent fail-open in child-process smoke tests. * test(antigravity): add integration tests and register in cross-platform matrix Adds end-to-end coverage on top of the unit-level tests, per maintainer request: - test/integration/setup-antigravity.test.ts (10 tests): exercises the real setupCommand() against a temp HOME with ~/.gemini/antigravity/ present. Verifies mcp_config.json shape, ~/.gemini/settings.json AfterTool entry, adapter + helpers + win-rm-list-json.ps1 copy, baked-in cliPath rewrite (issue #108 regression class), skill layout, polite-neighbor merge against existing user hooks, idempotency, skip-when-absent, corrupt-file safety, and key preservation. - test/integration/antigravity-hook-e2e.test.ts (19 tests): runs the full install-then-execute flow — invokes setupCommand to lay down the adapter + helpers, then spawns the INSTALLED adapter as a real child process against a temp git repo + .gitnexus/. The source adapter cannot be spawned directly (it requires sibling .cjs helpers that only live in hooks/claude/); install-then-spawn mirrors the production codepath. Covers staleness detection across all five git mutation types, --embeddings propagation, polite skip on toolResponse.error / exit_code !== 0, augment crash-free behavior, cwd validation, corrupted/missing meta.json, unknown event names, empty stdin, and the no-.gitnexus deep-nested case. - scripts/cross-platform-tests.ts: registers all three antigravity test files (unit in PLATFORM_LOGIC, two integration files in SPAWN_CLI) so Windows and macOS CI exercise them on every run. * fix(antigravity): review fixes — dedup, silent-failure guard, type coercion, glob filter - Delete mergeGeminiSettingsHooks (verbatim copy of mergeHooksJsonc), replace call site with the original - Unify geminiHasGitnexusHook into hasGitnexusHook with commandFragment parameter; delete the duplicate - Guard against silent adapter-copy failure: verify the adapter file exists before registering the AfterTool hook entry in settings.json; surface helper copy errors instead of swallowing - Fix toolSucceeded type coercion: use Number() so string exit_code values from Gemini CLI are handled correctly - Align glob tool extractPattern with Claude adapter's restrictive regex filter (/[*\/]([a-zA-Z][a-zA-Z0-9_-]{2,})/) - Remove bounds-only toBeGreaterThan(0) assertion (DoD §2.7) - Add antigravity adapter to HOOK_FILES windowsHide regression list * chore(autofix): apply prettier + eslint fixes via /autofix command * chore: trigger CI --------- Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Test <test@example.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>	2026-05-25 14:46:17 +01:00
eddie.pan	9f99259e5c	feat(wiki): support local Claude and Codex providers (#1769) ... * feat(wiki): support local Claude and Codex providers * chore(autofix): apply prettier + eslint fixes via /autofix command * fix(wiki): address local CLI provider review findings - Add subprocess timeout: LocalCLIConfig gains requestTimeoutMs, runLocalCLI sets a kill timer that rejects with an actionable error matching the HTTP timeout message format. --timeout is no longer silently ignored for claude/codex providers. - Add windowsHide: true to spawn() to prevent console window flash on Windows, matching cursor-client.ts behavior. - Skip GITNEXUS_MODEL env var for local providers so a user's OpenAI model name doesn't cross-contaminate claude/codex CLI invocations. Precedence for local providers: --model → savedLocalModel → ''. - Guard against empty stdout: reject with actionable error when CLI exits 0 but produces no output, preventing silent empty wiki pages. * fix(wiki): address deep-review findings in local CLI providers - Move empty-output guard from runLocalCLI to per-provider callers so Codex can read --output-last-message file even when stdout is empty - Merge existing config in interactive setup (local + Azure paths) to prevent saveCLIConfig from erasing previously saved API keys - Use StringDecoder for stdout/stderr to handle multi-byte UTF-8 chars split across pipe chunk boundaries - Distinguish ENOENT from non-zero exit in detectLocalCLI so users see auth guidance instead of misleading "CLI not found" when the binary exists but is not authenticated * test(wiki): add subprocess contract tests for local CLI providers Add 21 integration-level tests covering the Claude and Codex subprocess contracts that wiki-flags.test.ts mocks out: - Claude argv: -p, --output-format text, --no-session-persistence, --model conditional, stdin prompt content, CI=1, windowsHide:true - Codex argv: exec subcommand, --sandbox read-only, -c approval_policy, --output-last-message temp path, --cd, stdin marker, --model - Timeout: kill timer fires and rejects, no timer when unset - Codex file fallback: stdout used when file missing, error when both empty - detectLocalCLI: warn on non-ENOENT, silent on ENOENT - onChunk: cumulative byte count forwarded Also register the test in cross-platform-tests.ts SPAWN_CLI section and fix detectLocalCLI ENOENT detection logic (invert the check so non-ENOENT errors produce a warning). * fix(wiki): platform-aware process tree kill and Codex contract snapshot - Add killChildTree helper that uses taskkill /T /F /PID on Windows to terminate the entire process tree (including cmd.exe grandchildren), with fallback to child.kill() if taskkill fails or on non-Windows - Add Codex CLI flag contract snapshot test that locks the exact spawn args — any flag rename, reorder, or removal is caught immediately - Add Windows taskkill tests: success path asserts taskkill called with correct PID and /T /F flags, failure path verifies child.kill() fallback --------- Co-authored-by: eddie.pan2 <eddie.pan2@jtexpress.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Gergő Magyar <gergomagyar@icloud.com> Co-authored-by: Test <test@example.com>	2026-05-25 12:59:48 +01:00
Gergő Magyar	93158a1992	chore(ci): consolidate parity shards and narrow cross-platform matrix (#1798) ... * chore(ci): reduce CI runner-minutes by consolidating parity and narrowing cross-platform Scope-resolution parity previously spawned 9 separate GitHub Actions jobs (one per migrated language), each doing full checkout + npm ci + build for a single test file. Consolidate into one job running scripts/run-parity.ts which loops through all migrated languages sequentially — same coverage, ~45 fewer runner-minutes of redundant setup per PR. Cross-platform (Windows/macOS) previously ran the full 373-file test suite. Narrow to 45 platform-sensitive files (native LadybugDB, process spawning, path separators, worker threads, filesystem behavior). Full suite still runs on Ubuntu with coverage. Also adds 2 missing lbug integration tests (lbug-orphan-sidecar-recovery, lbug-readonly-init) to the sequential lbug-db vitest project where they belong, and rewrites TESTING.md to document all test lanes. * fix: address code review findings on parity and cross-platform scripts - Capture stderr in run-parity.ts (vitest writes diagnostics to stderr) - Lower per-invocation timeout from 5min to 60s to stay within CI job limit - Add --language flag validation (error on missing value) - Add timeout diagnostic to run-cross-platform.ts catch block - Add analyze-wal-checkpoint-failure.test.ts to lbug-db sequential project - Expand cross-platform list: parser-loader, pipeline, pipeline-graph-golden, setup-skills, cli/tool-no-index-stderr (51 files, was 45) * fix: add shell:true for Windows npx resolution and simplify fs import execFileSync('npx', ...) fails with ENOENT on Windows because npx is npx.cmd — shell:true resolves this. Also replaces dynamic await import('fs') with static import, and fixes timeout detection to use err.killed instead of err.code. * fix(ci): raise parity per-invocation timeout to 120s and job timeout to 30min TypeScript and C++ resolver tests take 60-90s on CI runners, exceeding the 60s per-invocation timeout. Raise to 120s. Also bump the job-level timeout from 25 to 30 minutes for margin (realistic total is ~11 min). * fix(ci): raise parity per-invocation timeout to 180s for C++ resolver C++ resolver tests take 130-150s on CI runners due to template metaprogramming, ADL, and SFINAE fixture volume. 120s was still too tight. Realistic total across all 9 languages is ~12 min, well under the 30-min job timeout. * fix(ci): use stdio inherit for parity — no per-invocation timeout Switch from piped stdio with per-invocation timeouts to stdio: 'inherit'. Vitest output streams to CI console in real time, making failures immediately visible. The CI job-level timeout (30 min) is the only guard — no more artificial per-invocation timeouts that cut off slow resolver tests like C++ (which genuinely takes 3+ minutes). --------- Co-authored-by: Test <test@example.com>	2026-05-24 12:10:10 +01:00