Context
Found while doing phase-22 complexity remediation (titan-forge) on src/graph/algorithms/leiden/partition.ts and adapter.ts. Fixed the functions explicitly named in the gauntlet recommendation (moveNode, makeGraphAdapter/populateUndirectedEdges) plus the two other cognitive/cyclomatic-exceeding functions caught by the same violation (buildSortedCommunityIds, computeDeltaCPM).
computeDeltaModularityDirected (partition.ts) was not part of that recommendation and predates this phase (present before phase 3's shared-helper extraction and before phase 22). Current metrics:
computeDeltaModularityDirected: cognitive=10, cyclomatic=11 (exceeds cyclomatic, threshold is 10)
It has no directed/undirected branch to split (it's already the directed-only variant). Its complexity comes from four repeated newC < arr.length ? fget(arr, newC) [|| 0] : 0 bounds-checked-getter expressions. A generic fgetOrZero(arr, c) helper could reduce this, but two of the four call sites omit the || 0 fallback (totalInStrengthNew/totalOutStrengthNew) while the other two include it (inFromNew/outToNew) — unifying them risks a subtle behavior change (masking a NaN case the current code doesn't mask) that needs its own careful review, not a same-phase drive-by fix.
Ask
Decompose computeDeltaModularityDirected (or otherwise reduce its cyclomatic complexity below the threshold) in a dedicated pass, verifying the ||0 fallback inconsistency intentionally or fixing it with an explicit behavior note.
Scope note
Filed per project scope-discipline rule — out of scope for phase 22, not silently left undocumented.
Context
Found while doing phase-22 complexity remediation (titan-forge) on
src/graph/algorithms/leiden/partition.tsandadapter.ts. Fixed the functions explicitly named in the gauntlet recommendation (moveNode,makeGraphAdapter/populateUndirectedEdges) plus the two other cognitive/cyclomatic-exceeding functions caught by the same violation (buildSortedCommunityIds,computeDeltaCPM).computeDeltaModularityDirected(partition.ts) was not part of that recommendation and predates this phase (present before phase 3's shared-helper extraction and before phase 22). Current metrics:It has no directed/undirected branch to split (it's already the directed-only variant). Its complexity comes from four repeated
newC < arr.length ? fget(arr, newC) [|| 0] : 0bounds-checked-getter expressions. A genericfgetOrZero(arr, c)helper could reduce this, but two of the four call sites omit the|| 0fallback (totalInStrengthNew/totalOutStrengthNew) while the other two include it (inFromNew/outToNew) — unifying them risks a subtle behavior change (masking a NaN case the current code doesn't mask) that needs its own careful review, not a same-phase drive-by fix.Ask
Decompose
computeDeltaModularityDirected(or otherwise reduce its cyclomatic complexity below the threshold) in a dedicated pass, verifying the||0fallback inconsistency intentionally or fixing it with an explicit behavior note.Scope note
Filed per project scope-discipline rule — out of scope for phase 22, not silently left undocumented.