03 — Frontmatter-Audit

Pruefung: Pflichtfelder pro Type, ID-Konsistenz, Schema-Drift.

Behoben

intern/lieferanten/ypsum.md

Fehlte category:-Feld (Schema 5.3 Pflicht). Auf category: service_provider gesetzt — Ypsum ist eine Partner-Agentur, weiterleitend, das passt unter die Schema-Werte (tool | freelancer | service_provider | infrastructure).

CLAUDE.md, CONTEXT.md, ONBOARDING.md

type: meta_doc ergaenzt (analog _meta/conventions.md, _meta/schemas.md etc.). last_reviewed: auf 2026-05-08 gesetzt.

AGENTS.md ist Symlink, faellt automatisch mit.

Bewusst NICHT geaendert

44 Files ohne type:-Feld

Alle gehoeren zu zwei Kategorien:

Kategorie 1 — Wissen-Files mit altem Frontmatter (32 Files):

  • intern/wissen/entscheidungen/*.md (7 Files: agent-native-architektur, anthropic-datenschutz, claude-dsgvo-setup, eu-ai-act-pflichten, llm-hosting-eu-optionen, runner-architektur, zugriffsmodell)
  • intern/wissen/glossar/*.md (2 Files: anthropic-skills, claude-plugins)
  • intern/wissen/prozesse/*.md (13 Files: cal-com-setup, claude-remote-server, librechat-railway-multiuser, m365-sharepoint-storage-voll, mac-screenshot-location, mobile-claude-architektur, pandoc-docx-pdf-pipeline, payload-r2-railway-setup, prompt-engineering, saas-partnervertrag-pattern, seatable-permissions-api, shopify-b2b-lexify-sync, web-hero-sequence-animation)
  • intern/firma/*.md (4 Files: brand, fahrplan, leistung-claude-dsgvo-hosting, positioning)
  • assets/firma/... (3 Files)

Migration-Log §“Frontmatter-Schema-Wechsel” sagt explizit:

„Bei den kopierten Wissen-Files (Welle 3 sub 3) ist das alte Frontmatter teils unangetastet — sollte beim naechsten Editieren auf neues Schema umgestellt werden.”

Bewusster Migrations-Stand, kein Bug. Schema-Migration laeuft beim Editieren.

Kategorie 2 — SKILL.md Files (10 Files):

Alle 10 SKILL.md-Files (email-review, email-schreiben, image-gen, inbox-sync, mcp-cloud-bereitstellung, mcp-eigenbau, tages-planung, termin-koordinieren, wiki-maintenance) plus wochen-planung/plan.md und 2 Reference-Files unter image-gen/references/.

Diese folgen Anthropic-SKILL-Schema (name: + description:-only Frontmatter), nicht dem Vault-Schema (Schema 5.17). Das ist konsistent mit dem Plugin-Format — aber der Vault verlangt id: + type: skill + required_mcps: + status: etc.

Folge: Die Skill-↔-MCP-Cross-Refs koennen nicht symmetrisch geprueft werden:

MCPclaimed used_by_skillsSkill claims required_mcps
gsuite5 Skills (email-schreiben, email-review, …)— (kein required_mcps-Feld in den SKILL.md)
replicate1 Skill (image-gen)

Marvin-Entscheidung noetig: SKILL.md auf Vault-Schema umstellen (id, type: skill, required_mcps, status, last_used) ODER Plugin-Format akzeptieren und Schema 5.17 verwerfen ODER doppeltes Frontmatter (Plugin-Pflicht + Vault-Felder).

Index-/Container-Files ohne id: (13 Files)

_index.md Files (intern/capabilities/_index.md, intern/capabilities/aws/_index.md, intern/capabilities/mcps/_index.md, intern/capabilities/repos/_index.md, intern/capabilities/skills/_index.md, intern/runs/_index.md, intern/wissen/entscheidungen/_index.md, intern/wissen/prozesse/_index.md, intern/wissen/glossar/_index.md, intern/wissen/templates/_index.md) sowie _meta/config.md, intern/projekte/bas-twin/meilensteine.md, intern/projekte/bas-twin/verlauf.md.

Schema sieht keine id: fuer Container-Files vor — diese sind reine Inventarlisten oder Projekt-Subfiles. Kein Issue.

ID-Konsistenz

Keine echten Duplikate. Die initiale Suche fand „6 Duplikate”, aber alle waren Beispiele in _meta/schemas.md Code-Bloecken (cust-001 / proj-2026-001 / pers-014 / mcp-papierkram / repo-mcp-papierkram / script-2026-042) — nicht echte Duplikate.

ID-Schema-Stichprobe sauber:

  • 8 Customers: cust-001 bis cust-008
  • 19 Personen: pers-001 bis pers-019
  • 9 Projekte: proj-2026-001 bis proj-2026-009
  • 8 MCPs: mcp-<name> Schema (gsuite, m365, papierkram, ticketpay, …)
  • 8 Repos: repo-mcp-<name> Schema
  • 1 Lieferant: supplier-001 (Schema sagt sup- ODER supplier- ist OK)

Cross-Refs (Detail aus Check D)

Customers (8/8):

Kundecontact_mainStatus
maydayconny-schmidt
beckerralf-schmid
ickingnicole-icking
ladezonpaul-radau
beerthorsten-beer
erleimarkus-erlei
vibe-factoryandre-vibe-factory
koehnemann-designjoern-koehnemann

Projekte (9/9): alle haben validen Customer + Owner + Team. Frontmatter sauber.

MCPs ↔ Repos: alle 8 active+configured MCPs zeigen auf existierendes Repo via source:. Keine waisen.

Empfehlung Schema-Migration

Wenn Marvin 2-3 Stunden investieren will, kann das Vault auf einheitliches Schema gebracht werden:

  1. Wissen-Files: Frontmatter umstellen auf type: process / type: glossary_entry / type: decision_record. Schemas entsprechend in _meta/schemas.md ergaenzen (Schema 5.21 Process, 5.22 Glossary).
  2. SKILL.md Files: Schema 5.17 umsetzen — id, type: skill, name, description, purpose, required_mcps, required_tools, status. Anthropic-Plugin-Felder bleiben kompatibel daneben.
  3. Container-Files: _index.md Schema in _meta/schemas.md 5.x ergaenzen (Index, type-spezifisch).

Alternativ: dokumentieren dass Schema-Migration ein „lebender Prozess” ist und nur fuer aktiv editierte Files passiert (was Migration-Log §Frontmatter-Schema-Wechsel implizit sagt).