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,52 @@
|
||||
# kb/entities/ - Collection Contract
|
||||
|
||||
Concrete things that exist: a project, a deployed system, a CLI tool, a technology, a person or
|
||||
an organization. If it can be pointed at, it is an entity.
|
||||
|
||||
**Quality goal:** pointability + currency - a reader should come away knowing what the thing
|
||||
is, where it actually is, and whether that is still true. An entity page that describes a
|
||||
system correctly but names no host, path, version or status has not earned its keep.
|
||||
|
||||
Inherits [kb/CONTRACT.md](../CONTRACT.md) - naming, tone, linking, provenance and confidence
|
||||
are defined there and are not restated here.
|
||||
|
||||
## Types offered
|
||||
|
||||
`entity` (`tools/wikitool types describe entity`). The `entity_type:` field selects the area:
|
||||
|
||||
| Area | Holds |
|
||||
|------|-------|
|
||||
| `projects/` | Codebases and initiatives, named after their repository or common name |
|
||||
| `systems/` | Deployed and running systems, given a descriptive name |
|
||||
| `tools/` | CLI and desktop tools, named as the tool names itself |
|
||||
| `technologies/` | Protocols, languages, formats, in their standard spelling and capitalization |
|
||||
| `people/` | People and organizations, by full name or common handle |
|
||||
|
||||
These are areas, not collections: they inherit this contract and carry no `COLLECTION.md`.
|
||||
|
||||
## Per-area emphasis
|
||||
|
||||
- **Projects** - purpose, status, language/stack, owner, repository, dependencies on other
|
||||
projects and systems, architectural decisions.
|
||||
- **Systems** - purpose, components, dependencies, configuration locations, deployment,
|
||||
operational status, monitoring.
|
||||
- **Technologies** - purpose, use cases, trade-offs, version compatibility, which projects and
|
||||
systems use it.
|
||||
- **Tools** - purpose, installation, usage, notable options, which projects use it.
|
||||
- **People** - role, affiliation, and the projects or decisions they are connected to. Nothing
|
||||
personal beyond what the source states.
|
||||
|
||||
## Outbound linking
|
||||
|
||||
An entity links to the technologies it uses, the systems it runs on, the projects that depend
|
||||
on it, and the concepts it implements.
|
||||
|
||||
An entity that mentions a concept without linking it is incomplete; the concept page is where
|
||||
the *why* lives, and the entity page should not restate it.
|
||||
|
||||
## What does not belong here
|
||||
|
||||
- A pattern, protocol, architecture or decision - those are concepts, even when only one entity
|
||||
uses them.
|
||||
- A page about a source document - that is a `source` page in `kb/sources/`.
|
||||
- Singular naming is required: `ha-core.md`, not `ha-cores.md`.
|
||||
@@ -0,0 +1,103 @@
|
||||
<!-- Generated by `wikitool index rebuild`. Do not hand-edit. -->
|
||||
|
||||
# kb/entities/ - Index
|
||||
|
||||
72 page(s). Regenerated by `wikitool index rebuild`.
|
||||
|
||||
## Personen
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[Andrej Karpathy]] | person | KI-Forscher, der das grundlegende LLM-Wiki-Muster geprägt und damit die Methodik der Wissenskompilierung etabliert hat. | 2026-08-29 |
|
||||
| [[E3DC GmbH]] | person | Deutscher Hersteller von Energiespeichersystemen für Wohn- und Gewerbegebäude. | 2026-08-29 |
|
||||
| [[Rohit Gupta]] | person | Urheber von agentmemory, einem persistenten Speicher für KI-Coding-Agenten mit über 20000 GitHub-Stars. | 2026-08-29 |
|
||||
| [[Vannevar Bush]] | person | Amerikanischer Ingenieur und Wissenschaftsadministrator, der 1945 das Memex-Konzept ersann: ein persönlicher, kuratierter Wissensspeicher mit assoziativen Dokumentpfaden. | 2026-08-29 |
|
||||
|
||||
## Projekte
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[andybalholm-edl]] | project | Go-basierte EDL-Bibliothek für die Kommunikation mit eingebetteten Geräten. | 2026-08-29 |
|
||||
| [[BCDModule]] | project | Go-Modul, das die Entscheidungslogik für die Batterieladung umsetzt. | 2026-08-29 |
|
||||
| [[Chemenu]] | project | Persoenliches IT-Wissenswiki, gepflegt von LLM-Agenten; seit 1.0.0 versioniert, seit 1.1.0 Personalization Plane, seit 1.8.0 ENVIRONMENT.md, seit 2.0.0 unter dem Namen Chemenu (vorher llm-wiki-test1) mit dem Python-Paket chemenu | 2026-09-01 |
|
||||
| [[goresponsiveness]] | project | Go-Werkzeug zur Messung von Anwendungsleistung und Responsiveness. | 2026-08-29 |
|
||||
| [[ha-core]] | project | Kern-Integrationsbibliothek für Home-Assistant-E3DC-Systeme; stellt die E3DC-Kommunikationsprotokolle und den Home-Assistant-Integrationscode bereit. | 2026-08-29 |
|
||||
| [[hacs-e3dc]] | project | Home Assistant Custom Component zur Überwachung von E3DC-Energiesystemen. | 2026-08-29 |
|
||||
| [[hacs-integration-blueprint]] | project | Home-Assistant-Automatisierungs-Blueprints für das E3DC-Energiemanagement. | 2026-08-29 |
|
||||
| [[llm-wiki-skills]] | project | Plattformübergreifende LLM-Wiki-Skills von yugasun | 2026-08-29 |
|
||||
| [[plugnburn-edl]] | project | Go-basiertes EDL-Werkzeug zur Firmware-Programmierung eingebetteter Geräte. | 2026-08-29 |
|
||||
| [[wiki-skills]] | project | Umsetzung der Wiki-Skills für Claude Code von kfchou | 2026-09-01 |
|
||||
| [[wiki-skills-vanillaflava]] | project | Referenzimplementierung plattformübergreifender LLM-Wiki-Skills | 2026-09-01 |
|
||||
|
||||
## Systeme
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[AGENTS.md]] | system | Kontrollebene des LLM-Wikis: Invarianten, Dateibenennung, Routing, Gates, seit 1.1.0 Personalization und seit 1.8.0 der Environment-Abschnitt; erreicht Claude Code nur ueber den Import in CLAUDE.md | 2026-08-31 |
|
||||
| [[CLAUDE.md]] | system | Datei, die Claude Code beim Sitzungsstart laedt; importiert AGENTS.md/USER.md/SOUL.md und seit 1.8.0 ENVIRONMENT.md, traegt selbst keine Regeln | 2026-09-01 |
|
||||
| [[E3DC]] | system | Deutsches Heim-Energiespeichersystem, das Solarstromerzeugung mit Lithium-Batteriespeicher für Eigenverbrauch und Notstrom verbindet. | 2026-08-29 |
|
||||
| [[ENVIRONMENT.md]] | system | Optionale, gitignorete Root-Datei: Harness, Skills, MCP-Server, Connectoren, Remotes und CI-Ort eines Checkouts; doctor meldet sie, scheitert aber nie an ihr | 2026-08-31 |
|
||||
| [[Memex]] | system | Vannevar Bushs Konzept eines Wissensmanagementsystems von 1945 mit assoziativen Pfaden und Hypertext; geistiger Vorläufer moderner Wikis. | 2026-08-29 |
|
||||
| [[Tolkien Gateway]] | system | Von Fans erstelltes Wiki mit Tausenden verlinkten Seiten zum Tolkien-Legendarium; Beispiel für den Aufbau einer persönlichen Wissensbasis durch schrittweise Anhäufung. | 2026-08-29 |
|
||||
|
||||
## Technologien
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[acpi-cpufreq]] | technology | Linux-Kerneltreiber für die CPU-Frequenzskalierung von Prozessoren nach dem ACPI-Standard. | 2026-08-29 |
|
||||
| [[amd-pstate]] | technology | Linux-Kerneltreiber für das Power Management von AMD-Prozessoren über die CPPC-Schnittstelle; löst acpi-cpufreq ab. | 2026-08-29 |
|
||||
| [[Arch Linux]] | technology | Schlanke Rolling-Release-Linux-Distribution, genutzt als Basis für CI/CD-Paketbau-Umgebungen und Infrastruktur. | 2026-08-29 |
|
||||
| [[Disk Encryption]] | technology | Schutz ruhender Daten über das Kernelmodul dm-crypt und die LUKS-Schlüsselverwaltung zur transparenten Verschlüsselung von Speichergeräten unter Linux. | 2026-08-29 |
|
||||
| [[Docker]] | technology | Container-Plattform als Industriestandard für CI/CD-Infrastruktur, mit BuildKit-Daemon und entfernter Docker-Verwaltung über SSH. | 2026-09-01 |
|
||||
| [[Gitea]] | technology | Selbst gehosteter Git-Dienst auf docker-host.example.net; bietet Repository-Verwaltung und CI/CD über Gitea Actions mit Act Runner. | 2026-08-29 |
|
||||
| [[Gitea Actions]] | technology | CI/CD-Workflow-Plattform, in Gitea integriert; fuehrt YAML-Workflows ueber den Act Runner aus, samt Release-Pipeline, belegten paths-ignore-Filtern und einem nightly.yml-Drift-Check, dessen schedule-Ausloesung seit 2026-09-01 (Run 90) belegt ist | 2026-09-01 |
|
||||
| [[Go]] | technology | Quelloffene Programmiersprache von Google für Systemprogrammierung und Backend-Dienste, mit eingebauter Nebenläufigkeit über Goroutines und Channels. | 2026-08-29 |
|
||||
| [[GRUB]] | technology | GNU-Bootloader für Linux-Systeme; übernimmt das Laden des Kernels und die Boot-Konfiguration. | 2026-08-29 |
|
||||
| [[Home Assistant]] | technology | Quelloffene Plattform zum Aufbau von Hausautomationssystemen mit Gerätesteuerung und Automatisierung. | 2026-08-29 |
|
||||
| [[iii Engine]] | technology | Kern-Engine, die die Infrastruktur für persistente Speicher von KI-Agenten und die Umsetzung des Wissensgraphen bereitstellt. | 2026-08-29 |
|
||||
| [[Kernel PM Governors]] | technology | Power-Management-Module des Linux-Kernels, die die CPU-Frequenz dynamisch nach Systemlast und Leistungsanforderung skalieren. | 2026-08-29 |
|
||||
| [[Linux Kernel]] | technology | Quelloffener Betriebssystemkern; verwaltet Systemressourcen und Hardware-Abstraktion, einschließlich Power Management und CPU-Frequenzskalierung. | 2026-08-29 |
|
||||
| [[LVM]] | technology | Device-Mapper-Framework unter Linux für flexible Datenträgerverwaltung mit Logical Volumes, Snapshots und Online-Vergrößerung jenseits klassischer Partitionierung. | 2026-08-29 |
|
||||
| [[MQTT]] | technology | Leichtgewichtiges Publish-Subscribe-Protokoll für die Kommunikation von IoT-Geräten über TCP/IP-Netze. | 2026-08-28 |
|
||||
| [[OPC UA]] | technology | Industrieprotokoll für sichere, standardisierte Gerätekommunikation mit semantischer Datenmodellierung. | 2026-08-29 |
|
||||
| [[Python]] | technology | Interpretierte Programmiersprache, weit verbreitet für Backend-Dienste und Hausautomationsplattformen. | 2026-08-29 |
|
||||
| [[Rust]] | technology | Systemprogrammiersprache, die Speichersicherheit ohne Garbage Collection bietet. | 2026-08-29 |
|
||||
| [[Wine GE]] | technology | Eigene Wine-Builds von GloriousEggroll mit zusätzlichen Patches und Optimierungen für bessere Kompatibilität von Windows-Anwendungen und -Spielen unter Linux. | 2026-08-29 |
|
||||
| [[Wine-Staging]] | technology | Experimenteller Entwicklungszweig von Wine mit ungetesteten Patches und Funktionen vor der Aufnahme upstream; dient als Erprobungsfeld für neue Wine-Funktionalität. | 2026-08-29 |
|
||||
|
||||
## Werkzeuge
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[Act Runner]] | tool | 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 | 2026-09-01 |
|
||||
| [[Agent Memory]] | tool | Persistenter Speicher für KI-Coding-Agenten; setzt Wissensgraph- und Lifecycle-Management-Muster um. | 2026-08-29 |
|
||||
| [[AUR]] | tool | Gemeinschaftlich gepflegtes Repository für Arch-Linux-Pakete, gebaut aus PKGBUILD-Quellbeschreibungen. | 2026-09-01 |
|
||||
| [[Aura]] | tool | In Rust geschriebener AUR-Helper mit sicherer Paketverwaltung und eigenem Build-Verzeichnis für Arch Linux. | 2026-08-29 |
|
||||
| [[awesome-llm-wiki]] | tool | Externes GitHub-Repository (gavischneider/awesome-llm-wiki) mit verschiedenen Umsetzungen und Mustern für LLM-Wiki-Skills | 2026-08-29 |
|
||||
| [[Bottles]] | tool | Grafisches Werkzeug zur Verwaltung von Wine-Präfixen und zum Ausführen von Windows-Anwendungen unter Linux mit mehreren Runtimes. | 2026-08-29 |
|
||||
| [[ChatGPT]] | tool | KI-Chatbot von OpenAI mit Datei-Upload für RAG-artige Dokumentabfragen, ohne dauerhafte Wissensanhäufung oder Querverweis-Synthese. | 2026-08-29 |
|
||||
| [[Claude Code]] | tool | 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. | 2026-08-31 |
|
||||
| [[Codex CLI]] | tool | Kommandozeilenschnittstelle für das Coding-Modell Codex | 2026-08-29 |
|
||||
| [[Dataview]] | tool | Obsidian-Plugin für Abfragen über das Frontmatter von Seiten; erzeugt dynamische Tabellen, Listen und strukturierte Sichten auf Wiki-Inhalte. | 2026-08-29 |
|
||||
| [[farzaa gist]] | tool | Externes Gist (farzaa/c35ac0cfbeb957788650e36aabea836d) mit Ideen und Umsetzungen zum LLM-Wiki-Muster | 2026-08-29 |
|
||||
| [[gdeploy]] | tool | In Go geschriebenes CLI-Werkzeug zur Automatisierung von Anwendungs-Deployment, Konfigurationsverwaltung und Infrastruktur. | 2026-08-29 |
|
||||
| [[Gitea MCP Server]] | tool | 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 | 2026-08-31 |
|
||||
| [[GitHub Copilot]] | tool | 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). | 2026-08-29 |
|
||||
| [[GPG]] | tool | GNU Privacy Guard zum Verschlüsseln und Signieren; unverzichtbar für die Prüfung von AUR-Paketen und kryptografische Operationen unter Arch Linux. | 2026-08-29 |
|
||||
| [[Lutris]] | tool | Quelloffene Spieleplattform für Linux mit einheitlicher Oberfläche für Installation und Start von Spielen über die Wine-Kompatibilitätsschicht. | 2026-08-29 |
|
||||
| [[makepkg]] | tool | Build-Werkzeug von Arch Linux; wertet PKGBUILD-Dateien aus, um Quellcode zu übersetzen und installierbare Pakete zu erzeugen. | 2026-08-29 |
|
||||
| [[Marp]] | tool | Markdown-basiertes Format für Foliensätze; erzeugt Präsentationen direkt aus Markdown, mit Themes und PDF-Export. | 2026-08-29 |
|
||||
| [[Mistral Vibe]] | tool | CLI-Coding-Agent von Mistral AI | 2026-08-29 |
|
||||
| [[NotebookLM]] | tool | RAG-basiertes KI-Wissenswerkzeug von Google; beantwortet Fragen aus hochgeladenen Dokumenten, ohne Wissen dauerhaft anzuhäufen. | 2026-08-29 |
|
||||
| [[Obsidian]] | tool | Markdown-basierte Notizanwendung mit bidirektionaler Verlinkung, Wissensgraph-Darstellung und Plugin-Ökosystem für persönliche Wikis. | 2026-08-29 |
|
||||
| [[Obsidian Web Clipper]] | tool | Browser-Erweiterung, die Webartikel als Markdown direkt in Obsidian-Vaults ablegt, für die schnelle Aufnahme in Wissens-Workflows. | 2026-08-29 |
|
||||
| [[OpenAI Codex]] | tool | Coding-Modell von OpenAI, das GitHub Copilot antreibt; versteht, erzeugt und ändert Code in mehreren Sprachen. | 2026-08-29 |
|
||||
| [[OpenCode]] | tool | KI-Coding-Assistent für Codeerzeugung und -analyse; kann das LLM-Wiki-Muster für dauerhafte Wissensverwaltung umsetzen. | 2026-08-29 |
|
||||
| [[pascalandy schema]] | tool | Von der Community beigesteuertes Wiki Schema (Global) aus pascalandys Kommentar in Farzas Gist, mit alternativer Tag-Taxonomie (area/kind/topic/status/pty) | 2026-08-29 |
|
||||
| [[Pi]] | tool | Assistenz-Agent von Inflection AI; kann das LLM-Wiki-Muster wie andere LLM-Agenten umsetzen. | 2026-08-29 |
|
||||
| [[Proton]] | tool | Wine-basierte Kompatibilitätsschicht von Valve; lässt Windows-Spiele über Steam unter Linux laufen, mit optimierter DirectX-Übersetzung. | 2026-08-29 |
|
||||
| [[qmd]] | tool | Lokale Suchmaschine für Markdown-Dateien mit hybrider BM25-Vektor-Suche und LLM-Reranking. | 2026-08-29 |
|
||||
| [[Steam]] | tool | Valves Plattform für digitalen Spielevertrieb und Spielebibliothek auf dem PC. | 2026-08-29 |
|
||||
| [[wikitool]] | tool | Deterministisches CLI fuer alle mechanischen Wiki-Operationen; seit 2.0.0 liegt es im Python-Paket chemenu, das Kommando heisst weiterhin wikitool | 2026-09-01 |
|
||||
| [[Wine]] | tool | Kompatibilitätsschicht, die Windows-API-Aufrufe nach POSIX übersetzt und Windows-Anwendungen unter Linux, BSD und macOS ohne Virtualisierung oder Emulation ausführt. | 2026-08-29 |
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: [researcher, ai, machine-learning, open-source]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Three-Layer Architecture, Knowledge Compounding, RAG]
|
||||
sources: [Source - LLM Wiki v2, Source - LLM Wiki Pattern]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: KI-Forscher, der das grundlegende LLM-Wiki-Muster geprägt und damit die Methodik der Wissenskompilierung etabliert hat.
|
||||
---
|
||||
# Andrej Karpathy
|
||||
|
||||
**Typ:** Person (AI Researcher, Engineer)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Andrej Karpathy ist ein KI-Forscher und Ingenieur, bekannt für seine Arbeiten zu großen Sprachmodellen und neuronalen Netzen. Er erstellte das ursprüngliche [LLM Wiki Gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), das das Grundmuster für den Aufbau persönlicher Wissensdatenbanken mit LLMs etablierte.
|
||||
|
||||
Seine ursprüngliche Einsicht - "stop re-deriving, start compiling" - bildet die Kernphilosophie des LLM-Wiki-Musters. Das Muster adressiert die Limitierungen traditioneller RAG-Systeme durch die Einführung einer persistenten Wiki-Schicht, die Wissen im Laufe der Zeit akkumuliert und verstärkt.
|
||||
|
||||
## Kernbeiträge
|
||||
|
||||
- **Ursprüngliches LLM Wiki Gist:** Grundlegendes Musterdokument, das die dreischichtige Architektur (Rohdatenquellen, Wiki, Schema) etabliert
|
||||
- **Kernphilosophie:** Wissen sollte einmal kompiliert und aktuell gehalten werden, nicht bei jeder Abfrage neu abgeleitet
|
||||
- **Operatives Framework:** Definierte Ingest-, Query- und Lint-Operationen
|
||||
- **Architektur:** Etablierte das Rohdaten - Wiki - Schema-Schichting
|
||||
|
||||
## Philosophie
|
||||
|
||||
> "The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask."
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erstellt:** [[LLM Wiki Pattern]] (original)
|
||||
- **Erweitert durch:** [[Rohit Gupta]] (LLM Wiki v2)
|
||||
- **Definiert:** [[Three-Layer Architecture]]
|
||||
- **Verwandt mit:** [[Knowledge Compounding]]
|
||||
- **Im Kontrast zu:** [[RAG]] (traditioneller Ansatz)
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Three-Layer Architecture]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[RAG]]
|
||||
- [[Rohit Gupta]]
|
||||
- [[Agent Memory]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Deutscher Hersteller von Energiespeichersystemen für Wohn- und Gewerbegebäude.
|
||||
---
|
||||
# E3DC GmbH
|
||||
|
||||
**Typ:** person
|
||||
|
||||
## Beschreibung
|
||||
|
||||
E3DC GmbH ist ein deutsches Unternehmen, das Hybrid-Wechselrichter-Systeme herstellt, die Solarstromerzeugung mit Lithium-Ionen-Batteriespeichern kombinieren. Ihre Systeme sind über Home-Assistant-Integrationen wie ha-core in die Hausautomation integriert.
|
||||
|
||||
## 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,49 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: [developer, ai, memory, open-source]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [iii Engine, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Urheber von agentmemory, einem persistenten Speicher für KI-Coding-Agenten mit über 20000 GitHub-Stars.
|
||||
---
|
||||
# Rohit Gupta
|
||||
|
||||
**Typ:** Person (Developer, Open Source Contributor)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Rohit Gupta ist der Schöpfer von [agentmemory](https://github.com/rohitg00/agentmemory), ein persistentes Speichermodul für KI-Coding-Agenten mit über 20.000 Stars auf GitHub. Er ist ein Schlüsselbeitragender zur Entwicklung des LLM-Wiki-Musters, insbesondere durch seine Arbeit an agentmemory, die Andrej Karpathys ursprüngliches Konzept mit produktionserprobten Verbesserungen erweitert.
|
||||
|
||||
Seine Arbeit an agentmemory und das zugehörige [LLM Wiki v2](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)-Dokument bietet praktische Erkenntnisse darüber, was funktioniert und was nicht, wenn man Wissensmanagementsysteme in großem Maßstab implementiert.
|
||||
|
||||
## Kernbeiträge
|
||||
|
||||
- **agentmemory:** Persistentes Speichermodul für KI-Coding-Agenten (20K+ Stars)
|
||||
- **LLM Wiki v2:** Erweiterung des ursprünglichen LLM-Wiki-Musters mit Produktionslektionen
|
||||
- **Wichtige Innovationen:** Speicher-Lebenszyklus-Management, Knowledge Graphs, Event-Driven Automation, Hybrid Search
|
||||
|
||||
## Projekte
|
||||
|
||||
- **[agentmemory](https://github.com/rohitg00/agentmemory)** - Persistentes Speichermodul für KI-Agenten
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erstellt:** [[Agent Memory]]
|
||||
- **Verwendet:** [[iii Engine]]
|
||||
- **Erweitert Arbeit von:** [[Andrej Karpathy]] (LLM Wiki original)
|
||||
- **Trägt bei zu:** [[LLM Wiki Pattern]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Agent Memory]]
|
||||
- [[iii Engine]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Andrej Karpathy]]
|
||||
- [[Memory Lifecycle]]
|
||||
- [[Knowledge Graph]]
|
||||
- [[Event-Driven Automation]]
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: [history, computer-science, knowledge-management, '1945']
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memex, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: "Amerikanischer Ingenieur und Wissenschaftsadministrator, der 1945 das Memex-Konzept ersann: ein pers\xF6nlicher, kuratierter Wissensspeicher mit assoziativen Dokumentpfaden."
|
||||
---
|
||||
# Vannevar Bush
|
||||
|
||||
**Typ:** Person (American Engineer and Science Administrator)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Vannevar Bush (1890-1974) war ein amerikanischer Ingenieur, Erfinder und Wissenschaftsadministrator, der bedeutende Beiträge zur Entwicklung von Analogrechnern und zur Organisation der Forschung in den USA leistete. Er ist vor allem für seinen 1945er Artikel "As We May Think" bekannt, in dem er das Konzept der **Memex** vorschlug.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Vollständiger Name:** Vannevar Bush
|
||||
- **Geboren:** 11. März 1890
|
||||
- **Gestorben:** 28. Juni 1974
|
||||
- **Nationalität:** Amerikanisch
|
||||
- **Fachbereiche:** Engineering, Computer Science, Science Administration
|
||||
- **Bekannte Arbeiten:** "As We May Think" (1945)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erfand:** [[Memex]]
|
||||
- **Inspiration für:** [[LLM Wiki Pattern]] (geistiger Vorläufer)
|
||||
|
||||
## Beiträge
|
||||
|
||||
### Memex-Konzept (1945)
|
||||
Bushs berühmtester Beitrag zum Wissensmanagement ist das **Memex** (Memory Extender), beschrieben in seinem 1945er Artikel "As We May Think" in Atlantic Monthly. Das Memex war gedacht als:
|
||||
|
||||
- Ein persönliches, kuratiertes Wissensspeicher
|
||||
- Mit assoziativen Verbindungen zwischen Dokumenten
|
||||
- Privat und aktiv vom Benutzer kuratiert
|
||||
- Wo Verbindungen zwischen Dokumenten genauso wertvoll sind wie die Dokumente selbst
|
||||
|
||||
### Wissenschaftliche Führung
|
||||
- Direktor des Office of Scientific Research and Development (OSRD) während des Zweiten Weltkriegs
|
||||
- Übersicht über das Manhattan-Projekt und andere Kriegsforschung
|
||||
- Ratgeber bei der Schaffung der National Science Foundation
|
||||
- Präsident des MIT (1923-1932)
|
||||
|
||||
## Verbindung zum LLM-Wiki-Muster
|
||||
|
||||
Laut dem Artikel [[LLM Wiki Pattern]] war Bushs Memex-Vision:
|
||||
- Näher im Geist zum LLM-Wiki-Muster als zu dem, was das Web wurde
|
||||
- Privat und aktiv kuratiert (vs. öffentliches, passiv konsumiertes Web)
|
||||
- Geschätzte assoziative Verbindungen zwischen Dokumenten
|
||||
- **Das, was er nicht lösen konnte**: Wer macht die Wartung? Das LLM übernimmt das.
|
||||
|
||||
## Zitate
|
||||
|
||||
> "The human mind... operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain."
|
||||
> — Vannevar Bush, "As We May Think"
|
||||
|
||||
## Historie
|
||||
|
||||
- [1945] - Veröffentlicht "As We May Think" mit Beschreibung von Memex
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Muster-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Memex]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Compounding]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-Modul, das die Entscheidungslogik für die Batterieladung umsetzt.
|
||||
---
|
||||
# BCDModule
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
BCDModule ist eine Go-Bibliothek, die Algorithmen zur Batterieladungsentscheidung für Energiemanagementsysteme bereitstellt, die in der E3DC-Integration verwendet wird, um Batterie-Lade-/Entlade-Zyklen zu optimieren.
|
||||
|
||||
## 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,208 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, llm, knowledge-base]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: [Personalization Plane, Issue Label Scheme, Optional Instance Context File]
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, 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 - 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]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: mixed
|
||||
summary: Persoenliches IT-Wissenswiki, gepflegt von LLM-Agenten; seit 1.0.0 versioniert, seit 1.1.0 Personalization Plane, seit 1.8.0 ENVIRONMENT.md, seit 2.0.0 unter dem Namen Chemenu (vorher llm-wiki-test1) mit dem Python-Paket chemenu
|
||||
---
|
||||
# Chemenu
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Chemenu ist das persönliche IT-Wissens-Wiki-Repository, das Gegenstand der Skill-Umstrukturierung ist, die in den Copilot Skill Restructure Instructions beschrieben wird[^s-copilot-skill-restructure-instructions]. Es hat derzeit eine monolithische `AGENTS.md`-Datei (~30KB), die fünf Workflows (INGEST, QUERY, LINT, CREATE, UPDATE), das Frontmatter-Schema des Wikis, Entity/Concept-Typ-Tabellen, Provenance/Citation-Regeln, Naming-Konventionen und eine Konfidenz-Scoring-Formel beschreibt[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
**Der Name.** Bis zum 2026-09-01 hieß das Projekt `llm-wiki-test1` - ein Arbeitstitel mit einer
|
||||
Ordnungszahl darin, kein Name. **Chemenu** ist die deutsche Wikipedia-Schreibweise des
|
||||
altägyptischen Namens von Hermopolis Magna, Hauptkultort des Thoth und „Stadt der Acht" der
|
||||
Ogdoade. Der Ort, nicht der Gott: die Persona dieser Instanz heißt Thoth, und Chemenu ist das,
|
||||
worin sie schreibt. Ältere Quellen, Logeinträge und Transkripte führen weiterhin den alten
|
||||
Namen - sie sind Aufzeichnungen dessen, was zu ihrer Zeit galt.
|
||||
|
||||
Das Repository hat bereits ein deterministisches CLI, `tools/wikitool` (Python, unterstützt durch das Paket `tools/chemenu/`), das alle mechanischen Operationen handhabt. Die Aufgabe des LLMs ist Prosa und Urteilsfindung, während `wikitool` strukturelle Korrektheit garantiert[^s-copilot-skill-restructure-instructions]. Die Skill-Umstrukturierung zielt darauf ab, die prozeduralen Workflows von den deklarativen Regeln zu trennen, Workflow-Abschnitte in diskrete Skills in `.agents/skills/` zu extrahieren, während Schema und Richtlinien in der Root `AGENTS.md` bleiben.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Persönliche IT-Wissensbasis
|
||||
- **Status:** Aktiv - Skill-Umstrukturierung abgeschlossen 2026-08-04
|
||||
- **Verantwortlich:** Torben
|
||||
- **Repository:** `torben/chemenu` auf gitea.nehmer.net; bis 2026-09-01 `torben/llm-wiki-test1`
|
||||
- **Architektur:** Dreilagig: raw/ (Quelle), wiki/ (Wissen), tools/ (deterministisches CLI)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet:** [[wikitool]] für deterministische Operationen
|
||||
- **Enthält:** [[AGENTS.md]] (Wiki-Betriebssystem)
|
||||
- **Vorlagen:** [[wiki-skills]], [[wiki-skills-vanillaflava]], [[llm-wiki-skills]]
|
||||
- **Zielplattformen:** [[GitHub Copilot]], [[Claude Code]], [[Codex CLI]], [[Mistral Vibe]]
|
||||
- **verwendet:** [[Personalization Plane]]
|
||||
- **verwendet:** [[Issue Label Scheme]]
|
||||
- **verwendet:** [[Optional Instance Context File]]
|
||||
|
||||
## Details
|
||||
|
||||
Die Repository-Struktur umfasst:
|
||||
- `raw/` - Unveränderliche Rohmaterialien (Artikel, Dokumente, Notizen, Assets)
|
||||
- `kb/` - Von LLM gepflegtes Wissen (Entities, Concepts, Quellen, Vergleiche, Katalog, Log)
|
||||
- `types/` - Die globale Typ-Oberfläche: eine Typ-Spezifikation pro Artefakt-Typ
|
||||
- `tools/` - Deterministische CLI-Tools (Kommando `wikitool`, Paket `chemenu`)
|
||||
- `instructions/` - Agent-gerichtete Prozedur: flache Anweisungen plus Skill-Verzeichnisse
|
||||
- ~~`.agents/skills/` - Kanonischer Ort für die 5 extrahierten Workflow-Skills (erstellt
|
||||
2026-08-04), gespiegelt zu `.claude/skills/` für Claude Code via `tools/wikitool skills sync`~~[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]
|
||||
Überwunden 2026-08-22: die Quelle der Skills wurde zu `instructions/<name>/` verschoben, und sowohl
|
||||
`.agents/skills/` als auch `.claude/skills/` wurden zu gitignorierten Kopien, die von
|
||||
`tools/wikitool instructions sync` veröffentlicht werden.
|
||||
|
||||
Die Umstrukturierung befasste sich mit Token-Ökonomie und Skalierungsgrenzen-Bedenken durch die Aufteilung der
|
||||
monolithischen AGENTS.md (745 Zeilen) in 5 diskrete Skills: `wiki-ingest`, `wiki-query`,
|
||||
`wiki-lint`, `wiki-manage` (CREATE+UPDATE zusammengefasst) und `wiki-status` (neu, nur-Lesezugriff) -
|
||||
finalisiert als 5, nicht das ursprünglich vorgeschlagene "wiki-create, wiki-update, optional wiki-status"[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
### Versionierung, CI und Releases
|
||||
|
||||
Seit 2026-08-30 ist der Stack versioniert und die CI-Pipeline in Betrieb. Der Zuschnitt folgt [[KB Stack Versioning]] und
|
||||
[[KB Migration]][^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
| Fakt | Datei | Geschrieben von |
|
||||
|---|---|---|
|
||||
| Stack-Version | `VERSION` | `wikitool version bump` |
|
||||
| Release-Stempel | `.wikitool-release.json` | `wikitool dist export` |
|
||||
| KB-Version | `.wikitool-kb.json` | `wikitool migrate done` |
|
||||
|
||||
Zwei Workflows unter `.gitea/workflows/`: `ci.yml` mit Tests, Version-Gate und Export-Smoke-Test,
|
||||
und `release.yml`, das bei einer Änderung an `VERSION` einen Tag setzt und ein
|
||||
`dist export`-Tarball samt `.sha256`
|
||||
veröffentlicht[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Beide
|
||||
laufen wegen `paths-ignore` nicht bei reinen Content-Änderungen; `kb/CONTRACT.md` ist von der
|
||||
Ausnahme absichtlich ausgenommen, weil es unter einem Content-Verzeichnis liegt, aber zum Stack
|
||||
gehört[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
Der Entwicklungsbaum war der erste Fall für `migrate baseline` und bekam `1.0.0`, weil er zwar
|
||||
älter als `.wikitool-kb.json` ist, sein Inhalt der Maschinerie aber nie
|
||||
hinterherhing[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Das
|
||||
Origin-Repository ist privat; Läufe werden über den [[Gitea MCP Server]] gelesen, und die
|
||||
offenen Ausbaustufen liegen als Gitea-Issues statt als Prosa in
|
||||
`TODO.md`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Seit
|
||||
2026-08-31 ist das nicht mehr nur eine Gewichtung, sondern der einzige Weg: `TODO.md` wurde
|
||||
gelöscht, ihr letzter substantieller Inhalt ging als Issue #15 nach Gitea, und offene Arbeit
|
||||
existiert nur noch als Issue mit Priorität und Größe nach dem
|
||||
[[Issue Label Scheme]][^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
### Personalization und Harness-Anbindung
|
||||
|
||||
Mit `1.1.0` bekam die Instanz eine [[Personalization Plane]]: `USER.md` hält fest, wer sie
|
||||
bedient, `SOUL.md`, wie sie klingt. Ausgeliefert werden nur die beiden `.template`-Dateien; die
|
||||
befüllten Fassungen bleiben in dieser Instanz, und `wikitool doctor` prüft sie über den
|
||||
`personalization`-Check. Die Persona heißt **Thoth** - gewählt passend zur
|
||||
ägyptischen Namensgebung des Stacks selbst; der Name
|
||||
ist eine Nutzerentscheidung, und das Template schlug bis `1.8.1` ausdrücklich keinen
|
||||
vor. Seit `2.0.0` nennt
|
||||
es Thoth als Startpunkt - der Repo-Name Chemenu ist Thoths Kultort, also gehören beide zusammen -
|
||||
ohne die Frage zu ersetzen: gefragt wird trotzdem, und ein anderer Name gewinnt. Verzeichnet in
|
||||
`CHANGES.md` (`2.0.0`).
|
||||
|
||||
Mit `1.1.1` kam [[CLAUDE.md]] dazu. Bis dahin erreichte [[AGENTS.md]] [[Claude Code]] nie,
|
||||
weil dieses Harness nur `CLAUDE.md` automatisch lädt, während [[Codex CLI]] und
|
||||
[[GitHub Copilot]] `AGENTS.md` nativ lesen. Jede Claude-Code-Sitzung lief bis dahin ohne
|
||||
Invarianten, Routing und Gate-Regeln, sofern der Agent die Datei nicht selbst öffnete.
|
||||
|
||||
## Allgemeine Hinweise (unbelegt)
|
||||
|
||||
Ab 2026-08-22 ist das Repository eine vierstufige Pipeline - `raw/` -> `types/` + `tools/` ->
|
||||
`kb/` -> `reports/` - mit `instructions/` und `AGENTS.md` daneben als Kontrollrahmen.
|
||||
Die Abfrage läuft durch `tools/wikitool search` anstelle des Katalogs, und
|
||||
`kb/index.md` ist eine Karte, die auf pro-Kollektion `INDEX.md` Shards verlinkt. Dies sind Eigenschaften des
|
||||
Repositorys selbst und keine Aussagen aus einer Rohdatenquelle; der Änderungsdatensatz ist
|
||||
`CHANGES.md`, und das Operationslog ist `kb/log.md`.
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-09-01 - `2.0.0` (Commit `9a7abe6`, 121 Dateien, 730 Tests grün): Rebranding von
|
||||
`llm-wiki-test1` auf **Chemenu** nach Gitea-Issue #3 - Repo-Rename, Produktname,
|
||||
Release-Artefakt (`chemenu-stack-<version>.tar.gz`), Release-Feed, und das Python-Paket
|
||||
`wiki_tools` → `chemenu` bei unverändertem Kommando `wikitool`. MAJOR nicht wegen einer
|
||||
Inhaltsmigration - `kb/` bleibt auf Shape `1.0.0`, der Bump trägt `--no-migration` - sondern
|
||||
weil der Update-Pfad bricht: das `update_url` in jeder älteren `.wikitool-release.json` zeigt
|
||||
auf den alten Repo-Pfad und lässt sich per Invariante 1 nicht von Hand reparieren. Die
|
||||
erste Einschätzung lautete `1.9.0` und wurde von Torben korrigiert; die Lücke in der Doku,
|
||||
die dazu führte - MAJOR ist dort als Inhaltsmigration statt als Kompatibilitätsbruch
|
||||
beschrieben - liegt als Issue #26. Verzeichnet in `CHANGES.md` (`2.0.0`).
|
||||
- 2026-08-31 - `1.8.1` (Commit `a243a4a`, Korrektur `2b7b3cb`): Test-Coverage wird in CI
|
||||
gemessen und als Artefakt ausgewiesen, ohne `--cov-fail-under` - siehe
|
||||
Messen vor Schwelle. Die Messung deckte einen `dist export`-Fehler auf: Coverage-Ausgabe
|
||||
wurde mitausgeliefert, weil `TOOLS_EXCLUDE_DIRS` nur Verzeichnisse prunet und zwei Drittel der
|
||||
Ausgabe als Dateien neben dem Code liegen
|
||||
- 2026-08-31 - `1.5.1` (Commit `bb4123b`) und `1.6.0` (Commit `ce03749`, 689 Tests grün):
|
||||
zwei Datenintegritätsdefekte, beide `prio/1`, beide von einem Ingest gefunden und am selben
|
||||
Tag geschlossen. `cite add` löschte Inhalt hinter dem Fußnotenblock (Issue #17), und die
|
||||
Referenz-Arrays einer Source-Seite waren unerreichbar, während `xref add` dort ein Feld
|
||||
schrieb, das `xref remove` nicht räumen konnte (Issue #18). Der Korpus wurde mit dem
|
||||
Werkzeug repariert: `cite sync --all` normalisierte elf Seiten, danach 0 Seiten mit Inhalt
|
||||
hinter dem Block. Der bleibende Befund über den beiden Fixes: beide Defekte lebten unter
|
||||
einer vollständig grünen Suite, weil nie ein Test das richtige Verhalten behauptet hatte -
|
||||
siehe [[Green Suite Blind Spot]][^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]
|
||||
- 2026-08-31 - `1.5.0` (Commit `3166c31`, 9 Dateien, 678 Tests grün): zwei nie gemessene
|
||||
Grenzen wurden an realen Läufen kalibriert, angestoßen von Torbens Beobachtung, dass drei
|
||||
gewöhnliche Ingests nacheinander am [[Mass-Update Gate]] stehen blieben. Generierte
|
||||
Dateien zählen seither nicht mehr gegen die Gate-Schwelle, und das Kalibrierungsband für
|
||||
komplexe Workflows steigt von 15-25 auf 20-35 `wikitool`-Aufrufe. Die Messwerte lagen
|
||||
bereits im Repository - in den Changesets der drei Ingests und in
|
||||
`tools/.wikitool_session/budget.json`[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- 2026-08-31 - `1.4.0` (Commit `dbe2f73`, 9 Dateien, 674 Tests grün): `touch --set/--add/--remove`
|
||||
schließt Gitea-Issue #14 und macht Felder reparierbar, die zuvor nur beim Anlegen schreibbar
|
||||
waren. Torben entschied dabei drei Punkte: Denylist statt Allowlist für die schreibbaren
|
||||
Felder, Ersetzen plus `--add`/`--remove` für Listenfelder, und einen engen Auslieferungsschnitt,
|
||||
der `raw rename` als Issue #16 (`prio/2`, `size/S`) abspaltet. Die Korpus-Seite
|
||||
[[Diff-Reviewable Agent Edits]], die den Defekt ausgelöst hatte, wurde damit im selben Lauf
|
||||
repariert[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]
|
||||
- 2026-08-31 - `1.2.1` (Commit `9fa70f3`, 5 Dateien): `TODO.md` gelöscht,
|
||||
`instructions/dev/issue-tracking.md` angelegt, sieben `prio/`- und `size/`-Labels auf allen
|
||||
zehn offenen Issues. PATCH, weil die Regel unter `instructions/dev/` liegt und keine
|
||||
ausgelieferte Instanz erreicht. In derselben Sitzung wurde Issue #11 mit dem Beleg
|
||||
geschlossen, dass `paths-ignore` greift; #14 und #15 wurden
|
||||
eröffnet[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]
|
||||
- 2026-08-31 - `1.2.0` (Commit `40adbb7`): Arraywerte mit Komma in `--set`, korrektes Flow-Quoting im Frontmatter, Budget-Erstattung für abgelehnte Aufrufe, Obergrenze 60 und ein `lint`, das seinen Reportpfad nennt. Danach `5426a6e` als Inhaltskorrektur: die beim Ingest vom 2026-08-30 umbenannte Rohdatei bekam ihren ursprünglichen Namen zurück[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-30 - Personalization Plane als Setup-Schritt ausgeliefert (`1.1.0`, Commit
|
||||
`6f54c31`), danach `CLAUDE.md` ergänzt, nachdem auffiel, dass die Kontrollebene Claude Code
|
||||
nie erreicht hatte (`1.1.1`, Commit `adfa220`)
|
||||
- 2026-08-30 - Stack-Versionierung, KB-Versionierung mit Migrationskette und die
|
||||
Gitea-Actions-Pipeline in Betrieb; `1.0.0` als Migrationsbasis gesetzt, `1.0.1` als erstes
|
||||
über die Pipeline veröffentlichtes Release mit Tarball und
|
||||
`.sha256`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- 2026-08-22 - Abfrage, Katalog-Sharding und die `instructions/`-Ebene eingeführt; Agent-seitige
|
||||
Verträge umbenannt zu `CONTRACT.md`. Verzeichnet in `CHANGES.md`.
|
||||
- 2026-08-04 - Skill-Umstrukturierung abgeschlossen: 5 Skills erstellt unter `.agents/skills/`, gespiegelt zu `.claude/skills/`, AGENTS.md geschlankt auf ~573 Zeilen, veröffentlicht bei Commit `ae2024d`[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[AGENTS.md]]
|
||||
- [[wikitool]]
|
||||
- [[Personalization Plane]]
|
||||
- [[Issue Label Scheme]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement 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]]
|
||||
- [[Optional Instance Context File]]
|
||||
|
||||
## 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]]
|
||||
[^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]]
|
||||
[^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-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-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]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-basierte EDL-Bibliothek für die Kommunikation mit eingebetteten Geräten.
|
||||
---
|
||||
# andybalholm-edl
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
andybalholm-edl ist eine Go-Bibliothek, die eine EDL-Protokoll-Implementierung für die Kommunikation mit eingebetteten Geräten und Mikrocontrollern bereitstellt und eine Grundlage für Geräteprogrammierungs- und Konfigurationsabläufe bildet.
|
||||
|
||||
## 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,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-Werkzeug zur Messung von Anwendungsleistung und Responsiveness.
|
||||
---
|
||||
# goresponsiveness
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
goresponsiveness ist ein in Go geschriebenes Performance-Test-Dienstprogramm, das Anwendungslatenz, Antwortzeiten und Durchsatz unter verschiedenen Lastbedingungen misst.
|
||||
|
||||
## 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,63 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [home-automation, e3dc, go, python]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [hacs-e3dc, hacs-integration-blueprint, E3DC, Home Assistant, Go, Python]
|
||||
sources: []
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: general
|
||||
summary: Kern-Integrationsbibliothek für Home-Assistant-E3DC-Systeme; stellt die E3DC-Kommunikationsprotokolle und den Home-Assistant-Integrationscode bereit.
|
||||
---
|
||||
# ha-core
|
||||
|
||||
**Typ:** Project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
ha-core scheint eine Kernkomponente für die Integrationierung von E3DC-Systemen in Home Assistant zu sein. Basierend auf der Verzeichnisstruktur im übergeordneten Repository ist dies wahrscheinlich ein Go- oder Python-Projekt, das grundlegende Funktionen für die Überwachung und Steuerung von E3DC-Energiespeichersystemen im Home-Assistant-Ökosystem bietet.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Kernintegrationsbibliothek für E3DC-Systeme
|
||||
- **Status:** Aktiv (aus Präsenz im Quellbaum abgeleitet)
|
||||
- **Sprache/Technik:** Go und/oder Python
|
||||
- **Verantwortlich:** Torben
|
||||
- **Repository:** Lokales Verzeichnis (ha-core/)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** [[Home Assistant]] Ökosystem
|
||||
- **Hängt ab von:** [[E3DC]] Systemen
|
||||
- **Verwandt mit:** [[hacs-e3dc]], [[hacs-integration-blueprint]]
|
||||
- **Verwendet:** [[Go]], [[Python]]
|
||||
|
||||
## Details
|
||||
|
||||
### Komponenten
|
||||
|
||||
Basierend auf der Repository-Struktur wahrscheinlich enthalten:
|
||||
- E3DC-Kommunikationsprotokolle
|
||||
- Datenmodelle für E3DC-Systeme
|
||||
- Home Assistant Integrationscode
|
||||
- Konfigurationsverwaltung
|
||||
|
||||
### Abhängigkeiten
|
||||
|
||||
- E3DC Hardware-/Softwareschnittellen
|
||||
- Home Assistant Integrations-Frameworks
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-25] - Entity-Seite erstellt als Teil des Initial-Wiki-Scaffolds
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[E3DC]]
|
||||
- [[Home Assistant]]
|
||||
- [[hacs-e3dc]]
|
||||
- [[hacs-integration-blueprint]]
|
||||
- [[Go]]
|
||||
- [[Python]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, Go, ha-core]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Home Assistant Custom Component zur Überwachung von E3DC-Energiesystemen.
|
||||
---
|
||||
# hacs-e3dc
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
hacs-e3dc ist eine Home Assistant Custom Component (HACS), die eine Integration für E3DC-Energiespeichersysteme bereitstellt. Sie ermöglicht die Überwachung des Batterieladestands, der Solarstromerzeugung und des Netzverbrauchs und unterstützt die Automatisierung von Energierouting und Optimierung.
|
||||
|
||||
## 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 erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, ha-core]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Home-Assistant-Automatisierungs-Blueprints für das E3DC-Energiemanagement.
|
||||
---
|
||||
# hacs-integration-blueprint
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
hacs-integration-blueprint stellt Home Assistant Integrations-Blueprints bereit - vorgefertigte Automatisierungsvorlagen für E3DC-Energiesysteme, einschließlich Multi-Sensor-Setup, Batterieoptimierung und Grid-Synchronisierungsautomatisierungen.
|
||||
|
||||
## 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 erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, skills, claude-code]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
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: Umsetzung der Wiki-Skills für Claude Code von kfchou
|
||||
---
|
||||
# wiki-skills
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das kfchou/wiki-skills-Projekt wird in den Copilot Skill Restructure Instructions als eine Vorgängerimplementierung im LLM-wiki-Ökosystem erwähnt[^s-copilot-skill-restructure-instructions]. Es zeigt ein funktionierendes Beispiel von sechs eigenständigen Claude-Code-Skills: `wiki-init`, `wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-update` und `wiki-audit`, von denen jede ihre eigene Datei ist und nur beim Aufruf geladen wird[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
Dies wird als das nächste 1:1-Strukturanalog zu dem beschrieben, was die Chemenu-Umstrukturierung anstrebt - es zeigt, dass das Muster von diskreten, aufrufbaren Skills gut für ein allgemeines IT-Wiki funktioniert, anstatt für ein persönliches Journal[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Claude Code Wiki-Skills Implementierung
|
||||
- **Status:** Extern, als Vorlage referenziert
|
||||
- **Verantwortlich:** kfchou
|
||||
- **Repository:** https://github.com/kfchou/wiki-skills (abgeleitet)
|
||||
- **Skills:** wiki-init, wiki-ingest, wiki-query, wiki-lint, wiki-update, wiki-audit
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Vorlage für:** [[Chemenu]] Skill-Umstrukturierung
|
||||
- **Ähnlich wie:** [[wiki-skills-vanillaflava]], [[llm-wiki-skills]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Die kfchou/wiki-skills Implementierung zeigt, dass das Muster von sechs eigenständigen Skills (eine für jeden Workflow) effektiv für ein allgemeines Wiki funktioniert. Jede Skill-Datei ist in sich geschlossen und wird nur bei Ausführung des entsprechenden Befehls geladen, was Vorteile bei der Kontextisolation bietet[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Chemenu]]
|
||||
- [[wiki-skills-vanillaflava]]
|
||||
- [[llm-wiki-skills]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go, gdeploy]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-basiertes EDL-Werkzeug zur Firmware-Programmierung eingebetteter Geräte.
|
||||
---
|
||||
# plugnburn-edl
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
plugnburn-edl ist ein Go-Sprachen-Tool für Embedded Device Line (EDL) Programmierung, das Firmware-Updates und Konfiguration von eingebetteten Geräten ermöglicht. Es ist Teil von Torbens Deployment- und Device-Management-Toolchain.
|
||||
|
||||
## 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 erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, skills, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Referenzimplementierung plattformübergreifender LLM-Wiki-Skills
|
||||
---
|
||||
# wiki-skills-vanillaflava
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das vanillaflava/wiki-skills-vanillaflava-Projekt wird in den Copilot Skill Restructure Instructions als die Referenzimplementierung für **plattformübergreifende Verteilung** erwähnt[^s-copilot-skill-restructure-instructions]. Es zeigt sechs Wiki-Skills, die gleichzeitig gegen Claude Code, Gemini CLI, Codex CLI und GitHub Copilot getestet werden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
Dieses Projekt ist besonders bemerkenswert für seinen plattformübergreifenden Ansatz, der ein gemeinsames Verzeichnis (`.agents/skills/`) verwendet, das in das native Skill-Verzeichnis jedes Tools verlinkt ist, was sicherstellt, dass alle vier Tools mit einer einzigen Quelle der Wahrheit synchronisiert bleiben[^s-copilot-skill-restructure-instructions]. Es bietet auch ein Installer-Muster, das die Chemenu-Umstrukturierung als Modell nutzen kann[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Plattformübergreifende LLM-Wiki-Skill-Verteilung
|
||||
- **Status:** Extern, als Referenzimplementierung referenziert
|
||||
- **Verantwortlich:** vanillaflava
|
||||
- **Repository:** https://github.com/vanillaflava/wiki-skills-vanillaflava (abgeleitet)
|
||||
- **Zieltools:** Claude Code, Gemini CLI, Codex CLI, GitHub Copilot
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Referenzimplementierung für:** [[Chemenu]] plattformübergreifende Ausrichtung
|
||||
- **Ähnlich wie:** [[wiki-skills]], [[llm-wiki-skills]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Das vanillaflava/wiki-skills-vanillaflava-Projekt wird als das kanonische Installationsziel hervorgehoben, das in tool-spezifische Verzeichnisse verlinkt wird[^s-copilot-skill-restructure-instructions]. Dieser Ansatz vermeidet die Verwaltung von vier Kopien derselben Skills und stellt Konsistenz über alle Ziel-LLM-Tools hinweg sicher.
|
||||
|
||||
Das Installer-Muster des Projekts dient als Modell für die Chemenu-Umstrukturierung und zeigt, wie ein kleines Skript das gemeinsame Verzeichnis einmal erstellen und in den nativen Skill-Pfad jedes Tools verlinken kann[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Chemenu]]
|
||||
- [[wiki-skills]]
|
||||
- [[llm-wiki-skills]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, skills, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Plattformübergreifende LLM-Wiki-Skills von yugasun
|
||||
---
|
||||
# llm-wiki-skills
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das yugasun/llm-wiki-skills-Projekt wird in den Copilot Skill Restructure Instructions als ein weiteres plattformübergreifendes Repository erwähnt, das explizit Claude Code, GitHub Copilot und Codex CLI anstrebt[^s-copilot-skill-restructure-instructions]. Es dient als Vorlage, die zeigt, dass das plattformübergreifende Skill-Verteilungsmuster praktikabel ist und aktiv von mehreren Implementierungen im LLM-wiki-Ökosystem genutzt wird[^s-copilot-skill-restructure-instructions]. Das eigentliche Repository befindet sich unter https://github.com/yugasun/llm-wiki-skills.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Plattformübergreifende LLM-Wiki-Skills
|
||||
- **Status:** Extern, als Vorlage referenziert
|
||||
- **Verantwortlich:** yugasun
|
||||
- **Repository:** https://github.com/yugasun/llm-wiki-skills (abgeleitet)
|
||||
- **Zieltools:** Claude Code, GitHub Copilot, Codex CLI
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Vorlage für:** [[Chemenu]] plattformübergreifende Ausrichtung
|
||||
- **Ähnlich wie:** [[wiki-skills]], [[wiki-skills-vanillaflava]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Das yugasun/llm-wiki-skills-Projekt wird neben vanillaflava/wiki-skills-vanillaflava zitiert als Beweis dafür, dass der plattformübergreifende Ansatz für LLM-Wiki-Skills an Fahrt im Ökosystem gewinnt[^s-copilot-skill-restructure-instructions]. Dies validiert die architektonische Entscheidung, mehrere LLM-Tools mit einem einzigen gemeinsamen Skill-Satz anzusprechen.
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Chemenu]]
|
||||
- [[wiki-skills]]
|
||||
- [[wiki-skills-vanillaflava]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: [schema, configuration, wiki, operating-system]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Naming Convention Conflict, CLAUDE.md, Denylist over Allowlist, ENVIRONMENT.md]
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis, Source - LLM Wiki v2, Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path 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: 'Kontrollebene des LLM-Wikis: Invarianten, Dateibenennung, Routing, Gates, seit 1.1.0 Personalization und seit 1.8.0 der Environment-Abschnitt; erreicht Claude Code nur ueber den Import in CLAUDE.md'
|
||||
---
|
||||
# AGENTS.md
|
||||
|
||||
**Typ:** system
|
||||
|
||||
## Beschreibung
|
||||
|
||||
AGENTS.md ist das Schema und Betriebssystem für die LLM Wiki. Es definiert die vollständige Methodik, wie die LLM die Wiki pflegt, Quellen verarbeitet, Anfragen beantwortet, Linting durchführt, Seiten erstellt und Konsistenz über alle Operationen hinweg aufrechterhält. Das Dokument etabliert den Grundsatz „Niemals ableiten. Immer kompilieren." und erzwingt eine strenge Trennung zwischen mechanischen Operationen (von wikitool gehandhabt) und semantischen Operationen (von der LLM gehandhabt).
|
||||
|
||||
Die Codex-Analyse identifizierte AGENTS.md als Bereitstellung einer deterministisch erzwungenen Grundlage, die vielen öffentlichen LLM-Wiki-Skills voraus ist. Sie kodifiziert Workflows (INGEST, QUERY, LINT, CREATE, UPDATE), Qualitätsstandards, Namenskonventionen, Seitenformate, Cross-Reference-Regeln und die drei-schichtige Architektur (Rohquellen, von LLM verwaltete Wiki, Schema).
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Kontrollebene für die Wiki: Invarianten, Dateibenennnung, Routing, Gates
|
||||
- **Status:** Aktiv, unter aktiver Entwicklung
|
||||
- **Version:** Umstrukturiert 2026-08-22 - siehe `CHANGES.md`
|
||||
- **Sprache/Technik:** Markdown, YAML-Frontmatter
|
||||
- **Standort:** Repo-Wurzel: `/AGENTS.md`
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Implementiert von:** [[wikitool]]
|
||||
- **Definiert:** [[LLM Wiki Pattern]], [[Three-Layer Architecture]], [[Workflow Orchestration]]
|
||||
- **Verwendet von:** Alle LLM-Operationen in dieser Wiki
|
||||
- **hat:** [[Naming Convention Conflict]]
|
||||
- **Analysiert in:** [[Source - LLM Improvements Codex Analysis]], [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- **verwandt mit:** [[CLAUDE.md]]
|
||||
- **begründet:** [[Denylist over Allowlist]]
|
||||
- **beschreibt:** [[ENVIRONMENT.md]]
|
||||
|
||||
## Hauptabschnitte
|
||||
|
||||
AGENTS.md enthält diese Hauptabschnitte:
|
||||
|
||||
- **Übersicht:** Grundsätze und Architektur
|
||||
- **Werkzeuge:** wikitool-CLI-Befehlsreferenz
|
||||
- **Provenienz und Zitation:** raw_files, Provenienz-Marker, Inline-Zitationen
|
||||
- **Entity-Typen:** Projects, Systems, Tools, Technologies, People
|
||||
- **Concept-Typen:** Architecture, Pattern, Protocol, Workflow, Decision, Problem
|
||||
- **Relationship-Typen:** depends on, uses, implements, extends, replaces, etc.
|
||||
- **Workflows:** ~~INGEST, QUERY, LINT, CREATE, UPDATE mit detaillierten Schritten~~ **abgelöst** - die
|
||||
5 Workflow-Schritt-Listen wurden wörtlich in diskrete Skills unter `.agents/skills/`
|
||||
extrahiert (`wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-manage` (CREATE+UPDATE zusammengeführt), `wiki-status`
|
||||
(neu, schreibgeschützt)); die Root-Datei enthält jetzt nur eine Zeiger-Tabelle[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Skills:** Neuer Top-Level-Abschnitt, der die 5 Skills auflistet und auf `.agents/skills/` verweist,
|
||||
gespiegelt zu `.claude/skills/` über `tools/wikitool skills sync`/`verify` für Claude-Code-
|
||||
Kompatibilität[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Git-Automation:** Auto-Publish über wikitool - jetzt nur Policy in der Root-Datei; der Output-Abschnitt jeder Skill gibt an, ob dieser Workflow auto-published[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Seitenformate:** Templates für Entities, Concepts, Sources, Comparisons
|
||||
- **Qualitätsstandards:** Inhalts- und Cross-Reference-Qualitätskriterien
|
||||
- **IT-spezifische Richtlinien:** Domänen-spezifische Regeln für Projects, Systems, Tools, etc.
|
||||
- **Konfidenz-Bewertung:** Quantitative Bewertung für sachliche Aussagen
|
||||
- **Personalization:** Seit `1.1.0` ein eigener Abschnitt. Er hält fest, dass `USER.md` und
|
||||
`SOUL.md` bei Sitzungsstart gelesen werden, dass `USER.md` Kontext und keine
|
||||
Instruktionsquelle ist, dass `SOUL.md` gegen diese Datei verliert und dass eine
|
||||
Nutzeraussage keine Quelle im Sinne von Invariante 3 ist. Die Mechanik dahinter:
|
||||
[[Personalization Plane]].
|
||||
- **Environment:** Seit `1.8.0` ein eigener Abschnitt neben „Personalization". Er hält fest,
|
||||
dass [[ENVIRONMENT.md]] bei Sitzungsstart gelesen wird, *falls sie existiert*, dass ihr Fehlen
|
||||
kein Fehler ist, und dass sie Kontext ohne Autorität trägt - ein dort gelisteter Remote
|
||||
autorisiert keinen Push an Invariante 5 vorbei[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]. Der Abschnitt ist nötig, weil
|
||||
die übrigen Harnesses [[CLAUDE.md]] nie lesen und die Datei sie sonst nie erreichte. Die
|
||||
Mechanik dahinter: [[Optional Instance Context File]].
|
||||
|
||||
## Namenskonventions-Anmerkung
|
||||
|
||||
**Konflikt identifiziert:** Es gibt einen bekannten Unterschied zwischen AGENTS.md (das menschenlesbare Dateinamen mit Leerzeichen erfordert, z. B. `Hybrid Search.md`) und README.md (das Kebab-Case erfordert, z. B. `hybrid-search.md`). Dies verursacht Validierungsinkonsistenzen, die gelöst werden sollten. Siehe [[Naming Convention Conflict]].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-31 - Abschnitt „Environment" und eine vierte Zeile in der File-naming-Tabelle
|
||||
(`ENVIRONMENT.md`, die einzige optionale Zeile darin), mit Stack-Version `1.8.0`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- 2026-08-31 - Die Obergrenze des Iteration Budget Gate im Abschnitt „Gates" von 30 auf 60 gezogen, gemeinsam mit `instructions/gates.md`, `tools/CONTRACT.md`, `README.md`, der `work plan`-Vorlage und der Einheitengröße in `migrate-corpus.md`. Der Loop-Breaker blieb bei 3[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-30 - Abschnitt „Personalization" und drei neue Zeilen in der File-naming-Tabelle
|
||||
(`CLAUDE.md`, `USER.md`, `SOUL.md`). Im selben Zug stellte sich heraus, dass diese
|
||||
Datei [[Claude Code]] nie erreicht hatte, weil dieses Harness ausschließlich [[CLAUDE.md]]
|
||||
lädt
|
||||
|
||||
- 2026-08-04 - Umstrukturiert: Die 5 Workflow-Abschnitte wurden in `.agents/skills/`-Skills extrahiert (`wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-manage`, `wiki-status`), Datei von 745 auf ~573 Zeilen reduziert, neue „## Skills"-Sektion und Git-Automation-Policy-only-Umschreiben[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-03 - Seite während der Aufnahme der Codex-Analyse erstellt
|
||||
- 2026-08-02 - Namenskonventionen auf menschenlesbare Titel mit Leerzeichen aktualisiert
|
||||
- 2026-07-26 - Mit Git-Automation- und Tooling-Abschnitten aktualisiert
|
||||
- 2026-07-25 - Initiales IT-fokussiertes Schema erstellt
|
||||
|
||||
## Analyseergebnisse
|
||||
|
||||
Die Sonnet-Analyse kam zu dem Ergebnis, dass AGENTS.md in drei Schlüsselbereichen konzeptionell bereits vor den meisten öffentlichen LLM-Wiki-Implementierungen ist:
|
||||
- **Provenienz und Zitation:** Die raw_files:, provenance:, [^s-llm-wiki-v2]-Marker und provenance.md-Rückwärtsindex bieten ungewöhnlich reife Coverage[^s-llm-improvements-sonnet-analysis]
|
||||
- **Deterministisches CLI:** wikitool handhabt mechanische Operationen präzise, anstatt an Ad-hoc-LLM-Scripts zu delegieren[^s-llm-improvements-sonnet-analysis]
|
||||
- **Konfidenz-Bewertung:** Die Verfallsformel und das Bewertungssystem existieren und funktionieren effektiv[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
Die Sonnet-Analyse identifizierte jedoch Lücken, wo AGENTS.md verbessert werden könnte:
|
||||
- Einen Abschnitt „Content Quality & Style" mit Seitenlängen-Schwellwerten und Style-Guide-Regeln hinzufügen[^s-llm-improvements-sonnet-analysis]
|
||||
- Session-Orientierung als obligatorischen ersten Schritt für alle Workflows einbauen[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Three-Layer Architecture]]
|
||||
- [[Naming Convention Conflict]]
|
||||
- [[Content Quality Control]]
|
||||
- [[Session Orientation]]
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - LLM Wiki v2]]
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[CLAUDE.md]]
|
||||
- [[Denylist over Allowlist]]
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[ENVIRONMENT.md]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File 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-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-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-llm-wiki-v2]: [[Source - LLM Wiki v2]]
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-09-01
|
||||
related: [AGENTS.md, ENVIRONMENT.md]
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: Datei, die Claude Code beim Sitzungsstart laedt; importiert AGENTS.md/USER.md/SOUL.md und seit 1.8.0 ENVIRONMENT.md, traegt selbst keine Regeln
|
||||
---
|
||||
# CLAUDE.md
|
||||
|
||||
**Typ:** System
|
||||
|
||||
## Beschreibung
|
||||
|
||||
`CLAUDE.md` ist die Datei, die [[Claude Code]] beim Sitzungsstart automatisch lädt. In
|
||||
[[Chemenu]] enthält sie **keine eigenen Regeln**, sondern ausschließlich Importe:
|
||||
`@AGENTS.md`, `@USER.md` und `@SOUL.md`, seit Stack-Version `1.8.0` zusätzlich
|
||||
`@ENVIRONMENT.md`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]. Ihr einziger Zweck ist, die Kontrollebene in ein
|
||||
Harness zu bringen, das sie sonst nicht sieht.
|
||||
|
||||
Der Grund ist eine Asymmetrie zwischen den Agenten-Werkzeugen: Codex CLI, GitHub Copilot und
|
||||
Mistral Vibe lesen [[AGENTS.md]] nativ, Claude Code nicht. Solange keine `CLAUDE.md` existierte,
|
||||
lief jede Claude-Code-Sitzung ohne Invarianten, Routing und Gate-Regeln - es sei denn, der Agent
|
||||
öffnete `AGENTS.md` von sich aus. Der Defekt blieb unbemerkt, weil er unter keinem anderen
|
||||
Harness auftrat.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Kontrollebene und Personalization Plane in Claude-Code-Sitzungen laden
|
||||
- **Status:** Aktiv, eingeführt mit Stack-Version `1.1.1`
|
||||
- **Version:** eingeführt 2026-08-30, Commit `adfa220`
|
||||
- **Sprache/Technik:** Markdown mit `@pfad`-Importsyntax
|
||||
- **Standort:** Repo-Wurzel: `/CLAUDE.md`
|
||||
- **Ausgeliefert:** ja, über die Root-Allowlist von `dist export`
|
||||
|
||||
## Beziehungen
|
||||
- **importiert:** [[AGENTS.md]]
|
||||
- **importiert:** [[ENVIRONMENT.md]]
|
||||
|
||||
## Details
|
||||
|
||||
### Warum keine eigenen Regeln
|
||||
|
||||
Eine Regel in `CLAUDE.md` wäre eine zweite Kopie einer bereits existierenden Regel und damit ein
|
||||
Verstoß gegen Invariante 8 von [[AGENTS.md]]. Sie wäre zugleich die am schnellsten driftende
|
||||
Kopie, weil nur ein einziges Harness sie liest: eine Abweichung fiele unter Codex oder Copilot
|
||||
gar nicht auf. Die Datei beschränkt sich deshalb auf Importe und die Begründung, warum sie
|
||||
existiert.
|
||||
|
||||
### Auslieferung
|
||||
|
||||
`CLAUDE.md` steht in `ROOT_FILES` von `tools/chemenu/commands/dist_cmd.py` und geht damit in
|
||||
jede Distribution - aus demselben Grund wie `.claude/settings.json`: eine ausgelieferte Instanz
|
||||
unter Claude Code hätte sonst denselben Defekt. Anders als bei `USER.md` und `SOUL.md` wird die
|
||||
Datei selbst ausgeliefert und nicht als Template, weil sie keinen persönlichen Inhalt trägt.
|
||||
|
||||
### Kein doctor-Check
|
||||
|
||||
Für `CLAUDE.md` gibt es bewusst keinen `wikitool doctor`-Check. Die Datei ist
|
||||
harness-spezifisch; eine Instanz, die ausschließlich unter Codex CLI betrieben wird, braucht sie
|
||||
nicht, und ein `FAIL` wäre dort schlicht falsch. Das unterscheidet sie von `USER.md` und
|
||||
`SOUL.md`, die jedes Harness liest und die deshalb geprüft werden - siehe
|
||||
[[Personalization Plane]].
|
||||
|
||||
### Verhalten während der Installation
|
||||
|
||||
Während des Setups einer frischen Instanz existieren `USER.md` und `SOUL.md` noch nicht; sie
|
||||
entstehen erst im Personalization-Schritt. Die Setup-Sitzung löst daher nur `@AGENTS.md` auf.
|
||||
Ob Claude Code einen fehlenden `@import` still überspringt oder meldet, ist **unbestätigt** und
|
||||
wurde in der einführenden Sitzung nicht geprüft.
|
||||
|
||||
Mit [[ENVIRONMENT.md]] wiegt diese offene Frage seit `1.8.0` schwerer: jene Datei ist optional
|
||||
und gitignored, ein unaufgelöster Import ist dort also kein Übergangszustand während des Setups,
|
||||
sondern der Normalfall[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]. Auch die Sitzung, die den Import einführte, hat das
|
||||
Verhalten nicht beobachtet - sie fügte ihn einer laufenden Sitzung hinzu, deren Kontext bereits
|
||||
geladen war.
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-30 - Angelegt mit Stack-Version `1.1.1` (Commit `adfa220`), nachdem aufgefallen war,
|
||||
dass `AGENTS.md` Claude Code nie erreicht hatte
|
||||
- 2026-08-03 - Die Seite [[AGENTS.md]] führte `CLAUDE.md` bereits als „analoge
|
||||
Konfigurationsdatei für Claude Code" - zu diesem Zeitpunkt gab es die Datei im Repo nicht
|
||||
|
||||
## Siehe auch
|
||||
- [[AGENTS.md]]
|
||||
- [[ENVIRONMENT.md]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^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]]
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: [energy-storage, solar, battery, home-automation]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [ha-core, hacs-e3dc, hacs-integration-blueprint, Home Assistant, E3DC GmbH]
|
||||
sources: []
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: general
|
||||
summary: Deutsches Heim-Energiespeichersystem, das Solarstromerzeugung mit Lithium-Batteriespeicher für Eigenverbrauch und Notstrom verbindet.
|
||||
---
|
||||
# E3DC
|
||||
|
||||
**Typ:** System
|
||||
|
||||
## Beschreibung
|
||||
|
||||
E3DC (Energy 3DC) ist ein deutscher Hersteller von Heimenergiespeichersystemen. Diese Systeme kombinieren Solarenergieerzeugung mit Batteriespeichern und ermöglichen es Hausbesitzern, die Eigennutzung von Solarenergie zu maximieren und Backupstrom bereitzustellen.
|
||||
|
||||
Das E3DC-System umfasst typischerweise:
|
||||
- Hybrid-Wechselrichter/Ladegerät
|
||||
- Lithium-Ionen-Batteriespeicher
|
||||
- Energiemanagementsystem
|
||||
- Überwachungs- und Steuerungsschnittstellen
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Heimenergiespeichersystem
|
||||
- **Hersteller:** [[E3DC GmbH]]
|
||||
- **Primärer Zweck:** Solarenergiespeicherung und -verwaltung
|
||||
- **Status:** Kommerzielles Produkt (aktiv)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Integriert mit:** [[Home Assistant]] über [[ha-core]], [[hacs-e3dc]]
|
||||
- **Verwendet von:** Hausbesitzer, Installateure, Systemintegratoren
|
||||
- **Verwandt mit:** [[hacs-integration-blueprint]]
|
||||
- **Teil von:** Heimenergiemanagement-Ökosystem
|
||||
|
||||
## Technische Details
|
||||
|
||||
### Kommunikation
|
||||
|
||||
E3DC-Systeme stellen typischerweise zur Verfügung:
|
||||
- Modbus-TCP-Schnittstelle
|
||||
- REST-API (variiert je nach Modell)
|
||||
- Lokale Web-Schnittstelle
|
||||
- Cloud-Konnektivität (optional)
|
||||
|
||||
### Gängige Modelle
|
||||
|
||||
- S10 E (10 kWh)
|
||||
- S10 E Mini
|
||||
- Verschiedene kommerzielle/industrielle Modelle
|
||||
|
||||
### Datenpunkte
|
||||
|
||||
Typische Überwachungsdaten umfassen:
|
||||
- Batterieladezustand (SOC)
|
||||
- Batterieenergie (Laden/Entladen)
|
||||
- PV-Erzeugung
|
||||
- Hausverbrauch
|
||||
- Netzbezug/-einspeisung
|
||||
- Systemstatus und Alarme
|
||||
|
||||
## Integrationsansätze
|
||||
|
||||
1. **Direktes Modbus** - Am zuverlässigsten, erfordert Netzwerkzugriff auf Wechselrichter
|
||||
2. **Lokale API** - HTTP-basiert, variiert je nach Firmware-Version
|
||||
3. **Cloud-API** - Erfordert Internet, kann Ratenlimits haben
|
||||
4. **Home-Assistant-Integration** - Über [[ha-core]] und [[hacs-e3dc]]
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-25] - Entity-Seite erstellt als Teil des anfänglichen Wiki-Gerüsts
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[E3DC GmbH]]
|
||||
- [[Home Assistant]]
|
||||
- [[ha-core]]
|
||||
- [[hacs-e3dc]]
|
||||
- [[hacs-integration-blueprint]]
|
||||
- [[Modbus]] Protocol
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [CLAUDE.md, Optional Instance Context File, AGENTS.md]
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Optionale, gitignorete Root-Datei: Harness, Skills, MCP-Server, Connectoren, Remotes und CI-Ort eines Checkouts; doctor meldet sie, scheitert aber nie an ihr'
|
||||
---
|
||||
# ENVIRONMENT.md
|
||||
|
||||
**Typ:** System
|
||||
|
||||
## Beschreibung
|
||||
|
||||
`ENVIRONMENT.md` hält fest, womit *ein bestimmter Checkout* arbeitet: welches Harness läuft,
|
||||
welche Skills publiziert sind, welche MCP-Server erreichbar sind, welche Connectoren dranhängen,
|
||||
wohin `publish` veröffentlicht und wo CI läuft. Es ist das dritte Root-Dokument der
|
||||
Sitzungsebene neben `USER.md` und `SOUL.md`, und es beantwortet die Frage, die die beiden offen
|
||||
lassen: `USER.md` sagt, *wer* die Instanz bedient, `SOUL.md`, *wie* sie klingt — womit sie
|
||||
arbeitet, sagte bis dahin niemand.
|
||||
|
||||
Das Problem war nicht Unkenntnis, sondern Wiederholung. Es sind über Wochen konstante Werte, die
|
||||
trotzdem jede Sitzung neu erfragte, weil nichts sie festhielt.
|
||||
|
||||
Die Datei ist **optional** und **gitignored**. Beides unterscheidet sie von der
|
||||
[[Personalization Plane]], deren Muster sie sonst übernimmt; die Verallgemeinerung steht unter
|
||||
[[Optional Instance Context File]].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Harness, Skills, MCP-Server, Connectoren, Remotes und CI-Ort eines Checkouts festhalten
|
||||
- **Status:** Aktiv, eingeführt mit Stack-Version `1.8.0`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- **Version:** eingeführt 2026-08-31, Commit `a243a4a`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- **Sprache/Technik:** Markdown, Abschnittsvorgabe über `ENVIRONMENT.md.template`
|
||||
- **Standort:** Repo-Wurzel: `/ENVIRONMENT.md` — gitignored, nie committet
|
||||
- **Ausgeliefert:** nur als `ENVIRONMENT.md.template`, über die Root-Allowlist von `dist export`
|
||||
- **Health-Check:** `wikitool doctor`, Prüfung `environment` — meldet, scheitert nie[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
|
||||
## Beziehungen
|
||||
- **importiert von:** [[CLAUDE.md]]
|
||||
- **implementiert:** [[Optional Instance Context File]]
|
||||
- **beschrieben in:** [[AGENTS.md]]
|
||||
|
||||
## Details
|
||||
|
||||
### Warum gitignored und nicht committet
|
||||
|
||||
Zwei Clones desselben Repos sind zwei verschiedene Umgebungen. Eine committete Fassung würde dem
|
||||
zweiten Clone Antworten geben, die falsch sind statt zu fehlen — und falsch wiegt hier schwerer,
|
||||
weil die Datei geglaubt wird. Das ist der Unterschied zu `USER.md`/`SOUL.md`, die committet sind
|
||||
und lediglich vom Export ausgenommen werden.
|
||||
|
||||
Der Preis ist, dass ein frischer Clone die Datei nie mitbringt; `instructions/bootstrap.md`
|
||||
Schritt 5 bietet das Anlegen deshalb ausdrücklich an.
|
||||
|
||||
### Das Ignore-Muster trennt Datei und Template
|
||||
|
||||
`.gitignore` trägt den verankerten Eintrag `/ENVIRONMENT.md`, der das `.template` bewusst nicht
|
||||
trifft. Das naheliegende `ENVIRONMENT.md*` würde beide schlucken, und `dist export` verlöre
|
||||
damit die Vorlage. `wikitool docs verify` prüft deshalb beide Richtungen: `ENVIRONMENT.md` steht
|
||||
in `REQUIRED_IGNORE_CANARIES`, `ENVIRONMENT.md.template` in `REQUIRED_TRACKED_PATHS`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].
|
||||
|
||||
### Kontext, keine Autorität
|
||||
|
||||
Die Datei beschreibt, was vorhanden ist, nicht, was erlaubt ist. Ein dort gelisteter Remote
|
||||
autorisiert kein `git push` — Invariante 5 von [[AGENTS.md]] führt weiter über
|
||||
`wikitool publish` —, ein gelisteter MCP-Server öffnet kein Gate, und nichts darin ist eine
|
||||
Quelle im Sinne von Invariante 3. Zugangsdaten gehören nicht hinein: die Datei liegt im Klartext
|
||||
im Arbeitsverzeichnis und in jedem Agenten-Kontext.
|
||||
|
||||
### Import statt Link
|
||||
|
||||
[[CLAUDE.md]] bindet sie als `@ENVIRONMENT.md` ein, nicht als Markdown-Link. Der Maßstab aus
|
||||
`instructions/CONTRACT.md` ist, *wann* die Entscheidung fällt: importieren, was nebenbei
|
||||
gebraucht wird, verlinken, was gezielt nachgeschlagen wird. Welcher MCP-Server welche Frage
|
||||
beantwortet, wird mitten in einer Aufgabe gebraucht — und eine Sitzung, die erst nachschlagen
|
||||
müsste, fragt stattdessen wieder den Nutzer, also genau die Kosten, die die Datei beseitigen
|
||||
soll.
|
||||
|
||||
Ob Claude Code einen unaufgelösten `@import` still überspringt oder meldet, ist weiterhin
|
||||
**unbestätigt** — dieselbe offene Frage, die [[CLAUDE.md]] seit `1.1.1` trägt. Sie wiegt hier
|
||||
schwerer, weil Abwesenheit bei dieser Datei der Dauerzustand sein darf und nicht nur ein
|
||||
Übergang während des Setups.
|
||||
|
||||
### Warum nicht unter `instructions/dev/`
|
||||
|
||||
Der Auftrag sprach von einer Erweiterung „im dev skillset". `instructions/CONTRACT.md` verbietet
|
||||
jedoch Referenzen von außerhalb auf `instructions/dev/`, weil sie beim `dist export` ins Leere
|
||||
zeigen würden; ein Link aus `CLAUDE.md` bräuchte die `dist:strip`-Marker-Konstruktion. Mehr
|
||||
Mechanik für weniger Reichweite — und der Inhalt betrifft auch reine Content-Sitzungen, die
|
||||
denselben Remote und denselben MCP-Server benutzen.
|
||||
|
||||
### Kein eigenes Kommando
|
||||
|
||||
Es gibt bewusst kein `wikitool environment`. Die Datei wird oft gelesen und selten geschrieben;
|
||||
ein Kommando dafür wäre Maschinerie ohne Abnehmer. Die Oberfläche besteht aus dem Template und
|
||||
zwei Instruktionsschritten (`bootstrap.md` Schritt 5, `setup-instance.md` Schritt 9).
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-31 — Angelegt mit Stack-Version `1.8.0` (Commit `a243a4a`), aus Gitea-Issue #24[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
|
||||
## Siehe auch
|
||||
- [[CLAUDE.md]]
|
||||
- [[AGENTS.md]]
|
||||
- [[Personalization Plane]]
|
||||
- [[Optional Instance Context File]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^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]]
|
||||
@@ -0,0 +1,98 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: [history, knowledge-management, concept, '1945']
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Vannevar Bush, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Vannevar Bushs Konzept eines Wissensmanagementsystems von 1945 mit assoziativen Pfaden und Hypertext; geistiger Vorläufer moderner Wikis.
|
||||
---
|
||||
# Memex
|
||||
|
||||
**Typ:** System (Konzeptionelles Wissensmanagement-System)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Memex (Memory Extender) ist ein konzeptionelles Wissensmanagement-System, das [[Vannevar Bush]] in seinem Artikel "As We May Think" von 1945 vorgeschlagen hat. Es stellt eine frühe Vision von Hypertext und persönlichem Wissensmanagement dar, die dem modernen Web vorausgeht und direkt das [[LLM Wiki Pattern]] inspiriert.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Vorgeschlagen von:** [[Vannevar Bush]]
|
||||
- **Jahr:** 1945
|
||||
- **Status:** Konzeptionell (wurde nie physisch gebaut)
|
||||
- **Einfluss:** Hypertext, World Wide Web, Persönliches Wissensmanagement
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erfunden von:** [[Vannevar Bush]]
|
||||
- **Geistiger Vorgänger von:** [[LLM Wiki Pattern]]
|
||||
- **Verwandtes Konzept:** [[Knowledge Compounding]]
|
||||
|
||||
## Konzept-Übersicht
|
||||
|
||||
Memex wurde als ein Gerät konzipiert, das:
|
||||
|
||||
### Kernfunktionen
|
||||
- Alle Bücher, Aufzeichnungen und Kommunikation eines Benutzers speichern
|
||||
- Sofortige Abrufbarkeit jedes Elements ermöglichen
|
||||
- **Assoziative Pfade** unterstützen - von Benutzern erstellte Links zwischen Dokumenten
|
||||
- Erstellung neuer Pfade durch Kombinieren bestehender ermöglichen
|
||||
- Eine permanente Aufzeichnung aller Hinzufügungen und Änderungen führen
|
||||
|
||||
### Assoziative Indexierung
|
||||
Anstelle hierarchischer oder alphabetischer Ordnung nutzte Memex **assoziative Indexierung**:
|
||||
- Elemente sind basierend auf benutzerdefinierten Beziehungen verlinkt
|
||||
- Pfade können wie Wege durch Wissen erstellt und verfolgt werden
|
||||
- Verbindungen zwischen Dokumenten sind gleichberechtigte Einträge
|
||||
|
||||
### Physische Beschreibung
|
||||
Bush stellte sich Memex als ein Gerät vor mit:
|
||||
- Schreibtischgroßem Format mit transparenten Bildschirmen
|
||||
- Mikrofilm-basierter Speicherung (hochmoderne Technologie der Zeit)
|
||||
- Tastatur und Schaltflächen zur Bedienung
|
||||
- Optischer Zeichenerkennung für die Eingabe
|
||||
|
||||
## Bezug zum LLM Wiki Pattern
|
||||
|
||||
Der [[LLM Wiki Pattern]]-Artikel vermerkt, dass Memex:
|
||||
- dem LLM-Wiki-Pattern näher im Geist steht als dem, was das Web wurde
|
||||
- privat und aktiv kuratiert ist (gegenüber dem öffentlichen, passiv konsumierten Web)
|
||||
- Verbindungen zwischen Dokumenten ebenso wertvoll erachtet wie die Dokumente selbst
|
||||
- **Das fehlende Stück:** Bush konnte nicht lösen, wer die Wartung übernehmen würde. Das LLM-Wiki-Pattern beantwortet dies mit LLMs, die die Verwaltung übernehmen.
|
||||
|
||||
## Vermächtnis und Einfluss
|
||||
|
||||
### Direkter Einfluss
|
||||
- Inspirierte Ted Nelsons **Xanadu**-Projekt (Hypertext)
|
||||
- Beeinflusste Tim Berners-Lees **World Wide Web**
|
||||
- Vorausgegangen für moderne **Wikis** und **Wissensgraphen**
|
||||
|
||||
### Moderne Realisierungen
|
||||
- Werkzeuge für persönliches Wissensmanagement (Obsidian, Roam Research etc.)
|
||||
- Das LLM-Wiki-Pattern selbst
|
||||
- Fan-Wikis wie [[Tolkien Gateway]]
|
||||
|
||||
## Vergleich mit modernen Systemen
|
||||
|
||||
| Merkmal | Memex (1945) | LLM Wiki Pattern | World Wide Web |
|
||||
|---------|--------------|-------------------|----------------|
|
||||
| Privat | Ja | Ja | Nein |
|
||||
| Kuratiert | Ja | Ja | Variabel |
|
||||
| Assoziative Links | Ja | Ja | Ja (Hypertext) |
|
||||
| Automatisierte Wartung | Nein | Ja (LLM) | Nein |
|
||||
| Sofortige Abrufbarkeit | Geplant | Ja | Ja |
|
||||
|
||||
## Historie
|
||||
|
||||
- [1945] - Konzept beschrieben in "As We May Think" (Atlantic Monthly)
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Pattern-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Vannevar Bush]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Tolkien Gateway]]
|
||||
@@ -0,0 +1,90 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: [wiki, fan-community, example, knowledge-base]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memex]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Von Fans erstelltes Wiki mit Tausenden verlinkten Seiten zum Tolkien-Legendarium; Beispiel für den Aufbau einer persönlichen Wissensbasis durch schrittweise Anhäufung.
|
||||
---
|
||||
# Tolkien Gateway
|
||||
|
||||
**Typ:** System (Fan-Wiki / Wissensdatenbank)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Tolkien Gateway ist ein Fan-erstelltes Wiki, das sich J.R.R. Tolkiens Legendarium widmet. Es dient als Beispiel im [[LLM Wiki Pattern]]-Artikel dafür, was durch inkrementelle Wissensakkumulation aufgebaut werden kann. Das Wiki enthält Tausende miteinander verlinkter Seiten, die Charaktere, Orte, Ereignisse, Sprachen und mehr abdecken.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Fan-Wiki / Wissensdatenbank
|
||||
- **Thema:** J.R.R. Tolkiens Werke (Lord of the Rings, Silmarillion, etc.)
|
||||
- **URL:** https://tolkiengateway.net/wiki/Main_Page
|
||||
- **Status:** Aktiv
|
||||
- **Umfang:** Tausende miteinander verlinkter Seiten
|
||||
- **Gepflegt von:** Gemeinschaft von Freiwilligen
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Beispiel für:** [[LLM Wiki Pattern]] (was persönlich mit LLM-Unterstützung gebaut werden kann)
|
||||
- **Verwandt mit:** [[Memex]] (ähnliche Vision von vernetztem Wissen)
|
||||
|
||||
## Funktionen
|
||||
|
||||
### Inhaltsabdeckung
|
||||
- Charaktere (Aragorn, Gandalf, Galadriel, etc.)
|
||||
- Orte (Middle-earth, Gondor, Rivendell, etc.)
|
||||
- Ereignisse (War of the Ring, Fall of Gondolin, etc.)
|
||||
- Sprachen (Sindarin, Quenya, Adûnaic, etc.)
|
||||
- Gegenstände (One Ring, Palantíri, etc.)
|
||||
- Rassen (Elves, Dwarves, Hobbits, Men, etc.)
|
||||
- Historische Zeitlinien
|
||||
|
||||
### Struktur
|
||||
- **Verlinkte Seiten:** Umfassende Querverweise zwischen Artikeln
|
||||
- **Kategorien:** Organisiert nach Thementyp
|
||||
- **Templates:** Standardisierte Seitenlayouts
|
||||
- **Quellenangaben:** Zitate aus Tolkiens Werken
|
||||
|
||||
## Bedeutung für das LLM-Wiki-Pattern
|
||||
|
||||
Der [[LLM Wiki Pattern]]-Artikel verwendet Tolkien Gateway als Beispiel:
|
||||
- "Denken Sie an Fan-Wikis wie Tolkien Gateway — Tausende miteinander verlinkter Seiten, die Charaktere, Orte, Ereignisse, Sprachen abdecken, von einer Gemeinschaft von Freiwilligen über Jahre hinweg gebaut."
|
||||
- "Sie könnten persönlich etwas Ähnliches während des Lesens aufbauen, wobei das LLM alle Querverweise und Wartung übernimmt."
|
||||
|
||||
Dies veranschaulicht die **kumulative Wirkung** der Wissensakkumulation:
|
||||
- Was eine Gemeinschaft Jahre kostet, kann persönlich mit LLM-Unterstützung erreicht werden
|
||||
- Das LLM übernimmt die mühsame Querverweisverwaltung und Wartung
|
||||
- Der Mensch konzentriert sich auf Lesen, Verständnis und Lenkung der Analyse
|
||||
|
||||
## Größe und Umfang
|
||||
|
||||
- **Seiten:** Tausende von Artikeln
|
||||
- **Zeitrahmen:** Über viele Jahre gebaut
|
||||
- **Mitwirkende:** Gemeinschaft von Tolkien-Enthusiasten
|
||||
- **Qualität:** Hochdetailliert, gut zitiert, umfassend
|
||||
|
||||
## Vergleich mit LLM-Wiki-Ansatz
|
||||
|
||||
| Aspekt | Tolkien Gateway | LLM Wiki Pattern |
|
||||
|--------|------------------|-------------------|
|
||||
| Schöpfer | Gemeinschaft | Einzelperson + LLM |
|
||||
| Zeit zum Aufbau | Jahre | Wochen/Monate |
|
||||
| Wartung | Gemeinschaftsanstrengung | LLM automatisiert |
|
||||
| Querverweise | Manuell | LLM übernimmt |
|
||||
| Umfang | Einzelne Domäne (Tolkien) | Jede Domäne |
|
||||
|
||||
## Historie
|
||||
|
||||
- [Unbekannt] - Tolkien Gateway gegründet
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Pattern-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[Memex]]
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [operating-system, linux, arch, package-management, encryption, storage]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [Docker, Gitea Actions, AUR, makepkg, Aura, GPG, Disk Encryption, LVM, Wine]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Schlanke Rolling-Release-Linux-Distribution, genutzt als Basis für CI/CD-Paketbau-Umgebungen und Infrastruktur.
|
||||
---
|
||||
# Arch Linux
|
||||
|
||||
**Typ:** Technology (Betriebssystem)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Arch Linux ist eine leichte, Rolling-Release-Linux-Distribution, bekannt für ihre Einfachheit, Minimalismus und benutzerorientiertes Design. In der CI/CD-Infrastruktur wird Arch Linux als Basis-Image für Szenario A (Arch-Paketbau) verwendet.
|
||||
|
||||
Arch Linux bietet hervorragende Unterstützung für Disk-Verschlüsselung (dm-crypt/LUKS), LVM und SSD-TRIM-Optimierung und eignet sich ideal für Entwicklungs- und Produktionsumgebungen mit Sicherheitsanforderungen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Linux-Distribution
|
||||
- **Release-Modell:** Rolling Release
|
||||
- **Status:** Aktiv
|
||||
- **Zweck:** Paketbau-Umgebung
|
||||
- **Paketmanager:** pacman
|
||||
- **Build-Tool:** [[makepkg]]
|
||||
- **AUR-Helfer:** [[Aura]]
|
||||
- **Verschlüsselung:** [[Disk Encryption]] (dm-crypt/LUKS)
|
||||
|
||||
## Verwendung in der Infrastruktur
|
||||
|
||||
### Szenario A: Arch-Paketbau
|
||||
- **Basis-Image:** `archlinux:base-devel`
|
||||
- **Zweck:** Arch-Linux-Pakete bauen
|
||||
- **Herausforderung:** `makepkg` erfordert Root-Rechte
|
||||
- **Lösung:** Erstelle im Workflow einen Benutzer `builder` ohne Root-Rechte
|
||||
|
||||
### Docker-Image
|
||||
```dockerfile
|
||||
FROM archlinux:base-devel
|
||||
|
||||
# Build-Kontext enthält base-devel-Pakete:
|
||||
# - gcc, make, autoconf, automake, binutils, bison, fawk, flex,
|
||||
# gawk, gettext, groff, libtool, m4, pacman, patch, pkgconf, sed, texinfo
|
||||
```
|
||||
|
||||
### 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
|
||||
```
|
||||
|
||||
## Workaround für Root-Beschränkung
|
||||
|
||||
### Das Problem
|
||||
`makepkg` (Arch's Build-Tool) erfordert traditionell Root für:
|
||||
- Installation von Build-Abhängigkeiten
|
||||
- Erstellung von Paketen
|
||||
- Verwaltung der Paketdatenbank
|
||||
|
||||
### Die Lösung
|
||||
Der Workflow erstellt einen Benutzer `builder` ohne Root-Rechte und:
|
||||
1. Gewährt passwortloses sudo via `/etc/sudoers`
|
||||
2. Wechselt zu Benutzer `builder` mit `su - builder`
|
||||
3. Führt `makepkg` im Builder-Kontext aus
|
||||
4. Lädt entstehende `.pkg.tar.zst`-Dateien als Artifacts hoch
|
||||
|
||||
## Warum nicht Alpine?
|
||||
|
||||
Für Szenario A ist Alpine Linux nicht geeignet, da:
|
||||
1. **Anderes Paketformat:** Alpine verwendet `.apk`-Pakete, nicht Arch's `.pkg.tar.zst`
|
||||
2. **Inkompatible Build-Tools:** `makepkg` ist Arch-spezifisch
|
||||
3. **musl libc:** Obwohl nicht direkt ein Problem für `makepkg`, ist es nicht kompatibel mit 1Password CLI
|
||||
|
||||
## Beziehungen
|
||||
|
||||
(Szenario A-Workflows)
|
||||
- **Läuft in:** [[Docker]]-Containern
|
||||
(für verschiedene Build-Szenarien)
|
||||
- **Teil von:** [[Gitea Actions]]-Workflow-Ökosystem
|
||||
|
||||
## Hinweis zum Artifact-Upload
|
||||
|
||||
### Gitea Actions v4 Einschränkung
|
||||
- **Problem:** Gitea Actions v4 unterstützt Artifact-Upload/Download nicht vollständig
|
||||
- **Symptom:** GHES (GitHub Enterprise Server)-Fehler bei Verwendung von v4
|
||||
- **Workaround:** Verwende `actions/upload-artifact@v3` explizit
|
||||
- **Auswirkung:** Szenario A muss auf v3 pinnen, bis Gitea Actions v4 reif ist
|
||||
|
||||
## Speicher- und Verschlüsselungsfunktionen
|
||||
|
||||
Arch Linux hat robuste Unterstützung für Speichertechnologien:
|
||||
|
||||
- **Disk-Verschlüsselung:** Vollständige Unterstützung für [[Disk Encryption]] via dm-crypt und LUKS
|
||||
- **LVM:** Integrierte [[LVM]]-Unterstützung (Logical Volume Manager)
|
||||
- **SSD TRIM:** Hervorragende [[SSD TRIM]]-Unterstützung, auch für verschlüsselte SSDs
|
||||
- **Dateisysteme:** Unterstützt ext4, XFS, Btrfs und andere moderne Dateisysteme mit TRIM
|
||||
- **Anwendungskompatibilität:** Unterstützt [[Wine]] zum Ausführen von Windows-Anwendungen, mit Konfigurationsoptionen zur Verhinderung von systemweiten Dateibindungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- CI-VM mit Arch-basierten Builds
|
||||
- [[Docker]] - Container-Laufzeit
|
||||
- [[Gitea Actions]] - CI/CD-Plattform
|
||||
- Alternatives Basis-Image
|
||||
Konzept
|
||||
- [[AUR]] - Arch User Repository
|
||||
- [[makepkg]] - Build-Tool
|
||||
- [[Aura]] - AUR-Helfer
|
||||
- [[GPG]] - GNU Privacy Guard
|
||||
- [[Disk Encryption]] - dm-crypt/LUKS
|
||||
- [[LVM]] - Logical Volume Manager
|
||||
- [[SSD TRIM]] - SSD-Optimierung
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [encryption, storage, security, dm-crypt, luke, linux]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Arch Linux, LVM, SSD TRIM, AUR, makepkg]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Schutz ruhender Daten über das Kernelmodul dm-crypt und die LUKS-Schlüsselverwaltung zur transparenten Verschlüsselung von Speichergeräten unter Linux.
|
||||
---
|
||||
# Disk Encryption
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Disk-Verschlüsselung bietet Schutz ruhender Daten auf Speichergeräten durch kryptographische Algorithmen. Unter Linux wird dies hauptsächlich durch das **dm-crypt** Kernel-Modul kombiniert mit **LUKS** (Linux Unified Key Setup) zur Schlüsselverwaltung implementiert. Diese Technologie schützt sensible Daten auf SSDs und HDDs vor unbefugtem Zugriff, besonders wichtig für Laptops, externe Laufwerke und Server mit physischen Zugriffsproblemen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Verschlüsselung gesamter Festplatte und Partitionen
|
||||
- **Status:** Aktiv, weit verbreitet
|
||||
- **Kernel-Modul:** dm-crypt (device-mapper Crypto Target)
|
||||
- **Schlüsselverwaltung:** LUKS (Linux Unified Key Setup)
|
||||
- **Verschlüsselungsalgorithmen:** AES, XTS, Serpent, Twofish, Camellia
|
||||
- **Hash-Algorithmen:** SHA-256, SHA-512, SHA-1 (Legacy)
|
||||
|
||||
## Komponenten
|
||||
|
||||
### dm-crypt
|
||||
Das device-mapper Crypto Target, das transparente Verschlüsselung von Block-Geräten bietet. Es arbeitet auf der Block-Geräte-Ebene und verschlüsselt/entschlüsselt Daten im laufenden Betrieb.
|
||||
|
||||
**Hauptmerkmale:**
|
||||
- Transparente Verschlüsselung/Entschlüsselung
|
||||
- Unterstützt mehrere Verschlüsselungsmodi (ECB, CBC, XTS usw.)
|
||||
- Funktioniert mit beliebigen Block-Geräten
|
||||
- Kann gesamte Festplatten oder einzelne Partitionen verschlüsseln
|
||||
|
||||
### LUKS (Linux Unified Key Setup)
|
||||
Eine Spezifikation für Disk-Verschlüsselung, die eine standardisierte Methode zur Verwaltung von Verschlüsselungsschlüsseln bietet. LUKS fügt einen Header zum verschlüsselten Gerät hinzu, das die Schlüssel-Slots, Metadaten und Checksummen enthält.
|
||||
|
||||
**Hauptmerkmale:**
|
||||
- Mehrere Schlüssel-Slots (bis zu 8 in LUKS1, mehr in LUKS2)
|
||||
- Schlüssel-Slot-Verwaltung (hinzufügen, entfernen, Passphrasen ändern)
|
||||
- Header-Backup und -Wiederherstellung
|
||||
- Unterstützung für Schlüsseldateien
|
||||
- Anti-Forensik-Funktionen (LUKS2)
|
||||
|
||||
## Einrichtung und Konfiguration
|
||||
|
||||
### Erstellen einer verschlüsselten Partition
|
||||
|
||||
```bash
|
||||
# Erstelle LUKS-Container
|
||||
cryptsetup luksFormat /dev/sdX1
|
||||
|
||||
# Öffne (entsperre) die verschlüsselte Partition
|
||||
cryptsetup open /dev/sdX1 crypted
|
||||
|
||||
# Erstelle Dateisystem auf entschlüsseltem Gerät
|
||||
mkfs.ext4 /dev/mapper/crypted
|
||||
|
||||
# Hänge das Dateisystem ein
|
||||
mount /dev/mapper/crypted /mnt
|
||||
```
|
||||
|
||||
### Ändern der Größe verschlüsselter Partitionen
|
||||
|
||||
Bei Verwendung von LUKS mit LVM (häufige Konfiguration) ist der Arbeitsablauf zum Größenändern:
|
||||
|
||||
1. **Ändere die Größe des zugrunde liegenden Block-Geräts** (z.B. VM-Festplatte erweitern)
|
||||
2. **Ändere die Größe des LUKS-Containers**
|
||||
3. **Ändere die Größe des LVM Physical Volume**
|
||||
4. **Ändere die Größe des LVM Logical Volume**
|
||||
5. **Ändere die Größe des Dateisystems**
|
||||
|
||||
**Beispiel für ESXi/SCSI:**
|
||||
```bash
|
||||
# SCSI-Bus neu scannen, um erweiterte Festplatte zu sehen
|
||||
echo "1" > /sys/class/block/sdb/device/rescan
|
||||
|
||||
# Prüfe Festplattengröße
|
||||
fdisk -l /dev/xyz
|
||||
|
||||
# Ändere Größe des LUKS-Containers
|
||||
cryptsetup status crypted
|
||||
cryptsetup resize crypted
|
||||
cryptsetup status crypted
|
||||
|
||||
# Ändere Größe des LVM PV (siehe [[LVM]])
|
||||
pvresize /dev/mapper/crypted
|
||||
```
|
||||
|
||||
## SSD-TRIM-Unterstützung
|
||||
|
||||
SSD TRIM ermöglicht es dem Betriebssystem, der SSD mitzuteilen, welche Blöcke nicht mehr in Gebrauch sind und verbessert damit Leistung und Haltbarkeit. Bei verschlüsselten Festplatten erfordert TRIM-Unterstützung eine sorgfältige Konfiguration.
|
||||
|
||||
### Aktivieren von TRIM auf verschlüsselten SSDs
|
||||
|
||||
**Wichtig:** Das Zulassen von discard (TRIM) auf verschlüsselten Geräten kann Informationen über verwendete Blöcke verraten. Bedenke die Sicherheitsauswirkungen.
|
||||
|
||||
**Optionen:**
|
||||
1. **Erlaube discard auf LUKS-Ebene:**
|
||||
```bash
|
||||
cryptsetup reencrypt --encrypt --reduce-device-size 16M --allow-discards /dev/sdX
|
||||
```
|
||||
|
||||
2. **Verwende fstrim auf gemountettem Dateisystem:**
|
||||
```bash
|
||||
fstrim /mount/point
|
||||
```
|
||||
|
||||
3. **Konfiguriere periodisches TRIM:**
|
||||
```bash
|
||||
# Aktiviere systemd-Timer
|
||||
systemctl enable fstrim.timer
|
||||
systemctl start fstrim.timer
|
||||
```
|
||||
|
||||
**Referenz:** https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[Arch Linux]] (häufige Distribution für Verschlüsselung)
|
||||
- **Ergänzt:** [[LVM]] (Logical Volume Manager)
|
||||
- **Verbessert durch:** [[SSD TRIM]] (Leistungsoptimierung)
|
||||
und anderen Systemen
|
||||
Ansatz
|
||||
|
||||
## Sicherheitsaspekte
|
||||
|
||||
### Best Practices
|
||||
|
||||
1. **Verwende starke Passphrasen:** Lange, komplexe Passphrasen mit hoher Entropie
|
||||
2. **Backup LUKS-Header:** `cryptsetup luksHeaderBackup /dev/sdX1 --header-backup-file header.img`
|
||||
3. **Mehrere Schlüssel-Slots:** Speichere Backup-Schlüssel in separaten Slots
|
||||
4. **Schlüsseldateien:** Erwäge Schlüsseldateien für headless-Systeme
|
||||
5. **Vermeide discard:** Für maximale Sicherheit, deaktiviere TRIM auf verschlüsselten Geräten
|
||||
|
||||
### Einschränkungen
|
||||
|
||||
- **Schützt nicht vor:** Evil-Maid-Angriffen, Keyloggern, Schulter-Blicken
|
||||
- **Leistungs-Overhead:** Verschlüsselung/Entschlüsselung fügt CPU-Overhead hinzu (typischerweise 5-10%)
|
||||
- **Wiederherstellung:** Verlorene Passphrase = verlorene Daten (kein Hintertür)
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LVM]] - Logical Volume Manager
|
||||
- [[SSD TRIM]] - TRIM-Optimierung für SSDs
|
||||
- [[Arch Linux]] - Distribution mit hervorragender Verschlüsselungsunterstützung
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://wiki.archlinux.org/title/Dm-crypt
|
||||
- https://wiki.archlinux.org/title/LUKS
|
||||
- https://gitlab.com/cryptsetup/cryptsetup
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [containers, containerization, docker, runtime]
|
||||
created: 2026-07-25
|
||||
modified: 2026-09-01
|
||||
related: [Act Runner, Gitea Actions]
|
||||
sources: [Source - Docker Cheatsheet]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Container-Plattform als Industriestandard für CI/CD-Infrastruktur, mit BuildKit-Daemon und entfernter Docker-Verwaltung über SSH.
|
||||
---
|
||||
# Docker
|
||||
|
||||
**Typ:** Technology (Container Platform)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Docker ist die Industrie-Standard-Container-Plattform, die in der gesamten CI/CD-Infrastruktur für Container-Laufzeit, Build-Ausführung und Service-Bereitstellung verwendet wird. Sie bietet die Grundlage für die Ausführung von Containern auf `ci-runner.example.net` und `docker-host.example.net`.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Container-Plattform
|
||||
- **Status:** Aktiv
|
||||
- **Zweck:** Container-Laufzeit und Build-Ausführung
|
||||
- **Lizenz:** Apache 2.0
|
||||
- **Geschrieben in:** Go
|
||||
|
||||
## Architektur in der Infrastruktur
|
||||
|
||||
### Auf ci-runner.example.net
|
||||
- **Docker-Daemon:** Docker-Service auf Host-Ebene
|
||||
- **Runner-Container:** `act_runner` läuft als Docker-Container
|
||||
- **BuildKit-Daemon:** `moby/buildkitd` läuft als Docker-Container auf Port 1234
|
||||
- **Job-Container:** Kurzlebige Container pro CI-Job in isolierten Bridge-Netzen
|
||||
|
||||
### Auf dem Docker-Host
|
||||
- **Legacy-Container:** Werden von `ci-runner.example.net` aus remote verwaltet
|
||||
- **Docker-Daemon:** Standard Docker-Service
|
||||
- **Zugriff:** Via SSH aus CI-Workflows
|
||||
|
||||
## Konfigurationsdetails
|
||||
|
||||
### Docker-Socket-Anbindung
|
||||
- **Ort:** `/var/run/docker.sock`
|
||||
- **Angebunden an:** `act_runner`-Container (für BuildKit-Verwaltung)
|
||||
- **NICHT angebunden an:** Job-Container (Sicherheit: vermeidet DinD-Risiken)
|
||||
|
||||
### Network-Modi
|
||||
- **Runner:** `host`-Network-Modus für Cache-Anbindung
|
||||
- **Jobs:** Isolierte temporäre Bridge-Netze (leeres `container.network`)
|
||||
- **BuildKit:** `bridge`-Netz mit Port 1234 freigegeben
|
||||
|
||||
## Fernverwaltung
|
||||
|
||||
### SSH-basierte Docker-Kontrolle
|
||||
CI-Workflows auf `ci-runner.example.net` verwalten Docker auf `docker-host.example.net`:
|
||||
|
||||
```bash
|
||||
# Set Docker host to remote via SSH
|
||||
export DOCKER_HOST=ssh://ci@192.0.2.10
|
||||
|
||||
# Execute Docker commands remotely
|
||||
docker ps
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
### Authentifizierung
|
||||
- **SSH-Schlüssel:** Ed25519-Schlüssel aus 1Password "CI-CD"-Vault
|
||||
- **Benutzer:** ci
|
||||
- **Methode:** Standard-SSH-Authentifizierung
|
||||
|
||||
## Sicherheitsaspekte
|
||||
|
||||
### Docker-in-Docker (DinD) - Vermeidung
|
||||
Traditioneller DinD-Ansatz:
|
||||
```bash
|
||||
# NOT USED - Security risk
|
||||
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
|
||||
```
|
||||
|
||||
**Stattdessen:**
|
||||
- BuildKit-Daemon läuft separat
|
||||
- Job-Container verbinden sich via TCP
|
||||
- Kein Zugriff auf Host Docker-Socket in Jobs
|
||||
|
||||
### Vorteile
|
||||
- **Isolation:** Job-Container können nicht auf Host Docker zugreifen
|
||||
- **Sicherheit:** Reduzierte Angriffsfläche
|
||||
- **Kontrolle:** Zentralisierte Build-Infrastruktur
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[Act Runner]], [[Gitea Actions]]
|
||||
- **Teil von:** Kerninfrastruktur
|
||||
|
||||
## Version und Kompatibilität
|
||||
|
||||
### Kompatibilitätshinweise
|
||||
- **Debian 13:** Exzellente Docker-Unterstützung (Referenzplattform)
|
||||
- **Arch Linux:** Gute Docker-Unterstützung für Build-Szenarien
|
||||
- **Alpine Linux:** Unterstützt, aber eingeschränkt durch musl libc für einige Tools
|
||||
|
||||
### 1Password CLI-Kompatibilität
|
||||
- **Funktioniert:** glibc-basierte Distributionen (Debian, Arch)
|
||||
- **Funktioniert nicht:** musl libc-basierte Distributionen (Alpine) mit Exitcode 127
|
||||
- **Auswirkung:** Container-Build-Jobs verwenden `debian:trixie-slim` anstelle von Alpine
|
||||
|
||||
## Volume-Verwaltung und Fehlerbehebung
|
||||
|
||||
### Overlay-FS-Auflösung
|
||||
Bei der Fehlerbehebung von Backup-Problemen, gesperrten Dateien oder Berechtigungsproblemen können Sie Overlay-Dateisystem-Verzeichnisse ihren Containern zuordnen:
|
||||
|
||||
```bash
|
||||
for container in $(docker ps --all --quiet --format '{{ .Names }}'); do
|
||||
echo "$(docker inspect $container --format '{{.GraphDriver.Data.MergedDir }}' | grep -Po '^.+?(?=/merged)' ) = $container"
|
||||
done
|
||||
```
|
||||
|
||||
**Ausgabe:** Listet alle Overlay-Verzeichnisse unter `/var/lib/docker/overlay2/` mit ihren entsprechenden Container-Namen auf.
|
||||
|
||||
**Anwendungsfall:** Identifiziert, welcher Container ein bestimmtes Overlay-Verzeichnis besitzt (z. B. `/var/lib/docker/overlay2/768... = starwars`).
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- Primärer Docker-Host
|
||||
- Legacy Docker-Host
|
||||
- Build-System mit Docker
|
||||
- [[Act Runner]] - Docker-Container
|
||||
- [[Gitea Actions]] - CI/CD mit Docker
|
||||
- Verwendet Docker als Laufzeit
|
||||
concept
|
||||
concept
|
||||
- [[Source - Docker Cheatsheet]]
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: GNU-Bootloader für Linux-Systeme; übernimmt das Laden des Kernels und die Boot-Konfiguration.
|
||||
---
|
||||
# GRUB
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
GRUB (GNU GRUB) ist der Standard-Bootloader für Linux-Systeme und verwaltet das initiale Kernel-Laden und die Boot-Zeit-Konfiguration. Es unterstützt Multi-Boot-Umgebungen und komplexe Partitionierungsschemas.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Bezogen auf:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite via wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,285 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [ci-cd, workflows, automation, gitea]
|
||||
created: 2026-07-25
|
||||
modified: 2026-09-01
|
||||
related: [Gitea, Act Runner, Docker, Gitea MCP Server, Ambient Environment Dependency, CI Integration]
|
||||
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, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: CI/CD-Workflow-Plattform, in Gitea integriert; fuehrt YAML-Workflows ueber den Act Runner aus, samt Release-Pipeline, belegten paths-ignore-Filtern und einem nightly.yml-Drift-Check, dessen schedule-Ausloesung seit 2026-09-01 (Run 90) belegt ist
|
||||
---
|
||||
# Gitea Actions
|
||||
|
||||
**Typ:** Technology (CI/CD Platform)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Gitea Actions ist das CI/CD-Workflow-Automatisierungssystem, das in Gitea integriert ist. Es ermöglicht die Definition von Build-, Test- und Deployment-Pipelines als Code in YAML-Workflow-Dateien. Die Workflows werden vom [[Act Runner]] ausgeführt.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** CI/CD-Workflow-Automatisierung
|
||||
- **Status:** Aktiv (Stand 2026-07-12)
|
||||
- **Runner:** [[Act Runner]]
|
||||
- **Workflow-Syntax:** GitHub Actions kompatibles YAML
|
||||
|
||||
## Architektur
|
||||
|
||||
### Workflow-Ausführung
|
||||
1. **Auslöser:** Push, PR, Zeitplan oder manuelle Auslösung
|
||||
2. **Runner-Auswahl:** Basierend auf Routing-Labels (`linux-docker`, `container-builder`, `k3s-deploy`)
|
||||
3. **Job-Container:** Isoliertes Bridge-Netz pro Job
|
||||
4. **Secret-Injektion:** Runtime-Abruf aus 1Password
|
||||
5. **Cache:** Built-in Actions Cache Server auf Port 8088
|
||||
|
||||
### Schlüsselkomponenten
|
||||
- **Runner:** `act_runner`-Docker-Container im Host-Network-Modus
|
||||
- **Cache Server:** Built-in, zugänglich via statische IP-Konfiguration
|
||||
- **Job-Container:** Kurzlebige Docker-Container pro Workflow-Job
|
||||
- **Actions:** Wiederverwendbare Workflow-Komponenten
|
||||
|
||||
## Konfiguration
|
||||
|
||||
### Cache-Konfiguration
|
||||
```yaml
|
||||
# In act_runner config.yaml
|
||||
cache:
|
||||
enabled: true
|
||||
host: "192.0.2.10" # static IP of ci-runner.example.net
|
||||
port: 8088
|
||||
```
|
||||
|
||||
**Wichtig:** `cache.host` ist die Adresse, die Job-Container verwenden, um den Cache-Server zu erreichen, nicht die Listen-Adresse des Servers.
|
||||
|
||||
### Workflow-Beispiel
|
||||
```yaml
|
||||
name: Build and Deploy
|
||||
|
||||
on: [push]
|
||||
|
||||
permissions:
|
||||
packages: write # Required for registry pushes
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: linux-docker
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Load secrets
|
||||
uses: 1password/load-secrets-action@v2
|
||||
with:
|
||||
vault: CI-CD
|
||||
env:
|
||||
REGISTRY_TOKEN: ${{ secrets.REGISTRY_TOKEN }}
|
||||
|
||||
- name: Build with BuildKit
|
||||
run: |
|
||||
docker buildx create --driver remote tcp://$HOST_IP:1234
|
||||
docker buildx build --push ...
|
||||
```
|
||||
|
||||
## Validierte Szenarien
|
||||
|
||||
### Szenario A: Arch-Paketbuilds
|
||||
- **Basis-Image:** `archlinux:base-devel`
|
||||
- **Herausforderung:** `makepkg` benötigt Root
|
||||
- **Lösung:** Erstelle non-Root-Benutzer `builder` on-the-fly
|
||||
- **Artefakte:** `actions/upload-artifact@v3` (v4 nicht vollständig unterstützt)
|
||||
- **Hinweis:** Gitea Actions v4 hat begrenzte Artefakt-Unterstützung
|
||||
|
||||
### Szenario B: Container-Builds
|
||||
- **Basis-Image:** `debian:trixie-slim` (Standard)
|
||||
- **Vermeidet:** Alpine Linux (musl libc inkompatibel mit 1Password CLI)
|
||||
- **Verbindung:** Dynamische IP-Erkennung via `ip route | awk '/default/ { print $3 }'`
|
||||
|
||||
### Szenario C: K3s-Deployments
|
||||
-Cluster
|
||||
- **Authentifizierung:** Kubeconfig aus 1Password-Vault
|
||||
- **Muster:** `kubectl wait --for=delete pod -l ...` für zuverlässige Ressourcenverwaltung
|
||||
|
||||
### Szenario D: Test- und Release-Pipeline eines Python-Werkzeugs
|
||||
|
||||
- **Basis-Image:** `debian:trixie-slim`, trägt python3 3.13[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- **Erster Schritt:** `apt-get install nodejs`, **vor** dem Checkout - Voraussetzung für jede
|
||||
JavaScript-Action, siehe [[Act Runner]][^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- **Checkout:** `actions/checkout@v7`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- **Release:** `${{ gitea.token }}` genügt für das Anlegen von Release und Tag sowie für
|
||||
Asset-Uploads; kein Actions-Secret mit `write:repository`
|
||||
nötig[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- **Auslöser des Release-Workflows:** eine Änderung an der `VERSION`-Datei, siehe
|
||||
[[KB Stack Versioning]]
|
||||
|
||||
### Läufe eines Workflows auf ihre Ursache prüfen
|
||||
|
||||
Bei einem privaten Repository lässt sich der Lauf-Zustand nicht anonym über HTTP feststellen;
|
||||
[[Gitea]] antwortet einem anonymen Aufrufer identisch mit `404`, ob das Repository unsichtbar
|
||||
oder nicht vorhanden
|
||||
ist[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Läufe, ihr
|
||||
Ausgang und ihre Logs werden über den [[Gitea MCP Server]] gelesen.
|
||||
|
||||
## Auslöser filtern
|
||||
|
||||
`paths-ignore` schließt Pfade von einem Workflow aus. Für die Filterlisten gelten hier drei
|
||||
Festlegungen, die alle Ableitungen aus Undokumentiertem
|
||||
vermeiden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
- **Keine YAML-Anker**, um eine Liste zwischen zwei Workflows zu teilen. GitHubs Parser lehnt
|
||||
Anker ab, und für Gitea ist nicht dokumentiert, dass er sie annimmt. Die Liste steht lieber
|
||||
zweimal.
|
||||
- **Keine negierten Muster** wie `!**/CONTRACT.md`. Gitea dokumentiert die Unterstützung
|
||||
negierter Filtermuster nicht.
|
||||
- **Die Muster scheitern offen.** Alles Unvorhergesehene löst weiterhin einen Lauf aus; das ist
|
||||
die richtige Richtung für einen Filter, dessen Auswertung nicht bewiesen ist.
|
||||
|
||||
Dass die Filter greifen, ist seit 2026-08-31 beobachtet und nicht mehr angenommen. Commit
|
||||
`f916376` war ein reiner Content-Publish - `kb/index.md`, `kb/log.md`, `kb/provenance.md`, acht
|
||||
Seiten unter `kb/*/**` und eine Datei unter `raw/notes/`, sämtlich auf der Ignore-Liste - und
|
||||
erzeugte zu seiner `head_sha` keinen einzigen Lauf[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]:
|
||||
|
||||
| Commit | Inhalt | Läufe |
|
||||
|---|---|---|
|
||||
| `6f54c31` | Stack (1.1.0) | 59 |
|
||||
| `adfa220` | Stack (1.1.1) | 60, 61 |
|
||||
| `f916376` | nur `kb/` und `raw/` | keine |
|
||||
| `40adbb7` | Stack (1.2.0) | 62, 63 |
|
||||
|
||||
Die Stack-Commits davor und danach erzeugten je zwei Läufe, CI und Release, weil `VERSION` sich
|
||||
bewegt hatte. Der Unterschied ist also der Filter und kein untätiger Runner; Gitea wertet diese
|
||||
Muster wie GitHub aus[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]. Der Befund steht im Kommentarkopf von
|
||||
`.gitea/workflows/ci.yml`, damit er nicht erneut für eine Annahme gehalten wird, und schloss
|
||||
Gitea-Issue #11[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
Als Folgewirkung bleibt die stärkste Hälfte der Begründung für den nächtlichen Drift-Check
|
||||
(Issue #9) stehen: Weil der Filter greift, läuft `lint --fail-on-error` bei einem
|
||||
Content-Publish tatsächlich nicht mehr. Ob dieser Gitea-Build `on: schedule` überhaupt
|
||||
auswertet, ist davon unberührt - ~~und weiter offen~~ (Stand 2026-08-31; seit 2026-09-01
|
||||
geklärt, siehe unten)[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
`.gitea/workflows/nightly.yml` (seit 2026-08-31) implementiert diesen Drift-Check: `on:
|
||||
schedule` (`17 3 * * *` UTC) plus `workflow_dispatch`, kein Push-Trigger, dieselbe Runner-Form
|
||||
wie `ci.yml`. Diese Gitea-Instanz läuft **1.26.1** - weit über der 1.20-Version, die
|
||||
Actions-Schedules einführte, was den Trigger plausibel, aber nicht bewiesen
|
||||
macht[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
Zwei `workflow_dispatch`-Testläufe bestätigten zunächst nur, dass der Job selbst durchläuft
|
||||
(Run 85, alle sieben Schritte grün) - ~~keiner davon ist ein `schedule`-Lauf. **Offen bleibt
|
||||
weiterhin**, ob der Cron-Trigger auf diesem Stand tatsächlich feuert - frühestens ab
|
||||
2026-09-01 03:17 UTC zu beobachten, an einem Lauf mit `"event":"schedule"`, nicht an einem
|
||||
weiteren `workflow_dispatch`-Erfolg~~ (Stand
|
||||
2026-08-31)[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
|
||||
**Bestätigt seit 2026-09-01:** Run 90 ist der erste Lauf der Repository-Historie mit
|
||||
`"event":"schedule"` - gestartet `2026-09-01T03:17:35Z`, exakt zur konfigurierten Cron-Zeit,
|
||||
abgeschlossen `03:17:38Z`, alle sieben Schritte grün. Dieser Gitea-1.26.1-Stand wertet
|
||||
`on: schedule` auf dem Default-Branch also tatsächlich aus; der im Issue vorgesehene externe
|
||||
Fallback (ein externer Cron gegen die Actions-API) war nicht nötig.
|
||||
Gitea-Issue #9 ist damit
|
||||
geschlossen.
|
||||
|
||||
## Bekannte Probleme und Lösungen
|
||||
|
||||
### Der Job-Container ist keine konfigurationsfreie Maschine (Beobachtet 2026-08-31)
|
||||
|
||||
**Beobachtung:** `actions/checkout@v7` legt im Job-Container selbst eine globale
|
||||
git-Konfiguration an. Aus dem Log von Lauf 79 des Chemenu-CI (damals `llm-wiki-test1`):
|
||||
`Copying '/root/.gitconfig' to '/tmp/<uuid>/.gitconfig'` und `Temporarily overriding
|
||||
HOME='/tmp/<uuid>' before making global git config changes`. Ein `git config --global --add
|
||||
safe.directory` im eigenen Setup-Schritt schreibt zusätzlich
|
||||
hinein[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31].
|
||||
|
||||
**Warum das zählt:** Ein CI-Container gilt gern als neutrale Umgebung - "hier ist nichts
|
||||
konfiguriert, also fällt auf, was von der Maschine gelesen wird". Für git stimmt das nicht mehr.
|
||||
Ein Test oder Guard, der sich darauf verlässt, hört still auf zu greifen: kein roter Lauf, keine
|
||||
Meldung, nur eine Prüfung, die nichts mehr prüft.
|
||||
|
||||
**Konsequenz:** Wer Umgebungsunabhängigkeit prüfen will, stellt sie explizit her
|
||||
(`GIT_CONFIG_GLOBAL=/dev/null`, eigenes `HOME`) statt sie vom Container zu erwarten. Siehe
|
||||
[[Ambient Environment Dependency]].
|
||||
|
||||
### `doctor` prüft eine Instanz, ein Checkout ist noch keine (Behoben 2026-08-31)
|
||||
|
||||
**Problem:** Der erste `workflow_dispatch`-Lauf von `nightly.yml` scheiterte am `doctor`-Schritt:
|
||||
`FAIL git-identity: 'git config user.name' is not set` und `FAIL skills: No skills published
|
||||
yet`[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
|
||||
**Grundursache:** `doctor` fragt, ob eine *arbeitsfähige Instanz* korrekt konfiguriert ist, nicht
|
||||
ob ein Checkout vollständig ist. `.agents/skills/` und `.claude/skills/` sind generiert und
|
||||
bewusst nicht committet (siehe `instructions/bootstrap.md`), existieren also erst nach
|
||||
`wikitool instructions sync`; und der Job-Container hat keine git-Konfiguration, unabhängig
|
||||
davon, ob `WIKI_AUTHOR` gesetzt ist - das deckt nur die separate `author`-Prüfung, nicht
|
||||
`git-identity`[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
Weil `doctor` den Job abbrach, wurde `instructions verify` nie erreicht - der Fehlschlag stand
|
||||
vor dem eigentlichen Prüfzweck des Laufs, nicht in
|
||||
ihm[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
|
||||
**Lösung:** Vor `doctor` eine echte git-Identität setzen (`git config --global user.name/
|
||||
user.email`) und `tools/wikitool instructions sync` laufen lassen - ein Mechanismus deckt beide
|
||||
Prüfungen ab, statt zwei separate (git-Identität, `WIKI_AUTHOR`) je eine. Jeder Workflow, der
|
||||
`doctor` oder `instructions verify` auf einem frischen Checkout aufruft, braucht denselben
|
||||
Bootstrap[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
|
||||
### JavaScript-Actions ohne `node` im Job-Image (Behoben 2026-08-30)
|
||||
|
||||
**Problem:** Jeder Lauf scheiterte an `actions/checkout` mit
|
||||
`exec: "node": executable file not found in $PATH` und `exitcode '127'`.
|
||||
|
||||
**Grundursache:** act_runner führt JavaScript-Actions mit `node` im Job-Container aus; das
|
||||
gepinnte `debian:trixie-slim` bringt keins mit. Das Runner-Label `linux-docker` war nie das
|
||||
Problem - es routete und startete den Container von Anfang
|
||||
an[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
**Lösung:** `nodejs` als erster Schritt vor dem Checkout installieren, Checkout auf
|
||||
`actions/checkout@v7` heben. Ausführlich auf der Seite [[Act Runner]].
|
||||
|
||||
### Actions Cache Server-Konnektivität (Behoben 2026-07-12)
|
||||
**Problem:** `setup-go@v6` und andere Cache-verwendende Actions zeigten Timeout bei Versuch, den Cache-Server unter `172.18.0.2:39329` (interne Docker-Bridge-IP) zu erreichen.
|
||||
|
||||
**Grundursache:** Runner-Container befand sich in seinem eigenen Bridge-Netz (`act_runner_default`), während sich jeder Job-Container in einem isolierten temporären Bridge-Netz befand. Diese Netze konnten ohne Host-Routing nicht miteinander kommunizieren.
|
||||
|
||||
**Lösung:**
|
||||
1. Änderte Runner-Container zu `network_mode: host`
|
||||
2. Setzte `cache.host` auf statische IP `192.0.2.10`
|
||||
3. Cache-URL automatisch als `ACTIONS_CACHE_URL` injiziert
|
||||
4. Vollständiger Neustart erforderlich: `docker compose down && docker compose up -d`
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** [[Gitea]]-Ökosystem
|
||||
- **Ausgeführt von:** [[Act Runner]]
|
||||
- **Nutzt:** [[Docker]] für Container
|
||||
- **beobachtet über:** [[Gitea MCP Server]]
|
||||
- **zeigte:** [[Ambient Environment Dependency]]
|
||||
- **implementiert:** [[CI Integration]]
|
||||
|
||||
## Vorteile
|
||||
|
||||
- GitHub Actions kompatible Syntax
|
||||
- Selbstgehostet, volle Kontrolle
|
||||
- Integriert mit Gitea-Ökosystem
|
||||
- Zero-Trust-ready mit 1Password-Integration
|
||||
- Keine Vendor-Lock-in
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Gitea]] - Git-Dienst
|
||||
- [[Act Runner]] - Runner-Implementierung
|
||||
- Host-VM
|
||||
- Secrets-Verwaltung
|
||||
- Build-System
|
||||
- [[Docker]] - Container-Plattform
|
||||
concept
|
||||
- [[Gitea MCP Server]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[Ambient Environment Dependency]]
|
||||
- [[CI Integration]]
|
||||
|
||||
## 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]]
|
||||
[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31]: [[Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]]
|
||||
[^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]]
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [git, version-control, self-hosted, ci-cd]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [Act Runner, Gitea Actions]
|
||||
sources: [Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Selbst gehosteter Git-Dienst auf docker-host.example.net; bietet Repository-Verwaltung und CI/CD über Gitea Actions mit Act Runner.
|
||||
---
|
||||
# Gitea
|
||||
|
||||
**Typ:** Technology (Git Service)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Gitea ist ein selbst gehosteter Git-Dienst, der Quellcode-Verwaltung und CI/CD-Funktionen durch Gitea Actions bietet. Die Instanz läuft auf `docker-host.example.net` unter http://192.0.2.10:3000.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Git-Dienst / Quellcode-Verwaltung
|
||||
- **Status:** Aktiv
|
||||
- **Instanz-URL:** http://192.0.2.10:3000
|
||||
- **Lizenz:** MIT
|
||||
- **Geschrieben in:** Go
|
||||
|
||||
## Funktionen
|
||||
|
||||
### Kernfunktionen
|
||||
- Git-Repository-Hosting
|
||||
- Issue-Tracking
|
||||
- Pull Requests
|
||||
- Wiki
|
||||
- Projektmanagement
|
||||
|
||||
### CI/CD-Funktionen (via Gitea Actions)
|
||||
- Workflow-Ausführung via [[Act Runner]]
|
||||
- Actions-Marketplace
|
||||
- Container Registry
|
||||
- Secrets-Verwaltung
|
||||
|
||||
## Konfiguration
|
||||
|
||||
### app.ini-Einstellungen
|
||||
```ini
|
||||
[actions]
|
||||
ENABLE_ACTIONS_TOKEN = true
|
||||
```
|
||||
|
||||
Dies ermöglicht Workflows, `${{ gitea.token }}` zur Authentifizierung zu verwenden.
|
||||
|
||||
### Runner-Registrierung
|
||||
- **Token:** `GITEA_RUNNER_REGISTRATION_TOKEN`
|
||||
- **Runner-Name:** ci-vm-runner
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet Runner:** [[Act Runner]]
|
||||
- **Bietet:** [[Gitea Actions]]-CI/CD-Funktionalität
|
||||
- **Verbunden mit:** Container Registry für Image-Speicherung
|
||||
|
||||
## Container Registry
|
||||
|
||||
- **Zweck:** Speichert Container-Images, die von CI/CD-Workflows erstellt werden
|
||||
- **Authentifizierung:** Verwendet `${{ gitea.token }}` mit `packages: write`-Berechtigung
|
||||
- **Zugriffsmuster:** Workflows pushen Images während des Build-Prozesses
|
||||
|
||||
## Workflow-Berechtigungen
|
||||
|
||||
Erforderlich für Registry-Pushes:
|
||||
```yaml
|
||||
permissions:
|
||||
packages: write
|
||||
```
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- Dedizierte CI-VM
|
||||
- Host-System
|
||||
- [[Act Runner]] - Gitea Actions Runner
|
||||
- [[Gitea Actions]] - CI/CD-Plattform
|
||||
concept
|
||||
- Dotfile-Manager mit Gitea für Repository-Hosting
|
||||
- System, das YADM-Repository beherbergt
|
||||
- Workstation mit YADM und Gitea
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [programming-language, compiled, backend, systems]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [ha-core, gdeploy, plugnburn-edl, BCDModule, goresponsiveness, hacs-e3dc]
|
||||
sources: []
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: general
|
||||
summary: Quelloffene Programmiersprache von Google für Systemprogrammierung und Backend-Dienste, mit eingebauter Nebenläufigkeit über Goroutines und Channels.
|
||||
---
|
||||
# Go
|
||||
|
||||
**Typ:** Technology (Programming Language)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Go (häufig als Golang bezeichnet) ist eine Open-Source-, statisch typisierte, kompilierte Programmiersprache, die von Google entwickelt wurde. Sie ist für die Erstellung einfacher, schneller und zuverlässiger Software konzipiert.
|
||||
|
||||
Go ist besonders gut geeignet für Systemprogrammierung, Backend-Services und nebenläufige Anwendungen aufgrund seiner integrierten Unterstützung für Nebenläufigkeit (Goroutines und Channels), schnelle Kompilierung und effiziente Laufzeit.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Typ:** Programmiersprache
|
||||
- **Paradigma:** Prozedural, nebenläufig
|
||||
- **Erste Erscheinung:** 2009
|
||||
- **Entworfen von:** Robert Griesemer, Rob Pike, Ken Thompson bei Google
|
||||
- **Lizenz:** BSD-ähnlich
|
||||
- **Website:** https://golang.org
|
||||
- **Aktuelle stabile Version:** 1.22+ (Stand 2026)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[ha-core]], [[gdeploy]], [[plugnburn-edl]], [[BCDModule]], [[goresponsiveness]], [[hacs-e3dc]]
|
||||
- **Konkurriert mit:** Rust, Java, C++, Python (für Backend)
|
||||
- **Beeinflusst von:** C, Pascal, Oberon
|
||||
- **Beeinflusst:** Viele moderne Sprachen
|
||||
|
||||
## Schlüsselfunktionen
|
||||
|
||||
### Sprachfunktionen
|
||||
|
||||
- **Statische Typisierung** - Typsicherheit mit Typinferenz
|
||||
- **Nebenläufigkeit** - Goroutines (leichte Threads) und Channels
|
||||
- **Garbage Collection** - Automatische Speicherverwaltung
|
||||
- **Interfaces** - Implizite Implementierung (Duck Typing)
|
||||
- **Pakete** - Modulare Organisation
|
||||
- **Tooling** - Built-in Build-, Test-, Format- und Dokumentations-Tools
|
||||
|
||||
### Leistung
|
||||
|
||||
- Schnelle Kompilierung
|
||||
- Effiziente Ausführung (native Binärdateien)
|
||||
- Niedrige Latenz
|
||||
- Gut für CPU-intensive und I/O-intensive Aufgaben
|
||||
|
||||
### Ökosystem
|
||||
|
||||
- **Pakerverwaltung:** Go Modules (seit Go 1.11)
|
||||
- **Standardbibliothek:** Umfangreich und gut konzipiert
|
||||
- **Pakete von Drittanbietern:** Wachsendes Ökosystem auf pkg.go.dev
|
||||
|
||||
## Anwendungsfälle
|
||||
|
||||
Basierend auf der Repository-Struktur wird Go verwendet für:
|
||||
|
||||
1. **Hausautomation** - [[ha-core]]
|
||||
2. **Deployment-Tools** - [[gdeploy]]
|
||||
3. **EDL-bezogene Tools** - [[plugnburn-edl]], [[andybalholm-edl]]
|
||||
4. **Modulsysteme** - [[BCDModule]]
|
||||
6. **Performance-Testing** - [[goresponsiveness]]
|
||||
|
||||
## Vor- und Nachteile
|
||||
|
||||
### Vorteile
|
||||
|
||||
- Schnelle Kompilierung und Ausführung
|
||||
- Exzellente Standardbibliothek
|
||||
- Integrierte Unterstützung für Nebenläufigkeit
|
||||
- Einfache Syntax
|
||||
- Starkes Tooling-Ökosystem
|
||||
- Plattformübergreifende Kompilierung
|
||||
- Gut für Microservices und CLI-Tools
|
||||
|
||||
### Nachteile
|
||||
|
||||
- Weniger flexibel als dynamisch typisierte Sprachen
|
||||
- Keine Generics (bis Go 1.18)
|
||||
- Error Handling kann verbose sein
|
||||
- Begrenzte Meta-Programmierungsfunktionen
|
||||
|
||||
## Lernressourcen
|
||||
|
||||
- **Offiziell:** https://golang.org/doc
|
||||
- **Tour:** https://go.dev/tour/
|
||||
- **Effective Go:** https://go.dev/doc/effective_go
|
||||
- **Blog:** https://go.dev/blog/
|
||||
|
||||
## Toolchain
|
||||
|
||||
- `go build` - Pakete und Abhängigkeiten kompilieren
|
||||
- `go test` - Tests ausführen
|
||||
- `go fmt` - Code formatieren
|
||||
- `go mod` - Modul-Verwaltung
|
||||
- `go doc` - Dokumentation
|
||||
- `go run` - Kompilieren und ausführen
|
||||
- `godep` - Abhängigkeits-Tool (älter)
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Formatierung:** Immer `go fmt` verwenden
|
||||
2. **Testen:** Tests mit dem Testing-Paket schreiben
|
||||
3. **Error Handling:** Explizite Fehlerprüfung
|
||||
4. **Nebenläufigkeit:** Channels für Kommunikation verwenden
|
||||
5. **Interfaces:** Kleine, fokussierte Interfaces entwerfen
|
||||
|
||||
## Historie
|
||||
|
||||
- [2009] - Erste öffentliche Veröffentlichung
|
||||
- [2012] - Go 1.0 veröffentlicht
|
||||
- [2015] - Go 1.5 mit Self-Hosting-Compiler
|
||||
- [2018] - Go 1.11 mit Modulen
|
||||
- [2020] - Go 1.15 mit verbessertem Linker
|
||||
- [2022] - Go 1.18 mit Generics
|
||||
- [2026-07-25] - Entity-Seite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[ha-core]] - Verwendet Go für E3DC-Integration
|
||||
- [[gdeploy]] - Go-basiertes Deployment-Tool
|
||||
- [[Rust]] - Alternative Systemsprache
|
||||
- [[Python]] - Alternative Skriptsprache
|
||||
- Systems Programming concept
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, Modbus, ha-core]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Quelloffene Plattform zum Aufbau von Hausautomationssystemen mit Gerätesteuerung und Automatisierung.
|
||||
---
|
||||
# Home Assistant
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Home Assistant ist eine Python-basierte Open-Source-Hausautomationsplattform, die die Kontrolle von Smart-Home-Geräten vieler Hersteller hinter einer einzigen Schnittstelle vereinheitlicht. ha-core integriert es mit E3DC-Energiespeichersystemen zur Überwachung und Kontrolle.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Bezogen auf:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite via wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,94 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [kernel, power-management, cpu, governor]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Linux Kernel, amd-pstate, acpi-cpufreq, CPPC]
|
||||
sources: [Source - AMD Powermanagement CPU]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Power-Management-Module des Linux-Kernels, die die CPU-Frequenz dynamisch nach Systemlast und Leistungsanforderung skalieren.
|
||||
---
|
||||
# Kernel PM Governors
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Kernel-PM-Governoren (Power Management) sind Richtlinienmodule innerhalb des Linux-Kernels, die bestimmen, wie die CPU-Frequenzskalierung durchgeführt wird. Sie bewerten die Systemauslastung und Leistungsanforderungen, um geeignete CPU-Leistungszustände auszuwählen und dabei Leistung und Energieeffizienz auszugleichen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Dynamische CPU-Frequenzskalierungsrichtlinien
|
||||
- **Status:** Aktiv
|
||||
- **Typ:** Kernel-Governor-Module
|
||||
- **Schnittstelle:** Funktioniert mit cpufreq-Treibern (amd-pstate, acpi-cpufreq)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Hängt ab von:** [[Linux Kernel]]
|
||||
- **Verwendet von:** [[amd-pstate]], [[acpi-cpufreq]]
|
||||
- **Bewertet:** [[CPPC]]-Ziele und Hinweise (bei Verwendung von amd-pstate)
|
||||
- **Verwandt mit:** CPU-Power-Management-Subsystem
|
||||
|
||||
## Details
|
||||
|
||||
### Governor-Typen
|
||||
|
||||
Der Linux-Kernel umfasst mehrere Governoren, wobei die folgenden am relevantesten sind:
|
||||
|
||||
#### schedutil
|
||||
|
||||
- **Beschreibung:** Standard-Governor in modernen Linux-Kernels
|
||||
- **Ansatz:** Verwendet Scheduler-Auslastungsdaten, um Frequenzskalierungsentscheidungen zu treffen
|
||||
- **Merkmale:**
|
||||
- Niedrige Latenz
|
||||
- Geeignet für universelle Arbeitslasten
|
||||
- Funktioniert gut mit sowohl acpi-cpufreq als auch amd-pstate
|
||||
- Kann CPPC-Leistungsziele und Hinweise bewerten, wenn amd-pstate verwendet wird
|
||||
|
||||
#### ondemand
|
||||
|
||||
- **Beschreibung:** Skaliert Frequenz basierend auf aktueller CPU-Auslastung
|
||||
- **Ansatz:** Erhöht die Frequenz, wenn die CPU-Auslastung steigt, senkt sie ab, wenn keine Last vorhanden ist
|
||||
- **Merkmale:**
|
||||
- Einfach und effektiv
|
||||
- Kann CPPC-Hinweise bewerten, wenn amd-pstate verwendet wird
|
||||
- Geeignet für Systeme, bei denen Leistung Priorität hat
|
||||
- Weniger aggressive Energieersparnisse als conservative
|
||||
|
||||
#### Andere Governoren
|
||||
|
||||
- **conservative:** Konservativere Frequenzskalierung, priorisiert Energieersparnisse
|
||||
- **powersave:** Wählt immer die niedrigste Frequenz
|
||||
- **performance:** Wählt immer die höchste Frequenz
|
||||
- **userspace:** Ermöglicht User-Space-Anwendungen, die Frequenz zu steuern
|
||||
|
||||
### Governoren mit amd-pstate
|
||||
|
||||
Bei Verwendung des **amd-pstate**-Treibers erhalten Governoren wie **schedutil** und **ondemand** zusätzliche Funktionen:
|
||||
|
||||
- Können **CPPC-Leistungsziele** bewerten, die von der Hardware bereitgestellt werden
|
||||
- Können **CPPC-Hinweise** interpretieren, um fundiertere Entscheidungen zu treffen
|
||||
- Ermöglichen **feinkörnige Regulierung** des Systems
|
||||
- Führen zu verbesserter **Energieeffizienz** und verlängerter Batterielebensdauer auf mobilen Geräten
|
||||
|
||||
### Governoren mit acpi-cpufreq
|
||||
|
||||
Bei Verwendung des **acpi-cpufreq**-Treibers sind Governoren auf die Auswahl aus verfügbaren **P-States** beschränkt (normalerweise 3 Zustände für AMD):
|
||||
- P-State 0 (vollständige Leistung)
|
||||
- P-State 1 (Zwischen)
|
||||
- P-State 2 (niedrigste Leistung)
|
||||
|
||||
Dies führt zu grobkörnigerer Kontrolle im Vergleich zu amd-pstate + CPPC.
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Linux Kernel]]
|
||||
- [[amd-pstate]]
|
||||
- [[acpi-cpufreq]]
|
||||
- [[CPPC]]
|
||||
- [[Source - AMD Powermanagement CPU]]
|
||||
|
||||
@@ -0,0 +1,188 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [storage, volume-management, linux, disks]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Arch Linux, Disk Encryption, AUR]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Device-Mapper-Framework unter Linux für flexible Datenträgerverwaltung mit Logical Volumes, Snapshots und Online-Vergrößerung jenseits klassischer Partitionierung.
|
||||
---
|
||||
# LVM
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Logical Volume Manager (LVM) ist ein Device-Mapper-Framework für Linux, das eine logische Volumenverwaltung für Festplattenspeicher bietet. Es ermöglicht flexible Speicherzuweisung, Größenänderung und Verwaltung über die Grenzen traditioneller Partitionierungsschemata hinaus.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Vollständiger Name:** Logical Volume Manager
|
||||
- **Zweck:** Flexible Disk-Speicherverwaltung
|
||||
- **Status:** Aktiv, reife Technologie
|
||||
- **Kernel-Komponente:** Device Mapper
|
||||
- **Upstream:** Teil des Linux-Kernels
|
||||
- **Paket:** `lvm2` in den meisten Distributionen
|
||||
|
||||
## Komponenten
|
||||
|
||||
### Physical Volumes (PV)
|
||||
Roh-Speichergeräte oder Partitionen, die für LVM-Nutzung initialisiert werden. Dies sind die Bausteine von LVM-Speicherpools.
|
||||
|
||||
### Volume Groups (VG)
|
||||
Sammlungen von physischen Volumes, die einen Speicherpool bilden. Mehrere PVs können in einem einzigen VG kombiniert werden.
|
||||
|
||||
### Logical Volumes (LV)
|
||||
Virtuelle Partitionen, die aus Volume Groups erstellt werden. LVs erscheinen dem System als normale Block-Geräte.
|
||||
|
||||
## Funktionen
|
||||
|
||||
- **Flexible Größenanpassung:** Größe von Volumes online ändern (auch während des Betriebs)
|
||||
- **Dynamische Zuweisung:** Speicher nach Bedarf zuweisen
|
||||
- **Snapshots:** Zeitpunktgenaue Kopien von Volumes erstellen
|
||||
- **Thin Provisioning:** Speicher bei Bedarf zuweisen
|
||||
- **Striping:** Daten auf mehrere Festplatten für Leistung verteilen
|
||||
- **Mirroring:** Redundante Kopien für Zuverlässigkeit erstellen
|
||||
|
||||
## Häufige Befehle
|
||||
|
||||
### Physical Volumes
|
||||
|
||||
```bash
|
||||
# Initialize a disk or partition as PV
|
||||
pvcreate /dev/sdX1
|
||||
|
||||
# Display PV information
|
||||
pvdisplay
|
||||
pvs
|
||||
|
||||
# Remove PV
|
||||
pvremove /dev/sdX1
|
||||
```
|
||||
|
||||
### Volume Groups
|
||||
|
||||
```bash
|
||||
# Create VG from one or more PVs
|
||||
vgcreate myvg /dev/sdX1 /dev/sdX2
|
||||
|
||||
# Display VG information
|
||||
vgdisplay
|
||||
vgs
|
||||
|
||||
# Extend VG with additional PV
|
||||
vgextend myvg /dev/sdX3
|
||||
|
||||
# Remove VG
|
||||
vgremove myvg
|
||||
```
|
||||
|
||||
### Logical Volumes
|
||||
|
||||
```bash
|
||||
# Create LV
|
||||
lvcreate -n mylv -L 10G myvg
|
||||
|
||||
# Display LV information
|
||||
lvdisplay
|
||||
lvs
|
||||
|
||||
# Resize LV
|
||||
lvresize -L +5G myvg/mylv
|
||||
lvresize -L 15G myvg/mylv
|
||||
|
||||
# Remove LV
|
||||
lvremove myvg/mylv
|
||||
```
|
||||
|
||||
## Ändern der Größe verschlüsselter LVM-Disks
|
||||
|
||||
Bei Verwendung von LVM mit LUKS-Verschlüsselung (häufige Konfiguration) ist der vollständige Größenänderungs-Workflow:
|
||||
|
||||
**Example from [[Source - Arch Linux Cheat Sheet]]:**
|
||||
|
||||
```bash
|
||||
# 1. Expand the disk in virtualization layer (ESXi, etc.)
|
||||
# 2. Rescan SCSI bus to see expanded disk
|
||||
echo "1" > /sys/class/block/sdb/device/rescan
|
||||
|
||||
# 3. Verify disk size
|
||||
fdisk -l /dev/xyz
|
||||
|
||||
# 4. Check LUKS status
|
||||
cryptsetup status crypted
|
||||
|
||||
# 5. Resize LUKS container
|
||||
cryptsetup resize crypted
|
||||
|
||||
# 6. Verify LUKS status
|
||||
cryptsetup status crypted
|
||||
|
||||
# 7. Resize LVM Physical Volume
|
||||
pvresize /dev/mapper/crypted
|
||||
|
||||
# 8. Verify PV size
|
||||
pvdisplay
|
||||
|
||||
# 9. Allocate additional space to Logical Volume
|
||||
lvresize -L+750g /dev/isp/owncloud
|
||||
|
||||
# 10. Verify LV size
|
||||
lvs
|
||||
|
||||
# 11. Resize filesystem
|
||||
resize2fs /dev/mapper/isp-owncloud
|
||||
|
||||
# 12. Verify
|
||||
df -h
|
||||
```
|
||||
|
||||
## Snapshot-Verwaltung
|
||||
|
||||
```bash
|
||||
# Create snapshot
|
||||
lvcreate -L 1G -s -n mysnap /dev/myvg/mylv
|
||||
|
||||
# Mount snapshot (read-only)
|
||||
mount /dev/myvg/mysnap /mnt/snapshot
|
||||
|
||||
# Remove snapshot
|
||||
lvremove /dev/myvg/mysnap
|
||||
```
|
||||
|
||||
## Thin Provisioning
|
||||
|
||||
```bash
|
||||
# Create thin pool
|
||||
lvcreate -L 100G --thinpool mypool myvg
|
||||
|
||||
# Create thin LV
|
||||
lvcreate -V 10G --thin mypool -n mythinlv
|
||||
```
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[Disk Encryption]] (dm-crypt/LUKS) für verschlüsselte Volumes
|
||||
- **Läuft auf:** [[Arch Linux]] und andere Linux-Distributionen
|
||||
und andere Infrastruktur
|
||||
- **Teil von:** Speicherverwaltung in Linux-Systemen
|
||||
|
||||
## Bewährte Praktiken
|
||||
|
||||
1. **Aussagekräftige Namen verwenden:** VG- und LV-Namen sollten ihren Zweck beschreiben
|
||||
2. **Freien Speicher überwachen:** `vgs` und `lvs` regelmäßig verwenden
|
||||
3. **Metadaten sichern:** `vgcfgbackup` und `vgcfgrestore`
|
||||
4. **Partitionen ausrichten:** Richtige Ausrichtung für SSDs verwenden (normalerweise 1 MiB)
|
||||
5. **Redundanz erwägen:** Mirroring für kritische Daten verwenden
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Disk Encryption]] - dm-crypt/LUKS für verschlüsselte LVM
|
||||
- [[Arch Linux]] - Distribution mit LVM-Unterstützung
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://wiki.archlinux.org/title/LVM
|
||||
- https://sourceware.org/lvm2/
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [os, kernel, linux]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [amd-pstate, acpi-cpufreq, Kernel PM Governors, CPPC]
|
||||
sources: [Source - AMD Powermanagement CPU]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Quelloffener Betriebssystemkern; verwaltet Systemressourcen und Hardware-Abstraktion, einschließlich Power Management und CPU-Frequenzskalierung.
|
||||
---
|
||||
# Linux Kernel
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Der Linux-Kernel ist der Open-Source-Betriebssystem-Kernel, der das Kernstück von Linux-Distributionen darstellt. Er verwaltet Systemressourcen, Hardware-Abstraktion, Prozessverwaltung und bietet die Schnittstelle zwischen Hardware und User-Space-Anwendungen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Zentrale Betriebssystem-Komponente mit Hardware-Abstraktion und Ressourcenverwaltung
|
||||
- **Status:** Aktiv, laufend entwickelt
|
||||
- **Version:** 5.17+ (für amd-pstate-Unterstützung)
|
||||
- **Sprache/Technik:** C, Assembler
|
||||
- **Repository:** https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[amd-pstate]], [[acpi-cpufreq]], [[Kernel PM Governors]]
|
||||
- **Implementiert:** [[CPPC]]-Unterstützung über amd-pstate-Treiber
|
||||
- **Verwandt mit:** Power-Management-Subsystemen
|
||||
|
||||
## Details
|
||||
|
||||
### Power Management im Linux-Kernel
|
||||
|
||||
Der Linux-Kernel bietet ein umfassendes Power-Management-Framework, das Folgendes umfasst:
|
||||
|
||||
- **CPU-Frequenzskalierung:** Ermöglicht die dynamische Anpassung der CPU-Taktgeschwindigkeiten zur Ausbalancierung von Leistung und Stromverbrauch
|
||||
- **CPU-Leerlaufzustände:** Verwaltet CPU-Leistungszustände bei Untätigkeit (C-States)
|
||||
- **Leistungszustände:** Verwaltet CPU-Leistungszustände (P-States)
|
||||
- **Governoren:** Richtlinien, die bestimmen, wie die Frequenzskalierung durchgeführt wird
|
||||
|
||||
### Verbesserungen in Version 5.17
|
||||
|
||||
Der Linux-Kernel 5.17 führte bedeutende Verbesserungen zum AMD-CPU-Power-Management ein:
|
||||
|
||||
- Neuer **amd-pstate**-Treiber für AMD-Prozessoren
|
||||
- Unterstützung für CPPC (Collaborative Processor Performance Control)
|
||||
- Feinkörnigere Power-Management-Kontrolle
|
||||
- Bessere Energieeffizienz für mobile Geräte
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[amd-pstate]]
|
||||
- [[acpi-cpufreq]]
|
||||
- [[Kernel PM Governors]]
|
||||
- [[CPPC]]
|
||||
- [[Source - AMD Powermanagement CPU]]
|
||||
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-28
|
||||
related: [Modbus]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Leichtgewichtiges Publish-Subscribe-Protokoll für die Kommunikation von IoT-Geräten über TCP/IP-Netze.
|
||||
---
|
||||
# MQTT
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
MQTT ist ein offenes, standardisiertes Messaging-Protokoll für die Kommunikation zwischen IoT- und anderen Geräten. Es ermöglicht leichtgewichtiges Publish-Subscribe-Messaging zwischen Geräten und zentralen Brokern über TCP/IP-Netze und wird häufig zusammen mit Home Assistant eingesetzt.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Page created via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Modbus]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Industrieprotokoll für sichere, standardisierte Gerätekommunikation mit semantischer Datenmodellierung.
|
||||
---
|
||||
# OPC UA
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
OPC UA (OPC Unified Architecture) ist ein modernes Industrieprotokoll, das sichere Geräte-zu-Geräte-Kommunikation mit reichhaltiger Datentypisierung und semantischer Modellierung bietet. Es ersetzt veraltete OPC-Protokolle für Industrial-IoT-Anwendungen und wird zusammen mit Modbus erwähnt.
|
||||
|
||||
## 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,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go, ha-core]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Interpretierte Programmiersprache, weit verbreitet für Backend-Dienste und Hausautomationsplattformen.
|
||||
---
|
||||
# Python
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Python ist eine höhere interpretierte Programmiersprache, bekannt für Lesbarkeit und schnelle Entwicklung. Sie ist die Implementierungssprache von Home Assistant und wird umfangreich in ha-core verwendet.
|
||||
|
||||
## 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 erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Systemprogrammiersprache, die Speichersicherheit ohne Garbage Collection bietet.
|
||||
---
|
||||
# Rust
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Rust ist eine Systemprogrammiersprache, die Speichersicherheit und sichere Parallelität betont. Sie bietet starke Speichergarantien ohne Garbage Collection mit einer Leistung vergleichbar mit C/C++; Aura verwendet sie zur Implementierung eines sicheren AUR-Helpers.
|
||||
|
||||
## 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 erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,61 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [wine, compatibility, gaming, glorious-eggroll]
|
||||
created: 2026-08-01
|
||||
modified: 2026-08-29
|
||||
related: [Wine, Bottles, Proton, Wine-Staging, Lutris]
|
||||
sources: [Source - Wine]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Eigene Wine-Builds von GloriousEggroll mit zusätzlichen Patches und Optimierungen für bessere Kompatibilität von Windows-Anwendungen und -Spielen unter Linux.
|
||||
---
|
||||
# Wine GE
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Wine GE (GloriousEggroll) ist eine Sammlung benutzerdefinierter [[Wine]]-Builds, gepflegt von GloriousEggroll, mit zusätzlichen Patches und Optimierungen zur Verbesserung der Kompatibilität mit Windows-Anwendungen und Spielen unter Linux. Diese Builds enthalten häufig Patches aus Wine-Staging sowie zusätzliche spielfokussierte Verbesserungen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Erweiterte Wine-Builds für Gaming- und Anwendungskompatibilität
|
||||
- **Status:** Aktiv, von der Community gepflegt
|
||||
- **Maintainer:** GloriousEggroll
|
||||
- **Website:** https://github.com/GloriousEggroll/wine-ge-custom
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erweitert:** [[Wine]]
|
||||
- **Enthält:** [[Wine-Staging]]-Patches (typischerweise)
|
||||
- **Verwendet in:** [[Bottles]] (GE Wine und GE Proton Runtimes)
|
||||
- **Verwandt mit:** [[Proton]], [[Lutris]], [[Bottles]]
|
||||
|
||||
## Details
|
||||
|
||||
### Bottles-Integration
|
||||
|
||||
Wine GE ist in [[Bottles]] über zwei Runtimes verfügbar:
|
||||
|
||||
- **GE Wine:** Reiner Wine GE Build
|
||||
- **GE Proton:** Wine Valve + Wine-Staging + Proton + Steam (verwendet GE-Patches)
|
||||
|
||||
### Kernfunktionen
|
||||
|
||||
- Gaming-fokussierte Optimierungen
|
||||
- Zusätzliche Direct3D-Patches
|
||||
- Verbesserungen des Media-Foundation
|
||||
- Bessere Controller-Unterstützung
|
||||
- Verschiedene anwendungsspezifische Fixes
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Wine]]
|
||||
- [[Bottles]]
|
||||
- [[Proton]]
|
||||
- [[Wine-Staging]]
|
||||
- [[Lutris]]
|
||||
- [[Source - Wine]]
|
||||
|
||||
@@ -0,0 +1,62 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [wine, compatibility, patches, gaming]
|
||||
created: 2026-08-01
|
||||
modified: 2026-08-29
|
||||
related: [Wine, Bottles, Proton, Wine GE]
|
||||
sources: [Source - Wine]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Experimenteller Entwicklungszweig von Wine mit ungetesteten Patches und Funktionen vor der Aufnahme upstream; dient als Erprobungsfeld für neue Wine-Funktionalität.
|
||||
---
|
||||
# Wine-Staging
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Wine-Staging ist ein Entwicklungszweig von [[Wine]], der experimentelle Patches und Features enthält, die noch nicht in den Haupt-Wine-Baum integriert wurden. Diese Patches enthalten häufig Leistungsverbesserungen, Bugfixes und neue Funktionalität, die vor der Upstream-Akzeptanz getestet werden.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Testfeld für Wine-Patches und Features
|
||||
- **Status:** Aktiv, experimentell
|
||||
- **Betreuer:** Wine-Staging-Team
|
||||
- **Website:** https://wine-staging.github.io/
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erweitert:** [[Wine]]
|
||||
- **Verwendet von:** [[Bottles]] (enthalten in Soda, Caffe, Vaniglia, GE Proton Runtimes)
|
||||
- **Verwandt mit:** [[Proton]], [[Wine GE]], [[Arch Linux]]
|
||||
|
||||
## Details
|
||||
|
||||
### Aufnahme in Bottles-Runtimes
|
||||
|
||||
Wine-Staging-Patches sind in den folgenden [[Bottles]]-Runtimes enthalten:
|
||||
|
||||
- **Soda:** Wine Valve + Wine-Staging + Proton
|
||||
- **Caffe:** Wine Upstream + Wine-Staging + Proton
|
||||
- **Vaniglia:** Wine Upstream + Wine-Staging
|
||||
- **GE Proton:** Wine Valve + Wine-Staging + Proton + Steam
|
||||
|
||||
### Patch-Kategorien
|
||||
|
||||
Wine-Staging-Patches enthalten typischerweise:
|
||||
- Leistungsoptimierungen
|
||||
- Direct3D-Verbesserungen
|
||||
- Media-Foundation-Unterstützung
|
||||
- Verschiedene Bugfixes für bestimmte Anwendungen und Spiele
|
||||
- Experimentelle Features, die auf Upstream-Überprüfung warten
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Wine]]
|
||||
- [[Bottles]]
|
||||
- [[Proton]]
|
||||
- [[Wine GE]]
|
||||
- [[Source - Wine]]
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [kernel, driver, power-management, acpi, cpu]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Linux Kernel, amd-pstate, Kernel PM Governors, amd-pstate vs acpi-cpufreq]
|
||||
sources: [Source - AMD Powermanagement CPU]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Linux-Kerneltreiber für die CPU-Frequenzskalierung von Prozessoren nach dem ACPI-Standard.
|
||||
---
|
||||
# acpi-cpufreq
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
acpi-cpufreq ist ein Linux-Kerneltreiber, der CPU-Frequenzskalierung für Prozessoren mit dem ACPI-Standard (Advanced Configuration and Power Interface) implementiert. Er war der primäre Energieverwaltungstreiber für AMD-CPUs vor der Einführung von amd-pstate.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** CPU-Frequenzskalierung und Energieverwaltung
|
||||
- **Status:** Aktiv (Legacy für AMD, wird noch als Fallback verwendet)
|
||||
- **Typ:** Kerneltreiber
|
||||
- **Standard:** ACPI (Advanced Configuration and Power Interface)
|
||||
- **Schnittstelle:** sysfs
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Hängt ab von:** [[Linux Kernel]]
|
||||
- **Verwendet von:** AMD-CPUs (vor amd-pstate)
|
||||
- **Ersetzt durch:** [[amd-pstate]] für neuere AMD-CPUs
|
||||
- **Arbeitet mit:** [[Kernel PM Governors]] (schedutil, ondemand, conservative, powersave, performance)
|
||||
- **Fallback für:** [[amd-pstate]] auf inkompatiblen Systemen
|
||||
- **Verglichen in:** [[amd-pstate vs acpi-cpufreq]]
|
||||
|
||||
## Details
|
||||
|
||||
### Leistungszustände (P-States)
|
||||
|
||||
acpi-cpufreq reguliert CPU-Leistung mit diskreten **P-States** (Performance States):
|
||||
|
||||
- **P-State 0:** Volle Leistung (maximale Frequenz)
|
||||
- **P-State 1:** Zwischenlleistung
|
||||
- **P-State 2:** Niedrigste Leistung (minimale Frequenz)
|
||||
|
||||
Bei AMD-Prozessoren war acpi-cpufreq auf diese **3 P-States** beschränkt, was eine grobe Kontrolle über CPU-Leistung und Stromverbrauch bot.
|
||||
|
||||
### Betrieb
|
||||
|
||||
Der Treiber:
|
||||
1. Liest verfügbare P-States aus ACPI-Tabellen
|
||||
2. Stellt diese Status über sysfs-Schnittstelle bereit
|
||||
3. Erlaubt Governoren, passende P-States basierend auf Systemlast auszuwählen
|
||||
4. Behandelt Übergänge zwischen Zuständen
|
||||
|
||||
### Einschränkungen für AMD
|
||||
|
||||
- Nur 3 Leistungszustände verfügbar (grobe Granularität)
|
||||
- Weniger effizient als CPPC-basierte Ansätze
|
||||
- Begrenzte Möglichkeit zur Optimierung für Energieeffizienz auf modernen AMD-Prozessoren
|
||||
|
||||
### Aktueller Status
|
||||
|
||||
Während amd-pstate jetzt der bevorzugte Treiber für AMD-CPUs mit CPPC-Unterstützung ist, bleibt acpi-cpufreq wichtig als:
|
||||
- **Fallback-Treiber** wenn amd-pstate nicht initialisiert werden kann
|
||||
- **Treiber für ältere Hardware** ohne CPPC-Unterstützung
|
||||
- **Referenzimplementierung** für ACPI-basierte CPU-Frequenzskalierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Linux Kernel]]
|
||||
- [[amd-pstate]]
|
||||
- [[Kernel PM Governors]]
|
||||
- [[Source - AMD Powermanagement CPU]]
|
||||
- [[amd-pstate vs acpi-cpufreq]]
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [kernel, driver, power-management, amd, cpu]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Linux Kernel, acpi-cpufreq, Kernel PM Governors, CPPC, amd-pstate vs acpi-cpufreq]
|
||||
sources: [Source - AMD Powermanagement CPU]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Linux-Kerneltreiber für das Power Management von AMD-Prozessoren über die CPPC-Schnittstelle; löst acpi-cpufreq ab.
|
||||
---
|
||||
# amd-pstate
|
||||
|
||||
**Typ:** technology
|
||||
|
||||
## Beschreibung
|
||||
|
||||
amd-pstate ist ein Linux-Kerneltreiber, der in Version 5.17 eingeführt wurde und Energieverwaltung für AMD-Prozessoren mithilfe der CPPC-Schnittstelle (Collaborative Processor Performance Control) bietet. Er ersetzt den älteren ACPI-basierten Ansatz mit einem feingranularerem und effizienteren Mechanismus zur Steuerung von CPU-Leistung und Stromverbrauch.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** CPU-Energieverwaltung für AMD-Prozessoren
|
||||
- **Status:** Aktiv (eingeführt in Linux 5.17)
|
||||
- **Typ:** Kerneltreiber
|
||||
- **Schnittstelle:** sysfs
|
||||
- **Hardware-Anforderung:** AMD-CPUs mit CPPC-Unterstützung (neuere Generationen, sowie einige Zen2- und Zen3-Modelle)
|
||||
- **Kernel-Commit:** [c22760885fd6](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c22760885fd6)
|
||||
- **Dokumentation:** Documentation/admin-guide/pm/amd-pstate.rst
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Hängt ab von:** [[Linux Kernel]] 5.17+
|
||||
- **Implementiert:** [[CPPC]] (Collaborative Processor Performance Control)
|
||||
- **Ersetzt:** [[acpi-cpufreq]] für AMD-CPUs auf unterstützter Hardware
|
||||
- **Verwendet von:** [[Kernel PM Governors]] (schedutil, ondemand)
|
||||
- **Fällt zurück auf:** [[acpi-cpufreq]] auf inkompatiblen Systemen
|
||||
- **Verglichen in:** [[amd-pstate vs acpi-cpufreq]]
|
||||
|
||||
## Details
|
||||
|
||||
### Funktionen
|
||||
|
||||
- **Feinere Granularität:** Bietet präzisere Kontrolle über CPU-Leistungszustände im Vergleich zu den 3 P-States, die acpi-cpufreq anbietet
|
||||
- **Hardware-Hinweise:** CPPC-Hardware bietet Leistungsziele und Hinweise, die Governor auswerten können
|
||||
- **Dynamische Regulierung:** Ermöglicht feingranulare Systemregulation basierend auf Workload und Stromanforderungen
|
||||
- **Energieeffizienz:** Reduziert Stromverbrauch, besonders vorteilhaft für mobile Geräte, wo es die Akkulaufzeit verlängert
|
||||
|
||||
### Kompatibilität
|
||||
|
||||
- **Unterstützte Hardware:** Neuere AMD-CPU-Generationen, sowie einige Zen2- und Zen3-Modelle
|
||||
- **Fallback-Mechanismus:** Wenn amd-pstate nicht initialisiert werden kann oder auf inkompatible Hardware läuft, fällt der Kernel automatisch auf acpi-cpufreq zurück
|
||||
- **Governor-Unterstützung:** Funktioniert mit vorhandenen Kernel-Governoren wie schedutil und ondemand
|
||||
|
||||
### Verwendung
|
||||
|
||||
Der Treiber stellt seine Konfiguration und Status über die sysfs-Schnittstelle bereit und ermöglicht:
|
||||
- Anzeigen von aktuellen Leistungszuständen
|
||||
- Anpassung von Energieverwaltungsparametern
|
||||
- Überwachung von CPPC-bezogenen Metriken
|
||||
|
||||
## Historie
|
||||
|
||||
- **2022-03-20:** Eingeführt in Linux Kernel 5.17
|
||||
- **2022:** Initiale Bereitstellung auf AMD Zen2- und Zen3-Prozessoren
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Linux Kernel]]
|
||||
- [[acpi-cpufreq]]
|
||||
- [[Kernel PM Governors]]
|
||||
- [[CPPC]]
|
||||
- [Kernel Commit c22760885fd6](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c22760885fd6)
|
||||
- [[Source - AMD Powermanagement CPU]]
|
||||
- [[amd-pstate vs acpi-cpufreq]]
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: technology
|
||||
tags: [engine, framework, memory, llm]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Agent Memory, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Kern-Engine, die die Infrastruktur für persistente Speicher von KI-Agenten und die Umsetzung des Wissensgraphen bereitstellt.
|
||||
---
|
||||
# iii Engine
|
||||
|
||||
**Typ:** Technology (Engine/Framework)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
[iii-engine](https://github.com/iii-hq/iii) ist das zugrundeliegende Engine-/Framework, auf dem [agentmemory](https://github.com/rohitg00/agentmemory) aufgebaut ist. Es bietet die Kerninfrastruktur zur Implementierung von persistenten Speicher- und Wissensverwaltungssystemen für AI-Agenten.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Core Engine für AI-Agent-Memory- und Wissenssysteme
|
||||
- **Status:** Aktiv
|
||||
- **Repository:** [github.com/iii-hq/iii](https://github.com/iii-hq/iii)
|
||||
- **Verwendet von:** [[Agent Memory]]
|
||||
|
||||
## Funktionen
|
||||
|
||||
Die iii-engine ermöglicht die Implementierung von:
|
||||
|
||||
- Persistenter Speicherung und Abruf
|
||||
- Knowledge-Graph-Strukturen
|
||||
- Entity-Extraktion und Beziehungsverwaltung
|
||||
- Event-gesteuerte Automatisierungs-Hooks
|
||||
- Skalierbare Suchfunktionen
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet von:** [[Agent Memory]]
|
||||
- **Implementiert:** [[LLM Wiki Pattern]]-Infrastruktur
|
||||
- **Unterstützt:** [[Knowledge Graph]]-Strukturen
|
||||
- **Ermöglicht:** [[Event-Driven Automation]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Agent Memory]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Graph]]
|
||||
- [[Event-Driven Automation]]
|
||||
@@ -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