my observations #81
|
Hello, Here is my observation: outputs of
|
| Command | Coverage shown | Meaning |
|---|---|---|
--report |
D (39%) — 51/131 | Files that had ≥1 extractable signature |
--health |
A (100%) — 131/131 | Files that were successfully scanned |
Health score 100/100 (A) is the correct signal — sigmap successfully processed all files.
The D-grade from --report reflects that 80 of 131 files have zero extractable signatures (they're non-code files).
--health also shows extractor coverage: 14.3% — sigmap's parsers only recognize 14.3% of file types in the project, which is expected (the rest are JSON, YAML, shell, markdown, etc.).
What Does NOT Work
autoMaxTokens: true— auto-scales to the 4000-token floor for small repos regardless ofmodelContextLimitormaxTokensmonorepo: true(sigmap 5.4.0) — processes each srcDir as a separate project, writes per-package.github/context-*.mdfiles andAGENTS.mdinside eachpkgs/*/dir; root AGENTS.md gets only overview summaries that Claude Code cannot deep-readstrategy: "per-module"+monorepo: true— creates deeply nested context files Claude Code never sees- Raising
maxTokensbeyond ~5000 — has no effect since only ~2665 tokens are actually used
Key Sigmap Behavior (v5.4.0)
- Files with 0 extractable signatures are excluded before budget enforcement (gen-context.js line 7763)
- Budget enforcement only drops lowest-priority files when total > budget
diffPriority: true(default) ranks recently-changed files higher but does not exclude stable files when budget is availablestrategy: "full"+monorepo: falseproduces a single root AGENTS.md — the correct target for Claude Code
======================================= endd of claude findings ===============================
Conclusion?
If I understand correctly, I should NOT worry about low coverage in --report output, right?
sigmap's parsers only recognize 14.3% of file types in the project, which is expected (the rest are JSON, YAML, shell, markdown, etc.).
Maybe my use of Sigmap isn't ideal, but since I'm new and cautious I want to adopt Sigmap into my project gradually — only the basic features for now; I may add advanced features later.
Replies: 1 comment
|
Hi @lukasMega — great analysis, and Claude gave you exactly the right answer! Short answer: Your config is correct and you should not worry about the D (39%) coverage. Why the numbers differ: --health coverage (A, 100%) = "how many files in your srcDirs could sigmap even see?" — this is computed by passing all found files as fake "included" entries, so it's always 100%. On ← attention needed: This flag means a module has <50% file coverage. In your case it's expected — most of those are non-code files. I'm going to fix the output to explain this rather than leaving you to guess. Recommended config for gradual adoption (what you already have is good): { |
Hi @lukasMega — great analysis, and Claude gave you exactly the right answer!
Short answer: Your config is correct and you should not worry about the D (39%) coverage.
Why the numbers differ:
--health coverage (A, 100%) = "how many files in your srcDirs could sigmap even see?" — this is computed by passing all found files as fake "included" entries, so it's always 100%.
--report coverage (D, 39%) = "of all files sigmap found, how many produced at least one extractable signature?" — the 80 missing files are package.json, tsconfig.json, README.md, .config.ts etc. that sigmap's extractors don't support.
Your actual output is healthy: 51 files, 195 symbols, ~2665 tokens, well under your 5000 …