vault irregular

Zeigt Dateien im Vault an, die nicht als reguläre Entität oder regulärer Asset-Datei gelten — typischerweise extern eingefügte Markdown-Dateien ohne NanoID, durch einen externen Editor korrumpierte Entitäten oder Asset-Binärdateien ohne Schema-Suffix.

Grundaufruf

apparat vault irregular

Apparat scannt content/ und assets/ und listet alles, was die Konventionen verletzt:

Vault "recherche" — irregular files:

[entity]   content/2026-04-19--notiz.md
  file.schema              Content filename does not match the entity schema.
  Fix: apparat entity import <pfad>

[entity]   content/2026-04-20--broken--Ab12Cd34.md
  language.missing         Pflichtfeld `language` fehlt oder ist leer.
  Fix: apparat entity import <pfad>

[asset]    assets/photo.jpg
  asset.schema             Asset filename does not match the asset schema.
  Fix: apparat entity attach <entity-id> <pfad> --move  (assign to an owning entity)

3 irregular file(s) found.

Jede Zeile zeigt den Befund (Rule-ID + Nachricht) und einen kurzen Fix-Hinweis. Der Exit-Code ist immer 0 — irreguläre Dateien sind eine Information, kein Fehler.

Was zählt als irregulär?

Eine Datei unter content/ ist irregulär, sobald eine dieser Bedingungen zutrifft:

  1. Dateiname-Schema verletzt — der Name entspricht nicht YYYY-MM-DD--slug--nanoid.md.
  2. Frontmatter fehlt oder parst nicht — kein ----Block oder defektes YAML.
  3. Pflichtfeld fehlt — eines von id, type, created, language ist nicht gesetzt oder hat eine nicht-konforme Form.
  4. NanoID-Mismatch — die NanoID im Dateinamen weicht vom id-Feld im Frontmatter ab.

Für Asset-Dateien unter assets/ gibt es nur ein einziges Kriterium: Dateiname verletzt das Asset-Schema (YYYY-MM-DD--slug--nanoid.<ext>). Assets haben kein eigenes Frontmatter und keine Pflichtfelder.

Die Sicht ist abgeleitet

vault irregular hält keinen eigenen Zustand vor — es ist bei jedem Aufruf ein frischer Scan. Eine Datei, die du extern korrigierst (z.B. im Editor das fehlende language-Feld einfügst), verschwindet beim nächsten Aufruf automatisch aus der Liste. Es gibt keine Persistenz, keine „Inbox", die gepflegt werden muss.

JSON-Ausgabe

Für Skripte oder Tooling:

apparat vault irregular --json

Gibt ein JSON-Objekt auf stdout aus:

{
  "vault": {
    "name": "recherche",
    "url": "https://apparat.example.com/vaults/recherche",
    "path": "/home/max/vaults/recherche"
  },
  "count": 3,
  "files": [
    {
      "kind": "entity",
      "file": "content/2026-04-19--notiz.md",
      "issues": [
        { "rule": "file.schema", "message": "..." }
      ]
    },
    ...
  ]
}

Vault wählen

Ohne --vault verwendet Apparat die übliche Auflösung (CWD → einziger registrierter Vault → interaktive Auswahl). Mit --vault übersteuerst du sie:

apparat vault irregular --vault=arbeit
apparat vault irregular --vault=/home/max/vaults/arbeit

Wie man aufräumt

Sanierung direkt aus dem Listing

Interaktiv bietet Apparat am Ende der Liste an, alle irregulären Entitäten in einem Rutsch zu sanieren:

3 irregular file(s) found.

 ┌ Sanitise the listed entities now? (Asset entries are always skipped.)
 │ ◯ Yes / ● No

Ein Ja startet pro Entity-Eintrag einen Durchlauf des entity import-Walkthroughs. Asset-Einträge werden mit einem Hinweis übersprungen, weil sie keinen standalone Import-Weg haben (sie müssen einer Entität zugeordnet werden — siehe oben).

Für Skripte oder wenn die Rückfrage stört, gibt es den Flag --fix:

apparat vault irregular --fix

Das überspringt die Rückfrage und geht direkt in den Sanitisierungs-Lauf. Kombination mit --no-interaction funktioniert als Best-Effort: Der pro-Datei-Walkthrough läuft non-interactive, d.h. jede Datei wird nur dann saniert, wenn sich alle Pflichtfelder aus ihrem Frontmatter oder den Config-Defaults auflösen lassen. Dateien, bei denen z.B. der Typ fehlt, werden mit klarer Fehlermeldung übersprungen und in der Summary gezählt.

Am Ende gibt es eine Zusammenfassung:

Sanitisation finished — 5 sanitised, 2 failed, 1 asset(s) skipped.
  Assets must be attached to an owning entity; run `apparat entity attach <entity-id> <pfad> --move` for each.
⚠ 2 import(s) did not complete — inspect the output above for the specific reason(s).

Der Exit-Code ist 0, wenn jede angepackte Entity-Sanierung erfolgreich war (Asset-Skips zählen nicht als Fehler); andernfalls 1.

Für eine umfassendere Konventionsprüfung inklusive Warnings (nicht-englische Frontmatter-Schlüssel, CamelCase-Tags etc.) ist vault validate das richtige Werkzeug. vault irregular ist der schnelle Blick auf „was muss ich sanieren, damit eine Datei als reguläre Entität zählt?" — und mit --fix der kürzeste Weg dahin.