Chemenu 2.1.0 - deterministischer Wissenskompiler
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki: raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren Grenzen in Code durchgesetzt sind statt im Prompt. Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44 Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist. Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs. Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte. Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet - siehe NOTICE.
This commit is contained in:
@@ -0,0 +1,93 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [arch-linux, packaging, repository]
|
||||
created: 2026-07-31
|
||||
modified: 2026-09-01
|
||||
related: [Arch Linux, Aura, makepkg, GPG]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Gemeinschaftlich gepflegtes Repository für Arch-Linux-Pakete, gebaut aus PKGBUILD-Quellbeschreibungen.
|
||||
---
|
||||
# AUR
|
||||
|
||||
**Typ:** Tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das **Arch User Repository (AUR)** ist ein community-gestütztes Repository für Arch Linux-Pakete. Es enthält Paketbeschreibungen (PKGBUILDs), die es Benutzern ermöglichen, Pakete von der Quelle mit makepkg zu kompilieren und zu installieren, wobei die resultierenden Pakete durch pacman verwaltet werden.
|
||||
|
||||
Auf das AUR wird üblicherweise mit AUR-Helfern wie [[Aura]] zugegriffen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Community-Paket-Repository für Arch Linux
|
||||
- **Status:** Aktiv
|
||||
- **Zugang:** Webbasiert unter https://aur.archlinux.org
|
||||
- **Tool:** `makepkg` zum Erstellen, `pacman` zur Installation
|
||||
- **Git-basiert:** Jedes Paket ist ein Git-Repository
|
||||
- **AUR-Helfer:** [[Aura]], yay, paru und andere
|
||||
|
||||
## Paketwartung
|
||||
|
||||
### Wartungsbefehle
|
||||
```bash
|
||||
# Clone a package repository
|
||||
git clone ssh://aur@aur.archlinux.org/<package-name>.git
|
||||
|
||||
# Update package
|
||||
git pull
|
||||
|
||||
# Submit changes (not committed - local only per workflow)
|
||||
# Note: The AUR AGENTS.md workflow explicitly states "Never commit or push changes"
|
||||
# This is a local maintenance workflow only
|
||||
```
|
||||
|
||||
## AUR-Helfer
|
||||
|
||||
AUR-Helfer automatisieren den Prozess des Erstellens und Installierens von Paketen aus dem AUR:
|
||||
|
||||
### Aura
|
||||
[[Aura]] ist ein sicherer, Rust-basierter AUR-Helper, der sichere Standardwerte bietet und sich in den AUR-Workflow integriert. Er unterstützt benutzerdefinierte Build-Verzeichnisse und GPG-Schlüsselverwaltung.
|
||||
|
||||
**Beispielbefehle:**
|
||||
```bash
|
||||
# Install a package
|
||||
aura -A <package-name>
|
||||
|
||||
# Sync and upgrade all packages
|
||||
aura -Syu
|
||||
```
|
||||
|
||||
**Wichtig:** AUR GPG-Schlüssel müssen in den **Benutzer-** GPG-Keyring importiert werden, nicht in den des Administrators. Siehe [[GPG]] für Details.
|
||||
|
||||
## GPG-Schlüsselverwaltung
|
||||
|
||||
Für signierte AUR-Pakete ist eine ordnungsgemäße GPG-Schlüsselverwaltung entscheidend:
|
||||
- Schlüssel immer in den Benutzer-Keyring importieren, nicht in den des Administrators
|
||||
- Zum Importieren von Schlüsseln `gpg --recv-key KEY_ID` verwenden
|
||||
- Siehe [[GPG]] für vollständige Schlüsselverwaltungsinformationen
|
||||
|
||||
## Workflow-Integration
|
||||
|
||||
Das AUR ist zentral für den Arch-Linux-Paketierungsworkflow zum Konvertieren von Debian-Paketen in das Arch-Format. Zum Erstellen von AUR-Paketen ist [[makepkg]] das zugrundeliegende Build-Tool.
|
||||
|
||||
## Python-Paket-Neuinstallation
|
||||
|
||||
Nach Python-Versionsupgrades werden alle AUR Python-Pakete neu installiert, um Kompatibilität zu gewährleisten:
|
||||
```bash
|
||||
aura -A $(pacman -Qqm | xargs -I {} pacman -Ql {} | grep "/usr/lib/python3.12/site-packages" | cut -d'/' -f1)
|
||||
```
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Arch Linux]]
|
||||
- [[Aura]]
|
||||
- [[makepkg]]
|
||||
- [[GPG]]
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://aur.archlinux.org
|
||||
- https://wiki.archlinux.org/title/Arch_User_Repository
|
||||
- https://wiki.archlinux.org/title/AUR_helpers
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [ci-cd, gitea, docker, runner]
|
||||
created: 2026-07-25
|
||||
modified: 2026-09-01
|
||||
related: [Gitea, Gitea Actions, Docker]
|
||||
sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Offizieller Gitea-Actions-Runner, der CI/CD-Workflows in Docker-Containern auf einer dedizierten Runner-VM ausführt; JavaScript-Actions brauchen node im Job-Container
|
||||
---
|
||||
# Act Runner
|
||||
|
||||
**Typ:** Tool (Gitea Actions Runner)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
`act_runner` ist die offizielle Runner-Implementierung für Gitea Actions. Sie führt CI/CD-Workflows auf der VM `ci-runner.example.net` aus und läuft als Docker-Container im Host-Network-Modus, damit die Verbindung zu den Job-Containern und zum Actions Cache Server funktioniert.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Ausführen von Gitea-Actions-Workflows
|
||||
- **Status:** Aktiv (Stand 2026-07-12)
|
||||
- **Container-Image:** `gitea/act_runner:latest`
|
||||
- **Containername:** `act_runner`
|
||||
- **Restart Policy:** `unless-stopped`
|
||||
- **Network Mode:** `host` (entscheidend für die Cache-Anbindung)
|
||||
|
||||
## Architektur
|
||||
|
||||
### Container-Konfiguration
|
||||
```yaml
|
||||
services:
|
||||
act_runner:
|
||||
image: gitea/act_runner:latest
|
||||
container_name: act_runner
|
||||
restart: unless-stopped
|
||||
network_mode: host
|
||||
environment:
|
||||
- CONFIG_FILE=/config.yaml
|
||||
- GITEA_INSTANCE_URL=http://192.0.2.10:3000
|
||||
- GITEA_RUNNER_REGISTRATION_TOKEN=${GITEA_RUNNER_REGISTRATION_TOKEN}
|
||||
- GITEA_RUNNER_NAME=ci-vm-runner
|
||||
volumes:
|
||||
- ./data:/data
|
||||
- ./config.yaml:/config.yaml:ro
|
||||
- /var/run/docker.sock:/var/run/docker.sock
|
||||
```
|
||||
|
||||
### Wesentliche Konfigurationseinstellungen
|
||||
|
||||
**config.yaml:**
|
||||
```yaml
|
||||
cache:
|
||||
enabled: true
|
||||
host: "192.0.2.10" # static IP of ci-runner.example.net
|
||||
port: 8088
|
||||
|
||||
container:
|
||||
network: "" # empty = each job gets isolated bridge network
|
||||
```
|
||||
|
||||
### Routing-Labels
|
||||
Eigene semantische Labels anstelle der Standard-Ubuntu-Labels:
|
||||
- `linux-docker`
|
||||
- `container-builder`
|
||||
- `k3s-deploy`
|
||||
|
||||
Damit lassen sich Workflows gezielt an Runner mit bestimmten Capabilities leiten.
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** Ökosystem [[Gitea Actions]]
|
||||
- **Verbindet sich mit:** [[Gitea]]-Instanz unter `docker-host.example.net`
|
||||
- **Verwendet:** [[Docker]] für die Container-Ausführung
|
||||
- **Verwaltet:** Job-Container mit isolierten Bridge-Netzen
|
||||
|
||||
## Netzwerk
|
||||
|
||||
### Host-Network-Modus
|
||||
Die entscheidende Einstellung, die das Problem mit dem Actions Cache Server gelöst hat:
|
||||
- Der Runner-Container nutzt `network_mode: host`
|
||||
- Dadurch erreichen Job-Container den Cache-Server unter der konfigurierten statischen IP
|
||||
- Die Cache-URL wird automatisch als Umgebungsvariable `ACTIONS_CACHE_URL` gesetzt
|
||||
- **Wichtig:** `network_mode: host` und ein `networks:`-Block schließen sich in Docker Compose gegenseitig aus
|
||||
|
||||
### Isolation der Job-Container
|
||||
Obwohl der Runner im Host-Netz läuft:
|
||||
- Jeder CI-Job läuft in einem eigenen, temporären Bridge-Netz
|
||||
- `container.network: ""` in der `config.yaml` stellt das sicher
|
||||
- Die Job-Isolation bleibt erhalten
|
||||
- Nur der Runner-Prozess selbst hat Zugriff auf das Host-Netz
|
||||
|
||||
## Verwaltung von Secrets
|
||||
|
||||
### 1Password-Anbindung
|
||||
- Das Service-Account-Token wird über eine systemd-`EnvironmentFile` eingespielt (`/etc/act_runner/secrets.env`)
|
||||
- Es ist das einzige Secret, das als Umgebungsvariable vorliegt
|
||||
- In Gitea heißt das ein "Actions Secret"
|
||||
- Workflows holen weitere Secrets zur Laufzeit über `1password/load-secrets-action@v2`
|
||||
|
||||
### Gitea-Token
|
||||
- Workflows können `${{ gitea.token }}` zur Authentifizierung verwenden
|
||||
- Genutzt für Image-Pushes in die Gitea Container Registry
|
||||
- Erfordert `permissions: packages: write` im Workflow
|
||||
- Reicht auch für **Releases, Tags und Asset-Uploads**; ein Actions-Secret mit
|
||||
`write:repository` ist dafür nicht nötig. Belegt dadurch, dass ein Release-Workflow beim
|
||||
Versionssprung von selbst feuerte und Tarball samt `.sha256` ablegte[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
|
||||
## Betrieb
|
||||
|
||||
### Neustartverhalten
|
||||
- Nach Netzwerkänderungen ist ein vollständiges `docker compose down && docker compose up -d` nötig
|
||||
- Ein einfaches `docker restart` übernimmt Änderungen an `network_mode` **nicht** zuverlässig
|
||||
|
||||
### Persistenz
|
||||
- Workflow-Daten liegen im Volume `./data`
|
||||
- Konfiguration in `./config.yaml` (nur lesend eingebunden)
|
||||
- Docker-Socket eingebunden für den Zugriff auf BuildKit
|
||||
|
||||
## JavaScript-Actions brauchen `node` im Job-Container
|
||||
|
||||
Nennt ein Job sein eigenes `container:`-Image, führt act_runner JavaScript-Actions - darunter
|
||||
`actions/checkout` - mit `node` **innerhalb dieses Job-Containers** aus. Ein schlankes Image
|
||||
bringt keins mit, und der Lauf endet vor dem ersten eigenen
|
||||
Schritt[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
```
|
||||
OCI runtime exec failed: exec: "node": executable file not found in $PATH
|
||||
❌ Failure - Main actions/checkout@v4
|
||||
exitcode '127': command not found
|
||||
```
|
||||
|
||||
Der erste Schritt eines solchen Jobs muss deshalb `nodejs` nachinstallieren, **vor** dem
|
||||
Checkout[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
```yaml
|
||||
- name: Install CI Dependencies
|
||||
run: apt-get install -y --no-install-recommends git nodejs curl unzip ca-certificates build-essential
|
||||
- name: Checkout Code
|
||||
uses: actions/checkout@v7
|
||||
```
|
||||
|
||||
Bekannt funktionierende Kombination auf dieser Installation, nicht neu
|
||||
herzuleiten[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
- `actions/checkout@v7` und `actions/upload-artifact@v3` (v4 ist auf dieser Instanz eingeschränkt)
|
||||
- `debian:trixie-slim` als Job-Image; es trägt python3 3.13
|
||||
- Die Labels `linux-docker` und `container-builder` nehmen beide einen Job an, der sein eigenes
|
||||
Image benennt
|
||||
|
||||
Ein gepinntes Image war ursprünglich als Vorsichtsmaßnahme gegen die undokumentierte Zuordnung
|
||||
von `linux-docker` zu einem Image gewählt worden. Die Vorsichtsmaßnahme verursachte den
|
||||
Fehlschlag: Das Label routete von Anfang an korrekt und startete den Container, nur fehlte im
|
||||
gewählten Image `node`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
## Läufe sind von außen nicht beobachtbar
|
||||
|
||||
Bei einem privaten Repository antwortet [[Gitea]] einem anonymen Aufrufer mit einem identischen
|
||||
`404` für ein unsichtbares und für ein nicht existierendes
|
||||
Repository[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Aus einem
|
||||
`curl` gegen die API lässt sich damit kein Rückschluss auf den Lauf-Zustand ziehen. Läufe und
|
||||
ihre Logs werden über den [[Gitea MCP Server]] gelesen.
|
||||
|
||||
## Erprobte CI/CD-Szenarien
|
||||
|
||||
Der Runner deckt drei Szenarien nachweislich ab:
|
||||
1. **Arch-Paketbau** - Builder-Benutzer ohne Root-Rechte, `actions/upload-artifact@v3`
|
||||
2. **Container-Builds** - Debian-basierte Images, entferntes BuildKit
|
||||
3. **K3s-Deployments** - Kubeconfig aus 1Password, kubectl-Operationen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-12] - Network Mode auf `host` umgestellt, um die Anbindung an den Actions Cache Server zu reparieren (ETIMEDOUT auf 172.18.0.2:39329)
|
||||
- [2026-07-25] - Entity-Seite aus dem Quellen-Ingest erstellt
|
||||
- [2026-08-30] - Ursache der bis dahin unerklärten Workflow-Fehlschläge geklärt: fehlendes
|
||||
`node` im gepinnten Job-Image, nicht ein falsches Runner-Label. `nodejs` vor dem Checkout und
|
||||
`actions/checkout@v7` als Abhilfe festgehalten[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- Host-System
|
||||
- [[Gitea]] - Git-Dienst
|
||||
- [[Gitea Actions]] - CI/CD-Plattform
|
||||
- [[Docker]] - Container-Plattform
|
||||
- Secrets-Verwaltung
|
||||
- Behebung des Actions-Cache-Server-Problems
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [llm, memory, agent, knowledge-management, python]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [iii Engine, LLM Wiki Pattern, Memory Lifecycle, Knowledge Graph]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Persistenter Speicher für KI-Coding-Agenten; setzt Wissensgraph- und Lifecycle-Management-Muster um.
|
||||
---
|
||||
# Agent Memory
|
||||
|
||||
**Typ:** Tool (Persistente Memory-Engine für KI-Agenten)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
[agentmemory](https://github.com/rohitg00/agentmemory) ist eine persistente Memory-Engine für KI-Coding-Agenten mit über 20.000 Stars auf GitHub. Sie bietet die Infrastruktur für KI-Agenten, um langfristig Erinnerungen über Sitzungen hinweg zu bewahren, was ihnen ermöglicht, Kontext zu speichern, von früheren Interaktionen zu lernen und auf vorherigem Wissen aufzubauen.
|
||||
|
||||
Basierend auf [iii-engine](https://github.com/iii-hq/iii) löst agentmemory die praktischen Herausforderungen der Implementierung des LLM-Wiki-Musters im großen Maßstab. Sie dient als bewährte Implementierung vieler in LLM Wiki v2 beschriebener Konzepte, insbesondere im Hinblick auf Memory Lifecycle Management, Knowledge Graphs und Event-Driven Automation.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Persistente Memory für KI-Coding-Agenten
|
||||
- **Status:** Aktiv (20K+ GitHub-Stars)
|
||||
- **Sprache/Technik:** Python-basiert
|
||||
- **Repository:** [github.com/rohitg00/agentmemory](https://github.com/rohitg00/agentmemory)
|
||||
- **Autor:** [[Rohit Gupta]]
|
||||
- **Basiert auf:** [[iii Engine]]
|
||||
- **Verwandtes Muster:** [[LLM Wiki Pattern]]
|
||||
|
||||
## Features
|
||||
|
||||
Basierend auf den Lektionen von agentmemory (wie in LLM Wiki v2 beschrieben):
|
||||
|
||||
- **Memory Lifecycle Management:** Implementiert Confidence Scoring, Supersession und Vergessen-Mechanismen
|
||||
- **Knowledge Graph:** Strukturierte Entities mit typisierten Beziehungen für bessere Abfragen und Entdeckung
|
||||
- **Event-Driven Automation:** Hooks für Auto-Ingest, Auto-Lint und Context-Injection
|
||||
- **Hybrid Search:** Kombiniert BM25, Vektorsuche und Graph-Traversierung
|
||||
- **Qualitätskontrollen:** Self-Healing-Mechanismen und Konfliktauflösung
|
||||
- **Multi-Agent-Unterstützung:** Mesh-Synchronisierung für parallele Agent-Zusammenarbeit
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Implementiert:** [[LLM Wiki Pattern]]
|
||||
- **Basiert auf:** [[iii Engine]]
|
||||
- **Erstellt durch:** [[Rohit Gupta]]
|
||||
- **Erweitert:** [[Knowledge Graph]] Concepts
|
||||
- **Nutzt:** [[Memory Lifecycle]] Mechanismen
|
||||
- **Verwandt mit:** [[Event-Driven Automation]]
|
||||
|
||||
## Anwendungsfälle
|
||||
|
||||
- Kontext über mehrere Coding-Sitzungen hinweg beibehalten
|
||||
- Persistente Knowledge Bases für KI-Agenten erstellen
|
||||
- Agenten ermöglichen, von früheren Interaktionen zu lernen
|
||||
- Langfristige Memory für Forschungs- und Entwicklungsaufgaben bereitstellen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[iii Engine]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Memory Lifecycle]]
|
||||
- [[Knowledge Graph]]
|
||||
- [[Event-Driven Automation]]
|
||||
- [[Rohit Gupta]]
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [arch-linux, aur, package-manager, helper]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Arch Linux, AUR, makepkg, GPG]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: In Rust geschriebener AUR-Helper mit sicherer Paketverwaltung und eigenem Build-Verzeichnis für Arch Linux.
|
||||
---
|
||||
# Aura
|
||||
|
||||
**Typ:** Tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Aura ist ein sicherer, mehrsprachiger Paketmanager für Arch Linux und das AUR. Es ist ein in Rust geschriebener AUR-Helper, der sichere Standardwerte bietet und sich in den Arch User Repository Workflow integriert.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** AUR-Helper und Paketmanager
|
||||
- **Status:** Aktiv
|
||||
- **Sprache:** Rust
|
||||
- **Repository:** https://github.com/fosskers/aura
|
||||
- **Lizenz:** GPL-3.0
|
||||
|
||||
## Features
|
||||
|
||||
- **Sichere Standardwerte:** Konzipiert zur Vermeidung häufiger Fehler
|
||||
- **Mehrsprachig:** Unterstützt mehrere Sprachen
|
||||
- **Build-Verzeichnis-Anpassung:** Unterstützt benutzerdefinierte Build-Verzeichnisse über die `BUILDDIR`-Umgebungsvariable
|
||||
- **GPG-Integration:** Funktioniert mit Benutzer-GPG-Keyring zur AUR-Paketsignierung
|
||||
- **Abhängigkeitsauflösung:** Automatische Abhängigkeitsbehandlung
|
||||
|
||||
## Verwendung
|
||||
|
||||
### Grundlegende Befehle
|
||||
|
||||
```bash
|
||||
# Install a package from AUR
|
||||
aura -A <package-name>
|
||||
|
||||
# Sync and upgrade all packages
|
||||
aura -Syu
|
||||
|
||||
# Build in custom directory
|
||||
export BUILDDIR=/var/cache/makepkg-local
|
||||
sudo --preserve-env=BUILDDIR aura -Axac <package> --build $BUILDDIR
|
||||
```
|
||||
|
||||
### Build-Verzeichnis-Konfiguration
|
||||
|
||||
Für Systeme mit begrenztem Platz in `/tmp` oder `/home` wird ein benutzerdefiniertes Build-Verzeichnis konfiguriert:
|
||||
|
||||
```bash
|
||||
export BUILDDIR=/var/cache/makepkg-local
|
||||
sudo --preserve-env=BUILDDIR aura -Axac proton --build $BUILDDIR
|
||||
```
|
||||
|
||||
Dies erstellt Pakete in `/var/cache/makepkg-local` statt am Standardort.
|
||||
|
||||
## GPG-Schlüsselverwaltung
|
||||
|
||||
**Wichtig:** AUR GPG-Schlüssel müssen in den **Benutzer-** GPG-Keyring importiert werden, nicht in den des Administrators:
|
||||
|
||||
```bash
|
||||
# Import a GPG key
|
||||
gpg --recv-key B94556F81C85D0D5
|
||||
```
|
||||
|
||||
Dies ist eine kritische Anforderung bei der Verwendung von Aura mit signierten AUR-Paketen.
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet durch:** Paketbetreuer für AUR-Pakete
|
||||
- **Funktioniert mit:** [[AUR]] (Arch User Repository)
|
||||
- **Hängt ab von:** [[makepkg]] zum Packetbau
|
||||
- **Nutzt:** [[GPG]] zur Paketsignaturüberprüfung
|
||||
- **Läuft auf:** [[Arch Linux]]
|
||||
|
||||
## Neuinstallation von Python-Paketen
|
||||
|
||||
Nach einem Python-Versionsupdate werden alle AUR Python-Pakete neu installiert:
|
||||
|
||||
```bash
|
||||
aura -A $(pacman -Qqm | xargs -I {} pacman -Ql {} | grep "/usr/lib/python3.12/site-packages" | cut -d'/' -f1)
|
||||
```
|
||||
|
||||
Dieser Befehl identifiziert alle AUR-Pakete mit Dateien im Python 3.12 site-packages-Verzeichnis und installiert sie neu.
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[AUR]] - Arch User Repository
|
||||
- [[makepkg]] - Arch Linux Build-Tool
|
||||
- [[GPG]] - GNU Privacy Guard
|
||||
- [[Arch Linux]] - Betriebssystem
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://github.com/fosskers/aura
|
||||
- https://wiki.archlinux.org/title/AUR_helpers
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [wine, compatibility, windows, gaming, containerization]
|
||||
created: 2026-08-01
|
||||
modified: 2026-08-29
|
||||
related: [Wine, Proton, Wine-Staging, Wine GE, Lutris, Arch Linux]
|
||||
sources: [Source - Wine]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Grafisches Werkzeug zur Verwaltung von Wine-Präfixen und zum Ausführen von Windows-Anwendungen unter Linux mit mehreren Runtimes.
|
||||
---
|
||||
# Bottles
|
||||
|
||||
**Typ:** Tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Bottles ist ein benutzerfreundliches grafisches Hilfsprogramm zur Verwaltung von Wine-Präfixen und zum Ausführen von Windows-Anwendungen unter Linux. Es bietet sandboxed Umgebungen ("Bottles"), die Windows-Anwendungen vom Host-System isolieren, mit einfacher Installation und Verwaltung verschiedener Wine-Runtimes.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Verwaltung von Wine-Präfixen und Windows-Anwendungen unter Linux
|
||||
- **Status:** Aktiv, Open-Source
|
||||
- **Lizenz:** GPL-3.0
|
||||
- **Plattform:** Linux (Flatpak, AppImage, native Pakete)
|
||||
- **Website:** https://usebottles.com/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Nutzt:** [[Wine]], [[Proton]], [[Wine-Staging]], [[Wine GE]]
|
||||
- **Verwandt mit:** [[Lutris]], [[Arch Linux]]
|
||||
- **Bietet:** Mehrere Runtime-Optionen für verschiedene Anwendungsfälle
|
||||
|
||||
## Details
|
||||
|
||||
### Verfügbare Runtimes
|
||||
|
||||
Bottles bietet sieben unterschiedliche Runtime-Umgebungen, die jeweils verschiedene Wine-Varianten und Patch-Sets haben:
|
||||
|
||||
| Runtime | Basis | Patches | Integrationen |
|
||||
|---------|------|---------|---------------|
|
||||
| **Soda** | Wine Valve | +[[Wine-Staging]] | +[[Proton]] |
|
||||
| **Caffe** | [[Wine]] Upstream | +[[Wine-Staging]] | +[[Proton]] |
|
||||
| **GE Wine** | [[Wine GE]] | - | - |
|
||||
| **Lutris** | Lutris [[Wine]] | - | - |
|
||||
| **Lutris-Ge-Lol** | Lutris GE | - | - |
|
||||
| **Vaniglia** | [[Wine]] Upstream | +[[Wine-Staging]] | - |
|
||||
| **GE Proton** | Wine Valve | +[[Wine-Staging]] | +[[Proton]], +Steam |
|
||||
|
||||
### Runtime-Auswahl
|
||||
|
||||
- **Soda:** Valves Wine-Build optimiert für Steam/Proton-Kompatibilität
|
||||
- **Caffe:** Upstream Wine mit Staging-Patches und Proton-Integration
|
||||
- **GE Wine:** GloriousEggroll's Builds mit zusätzlichen Gaming-fokussierten Patches
|
||||
- **Lutris:** Lutris-spezifische Wine-Builds
|
||||
- **Lutris-Ge-Lol:** League of Legends optimierter Lutris GE Build
|
||||
- **Vaniglia:** Vanilla Upstream Wine mit Staging-Patches
|
||||
- **GE Proton:** Valves Wine mit vollständiger Proton- und Steam-Integration
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Wine]]
|
||||
- [[Proton]]
|
||||
- [[Wine-Staging]]
|
||||
- [[Wine GE]]
|
||||
- [[Lutris]]
|
||||
- [[Arch Linux]]
|
||||
- [[Source - Wine]]
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [openai, ai, chatbot, rag]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [NotebookLM, RAG, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: KI-Chatbot von OpenAI mit Datei-Upload für RAG-artige Dokumentabfragen, ohne dauerhafte Wissensanhäufung oder Querverweis-Synthese.
|
||||
---
|
||||
# ChatGPT
|
||||
|
||||
**Typ:** Tool (KI-Chatbot von OpenAI)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
ChatGPT ist OpenAIs KI-Chatbot, der Fragen beantworten, Inhalte generieren und mit Datei-Uploads RAG-artige Abfragen zu hochgeladenen Dokumenten durchführen kann. Wie NotebookLM stellt es den traditionellen Ansatz dar, den das [[LLM Wiki Pattern]] verbessert.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Webanwendung / KI-Assistent
|
||||
- **Entwickler:** OpenAI
|
||||
- **Ansatz:** RAG (mit Datei-Uploads)
|
||||
- **Status:** Aktiv
|
||||
- **Website:** https://chat.openai.com/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Nutzt Ansatz:** [[RAG]] (mit Datei-Uploads)
|
||||
- **Verglichen mit:** [[LLM Wiki Pattern]]
|
||||
- **Ähnlich wie:** [[NotebookLM]]
|
||||
|
||||
## Features
|
||||
|
||||
### Datei-Upload / RAG-Modus
|
||||
- Dokumente für Kontext hochladen
|
||||
- Fragen zum hochgeladenen Inhalt stellen
|
||||
- System ruft relevante Chunks ab und generiert Antworten
|
||||
- Keine persistente Wissensammlung
|
||||
|
||||
### Allgemeine Funktionen
|
||||
- Natürlichsprachverarbeitung und -generierung
|
||||
- Code-Generierung und Analyse
|
||||
- Mehrschrittige Konversationen
|
||||
- Plugin-/Erweiterungs-Ökosystem
|
||||
|
||||
### Einschränkungen beim Wissensmanagement
|
||||
|
||||
Nach dem [[LLM Wiki Pattern]] gelten für ChatGPT Datei-Uploads:
|
||||
- Wissen wird bei jeder Abfrage von Grund auf neu entdeckt
|
||||
- Keine Sammlung von synthetisiertem Wissen
|
||||
- Keine persistenten Querverweise
|
||||
- Kein Compounding-Effekt aus mehreren Dokumenten
|
||||
- Keine Kennzeichnung von Widersprüchen zwischen Quellen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite erstellt während der Aufnahme des LLM Wiki Pattern Artikels
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[RAG]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[NotebookLM]]
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [anthropic, ai, coding, agent]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-31
|
||||
related: [OpenAI Codex, OpenCode, Pi, LLM Wiki Pattern, Claude Code Auto Mode, Diff-Reviewable Agent Edits]
|
||||
sources: [Source - LLM Wiki Pattern, Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: KI-Coding-Assistent von Anthropic; liest ganze Codebasen, erzeugt Code und ändert Dateien, konfiguriert über CLAUDE.md; liest Agent Skills ausschließlich aus .claude/skills/; steuert Freigaben über sechs --permission-mode-Werte.
|
||||
---
|
||||
# Claude Code
|
||||
|
||||
**Typ:** Tool (KI-Coding-Assistent von Anthropic)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Claude Code ist Anthropics KI-Coding-Assistent, entwickelt um Entwicklern bei Programmieraufgaben zu helfen. Es kann Dateien lesen, Codebases verstehen und Edits machen. Es ist einer der in [[LLM Wiki Pattern]] erwähnten LLM-Agenten als Ziel.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** KI-Assistent / Agent
|
||||
- **Entwickler:** Anthropic
|
||||
- **Hauptverwendung:** Code-Generierung und Analyse
|
||||
- **Konfiguration:** CLAUDE.md Datei für projektspezifische Anweisungen
|
||||
- **Status:** Aktiv
|
||||
- **Website:** https://www.anthropic.com/products/claude-code
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[LLM Wiki Pattern]] (als Ziel-LLM-Agent)
|
||||
- **Ähnlich wie:** [[OpenAI Codex]], [[OpenCode]], [[Pi]]
|
||||
- **Konfigurationsdatei:** CLAUDE.md (analog zu AGENTS.md in diesem Wiki)
|
||||
- **implementiert:** [[Claude Code Auto Mode]]
|
||||
- **verwendet:** [[Diff-Reviewable Agent Edits]]
|
||||
|
||||
## Features
|
||||
|
||||
- Komplette Codebases lesen und verstehen
|
||||
- Code basierend auf natürlichsprachlichen Eingaben generieren
|
||||
- Edits über mehrere Dateien hinweg machen
|
||||
- Code-Verhalten erklären
|
||||
- Fehler debuggen und beheben
|
||||
|
||||
## Verwendung im LLM Wiki Pattern
|
||||
|
||||
Claude Code wird als einer der LLM-Agenten erwähnt, die das LLM Wiki Pattern implementieren können:
|
||||
- Nutzt CLAUDE.md Datei (ähnlich wie AGENTS.md dieses Wikis)
|
||||
- Kann Quelldateien lesen, Zusammenfassungen generieren, Querverweise beibehalten
|
||||
- Mensch und LLM entwickeln das Schema-Dokument im Laufe der Zeit gemeinsam weiter
|
||||
|
||||
## Konfiguration
|
||||
|
||||
Die CLAUDE.md Datei dient einem ähnlichen Zweck wie AGENTS.md dieses Wikis:
|
||||
- Definiert, wie der LLM operieren soll
|
||||
- Gibt die Verzeichnisstruktur an
|
||||
- Definiert Konventionen und Seitenformate
|
||||
- Dokumentiert Workflows zum Ingesten, Abfragen und Warten des Wikis
|
||||
|
||||
## Agent Skills
|
||||
|
||||
Claude Code unterstützt `SKILL.md`-basierte Agent Skills, aber nur unter `.claude/skills/<name>/SKILL.md`
|
||||
(Projekt-Bereich) oder `~/.claude/skills/<name>/SKILL.md` (persönlicher Bereich) - bestätigt direkt aus
|
||||
Claude Codes offizieller Dokumentation (`code.claude.com/docs/en/skills`). Es liest **nicht** nativ
|
||||
`.agents/skills/`, anders als Codex CLI, Mistral Vibe und GitHub Copilot; ein Projekt, das
|
||||
Claude Code mit denselben Skills wie diese anderen Tools sehen will, benötigt einen generierten Mirror kopiert
|
||||
in `.claude/skills/`[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Berechtigungsmodi
|
||||
|
||||
Claude Code führt die Freigabe von Aktionen über Berechtigungsmodi. Auf Version 2.1.251 nennt
|
||||
`claude --help` sechs Werte für `--permission-mode`: `auto`, `acceptEdits`, `bypassPermissions`,
|
||||
`manual`, `dontAsk` und `plan`[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
Der Modus wird mit `Shift+Tab` in der laufenden Sitzung gewechselt, beim Start über
|
||||
`--permission-mode`, oder dauerhaft über `permissions.defaultMode` in `~/.claude/settings.json`
|
||||
beziehungsweise Managed Settings; ein `/auto`-Slash-Command existiert
|
||||
nicht[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]. Der Standardmodus dieser
|
||||
Instanz und seine Eigenheiten stehen auf [[Claude Code Auto Mode]].
|
||||
|
||||
Das Bash-Werkzeug der Sitzung führt einen `dangerouslyDisableSandbox`-Parameter, läuft also
|
||||
standardmäßig in einer Sandbox[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite erstellt während der Aufnahme des LLM Wiki Pattern Artikels
|
||||
- [2026-08-31] - Berechtigungsmodi ergänzt aus der Sitzung zum `auto`-Modus
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[OpenAI Codex]]
|
||||
- [[OpenCode]]
|
||||
- [[Pi]]
|
||||
- AGENTS.md
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[Claude Code Auto Mode]]
|
||||
- [[Diff-Reviewable Agent Edits]]
|
||||
- [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]: [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [ai, coding, agent]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Kommandozeilenschnittstelle für das Coding-Modell Codex
|
||||
---
|
||||
# Codex CLI
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Codex CLI ist die Befehlszeilenschnittstelle für das Codex-AI-Kodierungsmodell und eines der Zielwerkzeuge für die Cross-Platform-Agent-Skills-Architektur, die in der Anleitung zum Umstrukturieren von Copilot-Skills beschrieben wird[^s-copilot-skill-restructure-instructions]. Sie ermöglicht es Entwicklern, Codex-AI-Funktionen direkt über das Terminal für Code-Generierung, Analyse und andere Kodierungsaufgaben aufzurufen.
|
||||
|
||||
Codex CLI wird als eine der vier Zielplattformen erwähnt (neben GitHub Copilot, Claude Code und Mistral Vibe), die die eigenständigen Wiki-Skills aufrufen können, die aus der monolithischen Datei AGENTS.md extrahiert werden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Befehlszeilenschnittstelle für das Codex-AI-Kodierungsmodell
|
||||
- **Status:** Aktiv (erwähnt als Zielplattform)
|
||||
- **Sprache/Technik:** CLI-Tool
|
||||
- **Besitzer:** OpenAI (hergeleitet aus Codex-Branding)
|
||||
- **Repository:** In den Quellen nicht angegeben
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[wikitool]] (über Skill-Aufrufe)
|
||||
- **Ähnlich wie:** [[GitHub Copilot]], [[Claude Code]], [[Mistral Vibe]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Codex CLI ist Teil der Cross-Platform-Zielstrategie für die Umstrukturierung der LLM-Wiki-Skills.
|
||||
|
||||
~~Der Ansatz mit dem gemeinsamen `.agents/skills/`-Verzeichnis ermöglicht es Codex CLI, Skills über Symlinks im nativen Skill-Pfad (~/.codex/skills/) aufzulösen.~~ **Korrigiert:** Gemäß OpenAIs eigener Dokumentation (`learn.chatgpt.com/docs/build-skills`, "Where Codex loads local skills") scannt Codex CLI nativ `.agents/skills` vom aktuellen Arbeitsverzeichnis bis zur Repository-Root sowie `$HOME/.agents/skills` für benutzergesteuerte Skills - **kein Symlink ist erforderlich**. Codex unterstützt auch symlink-Skill-Ordner und folgt dem Symlink-Ziel beim Scannen dieser Speicherorte, aber das ist eine Option, keine Anforderung, für den Fall des Basis-`.agents/skills/`[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Die Aussage zur Skill-Speicherort wurde von `~/.codex/skills/` (Symlink erforderlich) auf das überprüfte `.agents/skills/` (nativ, kein Symlink) korrigiert, gemäß OpenAis offizielle Dokumentation[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-04 - Seite während der Erfassung der Anleitung zum Umstrukturieren von Copilot-Skills erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[GitHub Copilot]]
|
||||
- [[Claude Code]]
|
||||
- [[Mistral Vibe]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [obsidian, plugin, query, frontmatter]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Obsidian, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Obsidian-Plugin für Abfragen über das Frontmatter von Seiten; erzeugt dynamische Tabellen, Listen und strukturierte Sichten auf Wiki-Inhalte.
|
||||
---
|
||||
# Dataview
|
||||
|
||||
**Typ:** Tool (Obsidian Plugin for Querying Frontmatter)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Dataview ist ein Obsidian-Plugin, das es Benutzern ermöglicht, Abfragen über Seiten-Frontmatter und Inhalte auszuführen, um dynamische Tabellen, Listen und andere strukturierte Ausgaben zu generieren. Es ist besonders nützlich für die Erstellung automatisierter Indizes, das Verfolgen von Metadaten und die Erstellung benutzerdefinierter Ansichten von Wiki-Inhalten.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Obsidian-Plugin
|
||||
- **Zweck:** Seiten-Metadaten abfragen und aggregieren
|
||||
- **Abfragesprache:** Dataview Query Language (DQL)
|
||||
- **Datenquelle:** YAML-Frontmatter und Inline-Felder
|
||||
- **Website:** https://blacksmithgu.github.io/obsidian-dataview/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Plugin für:** [[Obsidian]]
|
||||
- **Verwendet von:** [[LLM Wiki Pattern]] (für dynamische Tabellen und Listen)
|
||||
- **Abfragt:** Seiten-Frontmatter (Tags, Daten, Quellanzählungen usw.)
|
||||
|
||||
## Funktionen
|
||||
|
||||
### Abfragefunktionen
|
||||
- Seiten nach Frontmatter-Feldern filtern
|
||||
- Ergebnisse sortieren und gruppieren
|
||||
- Daten aggregieren (Anzahl, Summe, Durchschnitt)
|
||||
- Dynamische Tabellen erstellen
|
||||
- Listen aus Abfragen generieren
|
||||
- Inline-Abfragen innerhalb von Notizen
|
||||
|
||||
### Häufige Anwendungsfälle
|
||||
- Dynamische Indizes von Seiten erstellen
|
||||
- Statistiken über das Wiki hinweg verfolgen
|
||||
- Benutzerdefinierte Dashboards erstellen
|
||||
- Listen automatisch basierend auf Kriterien aktualisieren
|
||||
|
||||
## Beispiele für Abfragen
|
||||
|
||||
```dataview
|
||||
-- List all pages with tag #technology
|
||||
LIST FROM #technology
|
||||
|
||||
-- Table of all entity pages with modification dates
|
||||
TABLE modified, entity_type
|
||||
FROM "entities"
|
||||
WHERE type = "entity"
|
||||
SORT modified DESC
|
||||
|
||||
-- Count pages by type
|
||||
TABLE type, COUNT(rows) AS Count
|
||||
FROM ""
|
||||
GROUP BY type
|
||||
```
|
||||
|
||||
## Anwendungsfälle im LLM-Wiki-Muster
|
||||
|
||||
Gemäß [[LLM Wiki Pattern]] ist Dataview nützlich, wenn:
|
||||
- Das LLM YAML-Frontmatter zu Wiki-Seiten hinzufügt (Tags, Daten, Quellanzählungen)
|
||||
- Dynamische Tabellen und Listen erforderlich sind, die sich automatisch aktualisieren
|
||||
- Benutzerdefinierte Ansichten der Wissensdatenbank erstellt werden sollen
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wiki hat strukturiertes Frontmatter
|
||||
- Automatisierte, aktuelle Listen erforderlich
|
||||
- Metadaten über Seiten hinweg verfolgt werden sollen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Erfassung des LLM-Wiki-Muster-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Obsidian]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [encryption, security, signing, verification]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [AUR, Aura, makepkg, Arch Linux]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: GNU Privacy Guard zum Verschlüsseln und Signieren; unverzichtbar für die Prüfung von AUR-Paketen und kryptografische Operationen unter Arch Linux.
|
||||
---
|
||||
# GPG
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
GNU Privacy Guard (GPG) ist eine freie Implementierung des OpenPGP-Standards zur Verschlüsselung und Signierung von Daten. Sie bietet kryptografische Vertraulichkeit und Authentifizierung für Datenkommunikation.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Vollständiger Name:** GNU Privacy Guard
|
||||
- **Zweck:** Verschlüsselung, digitale Signaturen, Schlüsselverwaltung
|
||||
- **Status:** Aktiv
|
||||
- **Protokoll:** OpenPGP (RFC 4880)
|
||||
- **Website:** https://gnupg.org
|
||||
- **Paket:** `gnupg` in den meisten Linux-Distributionen
|
||||
|
||||
## Verwendung in Arch Linux AUR
|
||||
|
||||
**Kritischer Hinweis:** Bei der AUR-Paketverwaltung müssen GPG-Schlüssel in den Schlüsselbund des **Benutzers** importiert werden, **nicht** in den Root-Schlüsselbund. Dies ist eine häufige Fehlerquelle.
|
||||
|
||||
### AUR-GPG-Schlüssel importieren
|
||||
|
||||
```bash
|
||||
# Import a specific key
|
||||
gpg --recv-key B94556F81C85D0D5
|
||||
|
||||
# Import from keyserver
|
||||
gpg --keyserver hkps://keys.openpgp.org --recv-key KEY_ID
|
||||
|
||||
# List keys
|
||||
gpg --list-keys
|
||||
|
||||
# List secret keys
|
||||
gpg --list-secret-keys
|
||||
```
|
||||
|
||||
### Paketsignaturen verifizieren
|
||||
|
||||
```bash
|
||||
# Verify a package signature
|
||||
gpg --verify package.pkg.tar.zst.sig package.pkg.tar.zst
|
||||
```
|
||||
|
||||
### Pakete mit makepkg signieren
|
||||
|
||||
Bei der Verwendung von `makepkg` mit GPG-Signierung:
|
||||
|
||||
```bash
|
||||
# Enable signing in makepkg.conf
|
||||
# GPGKEY="your-key-id"
|
||||
|
||||
# Sign a built package
|
||||
makepkg --sign
|
||||
```
|
||||
|
||||
## Schlüsselverwaltung
|
||||
|
||||
### Öffentlichen Schlüssel exportieren
|
||||
|
||||
```bash
|
||||
# Export to file
|
||||
gpg --export --armor KEY_ID > public.key
|
||||
|
||||
# Export to keyserver
|
||||
gpg --keyserver hkps://keys.openpgp.org --send-keys KEY_ID
|
||||
```
|
||||
|
||||
### Öffentlichen Schlüssel importieren
|
||||
|
||||
```bash
|
||||
# From file
|
||||
gpg --import public.key
|
||||
|
||||
# From keyserver
|
||||
gpg --recv-key KEY_ID
|
||||
```
|
||||
|
||||
### Schlüssel widerrufen
|
||||
|
||||
```bash
|
||||
# Generate revocation certificate (do this when creating key)
|
||||
gpg --gen-revoke KEY_ID > revoke.asc
|
||||
|
||||
# Publish revocation
|
||||
gpg --keyserver hkps://keys.openpgp.org --send-keys KEY_ID
|
||||
```
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[AUR]]-Paketmitverantwortlichen zum Signieren
|
||||
- **Integriert mit:** [[Aura]]-AUR-Helfer
|
||||
- **Verwendet mit:** [[makepkg]] für das Paketsignieren
|
||||
- **Läuft auf:** [[Arch Linux]] und anderen Distributionen
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Benutzer vs. Root:** AUR-Schlüssel immer in den Schlüsselbund des Benutzers importieren, nicht in Root
|
||||
2. **Schlüsselsicherung:** Privaten Schlüssel und das Widerrufszertifikat sichern
|
||||
3. **Schlüsselablauf:** Angemessene Ablaufdaten für Schlüssel festlegen
|
||||
4. **Schlüsselrotation:** Schlüssel regelmäßig rotieren
|
||||
5. **Schlüssel verifizieren:** Schlüssel-Fingerprints immer vor dem Vertrauen verifizieren
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[AUR]] - Arch User Repository
|
||||
- [[Aura]] - AUR-Helfertool
|
||||
- [[makepkg]] - Arch-Linux-Buildtool
|
||||
- [[Arch Linux]]
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://wiki.archlinux.org/title/GnuPG
|
||||
- https://gnupg.org
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [ai, coding, agent, vscode]
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [OpenAI Codex]
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: mixed
|
||||
summary: KI-gestützte Code-Vervollständigung auf Basis der OpenAI-Modelle, in Entwickler-Editoren integriert; unterstützt in VS Code die native Erkennung von Agent Skills (SKILL.md).
|
||||
---
|
||||
# GitHub Copilot
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
GitHub Copilot ist ein KI-gestütztes Code-Completion-Tool, das sich in Code-Editoren integriert und kontextbezogene Code-Vorschläge unter Verwendung großer Sprachmodelle wie OpenAI Codex bereitstellt, die auf öffentlich verfügbarem Code trainiert wurden.
|
||||
|
||||
## Allgemeine Hinweise (unbelegt)
|
||||
|
||||
Die allgemeinen Chat- und Completion-Funktionen von GitHub Copilot sind verbreitetes Hintergrundwissen, nicht durch eine Rohdatei in diesem Wiki belegt.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** KI-Pair-Programming-Assistent: Code-Completion, Chat und agentengesteuerte Coding-Aufgaben in VS Code und anderen Editoren
|
||||
- **Status:** Aktiv
|
||||
- **Sprache/Technik:** Integriert OpenAI-Modelle; VS Code-Erweiterung
|
||||
- **Verantwortlich:** GitHub / Microsoft
|
||||
- **Repository:** https://github.com/microsoft/vscode-copilot-chat
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **verwandt mit:** [[OpenAI Codex]], [[Codex CLI]], [[Claude Code]], [[Mistral Vibe]]
|
||||
|
||||
## Details
|
||||
|
||||
GitHub Copilot (in VS Code) entdeckt Agent Skills (`SKILL.md`) nativ auf Projektebene aus `.github/skills/<name>/`, `.agents/skills/<name>/` oder `.claude/skills/<name>/` und auf persönlicher Ebene aus `~/.copilot/skills/`, `~/.agents/skills/` oder `~/.claude/skills/` - gemäß VS Codes eigener gebündelter Skill-Dokumentation. Die Erkennung ist progressiv: Nur der `name` und die `description` (~100 Tokens) jedes Skills bleiben resident; der vollständige `SKILL.md`-Body (<5000 Tokens) wird nur geladen, wenn die Beschreibung zur aktuellen Aufgabe passt[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
Ob diese genaue installierte Version zusätzlich einen `.vscode/settings.json`-Eintrag `chat.agentSkillsLocations` für `.agents/skills/` speziell erfordert, wurde während der AGENTS.md-Skill-Umstrukturierung als ungeklärt gekennzeichnet - die gebündelte Dokumentation deutet darauf hin, dass keine zusätzliche Konfiguration erforderlich ist, wurde aber nicht schlüssig empirisch innerhalb einer Sitzung bestätigt[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - TODO-Platzhalter mit beschafften Fakten zur nativen Agent-Skills-Erkennung gefüllt, bestätigt aus der VS-Code-Dokumentation.
|
||||
- 2026-08-02 - Seite über wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Claude Code]]
|
||||
- [[Codex CLI]]
|
||||
- [[Mistral Vibe]]
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [gitea, mcp, ci-cd, diagnostics]
|
||||
created: 2026-08-30
|
||||
modified: 2026-08-31
|
||||
related: [Gitea Actions, Issue Label Scheme]
|
||||
sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: MCP-Server fuer die Gitea-API; liest Actions-Laeufe, Logs, Releases und Issues, ist bei privatem Repository der einzige belastbare Blick auf den CI-Zustand und traegt seit 2026-08-31 auch die Board-Triage
|
||||
---
|
||||
# Gitea MCP Server
|
||||
|
||||
**Typ:** Tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Der Gitea MCP Server stellt die Gitea-API als MCP-Werkzeuge bereit und erlaubt einem Agenten
|
||||
damit den lesenden und schreibenden Zugriff auf Repositories, Actions-Läufe samt Logs, Releases,
|
||||
Tags, Issues und Pull Requests. Er wurde in der Sitzung vom 2026-08-30 verfügbar gemacht,
|
||||
nachdem die Fehlersuche an der CI-Pipeline von außen an eine Wand gelaufen
|
||||
war[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
Seine praktische Bedeutung in dieser Installation ergibt sich aus einer Eigenschaft des
|
||||
Origin-Repositories: Es ist privat, und [[Gitea]] antwortet einem anonymen Aufrufer mit einem
|
||||
identischen `404` für ein unsichtbares und für ein nicht existierendes
|
||||
Repository[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Ein
|
||||
`curl` gegen die API beweist deshalb nichts, und aus einem `404` lässt sich kein Rückschluss auf
|
||||
den CI-Zustand ziehen. Der MCP-Server ist der Weg, auf dem Läufe tatsächlich gelesen werden.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Gitea-API als MCP-Werkzeuge; Diagnose von Actions-Läufen, Verwaltung von Issues und
|
||||
Releases
|
||||
- **Status:** Aktiv, in Gebrauch seit 2026-08-30
|
||||
- **Angebunden an:** die [[Gitea]]-Instanz, die die Repositories und [[Gitea Actions]] betreibt
|
||||
- **Zugriffsart:** authentifiziert - anders als ein anonymer HTTP-Aufruf sieht er private
|
||||
Repositories
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet:** [[Gitea]]-API
|
||||
- **Liest:** Läufe und Logs von [[Gitea Actions]], ausgeführt vom [[Act Runner]]
|
||||
- **Verwendet von:** [[Chemenu]] zur Diagnose der eigenen Pipeline
|
||||
- **setzt um:** [[Issue Label Scheme]]
|
||||
|
||||
## Details
|
||||
|
||||
### Verwendung in der Fehlersuche
|
||||
|
||||
Die erste Diagnose über den Server war schreibgeschützt und drehte die stehende Annahme um:
|
||||
`list_runs` lieferte sechs Läufe, die Läufe 46-51 alle mit `conclusion: failure`, und die Logs
|
||||
nannten den Grund konkret[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
```
|
||||
OCI runtime exec failed: exec: "node": executable file not found in $PATH
|
||||
❌ Failure - Main actions/checkout@v4
|
||||
exitcode '127': command not found
|
||||
```
|
||||
|
||||
Die Runner hatten die Workflows also die ganze Zeit angenommen. Der Befund „die Runner laufen
|
||||
nicht" war von außen nicht überprüfbar gewesen und falsch. Details zur Ursache auf der Seite
|
||||
[[Act Runner]].
|
||||
|
||||
### Anwendungsfälle in dieser Installation
|
||||
|
||||
- Actions-Läufe auflisten, ihren Ausgang und ihre Logs lesen
|
||||
- Releases prüfen, die `release.yml` erzeugt hat, samt hochgeladener Assets
|
||||
- Issues anlegen und pflegen - die offenen Ausbaustufen der CI/CD-Arbeit liegen als Gitea-Issues
|
||||
statt als Prosa in `TODO.md`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
Seit der Löschung von `TODO.md` am 2026-08-31 ist das Board die einzige Ablage offener
|
||||
Arbeit[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]
|
||||
- Ein ganzes Board triagieren: Beim Priorisierungslauf vom 2026-08-31 wurden elf Issue-Texte
|
||||
über den Server gelesen statt aus den Titeln erschlossen, danach sieben Labels angelegt und
|
||||
auf alle zehn offenen Issues angewandt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]
|
||||
- `list_runs` als Beweismittel: Die Beobachtung, dass zu Commit `f916376` kein Lauf existiert,
|
||||
schloss Gitea-Issue #11, ohne dass eine Zeile Code geschrieben wurde[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-08-31] - Trägerwerkzeug der ersten Board-Triage: elf Issue-Texte gelesen, sieben Labels
|
||||
nach dem [[Issue Label Scheme]] angelegt und angewandt, #11 geschlossen, #14 und #15
|
||||
eröffnet[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]
|
||||
- [2026-08-30] - Verfügbar gemacht und erstmals eingesetzt; die Diagnose der bis dahin
|
||||
unerklärten CI-Fehlschläge lief vollständig über ihn
|
||||
- [2026-08-30] - Seite beim Ingest des Sitzungstranskripts erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Gitea]]
|
||||
- [[Gitea Actions]]
|
||||
- [[Act Runner]]
|
||||
- [[Chemenu]]
|
||||
- [[Issue Label Scheme]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
|
||||
[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [gaming, wine, launcher, windows, compatibility]
|
||||
created: 2026-08-01
|
||||
modified: 2026-08-29
|
||||
related: [Wine, Bottles, Proton, Wine-Staging, Wine GE, Steam]
|
||||
sources: [Source - Wine]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Quelloffene Spieleplattform für Linux mit einheitlicher Oberfläche für Installation und Start von Spielen über die Wine-Kompatibilitätsschicht.
|
||||
---
|
||||
# Lutris
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Lutris ist eine quelloffene Spiele-Plattform für Linux, die eine einheitliche Benutzeroberfläche für die Installation, Konfiguration und das Starten von Spielen aus verschiedenen Quellen bereitstellt, darunter Steam, GOG, Origin und native Linux-Spiele. Sie nutzt [[Wine]] als Kompatibilitätsebene für die Ausführung von Windows-Spielen und bietet eigene Wine-Builds, die für Spiele optimiert sind.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Spieleverwaltung und Windows-Spiele-Kompatibilität unter Linux
|
||||
- **Status:** Aktiv, quelloffen
|
||||
- **Lizenz:** GPL-2.0
|
||||
- **Plattform:** Linux
|
||||
- **Website:** https://lutris.net/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet:** [[Wine]], [[Wine-Staging]], [[Proton]]
|
||||
- **Verwandt mit:** [[Bottles]], [[Steam]], [[Wine GE]]
|
||||
- **Bietet:** Custom Wine-Builds (Lutris Wine, Lutris GE)
|
||||
- **Integriert in:** [[Bottles]] (Lutris und Lutris-Ge-Lol Runtimes)
|
||||
|
||||
## Details
|
||||
|
||||
### Wine-Builds
|
||||
|
||||
Lutris bietet mehrere Wine-Builds:
|
||||
- **Lutris Wine:** Standard-Wine-Build mit Lutris-Patches
|
||||
- **Lutris GE:** Spielverstärkter Wine-Build mit zusätzlichen Patches
|
||||
- **Lutris-Ge-Lol:** League-of-Legends-optimierter Build
|
||||
|
||||
### Bottles-Integration
|
||||
|
||||
Lutris-Wine-Builds sind als Runtimes in [[Bottles]] verfügbar:
|
||||
|
||||
- **[[Lutris]]:** Verwendet Lutris Wine
|
||||
- **Lutris-Ge-Lol:** Verwendet Lutris-GE-Build, optimiert für League of Legends
|
||||
|
||||
### Features
|
||||
|
||||
- Einheitliche Spielebibliotheks-Verwaltung
|
||||
- Automatisierte Spielinstallation über Installer/Skripte
|
||||
- Controller-Konfiguration
|
||||
- Leistungsüberwachung
|
||||
- Von der Gemeinschaft betriebene Spielekonfigurationen
|
||||
- Unterstützung mehrerer Kompatibilitätsebenen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Wine]]
|
||||
- [[Bottles]]
|
||||
- [[Proton]]
|
||||
- [[Wine-Staging]]
|
||||
- [[Wine GE]]
|
||||
- [[Steam]]
|
||||
- [[Source - Wine]]
|
||||
|
||||
@@ -0,0 +1,93 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [presentation, slides, markdown, marp]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Obsidian, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Markdown-basiertes Format für Foliensätze; erzeugt Präsentationen direkt aus Markdown, mit Themes und PDF-Export.
|
||||
---
|
||||
# Marp
|
||||
|
||||
**Typ:** Tool (Markdown-basiertes Foliendeck-Format)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Marp (Markdown Presentation Ecosystem) ist ein Markdown-basiertes Foliendeck-Format, das Benutzern ermöglicht, Präsentationen direkt aus Markdown-Inhalten zu erstellen. Es verwendet spezielle Markdown-Syntax zur Definition von Folien und kann über ein Plugin mit Obsidian verwendet werden.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Format/Tool
|
||||
- **Format:** Markdown mit Erweiterungen
|
||||
- **Ausgabe:** Folienpräsentationen (HTML, PDF, PPTX)
|
||||
- **Website:** https://marp.app/
|
||||
- **Obsidian-Plugin:** Verfügbar
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[LLM Wiki Pattern]] (zum Generieren von Präsentationen aus Wiki-Inhalten)
|
||||
- **Integriert mit:** [[Obsidian]] (über Plugin)
|
||||
- **Erstellt aus:** Wiki-Inhalten
|
||||
|
||||
## Features
|
||||
|
||||
### Markdown-Erweiterungen
|
||||
- Folientrenner (`---` oder `---?---`)
|
||||
- Sprechernotizen
|
||||
- Themen und Styling
|
||||
- Diagramme und Grafiken
|
||||
- Mathematische Ausdrücke
|
||||
- Benutzerdefiniertes CSS
|
||||
|
||||
### Ausgabeformate
|
||||
- HTML-Folien
|
||||
- PDF
|
||||
- PowerPoint (PPTX)
|
||||
|
||||
## Anwendungsfälle im LLM Wiki Pattern
|
||||
|
||||
Nach dem [[LLM Wiki Pattern]] ist Marp nützlich für:
|
||||
- Generieren von Präsentationen direkt aus Wiki-Inhalten
|
||||
- Erstellen von Foliendecks aus Markdown, ohne den Workflow zu verlassen
|
||||
- Präsentieren von synthetisiertem Wissen aus dem Wiki
|
||||
|
||||
## Beispiel-Verwendung
|
||||
|
||||
```markdown
|
||||
---
|
||||
marp: true
|
||||
theme: default
|
||||
---
|
||||
|
||||
# Presentation Title
|
||||
|
||||
This is a slide created from wiki content.
|
||||
|
||||
---
|
||||
|
||||
# Next Slide
|
||||
|
||||
- Point 1
|
||||
- Point 2
|
||||
- Point 3
|
||||
```
|
||||
|
||||
## Obsidian-Integration
|
||||
|
||||
1. Das Marp-Plugin in Obsidian installieren
|
||||
2. Notizen mit Marp-Direktiven erstellen
|
||||
3. Den Vorschaumodus von Marp verwenden, um Folien anzuzeigen
|
||||
4. In verschiedene Formate exportieren
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Verarbeitung des LLM Wiki Pattern Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Obsidian]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [ai, coding, agent, cli]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: CLI-Coding-Agent von Mistral AI
|
||||
---
|
||||
# Mistral Vibe
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Mistral Vibe ist Mistral AIs CLI-Coding-Agent und eines von vier Ziel-Tools für die plattformübergreifende Agent-Skills-Architektur, die in der Copilot Skill Restructure Instructions beschrieben ist[^s-copilot-skill-restructure-instructions]. Es wird speziell erwähnt, dass es `.agents/skills/` direkt als gemeinsamen Projektort liest, was es zum primären Ziel für die Skill-Umstrukturierung macht[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
Mistral Vibe ist eine von vier Plattformen (zusammen mit GitHub Copilot, Claude Code und Codex CLI), die die diskreten Wiki-Skills aufrufen können, die aus der monolithischen AGENTS.md-Datei extrahiert werden. Die Quelle vermerkt, dass Mistral Vibe `.agents/skills/` nativ auflöst und keine zusätzliche Verkabelung erfordert[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** CLI-Coding-Agent
|
||||
- **Status:** Aktiv
|
||||
- **Sprache/Technik:** CLI-Tool
|
||||
- **Verantwortlich:** Mistral AI
|
||||
- **Repository:** Nicht in der Quelle angegeben
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[wikitool]] (über Skill-Aufrufe)
|
||||
- **Ähnlich wie:** [[GitHub Copilot]], [[Claude Code]], [[Codex CLI]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Mistral Vibe liest `.agents/skills/` nativ als gemeinsamen Projektort und unterstützt auch `.vibe/skills/`-Projekt-lokal oder `~/.vibe/skills/` globale Skill-Verzeichnisse[^s-copilot-skill-restructure-instructions]. Dies macht es besonders geeignet für den gemeinsamen Skill-Verzeichnis-Ansatz, der im Umstrukturierungsplan beschrieben ist.
|
||||
|
||||
**Direkt aus der Quelle bestätigt** (`mistralai/mistral-vibe`'s `vibe/core/skills/builtins/skill_creator.py`, `vibe/core/skills/builtins/vibe.py` und `CHANGELOG.md`): Mistral Vibe löst Skills in der Reihenfolge `.vibe/skills/` (Projekt, Trusted-Folder-gated), `.agents/skills/` (Projekt, Trusted-Folder-gated), `~/.vibe/skills/` (Benutzer) und `~/.agents/skills/` (Benutzer) auf - das Changelog vermerkt explizit „Load skills from `~/.agents/skills` so they can be shared across agents"[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - `.agents/skills/`-native Support-Behauptung direkt aus der `mistralai/mistral-vibe`-Quelle bestätigt (zuvor nur aus dem nicht verifizierten Anweisungssatz zitiert)[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-04 - Seite während der Verarbeitung der Copilot Skill Restructure Instructions erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[GitHub Copilot]]
|
||||
- [[Claude Code]]
|
||||
- [[Codex CLI]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [google, ai, rag, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [ChatGPT, RAG, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: RAG-basiertes KI-Wissenswerkzeug von Google; beantwortet Fragen aus hochgeladenen Dokumenten, ohne Wissen dauerhaft anzuhäufen.
|
||||
---
|
||||
# NotebookLM
|
||||
|
||||
**Typ:** Tool (Googles KI-Wissensmanagementsystem)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
NotebookLM ist Googles KI-gesteutertes Wissensmanagementsystem, das Retrieval Augmented Generation (RAG) verwendet, um Fragen auf Grundlage hochgeladener Dokumente zu beantworten. Es stellt den traditionellen RAG-Ansatz dar, den das [[LLM Wiki Pattern]] verbessern möchte.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Web-Anwendung / KI-Assistent
|
||||
- **Entwickler:** Google
|
||||
- **Ansatz:** RAG (Retrieval Augmented Generation)
|
||||
- **Status:** Aktiv (Stand Quelle)
|
||||
- **Website:** https://notebooklm.google/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet Ansatz:** [[RAG]]
|
||||
- **Verglichen mit:** [[LLM Wiki Pattern]] (traditionelles RAG vs. persistentes Wiki)
|
||||
- **Ähnlich wie:** [[ChatGPT]] Datei-Uploads
|
||||
|
||||
## Funktionsweise
|
||||
|
||||
1. Benutzer lädt eine Sammlung von Dokumenten hoch
|
||||
2. Bei jeder Abfrage führt das System Folgendes durch:
|
||||
- Ruft relevante Chunks aus den hochgeladenen Dokumenten ab
|
||||
- Generiert eine Antwort basierend auf diesen Chunks
|
||||
- Behält KEINE persistenten synthetisierten Kenntnisse bei
|
||||
3. Wissen wird bei jeder Abfrage von Grund auf neu abgeleitet
|
||||
|
||||
## Einschränkungen (im LLM Wiki Pattern)
|
||||
|
||||
- Keine Akkumulation von Wissen über Abfragen hinweg
|
||||
- Subtile Fragen, die eine Synthese mehrerer Dokumente erfordern, müssen jedes Mal neu abgeleitet werden
|
||||
- Keine persistenten Querverweise oder gekennzeichnete Widersprüche
|
||||
- Keine Aufzinsung durch das Hinzufügen neuer Quellen
|
||||
|
||||
## Vergleich mit dem LLM Wiki Pattern
|
||||
|
||||
| Merkmal | NotebookLM | LLM Wiki Pattern |
|
||||
|---------|------------|-------------------|
|
||||
| Ansatz | RAG | Persistentes Wiki |
|
||||
| Wissensakkumulation | Nein | Ja |
|
||||
| Querverweise | Nein | Ja |
|
||||
| Widerspruchserkennung | Nein | Ja |
|
||||
| Wartungsaufwand | Niedrig (automatisch) | Niedrig (vom LLM gepflegt) |
|
||||
| Abfrageleistung | Schnell | Schnell (nach initialer Kompilierung) |
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Verarbeitung des LLM Wiki Pattern Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[RAG]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[ChatGPT]]
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [obsidian, browser, clipping, web]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Obsidian, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Browser-Erweiterung, die Webartikel als Markdown direkt in Obsidian-Vaults ablegt, für die schnelle Aufnahme in Wissens-Workflows.
|
||||
---
|
||||
# Obsidian Web Clipper
|
||||
|
||||
**Typ:** Tool (Browser-Erweiterung für Obsidian)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Obsidian Web Clipper ist eine Browser-Erweiterung, die Web-Artikel in Markdown-Format konvertiert und es einfach macht, Online-Inhalte direkt in einem Obsidian-Tresor zu speichern. Es soll Quellen schnell in die Rohsammlung für die Verarbeitung durch das LLM bekommen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Browser-Erweiterung
|
||||
- **Plattform:** Chrome, Firefox, Edge, Safari
|
||||
- **Zweck:** Web-Artikel als Markdown speichern
|
||||
- **Integration:** Direkt mit Obsidian-Tresoren
|
||||
- **Ausgabeformat:** Markdown
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erweitert:** [[Obsidian]]
|
||||
- **Verwendet von:** [[LLM Wiki Pattern]] (um Quellen schnell in die Rohsammlung zu bekommen)
|
||||
- **Erstellt Dateien für:** Raw Sources Layer
|
||||
|
||||
## Features
|
||||
|
||||
### Clipping-Funktionen
|
||||
- Ganze Artikel als Markdown speichern
|
||||
- Hauptinhalte extrahieren (Anzeigen, Navigation usw. entfernen)
|
||||
- Formatierung und Bilder beibehalten
|
||||
- Anpassbare Vorlagen
|
||||
- In bestimmten Ordnern speichern
|
||||
|
||||
### Workflow-Integration
|
||||
- One-Click-Clipping vom Browser
|
||||
- Tastaturkürzel
|
||||
- Schneller Zugriff von der Browser-Symbolleiste
|
||||
|
||||
## Anwendungsfälle im LLM Wiki Pattern
|
||||
|
||||
Nach dem [[LLM Wiki Pattern]] ist Obsidian Web Clipper:
|
||||
- Sehr nützlich, um Quellen schnell in die Rohsammlung zu bekommen
|
||||
- Erster Schritt im Ingest-Workflow: Clip → Bilder herunterladen → Ingest
|
||||
|
||||
## Empfohlene Konfiguration
|
||||
|
||||
1. Die Erweiterung für den bevorzugten Browser installieren
|
||||
2. Das Speichern im Ordner `raw/articles/` konfigurieren
|
||||
3. Hotkeys für schnelles Clipping einrichten
|
||||
4. Mit der "Download attachments"-Funktion von Obsidian kombinieren:
|
||||
- Einstellungen → Dateien und Links → "Attachment folder path" = `raw/assets/`
|
||||
- Einstellungen → Hotkeys → "Download attachments for current file" an einen Hotkey binden (z.B. Strg+Umschalt+D)
|
||||
- Nach dem Clipping den Hotkey drücken, um alle Bilder lokal herunterzuladen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Verarbeitung des LLM Wiki Pattern Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Obsidian]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [note-taking, knowledge-management, markdown, visualization, export]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Obsidian Web Clipper, Dataview, Marp, qmd]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Markdown-basierte Notizanwendung mit bidirektionaler Verlinkung, Wissensgraph-Darstellung und Plugin-Ökosystem für persönliche Wikis.
|
||||
---
|
||||
# Obsidian
|
||||
|
||||
**Typ:** Tool (Notiztakings- und Wissensmanagementsystem Anwendung)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Obsidian ist eine erweiterbare, Markdown-basierte Notizanwendung für den Aufbau von Wissensmanagementsystemen. Sie erlaubt es, Notizen in einem lokalen Ordner anzulegen und zu verlinken und daraus einen persönlichen Wissensgraphen aufzubauen. Notizen werden als reine Markdown-Dateien gespeichert, wodurch sie tragbar und versionskontrollierbar sind.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Desktop-Anwendung
|
||||
- **Plattform:** Windows, macOS, Linux, Mobile (iOS, Android)
|
||||
- **Lizenz:** Proprietär (kostenlos für den persönlichen Gebrauch)
|
||||
- **Dateiformat:** Markdown
|
||||
- **Datenspeicher:** Lokale Dateien (kein Vendor Lock-in)
|
||||
- **Website:** https://obsidian.md
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[LLM Wiki Pattern]] (als IDE zum Durchsuchen von Wiki-Inhalten)
|
||||
- **Hat Plugin:** [[Dataview]]
|
||||
- **Hat Plugin:** [[Marp]]
|
||||
- **Verwandt mit:** [[Obsidian Web Clipper]] (Browser-Erweiterung)
|
||||
- **Kann suchen mit:** [[qmd]]
|
||||
|
||||
## Features
|
||||
|
||||
### Kernfunktionen
|
||||
- Lokal-erste Markdown-Notizen
|
||||
- Bidirektionale Verlinkung mit `wikilinks`
|
||||
- Graphenansicht zur Visualisierung von Verbindungen zwischen Notizen
|
||||
- Rückverweise zur Anzeige eingehender Verweise
|
||||
- Tägliche Notizen Plugin
|
||||
- Vorlagen
|
||||
- Suche in allen Notizen
|
||||
|
||||
### Plugin-Ökosystem
|
||||
- **Dataview**: Führe Abfragen über Seiten-Frontmatter durch, um dynamische Tabellen und Listen zu generieren
|
||||
- **Marp**: Erstelle Foliendecks aus Markdown
|
||||
- **Web Clipper**: Browser-Erweiterung zum Ausschneiden von Web-Artikeln
|
||||
- Viele Community-Plugins verfügbar
|
||||
|
||||
## Anwendungsfälle im LLM Wiki Pattern
|
||||
|
||||
Nach dem [[LLM Wiki Pattern]] dient Obsidian als "IDE" zum Durchsuchen des Wikis:
|
||||
- Der Mensch hält Obsidian offen, um Wiki-Inhalte in Echtzeit zu durchsuchen
|
||||
- Links folgen, die Graphenansicht prüfen, aktualisierte Seiten lesen
|
||||
- Der LLM-Agent nimmt Änderungen basierend auf dem Gespräch vor
|
||||
- Obsidian bietet die Visualisierungs- und Navigationsoberfläche
|
||||
|
||||
## Konfigurationstipps
|
||||
|
||||
- "Attachment folder path" auf `raw/assets/` festlegen, um Bilder lokal herunterzuladen
|
||||
- Einen Hotkey für "Download attachments for current file" binden (z.B. Strg+Umschalt+D)
|
||||
- Die Graphenansicht verwenden, um Verbindungen zwischen Seiten zu sehen
|
||||
|
||||
|
||||
Dieser Workflow ist besonders nützlich für:
|
||||
- Konvertierung von GTD (Getting Things Done) Bäumen zu Dokumentformaten
|
||||
- Archivierung kompletter Tresore mit komplexen Strukturen
|
||||
- Generierung von bearbeitbaren (DOCX) und archivierten (PDF) Versionen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Verarbeitung des LLM Wiki Pattern Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Obsidian Web Clipper]]
|
||||
- [[Dataview]]
|
||||
- [[Marp]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[qmd]]
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [openai, ai, coding, agent]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Claude Code, OpenCode, Pi, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Coding-Modell von OpenAI, das GitHub Copilot antreibt; versteht, erzeugt und ändert Code in mehreren Sprachen.
|
||||
---
|
||||
# OpenAI Codex
|
||||
|
||||
**Typ:** Tool (KI-Kodierungsmodell von OpenAI)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
OpenAI Codex ist Openais KI-Modell für Kodierungsaufgaben. Es treibt GitHub Copilot an und kann Code verstehen, generieren und bearbeiten. Es wird als einer der LLM-Agenten erwähnt, die das [[LLM Wiki Pattern]] implementieren können.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** KI-Modell / Agent
|
||||
- **Entwickler:** OpenAI
|
||||
- **Hauptverwendung:** Codegenerierung und Analyse
|
||||
- **Bemerkenswerte Verwendung:** Treibt GitHub Copilot an
|
||||
- **Status:** Aktiv (sich entwickelnd)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[LLM Wiki Pattern]] (als Ziel-LLM-Agent)
|
||||
- **Ähnlich zu:** [[Claude Code]], [[OpenCode]], [[Pi]]
|
||||
- **Treibt an:** GitHub Copilot
|
||||
|
||||
## Features
|
||||
|
||||
- Code in mehreren Sprachen verstehen und generieren
|
||||
- Kontextbewusste Vervollständigungen
|
||||
- Kann mehrere Dateien lesen und verarbeiten
|
||||
- Wird in Entwicklungsumgebungen integriert
|
||||
|
||||
## Verwendung im LLM Wiki Pattern
|
||||
|
||||
OpenAI Codex wird als einer der LLM-Agenten erwähnt, der das LLM-Wiki-Pattern implementieren kann:
|
||||
- Kann mit Schemadokumenten (wie CLAUDE.md oder AGENTS.md) konfiguriert werden
|
||||
- Kann Quelldateien lesen, Informationen extrahieren, Wiki pflegen
|
||||
- Mensch gibt Richtung vor, LLM führt die Wartungsarbeit durch
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Pattern-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Claude Code]]
|
||||
- [[OpenCode]]
|
||||
- [[Pi]]
|
||||
- [[GitHub Copilot]]
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [ai, coding, agent, open-source]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Claude Code, OpenAI Codex, Pi, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: KI-Coding-Assistent für Codeerzeugung und -analyse; kann das LLM-Wiki-Muster für dauerhafte Wissensverwaltung umsetzen.
|
||||
---
|
||||
# OpenCode
|
||||
|
||||
**Typ:** Tool (KI-Kodierassistent)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
OpenCode ist ein KI-Kodierassistent, der neben [[Claude Code]], [[OpenAI Codex]] und [[Pi]] als einer der LLM-Agenten erwähnt wird, die das [[LLM Wiki Pattern]] implementieren können. Er wurde entworfen, um Entwickler bei Kodierungsaufgaben zu unterstützen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** KI-Assistent / Agent
|
||||
- **Hauptverwendung:** Codegenerierung und Analyse
|
||||
- **Status:** Aktiv (zum Quellendatum)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[LLM Wiki Pattern]] (als Ziel-LLM-Agent)
|
||||
- **Ähnlich zu:** [[Claude Code]], [[OpenAI Codex]], [[Pi]]
|
||||
|
||||
## Features
|
||||
|
||||
- Codegenerierung und Analyse
|
||||
- Dateilesen und Bearbeitung
|
||||
- Verständnis mehrerer Dateikontexte
|
||||
- Integration in Entwickler-Workflows
|
||||
|
||||
## Verwendung im LLM Wiki Pattern
|
||||
|
||||
OpenCode wird als einer der LLM-Agenten erwähnt, die folgende Aufgaben ausführen können:
|
||||
- Quelldokumente lesen
|
||||
- Wichtige Informationen extrahieren
|
||||
- Ein beständiges Wiki pflegen
|
||||
- Schemavorgaben einhalten (wie AGENTS.md oder CLAUDE.md)
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Pattern-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Claude Code]]
|
||||
- [[OpenAI Codex]]
|
||||
- [[Pi]]
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [ai, coding, agent]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Claude Code, OpenAI Codex, OpenCode, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Assistenz-Agent von Inflection AI; kann das LLM-Wiki-Muster wie andere LLM-Agenten umsetzen.
|
||||
---
|
||||
# Pi
|
||||
|
||||
**Typ:** Tool (KI-Assistent)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Pi (auch bekannt als Inflection AIs Assistent) ist ein KI-Agent, der neben [[Claude Code]], [[OpenAI Codex]] und [[OpenCode]] als einer der LLM-Agenten erwähnt wird, die das [[LLM Wiki Pattern]] implementieren können.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** KI-Assistent / Agent
|
||||
- **Entwickler:** Inflection AI
|
||||
- **Hauptverwendung:** Allgemeine KI-Unterstützung (einschließlich Kodierung)
|
||||
- **Status:** Aktiv (zum Quellendatum)
|
||||
- **Website:** https://pi.ai/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[LLM Wiki Pattern]] (als Ziel-LLM-Agent)
|
||||
- **Ähnlich zu:** [[Claude Code]], [[OpenAI Codex]], [[OpenCode]]
|
||||
|
||||
## Features
|
||||
|
||||
- Allgemeine Konversations-KI
|
||||
- Code-Verständnis und Generierung
|
||||
- Multi-Turn-Gespräche
|
||||
- Datei- und Dokument-Verarbeitung
|
||||
|
||||
## Verwendung im LLM Wiki Pattern
|
||||
|
||||
Pi wird als einer der LLM-Agenten erwähnt, die folgende Aufgaben ausführen können:
|
||||
- Quelldokumente aufnehmen
|
||||
- Ein beständiges Wiki aufbauen und pflegen
|
||||
- Schema- und Konventionsdokumente einhalten
|
||||
- Wissens-Kumulation durchführen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Pattern-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Claude Code]]
|
||||
- [[OpenAI Codex]]
|
||||
- [[OpenCode]]
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [compatibility, windows, gaming, steam, valve]
|
||||
created: 2026-08-01
|
||||
modified: 2026-08-29
|
||||
related: [Wine, Bottles, Wine-Staging, Wine GE, Lutris, Steam]
|
||||
sources: [Source - Wine]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Wine-basierte Kompatibilitätsschicht von Valve; lässt Windows-Spiele über Steam unter Linux laufen, mit optimierter DirectX-Übersetzung.
|
||||
---
|
||||
# Proton
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Proton ist eine Kompatibilitätsebene, die von Valve für das Ausführen von Windows-Spielen auf Linux über Steam entwickelt wurde. Sie basiert auf [[Wine]], enthält aber zusätzliche Patches, Bibliotheken und Komponenten, die speziell für Gaming optimiert sind, einschließlich DirectX-Übersetzungsebenen (DXVK, VKD3D-Proton) und Steam-Client-Integration.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Windows-Spiele auf Linux über Steam ausführen
|
||||
- **Status:** Aktiv, gepflegt von Valve und CodeWeavers
|
||||
- **Entwickler:** Valve Corporation
|
||||
- **Lizenz:** Proprietär (Steam-Bedingungen)
|
||||
- **Plattform:** Linux (über Steam)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Basierend auf:** [[Wine]]
|
||||
- **Verwendet von:** [[Bottles]] (in mehrere Runtimes integriert)
|
||||
- **Verwandt mit:** [[Steam]], [[Wine-Staging]], [[Wine GE]], [[Lutris]]
|
||||
- **Integriert mit:** [[Bottles]] (Soda, Caffe, GE Proton Runtimes)
|
||||
|
||||
## Details
|
||||
|
||||
### Versionen
|
||||
|
||||
- **Proton:** Standard-Version, die mit Steam ausgeliefert wird
|
||||
- **Proton Experimental:** Bleeding-Edge-Version mit neuesten Features
|
||||
- **Proton GE:** Benutzerdefinierter Build von GloriousEggroll mit zusätzlichen Patches
|
||||
|
||||
### Integration mit Bottles
|
||||
|
||||
Proton ist in mehrere [[Bottles]]-Runtimes integriert:
|
||||
|
||||
- **Soda:** Wine Valve + Staging + Proton
|
||||
- **Caffe:** Wine Upstream + Staging + Proton
|
||||
- **GE Proton:** Wine Valve + Staging + Proton + Steam
|
||||
|
||||
Diese Runtimes ermöglichen die Verwendung von Proton-Gaming-Optimierungen außerhalb der Steam-Umgebung.
|
||||
|
||||
### Wichtigste Komponenten
|
||||
|
||||
- **DXVK:** Direct3D 9/10/11 zu Vulkan-Übersetzungsebene
|
||||
- **VKD3D-Proton:** Direct3D 12 zu Vulkan-Übersetzungsebene
|
||||
- **Wine:** Basis-Kompatibilitätsebene mit Valves benutzerdefinierten Patches
|
||||
- **Steam Runtime:** Bietet Windows-DLLs und Bibliotheken
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Wine]]
|
||||
- [[Bottles]]
|
||||
- Wine Valve
|
||||
- [[Wine-Staging]]
|
||||
- [[Wine GE]]
|
||||
- [[Lutris]]
|
||||
- [[Source - Wine]]
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Lutris, Proton]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Valves Plattform für digitalen Spielevertrieb und Spielebibliothek auf dem PC.
|
||||
---
|
||||
# Steam
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Steam ist Valves digitale Spielebörse und Game-Library-Client zum Kauf und Spielen von PC-Spielen. Unter Linux integriert er sich mit Proton, um nur-Windows-Spiele durch Steam-Play-Kompatibilität auszuführen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite über wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [compatibility, windows, linux, gaming]
|
||||
created: 2026-08-01
|
||||
modified: 2026-08-29
|
||||
related: [Bottles, Proton, Wine-Staging, Wine GE, Lutris, Arch Linux]
|
||||
sources: [Source - Wine, Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Kompatibilitätsschicht, die Windows-API-Aufrufe nach POSIX übersetzt und Windows-Anwendungen unter Linux, BSD und macOS ohne Virtualisierung oder Emulation ausführt.
|
||||
---
|
||||
# Wine
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Wine (Wine Is Not an Emulator) ist eine Kompatibilitätsschicht, die Windows-Anwendungen auf Unix-ähnlichen Betriebssystemen einschließlich Linux, macOS und BSD ausführen kann. Sie übersetzt Windows-API-Aufrufe zur Laufzeit in POSIX-kompatible Aufrufe, wodurch die Leistungs- und Speicherstrafen einer vollständigen virtuellen Maschine entfallen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Ausführen von Windows-Anwendungen unter Linux und anderen Unix-ähnlichen Systemen
|
||||
- **Status:** Aktiv, weit verbreitet
|
||||
- **Lizenz:** LGPL
|
||||
- **Plattform:** Linux, macOS, BSD
|
||||
- **Website:** https://www.winehq.org/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[Bottles]], [[Lutris]], [[Proton]]
|
||||
- **Erweitert von:** [[Wine-Staging]], [[Wine GE]]
|
||||
- **Verwandt mit:** [[Proton]], [[Arch Linux]]
|
||||
- **Abhängig von:** System-Bibliotheken, X11/Wayland
|
||||
|
||||
## Details
|
||||
|
||||
### Varianten
|
||||
|
||||
- **Wine Upstream:** Vanilla Wine from winehq.org
|
||||
- **Wine Valve:** Valves benutzerdefinierter Wine-Build mit Proton-Integration
|
||||
- **Wine GE:** Benutzerdefinierte Builds von GloriousEggroll mit zusätzlichen Patches
|
||||
- **Wine-Staging:** Wine mit zusätzlichen experimentellen Patches
|
||||
|
||||
### Arch-Linux-Konfiguration
|
||||
|
||||
Um zu verhindern, dass Wine während der Paketinstallation systemweit Dateibindungen erstellt, fügen Sie folgendes zu `/etc/pacman.conf` hinzu:
|
||||
|
||||
```
|
||||
[options]
|
||||
NoExtract = usr/lib/binfmt.d/wine.conf
|
||||
NoExtract = usr/share/applications/wine.desktop
|
||||
```
|
||||
|
||||
Dies verhindert, dass Wine Dateityp-Zuordnungen und binfmt-Handler systemweit registriert.
|
||||
|
||||
## Verwendung in Bottles
|
||||
|
||||
Wine dient als Grundlage für mehrere [[Bottles]]-Runtimes, einschließlich:
|
||||
- Soda - Basierend auf Wine Valve mit Staging und Proton
|
||||
- Caffe - Basierend auf Wine Upstream mit Staging und Proton
|
||||
- Vaniglia - Basierend auf Wine Upstream mit Staging
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Bottles]]
|
||||
- [[Proton]]
|
||||
- [[Wine-Staging]]
|
||||
- [[Wine GE]]
|
||||
- [[Lutris]]
|
||||
- [[Arch Linux]]
|
||||
- [[Source - Wine]]
|
||||
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [repository, external, reference, wiki-skills]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [OKF Compatibility, farzaa gist]
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis, Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Externes GitHub-Repository (gavischneider/awesome-llm-wiki) mit verschiedenen Umsetzungen und Mustern für LLM-Wiki-Skills
|
||||
---
|
||||
# awesome-llm-wiki
|
||||
|
||||
**Typ:** Tool (Externes Repository)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das awesome-llm-wiki Repository (gavischneider/awesome-llm-wiki) ist ein externes GitHub-Repository, das verschiedene LLM-Wiki-Skill-Implementierungen, Muster und Referenzen sammelt. Es dient als Community-Ressource zum Erkunden verschiedener Ansätze zum Erstellen und Pflegen von LLM-gestützten Wissensdatenbanken.
|
||||
|
||||
Während der Codex-Analyse wurde dieses Repository als Vergleichspunkt gegen das interne AGENTS.md-Schema und die wikitool-Implementierung verwendet. Die Analyse zeigte, dass zwar awesome-llm-wiki viele nützliche Ideen enthält (wie OKF-Kompatibilität), aber der deterministische Ansatz des aktuellen Repos über wikitool konzeptionell vielen Einträgen in der Sammlung bereits überlegen ist.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Community-Sammlung von LLM-Wiki-Skills und -Mustern
|
||||
- **Status:** Extern, aktiv
|
||||
- **Besitzer:** gavischneider
|
||||
- **Repository:** https://github.com/gavischneider/awesome-llm-wiki
|
||||
- **Typ:** GitHub-Repository
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verglichen mit:** [[AGENTS.md]], [[wikitool]]
|
||||
- **Verwandte Konzepte:** [[OKF Compatibility]]
|
||||
- **Analysequelle:** [[Source - LLM Improvements Codex Analysis]]
|
||||
- **Ähnlich wie:** [[farzaa gist]]
|
||||
|
||||
## Identifizierte Schlüsselbeiträge
|
||||
|
||||
Aus der Codex-Analyse wurden die folgenden Ideen von awesome-llm-wiki notiert:
|
||||
|
||||
- **OKF-Kompatibilität:** Großes Thema im Repository, identifiziert als potenzielle zukünftige Erweiterung (als Export-/Validierungsmodus, nicht als Ersatz)
|
||||
- **Verschiedene Skill-Muster:** Wird zum Vergleich verwendet, um zu identifizieren, was das aktuelle Repository bereits besser macht
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[farzaa gist]] (ein weiterer analysierter externer Referenz)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
- [[OKF Compatibility]]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [external, gist, reference, wiki-pattern]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [awesome-llm-wiki]
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Externes Gist (farzaa/c35ac0cfbeb957788650e36aabea836d) mit Ideen und Umsetzungen zum LLM-Wiki-Muster
|
||||
---
|
||||
# farzaa gist
|
||||
|
||||
**Typ:** tool (External Reference)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das farzaa-Gist (https://gist.github.com/farzaa/c35ac0cfbeb957788650e36aabea836d) ist ein externes GitHub-Gist, das LLM-Wiki-Muster-Ideen und Implementierungen enthält. Es wurde zusammen mit dem awesome-llm-wiki-Repository als Referenzpunkt verwendet, um externe Ansätze gegen das interne AGENTS.md-Schema und wikitool zu vergleichen.
|
||||
|
||||
Die Codex-Analyse stellte fest, dass dieses Gist viele Ideen und Meinungen enthält, aber auch Overhead und Ballast. Die Analyse kam zu dem Ergebnis, dass die deterministische Grundlage des aktuellen Repos stärker ist als viele Muster in externen Ressourcen wie diesem Gist.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** LLM-Wiki-Muster-Ideen und Implementierungen
|
||||
- **Status:** Extern, statisch
|
||||
- **Besitzer:** farzaa
|
||||
- **URL:** https://gist.github.com/farzaa/c35ac0cfbeb957788650e36aabea836d
|
||||
- **Typ:** GitHub-Gist
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verglichen mit:** [[AGENTS.md]], [[wikitool]]
|
||||
- **Analysequelle:** [[Source - LLM Improvements Codex Analysis]], [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- **Ähnlich wie:** [[awesome-llm-wiki]]
|
||||
- **Enthält:** [[pascalandy schema]] (in Community-Kommentaren)
|
||||
|
||||
## Analyseanmerkungen
|
||||
|
||||
Die Codex-Analyse charakterisierte dieses Gist als enthaltend:
|
||||
- Nützliche Ideen für Wiki-Muster
|
||||
- Einige Meinungen und Overhead, die möglicherweise nicht anwendbar sind
|
||||
- Person-zentrische Taxonomien (identifiziert als zu vermeidendes Anti-Muster für IT-Betrieb)
|
||||
- Aggressive "alles immer umschreiben"-Schleifen (identifiziert als Anti-Muster)
|
||||
|
||||
Die Sonnet-Analyse identifizierte mehrere spezifische, umsetzbare Empfehlungen aus diesem Gist:
|
||||
- Seiten-Längen-/Qualitätsschwellen (Stub-Minimum: ≥3 Sätze / 15 Zeilen; Split-Schwelle: >120-150 Zeilen)[^s-llm-improvements-sonnet-analysis]
|
||||
- Stilguide-Regeln (Wikipedia-Stil, vermeiden Sie em-dashes für Gedanken, Füllwörter, AI-Phrasen, max 2 Zitate/Seite)[^s-llm-improvements-sonnet-analysis]
|
||||
- Anti-Cramming-Heuristik (wenn Sie einen 3. Absatz zu einem Unterthema hinzufügen, erstellen Sie eine dedizierte Seite)[^s-llm-improvements-sonnet-analysis]
|
||||
- Checkpoint-/Audit-Rhythmus (Index+Backlinks alle 15 Einträge neu erstellen, auf 0 neue Artikel überprüfen, 3 am meisten geänderte neu lesen)[^s-llm-improvements-sonnet-analysis]
|
||||
- Massen-Update-Gate (Operationen bestätigen, die ≥10 Seiten betreffen)[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[awesome-llm-wiki]]
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Content Quality Control]]
|
||||
- [[Stub Threshold]]
|
||||
- [[Split Threshold]]
|
||||
- [[Anti-Cramming Heuristic]]
|
||||
- [[Checkpoint Audit]]
|
||||
- [[Mass-Update Gate]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,99 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [deployment, cli, go, automation]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [Go, ha-core, plugnburn-edl]
|
||||
sources: []
|
||||
confidence: 0.75
|
||||
confidence_base: 0.75
|
||||
provenance: general
|
||||
summary: In Go geschriebenes CLI-Werkzeug zur Automatisierung von Anwendungs-Deployment, Konfigurationsverwaltung und Infrastruktur.
|
||||
---
|
||||
# gdeploy
|
||||
|
||||
**Typ:** Tool (CLI Deployment Tool)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
gdeploy scheint ein Go-basiertes Bereitstellungstool zu sein, das sich im Repository befindet. Basierend auf seinem Namen und dem Vorhandensein verwandter Tools bietet es wahrscheinlich Funktionen zum Bereitstellen von Anwendungen, zum Verwalten von Infrastruktur oder zum Automatisieren von Release-Prozessen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** CLI-Tool
|
||||
- **Sprache:** [[Go]]
|
||||
- **Zweck:** Bereitstellungsautomatisierung
|
||||
- **Status:** Aktiv (hergeleitet aus Vorhandensein im Quellbaum)
|
||||
- **Repository:** Lokales Verzeichnis (gdeploy/)
|
||||
- **Besitzer:** Torben
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Geschrieben in:** [[Go]]
|
||||
- **Verwandt mit:** [[plugnburn-edl]] (ähnliche Bereitstellungs-/EDL-Werkzeuge)
|
||||
- **Kann verwendet werden von:** [[ha-core]] oder anderen Projekten
|
||||
|
||||
## Merkmale (hergeleitet)
|
||||
|
||||
Basierend auf typischen Bereitstellungstools und dem Kontext kann gdeploy bieten:
|
||||
|
||||
### Bereitstellungsfunktionen
|
||||
|
||||
- Anwendungsbereitstellung auf Servern
|
||||
- Konfigurationsverwaltung
|
||||
- Service-Neustart/Reload
|
||||
- Integritätsprüfungen
|
||||
- Rollback-Funktionen
|
||||
|
||||
### Automatisierung
|
||||
|
||||
- Skriptbare Bereitstellungs-Pipelines
|
||||
- Umgebungsverwaltung (dev, Staging, prod)
|
||||
- Secrets-Verwaltung
|
||||
- Protokollierung und Auditing
|
||||
|
||||
### Integration
|
||||
|
||||
- Kann sich in Container-Laufzeiten integrieren (Docker usw.)
|
||||
- Kann Cloud-Provider unterstützen
|
||||
- Kann mit Konfigurationsverwaltungstools arbeiten
|
||||
|
||||
## Typische Anwendungsfälle
|
||||
|
||||
```bash
|
||||
# Example usage patterns (hypothetical)
|
||||
gdeploy deploy myapp production
|
||||
gdeploy rollback myapp v1.2.3
|
||||
gdeploy status myapp
|
||||
gdeploy config set myapp DATABASE_URL=...
|
||||
```
|
||||
|
||||
## Vergleich mit ähnlichen Tools
|
||||
|
||||
| Funktion | gdeploy | plugnburn-edl | Ansible | Terraform |
|
||||
|---------|---------|---------------|---------|-----------|
|
||||
| Sprache | Go | Go | Python | Go |
|
||||
| Fokus | Bereitstellung | EDL/Bereitstellung | Konfigurationsverwaltung | IaC |
|
||||
| Agentlos | ? | ? | Ja | Ja |
|
||||
| Zustandsverwaltung | ? | ? | Ja | Ja |
|
||||
|
||||
## Architektur
|
||||
|
||||
Falls es den typischen Go CLI-Mustern folgt:
|
||||
- Hauptpaket mit Unterbefehlen
|
||||
- Konfiguration über YAML/JSON-Dateien
|
||||
- Plugin-Architektur möglich
|
||||
- Protokollierung zu stdout/Datei
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-25] - Entity-Seite als Teil des initialen Wiki-Gerüsts erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Go]] - Programming language used
|
||||
- [[plugnburn-edl]] - Related deployment tool
|
||||
- [[ha-core]] - May use this tool
|
||||
- Deployment Automation concept
|
||||
- CI/CD Pipeline concept
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [arch-linux, build-tool, packaging, aur]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Arch Linux, AUR, Aura, GPG]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Build-Werkzeug von Arch Linux; wertet PKGBUILD-Dateien aus, um Quellcode zu übersetzen und installierbare Pakete zu erzeugen.
|
||||
---
|
||||
# makepkg
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
`makepkg` ist das Build-Tool, das von Arch Linux verwendet wird, um Software aus dem Quellcode zu kompilieren und zu paketieren. Es liest PKGBUILD-Dateien, lädt die Quelle herunter, erstellt die Software und erzeugt `.pkg.tar.zst`-Pakete, die mit `pacman` installiert werden können.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Arch-Linux-Pakete aus PKGBUILD-Skripten erstellen
|
||||
- **Status:** Aktiv (Core-Arch-Linux-Tool)
|
||||
- **Sprache:** Bash
|
||||
- **Paket:** Teil des `pacman`-Pakets (`base-devel` Gruppe)
|
||||
- **Dokumentation:** https://man.archlinux.org/man/PKGBUILD.5
|
||||
|
||||
## Features
|
||||
|
||||
- **PKGBUILD-Analyse:** Liest Build-Anweisungen aus PKGBUILD-Dateien
|
||||
- **Abhängigkeitsauflösung:** Installiert automatisch Build-Abhängigkeiten
|
||||
- **Quellverifikation:** Validiert Prüfsummen heruntergeladener Quellen
|
||||
- **Paketerstellung:** Erzeugt installierbare `.pkg.tar.zst`-Pakete
|
||||
- **Signaturunterstützung:** Kann Pakete mit GPG signieren
|
||||
|
||||
## Verwendung in CI/CD
|
||||
|
||||
In Docker-basierten CI/CD-Umgebungen erfordert `makepkg` besondere Handhabung, da es traditionell Root-Privilegien benötigt:
|
||||
|
||||
```dockerfile
|
||||
FROM archlinux:base-devel
|
||||
|
||||
# base-devel includes: gcc, make, autoconf, automake, binutils, bison,
|
||||
# fawk, flex, gawk, gettext, groff, libtool, m4, pacman, patch,
|
||||
# pkgconf, sed, texinfo
|
||||
```
|
||||
|
||||
### Umgehung der Root-Einschränkung
|
||||
|
||||
**Das Problem:** `makepkg` benötigt Root für:
|
||||
- Installation von Build-Abhängigkeiten
|
||||
- Erstellung von Paketen
|
||||
- Verwaltung der Paketdatenbank
|
||||
|
||||
**Die Lösung:**
|
||||
1. Einen nicht-Root-`builder`-Benutzer erstellen
|
||||
2. Passwortloses sudo gewähren: `echo "builder ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers`
|
||||
3. Zu Builder wechseln: `su - builder -c "cd /workspace && makepkg"`
|
||||
|
||||
### Build-Workflow-Muster
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build-arch-package:
|
||||
runs-on: linux-docker
|
||||
container:
|
||||
image: archlinux:base-devel
|
||||
steps:
|
||||
- name: Create builder user
|
||||
run: |
|
||||
useradd -m builder
|
||||
echo "builder ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
|
||||
su - builder -c "cd /workspace && makepkg"
|
||||
|
||||
- name: Upload artifacts
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: arch-packages
|
||||
path: /workspace/*.pkg.tar.zst
|
||||
```
|
||||
|
||||
## Häufige Befehle
|
||||
|
||||
```bash
|
||||
# Build package in current directory
|
||||
makepkg
|
||||
|
||||
# Verify source integrity
|
||||
makepkg --verifysource
|
||||
|
||||
# Force rebuild (skip extraction and preparation)
|
||||
makepkg --noextract --noprepare -f
|
||||
|
||||
# Generate .SRCINFO file
|
||||
makepkg --printsrcinfo > .SRCINFO
|
||||
|
||||
# Install build dependencies
|
||||
makepkg --syncdeps
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Immer Quellen verifizieren:** Das Flag `--verifysource` verwenden
|
||||
2. **`--skipinteg` nie verwenden:** Dies umgeht Integritätsprüfungen
|
||||
3. **.SRCINFO neu generieren:** Immer `makepkg --printsrcinfo > .SRCINFO` verwenden, nie manuell bearbeiten
|
||||
4. **Saubere Builds:** Lokale Dateien vor dem Starten löschen (als abgelaufen betrachten)
|
||||
5. **Zweistufiges Bauen:**
|
||||
- Schritt 1: `makepkg --verifysource -f` - Quellintegrität überprüfen
|
||||
- Schritt 2: `makepkg --noextract --noprepare -f` - Bauen mit vorgezogenem src/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** [[Arch Linux]] Paketverwaltungs-Ökosystem
|
||||
- **Verwendet mit:** [[AUR]] zum Erstellen von Community-Paketen
|
||||
- **Funktioniert mit:** [[Aura]] AUR-Helfer
|
||||
Workflow
|
||||
CI/CD-Infrastruktur
|
||||
- **Signiert mit:** [[GPG]] für Paketverifikation
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Arch Linux]]
|
||||
- [[AUR]]
|
||||
- [[Aura]]
|
||||
- [[GPG]]
|
||||
- https://wiki.archlinux.org/title/makepkg
|
||||
- https://man.archlinux.org/man/makepkg.8
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [schema, taxonomy, external, farzaa-gist]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [farzaa gist, AGENTS.md]
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Von der Community beigesteuertes Wiki Schema (Global) aus pascalandys Kommentar in Farzas Gist, mit alternativer Tag-Taxonomie (area/kind/topic/status/pty)
|
||||
---
|
||||
# pascalandy schema
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das pascalandy-Schema ist ein von der Gemeinschaft beigetragenes "Wiki-Schema (Global)", das in einem Kommentar des Benutzers "pascalandy" am Ende von Farzas Gist zu finden ist (https://gist.github.com/farzaa/c35ac0cfbeb957788650e36aabea836d). Es präsentiert ein alternatives Taxonomie-System zur Organisation von Wiki-Inhalten mit mehreren Tag-Achsen.
|
||||
|
||||
Das Schema wurde während der Sonnet-LLM-Analyse als mögliche Referenz für die Verbesserung der Organisation des aktuellen Wikis bewertet. Obwohl es einige nützliche Ideen enthält (besonders um Skalierungsschwellwerte wie das Aufteilen von Index-Tabellen bei >50 Einträgen und das Erstellen von Thema-Karten bei >200 Seiten), kam die Analyse zu dem Ergebnis, dass seine vollständige Tag-Taxonomie (area/kind/topic/status/pty) mit dem bestehenden entity_type/concept_type/tags-Modell in AGENTS.md in Konflikt steht und nicht als Ganzes übernommen werden sollte.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Alternatives Wiki-Organisations-Schema mit mehrachsen-Tag-Taxonomie
|
||||
- **Status:** Externe Referenz, bewertet aber nicht übernommen
|
||||
- **Version:** Wie in Farzas Gist-Kommentar dokumentiert
|
||||
- **Sprache/Technik:** Markdown, Taxonomie-Design
|
||||
- **Verantwortlich:** pascalandy (GitHub-Benutzer)
|
||||
- **Repository:** Teil von Farzas Gist-Kommentar
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verglichen mit:** [[AGENTS.md]]
|
||||
- **Gefunden in:** [[farzaa gist]]
|
||||
- **Bewertet in:** [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
## Details
|
||||
|
||||
### Tag-Taxonomie
|
||||
|
||||
Das pascalandy-Schema schlägt diese Tag-Achsen vor:
|
||||
- **area/** - Domäne oder Themenbereich
|
||||
- **kind/** - Typ oder Art des Inhalts
|
||||
- **topic/** - Spezifisches Thema
|
||||
- **status/** - Status (z.B. Entwurf, aktiv, abgelöst)
|
||||
- **pty/** - Priorität
|
||||
|
||||
Dieser mehrdimensionale Ansatz ermöglicht flexiblere Filterung und Organisation im Vergleich zu einem einfachen flachen Tag-System.
|
||||
|
||||
### Skalierungs-Empfehlungen
|
||||
|
||||
Das Schema enthält konkrete Skalierungs-Schwellwerte:
|
||||
- Index-Tabellenabschnitte aufteilen, wenn sie 50 Einträge übersteigen[^s-llm-improvements-sonnet-analysis]
|
||||
- Eine `_meta/topic-map.md`-Datei erstellen, wenn Gesamtseiten 200 übersteigen[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
Dies sind handlungsfähige Empfehlungen, die in der Sonnet-Analyse als wertvoll identifiziert wurden.
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-03 - Seite während der Aufnahme der Sonnet-Analyse erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[farzaa gist]]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[AGENTS.md]]
|
||||
- [[Index Scaling]]
|
||||
- [[Three-Layer Architecture]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [search, markdown, cli, local]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Obsidian, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Lokale Suchmaschine für Markdown-Dateien mit hybrider BM25-Vektor-Suche und LLM-Reranking.
|
||||
---
|
||||
# qmd
|
||||
|
||||
**Typ:** Tool (Lokale Suchmaschine für Markdown)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
qmd ist eine lokale Suchmaschine, die speziell für Markdown-Dateien ausgelegt ist. Sie bietet hybride BM25/Vector-Suche mit LLM-Neu-Ranking, alles auf dem Gerät ausgeführt. Sie ist besonders nützlich für größere Wiki-Installationen, wo einfache Index-basierte Suche unzureichend wird.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** CLI-Tool
|
||||
- **Sprache:** Nicht angegeben (wahrscheinlich Go oder Rust)
|
||||
- **Such-Typen:** Hybrid (BM25 + Vector)
|
||||
- **Neu-Ranking:** LLM-basiert
|
||||
- **Bereitstellung:** On-device/lokal
|
||||
- **Repository:** https://github.com/tobi/qmd
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[LLM Wiki Pattern]] (optionales Such-Tool für größere Wikis)
|
||||
- **Durchsucht Inhalte von:** [[Obsidian]]
|
||||
- **Alternative zu:** index.md (für kleine Wikis)
|
||||
|
||||
## Features
|
||||
|
||||
### Such-Capabilities
|
||||
- Hybride BM25/Vector-Suche
|
||||
- LLM-basiertes Neu-Ranking von Ergebnissen
|
||||
- CLI-Schnittstelle für Shell-Integration
|
||||
- MCP-Server für native LLM-Tool-Integration
|
||||
|
||||
### Anwendungsfälle
|
||||
- Suche über Wiki-Seiten, wenn index.md zu umfangreich wird
|
||||
- LLM erlauben, qmd für Suchanfragen aufzurufen
|
||||
- Bessere Suche als einfaches grep für große Wissensdatenbanken
|
||||
|
||||
## Installation und Verwendung
|
||||
|
||||
```bash
|
||||
# Installation (hypothetisch, siehe aktuelles Repo für Details)
|
||||
go install github.com/tobi/qmd@latest
|
||||
|
||||
# Suche von CLI
|
||||
qmd search "knowledge management"
|
||||
|
||||
# Als MCP-Server für LLM-Integration verwenden
|
||||
qmd server
|
||||
```
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wiki ist über ~100 Quellen oder ~hunderte Seiten hinauswachsen
|
||||
- Bedarf für ordentliche Suche über das hinaus, was index.md bietet
|
||||
- Wollen On-device-Datenschutz (keine Cloud-basierte Suche)
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Kleine Wikis, wo index.md ausreicht
|
||||
- Bedarf für Cloud-basierte/Remote-Suche
|
||||
- Einfache grep-basierte Suche ist ausreichend
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Pattern-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Obsidian]]
|
||||
@@ -0,0 +1,263 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: tool
|
||||
tags: [cli, automation, deterministic, wiki-management]
|
||||
created: 2026-08-03
|
||||
modified: 2026-09-01
|
||||
related: [Semantic Lint Automation, Session Orientation, Iteration and Cost Limits, KB Stack Versioning, KB Migration, Personalization Plane, Detect-Repair Asymmetry, Write-Once Frontmatter Fields, Denylist over Allowlist, Command Round-Trip Integrity, Green Suite Blind Spot, Ambient Environment Dependency, Structural Enforcement over Documented Rule, Optional Instance Context File]
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis, Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31, Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31, Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Deterministisches CLI fuer alle mechanischen Wiki-Operationen; seit 2.0.0 liegt es im Python-Paket chemenu, das Kommando heisst weiterhin wikitool
|
||||
---
|
||||
# wikitool
|
||||
|
||||
**Typ:** tool
|
||||
|
||||
## Beschreibung
|
||||
|
||||
wikitool ist ein deterministisches CLI-Tool, das alle mechanischen Operationen für Chemenu verwaltet. Es erzwingt Konsistenz über Gerüstbau, Cross-References, Index-Neuerstellung, Log-Einträge, Confidence-Decay-Berechnungen und Git-Publishing. Das Tool ist so ausgelegt, dass es manuelle Fehler verhindert und strukturelle Aspekte des Wikis (Frontmatter, Linking, Indizierung) immer korrekt sind, sodass sich das LLM auf semantische Inhalte konzentrieren kann.
|
||||
|
||||
Wie in der Codex-Analyse vermerkt, bietet wikitool die deterministische Grundlage, die vielen öffentlichen LLM-Wiki-Skills fehlt. Es implementiert die Trennung von "mechanisch vs. semantisch", die in AGENTS.md definiert ist, wobei wikitool alles handhabt, das präzise automatisiert werden kann, während das LLM Urteile und Prosa handhabt.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Deterministische mechanische Wiki-Operationen
|
||||
- **Status:** Aktiv, in aktiver Entwicklung
|
||||
- **Version:** Teil des tools/chemenu-Pakets
|
||||
- **Sprache/Technik:** Python 3, Typer CLI Framework
|
||||
- **Repository:** Lokal unter `tools/chemenu/`
|
||||
- **Einstiegspunkt:** `tools/wikitool` (Bash-Wrapper)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** [[AGENTS.md]]-Workflow-Implementierung
|
||||
- **Verwendet:** [[Python]]
|
||||
- **Verwandt mit:** [[LLM Wiki Pattern]], [[Three-Layer Architecture]]
|
||||
, [[Mass-Update Gate]]
|
||||
- **implementiert:** [[Semantic Lint Automation]]
|
||||
- **würde implementieren:** [[Session Orientation]]
|
||||
- **Analyse:** [[Source - LLM Improvements Codex Analysis]], [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- **implementiert:** [[Iteration and Cost Limits]]
|
||||
- **implementiert:** [[KB Stack Versioning]]
|
||||
- **implementiert:** [[KB Migration]]
|
||||
- **implementiert:** [[Personalization Plane]]
|
||||
- **zeigt:** [[Detect-Repair Asymmetry]]
|
||||
- **behebt:** [[Write-Once Frontmatter Fields]]
|
||||
- **implementiert:** [[Denylist over Allowlist]]
|
||||
- **zeigt:** [[Command Round-Trip Integrity]]
|
||||
- **zeigt:** [[Green Suite Blind Spot]]
|
||||
- **zeigte:** [[Ambient Environment Dependency]]
|
||||
- **setzt um:** [[Structural Enforcement over Documented Rule]]
|
||||
- **setzt um:** [[Optional Instance Context File]]
|
||||
|
||||
## Befehle
|
||||
|
||||
wikitool bietet die folgenden Befehlskategorien:
|
||||
|
||||
- **Gerüstbau:** `new entity`, `new concept`, `new source`, `new comparison`, `new instruction`. Ein `--set`-Wert für ein Array-Feld wird auf Kommas gesplittet; seit `1.2.0` ist ein literales Komma als `\,` ausdrückbar (Lookbehind `(?<!\\),` plus Unescape je Element), und ein für dasselbe Array-Feld wiederholtes `--set` hängt an statt zu ersetzen. Skalare behalten „last one wins". Derselbe Helper bedient auch `xref add --entities`[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- **Seiten-Mutation:** `touch` (eines Seiten-`modified`/`summary`/`provenance`/`confidence_base`, seit `1.4.0` zusätzlich `--set`/`--add`/`--remove` für jedes Feld, das das Schema des Seitentyps deklariert, abzüglich der Sperrliste `type`, `confidence` und der Referenz-Arrays; `--add`/`--remove` arbeiten auf einzelnen Elementen eines Listenfelds, `--remove` gelingt und meldet es, wenn das Element nicht vorhanden ist, und ein per `touch` geschriebenes `raw_files:` wird gegen das Dateisystem geprüft wie beim Anlegen[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]. Siehe [[Write-Once Frontmatter Fields]] und [[Denylist over Allowlist]]), `rename` (Seite umtiteln und jeden Verweis neu ausrichten, oder Verweise auf eine bestehende Seite neu ausrichten), `rm` (Löschen und Entfernen von Verknüpfungen)
|
||||
- **Cross-References:** `xref add`, `xref remove`, `xref link-source` - seit `1.6.0` schreibt
|
||||
`link-source` **beide Richtungen**: das Ziel bekommt `sources:` und einen Siehe-auch-Eintrag,
|
||||
die Source-Seite trägt das Ziel in ihr eigenes `entities:` oder `concepts:` ein. Welches der
|
||||
beiden Felder es wird, folgt der Collection des Ziels (`kb/entities/` → `entities:`), sodass
|
||||
eine neue Collection hier keine Codeänderung braucht. `xref add` lehnt eine Seite ab, deren
|
||||
Typ `related:` nicht deklariert, und prüft beide Seiten, bevor es eine schreibt; `xref remove`
|
||||
fegt auch ein undeklariertes Feld weg und löscht den Schlüssel, sobald er leer ist[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
Siehe [[Command Round-Trip Integrity]]
|
||||
- **Zitate:** `cite id`, `cite add`, `cite sync` - der Fußnotenblock endet seit `1.5.1` an der
|
||||
**nächsten Überschrift** statt am Dateiende. Zuvor löschte `cite add` jeden Inhalt dahinter,
|
||||
weil `split_cite_block()` alles bis Dateiende als Block nahm und nur die
|
||||
Zitatdefinitionszeilen behielt; `cite sync` und `rename` benutzten denselben Pfad. Loser Text im Block wird auf den
|
||||
Seitenkopf zurückgefaltet statt abgelehnt, und weil der Block immer zuletzt gerendert wird,
|
||||
richtet die erste Zitatoperation eine verrutschte Seite von selbst wieder ein[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]
|
||||
- **Abfrage:** `search` - Textsuche über `kb/` durch ein austauschbares Backend (`rg` heute), plus `--field`-Prädikate, die auf Frontmatter evaluiert werden (`entity_type=system`, `confidence>=0.8`, `tags=k8s`, `!source_url`). Ohne Text ist es eine reine strukturierte Abfrage. Schreibgeschützt und ausgenommen von der Iteration-Budget-Gate, da Abfrage das Lesen statt das Iterieren ist
|
||||
- **Indizierung:** `index rebuild` - regeneriert die `kb/index.md`-Map plus eine pro-Sammlung `INDEX.md`, wobei ein Bereich bei 50 Zeilen in seine eigene Shard aufgeteilt wird
|
||||
- **Herkunft:** `sources coverage`, `sources trace`, `sources rebuild-index`
|
||||
- **Protokollierung:** `log append`, `log status`
|
||||
- **Linting:** `lint` - schreibt den vollen Report seit `1.2.0` immer, standardmäßig nach `reports/Lint Report <datum>.md`, und gibt den Pfad aus; gedruckt werden nur Abschnitte mit Befunden, `--full` druckt alles, `--json` schreibt nichts[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- **Typen:** `types list`, `types describe`
|
||||
- **Konfidenz:** `confidence decay`, `confidence init-base`
|
||||
- **Veröffentlichung:** `publish` - zählt seit `1.5.0` nur noch Dateien, die eine Entscheidung tragen: Pfade unter `work/` und generierte Dateien (`kb/index.md`, `kb/log.md`, `kb/provenance.md`, jede `INDEX.md`) werden committet und gepusht, aber nicht gegen die Schwelle gezählt; die Weigerungszeile weist beide Gründe getrennt aus[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]. Siehe [[Mass-Update Gate]]
|
||||
- **Budget:** `budget status`, `budget reset` - Obergrenze seit `1.2.0` 60 Aufrufe je Sitzung; ein Aufruf, der über `_util.fail()` abgelehnt wurde, bekommt seinen Slot zurück und bleibt trotzdem in `recent`, damit der Loop-Breaker ihn sieht[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]. Siehe [[Iteration and Cost Limits]]
|
||||
- **Versionierung:** `version bump`, `version check` - `bump` schreibt die Stack-Version in die
|
||||
Wurzeldatei `VERSION` und verweigert einen `MAJOR`-Sprung ohne Migrationsdokument, sofern er
|
||||
nicht ausdrücklich mit `--no-migration "<Begründung>"` gesetzt wird; `check` ist der einzige
|
||||
Befehl, der einen Netzaufruf machen darf - ohne Schlüssel, mit Timeout und injizierbarem
|
||||
Fetch, damit Tests nie ein Netz
|
||||
berühren[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- **Migration:** `migrate list`, `migrate status`, `migrate verify`, `migrate done`,
|
||||
`migrate baseline` - `status` bildet das Intervall `(kb_version, VERSION]` aufsteigend,
|
||||
`done` verweigert jede Version, die nicht das nächste Glied ist, `verify` vergleicht zwei
|
||||
Revisionen des Korpus über `corpus_diff` mit Zählungen statt Mengen, `baseline` setzt einer
|
||||
Instanz ohne `.wikitool-kb.json` ihren
|
||||
Startwert[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Siehe
|
||||
[[KB Migration]]
|
||||
- **Distribution:** `dist export` - erzeugt das Release-Artefakt und legt den Stempel
|
||||
`.wikitool-release.json` hinein[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- **Diagnose:** `doctor` - enthält einen `kb-version`-Check[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
sowie seit `1.1.0` einen `personalization`-Check: `FAIL`, wenn `USER.md` oder `SOUL.md`
|
||||
fehlen, und ebenso, wenn eine der beiden noch die Sentinel-Zeile des Templates trägt - ein
|
||||
umbenanntes Template ist kein ausgefülltes. Siehe [[Personalization Plane]]
|
||||
sowie seit `1.8.0` einen `environment`-Check für [[ENVIRONMENT.md]]: `OK` bei fehlender wie
|
||||
bei ausgefüllter Datei, `WARN` allein bei einem umbenannten, nie ausgefüllten Template. Nie
|
||||
`FAIL` - die Datei ist optional, und ein `FAIL` machte sie durch die Hintertür verpflichtend[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].
|
||||
Siehe [[Optional Instance Context File]]
|
||||
- **Coverage:** CI führt die Tests seit `1.8.1` mit `pytest --cov` aus (Konfiguration
|
||||
`tools/.coveragerc`, nicht `pytest.ini` - coverage.py liest Letzteres nicht) und lädt den
|
||||
Bericht als Artefakt hoch, ohne Abbruchschwelle - siehe Messen vor Schwelle
|
||||
- **Dokumentation:** `docs verify` - überprüft, dass jeder CLI-Befehl in `tools/CONTRACT.md` dokumentiert ist und umgekehrt, dass jedes Verzeichnis unter `kb/` eine `COLLECTION.md` hat und kein Verzeichnis außerhalb hat, dass jeder Stage-Contract existiert, und dass keine Ignorierungsregel Inhalte unter `raw/` oder `kb/` stille ausschließen würde (oder stille generierte Ausgabe unter `reports/` committen würde)
|
||||
- **Anweisungen:** `instructions sync`, `instructions verify`, `instructions list` - publiziert jede `instructions/<name>/SKILL.md` als **Kopie** in `.agents/skills/` (nativ gelesen von GitHub Copilot, Codex CLI und Mistral Vibe) und `.claude/skills/` (erforderlich für Claude Code, das nichts anderes liest), und überprüft die Schicht: Anweisungen gegen ihre Schema, Skill-Frontmatter gegen das, das der Harness liest, jede veröffentlichte Kopie Byte-für-Byte gegen ihre Quelle, und alle Anweisungen, auf die nichts verweist
|
||||
|
||||
## Details
|
||||
|
||||
Das Tool verwendet eine Python-Paketstruktur mit einer Typer-basierten CLI. Wichtige Module sind:
|
||||
- `cli.py` - Haupteinstiegspunkt des Befehls
|
||||
- `commands/new_page.py` - Seiten-Gerüstbau
|
||||
- `commands/xref.py` - Cross-Reference-Verwaltung
|
||||
- `commands/search.py` + `search/` - Abfrage, aufgeteilt in einen Backend-agnostischen Kern (`SearchBackend`-Protokoll, Frontmatter-Prädikate, Reciprocal Rank Fusion) und ein Backend (`ripgrep.py`), sodass ein Vektor-Backend ein neues Modul statt einer Umschrift ist
|
||||
- `commands/index_build.py` - Katalog-Map und Shard-Neuerstellung
|
||||
- `commands/instructions_cmd.py` - Anweisungs-Schicht: publish, verify, list
|
||||
- `commands/provenance_cmd.py` - Herkunfts-Verfolgung
|
||||
- `commands/log_append.py` - Log-Eintrag-Formatierung
|
||||
- `commands/lint.py` - Strukturvalidierung
|
||||
- `commands/git_publish.py` - Git-Operationen
|
||||
- `commands/skills_sync.py` - `.agents/skills/` <-> `.claude/skills/`-Spiegelung und Verifikation[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]
|
||||
|
||||
Die Provenance-Remediation-Session fügte drei wichtige operative Verbesserungen hinzu:
|
||||
|
||||
- Neue Provenance-Befehlsgruppe (`sources coverage`, `sources trace`, `sources rebuild-index`) für Raw-zu-Source- und Source-zu-Page-Nachverfolgbarkeit.
|
||||
- Erweiterte Lint-Überprüfungen für nicht abgedeckte Raw-Dateien, beschädigte Raw-Verweise, fehlende Provenance-Marker und Citation/Frontmatter-Drift.
|
||||
- Wrapper-Verhaltensbehebung, sodass relative Pfadargumente vom Arbeitsverzeichnis des Aufrufers (Repository-Root-Verwendung) statt von `tools/` aufgelöst werden.
|
||||
|
||||
Der Bash-Wrapper unter `tools/wikitool` aktiviert die Python venv und exportiert `PYTHONPATH`, um `chemenu` importierbar zu halten, ohne cwd zu ändern.
|
||||
|
||||
Für die Migrationsprüfung kamen zwei Module dazu: `corpus_diff.py` vergleicht zwei Revisionen
|
||||
des Korpus und `kb_state.py` liest und schreibt `.wikitool-kb.json`. Beide Seiten des Vergleichs
|
||||
müssen dieselbe Vorstellung von „Seite" haben: Ein erster Lauf meldete 13 entfernte Seiten, die
|
||||
keine waren, weil die historische Seite jede `.md` unter `kb/` zählte und die
|
||||
Arbeitsbaum-Seite `iter_kb_pages` benutzte. Ein gemeinsames `kb_scan.is_page_path` löst das
|
||||
auf[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
`kb_scan.extract_wikilinks()` liefert bewusst ein Set. Das ist die richtige Form für `lint`, das
|
||||
fragt, ob ein Verweis auflöst - und die falsche für eine Migrationsprüfung, die fragt, ob einer
|
||||
verschwunden
|
||||
ist[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-09-01 - `2.0.0` (Commit `9a7abe6`, 730 Tests grün): das Python-Paket heißt `chemenu`
|
||||
statt `wiki_tools`, **das Kommando bleibt `wikitool`**. Der Import-Name eines Pakets ist ein
|
||||
flacher globaler Namensraum ohne Kollisionsschutz, `wiki_tools` war dafür zu generisch;
|
||||
Distributionsname, Import-Name und Kommandoname sind drei unabhängige Dinge, und ein
|
||||
abweichender Kommandoname ist verbreitete Praxis. Unverändert bleiben damit auch
|
||||
`.wikitool-release.json`, `.wikitool-kb.json` und die `WIKITOOL_*`-Variablen - sie gehören
|
||||
zum Kommando, nicht zum Paket. Verzeichnet in `CHANGES.md` (`2.0.0`), Kontext in [[Chemenu]].
|
||||
- 2026-08-31 - `1.8.0` (Commit `a243a4a`): `doctor` bekommt den `environment`-Check,
|
||||
`dist export` liefert `ENVIRONMENT.md.template` über die Root-Allowlist aus, und `docs verify`
|
||||
prüft das zugehörige Ignore-Muster in beide Richtungen - die Datei muss ignoriert sein, ihr
|
||||
Template darf es nicht[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- 2026-08-31 - `1.7.1` (Commit `31c9b81`, Tag `v1.7.1`, 702 Tests grün, 7 neue): die Testsuite
|
||||
läuft seither gegen eine absichtlich leere Maschine, Gitea-Issue #8 (`prio/1`). Eine
|
||||
autouse-Fixture in `conftest.py` setzt `HOME` je Test in dessen `tmp_path`, git-Konfiguration
|
||||
auf `/dev/null` und löscht die Tool- sowie die git-Identitätsvariablen; `WIKI_TRACE_DIR` bleibt
|
||||
als einziges gesetzt, weil zwei Telemetrie-Tests einen geschriebenen Trace behaupten. Anlass
|
||||
war `default_author()`, das per `git config user.name` die globale Konfiguration des Aufrufers
|
||||
las - vier Tests hingen nacheinander daran, zwei davon geschrieben, nachdem das Issue offen
|
||||
war. Die Wirkung ist nicht am grünen Lauf belegt (die Suite war unter der gehärteten Umgebung
|
||||
schon vorher grün), sondern an der Gegenprobe: dieselbe Funktion antwortet ohne Isolierung mit
|
||||
dem globalen git-Namen, mit Isolierung `None`. 702 Tests in vier Umgebungen -
|
||||
Entwickler-Shell, vergiftet, `env -i`, CI[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31].
|
||||
Siehe [[Ambient Environment Dependency]] und [[Structural Enforcement over Documented Rule]]
|
||||
- 2026-08-31 - `1.6.0` (Commit `ce03749`, 689 Tests grün, 11 neue): drei Symptome mit einer
|
||||
Ursache, Gitea-Issue #18 (`prio/1`). `xref_link_source` schrieb nur die Zielseiten, nie die
|
||||
eigenen Arrays der Source-Seite - die waren nach `new source` unerreichbar. Das von
|
||||
`xref add` dort geschriebene `related:` deklariert `types/source.md` nicht, und
|
||||
`strip_frontmatter_ref()` räumte nur deklarierte Felder, also konnte `xref remove` es nicht
|
||||
entfernen. Seither schreibt `link-source` beide Richtungen, `xref add` prüft beide Seiten
|
||||
vorab und lehnt ein undeklariertes Feld ab, `xref remove` fegt Reste. Der Beleg für die
|
||||
Inversenbeziehung war eine Concept-Seite, die byteidentisch aus `xref remove` plus
|
||||
`xref link-source` zurückkam[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]. Siehe [[Command Round-Trip Integrity]]
|
||||
- 2026-08-31 - `1.5.1` (Commit `bb4123b`): `cite add` löschte jeden Inhalt hinter dem
|
||||
Fußnotenblock, weil `split_cite_block()` alles von der Überschrift bis Dateiende als Block
|
||||
nahm und daraus nur die Zitatdefinitionen behielt; `cite sync` und `rename` teilten den Pfad,
|
||||
und eine nur hinter dem Block referenzierte Fußnote wäre von `cite sync` als verwaist
|
||||
gelöscht worden. Da `xref add` am Dateiende anhängt, entschied allein die Reihenfolge beider
|
||||
Kommandos über den Bestand der Querverweise. 8 Seiten mit 74 Zeilen standen in dieser
|
||||
Position; `cite sync --all` normalisierte elf Seiten auf 0 (Gitea-Issue #17, `prio/1`)[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
Siehe [[Command Round-Trip Integrity]] und [[Green Suite Blind Spot]]
|
||||
- 2026-08-31 - `1.5.0` (Commit `3166c31`, 9 Dateien, 678 Tests grün): zwei Kalibrierungen aus
|
||||
einer Beobachtung, nicht aus einem Issue. `publish` nimmt generierte Dateien aus der
|
||||
Gate-Zählung heraus - `is_generated()` kannte die Liste und `GATE_EXEMPT_PREFIXES`/
|
||||
`counted_files()` boten den Mechanismus, verbunden waren beide nie -, und das
|
||||
Kalibrierungsband für einen komplexen Multi-Tool-Workflow steigt in `run_budget.py` von
|
||||
15-25 auf 20-35 Aufrufe. Beides ist an realen Läufen gemessen: drei Ingest-Changesets
|
||||
(14 → 9, 16 → 9, 11 → 5 gezählte Dateien) und vier Sitzungszähler aus
|
||||
`tools/.wikitool_session/budget.json` (30, 29, 26, 24 Aufrufe). Schwelle 10 und
|
||||
Budget-Obergrenze 60 blieben unverändert[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- 2026-08-31 - Gitea-Issues #12 und #13 behoben (`1.2.0`, Commit `40adbb7`): Komma-Escape und Append-Semantik in `parse_list()`, Budget-Erstattung für abgelehnte Aufrufe, Obergrenze 60 und der immer geschriebene Lint-Report. Der End-to-End-Test deckte einen zweiten Defekt auf: `dump_frontmatter` schreibt Listen im Flow-Stil, `_format_scalar` entschied das Quoting aber über eine Round-Trip-Probe auf Dokumentebene, wo ein Komma gewöhnlich ist - innerhalb von `[...]` ist es ein Indikator. Behoben in `frontmatter_io.py` über `_round_trips_as_string(text, flow=True)` und einen `_quote()`-Helper, der sich vom Dumper eine einelementige Flow-Sequenz geben lässt und die Klammern abstreift, weil ein blanker Plain-Scalar aus `safe_dump` einen `...`-Dokumentende-Marker mitbringt. Bestehende Ausgabe blieb unverändert. 658 Tests grün, auch in der gehärteten Umgebung, nachdem zwei neue Tests `WIKI_AUTHOR` selbst setzen[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-31 - Gitea-Issue #14 geschlossen (`1.4.0`, Commit `dbe2f73`, 9 Dateien, 674 Tests
|
||||
grün): `touch` bekommt `--set`/`--add`/`--remove`. Der Schnitt blieb bewusst eng - die
|
||||
Dateiverschiebung bleibt zweistufig (`git mv`, dann `touch --set raw_files=…`), `raw rename`
|
||||
wurde als Issue #16 (`prio/2`, `size/S`) abgespalten. `_coerce_set_value`, `_parse_set_fields`
|
||||
und `_check_raw_files_exist` wanderten aus `new_page.py` nach `commands/_util.py`, damit
|
||||
`touch --set` den Komma-Defekt aus Issue #12 nicht am ersten Tag erbt. Als Nebenbefund fiel
|
||||
eine Testfalle: ein direkt aufgerufener Typer-Callback bekommt für jedes ausgelassene Argument
|
||||
ein `OptionInfo`-Objekt, worauf drei neue Optionen sieben Aufrufstellen in `test_touch.py`
|
||||
brachen; die Tests laufen jetzt über einen `_touch(**overrides)`-Helper[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]
|
||||
- 2026-08-31 - Zuvor offene Lücke (Gitea-Issue #14): kein Befehl schreibt `raw_files:` auf einer bestehenden Seite. `touch` deckt die Felder ab, die die Seite beschreiben, `xref` die Seiten-Referenz-Arrays; `raw_files:` zeigt auf einen Pfad und ist keines von beidem. Vorgeschlagen sind `sources relink` oder ein `raw rename`, das `git mv` und jede referenzierende Source-Seite in einem Schritt erledigt. Siehe [[Detect-Repair Asymmetry]][^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-30 - Befehlsgruppen `version` und `migrate` sowie `dist export` ergänzt; Stack- und
|
||||
KB-Version werden seither in getrennten Dateien geführt. Zwei Tests, die die Autor-Ermittlung
|
||||
über `git config user.name` prüfen sollten, hingen unbemerkt an der globalen git-Konfiguration
|
||||
der ausführenden Maschine und fielen im ersten CI-Lauf; behoben in den Tests, nicht durch eine
|
||||
git-Identität für CI[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- 2026-08-05 - Wechsel von `skills sync`/`verify` vom Kopieren von Skill-Verzeichnissen zu relativen Symlinks (Claude Codes eigene Dokumentation bestätigt, dass es symlinked Skill-Ordner folgt) - ein Symlink kann niemals veralten, im Gegensatz zu einer Kopie.
|
||||
- 2026-08-04 - Befehle `skills sync`/`skills verify` hinzugefügt, um `.agents/skills/` in `.claude/skills/` für Claude-Code-Kompatibilität zu spiegeln, als Teil des Aufteilens von AGENTS.md-Workflows in diskrete Skills[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-03 - Deterministische Provenance-Befehlsgruppe hinzugefügt und Wrapper-Pfadverhalten während der Conversation-Ingest/Provenance-Remediation-Arbeit gehärtet.
|
||||
- 2026-08-03 - Seite während der Einspeisung der Codex-Analyse erstellt
|
||||
- 2026-08-02 - Tool referenziert in wikitool-Lint-Verbesserungen (Log-Eintrag)
|
||||
- 2026-07-26 - Anfängliche Implementierung als Teil der Wiki-Infrastruktur
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[AGENTS.md]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
- [[Semantic Lint Automation]]
|
||||
- [[Session Orientation]]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[KB Stack Versioning]]
|
||||
- [[KB Migration]]
|
||||
- [[Personalization Plane]]
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
- [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
- [[Write-Once Frontmatter Fields]]
|
||||
- [[Denylist over Allowlist]]
|
||||
- [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
- [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[Command Round-Trip Integrity]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[Ambient Environment Dependency]]
|
||||
- [[Structural Enforcement over Documented Rule]]
|
||||
- [[Optional Instance Context File]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
|
||||
[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
|
||||
[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
Reference in New Issue
Block a user