feat: add blast radius analysis with risk scoring#148
feat: add blast radius analysis with risk scoring#148maplenk wants to merge 9 commits intoDeusData:mainfrom
Conversation
|
Thanks @maplenk — blast radius analysis would be very useful for impact assessment. Will review. |
Account for optional signatures in the search_graph and trace_call_path size estimators, and improve compact trace chains to report omitted-node counts. This also documents the normal-path output enrichment introduced with Task 4: search_graph results now include file_path, start_line, end_line, and signature, and trace_call_path hop items now include file_path, start_line, and signature.
- Guard cbm_mcp_text_result() against NULL text - Fix memory leak in handle_get_key_symbols() REQUIRE_STORE path (focus not freed) - Wire qn_pattern through handle_search_graph() - Fix OOM infinite loop in markdown_builder_reserve() - Return 0 instead of CBM_STORE_ERR from summary_count_nodes() on prepare fail Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Prefer non-test symbol matches before pagerank for ambiguous short names. Batch-load visited node metadata and pagerank scores to remove per-node query loops during impact analysis. Hide test counts from the public summary when include_tests=false, and add max_tokens truncation support to get_impact_analysis with MCP coverage.
Add the impact-analysis store API declaration, expose get_impact_analysis in CLI help text, and cover the tool with the existing integration fixture.
- Chunk impact_fetch_nodes_with_scores() into batches of 900 to stay under SQLite's SQLITE_MAX_VARIABLE_NUMBER bind limit - Replace REQUIRE_STORE in handle_get_impact_analysis() with explicit cleanup that frees symbol on early return - Fix pre-existing test_integration assertion that used escaped JSON field matching (was already failing on origin/feat/blast-radius) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
maplenk
force-pushed
the
feat/blast-radius
branch
from
5c5517c to
31de109
Compare
|
@maplenk — I've updated the CONTRIBUTING.md with clearer guidelines. The key one: please open an issue first to discuss the feature before implementing it. This applies to all feature PRs. I appreciate the effort, but submitting fully implemented features without prior discussion makes it much harder to align on whether the feature is needed, how it should work, and whether it fits the project's direction. It also increases the likelihood that the PR gets closed. Could you open an issue describing the use case for blast radius analysis? I'd like to discuss the approach before any code is written. |
|
Thanks @maplenk! The blast radius / test coverage idea was useful. We took the core insight — "which tests are in the blast radius?" — and added it to the existing
This avoids the need for a separate Closing since the useful parts are merged. Thank you for the contribution! |
2 participants
Summary
New
get_impact_analysistool that answers "what breaks if I change this function?" with risk-tiered results and test coverage detection.New tool:
get_impact_analysisParameters:
project,symbol,depth(default 3),include_tests(default true),max_tokens(default 2000)Key features
cbm_store_bfs().Tests
New tests in
test_store_search.c(risk tiers, routes+tests, disambiguation) andtest_mcp.c(basic, missing symbol, disambiguation, include_tests, route typing).Part 2 of a 4-PR series. Depends on #147.
Built with OpenAI Codex and Claude Code.