pi_mcps/zoo_backup/work/rules/skills/skill-impact-analysis.md

Skill: impact-analysis

Analyze impact of changes to shared modules across the PAISY monorepo.

Invoked by

📋 Planner mode (or 🔍 Reviewer mode)

Required Inputs

Input	Source	Example
TICKET_KEY	Jira issue key	ESIDEPAISY-12081
CHANGED_MODULE	Module being changed	persistence, sv-common, flatfile-parser, paisy-common
CHANGED_API	Changed class/method (optional)	EMFactory.getLeftoverSchemas(), AbstractMeldung.initBaustein()

Output

• Impact summary with affected modules, files, and risk level
• Stored in BigMind for future reference

Steps

1. Identify the changed module's artifact

grep -A2 '<artifactId>' java/modules/cs-modules/<CHANGED_MODULE>/pom.xml | head -3
# Or for shared modules:
grep -A2 '<artifactId>' java/modules/<CHANGED_MODULE>/pom.xml | head -3

Extract the groupId and artifactId for dependency searching.

2. Find dependent modules (reverse dependency lookup)

# Search all module POMs for the changed artifact
grep -rn "<artifactId><CHANGED_MODULE></artifactId>" java/modules/cs-modules/*/pom.xml
grep -rn "<artifactId><CHANGED_MODULE></artifactId>" java/modules/*/pom.xml

Or use Maven dependency tree for a specific consumer:

cd /Users/pplate/git/paisy-<TICKET_KEY>
mvn dependency:tree -pl java/modules/cs-modules/<consumer_module> -DoutputType=text -f java/pom.xml | grep <CHANGED_MODULE>

3. For each dependent module, check API usage

# Search for usage of the changed class/method
grep -rn "ChangedClass\|changedMethod" java/modules/cs-modules/<dependent_module>/src/

# For import-level analysis
grep -rn "import.*<package>.<ChangedClass>" java/modules/cs-modules/*/src/main/java/

4. Classify impact per module

For each dependent module, determine:

Impact Level	Criteria	Action
🔴 High	Direct API consumer, method signature changed	Must update + test
🟡 Medium	Uses the module but not the changed API directly	Verify compilation, run tests
🟢 Low	Transitive dependency only, no direct usage	Monitor, no action needed
⚪ None	Not a dependency	Skip

5. Check for test coverage in dependent modules

# For each high/medium impact module, check if tests exist
find java/modules/cs-modules/<dependent_module>/src/test -name "*Test.java" | wc -l

# Check if the dependent module's tests use the changed API
grep -rn "ChangedClass\|changedMethod" java/modules/cs-modules/<dependent_module>/src/test/

6. Verify compilation across affected modules

cd /Users/pplate/git/paisy-<TICKET_KEY>
# Compile all affected modules without running tests
mvn compile -pl java/modules/cs-modules/<module1>,java/modules/cs-modules/<module2> -am -f java/pom.xml

7. Generate impact report

Present the findings as a structured summary:

# Impact Analysis: <TICKET_KEY> — <Changed Module>

**Datum:** <today>
**Geändertes Modul:** <CHANGED_MODULE>
**Geänderte API:** <CHANGED_API>

---

## Abhängige Module

| Modul | Impact | Direkte Nutzung | Dateien | Aktion |
|-------|--------|----------------|---------|--------|
| `eau` | 🔴 Hoch | `EMFactory.getLeftoverSchemas()` in `Center.java` | 2 | Update + Test |
| `eubp` | 🟡 Mittel | Nutzt EMFactory, aber nicht geänderte Methode | 1 | Kompilierung prüfen |
| `svmeldungen` | 🟢 Niedrig | Transitive Abhängigkeit | 0 | Monitoring |

## Betroffene Dateien (Detail)

### 🔴 eau
- `java/modules/cs-modules/eau/src/main/java/main/Center.java:142` — calls `EMFactory.getLeftoverSchemas()`
- `java/modules/cs-modules/eau/src/test/java/main/CenterTest.java:55` — tests the call

### 🟡 eubp
- `java/modules/cs-modules/eubp/src/main/java/main/EuBPCenter.java:88` — imports EMFactory

## Risikobewertung

| Risiko | Wahrscheinlichkeit | Auswirkung | Mitigation |
|--------|-------------------|------------|------------|
| Kompilierungsfehler in eau | Hoch | Hoch | Sofort anpassen |
| Laufzeitfehler in eubp | Niedrig | Mittel | Tests ausführen |

## Empfehlung

<Summary of recommended actions>

8. Store in BigMind

memory_store_fact(
    category="codebase",
    fact=f"{TICKET_KEY}: Impact analysis for {CHANGED_MODULE} — {high} high, {medium} medium, {low} low impact modules."
)
memory_append_chunk(
    session_id=SESSION_ID,
    content=f"Impact analysis for {CHANGED_MODULE} change in {TICKET_KEY}:\n<detailed findings>",
    flag_reason="impact analysis"
)

Expected Output

• Clear list of affected modules with impact levels
• Specific file:line references for high-impact usages
• Compilation verification results
• Risk assessment with mitigation recommendations
• BigMind fact stored

Error Handling

Error	Resolution
Module not found in POM	Check if it's a parent module or uses a different artifactId
Too many dependents (>10)	Focus on high-impact only, list others as "low" without detail
Compilation fails	Document the failure as part of the impact — it confirms the impact is real
No tests in dependent module	Flag as risk — untested dependency on changed API

Common Shared Modules

Module	Typical Dependents	Risk Profile
persistence	All modules with DB access	High — EMFactory, FlywayController
sv-common	All SV-Meldeverfahren modules	High — shared SV logic
flatfile-parser	Modules reading DSRV/ITSG files	Medium — parsing infrastructure
paisy-common	Nearly all modules	Very High — core utilities
message-broker	Modules using NATS	Medium — async messaging

Language

• Impact report: German
• Code references (class names, methods, file paths): English as-is
• BigMind facts: English