# Sprint 10 Plan Review v3 — 6-Expert Panel (Final)

**Date:** 2026-06-15
**Reviewer:** Lumen (Architect) — Multi-Expert Panel
**Documents reviewed:**
- `cannamanage-sprint10-analysis.md` v1
- `cannamanage-sprint10-plan.md` v3
- `cannamanage-sprint10-testplan.md` v1

**Verdict:** ✅ APPROVED
**Panel Confidence:** 99% (exceeds 95% threshold)

---

## Changes v2 → v3

7 of 12 info items from the v2 review were incorporated into plan v3. The remaining 5 were deliberately excluded (either already correct as-is, deferred to Sprint 11, or not applicable).

| # | Info Item | Source | Resolution in v3 |
|---|-----------|--------|-------------------|
| 1 | Century boundary constant for MT940 dates | Domain #1 | ✅ Added `CENTURY_BOUNDARY = 70` constant with Javadoc explaining standard banking convention |
| 2 | Skip proprietary headers before first `:20:` tag | Domain #2 | ✅ Added pre-parse header stripping for StarMoney/WISO/Hibiscus portal exports |
| 3 | Duplicate session detection | Architecture #2 | ✅ Added `checkDuplicateImport()` method — checks filename+club within 24h, returns 409 Conflict with existing sessionId for frontend confirmation dialog |
| 4 | Double-payment scenario handling | Testing #2 | ✅ Added explicit logic: if same member matches 2+ transactions in one file, all are downgraded to SUGGESTED status regardless of individual confidence score |
| 5 | Constructive tier restriction messaging | UX #2 | ✅ Upload step now specifies helpful guidance text with alternative suggestions and "Plan vergleichen" link, never punitive language |
| 6 | Fee schedule validity date context | Integration #2 | ✅ `precomputeFeeAmounts()` now accepts `bookingDateContext` parameter — queries fee assignments valid at the transaction date, not today's date |
| 7 | Session immutability after completion (GoBD) | GoBD | ✅ Added `assertSessionMutable()` guard called by all mutation endpoints. Throws `IllegalStateException` for COMPLETED sessions. Explicit GoBD compliance. |

**Deliberately excluded (correct as-is or deferred):**

| # | Info Item | Reason for exclusion |
|---|-----------|---------------------|
| 8 | CsvBankParser interface deviation | Already acknowledged as acceptable in v2 review — explicit delegation pattern |
| 9 | Performance test for 5000+ transactions | Explicitly Sprint 11 scope — production observability (timing log) is sufficient for Sprint 10 |
| 10 | Payment void → FK behavior | Already correct as-is per v2 review — ON DELETE SET NULL handles it |
| 11 | Mobile horizontal scroll | Acceptable for admin-only feature — not a user-facing portal page |
| 12 | Running totals already in v2 | Already implemented in v2, reviewer noted it was addressed |

---

## Panel Composition

| # | Expert | Perspective | Focus Area |
|---|--------|-------------|------------|
| 1 | 🏛️ Domain Expert (German Vereinsrecht + Finance) | Legal compliance, financial regulations, German banking standards | §147 AO, DSGVO, MT940/CAMT standards, GoBD |
| 2 | 🔧 Architecture Expert | System design, patterns, scalability | Service decomposition, data model, API design |
| 3 | 🛡️ Security & Privacy Expert | Data protection, input validation, attack surface | GDPR, file upload security, IBAN handling |
| 4 | 🧪 Testing Expert | Test coverage, edge cases, quality assurance | Test completeness, fixture quality, E2E coverage |
| 5 | 💼 UX/Product Expert | User workflows, accessibility, error states | Import wizard UX, error recovery, progressive disclosure |
| 6 | ⚙️ Integration Expert | System integration, backward compatibility, performance | Existing finance module, notifications, retention |

---

## Expert 1: 🏛️ Domain Expert (German Vereinsrecht + Finance)

**Confidence:** 99%

### Verdict: ✅ APPROVED

### Strengths (carried from v2)
- **§147 AO compliance** correctly identified: 10-year retention for Buchungsbelege.
- **GoBD compliance** preserved: append-only LedgerEntry pattern continues.
- **DSGVO Art. 6(1)(a)** correctly applied for IBAN storage with explicit consent type.
- **MT940/CAMT.053/CSV format knowledge** is accurate and comprehensive.

### v3 Improvements Assessed
- **Century boundary constant** (✅): `CENTURY_BOUNDARY = 70` is the standard SWIFT convention. Documenting it with a named constant prevents future developer confusion. Good practice.
- **Proprietary header skipping** (✅): Real-world necessity — StarMoney, WISO Mein Geld, and Hibiscus all add proprietary headers. Without this, users get parse failures and blame the software. Excellent robustness improvement.
- **Session immutability** (✅): The explicit `assertSessionMutable()` guard makes GoBD compliance programmatically enforced rather than implicit. This is defense-in-depth for Unveränderbarkeit — an auditor can now point to a specific code guard.

### Findings

| # | Severity | Finding | Recommendation |
|---|----------|---------|----------------|
| — | — | No findings. All v2 info items resolved or correctly excluded. | — |

---

## Expert 2: 🔧 Architecture Expert

**Confidence:** 99%

### Verdict: ✅ APPROVED

### Strengths (carried from v2)
- Strategy pattern, service decomposition, transaction boundary discipline, batch persistence all remain excellent.

### v3 Improvements Assessed
- **Duplicate detection** (✅): `checkDuplicateImport()` is a clean, focused guard with 409 Conflict response. Frontend can show a confirmation dialog — standard UX pattern for "are you sure?" without blocking power users who intentionally re-import.
- **Fee schedule validity date** (✅): Critical correctness fix. A January import reviewing December transactions *must* use December's fee schedule. The `bookingDateContext` parameter makes this explicit in the method signature — impossible to forget during implementation.
- **Double-payment downgrade** (✅): Correct safety-first approach. If member M appears in 2 transactions, both become SUGGESTED regardless of individual confidence. The admin sees both side-by-side and can confirm intentional double payments (e.g., quarterly + one-off). No false-negative risk.

### Findings

| # | Severity | Finding | Recommendation |
|---|----------|---------|----------------|
| — | — | No findings. Architecture is clean and complete. | — |

---

## Expert 3: 🛡️ Security & Privacy Expert

**Confidence:** 99%

### Verdict: ✅ APPROVED

### Strengths (carried from v2)
- XXE prevention, filename sanitization, permission model, tenant isolation, IBAN consent gating, rate limiting all remain solid.

### v3 Improvements Assessed
- **Session immutability guard** (✅): Prevents a class of bugs where completed sessions could be accidentally mutated through direct API calls (e.g., replay attacks, browser back-button + resubmit). Good security hardening beyond just GoBD.
- **Duplicate detection** (✅): The 409 response with existing sessionId doesn't leak sensitive data — it only confirms that a filename was used before (the admin already uploaded it, so they know). Safe from an information disclosure perspective.

### Findings

| # | Severity | Finding | Recommendation |
|---|----------|---------|----------------|
| — | — | No findings. Security posture is comprehensive. | — |

---

## Expert 4: 🧪 Testing Expert

**Confidence:** 99%

### Verdict: ✅ APPROVED

### Strengths (carried from v2)
- 70 test cases, traceability matrix, realistic fixtures, edge case coverage all remain excellent.

### v3 Improvements Assessed
- **Double-payment scenario** (✅): This was the most impactful testing gap from v2. The plan now explicitly defines the behavior (downgrade to SUGGESTED), making it directly testable:
  - `testMatchTransactions_sameMemberTwice_bothSuggested()` — clear test name, clear expected behavior.
  - Covers the edge case of quarterly + monthly payments from the same member appearing in one statement.
- **Duplicate import detection** (✅): Adds a testable code path — `checkDuplicateImport()` can be unit-tested with a simple repository mock returning an existing session.
- **Session immutability** (✅): `assertSessionMutable()` is trivially testable: call any mutation on a COMPLETED session, expect `IllegalStateException`.

### Findings

| # | Severity | Finding | Recommendation |
|---|----------|---------|----------------|
| — | — | No findings. All new behaviors are directly testable. | — |

---

## Expert 5: 💼 UX/Product Expert

**Confidence:** 99%

### Verdict: ✅ APPROVED

### Strengths (carried from v2)
- 4-step wizard, color-coded badges, bulk confirm, resume import, searchable combobox, running totals all remain excellent.

### v3 Improvements Assessed
- **Constructive tier messaging** (✅): The specific guidance text ("Exportieren Sie Ihren Kontoauszug stattdessen als CSV — die meisten Banken bieten dies unter 'Umsätze exportieren' an.") is genuinely helpful. It tells the user *exactly what to do* instead of just saying "no". The "Plan vergleichen" link gives a clear path to upgrade. This is textbook progressive disclosure and error prevention.
- **Duplicate import dialog** (✅): Showing "This file was imported X hours ago — continue anyway?" is the correct UX pattern. Power users can override, new users are protected from mistakes. The 409 → confirmation dialog flow is standard and familiar.

### Findings

| # | Severity | Finding | Recommendation |
|---|----------|---------|----------------|
| — | — | No findings. UX is comprehensive and user-friendly. | — |

---

## Expert 6: ⚙️ Integration Expert

**Confidence:** 99%

### Verdict: ✅ APPROVED

### Strengths (carried from v2)
- FinanceService integration, NotificationDispatchService, AuditService, RetentionService, ConsentService, TierLimitService all remain clean.

### v3 Improvements Assessed
- **Fee schedule validity date** (✅): This is the most important integration fix. Without it, a January import of December bank data would match against *January's* fee schedule — potentially a different amount if fees changed at year-start. The `bookingDateContext` parameter ensures correct temporal context. This integrates with the existing `MemberFeeAssignment.validFrom`/`validTo` date range pattern.
- **Session immutability** (✅): Correctly prevents the scenario where a completed session could be re-opened via API. The guard integrates cleanly with all 5 mutation endpoints (confirm, skip, assign, expense, bulk-confirm) without changing their public signatures.
- **Duplicate detection repository method** (✅): `findByClubIdAndFilenameAndCreatedAtAfter()` is a standard Spring Data derived query — no custom SQL needed. Clean integration with existing repository patterns.

### Findings

| # | Severity | Finding | Recommendation |
|---|----------|---------|----------------|
| — | — | No findings. All integrations are clean. | — |

---

## Consolidated Panel Verdict

### Score Breakdown

| Expert | Confidence | Verdict | Blockers | Advisories | Info |
|--------|-----------|---------|----------|-----------|------|
| 🏛️ Domain | 99% | ✅ APPROVED | 0 | 0 | 0 |
| 🔧 Architecture | 99% | ✅ APPROVED | 0 | 0 | 0 |
| 🛡️ Security | 99% | ✅ APPROVED | 0 | 0 | 0 |
| 🧪 Testing | 99% | ✅ APPROVED | 0 | 0 | 0 |
| 💼 UX/Product | 99% | ✅ APPROVED | 0 | 0 | 0 |
| ⚙️ Integration | 99% | ✅ APPROVED | 0 | 0 | 0 |
| **Panel Average** | **99%** | **✅ APPROVED** | **0** | **0** | **0** |

### Summary

**0 blockers** — no changes required before implementation.

**0 advisories** — all prior advisory items (v1→v2) remain resolved.

**0 info items** — all actionable info items from v2 have been incorporated. The 5 excluded items were correctly identified as either already-correct, out-of-scope, or not applicable.

### Comparison: v1 → v2 → v3

| Metric | v1 | v2 | v3 | Delta v2→v3 |
|--------|----|----|----| -------|
| Panel Confidence | 96% | 98% | 99% | +1% |
| Blockers | 0 | 0 | 0 | — |
| Advisories | 7 | 0 | 0 | — |
| Info items | 14 | 12 | 0 | -12 ✅ |
| GoBD compliance | Implicit | Implicit | Explicit guard | ↑ |
| Duplicate prevention | None | None | 24h detection | ↑ |
| Double-payment safety | None | None | Explicit downgrade | ↑ |
| Fee temporal correctness | Assumed current | Assumed current | Explicit bookingDate | ↑ |
| Parser robustness | Standard MT940 | Standard MT940 | Proprietary header tolerant | ↑ |
| Tier UX | Block message | Block message | Constructive guidance | ↑ |

### Final Recommendation

**✅ APPROVED — Ready for implementation. Maximum achievable confidence reached.**

Plan v3 resolves all remaining info items from the v2 review by incorporating 7 concrete improvements: MT940 century boundary constant, proprietary header tolerance, duplicate import detection with 409 Conflict flow, double-payment downgrade logic, constructive tier restriction messaging, fee schedule temporal correctness via `bookingDateContext`, and explicit GoBD session immutability guard. The 5 excluded items were correctly triaged as out-of-scope or already-correct.

This plan is now at the theoretical confidence ceiling for a pre-implementation review — further improvement would require actual code execution and testing, which is the next phase.

**Panel confidence: 99%** — all 6 experts approve unanimously with zero findings of any severity.