# Was NXM-Module sind

> Ein NXM-Modul ist ein Fachmodul, das Sie als eine Paketdatei in einen Mandanten installieren, mit eigenen Datensätzen, Listen, Seiten, Rollen, Aktionen und Werkzeugen für den KI-Assistenten. Diese Seite erklärt, woraus ein Modul besteht, wie es sich von eingebauten Modulen und Apps unterscheidet und wie aus einem Paket ein laufendes Modul wird.

Nehmen wir eine Anwaltskanzlei, die ihre Akten in nexxus führen will: Akten mit Nummer, Mandantin und Gegner, die Dokumente jeder Akte, Schreiben, die auf die Freigabe einer Anwältin warten, und Gerichtsfristen, die niemand versäumen darf. Nichts davon ist in nexxus eingebaut. Eine Entwicklerin beschreibt diese Fachobjekte, ihre Oberflächen und ihre Regeln in einem Paket. Ein Administrator lädt das Paket hoch, liest, was es mitbringt und worauf es zugreifen will, stimmt zu und installiert es. Ab diesem Moment finden die Mitarbeitenden der Kanzlei einen neuen Abschnitt im Menü, Listen und Datensatzseiten funktionieren wie überall in nexxus, und der KI-Assistent kann in den neuen Datensätzen suchen und Entwürfe anlegen, mit den Rechten der Person, die fragt.

So ein Paket ist ein **NXM-Modul**. Der Name kommt von der Dateiendung `.nxm`. In der App heißt der Katalog dieser Dateien <Ui>Pakete</Ui>.

<Screenshot src={shot_nxm_12} url="/x/acme.leihgeraete/geraet" alt={"Paketmodule im Menübereich Organisation"} caption={"Jedes Paket bekommt einen eigenen Abschnitt hinter den eingebauten."} />

## Was ein Modul mitbringt

Ein Paket beschreibt einen Fachbereich. Das meiste steht als Deklaration in einer einzigen Datei, dem Manifest `module.json`, und nexxus baut daraus Oberflächen und Prüfungen. Nur was sich nicht deklarieren lässt, ist Code, und dieser Code läuft nie in nexxus selbst.

<CardGrid>
  <Card title="Fachobjekte" icon="database">
    Zum Beispiel Akte oder Frist, mit typisierten Feldern: Text, Zahlen, Datumswerte, Auswahllisten und Verweise auf Partner, Benutzer, Dokumente oder andere Datensätze des Moduls. Laufende Nummern wie `2026/0184` vergibt nexxus selbst.
  </Card>
  <Card title="Listen und Datensatzseiten" icon="list-format">
    Deklariert statt programmiert. nexxus zeigt Listen mit Suche, Filtern und Sortierung und Datensatzseiten mit dem Reiter <Ui>Daten</Ui>, Bearbeitungsmodus und Bezugslisten.
  </Card>
  <Card title="Eigene Ansichten" icon="window">
    Seiten, Reiter und Dialoge, jeweils als eine abgeschlossene HTML-Datei. Sie laufen in einer Sandbox und kommen nur über das View-SDK an Daten, mit den Rechten der Person, die sie gerade ansieht.
  </Card>
  <Card title="Aktionen" icon="approve-check">
    Arbeitsschritte wie „ausleihen“, „freigeben“ oder „erledigen“, mit Bedingung, eigenem Recht und auf Wunsch einer Rückfrage. Jede Bedingung prüft der Server noch einmal.
  </Card>
  <Card title="Rechte und Rollen" icon="padlock">
    Jedes Fachobjekt bringt ein Lese- und ein Schreibrecht mit, das Modul ergänzt eigene Rechte, und seine Rollen erscheinen im Rolleneditor. Niemand bekommt eine Rolle automatisch.
  </Card>
  <Card title="KI-Assistent" icon="comment">
    Werkzeuge zum Suchen, Lesen, Anlegen und Ändern von Datensätzen, Anweisungen als Skill und Beispiel-Anweisungen je Ansicht. Jedes schreibende Werkzeug fragt vorher im Chat nach.
  </Card>
  <Card title="Moduldienste" icon="server">
    Optionale Programme außerhalb von nexxus, die rechnen, auf Änderungen reagieren oder Dokumente lesen. Sie arbeiten mit kurzlebigen Tokens und nur mit den Daten, denen der Administrator zugestimmt hat.
  </Card>
  <Card title="Versionen" icon="code-branch">
    Eine veröffentlichte Version ändert sich nie. Eine Aktualisierung kann Werte oder Felder in gespeicherten Datensätzen umbenennen, und nexxus zeigt vorher in einem Probelauf, was sich ändert.
  </Card>
</CardGrid>

## Eingebautes Modul, NXM-Modul oder App

nexxus lässt sich auf mehreren Wegen erweitern. Welcher passt, hängt davon ab, was entstehen soll und wer es baut.

| | Eingebautes Modul | NXM-Modul | App |
|---|---|---|---|
| **Was es ist** | Ein Teil von nexxus selbst, etwa Projekte, Zeiterfassung oder Dateien | Ein Fachmodul als `.nxm`-Paket | Ein kleines Werkzeug, dessen Dokumente Dateien sind, als `.nxa` |
| **Wer es baut** | Das nexxus-Team | Entwicklerinnen und Entwickler | Fachteams zusammen mit dem KI-Assistenten, oder Entwickler |
| **Wer es installiert** | Niemand: Es gehört zu jeder Instanz. Administratoren können ganze Fachbereiche abschalten | Administratoren, je Mandant | Jede Person für sich, Administratoren für den ganzen Mandanten |
| **Wo die Daten liegen** | In nexxus | Im Datensatzspeicher von nexxus, als typisierte Datensätze mit Indizes | In einem Dokument unter Dateien |
| **Wer was sehen darf** | Rechte, die nexxus festlegt | Eigene Rechte und Rollen | Die Freigabe des Dokuments |
| **KI-Assistent** | Eingebaute Werkzeuge | Eigene Werkzeuge, Anweisungen und Beispiel-Anweisungen | Die allgemeinen App-Werkzeuge |
| **Beispiel** | Projekte mit ihren Zeiten | Akten und Fristen einer Kanzlei | Ein Kanban-Board für das Onboarding neuer Mitarbeitender |

Ein **NXM-Modul** passt, wenn viele Personen mit Datensätzen in Listen arbeiten sollen, mit Rechten, Arbeitsschritten und einem Platz im Menü, und wenn das Modul in Versionen wächst, die gespeicherte Daten mitnehmen. Eine **App** passt, wenn am Ende ein Dokument steht, das Menschen öffnen, bearbeiten und teilen. Soll etwas für alle Kunden Teil von nexxus werden, ist es ein eingebautes Modul, und das baut das nexxus-Team.

Installierte Pakete stehen auch auf dem Reiter <Ui>Module</Ui> neben den eingebauten Modulen, mit dem Chip <Ui>Paket</Ui>, ihrer Version und ihrem Changelog.

<Screenshot src={shot_nxm_01} url="/modules" alt={"Die Modulliste mit installierten Paketen und dem Changelog des Tutorial-Pakets"} caption={"Installierte Pakete stehen neben den eingebauten Modulen, mit Version und Changelog."} />

## Eine Regel: Paketcode läuft nie in nexxus

Jede Plattform, die Kunden eine gemeinsame Installation erweitern lässt, muss entscheiden, wo deren Code läuft. nexxus hält ihn aus dem eigenen Prozess heraus. Ein Paket arbeitet deshalb auf drei Ebenen:

<Hub
  inputsLabel="Das Paket bringt"
  inputs={[
    { icon: 'file-cog', title: 'Deklarationen', text: 'Fachobjekte, Felder, Listen, Datensatzseiten, Menü, Aktionen, Rollen' },
    { icon: 'app-window', title: 'Eigene Ansichten', text: 'Eine HTML-Datei je Seite, Reiter oder Dialog' },
    { icon: 'server-cog', title: 'Moduldienst', text: 'Optional, läuft außerhalb von nexxus' },
  ]}
  core={{
    title: 'nexxus',
    text: 'Liest die Deklarationen, zeigt die Ansichten in einer Sandbox, ruft den Dienst mit signierten Tokens auf',
    items: ['Rechte', 'Datensätze', 'Zustimmung', 'Mandanten'],
  }}
  outputsLabel="Die Mitarbeitenden bekommen"
  outputs={[
    { icon: 'layout-list', title: 'Menü, Listen, Datensätze', text: 'Von nexxus gezeichnet wie jedes andere Modul' },
    { icon: 'panels-top-left', title: 'Seiten und Dialoge', text: 'Mit den Rechten der Person, die hinsieht' },
    { icon: 'bot', title: 'Werkzeuge für den KI-Assistenten', text: 'Schreibende Werkzeuge fragen vorher nach' },
  ]}
  caption="Deklarationen sind Daten, Ansichten laufen in der Sandbox, Dienste außerhalb. Jede Anfrage durchläuft dieselbe Rechteprüfung auf dem Server."
/>

1. **Deklarationen.** Fachobjekte, Felder, Listen, Datensatzseiten, Menüeinträge, Aktionen, Rollen und Einstellungen stehen als Daten in `module.json`. nexxus liest sie und baut daraus Oberflächen, Prüfungen und die Schnittstelle. Viele Module brauchen kaum mehr.
2. **Eigene Ansichten.** Wo Liste und Formular nicht reichen, bringt ein Paket eigene Oberflächen als HTML-Dateien mit. nexxus zeigt jede in einem abgeschotteten Rahmen ohne Netzwerkzugang. Die Ansicht holt ihre Daten über das View-SDK, und nexxus antwortet mit den Rechten der Person, die sie ansieht. Mehr unter [Ansichten und das View-SDK](/de/modules/views/).
3. **Moduldienste.** Arbeit, die ein Programm braucht, etwa Gerichtsfristen berechnen oder PDFs lesen, erledigt ein Dienst außerhalb von nexxus. nexxus ruft ihn mit einem kurzlebigen, signierten Token auf, und der Dienst ruft mit einem Token zurück, das nur den Zugriff enthält, dem der Administrator zugestimmt hat. Mehr unter [Moduldienste](/de/modules/services/).

Für Ihren Mandanten heißt das: Ein Paket kann weder Daten lesen, die es nicht bekommen hat, noch ein Recht umgehen, denn die Prüfung läuft auf dem Server und nie im Paket.

## Was jedes Modul von nexxus bekommt

Ein Paket muss nicht nachbauen, was nexxus schon kann:

- **Rechte.** Jede Liste, jeder Datensatz, jede Aktion, Ansicht und jedes Werkzeug prüft die Rechte der Person auf dem Server. Administratoren bestehen jede Prüfung.
- **Zustimmung.** Bevor ein Paket Daten außerhalb seiner eigenen anfassen darf (Partner, Benutzer, Dokumente) oder einen Dienst aufruft, hakt der Administrator jeden Punkt im Installationsdialog an. Will eine neue Version mehr, fragt die Aktualisierung erneut.
- **Mandanten.** Jeder Mandant installiert seine eigenen Pakete. Die Datensätze eines Mandanten sind für alle anderen unsichtbar.
- **In sich geschlossen.** Ein Paket baut nie auf einem anderen Paket auf; was zusammengehört, kommt als ein Paket. Auch das Abschalten eines Fachbereichs verbirgt ein Paket nicht, das tun nur Deaktivieren und Deinstallieren. Siehe [Pakete sind in sich geschlossen](/de/modules/structure/#pakete-sind-in-sich-geschlossen).
- **KI-Assistent.** Pakete bringen keinen eigenen Chat mit. Sie geben dem einen KI-Assistenten Werkzeuge, Anweisungen und Beispiel-Anweisungen, und er weiß, welches Modul, welchen Datensatz und welche Ansicht die Person gerade geöffnet hat.
- **Signaturen.** Herausgeber signieren Pakete mit dem eigenen Schlüssel, ohne ihn irgendwo anzumelden. Jeder Mandant entscheidet, ob er einem Schlüssel vertraut; ein Paket mit einem Schlüssel, dem er noch nicht vertraut, lässt sich hochladen und ansehen, aber nicht installieren. Unsignierte Pakete weist nexxus zurück, außer der Mandant oder der Betreiber der Instanz lässt sie zu (Entwicklungs- und Demo-Umgebungen tun das von sich aus). Siehe [Dem Herausgeber vertrauen](/de/modules/publish/#dem-herausgeber-vertrauen).

## Der Lebenslauf eines Pakets

<Flow
  steps={[
    { icon: 'package', title: 'Bauen', text: 'Manifest und Ansichten schreiben, den Ordner zur .nxm-Datei packen, signieren.' },
    { icon: 'upload', title: 'Hochladen', text: 'Ein Administrator lädt die Datei hoch. nexxus prüft sie und nennt jedes Problem.', tone: 'cyan' },
    { icon: 'shield-check', title: 'Prüfen und zustimmen', text: 'Die Paketseite zeigt, was das Paket mitbringt. Der Installationsdialog fragt nach Zustimmung und Rollen.', tone: 'lavender' },
    { icon: 'download', title: 'Installieren', text: 'Rollen, Beispieldaten und Menüeinträge entstehen. Das Modul ist aktiv.' },
    { icon: 'refresh-cw', title: 'Aktualisieren oder entfernen', text: 'Eine neue Version aktualisiert an Ort und Stelle. Deaktivieren und Deinstallieren behalten oder löschen die Daten.', tone: 'neutral' },
  ]}
  caption="Entwickler bauen die Datei. Administratoren laden sie hoch, installieren und aktualisieren sie unter Administration > Betrieb > Module, Reiter Pakete."
/>

Eine Installation hat einen von drei Zuständen, die der Katalog als Chip zeigt:

| Zustand | Bedeutung |
|---|---|
| <Ui>Aktiv</Ui> | Das Modul steht im Menü, Ansichten und Werkzeuge funktionieren. |
| <Ui>Deaktiviert</Ui> | Menüeinträge, Seiten und Werkzeuge sind für alle verschwunden. Daten, Rollen und Einstellungen bleiben, und <Ui>Aktivieren</Ui> bringt alles zurück. |
| <Ui>Entfernt, Daten behalten</Ui> | Das Modul wurde deinstalliert, seine Datensätze sind geblieben. Eine spätere Installation bindet sie wieder an. |

Deinstallieren mit <Ui>Daten löschen</Ui> entfernt die Installation ganz. Wie jeder Schritt abläuft, steht unter [Paketieren, installieren und aktualisieren](/de/modules/publish/). Was dabei mit gespeicherten Datensätzen passiert, erklärt [Daten und Aktualisierungen](/de/modules/data-and-upgrades/).

## Begriffe

- **Paket**: eine Version eines Moduls als `.nxm`-Datei, ein ZIP-Archiv mit Manifest, Changelog, Ansichten und Datendateien.
- **Manifest**: die Datei `module.json`, die alles deklariert, woraus das Modul besteht. Siehe [Aufbau eines Pakets](/de/modules/structure/).
- **Schlüssel**: der Name des Moduls in der Form `<herausgeber>.<name>`, etwa `curiaos.kanzlei`. Rechte, Werkzeuge und Adressen leiten sich daraus ab.
- **Fachobjekt**: ein Geschäftsobjekt des Moduls, etwa eine Akte. Die einzelnen Einträge sind **Datensätze**.
- **Ansicht**: eine Liste, eine Datensatzseite oder eine eigene HTML-Ansicht. Eigene Ansichten sitzen in einem **Slot**: Seite, Reiter am Datensatz, Dialog am Datensatz.
- **Aktion**: ein Arbeitsschritt an einem Datensatz, mit Bedingung und Recht.
- **Scope**: Daten außerhalb des Pakets, die seine Aktionen und Dienste nutzen dürfen, etwa `core:partner:read`.
- **Installation**: ein Paket in einem Mandanten, mit Version, Zustimmung und Einstellungen.
- **Moduldienst**: ein Programm außerhalb von nexxus, das das Modul aufruft oder das Ereignisse des Moduls bekommt.

## Wie es weitergeht

<CardGrid>
  <LinkCard title="Mit einer Einladung starten" description="Claude Code und eine Zeile aus Ihrer Einladung: Werkzeuge, Testmandant und ein erstes Modul in etwa einer Minute." href="/de/modules/invitation/" />
  <LinkCard title="Ihr erstes Modul" description="Ein kleines Leihgeräte-Register, vom leeren Ordner bis zum installierten Modul und seiner ersten Aktualisierung." href="/de/modules/first-module/" />
  <LinkCard title="Paketieren, installieren und aktualisieren" description="Die Seite der Administration: Katalog, Zustimmung, Rollen, Aktualisierungen und Deinstallation." href="/de/modules/publish/" />
  <LinkCard title="Fallstudie: CuriaOS" description="Ein Paket für eine Kanzlei, mit eigenen Ansichten und einem Fristendienst." href="/de/modules/curiaos/" />
</CardGrid>