Expose --depth's node-discovery cap as --max-depth-nodes - #22
Merged
Conversation
The 200-node safety cap on --depth traversal was a fixed constant the code explicitly flagged as "not exposed as a flag (yet)". Mirrors the existing --max-symbols pattern (same validation, same rejection when combined with --architecture) so a well-connected symbol that legitimately needs a higher cap to finish at --depth 3+ can get one. Default behavior is unchanged.
The cap stopped being internal-only in the previous commit --max-depth-nodes made it externally configurable, but the stderr message, USAGE.md, and TECHNICAL.md still called it "internal", undercutting the flag that answers it. Points users at --max-depth-nodes instead.
Two issues from code review: - The --architecture rejection now only fires when the explicit value differs from the default (200), matching --depth's own precedent (values.depth !== '1'). Previously any explicit --max-depth-nodes was rejected outright, even one matching the default, disagreeing with --depth's "only reject if it would actually change anything" behavior for what should be an identical contract. - TECHNICAL.md's config row claimed "same rationale as --max-symbols" in a way that implied enforcement parity that doesn't exist: --max-symbols has no guard at all outside --architecture (silently ignored), while --max-depth-nodes hard-errors on a real mismatch inside --architecture. Reworded to credit --max-symbols only for the "why expose this as a flag" reasoning, and --depth for the actual --architecture-rejection precedent.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
--depth's 200-node traversal safety cap was a fixed constant the code comment flagged as "not exposed as a flag (yet)" — now--max-depth-nodes <n>(default 200), mirroring the existing--max-symbolspattern (same validation, rejected alongside--architecture).Test plan
npm test— 90/92 pass. The 2 failures (--architectureend-to-end + embed round-trip) are pre-existing and unrelated — reproduced identically on unmodifiedmasterviagit stash, likely a local codegraph 1.5.0 vs. CI-pinned 1.4.1 version drift. Tracked separately.--architecturecombo rejection, and a live CLI trace against this repo's own codegraph index proving a lowered cap actually firesdepthBudgetWarning.--architecturecombo rejected).