# 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

```bash
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)

```bash
# 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:
```bash
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

```bash
# 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

```bash
# 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

```bash
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:

```markdown
# 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

```python
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