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:
| MCP | claimed used_by_skills | Skill claims required_mcps |
|---|---|---|
gsuite | 5 Skills (email-schreiben, email-review, …) | — (kein required_mcps-Feld in den SKILL.md) |
replicate | 1 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-001biscust-008 - 19 Personen:
pers-001bispers-019 - 9 Projekte:
proj-2026-001bisproj-2026-009 - 8 MCPs:
mcp-<name>Schema (gsuite, m365, papierkram, ticketpay, …) - 8 Repos:
repo-mcp-<name>Schema - 1 Lieferant:
supplier-001(Schema sagtsup-ODERsupplier-ist OK)
Cross-Refs (Detail aus Check D)
Customers (8/8):
| Kunde | contact_main | Status |
|---|---|---|
| mayday | conny-schmidt | ✅ |
| becker | ralf-schmid | ✅ |
| icking | nicole-icking | ✅ |
| ladezon | paul-radau | ✅ |
| beer | thorsten-beer | ✅ |
| erlei | markus-erlei | ✅ |
| vibe-factory | andre-vibe-factory | ✅ |
| koehnemann-design | joern-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:
- Wissen-Files: Frontmatter umstellen auf
type: process/type: glossary_entry/type: decision_record. Schemas entsprechend in_meta/schemas.mdergaenzen (Schema 5.21 Process, 5.22 Glossary). - SKILL.md Files: Schema 5.17 umsetzen —
id,type: skill,name,description,purpose,required_mcps,required_tools,status. Anthropic-Plugin-Felder bleiben kompatibel daneben. - Container-Files:
_index.mdSchema in_meta/schemas.md5.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).