drift-analyzer 2.1.2__tar.gz → 2.2.0__tar.gz

drift_analyzer-2.2.0/.github/AGENTS.md

@@ -0,0 +1,81 @@
+---
+description: Agents, Skills und Evaluation-Prompts im Drift-Workspace
+---
+
+# Drift Agents & Prompts
+
+## Release Agent
+
+**Quick Release** — Nach Code-Änderungen an `src/drift/` den vollständigen Release-Workflow ausführen.
+
+### Verwendung
+
+Im Chat erwähnen: „Release version", „Create release", „Publish to PyPI".
+
+Der Agent: Validiert → Version berechnet → CHANGELOG + pyproject.toml → Commit + Tag → Push → PyPI.
+
+> **Hinweis:** Releases werden automatisch via python-semantic-release in CI verwaltet.  
+> Lokaler Fallback nur bei CI-Ausfall: `python scripts/release_automation.py --full-release`
+
+### Wann verwenden
+
+- Nach `feat:`, `fix:` oder `BREAKING:`-Commits auf `src/drift/`
+- Wenn Tests bestehen und Code committed ist
+- Nicht bei unfertiger Arbeit oder fehlschlagenden Tests
+
+---
+
+## Evaluation-Prompts
+
+Prompts unter `.github/prompts/` evaluieren die Drift-CLI aus verschiedenen Perspektiven.
+Navigations-Guide: `.github/prompts/README.md`
+
+| Prompt | Zweck | Empfohlene Reihenfolge |
+|--------|-------|------------------------|
+| `drift-onboarding` | First-Use-Erfahrung (Zero-Knowledge) | 1 |
+| `drift-agent-workflow-test` | Vollständiger CLI-Pfadtest | 2 |
+| `drift-signal-quality` | Signal-Precision/Recall messen | 3 |
+| `drift-ci-gate` | CI-Integration validieren | 4 |
+| `drift-ai-integration` | LLM-Context-Qualität bewerten | 5 |
+| `drift-agent-ux` | Agent-UX-Audit (Auffindbarkeit, Latenz, Fehler) | 6 |
+| `PR-Orchestrator` | PR-Bewertung aus Agent-Perspektive | nach Bedarf |
+| `release` | Release-Workflow validieren | nach Bedarf |
+
+### Shared Components
+
+| Datei | Zweck |
+|-------|-------|
+| `_partials/bewertungs-taxonomie.md` | Einheitliche Bewertungs-Labels |
+| `_partials/konventionen.md` | Gemeinsame Konventionen (Policy Gate, Pfade, Sandbox) |
+| `_partials/issue-filing.md` | Issue-Filing-Template (interne Prompts) |
+| `_partials/issue-filing-external.md` | Issue-Filing-Template (Field-Tests, Cross-Repo) |
+
+---
+
+## Field-Test-Prompts (externe Repos)
+
+Prompts unter `.github/prompts/field-tests/` testen drift in **beliebigen Repositories**.
+Issues gehen an `mick-gsk/drift`. Details: `.github/prompts/field-tests/README.md`
+
+| Prompt | Zweck | Empfohlene Reihenfolge |
+|--------|-------|------------------------|
+| `drift-field-test` | Smoke-Test: Funktioniert drift? | 1 |
+| `drift-finding-audit` | Tiefenprüfung: Findings korrekt? | 2 |
+| `drift-context-eval` | Kontext-Qualität für AI-Workflows | 3 |
+
+---
+
+## Skills
+
+- **`drift-release`** — Vollständiger Release-Workflow
+- **`drift-pr-review`** — PR-Review gemäß Drift Policy
+- **`drift-security-triage`** — Security-Report-Triage
+
+---
+
+## Dokumentation
+
+- **Release Skill:** `.github/skills/drift-release/SKILL.md`
+- **Release Instructions:** `.github/instructions/drift-release-automation.instructions.md`
+- **Policy:** `.github/instructions/drift-policy.instructions.md`
+- **Push Gates:** `.github/instructions/drift-push-gates.instructions.md`

{drift_analyzer-2.1.2 → drift_analyzer-2.2.0}/.github/DISCUSSION_TEMPLATE/ideas.yml

@@ -5,7 +5,7 @@ body:
     attributes:
       value: |
         Share an idea or brainstorm about drift's future direction.
-        For concrete feature requests, please use the [issue template](https://github.com/sauremilk/drift/issues/new/choose) instead.
+        For concrete feature requests, please use the [issue template](https://github.com/mick-gsk/drift/issues/new/choose) instead.
 
   - type: textarea
     id: idea

{drift_analyzer-2.1.2 → drift_analyzer-2.2.0}/.github/DISCUSSION_TEMPLATE/questions.yml

@@ -6,7 +6,7 @@ body:
       value: |
         **Before posting**, please check:
         - [Documentation](https://sauremilk.github.io/drift/)
-        - [Existing discussions](https://github.com/sauremilk/drift/discussions)
+        - [Existing discussions](https://github.com/mick-gsk/drift/discussions)
 
   - type: textarea
     id: question

{drift_analyzer-2.1.2 → drift_analyzer-2.2.0}/.github/ISSUE_TEMPLATE/config.yml

@@ -1,17 +1,17 @@
 blank_issues_enabled: false
 contact_links:
   - name: Community studies — participate in drift research
-    url: https://github.com/sauremilk/drift/blob/main/CONTRIBUTING.md#participate-in-community-studies
+    url: https://github.com/mick-gsk/drift/blob/main/CONTRIBUTING.md#participate-in-community-studies
     about: Help validate drift's signals by running analyses, rating findings, or benchmarking repos.
   - name: Support and channel guide
-    url: https://github.com/sauremilk/drift/blob/main/SUPPORT.md
+    url: https://github.com/mick-gsk/drift/blob/main/SUPPORT.md
     about: Use SUPPORT.md to pick the right channel for questions, bugs, ideas, and security.
   - name: Questions and usage help
-    url: https://github.com/sauremilk/drift/discussions
+    url: https://github.com/mick-gsk/drift/discussions
     about: Please ask and answer general questions in Discussions.
   - name: Documentation
     url: https://sauremilk.github.io/drift/
     about: Check the docs site for setup, configuration, and examples.
   - name: Security report
-    url: https://github.com/sauremilk/drift/security/policy
+    url: https://github.com/mick-gsk/drift/security/policy
     about: Please report security vulnerabilities via the Security Policy page.

drift_analyzer-2.2.0/.github/prompts/PR-Orchestrator.prompt.md

@@ -0,0 +1,200 @@
+---
+name: "PR Orchestrator"
+description: "Bewertet Pull Requests risikobasiert und liefert eine klare Maintainer-Entscheidung (APPROVE/COMMENT/REQUEST_CHANGES/WAIT/MERGE) mit konkreten Next Actions."
+---
+
+# PR Orchestrator
+
+Du bist mein PR-Merge-Orchestrator für mein GitHub-Repository.
+
+> **Pflicht:** Vor Ausführung dieses Prompts das Drift Policy Gate durchlaufen
+> (siehe `.github/prompts/_partials/konventionen.md` und `.github/instructions/drift-policy.instructions.md`).
+
+## Relevante Referenzen
+
+- **Skill:** `.github/skills/drift-pr-review/SKILL.md` (systematische PR-Review-Checklist)
+- **Instruction:** `.github/instructions/drift-policy.instructions.md`
+- **Bewertungssystem:** `.github/prompts/_partials/bewertungs-taxonomie.md`
+- **Issue-Filing:** `.github/prompts/_partials/issue-filing.md`
+
+## Kontext
+
+- Ich bin Solo-Developer.
+- Ich bevorzuge pragmatische, schnelle Entscheidungen statt bürokratischer Review-Prozesse.
+- Externe Contributions sollen sauber geprüft werden, aber mit möglichst wenig Overhead.
+- Ziel ist: Risiko minimieren, Contribution-Wahrscheinlichkeit erhöhen, Main-Branch stabil halten.
+- Standard: keine unnötigen Diskussionen, keine generischen Floskeln, keine Halluzinationen.
+- Wenn Informationen fehlen, markiere Annahmen explizit.
+- Antworte auf Deutsch.
+- Schreibe präzise, technisch, strukturiert und entscheidungsorientiert.
+
+## Arbeitsmodus
+
+- Trenne strikt zwischen beobachtetem Diff, belastbarer Schlussfolgerung und offener Annahme.
+- Vergleiche mögliche Interpretationen, bevor du einen PR als riskant oder sicher einordnest.
+- Verdichte große Diffs in entscheidungsrelevante Kernaussagen statt sie breit nachzuerzählen.
+- Benenne immer die kleinste zusätzliche Evidenz, die eine unsichere Entscheidung absichern würde.
+- Wenn mehrere Review-Pfade möglich sind, priorisiere den mit dem höchsten Risikonutzen zuerst.
+
+## Primäre Ziele
+
+1. Verstehen, was der PR fachlich und technisch ändert.
+2. Risiko, Scope und Merge-Reife bewerten.
+3. Test- und Validierungsbedarf bestimmen.
+4. Konkretes Review-Feedback formulieren.
+5. Am Ende genau eine Empfehlung geben: APPROVE / COMMENT / REQUEST_CHANGES / WAIT / MERGE
+
+## Arbeitsprinzipien
+
+- Draft-PRs sind standardmäßig nicht merge-bereit.
+- Kleine, testgedeckte, klar begrenzte Änderungen bevorzugen.
+- Business-Logik, Architektur, API-Verhalten und Regressionen höher gewichten als Stilfragen.
+- Stil-/Nitpick-Themen nur nennen, wenn sie wirklich relevant sind.
+- Niemals Code als korrekt annehmen, nur weil Tests existieren.
+- Niemals Fehler behaupten, wenn du dafür keinen klaren Beleg hast.
+- Wenn ein PR aus einem Fork kommt, prüfe besonders: Vertrauensniveau, Scope-Begrenzung, unerwartete Dateien, versteckte Seiteneffekte, Testabdeckung.
+- Wenn Maintainer-Aktionen nötig sind, benenne sie explizit.
+
+## Bewertungs-Labels
+
+Verwende für Risikodimensionen die Labels aus `.github/prompts/_partials/bewertungs-taxonomie.md`:
+
+| Level | Bedeutung |
+|-------|-----------|
+| `low` | Minimaler Einfluss, kein zusätzlicher Review nötig |
+| `medium` | Spürbarer Einfluss, gezielte Prüfung empfohlen |
+| `high` | Erheblicher Einfluss, Validierung vor Merge Pflicht |
+| `critical` | Blocker — Merge nicht möglich ohne Korrektur |
+
+## Arbeitsablauf
+
+### PHASE 1 — Intake
+
+Erfasse:
+- PR-Nummer, Titel, Autor
+- Draft oder Ready
+- Base-Branch, Head-Branch/Fork
+- Kurzbeschreibung des Ziels
+- Betroffene Dateien
+- Größe und Art der Änderung: docs / tests / bugfix / refactor / feature / infra
+
+### PHASE 2 — Change-Verständnis
+
+Lies Diff und PR-Beschreibung und beantworte:
+- Welches Problem wird gelöst?
+- Was ändert sich im Laufzeitverhalten?
+- Was ändert sich nur an Tests oder Doku?
+- Welche impliziten Annahmen stecken in der Änderung?
+- Ist die Änderung eng geschnitten oder vermischt sie mehrere Themen?
+
+### PHASE 3 — Risikobewertung
+
+Bewerte in diesen Dimensionen:
+
+| Dimension | Beschreibung |
+|-----------|--------------|
+| Korrektheit | Ist die Logik richtig? |
+| Regression | Kann existierendes Verhalten brechen? |
+| Architektur | Passt die Änderung zur bestehenden Struktur? |
+| Sicherheit/Supply-Chain | Gibt es externe Dependencies, unsichere Inputs, oder verdächtige Patterns? |
+| Wartbarkeit | Erhöht die Änderung technische Schulden? |
+| Contributor | Vertrauen, Scope-Begrenzung, unerwartete Dateien |
+
+Ordne je Dimension ein: `low` / `medium` / `high` / `critical`.
+Nenne zu jeder Einstufung genau den Auslöser.
+
+**Risiko-Aggregation:** Das Gesamturteil entspricht dem **höchsten Einzelrisiko** (Worst-Case-Prinzip). Bei mehreren `medium`-Werten ohne `high`/`critical` kann das Gesamtrisiko auf `medium` bleiben; bei ≥2 `high`-Werten ist das Gesamtrisiko obligatorisch `critical`.
+
+### PHASE 4 — Validierung
+
+Prüfe:
+- Gibt es bestehende oder neue Tests?
+- Decken die Tests den eigentlichen Verhaltensänderungsraum ab?
+- Fehlen Gegenbeispiele, Randfälle oder Negativtests?
+- Müssen Linting, Typchecks, Unit-Tests oder Integrationstests ausgeführt werden?
+- Reicht die vorhandene Evidenz für Merge-Reife?
+
+Wenn konkrete Testkommandos sinnvoll sind, gib sie als ausführbare Liste aus.
+Wenn keine Ausführung möglich ist, formuliere klar: „empfohlene lokale Validierung".
+
+### PHASE 5 — Review-Entscheidung
+
+Entscheidungsregeln (**in Prioritätsreihenfolge** — erste zutreffende Regel gewinnt):
+
+1. **WAIT** wenn: PR ist Draft ODER zentrale Informationen fehlen ODER CI/Teststatus unbekannt bei nicht-trivialem PR
+2. **REQUEST_CHANGES** wenn: klarer fachlicher Fehler ODER unzureichende Testabdeckung bei relevantem Verhaltensrisiko ODER Scope unsauber/riskant
+3. **COMMENT** wenn: frühe Fragen, kleinere Unsicherheiten oder Verbesserungsvorschläge ohne Blocker
+4. **APPROVE** wenn: PR review-ready, Scope klar, Risiko ≤ medium, Evidenz ausreichend
+5. **MERGE** wenn: review-ready, keine offenen Blocker, Validierung ausreichend, Risiko ≤ low, Maintainer-Sicht konsistent
+
+### PHASE 6 — Ausgabestruktur
+
+Liefere immer in genau diesem Format:
+
+```markdown
+# PR-Entscheidung
+<eine von: APPROVE / COMMENT / REQUEST_CHANGES / WAIT / MERGE>
+
+## Kurzurteil
+2–4 Sätze mit der Kernaussage.
+
+## Einordnung
+- Typ:
+- Scope:
+- Reifegrad:
+- Risiko gesamt:
+- Merge-Bereitschaft:
+
+## Was geändert wird
+- ...
+
+## Risiken
+| Dimension | Level | Begründung |
+|-----------|-------|------------|
+| Korrektheit | ... | ... |
+| Regression | ... | ... |
+| Architektur | ... | ... |
+| Sicherheit | ... | ... |
+| Wartbarkeit | ... | ... |
+| Contributor | ... | ... |
+
+## Validierung
+- Vorhandene Evidenz:
+- Fehlende Evidenz:
+- Empfohlene Checks:
+- Merge ohne weitere Prüfung: ja/nein + Begründung
+
+## Review-Kommentar
+[GitHub-tauglicher Kommentar — respektvoll, knapp, konkret, contributor-freundlich.
+Keine generischen Lobfloskeln. Bei Draft: klar sagen, dass nach Ready-for-Review final entschieden wird.]
+
+## Maintainer-Aktion
+[Genau eine Aktion: „jetzt kommentieren" / „lokal testen" / „auf Ready for review warten" / „approve und mergen" / „changes anfordern"]
+```
+
+## Zusatzregeln
+
+- Wenn ein PR nur Tests ergänzt, prüfe trotzdem, ob die Tests die richtige Semantik absichern.
+- Wenn Codepfade stillschweigend Ausnahmen/Findings unterdrücken, prüfe auf False-Negative-Risiko.
+- Wenn Edge-Case-Handling hinzugefügt wird, verlange Klarheit darüber, warum die Grenze korrekt ist.
+- Wenn README-/ADR-/Dokumentationsregeln abgeschwächt werden, prüfe, ob das Produktziel verwässert wird.
+- Bei kleinen externen PRs: schneller, präziser Kommentar statt überformalisierter Prozess.
+- Wenn die Änderung sinnvoll wirkt, aber der PR noch Draft ist, entscheide WAIT mit kurzem positivem Kommentar.
+
+## GitHub-Issue-Erstellung
+
+Am Ende des Workflows GitHub-Issues erstellen gemäß `.github/prompts/_partials/issue-filing.md`.
+
+**Prompt-Kürzel für Titel:** `pr-review`
+
+### Issues erstellen für
+
+- Echte Produktfehler oder riskante Architekturprobleme, die über den konkreten PR hinausgehen
+- Wiederkehrende Test-, CI-, Dokumentations- oder Release-Lücken
+- Maintainer- oder Contributor-UX-Probleme, die in zukünftigen PRs erneut auftreten werden
+
+### Keine Issues erstellen für
+
+- Reine Einzelfall-Hinweise, die vollständig im PR-Kommentar gelöst sind
+- Lokale Umgebungsprobleme ohne Repo-Bezug
+- Duplikate bereits existierender Issues

drift_analyzer-2.2.0/.github/prompts/README.md

@@ -0,0 +1,82 @@
+# Drift Prompt-Bibliothek
+
+> Übersicht aller Evaluierungs- und Workflow-Prompts im Drift-Workspace.
+
+## Schnellübersicht
+
+| Prompt | Zweck | Relevanter Skill | Relevante Instruction | Wann verwenden |
+|--------|-------|-------------------|----------------------|----------------|
+| [drift-agent-ux](drift-agent-ux.prompt.md) | Agent-UX-Audit: Entscheidungsketten, Dead Ends, Recovery-Pfade | — | `drift-policy` | Agent-Nutzbarkeit der CLI bewerten |
+| [drift-agent-workflow-test](drift-agent-workflow-test.prompt.md) | Vollständiger CLI-Coverage-Test über alle Kommandos | — | `drift-policy` | Komplette CLI-Oberfläche testen |
+| [drift-ai-integration](drift-ai-integration.prompt.md) | LLM-Kontext-Qualität: Export-Formate, MCP, Token-Effizienz | — | `drift-policy` | AI-Integrations-Tauglichkeit prüfen |
+| [drift-ci-gate](drift-ci-gate.prompt.md) | CI-Sicherheit: Exit-Codes, Idempotenz, Maschinen-Formate | — | `drift-policy`, `drift-push-gates` | CI-Pipeline-Tauglichkeit validieren |
+| [drift-onboarding](drift-onboarding.prompt.md) | Erstnutzer-Friktionstest: Init, Config, Time-to-Value | — | `drift-policy` | Onboarding-Qualität für neue User bewerten |
+| [drift-signal-quality](drift-signal-quality.prompt.md) | Signalkorrektheit: TP/FP/FN, Precision/Recall, Oracle-Abgleich | — | `drift-policy` | Signalqualität und -vertrauen messen |
+| [PR-Orchestrator](PR-Orchestrator.prompt.md) | Risikobasierte PR-Review-Entscheidung (APPROVE/MERGE/WAIT/...) | `drift-pr-review` | `drift-policy` | Pull Requests bewerten und entscheiden |
+| [release](release.prompt.md) | Release-Workflow: Version, Changelog, Tag, Publish | `drift-release` | `drift-release-automation`, `drift-release-mandatory` | Nach Code-Änderungen releasen |
+
+## Empfohlene Reihenfolge für vollständige Produkt-Evaluation
+
+Für eine umfassende Drift-Bewertung diese Prompts in dieser Reihenfolge ausführen:
+
+1. **drift-onboarding** — Ersteinrichtung und Time-to-Value
+2. **drift-agent-workflow-test** — Vollständige CLI-Abdeckung in realistischen Workflows
+3. **drift-signal-quality** — Signalkorrektheit und -vertrauen messen
+4. **drift-ci-gate** — CI-Pipeline-Sicherheit und -Stabilität
+5. **drift-ai-integration** — LLM-Kontext-Qualität und MCP-Tauglichkeit
+6. **drift-agent-ux** — Autonomes Agent-UX-Audit (baut auf Ergebnissen der vorherigen auf)
+
+## Tägliche Workflows
+
+| Situation | Prompt |
+|-----------|--------|
+| PR bewerten und Merge-Entscheidung treffen | **PR-Orchestrator** |
+| Neue Version veröffentlichen | **release** |
+
+## Field-Test-Prompts (externe Repos)
+
+Prompts unter `field-tests/` testen drift in **beliebigen Repositories** — nicht nur im Drift-Repo.
+Details: [field-tests/README.md](field-tests/README.md)
+
+| Prompt | Zweck | Voraussetzung |
+|--------|-------|---------------|
+| [drift-field-test](field-tests/drift-field-test.prompt.md) | Smoke-Test: Funktioniert drift in diesem Repo? | Keine |
+| [drift-finding-audit](field-tests/drift-finding-audit.prompt.md) | Tiefenprüfung: Findings korrekt? TP/FP/FN | field-test = `pass` |
+| [drift-context-eval](field-tests/drift-context-eval.prompt.md) | Kontext-Qualität: Exports nützlich für AI? | field-test = `pass` |
+
+**Issues gehen an `mick-gsk/drift`**, nicht ans analysierte Ziel-Repo.
+
+## Shared Components
+
+Alle Prompts nutzen gemeinsame Referenz-Dateien unter `_partials/`:
+
+| Datei | Inhalt |
+|-------|--------|
+| [`_partials/bewertungs-taxonomie.md`](_partials/bewertungs-taxonomie.md) | Einheitliches Bewertungssystem (Labels, Scores, Klassifikationen) |
+| [`_partials/konventionen.md`](_partials/konventionen.md) | Policy-Gate-Pflicht, Datumsformat, Artefakt-Pfade, Sandbox-Erstellung |
+| [`_partials/issue-filing.md`](_partials/issue-filing.md) | Issue-Template für interne Prompts |
+| [`_partials/issue-filing-external.md`](_partials/issue-filing-external.md) | Issue-Template für Field-Test-Prompts (Cross-Repo) |
+
+## Beziehung zum Instructions/Skills-Ökosystem
+
+```
+.github/copilot-instructions.md          ← Master-Arbeitsvertrag für alle Agenten
+  ├── .github/instructions/
+  │   ├── drift-policy.instructions.md    ← Policy-Gate, Qualitätsanforderungen, Prioritäten
+  │   ├── drift-push-gates.instructions.md ← Pre-Push-Validierung (8 Gates)
+  │   ├── drift-release-automation.instructions.md ← PSR-Workflow (DE)
+  │   └── drift-release-mandatory.instructions.md  ← PSR-Pflicht (EN)
+  ├── .github/skills/
+  │   ├── drift-pr-review/SKILL.md        ← PR-Review-Checklist → verwendet von PR-Orchestrator
+  │   ├── drift-release/SKILL.md          ← Release-Workflow → verwendet von release.prompt.md
+  │   └── drift-security-triage/SKILL.md  ← Security-Triage (kein Prompt)
+  └── .github/prompts/                    ← Diese Prompt-Bibliothek
+```
+
+## Konventionen
+
+- **Sprache**: Alle Prompts sind auf Deutsch
+- **Bewertungssystem**: Einheitlich gemäß `_partials/bewertungs-taxonomie.md`
+- **Issue-Erstellung**: Einheitlich gemäß `_partials/issue-filing.md`
+- **Modellbezug**: Prompts sind modellunabhängig (keine spezifische Modellversion)
+- **Artefakte**: Unter `work_artifacts/<prompt-kürzel>_<YYYY-MM-DD>/`

drift_analyzer-2.2.0/.github/prompts/_partials/bewertungs-taxonomie.md

@@ -0,0 +1,73 @@
+# Bewertungs-Taxonomie (Shared Reference)
+
+> **Single Source of Truth** — Alle Prompts in `.github/prompts/` verwenden ausschließlich diese Labels.
+> Wenn ein Prompt abweichende Labels nutzt, ist diese Datei maßgeblich.
+
+## Ergebnis-Bewertung (pro Schritt / pro Kommando)
+
+| Label | Bedeutung |
+|-------|-----------|
+| `pass` | Nächster Schritt ist klar, Evidenz reicht aus, Agent kann sicher fortfahren |
+| `review` | Teilweise nützlich, aber fehlende Daten, Priorisierung oder Entscheidungsgrundlage — Agent braucht zusätzliche Prüfung |
+| `fail` | Irreführend, blockiert oder lenkt den Agent in eine falsche Richtung |
+
+## Abdeckungs-Status (pro Kommando / Testfall)
+
+| Label | Bedeutung |
+|-------|-----------|
+| `tested` | Vollständig ausgeführt und bewertet |
+| `skipped` | Begründet übersprungen (Grund dokumentiert) |
+| `blocked` | Ausführung nicht möglich (Ursache dokumentiert) |
+
+## Risiko-Level (pro Dimension / pro Finding)
+
+| Label | Bedeutung |
+|-------|-----------|
+| `low` | Kein oder minimaler Einfluss auf Entscheidungssicherheit |
+| `medium` | Spürbarer Einfluss, aber kein Workflow-Blocker |
+| `high` | Erheblicher Einfluss auf Entscheidungssicherheit oder Agent-Workflow |
+| `critical` | Blockiert den Workflow oder erzeugt falsche Entscheidungen |
+
+## Signal-Vertrauensstufe (pro Signal)
+
+| Label | Bedeutung |
+|-------|-----------|
+| `trusted` | Precision ≥ 70%, Actionability ≥ 3, Agent kann blindlings handeln |
+| `needs_review` | Precision 50–70% oder Actionability < 3, Maintainer-Prüfung nötig |
+| `unsafe` | Precision < 50%, Signal erzeugt mehr Fehlentscheidungen als korrekte |
+
+## Actionability-Score (1–4, pro Signal)
+
+| Score | Bedeutung | Akzeptabel? |
+|-------|-----------|-------------|
+| `1 automated` | Fix ist mechanisch ableitbar, Agent kann direkt handeln | ✅ Ja |
+| `2 guided` | Agent kann handeln, braucht aber expliciten Fix-Plan | ✅ Ja |
+| `3 human-review` | Signal plausibel, aber Fix-Entscheidung braucht Maintainer | ⚠️ Bedingt |
+| `4 blocked` | Keine sichere nächste Aktion möglich | ❌ Nein |
+
+Schwelle für Produktionseinsatz: **Score ≤ 2** = Agent-tauglich, **Score 3** = nur mit Maintainer-Freigabe.
+
+## Discoverability-Scale (für Recovery-Pfade)
+
+| Label | Bedeutung | Agent-tauglich? |
+|-------|-----------|-----------------|
+| `explicit` | Tool benennt direkt die Recovery-Aktion | ✅ Ja |
+| `hinted` | Genug Hinweise, um Recovery sicher abzuleiten | ✅ Ja |
+| `pattern-match` | Nur erfahrene User finden den Pfad | ❌ Nein |
+| `dark` | Kein Hinweis; nur Trial-and-Error | ❌ Nein |
+
+## Idempotenz-Klassifikation (für CI-Stabilität)
+
+| Label | Bedeutung | CI-tauglich? |
+|-------|-----------|-------------|
+| `stable` | Keine Differenz außer Timestamps/Run-IDs | ✅ Ja |
+| `ordering-unstable` | Gleiche Findings, aber instabile Reihenfolge | ⚠️ Bedingt |
+| `content-unstable` | Unterschiedliche Findings ohne Codeänderung — Product-Bug | ❌ Nein |
+
+## Cross-Validation-Klassifikation (scan vs. analyze Konsistenz)
+
+| Label | Bedeutung |
+|-------|-----------|
+| `metadata-only` | Nur kosmetisch, kein Entscheidungsimpact |
+| `priority-shift` | Severity/Ranking unterscheiden sich, kann Agent fehlleiten |
+| `contradiction` | Inhaltlich gegensätzliche Aussage — als `unsafe` bewerten |

drift_analyzer-2.2.0/.github/prompts/_partials/issue-filing-external.md

@@ -0,0 +1,121 @@
+# Issue-Filing-Template für External Field-Tests
+
+> **Für Prompts unter `.github/prompts/field-tests/`** — Issues aus externen Repo-Tests.
+> Basis-Regeln aus `_partials/issue-filing.md` gelten zusätzlich (Deduplizierung, Ein-Issue-pro-Problem, Evidenz-Pflicht).
+>
+> **Sprache: Issues werden IMMER auf Englisch verfasst.**
+> **Ziel-Repo: Issues gehen IMMER an `mick-gsk/drift`** — nicht ans analysierte Ziel-Repo.
+
+## Allgemeine Regeln
+
+1. **Vor Erstellung** prüfen, ob ein passendes Issue auf `mick-gsk/drift` bereits existiert
+2. **Ein Issue pro Problem** — keine Sammel-Issues
+3. **Evidenz-Pflicht** — exaktes Kommando, drift-Version, Ziel-Repo-Infos angeben
+4. **Nur reproduzierbare Defekte** — kein lokales Umgebungsrauschen
+5. **Labels**: `field-test` plus ggf. `agent-ux`, `signal-quality`, `bug`
+6. **Sprache**: Englisch (Titel + Body + Kommentare)
+7. **Scope**: Issues beschreiben Drift-Verhalten, nicht Probleme im Ziel-Repo
+
+## Titel-Format
+
+```
+[field-test:<prompt-prefix>] <concise problem description> (tested on <repo-name>)
+```
+
+Prompt-Kürzel (prefix):
+- `field-test` — aus drift-field-test.prompt.md
+- `finding-audit` — aus drift-finding-audit.prompt.md
+- `context-eval` — aus drift-context-eval.prompt.md
+
+Beispiele:
+- `[field-test:field-test] drift analyze crashes on monorepo with 500+ modules (tested on django/django)`
+- `[field-test:finding-audit] AVS signal fires on framework-idiomatic imports (tested on pallets/flask)`
+- `[field-test:context-eval] export-context raw format missing signal IDs (tested on encode/httpx)`
+
+## Body-Template (English)
+
+```markdown
+## Observed behavior
+
+[What drift produced — include relevant output snippet]
+
+## Expected behavior
+
+[What would have been correct/useful for this repository type]
+
+## Tested repository
+
+- **Repository:** [OWNER/REPO-NAME]
+- **Commit:** [COMMIT-HASH or branch]
+- **Repo type:** [Python / TypeScript / Mixed]
+- **Repo profile:** [Library / Framework / Application / Monorepo]
+- **Git history available:** [Yes (N commits) / No (shallow clone) / Partial]
+- **Repo size:** [approximate file count or LOC]
+
+## Reproduction
+
+- drift version: [VERSION]
+- Command: `drift ...`
+- Config used: [default / custom drift.yaml / drift init --profile ...]
+- Evidence artifact: [PATH in work_artifacts/]
+
+## Impact
+
+- [ ] Workflow blocker (drift cannot analyze this repository)
+- [ ] False positive (drift reports non-existent problem)
+- [ ] False negative (drift misses real architectural issue)
+- [ ] Severity miscalibration (finding real but severity wrong)
+- [ ] Cross-command inconsistency (scan vs. analyze disagree)
+- [ ] Context quality issue (export is noisy, irrelevant, or incomplete)
+- [ ] Repo-type-specific issue (only affects this architecture style)
+
+## Generalizability estimate
+
+[Is this likely specific to this one repo, or would it affect similar repos?
+e.g., "Likely affects all Django projects with apps/ structure"]
+
+## Source
+
+Auto-generated by `.github/prompts/field-tests/<PROMPT-FILE>` on [DATE].
+Tested on [OWNER/REPO-NAME] at commit [SHORT-HASH].
+```
+
+## Erstellungskriterien
+
+### Issues erstellen für
+
+- `fail`-Bewertungen mit reproduzierbarer Evidenz
+- Signale mit `unsafe`-Vertrauensstufe, die nicht repo-spezifisch erklärbar sind
+- False Positives, die auf ein systematisches Pattern hindeuten (nicht nur Einzelfall)
+- Cross-Command-Inkonsistenzen mit Entscheidungsimpact
+- Export-Kontext, der für das getestete Repo irrelevant oder irreführend ist
+
+### Keine Issues erstellen für
+
+- Findings, die korrekt aber unerwünscht sind (das Repo HAT das Problem)
+- Lokale Umgebungsprobleme (falsche Python-Version, fehlende Dependencies)
+- Einzelfälle ohne Generalisierungspotential
+- Subjektive Formatpräferenzen
+- Duplikate bereits existierender Issues auf `mick-gsk/drift`
+
+### Generalisierungs-Heuristik
+
+Vor Issue-Erstellung fragen: *Würde dieses Problem auch in einem anderen Repo desselben Typs auftreten?*
+- **Ja** → Issue erstellen mit Generalizability-Einschätzung
+- **Wahrscheinlich** → Issue erstellen, als `needs_review` kennzeichnen
+- **Nein, repo-spezifisch** → Nur im Report dokumentieren, kein Issue
+
+## Abschlussausgabe
+
+Nach Issue-Erstellung:
+
+```text
+Created issues on mick-gsk/drift:
+- #[NUMBER]: [TITLE] - [URL]
+
+Skipped issues (already exist):
+- [TITLE] -> #[NUMBER]
+
+Documented in report only (repo-specific, no issue):
+- [FINDING DESCRIPTION]
+```