jcodemunch-mcp 1.108.331__tar.gz → 1.108.332__tar.gz

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "jcodemunch",
   "displayName": "jCodeMunch",
-  "version": "1.108.331",
+  "version": "1.108.332",
   "description": "Token-efficient MCP server for source code exploration via tree-sitter AST parsing",
   "author": {
     "name": "J. Gravelle",

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/CHANGELOG.md

@@ -2,6 +2,51 @@
 
 ## [Unreleased]
 
+## [1.108.332] - 2026-10-07 - a macro's docstring is the comment directly above it
+
+### Fixed
+
+- **A macro's docstring is the comment directly above it (LEDGER L-126).** A dbt macro, test,
+  snapshot or materialization, and a Jinja or Twig `macro` or `block`, takes the `{# comment #}`
+  above it as its docstring. The lookup searched for a comment from the start of the file and
+  then checked only that the text before the directive ended in `#}`, so it returned the FIRST
+  comment of the file for every directive that had one above it. In a file of documented macros
+  each macro after the first carried the first one's description, and a search by what a macro
+  does found the wrong one. Through `parse_file` on `main` and then on the fix
+  (`evidence/l126_before_after.txt`): in a `.sql` of three macros, `second` under
+  `{# about second #}` read `about first` and reads `about second`; in a `.j2` of two, `button`
+  read `renders a field` and reads `renders a button`. The comment used now is the one that ENDS
+  where the text before the directive ends, read from a table of the file's comments built once,
+  so a `#}` that closes no comment, and a comment elsewhere in the file, are nobody's docstring.
+  A `--` comment above a directive was already its own and is unchanged. The dashes of a
+  whitespace-control comment, `{#- about m -#}`, were served as part of the docstring
+  (`- about m -`); they are the delimiter's and are dropped, as are Jinja's `+` and Twig's `~`,
+  one mark per side. ⚠ The docstring changes
+  on unchanged content, so `PARSER_GENERATION` is 10 and an existing index re-parses once at its
+  next index run; no symbol id moves. Not run: a dbt or Jinja corpus, so how many stored
+  docstrings move is not measured.
+
+- **Three loops on the parse path take time proportional to the file (LEDGER L-117).** Each
+  redid whole-file work per item, in Python, after the parse. Attributing calls to their
+  enclosing function rebuilt the list of function starts for every call and then walked back
+  over every function that did not hold it; it is one sweep now. The Razor `@code {` scan
+  started again for every block and ran to the end of the file when a block never closed; the
+  blocks of a file share their scans now. The dbt and Jinja directive loop copied the file up
+  to each macro, counted its newlines, searched it for a comment and split it into lines; it
+  reads tables built once per file. Five parsers (Razor, Astro, VHDL, Verilog, COBOL) numbered
+  each symbol by counting newlines from the start of the file; they share one table. Measured
+  through `parse_file` with the parse budget off, on `main` and then on the fix
+  (`evidence/l117_before_after.txt`): a 418,340-byte Python file of 6250 functions and 20000
+  module-level calls took 63.877 s and takes 0.593 s; a 50,000-byte Razor file of 6250
+  unclosed `@code {` took 106.431 s and takes 0.031 s; a 26,890-byte `.sql` of 1000 open
+  comments and macros took 38.390 s and takes 0.089 s. Each of those three times is past the
+  default parse budget of 20 s, at which a file is skipped and named. Every field of every
+  symbol is the same before and after over 9830 files (5137 of them Razor, 285 SQL), so no
+  re-index is owed by this entry. Not changed by it: the docstring of a macro under a second
+  `{# comment #}` (LEDGER L-126, the entry above); three shapes stay superlinear and are listed
+  in LEDGER L-127. Not run: a Jinja or Twig corpus; any Python but 3.12.4 on Windows; the files
+  above at the default budget.
+
 ## [1.108.331] - 2026-10-06 - a full re-index keeps the embedding metadata beside its vectors
 
 ### Fixed

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/ISSUE-HISTORY.md

@@ -2214,3 +2214,17 @@ The 1.108.330 entry, verbatim, dropped when it was compressed to a `Prior` line:
 The `Tests:` line's 1.108.328 count, verbatim:
 
 - ⚠ Prior (1.108.328): 14684 passed, 25 skipped, **0 failed** (14709 total).
+
+## Current State rotation (2026-10-07, release 1.108.332)
+
+The 1.108.329 entry, verbatim as it stood in `CLAUDE.md`:
+
+- **Prior (1.108.329):** **The parse budget stops a slow tree-sitter parse** (L-114): the deadline lives inside `parse_file` (`parser/parse_budget.py`), bound to every parser by `grammar_pack.get_parser` and ended by tree-sitter's own timeout (rules: the Env Vars row). Full text: `CHANGELOG.md`; verbatim in `ISSUE-HISTORY.md` (2026-10-06, release 1.108.330).
+
+The 1.108.331 entry, verbatim, dropped when it was compressed to a `Prior` line:
+
+- **Version:** 1.108.331 — **A full re-index keeps the embedding metadata beside its vectors** (#522, @lsg1103275794). `save_index` deletes the index's own `meta` keys and leaves those starting with `embedding_store.META_KEY_PREFIX`. ⚠ `embed_repo` after a full re-index no longer re-embeds everything; `force=true` does. ⚠ The semantic top-up in `search_symbols` still checks no stored model (L-121), and stale or orphan vectors survive (L-122). Also `embed_repo`'s task-type gate has THREE states (#523): `None` is never recorded and is not a change, `""` is a recorded value, and vectors with no embedding metadata at all are still rebuilt (jjg, 2026-10-06), named by `rebuild_reason`. Also a Vue or Svelte `<script>`'s comment lookup is one table per parent node, linear where it was quadratic (L-115). Forensics: `CHANGELOG.md`, `docs/workflows/LEDGER.md`.
+
+The `Tests:` line's 1.108.329 count, verbatim:
+
+- ⚠ Prior (1.108.329): 14726 passed, 25 skipped, **0 failed** (14751 total).

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: jcodemunch-mcp
-Version: 1.108.331
+Version: 1.108.332
 Summary: Token-efficient MCP server for source code exploration via tree-sitter AST parsing
 Project-URL: Homepage, https://github.com/jgravelle/jcodemunch-mcp
 Project-URL: Repository, https://github.com/jgravelle/jcodemunch-mcp
@@ -246,10 +246,10 @@ That's the highlight reel. The complete tour of 90+ tools, the MUNCH compact wir
 <!-- WHATSNEW:START -->
 #### What's new
 
+- **[v1.108.332](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.332)** (2026-10-07) — a macro's docstring is the comment directly above it
 - **[v1.108.331](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.331)** (2026-10-06) — a full re-index keeps the embedding metadata beside its vectors
 - **[v1.108.330](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.330)** (2026-10-06) — the parse budget bounds a file's Python-side time
 - **[v1.108.329](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.329)** (2026-10-05) — the parse budget stops a slow parse
-- **[v1.108.328](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.328)** (2026-10-04) — a file a package.json script runs is an entry point
 <!-- WHATSNEW:END -->
 
 ---

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/README.md

@@ -158,10 +158,10 @@ That's the highlight reel. The complete tour of 90+ tools, the MUNCH compact wir
 <!-- WHATSNEW:START -->
 #### What's new
 
+- **[v1.108.332](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.332)** (2026-10-07) — a macro's docstring is the comment directly above it
 - **[v1.108.331](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.331)** (2026-10-06) — a full re-index keeps the embedding metadata beside its vectors
 - **[v1.108.330](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.330)** (2026-10-06) — the parse budget bounds a file's Python-side time
 - **[v1.108.329](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.329)** (2026-10-05) — the parse budget stops a slow parse
-- **[v1.108.328](https://github.com/jgravelle/jcodemunch-mcp/releases/tag/v1.108.328)** (2026-10-04) — a file a package.json script runs is an entry point
 <!-- WHATSNEW:END -->
 
 ---

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/docs/harness/ARCHAEOLOGY.md

@@ -352,6 +352,8 @@ Criterion codes: 1 correctness, 2 token reduction, 3 freshness/caches/absence, 4
 | tests/test_parity_map.py | `get_parity_map` classifies ported/renamed/diverged/added/orphaned symbols across two scopes, computes `parity_pct`, orders the port plan topologically with SCC grouping, errors on same scope/unindexed/empty, and is read-only. | `07bbb0c get_parity_map: correspondence-aware migration parity map (v1.108.111)`; docstring | 1 | LOAD-BEARING | Fixture is a legacy/ vs v2/ tree with commented expected outcomes per symbol. |
 | tests/test_parse_budget_cancels.py | An over-budget tree-sitter parse is stopped at `JCODEMUNCH_PARSE_BUDGET_SECONDS` and the file is named in `warnings`, on `parse_file`, a full index and an incremental re-index, at any file size; a stop is recognised without a clock; another thread's time is not charged to the file; a first index starts no wait thread; the installed binding can still cancel a parse. | LEDGER L-114 (2026-10-04): the thread wait could not return while the parse held the GIL | 5 | LOAD-BEARING | The slow input is L-113's shape; each cancelled case costs its 0.25 s budget. The fake-parser cases pin both directions of the stop rule and the expired-deadline branch (review rounds found mutants that passed an earlier form). `test_a_first_index_leaves_no_thread_behind` predates L-116's fix and still holds; every route is in `tests/test_parse_budget_python_side.py`. `OLD_WAIT_GATE` is the retired wait's 128 KiB threshold, kept as a fixture boundary. The binding canary fails when `Parser.timeout_micros` is gone |
 | tests/test_parse_budget_python_side.py | A file's Python-side work is stopped at `JCODEMUNCH_PARSE_BUDGET_SECONDS` in the parsing thread and the file is named: the generic walker, dedicated parsers, a regex language, seven walkers on a tree that builds no symbol, and three quadratic loops that are no recursion. Over the source: every `for`/`while` in the six parse-path modules starts with a checkpoint (three named exemptions), no recursion lacks one, every module of `parser/` is classified. Also: a parser that swallows the stop builds nothing more; a parser-side stop raises at the next checkpoint; a file that ends past its deadline with no checkpoint having seen it is named; time the thread did not spend is not charged; a first index and a re-index name the same file the same way; every file is parsed on the calling thread; no clock is read outside a file or with the budget off. | LEDGER L-116 (2026-10-05): the thread wait was wall-clock, skipped one route and left its worker running | 5 | LOAD-BEARING | The clock is the test's: the deadline passes 5.5 s into a 5 s budget when the file's C parse returns, so nothing depends on a slow fixture and a far-over-only stop fails. ⚠ A new loop on the parse path fails the scan until its first statement is `parse_budget.checkpoint()`; do NOT add it to the exemption table to pass (each entry there has its reason beside it). A new module in `parser/` must be put on or off the path. The scans see statements, not a comprehension, a loop's iterable or one slow call (L-118) |
+| tests/test_parse_path_loops_are_linear.py | Three loops on the parse path are linear in the file: attributing calls to their enclosing symbol, the Razor `@code {` brace scan, and the dbt/Jinja directive loop. Each fix returns what the implementation it replaced returns (kept in the file as an oracle) on seeded generated input (since L-126 a directive's docstring is the one exception: the old loop's docstring was that defect, so the field is held to the rule, written the slow way beside the oracle), finishes a file twice as big before the oracle finishes the small one, and where `parse_budget.checkpoint()` sees the loop, passes under 2.6 times the checkpoints for twice the file. The Razor scan searches under 2.6 times the characters for twice the blocks when each opens an unclosed comment; the directive loop copies or searches under 2.6 times the characters for twice the directives; the call sweep raises under 2.6 times the line events for twice the calls. No module of `parser/` counts newlines up to an offset (`_line_numbers` is the one table), and that scan sees both spellings. Also: a call inside two symbols goes to the inner one; a brace in a string or a comment does not close a block; a macro keeps its line, its end and its `--` comment. | "fix: three loops on the parse path take time proportional to the file (LEDGER L-117)" | 5 | LOAD-BEARING | The race is against the oracle on the same machine in the same test, never against a typed number of seconds. A count of checkpoints is blind to work inside one C call (a slice, a `count`, a regex search), which is why the race is there too. The race is blind to a rescan cheaper than the old loop (a copy of the file per directive wins it), which is why the character and line-event counts are there: a new loop on these paths needs a count that can see its work, not only a race. The race is at TWICE the size, not more: coverage's C tracer (the 3.10 and 3.11 jobs) slows the fix and not the oracle, and at eight times the size the fix lost. Before changing a size, read the margins with the tracer on. The oracles are the old code and must not be edited to agree with a change. |
+| tests/test_a_macro_docstring_is_the_comment_above_it.py | A dbt macro, a Jinja template macro and a Twig macro and block each take the `{# comment #}` that ends directly above them as their docstring, through `parse_file`; the dashes of `{#- ... -#}` are not part of it; a comment elsewhere in the file, a stray `#}`, text that only ends like a comment and an unclosed comment are nobody's docstring; of two comments the nearer one is used; a `--` comment nearer than a Jinja one wins; 300 documented macros each keep their own; `PARSER_GENERATION` is at least 10. | "fix: a macro's docstring is the comment directly above it (LEDGER L-126)" | 1 | LOAD-BEARING | The lookup returned the FIRST comment of the file for any directive under a `#}`, so a one-macro fixture cannot fail on it: every case here has a first comment that is NOT the answer. The generation assertion is a floor, not an equality, so the next bump does not edit this file. |
 | tests/test_parse_cache.py | Content-addressed parse cache is a passthrough when disabled, returns identical symbols on hit, and FIFO-evicts past `DEFAULT_MAX_ROWS`. | `c57b070 release: v1.108.40 -- content-addressed parse cache for shared-host indexing`; `444925e v1.108.41 -- bound the shared parse cache (FIFO eviction)` | 3 | LOAD-BEARING | Env-gated by `JCODEMUNCH_PARSE_CACHE`; compares `dataclasses.asdict` of symbols. |
 | tests/test_parse_warnings.py | `index_folder` reports `missing_extractors` for a language with symbols but no import extractor (Elixir), and `get_dead_code_v2` emits `framework_warning` when no entry points are found. | `b4db152 release: v1.21.19 -- Phase 5 uncertainty disclosure (T15-T18)`; docstring T17/T18 | 9 | LOAD-BEARING | Elixir is the representative gap; if an Elixir import extractor is added this fixture language must change. |
 | tests/test_parser.py | Core `parse_file` extraction for Python plus Lua, JS/TS const constants, and Astro frontmatter/components. | `ac91053 feat: add Lua language support (v1.0.1)`; `c984804 feat: extract JS/TS const declarations as constants`; `d1aa0e5 feat(parser): enhance Astro support ... regression tests` | 1 | LOAD-BEARING | Phase 1 file that accreted language cases; one `read_text` on a fixture. |

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/docs/workflows/LEDGER.md

@@ -165,7 +165,7 @@ with jjg's reason. Keep the row. To promote a row to an issue, set Status to
 | L-114 | 2026-10-04, harness F-41 review | `JCODEMUNCH_PARSE_BUDGET_SECONDS` cannot stop or shorten a slow tree-sitter parse on any route, and one route does not ask it to. All of this is `evidence/l114_budget.txt`, budget 2 s, a 324,035-byte file that takes about 4.5 s to parse (L-113's shape). **The mechanism:** `parse_file_budgeted` waits with `worker.join(budget)`, and tree-sitter's parse holds the GIL for its whole duration: a ticker thread asked to tick every 50 ms ticked ONCE during a 4.57 s parse (about 91 were due), and `join(2.0)` returned after 4.57 s with the worker already finished. So the wait cannot return early, and by the time it returns the parse is usually done: four direct calls in one process raised `ParseBudgetExceeded` once (the cold first call, after 4.44 s) and returned the file's symbols three times (4.57 to 4.72 s), with no warning. The budget therefore bounds neither the latency nor, reliably, the outcome, and while the parse runs no other Python thread in the server runs either. **The routes** in `tools/index_folder.py`: the full-index loop calls `parse_file` directly (line 2928), so the budget is never consulted: a first index took 4.58 s with `incremental=True` (the default) and 4.75 s with `incremental=False`, each `warnings None` and no budgeted call; the incremental re-index (`parse_and_prepare_incremental`, line 2748) and the immediate route (`parse_immediate`, line 2120) reach `parse_file_budgeted`: a re-index after an edit took 4.70 s, made the budgeted call, got symbols back after 4.54 s, and reported no warning. CLAUDE.md's Env Vars row says an overrun file "is skipped and named in the index result's `warnings` instead of the run hanging" and adds that a watchdog cannot stop the work; measured, it does not skip or name the file either, in 4 of the 5 calls quoted here (6 of the 8 over-budget calls in the evidence file; both that raised were a process's cold first call). By the same mechanism the budget does bound time spent in Python code, which releases the GIL between bytecodes (the round-3 reviewer's probe: a 5 s pure-Python loop raised after 2.03 s; not in the evidence file); that was not what stalled here. Not run: the watcher's path, `index_repo`, a grammar whose parse is slow in Python-side walking instead of in the C parse, and a parse long enough that the post-parse walk is still running when the wait returns. Possible fixes, neither tried: tree-sitter's own parse timeout or progress callback if the installed binding has one, or a child process. Decide that first; routing the full-index loop through the budgeted call changes nothing until the budget can fire. | `src/jcodemunch_mcp/tools/_indexing_pipeline.py` (`parse_file_budgeted`); `src/jcodemunch_mcp/tools/index_folder.py` | defect | medium | FIXED 2026-10-04 for the tree-sitter parse; the Python-side half moved to L-116. The limit went one layer down, into the parser (`src/jcodemunch_mcp/parser/parse_budget.py`): `parse_file` opens one deadline per file, `grammar_pack.get_parser` (the one loader every grammar call uses) returns a parser carrying what is left of it, and tree-sitter's `timeout_micros` ends the parse in C. A cancel is recorded on the deadline and raised by `parse_file` after its dispatch, because most dedicated parsers catch `Exception` around their parse. Measured at the same 2 s budget on the same file (`evidence/l114_after.txt`): `parse_file` raised after 2.01 to 2.07 s on four calls of four, and the full index, the incremental first index and the re-index after an edit finished in 2.22 to 2.26 s with the file named in `warnings`. The size gate is gone for the parse. What two review rounds changed: a stop is recognised by what the binding raises, never by a clock (this box's monotonic clock has a resolution of 0.015625 s, `evidence/l115_vue_svelte_walk.txt` line 2, and a clock test called a late cancel a real error, returning the file empty and unnamed; `evidence/l114_r2_tiny_budgets.txt` shows no empty return and no bare error in 750 calls); between a file's parses the deadline is the parsing thread's own time, so another thread's parse cannot spend it (0 of 192 files falsely skipped, `evidence/l114_r2_two_threads.txt`; 0 of 120 across ten first indexes beside another, `evidence/l114_r3_first_index_two_threads.txt`); a parser asked after the deadline is refused and the refusal recorded; a stopped parser is reset before it is let go, because tree-sitter keeps a stopped parse to resume it; the warning filter for the deprecated setter is installed once per process. Round 1 also routed the full-index loop through `parse_file_budgeted`; round 2 measured that as a regression (the wall-clock wait names a fast file over budget beside another thread's parse, L-116 (2), and the first index is the default route) and it was taken back out. Why not the progress callback tree-sitter 0.25 recommends: it is ignored for a bytestring, and with a read callback it killed the interpreter with an access violation on eight variants of eight (`evidence/l114_read_cb_variants.txt`, `evidence/l114_read_cb_direct.txt`; tree-sitter 0.25.2, Python 3.12.4, Windows only). Guard: `tests/test_parse_budget_cancels.py` (35 reintroduced defects of 35 fail it, `evidence/l114_mutants.txt`), which also fails when the installed binding cannot cancel. Not covered: inside a parse the timer is tree-sitter's and it is wall-clock, so other PROCESSES can spend a file's budget (a file that parses in 0.672 s alone was stopped at a 1.01 s budget 12 times of 12 beside 48 CPU-burning processes on 24 cores, `evidence/l114_r4_other_processes.txt`; the file is named); `search_ast` loads its parser outside `parse_file` and has no limit; Python-side time between a file's parses counts toward its deadline, and Python-side time after its last parse has no limit on the first index (L-116); `pyproject.toml` allows any `tree-sitter>=0.25`, and a release that removes `timeout_micros` leaves only the thread wait (logged once at WARNING); on a platform without `time.thread_time` the deadline falls back to the monotonic clock. Not run: the callback crash, or any of this, on another OS or Python. |
 | L-115 | 2026-10-04, L-114 review round 1 | A Vue or Svelte file's plain `<script>` is slow in `parse_file`'s PYTHON-side work, not in the C parse. `evidence/l115_vue_svelte_walk.txt` (the probe sets a 600 s budget, so nothing is stopped, and builds 6000 functions): a 441,827-char `.vue` with those functions in `<script>` took 14.12 s in `parse_file` with its two C parses at 0.006 and 0.109 s, and a 441,806-char `.svelte` with the same script took 14.19 s with C parses of 0.004 and 0.131 s. The same count of functions as a `.ts` file reads at most 0.73 s per call over 25 calls (`evidence/l114_r2_tiny_budgets.txt`, row `a.ts budget 0.25`). Cause (2026-10-05, `evidence/l115_cause_profile.txt`): `_preceding_comment` inside `_parse_vue_symbols` rescans all of the parent's children for each function, 3.127 s of a 3.353 s parse at 3000 functions, and the time is quadratic (0.87 s at 1500 functions, 3.27 s at 3000). Since L-116 every route skips and names such a file once its walk passes the budget; it is still slow below it. Not run: the Svelte parser's profile, Astro, Razor, a `<script setup lang="ts">` block. | `src/jcodemunch_mcp/parser/extractor.py` (`_parse_vue_symbols`, `_parse_svelte_symbols`) | defect | medium | FIXED 2026-10-06. Both walks now read one shared table (`_CommentBefore`), built in one pass per parent node, where each scanned the parent's children from the first one for every declaration. `evidence/l115_before_after.txt`, a 368,717-byte `.vue` of 6000 functions: `parse_file` 22.674 s on 1.108.330 and 0.176 s after, loop iterations 36,168,008 and 174,008; the same script as `.svelte` 22.703 s and 0.122 s. The symbol digest (ids, lines, signatures, docstrings) is equal before and after at 1500, 3000 and 6000 functions for both languages, so no `PARSER_GENERATION` bump. Guard: `tests/test_vue_svelte_comment_lookup_is_linear.py` counts loop iterations at two sizes (on 1.108.330 the ratio read 3.68 for Vue and 3.92 for Svelte against a bound of 2.6) and pins which comment belongs to which function. The review ran the old lookup against the table on every node of 15,402 trees (818,172 nodes) with 0 differences, and every `Symbol` field over 3,696 Vue and Svelte files with 0 differing files; it also measured the same quadratic cost on 1.108.330 under an options-API `methods` object, top-level `const`, `<script setup lang="ts">`, Svelte `export let` and `$:` (iteration ratios 3.97 to 3.99 at 1500 and 3000 declarations), each 2.00 after. A first index of both 6000-function files at the default budget: 1.108.330 skipped and named both, the fix indexed both (`evidence/l115_before_after.txt`, the `index_folder` half). Not run: Astro and Razor script walks; any Python but 3.12.4 on Windows. Not pinned by a test: that the table keeps its parent node (a variant holding only the id gave 6 wrong docstrings in a three-script `.vue` in the review's probe; a valid file has at most two). Unmeasured candidates of the same class: `node.children.index(...)` per item in the SQL `_build_signature` loop and in `_parse_groovy_symbols`. Found on the way: L-124. |
 | L-116 | 2026-10-04, L-114 review round 2 | The thread wait around `parse_file` (`parse_file_budgeted`, since 1.108.182) is what bounds a file's Python-side time, and it has four defects L-114 did not fix. (1) Every route asks it (`parse_and_prepare_incremental`, `parse_immediate` and `parse_and_prepare_full` in `tools/_indexing_pipeline.py`, reached from an incremental `index_folder`, `index_file` and `index_repo`) except `index_folder`'s full-index loop, so the same file is indexed by a first index and skipped by a re-index: L-115's Vue file at a 2 s budget was indexed with 6002 symbols and no warning after 14.91 s on a first index, and skipped and named after 4.27 s on a re-index (`evidence/l114_r2_python_side.txt`). (2) `worker.join(budget)` is wall-clock, so time another thread holds the GIL is charged to the file: a 201,780-char file that parses in 0.28 s alone was named over a 1 s budget in 10 of 60 calls beside one over-budget parse in a second thread (`evidence/l116_wait_two_threads.txt`). (3) The abandoned worker keeps running after the caller moved on, and after `index_folder` returns, and with `JCODEMUNCH_PARSE_CACHE` set it stores its result in the parse cache for a file the caller was told is skipped (`evidence/l116_worker_writes_cache.txt`: 0 rows when the wait expired, 1 after the worker ended); SECURITY.md's background-behaviour list had no line for it until the PR that added this row. (4) Its gate and its message count characters, where the parse limit's message counts bytes, so one file can be named in either unit. Routing the first index through the wait was tried in L-114's review round 1 and taken out in round 2, because (2) and (3) then reach the default route. A fix has to bound the worker's own time, not the waiter's clock. Not run: how often two parsing threads coexist in one server (the dispatcher's `asyncio.to_thread` plus the watcher). | `src/jcodemunch_mcp/tools/_indexing_pipeline.py` (`parse_file_budgeted`); `src/jcodemunch_mcp/tools/index_folder.py` | defect | medium | FIXED 2026-10-05. The wait is gone and no second thread replaces it: the parsing thread checks its own deadline at `parse_budget.checkpoint()`, which raises inside a `parse_file` call once the deadline has passed, and `parse_file` reads the deadline once more when its dispatch returns. So (1) every route and every size has the limit, (2) the clock is the parsing thread's own time, (3) there is no worker to abandon and a stopped file writes no parse-cache row, and (4) the message counts bytes. A cooperative limit holds only where a checkpoint is passed, and three review rounds each found a hole: round 1, seven dedicated walkers that build no symbol; round 2, three quadratic loops that are no recursion (call-site attribution in the generic path, a Razor brace scan, a dbt directive loop), one of which held a re-index 9.62 s at a 2 s budget, unnamed, under the first form of this fix where 1.108.329 released it at 2.03 s; round 3, a file whose time went into one regex call and which then passed fewer checkpoints than a clock read needs, returned unnamed. The rule is therefore over the source: every `for` and `while` statement in the six modules a parse runs through starts with a checkpoint, every function there that can call itself passes one, building a `Symbol` is one, three loops are exempt by name with a reason, and every module of `parser/` is classified on or off the path. L-115's Vue file at a 2 s budget: first index 2.86 s and re-index 2.85 s, both named, against 13.96 s indexed with no warning and 4.39 s on 1.108.329 (`evidence/l116_vue_first_index_and_reindex.txt`); 0 of 60 fast files named beside another thread's parse against 9 of 60 (`evidence/l116_two_threads.txt`); 0 parse-cache rows for the stopped file against 1 (`evidence/l116_parse_cache.txt`); round 2's three shapes stopped and named after 2.02, 2.01 and 2.27 s at a 2 s budget, where 1.108.329 held the Razor file 41.34 s unnamed and the dbt file 48.40 s (`evidence/l116_quadratic_shapes.txt`). SECURITY.md's abandoned-worker line is removed with the worker. Cost: `evidence/l116_checkpoint_cost.txt` (Python), `evidence/l116_checkpoint_cost_other_languages.txt`, `evidence/l116_symbol_build_cost.txt`. Guard: `tests/test_parse_budget_python_side.py` (26 reintroduced defects of 26 fail it, `evidence/l116_mutants.txt`). Not covered: one slow call passes no checkpoint and is not cut short (a regex over the whole file, also as the iterable of a `for`; a comprehension; PyYAML's loader, which is Python code outside the six modules); the file is named when the call returns. At a 0.5 s budget (`evidence/l116_one_call_shapes.txt`) a 140,000-byte EJS file held its caller 30.90 s (30.62 s on 1.108.329, whose wait could not cut a regex short either), an Astro file 11.16 s (11.21 s), a dbt file 23.63 s (23.76 s), and a 400,000-byte YAML list 1.87 s where 1.108.329's wait released its caller at 0.53 s with the load still running: the one measured case where a caller waits longer than before. With the deadline forced past as the C parse returned, 66 inputs of 400 KB and every language enabled, 55 were stopped and named (48 with the forced deadline in effect, none more than 0.12 s past it; 7 by the real 0.3 s budget alone) and 11 load no parser and returned (`evidence/l116_residue_probe.txt`, its own summary). Other limits of L-114's row stand. Not run: any OS or Python but Windows, 3.12.4. Found on the way: L-117, L-118, L-119. |
-| L-117 | 2026-10-05, L-116 review round 2 | Three Python loops on the parse path are quadratic in file size. Since L-116 a file is stopped and named at `JCODEMUNCH_PARSE_BUDGET_SECONDS`; below the budget the time is still spent, and at the default 20 s that is a long wait per file. (1) `_find_enclosing_symbol` rebuilds its list of symbol starts and scans it for every call site, in the generic path every spec language uses: a 309,590-byte Python file of 6,250 functions and 20,000 module-level calls ran 9.62 s under the first form of L-116's fix, which did not stop it. (2) `_extract_razor_brace_block` scans to the end of the file for each `@code {`: a 50,000-byte Razor file held its caller 41.34 s on 1.108.329. (3) The dbt directive loop (`sql_preprocessor.extract_dbt_directives`, `_extract_preceding_docstring`) searches backward per directive: a 25,000-byte `.sql` of open comments and macros took 48.40 s on 1.108.329. All three: `evidence/l116_quadratic_shapes.txt`. Not run: how often real files have these shapes; the Jinja template path through `template_shared.py`. | `src/jcodemunch_mcp/parser/extractor.py` (`_find_enclosing_symbol`, `_extract_razor_brace_block`); `src/jcodemunch_mcp/parser/sql_preprocessor.py` | defect | medium | OPEN |
+| L-117 | 2026-10-05, L-116 review round 2 | Three Python loops on the parse path are quadratic in file size. Since L-116 a file is stopped and named at `JCODEMUNCH_PARSE_BUDGET_SECONDS`; below the budget the time is still spent, and at the default 20 s that is a long wait per file. (1) `_find_enclosing_symbol` rebuilds its list of symbol starts and scans it for every call site, in the generic path every spec language uses: a 309,590-byte Python file of 6,250 functions and 20,000 module-level calls ran 9.62 s under the first form of L-116's fix, which did not stop it. (2) `_extract_razor_brace_block` scans to the end of the file for each `@code {`: a 50,000-byte Razor file held its caller 41.34 s on 1.108.329. (3) The dbt directive loop (`sql_preprocessor.extract_dbt_directives`, `_extract_preceding_docstring`) searches backward per directive: a 25,000-byte `.sql` of open comments and macros took 48.40 s on 1.108.329. All three: `evidence/l116_quadratic_shapes.txt`. Not run: how often real files have these shapes; the Jinja template path through `template_shared.py`. | `src/jcodemunch_mcp/parser/extractor.py` (`_find_enclosing_symbol`, `_extract_razor_brace_block`); `src/jcodemunch_mcp/parser/sql_preprocessor.py` | defect | medium | FIXED 2026-10-06. (1) `_attribute_calls_to_symbols` sweeps the calls once in offset order with the callables that have started on a stack, and looks a name up in a set; `_find_enclosing_symbol` is gone. (2) `_RazorBraceBlocks` shares one set of scans between every block of a file: a scan stops where an earlier one already was in the same state (code, a comment, a string). `_extract_razor_brace_block` is gone. (3) `extract_dbt_directives` reads line numbers, end tags and the comment above a directive from tables built once per file (`_PrecedingComments`); `_extract_preceding_docstring` is gone. Also five parsers (Razor, Astro, VHDL, Verilog, COBOL) numbered each symbol by counting newlines from the start of the file; they read one table (`_line_numbers`). `evidence/l117_before_after.txt`, `parse_file` with the budget off, `main` then the fix: the 418,340-byte Python file of 6250 functions and 20000 module-level calls 63.877 s and 0.593 s; a 50,000-byte Razor file of 6250 unclosed `@code {` 106.431 s and 0.031 s; a 26,890-byte `.sql` of 1000 open comments and macros 38.390 s and 0.089 s. Every field of every symbol is the same on both trees over 9830 files (5137 Razor, 285 SQL, 1081 Python; one digest), so no `PARSER_GENERATION` bump. Guard: `tests/test_parse_path_loops_are_linear.py` keeps the three old implementations as oracles; the fix must return what they return on generated input, and must finish a file twice as big before the oracle finishes the small one; loop iterations are counted at two sizes where a checkpoint sees them, and the characters the Razor scan searches are counted where it does not. Review round 1 (`evidence/l117_race_margins.txt`, `evidence/l117_r1_mutants.txt`): the first race, at eight times the size, lost under coverage's C tracer, which the 3.10 and 3.11 jobs use; the smallest margin measured under that tracer is now x7.1. The review also found a Razor file whose every `@code {` opens an unclosed comment still quadratic (5000 such blocks, 50,000 bytes: 80.791 s on `main`, 0.035 s now), and the VHDL, Verilog and COBOL copies of the newline count (10000 items: 0.757, 0.722 and 1.165 s on `main`; 0.068, 0.076 and 0.077 s now). Review round 2 (`evidence/l117_r2_sibling_pairs.txt`, `evidence/l117_r2_mutants.txt`): an unclosed block found its closing brace by stepping over every matched pair after it, once per block (4000 commented-out `@code {` lines then 4000 `{}` pairs, 52,000 bytes: 7.987 s after round 1, 0.045 s now); each brace keeps the answer now (`_closer_from`). And the guard passed with four of the per-item rescans put back, because a slice, a search and a list build pass no checkpoint and are too cheap to lose the race: the file now counts the characters the directive loop copies or searches and the line events of the call sweep at two sizes, and each of seven such mutants fails it. Not run: any Python but 3.12.4 on Windows; a Jinja or Twig corpus (the template path shares the dbt function and its equality test runs with the `macro`/`block` keywords). What is still superlinear: L-127. Found on the way: L-126. What the guard still cannot see: L-128. |
 | L-118 | 2026-10-05, L-116 review round 3 | Three regex calls over a whole file are superlinear on unclosed delimiters, and a regex call cannot be stopped part-way by the parse budget (it passes no checkpoint and holds the interpreter), so the caller waits for it and the file is named afterwards. At a 0.5 s budget (`evidence/l116_one_call_shapes.txt`): a 140,000-byte EJS file of `<% x` lines held its caller 30.90 s (`_EJS_SCRIPTLET_RE.finditer`), a 149,996-byte Astro file of `<!-- x` lines 11.16 s (the comment mask's `sub`), a 150,000-byte dbt `.sql` of `{% x` lines 23.63 s (`JINJA_PATTERN.sub`). The same on 1.108.329 (30.62, 11.21, 23.76 s). With the budget off the time about quadruples per doubling of the file: EJS 0.38, 1.47 and 6.50 s at 15, 30 and 60 KB, Astro 0.13, 0.54 and 2.01 s, dbt 0.29, 1.12 and 4.20 s (the same file's GROWTH lines). 61 `for` statements in the six parse-path modules iterate a `finditer`, `findall`, `split` or `splitlines` call, 57 of them in `extractor.py` (`evidence/l116_regex_iterables.txt`); each such call runs before its loop's checkpoint. Not run: which of those patterns can backtrack; any size above 150 KB. | `src/jcodemunch_mcp/parser/extractor.py` (`_parse_ejs_symbols`, the Astro comment mask); `src/jcodemunch_mcp/parser/sql_preprocessor.py` (`strip_jinja`) | defect | medium | OPEN |
 | L-119 | 2026-10-05, L-116 review round 2 | A Racket file with 12,500 nested parentheses (25,000 bytes) raises `RecursionError` out of `parse_file`, on 1.108.329 and after L-116 (`evidence/l116_one_call_shapes.txt`, first line of each half). The reader in `racket_reader.py` recurses per nesting level. What a user sees was not traced: whether the index names the file as a parse failure or loses it. Not run: the depth at which it starts; other recursive walkers on deeply nested input in other languages. | `src/jcodemunch_mcp/parser/racket_reader.py` | defect | low | OPEN |
 | L-120 | 2026-10-05, review of contributor PR #972 | A bare Python module name is resolved against the importer's script directory since #972 (`resolve_specifier`), and four spellings of the same dependency can still build no edge, so `find_importers` returns nothing for the target and `find_dead_code` can list it. (1) A dotted name through a directory with no `__init__.py`: `from helpers import util` beside a namespace `helpers/` (the branch is gated on a name with no dot; in a repo with no package the dotted form does resolve, through the source-root lookup). (2) A nested test directory importing a module that sits beside a `conftest.py` above it (`tests/unit/test_x.py` importing `tests/helpers.py` by bare name; pytest's rootdir insertion is not modelled). (3) A sibling that exists only as `.pyi`. (4) A real script directory kept inside a package (`pkg/tests/`, `pkg/demos/`): the follow-up commit on #972 refuses a directory with no `__init__.py` under a package at any level, because the same shape is a namespace sub-package where the edge is false (reproduced: `import openai` in `app/llms/openai/common_utils.py` resolved to an unimported `app/llms/openai/openai.py`, and `find_dead_code` then listed no dead file). The reviewer counted the branch's firings in the site-packages of this box's `C:\Program Files\Python310` (37,971 `.py`/`.pyi` files): 112 unguarded, 100 with the standard-library refusal, 47 with a refusal on the parent directory alone (round 1), 39 with the any-level refusal that shipped (round 2). Round 2 classed the 53 that the parent-only refusal drops as 39 plausible script edges and 14 names that are also an installed distribution, and the 8 more that the any-level refusal drops as one self-edge and 7 plausible script edges (`onnx/test/version_converter`, `pythonwin/pywin/Demos/app` and `ocx`). The standard-library refusal reads the SERVER's interpreter, so `distutils` is refused on 3.10 and not on 3.12. Also unmodelled: `-m` from the root, `PYTHONPATH`, and a standard-library name a script directory really does shadow. Not run: any corpus but that site-packages tree and this repo (58 new edges, all kept by both refusals). The counts are the review's probe output, not a file under `evidence/`. | `src/jcodemunch_mcp/parser/imports.py` (`resolve_specifier`) | gap | low | OPEN |
@@ -173,3 +173,10 @@ with jjg's reason. Keep the row. To promote a row to an issue, set Status to
 | L-122 | 2026-10-06, review of the #522 fix | `embed_repo` without `force` embeds only symbols that have no vector, keyed by symbol id, so a symbol whose body changed keeps the vector of its old body and a symbol that no longer exists keeps its row: no caller of `EmbeddingStore.delete_many` exists in `src/`. This was already so after an incremental re-index. After a full re-index it was hidden until #522's fix, because the full save erased the `embed_task_type` row and the `task_type` gate (#523) then re-embedded everything. Reviewer's probe (mocked provider): add one file, delete one, rewrite one body, full re-index, `embed_repo` with the same model: 5 symbols embedded and no orphan before the fix, 1 embedded, one orphan row and one stale vector after it, the same as the incremental path gives on both trees. `force=true` rebuilds. Not run: how similarity ranking moves with stale vectors on a real corpus. | `src/jcodemunch_mcp/tools/embed_repo.py`; `src/jcodemunch_mcp/storage/embedding_store.py` | defect | low | OPEN |
 | L-123 | 2026-10-06, CI on PR #980 | `tests/test_v1_108_225.py::TestCachedFreshnessIsRevalidated::test_a_revalidated_hit_does_not_corrupt_later_hits` failed once on `full: test (windows-latest, 3.11)` (run 37464102292, 1 failed of 14812, `a revalidated hit must be reproducible, not a one-shot correction`) and passed when that job was re-run with no change. The other seven matrix jobs of the same run passed, and the test passed in all five local full-tier runs of that branch that day. PR #980 changes which `meta` rows a full save deletes and touches nothing the test exercises (a commit, then two cached `search_symbols` reads of row freshness). The job log shows `assert 'fresh' != 'fresh'` under the failure: the assertion is `first_hit == second_hit != "fresh"`, so the two cached reads AGREED and both said `fresh` after the commit. The hits were reproducible; what failed is that neither read saw the commit, which points at freshness detection after `_commit_edit` (the index's stored HEAD against git's, or a cached HEAD read) and away from the cache write-through the test is named for. Cause not established beyond that. Not run: the test in a loop on a Windows runner. | `tests/test_v1_108_225.py` | flake | low | OPEN |
 | L-124 | 2026-10-06, L-115 fix | In a Vue or Svelte `<script>`, the docstring taken from a `/* block comment */` above a declaration keeps the closing delimiter: `/* block comment */` is served as `block comment */`. `_preceding_comment` strips leading `/` and `*` and never the trailing `*/`. Pinned as it is by `tests/test_vue_svelte_comment_lookup_is_linear.py` so that L-115's fix moved no docstring. A fix changes stored docstrings on unchanged files and needs a `PARSER_GENERATION` bump. The review ran three more: a JSDoc block keeps its inner ` * ` lines and the closing `*/`; `/**/` and `/***/` give the docstring `/`. All the same on 1.108.330. Not run: the same lookup in Astro. | `src/jcodemunch_mcp/parser/extractor.py` (`_preceding_comment` in `_parse_vue_symbols` and `_parse_svelte_symbols`) | defect | low | OPEN |
+| L-125 | 2026-10-06, CI on PR #984 | `tests/test_parse_budget_cancels.py::test_a_first_index_leaves_no_thread_behind` failed once on `full: test (windows-latest, 3.13)` (run 37517459287) and passed when that job was re-run with no change. PR #984 changes one package block of `uv.lock` and no code. The failing assertion is `result.get("symbol_count", 0) >= 2`, and the count read 1. The test indexes two files under a short real-time parse budget, one of them large, so a slow runner that spends the budget on the large file leaves one symbol: that reading fits the count and is not confirmed from the log. Second timing-sensitive test to fail once on a Windows runner that day (L-123 is the first). Not run: the test in a loop on a Windows runner. Second occurrence, 2026-10-07, PR #985: `full: test (ubuntu-latest, 3.10)` (run 37623527802), the same assertion (`assert (True is True and 1 >= 2)`, 1 failed of 14832), passed when that job was re-run with no change; the other seven matrix jobs passed. So it is not a Windows-runner effect. | `tests/test_parse_budget_cancels.py` | flake | low | OPEN |
+| L-126 | 2026-10-06, L-117 fix | A dbt macro (or a Jinja `macro`/`block`) that follows a `{# comment #}` is given the FIRST `{# ... #}` of the file as its docstring, whichever comment it follows. The lookup searches the text before the directive from the start of the file and takes the first match; it checks only that the text ends with `#}`. `evidence/l126_first_comment.txt` on `main`: `{# about first #}` above `first`, `{# about second #}` above `second` gives `second` the docstring `about first`. A macro under `--` lines is right. The L-117 fix keeps this as it was, so it moves no symbol field; fixing it changes docstrings on unchanged files and owes a `PARSER_GENERATION` bump. Not run: how many macros in a real dbt project sit under a second or later Jinja comment. | `src/jcodemunch_mcp/parser/sql_preprocessor.py` (`_PrecedingComments`) | defect | high | FIXED 2026-10-07 (`fix/l126-macro-docstring-comment`). `_PrecedingComments` lists the file's comments once, left to right, and a directive takes the one that ENDS where the text before it ends; a `#}` that closes no comment falls through to the `--` lines. `evidence/l126_before_after.txt`, `parse_file`, `main` then the fix: `second` read `about first` and reads `about second`; a `.j2` `button` read `renders a field` and reads `renders a button`. `PARSER_GENERATION` 10: the docstring moves on unchanged content. Guard: `tests/test_a_macro_docstring_is_the_comment_above_it.py`; the L-117 oracle test holds every field but the docstring to the old loop and the docstring to the rule. Review round 1: the dashes of `{#- ... -#}` were served as part of the docstring (`- about m -`, the same on `main` for a file's first comment); they are dropped, in the same generation, with Jinja's `+` and Twig's `~` (review round 2), one mark per side. What the rule still gets wrong: L-129, L-130, L-131. Not run: a dbt or Jinja corpus. |
+| L-127 | 2026-10-06, L-117 fix | Three shapes on the paths L-117 fixed are still superlinear; each time about quadruples when the file doubles, the same on `main` and after the fix (`evidence/l117_before_after.txt`, the residue lines, budget off). (1) Razor `@code {` blocks nested in each other: every block's body is parsed as C#, and an outer body holds the inner ones, so 150 nested blocks took 0.458 s and 300 took 1.846 s. Not valid Razor; a real file has one or two blocks. (2) The directive regex (`_directive_pattern`) on an unclosed `{% macro m(`: each one reads on for its `)`, so 2000 such lines took 0.681 s and 4000 took 2.577 s. One regex call, so the budget cannot stop it part-way: the L-118 class, and not in L-118's list. (3) A directive on a `--` line takes every `--` line above it as its docstring, so N macros each on its own `--` line produce docstrings that total N * N: 500 took 0.124 s and 1000 took 0.432 s. The output is that size by its own definition. | `src/jcodemunch_mcp/parser/extractor.py` (`_parse_razor_symbols`); `src/jcodemunch_mcp/parser/sql_preprocessor.py` (`_directive_pattern`, `_PrecedingComments.before`) | defect | low | OPEN |
+| L-128 | 2026-10-07, L-117 review round 3 | The count instruments of `tests/test_parse_path_loops_are_linear.py` wrap the spellings the old loops used and nothing else, so a per-item rescan in another spelling passes all 35 tests. The reviewer put five back into a copy of the fix and each stayed green: `text.rfind(...)`, `x in text`, `text.partition(...)` and a slice of the undecoded bytes per directive, and `list(callable_syms)` per call (one line event, however long the list). None of the five has been in the tree. A list membership test per call is seen by the wall-clock race alone. The durable form is a counted `str` that fails on any method it does not list. Also `monkeypatch.undo()` inside the two counting helpers undoes the autouse `_every_language_enabled` patch for the rest of that test; no caller parses a file after a helper today. | `tests/test_parse_path_loops_are_linear.py` (`_characters_read_by_the_directive_loop`, `_line_events`, `_characters_searched`) | test | low | OPEN |
+| L-129 | 2026-10-07, L-126 review round 1 | A Jinja comment that trails code on its own line is taken as the docstring of the directive on the NEXT line: `{% macro a() %}x{% endmacro %} {# end of a #}` then `{% macro b() %}` gives `b` the docstring `end of a`. The `--` branch requires a comment line to start with `--`; the Jinja branch asks only that the comment END where the text before the directive ends. The same on `main` when that comment is the file's first. `tests/test_a_macro_docstring_is_the_comment_above_it.py` pins the same-line reading (`{# a #} x {# b #}` gives `b`), so a fix inverts that case. ⚠ A fix moves stored docstrings on unchanged content and owes its own `PARSER_GENERATION` bump. | `src/jcodemunch_mcp/parser/sql_preprocessor.py` (`_PrecedingComments.before`) | defect | low | OPEN |
+| L-130 | 2026-10-07, L-126 review round 1 | The comment table of `_PrecedingComments` reads `{#` wherever it stands, an expression or a string included: `{% macro first() %}{{ '{#' }}{% endmacro %}`, then `{# about second #}`, then `{% macro second() %}` gives `second` the docstring `' }}{% endmacro %}` + newline + `{# about second` (code in a docstring). `main` gave `about first`: wrong before, wrong differently now. Jinja's own lexer reads `{{ ... }}`, `{% ... %}` and `{# ... #}` left to right, so a `{#` inside an expression opens no comment; `JINJA_PATTERN` in the same module already lexes that way. ⚠ A fix owes its own `PARSER_GENERATION` bump. | `src/jcodemunch_mcp/parser/sql_preprocessor.py` (`_PrecedingComments.__init__`) | defect | low | OPEN |
+| L-131 | 2026-10-07, L-126 review round 3 | The whitespace-control marks dropped from a Jinja comment's ends are the same three for every dialect (`-`, `+`, `~`), and `~` is a mark in Twig only, `+` in Jinja only. A comment whose text starts or ends flush against the delimiter with the other dialect's mark loses that character: in a `.sql`, `{#~approx 5 rows#}` reads `approx 5 rows`; a Twig `{#+1 to the offset #}` reads `1 to the offset`. One punctuation character, and only with no space beside the delimiter (`{# ~approx #}` is untouched). The exact form passes the dialect's marks in beside `directive_keywords`. ⚠ A fix owes its own `PARSER_GENERATION` bump. | `src/jcodemunch_mcp/parser/sql_preprocessor.py` (`_WHITESPACE_CONTROL_MARKS`, `_PrecedingComments.before`) | defect | low | OPEN |

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "jcodemunch-mcp"
-version = "1.108.331"
+version = "1.108.332"
 description = "Token-efficient MCP server for source code exploration via tree-sitter AST parsing"
 readme = "README.md"
 requires-python = ">=3.10"

{jcodemunch_mcp-1.108.331 → jcodemunch_mcp-1.108.332}/server.json

@@ -3,12 +3,12 @@
   "name": "io.github.jgravelle/jcodemunch-mcp",
   "title": "jCodemunch MCP",
   "description": "Token-efficient code exploration via tree-sitter AST parsing. 70+ languages, 86-99% token savings.",
-  "version": "1.108.331",
+  "version": "1.108.332",
   "packages": [
     {
       "registryType": "pypi",
       "identifier": "jcodemunch-mcp",
-      "version": "1.108.331",
+      "version": "1.108.332",
       "transport": {
         "type": "stdio"
       }