Harness-Registry

Die Harness-Registry ist das Adapter-Inventar, das als Quelle der Wahrheit dient und von der CLI, der Dokumentation, den Fixture-Tests und der Validierung der Konventions-Pins verwendet wird. Die Laufzeitquelle ist src/apothem/lib/harness_registry.py; jede Zeile unten ist auf diese Registry, die adapterspezifische capabilities.yml und die STANDARD-CONVENTION-PIN.md jedes Adapters rückführbar.

Registry-MatrixCopy Anchor Link

Unterstützung der Payload-KohortenCopy Anchor Link

Die Statuswerte sind native, converted, support-tree, profile-projected, unsupported, not-applicable und discovery-pending.

Eine converted-Kohorte wird in das eigene Format des Harness umgeschrieben, und manche Quellfelder haben darin keinen Platz. Für jede konvertierte Kohorte aus Commands, Agenten oder Regeln trägt die capabilities.yml des Adapters eine conversion_losses-Map, die angibt, was mit jedem Frontmatter-Feld der Quelle geschieht:

Ein Test rendert jede konvertierte Datei und prüft die Maps gegen die Ausgabe.

Die Tabelle lässt die Zellen weg, die die Registry als not-applicable markiert: Tool-Einschränkungen bei jedem Harness außer Kimi Code (discovery-pending) und GLM (Z.ai) (unsupported) sowie Memory bei Claude Code, CodeBuddy, Codex, Hermes, Kiro, Open-Claw, OpenCode und Qwen Code.

Gemeinsame WurzelverzeichnisseCopy Anchor Link

Manche Installationsziele werden von anderen Harnesses geladen als von dem, der sie schreibt. Die Registry erfasst jeden solchen Pfad in SHARED_ROOTS mit einem registrierten Eigentümer (dem Adapter, für den der Vendor den Pfad dokumentiert), den Mitinstallierern, die dieselben Dateien dorthin schreiben, und den Lesern, deren Vendor-Dokumentation ihn standardmäßig lädt, dazu die Vendor-Seiten, die das belegen, und das Datum, an dem sie abgerufen wurden.

Ein Pfad mit Mitinstallierern ist ein Ordner auf Benutzerebene im Home-Verzeichnis, den mehrere Installationen mit denselben Bytes schreiben. Eine Maschine, auf der nur Cursor installiert ist, hat kein Codex, das ~/.agents/skills/ schreibt, daher schreibt jede Installation, die den Ordner nennt, ihn, und das Installations-Ledger zählt die Installationen, die ihn nutzen. Eigentümer laut Eintrag ist der registrierte Eigentümer, solange er den Ordner nutzt, und andernfalls die älteste Installation, die ihn nutzt; nichts wird verschoben, wenn der registrierte Eigentümer deinstalliert wird. Eine Deinstallation entfernt den Ordner nur, wenn keine andere Installation ihn noch nutzt (siehe uninstall). Die Installation eines Lesers legt keine Dateien in dem Ordner ab; die Installation des Eigentümers oder eines Mitinstallierers stellt Apothem-Inhalte jedem Leser bereit.

~/.config/apothem/rules/ und ~/.config/apothem/templates/ enthalten die Dateien, die Apothems eigene Skills und Anweisungsdateien zitieren. Kein anderes Werkzeug lädt sie, daher haben sie keine Leser und keine Vendor-Seiten. CodeBuddy, Kiro und Trae schreiben außerdem einen eigenen Skills-Ordner (~/.codebuddy/skills/, ~/.kiro/skills/ und ~/.trae/skills/); nur das jeweilige Werkzeug lädt ihn, daher ist er kein gemeinsames Wurzelverzeichnis.

Ein Leser wird nur dort aufgeführt, wo seine Vendor-Dokumentation ein standardmäßiges Laden genau dieses Pfads zeigt. Ein Leser ist an eine Bedingung geknüpft, und der Installationshinweis wiederholt sie: Open-Claw indiziert ~/.agents/skills/ nur unter seinem Standard-Zustandsverzeichnis (es überspringt den Ordner, wenn OPENCLAW_STATE_DIR woandershin zeigt). Die Cursor-Dokumentation führt ~/.codex/agents/ als Codex-Kompatibilitätsordner auf, sagt aber nicht, welche Dateiformate Cursor dort parst, und eine Codex-Installation schreibt TOML-Dateien, daher ist nicht bestätigt, ob Cursor diese Helfer liest. Die Cursor-Installation schreibt außerdem eine eigene Kopie der Helfer nach <project>/.cursor/agents/, die die Rangfolge des Vendors über die importierten Ordner stellt, sodass in einem installierten Projekt die native Kopie die aus ~/.claude/agents/ ablöst.

Manche Werkzeuge sind bewusst keine Leser von ~/.agents/skills/: Die Dokumentation von Antigravity, CodeBuddy, Kiro und Trae sagt nicht, dass sie ihn standardmäßig laden (Trae lädt den Projektordner .agents/skills/ erst, nachdem eine Einstellung aktiviert wurde), weshalb CodeBuddy, Kiro und Trae einen eigenen Skills-Ordner erhalten. Die Hermes-Dokumentation nennt ihn nur als Beispielwert für skills.external_dirs. GitHub Copilot ist kein Leser von ~/.claude/agents/: Die VS Code-Dokumentation führt diesen Ordner für den Anthropic-Claude-Agenten auf, nicht für den Agenten, den GitHub Copilot ausführt.

Der Apothem-Block, den ein Eigentümer in eine gemeinsame Anweisungsdatei schreibt, nennt kein einzelnes Werkzeug als seinen Leser. tests/unit/test_shared_roots.py schlägt fehl, wenn die Adapter, die ein Registry-Ziel schreiben, nicht genau sein Eigentümer und seine Mitinstallierer sind, und wenn ein Registry-Ziel, das wie eine werkzeugübergreifende Anweisungsdatei benannt ist (AGENTS.md, CLAUDE.md, GEMINI.md, copilot-instructions.md), keinen deklarierten Eigentümer hat. Die einzige Ausnahme ist ~/.codex/AGENTS.md; kein anderer registrierter Harness dokumentiert, dass er diese Datei lädt.

Validierungs-HooksCopy Anchor Link

Die Registry bleibt durch diese Prüfungen synchron:

Generierte Harness-Adapter-ReferenzCopy Anchor Link