Files
grok-botandCommandCodeBot 2bde15c077 docs: update AGENTS.md, CLAUDE.md, gitignore
AGENTS.md: note C++17 modernization complete.
CLAUDE.md: list all test targets.
.gitignore: add .aider* pattern.

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
2026-06-13 08:50:50 +02:00

5.4 KiB
Raw Permalink Blame History

AGENTS.md — Regelwerk (RW)

Verbindliche Verhaltensdefinition für Coding Agents im Regelwerk-Projekt.


Projekt-Kontext

Regelwerk ist ein C++ Expertensystem zur automatisierten Prüfung von kassenärztlichen Abrechnungsdaten (GOÄ/EBM) im deutschen Gesundheitssystem.

  • Autor: Martin Richardt, ms management systems GmbH
  • Zeitraum: 2006–2010
  • Sprache: C++17 (Phasen 0–4 Modernisierung abgeschlossen)
  • Build: CMake + Ninja (ursprünglich Visual Studio 2005 + NMAKE)
  • Datenbank: Oracle/Sybase → DummyDBConnection für Build/Test
  • Namespace: maatini::rw
  • Kritikalität: Medizinische Abrechnungsprüfung – Fehler haben finanzielle/regulatorische Folgen.

Modernisierungsziel: Wartbarkeit und Lesbarkeit erhöhen ohne funktionale Breaking Changes.


Grundlegende Prinzipien

  1. Think Before Coding — Annahmen explizit machen. Bei Unklarheiten sofort nachfragen.
  2. Simplicity First — Einfachste, minimal notwendige Lösung. Kein Over-Engineering.
  3. Surgical Changes — Nur das Nötigste ändern. Existierenden Code-Stil exakt respektieren.
  4. Goal-Driven Execution — Teilziele definieren, Fortschritt messen, Zielerreichung validieren.

Projekt-Regeln

Allgemein

  • Encoding: UTF-8 (keine neuen Dateien in ISO-8859-1)
  • Include-Reihenfolge: 1. Standard (<vector>, <memory>) 2. Boost 3. Projekt ("...")
  • Namespace: Alles in maatini::rw. Kein using namespace in Headern.
  • Thread-Safety: thread_local-Makros nie auf static zurückbauen.
  • DB: Nur DummyDBConnection (src/db/msdb_dummy.cpp). Neue DB-Zugriffe über MSDBConnection-Interface.
  • Keine friend: Zugriff nur über Getter/Setter oder neue öffentliche Methoden.
  • Commits: Ein Commit pro logischer Änderung. Sprache Deutsch oder Englisch, konsistent.

Build & Modernisierung

  • Build nach jeder Änderung: cmake -B build -G Ninja -DBUILD_TESTS=ON && cmake --build build -j$(sysctl -n hw.logicalcpu)
  • Build-Fehler sofort beheben. Nie mit fehlerhaftem Code committen.
  • Modern C++: auto, range-based for, Smart Pointer, RAII, constexpr, std::vector/std::array statt C-Arrays.
  • Header: Bestehende #ifndef-Guards behalten. Neue Header: #pragma once.
  • Keine neuen externen Abhängigkeiten ohne Rücksprache.

Kontext-Schutz

  • NIEMALS lesen: src/aktsource/gen_ops*.cpp (auto-generiert, je ~200K Zeilen).
  • NIEMALS lesen: src/aktsource/go*.cpp, src/aktsource/rw*.cpp (generierte Katalogdaten, ~100 MB insgesamt).
  • Bei Katalog-Fragen die entsprechenden .hpp-Header nutzen.

Prioritäten

  1. Korrektheit & Stabilität — Build muss grün sein, keine Breaking Changes.
  2. Minimalismus — Nur das Nötigste ändern.
  3. Modern C++ — Wo es den Code klarer und sicherer macht.
  4. Transparenz — Jede Änderung begründen und dokumentieren.

GitNexus — Code Intelligence

This project is indexed by GitNexus as regelwerk (18085 symbols, 41447 relationships, 300 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.

If any GitNexus tool warns the index is stale, run npx gitnexus analyze in terminal first.

Always Do

  • MUST run impact analysis before editing any symbol. Before modifying a function, class, or method, run gitnexus_impact({target: "symbolName", direction: "upstream"}) and report the blast radius (direct callers, affected processes, risk level) to the user.
  • MUST run gitnexus_detect_changes() before committing to verify your changes only affect expected symbols and execution flows.
  • MUST warn the user if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
  • When exploring unfamiliar code, use gitnexus_query({query: "concept"}) to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
  • When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use gitnexus_context({name: "symbolName"}).

Never Do

  • NEVER edit a function, class, or method without first running gitnexus_impact on it.
  • NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
  • NEVER rename symbols with find-and-replace — use gitnexus_rename which understands the call graph.
  • NEVER commit changes without running gitnexus_detect_changes() to check affected scope.

Resources

Resource Use for
gitnexus://repo/regelwerk/context Codebase overview, check index freshness
gitnexus://repo/regelwerk/clusters All functional areas
gitnexus://repo/regelwerk/processes All execution flows
gitnexus://repo/regelwerk/process/{name} Step-by-step execution trace

CLI

Task Read this skill file
Understand architecture / "How does X work?" .claude/skills/gitnexus/gitnexus-exploring/SKILL.md
Blast radius / "What breaks if I change X?" .claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md
Trace bugs / "Why is X failing?" .claude/skills/gitnexus/gitnexus-debugging/SKILL.md
Rename / extract / split / refactor .claude/skills/gitnexus/gitnexus-refactoring/SKILL.md
Tools, resources, schema reference .claude/skills/gitnexus/gitnexus-guide/SKILL.md
Index, status, clean, wiki CLI commands .claude/skills/gitnexus/gitnexus-cli/SKILL.md