feat: archive zoo_backup for home sync
This commit is contained in:
Patrick Plate
@@ -0,0 +1,241 @@
|
||||
---
|
||||
name: expert-panel-review
|
||||
description: Multi-expert panel review that analyzes a plan or code from 3 specialized perspectives (Domain Expert, Architecture Expert, Risk/Compliance Expert). Produces a synthesized panel verdict with confidence level. Use when reviewing plans, assessments, or code changes that need high-confidence validation — especially for GKV/SV domain changes.
|
||||
---
|
||||
|
||||
# Skill: expert-panel-review
|
||||
|
||||
Multi-expert panel review of plans or code from 3 specialist perspectives simultaneously.
|
||||
|
||||
## Invoked by
|
||||
|
||||
📋✅ Plan Reviewer mode (mandatory before verdict)
|
||||
🔍 Reviewer mode (optional, for complex changes)
|
||||
|
||||
## Required Inputs
|
||||
|
||||
| Input | Source | Example |
|
||||
|-------|--------|---------|
|
||||
| `TICKET_KEY` | Jira issue key | `ESIDEPAISY-13009` |
|
||||
| `MODULE` | PAISY module name | `eau`, `eubp`, `svmeldungen` |
|
||||
| `ARTIFACT_TYPE` | What's being reviewed | `plan`, `code`, `assessment` |
|
||||
| `ARTIFACT_PATH` | Path to the document or diff | `docs/EAU/ESIDEPAISY-13009/ESIDEPAISY-13009-plan.md` |
|
||||
|
||||
## Output
|
||||
|
||||
Markdown section appended to the review document, or standalone file:
|
||||
`docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-panel-review.md`
|
||||
|
||||
## Expert Panel Composition
|
||||
|
||||
### For Plan/Assessment Review
|
||||
|
||||
| # | Expert | Emoji | Lens | Focus Areas |
|
||||
|---|--------|-------|------|-------------|
|
||||
| 1 | Domain Expert | 🏛️ | GKV/SV regulation & business correctness | Are domain assumptions correct? Is the spec interpretation right? Do date boundaries, Kennzeichen values, and Verfahrensmerkmale match the official GKV documentation? |
|
||||
| 2 | Architecture Expert | 🔧 | PAISY patterns & technical design | Is the plan technically sound? Correct patterns used (AbstractMeldung, Datenbaustein, ServiceCenter, EMFactory, JAXB)? Missing components? Correct module boundaries? |
|
||||
| 3 | Risk & Compliance Expert | 🛡️ | Edge cases, backward compatibility, data integrity | What could go wrong? Missing error paths? Backward compatibility issues? Data migration risks? What happens to in-flight transactions? |
|
||||
|
||||
### For Code Review
|
||||
|
||||
| # | Expert | Emoji | Lens | Focus Areas |
|
||||
|---|--------|-------|------|-------------|
|
||||
| 1 | Domain Expert | 🏛️ | Business logic correctness | Does the code implement domain rules correctly? Are Datenbaustein field mappings correct? Do date calculations follow SV rules? |
|
||||
| 2 | Performance & Data Expert | ⚡ | DB queries, batch patterns, memory | N+1 queries? Missing EM flush/clear in loops? Unbounded collections? Correct transaction boundaries? Index usage? |
|
||||
| 3 | Integration Expert | 🔗 | API contracts, backward compat, versioning | Will this break existing callers? Is the JAXB contract preserved? Are Flyway migrations safe for rollback? ServiceCenter protocol correct? |
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Load the artifact
|
||||
|
||||
For plans/assessments:
|
||||
```bash
|
||||
cat docs/<MODULE>/<TICKET_KEY>/<TICKET_KEY>-<ARTIFACT_TYPE>.md
|
||||
```
|
||||
|
||||
For code:
|
||||
```bash
|
||||
cd /Users/pplate/git/paisy-<TICKET_KEY>
|
||||
git diff origin/current --stat
|
||||
git diff origin/current
|
||||
```
|
||||
|
||||
### 2. Load domain context
|
||||
|
||||
Search BigMind and Wiki for domain-specific context:
|
||||
```python
|
||||
memory_search_facts("<MODULE> <domain keywords>")
|
||||
# For GKV topics, also check ADP Docs Wiki
|
||||
set-wiki(uri="mcp://wikis/adpdocs.de.adp.com")
|
||||
search-page(query="<relevant domain topic>")
|
||||
```
|
||||
|
||||
### 3. Run Expert Panel (3 parallel perspectives)
|
||||
|
||||
For each expert, perform a **complete independent review** of the artifact. Each expert MUST:
|
||||
- State their assumptions explicitly
|
||||
- Challenge claims in the document with evidence
|
||||
- Provide a confidence score (0-100%) for their domain
|
||||
- List specific concerns with file/section references
|
||||
- Give a per-expert verdict: ✅ APPROVE / ⚠️ CONCERN / ❌ REJECT
|
||||
|
||||
#### Expert 1: 🏛️ Domain Expert Review
|
||||
|
||||
**System prompt context:**
|
||||
```
|
||||
You are a German social insurance (Sozialversicherung) domain expert specializing in GKV electronic data exchange procedures. You have deep knowledge of:
|
||||
- GKV Datenaustausch specifications (DSRV, ITSG standards)
|
||||
- SV-Meldeverfahren procedures (DEÜV, EEL, EAU, EuBP, DaBPV, DSAK, DSBD, DSVV)
|
||||
- Date boundary rules (Gültigkeitszeiträume, Abrechnungszeiträume)
|
||||
- Kennzeichen values and their semantics
|
||||
- Vorlaufsatz/Nachlaufsatz structure
|
||||
- XML schema versioning (v2025, v2027 namespaces)
|
||||
|
||||
Review this artifact for DOMAIN CORRECTNESS ONLY. Do not review code quality or architecture.
|
||||
Focus: Are the domain assumptions correct? Does this match the official GKV specifications?
|
||||
```
|
||||
|
||||
#### Expert 2: 🔧 Architecture Expert Review (for plans) / ⚡ Performance Expert (for code)
|
||||
|
||||
**For plans — system prompt context:**
|
||||
```
|
||||
You are a senior Java architect specializing in the PAISY monorepo patterns:
|
||||
- AbstractMeldung inheritance hierarchy
|
||||
- Datenbaustein field-based data exchange
|
||||
- ServiceCenter singleton + pgm protocol
|
||||
- EMFactory per-module pattern
|
||||
- JAXB binding with Jakarta namespace
|
||||
- Flyway dual-database migrations (H2 + Oracle)
|
||||
- Spring Shell command dispatch
|
||||
- NATS JetStream message broker integration
|
||||
|
||||
Review this plan for ARCHITECTURAL SOUNDNESS ONLY. Do not review domain correctness.
|
||||
Focus: Are the correct patterns used? Is the component decomposition right? Are there missing pieces?
|
||||
```
|
||||
|
||||
**For code — system prompt context:**
|
||||
```
|
||||
You are a performance and data access expert for Java/JPA applications:
|
||||
- JPA EntityManager lifecycle and persistence context management
|
||||
- Batch processing patterns (flush/clear every N items)
|
||||
- Query optimization (N+1 detection, eager vs lazy loading)
|
||||
- Transaction boundary correctness
|
||||
- Connection pool management
|
||||
- Memory-efficient collection processing
|
||||
- H2 vs Oracle behavioral differences
|
||||
|
||||
Review this code for PERFORMANCE AND DATA INTEGRITY ONLY. Do not review domain correctness.
|
||||
Focus: Will this scale? Are there hidden performance traps? Is data consistency guaranteed?
|
||||
```
|
||||
|
||||
#### Expert 3: 🛡️ Risk Expert Review (for plans) / 🔗 Integration Expert (for code)
|
||||
|
||||
**For plans — system prompt context:**
|
||||
```
|
||||
You are a risk and compliance analyst specializing in payroll system changes:
|
||||
- Backward compatibility requirements (Bestandskunden must not break)
|
||||
- Data migration risks (what happens to existing records?)
|
||||
- In-flight transaction handling during deployments
|
||||
- Wartungswechsel (maintenance version rotation) implications
|
||||
- Rollback scenarios (can this be undone safely?)
|
||||
- Edge cases: empty datasets, date sentinels (00.00.0000, 9999999), null BBNRs
|
||||
- Multi-tenant Oracle implications
|
||||
- Timing risks: what if this runs mid-Abrechnungslauf?
|
||||
|
||||
Review this plan for RISKS AND GAPS ONLY. Do not review architecture or domain.
|
||||
Focus: What could go wrong? What's not addressed? What edge cases are missing?
|
||||
```
|
||||
|
||||
**For code — system prompt context:**
|
||||
```
|
||||
You are an integration and contract expert for the PAISY module ecosystem:
|
||||
- API stability between modules (breaking changes detection)
|
||||
- JAXB XML contract preservation (namespace, element order, required fields)
|
||||
- Flyway migration safety (can it be applied to existing production data?)
|
||||
- ServiceCenter protocol compatibility (F; response handling)
|
||||
- Backward compatibility with existing callers
|
||||
- Dual-database correctness (H2 behavior vs Oracle behavior)
|
||||
- Version-aware code paths (V2/V3 coexistence)
|
||||
|
||||
Review this code for INTEGRATION SAFETY ONLY. Do not review performance or domain.
|
||||
Focus: Will this break anything that already works? Are contracts preserved?
|
||||
```
|
||||
|
||||
### 4. Synthesize Panel Verdict
|
||||
|
||||
After all 3 experts complete their reviews, synthesize:
|
||||
|
||||
```markdown
|
||||
## 👥 Expert Panel Verdict
|
||||
|
||||
### Panel Composition
|
||||
| Expert | Verdict | Confidence | Key Concern |
|
||||
|--------|---------|-----------|-------------|
|
||||
| 🏛️ Domain Expert | ✅/⚠️/❌ | <N>% | <one-line summary> |
|
||||
| 🔧/⚡ Architecture/Performance Expert | ✅/⚠️/❌ | <N>% | <one-line summary> |
|
||||
| 🛡️/🔗 Risk/Integration Expert | ✅/⚠️/❌ | <N>% | <one-line summary> |
|
||||
|
||||
### Consensus
|
||||
**Overall Panel Verdict:** ✅ UNANIMOUS APPROVE / ⚠️ CONDITIONAL APPROVE / ❌ REVISE REQUIRED
|
||||
|
||||
**Confidence Level:** <average of 3 experts>%
|
||||
|
||||
### Dissenting Opinions
|
||||
<If any expert disagrees with the others, document the disagreement explicitly>
|
||||
|
||||
### Consolidated Findings
|
||||
|
||||
#### Must Address (blocking)
|
||||
1. [Expert emoji] <finding> — <rationale>
|
||||
|
||||
#### Should Address (non-blocking)
|
||||
1. [Expert emoji] <finding> — <suggestion>
|
||||
|
||||
#### Noted (informational)
|
||||
1. [Expert emoji] <observation>
|
||||
```
|
||||
|
||||
### 5. Apply Panel Rules
|
||||
|
||||
| Scenario | Action |
|
||||
|----------|--------|
|
||||
| All 3 experts ✅ APPROVE | → Panel APPROVE, proceed to final verdict |
|
||||
| 2 experts ✅, 1 expert ⚠️ CONCERN | → Panel CONDITIONAL APPROVE, document concern |
|
||||
| Any expert ❌ REJECT | → Panel REVISE REQUIRED, must address before approval |
|
||||
| 2+ experts ⚠️ CONCERN | → Panel REVISE REQUIRED, cumulative risk too high |
|
||||
| Average confidence < 70% | → Flag for human review regardless of verdicts |
|
||||
|
||||
### 6. Store findings
|
||||
|
||||
```python
|
||||
memory_store_fact(
|
||||
category="codebase",
|
||||
fact=f"{TICKET_KEY}: Expert panel review — {verdict}. Domain: {d_verdict} ({d_conf}%), Arch: {a_verdict} ({a_conf}%), Risk: {r_verdict} ({r_conf}%)"
|
||||
)
|
||||
```
|
||||
|
||||
## Expected Output
|
||||
|
||||
- 3 independent expert reviews with specific findings
|
||||
- Synthesized panel verdict with confidence levels
|
||||
- Clear blocking/non-blocking categorization
|
||||
- Dissenting opinions explicitly documented (not suppressed)
|
||||
|
||||
## Error Handling
|
||||
|
||||
| Error | Resolution |
|
||||
|-------|------------|
|
||||
| No domain context found | Fetch from ADP Docs Wiki before domain expert runs |
|
||||
| Expert contradicts another | Document as dissenting opinion — don't average away disagreement |
|
||||
| Low confidence from an expert | Flag for human review — don't proceed with uncertain approval |
|
||||
| Plan too vague for experts | REVISE — experts need concrete details to review |
|
||||
|
||||
## Key Principle
|
||||
|
||||
**Never suppress dissent.** If the Risk Expert sees a problem that Architecture Expert dismisses, BOTH perspectives are documented. Patrick makes the final call on risk acceptance. The panel provides information, not consensus-for-consensus-sake.
|
||||
|
||||
## Language
|
||||
|
||||
- Expert reviews: **German** (PAISY domain convention)
|
||||
- Technical terms (class names, patterns): English as-is
|
||||
- Panel synthesis: German
|
||||
Reference in New Issue
Block a user