Back to list
noise-xyz

brane-impact

by noise-xyz

The Modern Ethereum SDK for Java

3🍴 1📅 Jan 23, 2026

SKILL.md


name: brane-impact description: Analyze change impact and discover affected tests. Use after making changes to understand what depends on the modified code, find relevant tests, and determine what to run.

Brane Impact & Test Discovery

Comprehensive impact analysis and test discovery for Brane SDK changes.


Module Dependency Graph

brane-primitives (no deps)
       |
       v
   brane-core (depends on: primitives)
       |
       v
    brane-rpc (depends on: core, primitives)
       |
       v
  brane-contract (depends on: rpc, core, primitives)
       |
       v
  [Consumer modules: examples, benchmark, brane-smoke]

Impact Propagation Matrix

Changed ModuleMust TestSeverity
brane-primitivesALL modulesHIGH
brane-corecore, rpc, contractHIGH
brane-rpcrpc, contractMEDIUM
brane-contractcontract onlyLOW
brane-examplesexamples onlyLOW

Quick Impact Analysis

Step 1: Identify Changed Files

# Recent commit
git diff --name-only HEAD~1 | grep '\.java$'

# Staged changes
git diff --cached --name-only | grep '\.java$'

# Working changes
git diff --name-only | grep '\.java$'

Step 2: Run Automated Analysis

# Full analysis with recommendations
./.claude/scripts/verify_change.sh

# Analyze specific file or class
./.claude/scripts/verify_change.sh Address
./.claude/scripts/verify_change.sh brane-core/src/main/java/sh/brane/core/types/Address.java

# Run with tests
./.claude/scripts/verify_change.sh --run

LSP-Enhanced Impact Analysis (Preferred)

Use cclsp MCP tools for precise, semantic impact analysis.

Why LSP > Grep

AspectGrep (text-based)LSP (semantic)
False positivesYes (comments, strings)No
Renamed importsMisses themFinds them
Qualified refsMay missFinds all
Accuracy~80%~99%

LSP Commands for Impact Analysis

# Find all usages of a symbol (MOST USEFUL)
mcp__cclsp__find_references(file_path, symbol_name)

# Find where a symbol is defined
mcp__cclsp__find_definition(file_path, symbol_name)

# Check for compile errors after changes
mcp__cclsp__get_diagnostics(file_path)

Example: Analyzing Impact of Changing Address.from()

# Step 1: Find all references to the method
mcp__cclsp__find_references(
  file_path="brane-core/src/main/java/sh/brane/core/types/Address.java",
  symbol_name="from"
)
→ Returns 47 locations across 12 files

# Step 2: Check if changes broke anything
mcp__cclsp__get_diagnostics(
  file_path="brane-core/src/main/java/sh/brane/core/types/Address.java"
)
→ Returns compile errors if signature is incompatible

When to Use LSP vs Grep

ScenarioUse
Public API changesLSP (precise reference count)
Method signature changesLSP (find all callers)
Class renamesLSP (safe refactoring)
Finding test files by nameGrep (pattern matching)
Quick text searchGrep (faster for simple cases)

Test Discovery Commands (Fallback)

Find Tests for a Changed Class

CLASS_NAME="Address"

# Direct unit test (same name)
find . -path "*/test/*" -name "*${CLASS_NAME}*Test.java" | grep -v target

# All tests that reference this class (less precise than LSP)
grep -rl "$CLASS_NAME" --include="*Test.java" . | grep -v target

# Integration tests
grep -rl "$CLASS_NAME" --include="*IntegrationTest.java" . | grep -v target

# Examples (integration tests in examples module)
grep -rl "$CLASS_NAME" brane-examples/src/main/java --include="*.java" | grep -v target

Module-Specific Test Commands

Module ChangedTest Command
brane-primitives./gradlew test (all)
brane-core./gradlew :brane-core:test :brane-rpc:test :brane-contract:test
brane-rpc./gradlew :brane-rpc:test :brane-contract:test
brane-contract./gradlew :brane-contract:test

Test Type Reference

Test TypePatternLocationRequires AnvilSkip?
Unit*Test.java*/src/test/java/NoNO
Integration*IntegrationTest.java*/src/test/java/YesNO
Examples*Example.javabrane-examples/src/main/java/YesNO
SmokeSmokeApp.javabrane-smoke/src/main/java/YesNO

Mandatory Test Layers

ALL THREE TEST LAYERS ARE MANDATORY. NEVER SKIP ANY.

LayerPurposeCommand
UnitLogic correctness, fast feedback./gradlew :module:test
IntegrationReal RPC calls, real transactions./scripts/test_integration.sh
SmokeFull E2E, consumer perspective./scripts/test_smoke.sh

Starting Anvil requires no special permission - just run anvil & in background.


Test Execution Order

Follow this order for every change:

Step 1: Unit Tests (Fast Feedback)

./gradlew :MODULE:test --tests "*ClassName*"
./gradlew :MODULE:test

Step 2: Downstream Unit Tests

./gradlew :downstream-module:test

Step 3: Integration Tests (Start Anvil First)

anvil &  # No permission needed
./scripts/test_integration.sh

Step 4: Smoke Tests

./scripts/test_smoke.sh

Full Verification (All at Once)

./verify_all.sh

Change Severity Categories

Note: Regardless of severity, ALL test layers (unit, integration, smoke) are MANDATORY.

HIGH Impact

  • Changes to brane-primitives (foundation)
  • Public API changes in brane-core (types, exceptions)
  • Changes to sealed exception hierarchy
  • Type signature changes (Address, Hash, Wei, HexData)

Action:

  1. Unit: ./gradlew test (all modules)
  2. Integration: ./scripts/test_integration.sh
  3. Smoke: ./scripts/test_smoke.sh

MEDIUM Impact

  • RPC client interface changes
  • Contract binding logic changes
  • Transaction builder changes
  • Internal utility changes in core

Action:

  1. Unit: Affected module + downstream modules
  2. Integration: ./scripts/test_integration.sh
  3. Smoke: ./scripts/test_smoke.sh

LOW Impact

  • Private method changes
  • Internal implementation details
  • Test-only changes
  • Documentation changes

Action:

  1. Unit: Direct tests + module tests
  2. Integration: ./scripts/test_integration.sh
  3. Smoke: ./scripts/test_smoke.sh

Cross-Module Test Examples

When Address (brane-core) Changes

Direct:     brane-core/.../types/AddressTest.java
Dependent:  brane-core/.../abi/AbiEncoderTest.java
            brane-rpc/.../BraneTest.java
            brane-contract/.../BraneContractTest.java
Integration: brane-examples/.../TransferExample.java

When Brane (brane-rpc) Changes

Direct:     brane-rpc/.../BraneTest.java
Dependent:  brane-contract/.../BraneContractTest.java
Integration: brane-examples/.../*Example.java

When BraneContract (brane-contract) Changes

Direct:     brane-contract/.../BraneContractTest.java
Integration: brane-examples/.../ContractExample.java

Execution Instructions for Claude

When asked to analyze impact or find affected tests:

Phase 1: Identify Changes

  1. Run git diff --name-only to find changed files
  2. Extract module names from paths
  3. Identify changed class/method names

Phase 2: LSP-Based Impact Analysis (PREFERRED)

For each changed public symbol, use LSP to find precise references:

mcp__cclsp__find_references(file_path, symbol_name)

This is MORE ACCURATE than grep because:

  • No false positives from comments/strings
  • Finds renamed imports and qualified references
  • Shows exact line numbers

Example workflow:

# Changed file: Address.java, changed method: from()
mcp__cclsp__find_references(
  "brane-core/.../Address.java",
  "from"
)
→ 47 references in 12 files

# Check for compile errors
mcp__cclsp__get_diagnostics("brane-core/.../Address.java")
→ No errors (or shows what broke)

Phase 3: Determine Module Impact

  1. Use the Impact Propagation Matrix to find affected modules
  2. Categorize severity (HIGH/MEDIUM/LOW)
  3. List transitive dependencies

Phase 4: Discover Tests

  1. From LSP references, filter for *Test.java files
  2. Find direct tests: find . -name "*ClassName*Test.java"
  3. Cross-reference with module dependency graph

Phase 5: Generate Report

Produce a report with:

  • Changed files summary
  • LSP reference count (e.g., "47 usages across 12 files")
  • Impact severity assessment
  • Affected tests (from LSP + file patterns)
  • Recommended test commands (minimal → full)

Phase 6: Optionally Execute

If --run is specified:

./.claude/scripts/verify_change.sh --run

CI/CD Integration

For automated pipelines (all three layers mandatory):

# Determine changed modules
CHANGED_MODULES=$(git diff --name-only origin/main | grep -oE 'brane-[a-z]+' | sort -u)

# Layer 1: Unit tests for affected modules
for MODULE in $CHANGED_MODULES; do
    ./gradlew ":${MODULE}:test"
done

# Layer 2: Integration tests (always run)
./scripts/test_integration.sh

# Layer 3: Smoke tests (always run)
./scripts/test_smoke.sh

All three layers must pass for CI to be green.

Score

Total Score

60/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

+10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

Reviews

💬

Reviews coming soon