Pod

Yes, this is on purpose. Pod is built for agents, so the default page is plain HTML.
Human? View the normal website.
Agent? You probably prefer /mcp/jdocmunch-mcp/issues.md or /mcp/jdocmunch-mcp/issues.json, or Pod over MCP.

Reported issues for jDocmunch MCP

Pod holds 24 of 90 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to jDocmunch MCP.

Most discussed

PR #92 gate: independent final re-verification of QA-15 + QA-17 at a frozen SHA

Summary

This is a merge-closure QA review of the current coordinated-retirement branch, PR #92, following the lifecycle work tracked through #80 and #93.

The attached behavioral harness confirms two remaining failures at 99a31c1:

Plan hardening also identified related final-authority requirements that the current seven-case h

Read the thread · 2026-07-25 · closed · outside contributor · 18 comments

QA against PR #92: the QA-17 both-indexes-absent state is still reachable — retirement-record enrollment races

Summary

QA against PR #92 head e1ca39e41ef152a0aab394bc0a5425cada1ac272 confirms that the QA-17 invariant — no interleaving finishes with both participating indexes absent — is still breachable. The gate shipped for QA-17 is sound for operations that arrive after the retirement record exists. The remaining exposure is enrollment: work already in flight on the retained handle when the record is published never joins the record's coordination, on either side of it.

Driven to compl

Read the thread · 2026-07-24 · closed · outside contributor · 5 comments

BM25 tokenizer silently discards all non-ASCII text (Korean/CJK → zero tokens)

BM25 tokenizer silently discards all non-ASCII text

retrieval/tokenize.py splits on [^a-z0-9]+, so every non-ASCII character is treated as a separator and dropped. Korean/Japanese/Chinese content produces zero tokens, and accented Latin is mangled.

from jdocmunch_mcp.retrieval.tokenize import tokenize tokenize('초과근무 승인 규칙') # -> [] tokenize('OvertimeService 초과근무 계산') # -> ['overtime', 'service'] tokenize('café naïve') # -> ['caf', 'na', 've']

The module docst

Read the thread · 2026-07-23 · closed · external user · 5 comments

JDocMunch v1.115.0 Retirement Completion QA

Reviewed branch: coordinated-retirement
Reviewed commit: 0d22087

Current verdict

Most of the #89 corrections work as described, including recovery-record publication, stale-record cleanup, retained-handle record voiding, read-only report behavior, and the Linux stale-inode lock correction.

One high-severity coordination gap remains. Retirement coordinates writes and deletes on each individua

Read the thread · 2026-07-23 · closed · outside contributor · 6 comments

Pre-production v1.115.0 QA: lifecycle blockers and follow-up decisions

Reviewed branch: coordinated-retirement
Exact commit: a194d5b3d41d64972f2b569d134a132b853e5edd
Declared version: 1.115.0, unpublished

The QA-03 read-only report correction passed the expanded matrix. Ready, uncertified, no-peer, content-difference, ambiguity, and peer-disappearance outcomes all left the index store byte-for-byte unchanged.

One high-severity lifecycle failure and one medium-sev

Read the thread · 2026-07-23 · closed · outside contributor · 6 comments

Preliminary QA: refresh/retirement coordination, cleanup recovery, and read-only report mode

JDocMunch Preliminary QA: Refresh/Retirement Coordination, Cleanup Recovery, and Read-Only Report Mode

Review date: 2026-07-21 Installed package: JDocMunch 1.112.0
Reviewed source: a54730b8b6f2a1b8424f07674c53494968d1ba54

Executive summary

This preliminary QA pass found three reproducible gaps. The two High-severity findings share one cause: identity coordination prevents competing creation, but does not continue through refresh, reconciliation, retirement, and cleanup. Extending tha

Read the thread · 2026-07-22 · closed · outside contributor · 6 comments

JDocMunch opportunities for safer local-index identity and reuse

Summary

While reviewing repeated local documentation indexes, I found three related JDocMunch opportunities with existing JCodeMunch precedents:

Read the thread · 2026-07-18 · closed · outside contributor · 18 comments

After updating to v1.69.0, index_local hangs

I recently updated, and when using jdocmunch with Claude Code, index_local stopped working. I can run the CLI command just fine, and Claude can (I believe) utilize the various get_ stuff... but can no longer index. I've tried several things including deleting index and trying again, starting new sessions, reconnecting to MCP, and completely reinstalling jdocmunch... same result.

Not sure what more information would be useful to narrow this down - just let me know and I'll do me best!

Edit:

Read the thread · 2026-06-10 · closed · outside contributor · 4 comments

Most recent

Offline embeddings without PyTorch — a FastEmbed/ONNX provider (856 MB → 184 MB, identical vectors)

sentence-transformers is currently the only offline embedding provider, and it drags PyTorch in with it. On one real install that is 730 MB of an 856 MB venv — torch 506, scipy 82, transformers 59, sklearn 34, numpy 26, tokenizers 9, sentence_transformers 6, huggingface_hub 6, safetensors 2.

That weight is the root cause behind three issues already closed here:

Read the thread · 2026-08-27 · closed · external user · 2 comments

list_repos still parses generated sidecars after the #77 summary fix

Summary

At upstream commit 9235e228, which declares JDocMunch 1.133.0, DocStore.list_repos() treats the auxiliary JSON sidecars generated by index_local as possible legacy primary indexes. It opens and parses .terms.json, .related.json, .boilerplate.json, and .duplicates.json, then discards them when primary-index fields are absent.

This is residue from [“list_repos json-parses ever

Read the thread · 2026-08-17 · closed · outside contributor · 1 comment

watch-install cannot pass --no-ai-summaries to the watcher it installs, and re-running it silently reverts a hand-edited ExecStart

Summary

watch-install cannot express the flags that watch accepts, and _install_systemd() rewrites the unit on every run — so there is no supported way to run the doc watcher as a login service with AI summaries off.

watch --no-ai-summaries works in the foreground. The service installer wraps that same daemon and cannot pass it through.

Observed on v1.133.0 (9235e228bb1fd1fc98fec2aaf6d494f8c54f3000, current master HEAD at time of writing).

This is the login-service half of #10

Read the thread · 2026-08-16 · closed · external user · 1 comment

index-local CLI silently discards a stored corpus selection it has no flag to express: a plain re-index re-admits files that extra_ignore_patterns had excluded

index-local CLI silently discards a stored corpus selection it has no flag to express: a plain re-index re-admits files that extra_ignore_patterns had excluded

Summary

The MCP index_local tool accepts extra_ignore_patterns; the jdocmunch-mcp index-local CLI does not. Because the CLI passes no patterns, its call computes a full corpus selection and overwrites the stored narrower selection, silently re-admitting every file the operator had deliberately excluded.

This is the

Read the thread · 2026-08-10 · closed · external user · 2 comments

watch bypasses the source root's .gitignore for changed documentation files

The one thing that is wrong

After a full index excludes a documentation file through the source root's .gitignore, jdocmunch-mcp watch can add that file when it changes.

Reproduction

Use two PowerShell sessions and new fixture and storage paths so the reproduction cannot touch an existing index. In the first session, run this exact setup. It stops instead of reusing either path:

$env:DOC_INDEX_PATH = "C:\tmp\jdoc-watch-ignore-index"
$env:JDOCMUNCH_EMBEDDING_PROVIDER =

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/115) · 2026-08-09 · closed · external user · 1 comment

### No local/self-hosted summarizer target: every valid summarizer provider is remote cloud, so private corpora cannot have AI summaries at all

# No local/self-hosted summarizer target: every valid summarizer provider is remote cloud, so private corpora cannot have AI summaries at all

## Summary

`JDOCMUNCH_SUMMARIZER_PROVIDER` accepts only cloud providers. There is no
openai-compatible / custom-URL option, so a self-hosted model (Ollama, llama.cpp,
vLLM, LM Studio) cannot be used. For a private corpus the only choices are
"no AI summaries" or "send every section to a third party".

This is asymmetric with the **embedding** side, which

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/112) · 2026-08-09 · closed · external user · 1 comment

### Embed input is hard-capped at 1000 chars: 41% of a 778k-token corpus never reaches the model, and larger-context models cannot be exercised

# Embed input is hard-capped at 1000 chars: 41% of a 778k-token corpus never reaches the model, and larger-context models cannot be exercised

## Summary

`_section_embed_text` truncates section content to a hardcoded 1000 characters before
embedding. On a real corpus this discards a large fraction of the text, and because the
cap (~250 tokens) sits just below `all-MiniLM-L6-v2`'s 256-token window, it also makes
larger-context embedding models nearly pointless — the text never reaches their wind

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/111) · 2026-08-09 · closed · external user · 1 comment

### Embedding provider is initialized eagerly at MCP startup: ~7.6 s added to every server start, and an uncached model pushes the handshake past the client's 30 s timeout

# Embedding provider is initialized eagerly at MCP startup: ~7.6 s added to every server start, and an uncached model pushes the handshake past the client's 30 s timeout

## Summary

`jdocmunch-mcp serve` initializes the sentence-transformers embedding provider before it
answers the MCP `initialize` handshake. This costs ~7.6 s on every server start even when
the model is fully cached and no embedding tool is ever called. When the configured model
is **not** yet in the local HuggingFace cache, t

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/110) · 2026-08-09 · closed · external user · 2 comments

### Embedding-model rotation with no source changes leaves the index unqueryable: incremental `index_local` reports success, keeps the old vectors, and every subsequent search fails with a 768-vs-384 matmul error

# Embedding-model rotation with no source changes leaves the index unqueryable: incremental `index_local` reports success, keeps the old vectors, and every subsequent search fails with a 768-vs-384 matmul error

## Summary

Changing the embedding model (e.g. `JDOCMUNCH_ST_MODEL`) and re-indexing a corpus whose
**source files have not changed** silently leaves the old vectors on disk. The run reports
`success: true`. Every search afterwards fails with a dimension-mismatch error, and the
only reco

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/109) · 2026-08-09 · closed · external user · 1 comment

### Incremental index_local destroys the embedding cache for untouched sections (5316 vectors -> 21); embed_sections rewrites the sidecar from only the sections it was handed

## Summary

An incremental `index_local` refresh destroys the embedding cache for every section it did not itself materialize. `embed_sections` rewrites the whole sidecar from the `sections` it was handed, and on an incremental refresh that is only the changed documents' sections.

Observed three times on a real 5,300-section corpus: the sidecar went from **5,316 vectors to 21**, then (after a rebuild) to **224**, then on a second index to **48**. Each time the run exited 0 with no warning. Sema

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/107) · 2026-08-08 · closed · external user · 1 comment

### Default semantic_weight=0.5 measures worse than disabling semantic search on a 5.3k-section corpus (0/15 paraphrase queries); 0.85 fixes it with no keyword cost

## Summary

On a 5,315-section Markdown corpus, the stock `semantic_weight = 0.5` measured **worse than disabling semantic search entirely** for paraphrased queries: 0/15 answered in the top 5, versus 1/15 for pure BM25. Raising it to the `SEMANTIC_WEIGHT_BOUNDS` ceiling of 0.85 takes the same queries to 5/15 with **no** loss on keyword queries.

Not filing this as a defect — 0.5 is a defensible starting point and the tuner exists precisely to move it. But the failure is silent and points the wr

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/106) · 2026-08-07 · closed · external user · 2 comments

### verify_index may be verifying the cached raw mirror rather than the current live source

Opening

I’d like to document what looks to me like a possible verify_index bug, or at least a verification-contract mismatch, for confirmation.

I may be missing an intended distinction in the current design, so I’m reporting the observed behavior rather than assuming the implementation is wrong.

In a controlled local fixture, I indexed four Markdown files, then left one unchanged, deleted one, modified one while preserving its byte length, and truncated one without reindexing. verify_index co

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/105) · 2026-08-07 · closed · external user · 2 comments

### Unknown tool arguments are silently ignored: get_toc{doc_path:...} returns the whole-corpus TOC instead of erroring

## Summary

Tool calls with an unrecognized argument name succeed and ignore the argument, rather than returning an error. For scoping arguments this turns a typo into a whole-corpus response — the exact outcome the server exists to avoid.

## Repro

`get_toc` accepts `repo` and `path_glob`. Passing `doc_path` (the parameter name used by `get_document_outline`, and the natural guess) returns the **entire corpus TOC**:

```jsonc
// request
{"name": "get_toc", "arguments": {"repo": "local/autosort

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/104) · 2026-08-07 · closed · external user · 1 comment

### index_local is O(n^2.3) in section count: all-pairs Jaccard in retrieval/dedup.py::detect_clusters is 85% of index time, runs unconditionally with no opt-out

## Summary

`index_local` wall-clock grows as roughly **O(n^2.3)** in section count. Profiling attributes ~85% of it to the near-duplicate sidecar `retrieval/dedup.py::detect_clusters`, which is an all-pairs Jaccard comparison with a length pre-filter. It runs unconditionally on every index and has no opt-out.

This is a **different site** from the two closed O(N²) issues — #14 (`related_persist.build`) and #62 (related-graph semantic cosine). Both of those are fixed; this one is reached with em

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/103) · 2026-08-07 · closed · external user · 1 comment

### index_local does not prune gitignored dot-directories: lstrip("./") eats the leading dot (.venv/, .worktrees/ get indexed)

## Summary

`index_local` does not prune gitignored directories whose name begins with a dot. `.venv/`, `.tox/`, `.next/`, `.cache/`, and (in my case) `.worktrees/` are walked and indexed even though `.gitignore` lists them and `git check-ignore` agrees.

Root cause is `str.lstrip("./")`, which strips a **character set**, not a prefix — so the leading dot of the first path component is eaten and the resulting path no longer matches the pattern.

## Repro

Undotted ignored dir — **correct**:

```

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/102) · 2026-08-07 · closed · external user · 1 comment

### search_sections: ~44% of each result is bytes the caller can't use, and no content snippet forces a get_section round-trip

**Version:** jdocmunch-mcp 1.120.0 (Windows 11, stdio transport, local markdown indexes)

## Summary

`search_sections` results carry ~44% bytes that the calling agent can never use, and no content snippet — so even a perfect top hit forces a `get_section` round-trip. Both together make the common search→read loop roughly twice as expensive in tokens as it needs to be.

## Measured breakdown (one representative result, 1,114 chars ≈ 278 tokens)

| field | chars | why it's dead weight for the cal

[Read the thread](https://github.com/jgravelle/jdocmunch-mcp/issues/101) · 2026-08-02 · closed · external user · 2 comments

The remaining reports are on [the project's issue tracker](https://github.com/jgravelle/jdocmunch-mcp/issues).