kb/concepts/ bekommt Areas: layout: fuer concept, Area-Titel aus jedem Type-Spec, Schwellen-Empfehlung im lint (schliesst #59)
Files changed: - CHANGES.md - README.md - VERSION - kb/concepts/Ambient Environment Dependency.md - kb/concepts/Anti-Cramming Heuristic.md - kb/concepts/Audit Trail.md - kb/concepts/BM25.md - kb/concepts/Bulk Operations.md - kb/concepts/CI Integration.md - kb/concepts/COLLECTION.md - kb/concepts/CPPC.md - kb/concepts/Checkpoint Audit.md - kb/concepts/Claude Code Auto Mode.md - kb/concepts/Command Round-Trip Integrity.md - kb/concepts/Confidence Scoring.md - kb/concepts/Consolidation Tiers.md - kb/concepts/Content Quality Control.md - kb/concepts/Context Isolation.md - kb/concepts/Contradiction Resolution.md - kb/concepts/Cross-platform Agent Skills.md - kb/concepts/Crystallization.md - kb/concepts/Delete Rather Than Anonymize.md - kb/concepts/Denylist over Allowlist.md - kb/concepts/Detect-Repair Asymmetry.md - kb/concepts/Diff-Reviewable Agent Edits.md - kb/concepts/Dual Licensing by File Plan.md - kb/concepts/Entity Extraction.md - kb/concepts/Episodic Memory.md - kb/concepts/Event-Driven Automation.md - kb/concepts/Filter on Ingest.md - kb/concepts/Forgetting.md - kb/concepts/Graph Traversal.md - kb/concepts/Green Suite Blind Spot.md - kb/concepts/Hooks.md - kb/concepts/Hybrid Search.md - kb/concepts/INDEX.md - kb/concepts/Implementation Spectrum.md - kb/concepts/Index Scaling.md - kb/concepts/Issue Label Scheme.md - kb/concepts/Iteration and Cost Limits.md - kb/concepts/KB Migration.md - kb/concepts/KB Stack Versioning.md - kb/concepts/Knowledge Compounding.md - kb/concepts/Knowledge Graph.md - kb/concepts/LLM Wiki Pattern.md - kb/concepts/Lint Workflow.md - kb/concepts/MCP-Leseserver.md - kb/concepts/Mass-Update Gate.md - kb/concepts/Memory Lifecycle.md - kb/concepts/Mesh Sync.md - kb/concepts/Modbus.md - kb/concepts/Multi-Agent Collaboration.md - kb/concepts/Naming Convention Conflict.md - kb/concepts/OKF Compatibility.md - kb/concepts/Optional Instance Context File.md - kb/concepts/Personalization Plane.md - kb/concepts/Privacy and Governance.md - kb/concepts/Procedural Memory.md - kb/concepts/Publish-Remote Gate.md - kb/concepts/Quality Scoring.md - kb/concepts/Quality and Self-Correction.md - kb/concepts/RAG.md - kb/concepts/Reciprocal Rank Fusion.md - kb/concepts/SSD TRIM.md - kb/concepts/Scale Ceiling.md - kb/concepts/Self-Healing.md - kb/concepts/Semantic Lint Automation.md - kb/concepts/Semantic Memory.md - kb/concepts/Session Orientation.md - kb/concepts/Shared vs Private.md - kb/concepts/Split Merge Reclassify.md - kb/concepts/Split Threshold.md - kb/concepts/Structural Enforcement over Documented Rule.md - kb/concepts/Stub Threshold.md - kb/concepts/Supersession.md - kb/concepts/Three-Layer Architecture.md - kb/concepts/Token Economics.md - kb/concepts/Typed Relationships.md - kb/concepts/User Management.md - kb/concepts/Vector Search.md - kb/concepts/Work Coordination.md - kb/concepts/Workflow Extraction.md - kb/concepts/Workflow Orchestration.md - kb/concepts/Working Memory.md - kb/concepts/Write-Once Frontmatter Fields.md - kb/concepts/architectures/Consolidation Tiers.md - kb/concepts/architectures/Context Isolation.md - kb/concepts/architectures/Cross-platform Agent Skills.md - kb/concepts/architectures/Episodic Memory.md - kb/concepts/architectures/Hybrid Search.md - kb/concepts/architectures/Implementation Spectrum.md - kb/concepts/architectures/Knowledge Graph.md - kb/concepts/architectures/LLM Wiki Pattern.md - kb/concepts/architectures/MCP-Leseserver.md - kb/concepts/architectures/Memory Lifecycle.md - kb/concepts/architectures/OKF Compatibility.md - kb/concepts/architectures/Optional Instance Context File.md - kb/concepts/architectures/Personalization Plane.md - kb/concepts/architectures/Procedural Memory.md - kb/concepts/architectures/RAG.md - kb/concepts/architectures/Scale Ceiling.md - kb/concepts/architectures/Semantic Memory.md - kb/concepts/architectures/Three-Layer Architecture.md - kb/concepts/architectures/Token Economics.md - kb/concepts/architectures/Working Memory.md - kb/concepts/decisions/Delete Rather Than Anonymize.md - kb/concepts/decisions/Denylist over Allowlist.md - kb/concepts/decisions/Diff-Reviewable Agent Edits.md - kb/concepts/decisions/Dual Licensing by File Plan.md - kb/concepts/decisions/Issue Label Scheme.md - kb/concepts/decisions/KB Stack Versioning.md - kb/concepts/decisions/Structural Enforcement over Documented Rule.md - kb/concepts/patterns/Audit Trail.md - kb/concepts/patterns/BM25.md - kb/concepts/patterns/Command Round-Trip Integrity.md - kb/concepts/patterns/Confidence Scoring.md - kb/concepts/patterns/Contradiction Resolution.md - kb/concepts/patterns/Entity Extraction.md - kb/concepts/patterns/Filter on Ingest.md - kb/concepts/patterns/Forgetting.md - kb/concepts/patterns/Graph Traversal.md - kb/concepts/patterns/Mesh Sync.md - kb/concepts/patterns/Quality Scoring.md - kb/concepts/patterns/Reciprocal Rank Fusion.md - kb/concepts/patterns/Self-Healing.md - kb/concepts/patterns/Shared vs Private.md - kb/concepts/patterns/Typed Relationships.md - kb/concepts/patterns/Vector Search.md - kb/concepts/patterns/Work Coordination.md - kb/concepts/problems/Ambient Environment Dependency.md - kb/concepts/problems/Detect-Repair Asymmetry.md - kb/concepts/problems/Green Suite Blind Spot.md - kb/concepts/problems/Naming Convention Conflict.md - kb/concepts/problems/Write-Once Frontmatter Fields.md - kb/concepts/protocols/CPPC.md - kb/concepts/protocols/Modbus.md - kb/concepts/protocols/SSD TRIM.md - kb/concepts/workflows/Anti-Cramming Heuristic.md - kb/concepts/workflows/Bulk Operations.md - kb/concepts/workflows/CI Integration.md - kb/concepts/workflows/Checkpoint Audit.md - kb/concepts/workflows/Claude Code Auto Mode.md - kb/concepts/workflows/Content Quality Control.md - kb/concepts/workflows/Crystallization.md - kb/concepts/workflows/Event-Driven Automation.md - kb/concepts/workflows/Hooks.md - kb/concepts/workflows/Index Scaling.md - kb/concepts/workflows/Iteration and Cost Limits.md - kb/concepts/workflows/KB Migration.md - kb/concepts/workflows/Knowledge Compounding.md - kb/concepts/workflows/Lint Workflow.md - kb/concepts/workflows/Mass-Update Gate.md - kb/concepts/workflows/Multi-Agent Collaboration.md - kb/concepts/workflows/Privacy and Governance.md - kb/concepts/workflows/Publish-Remote Gate.md - kb/concepts/workflows/Quality and Self-Correction.md - kb/concepts/workflows/Semantic Lint Automation.md - kb/concepts/workflows/Session Orientation.md - kb/concepts/workflows/Split Merge Reclassify.md - kb/concepts/workflows/Split Threshold.md - kb/concepts/workflows/Stub Threshold.md - kb/concepts/workflows/Supersession.md - kb/concepts/workflows/User Management.md - kb/concepts/workflows/Workflow Extraction.md - kb/concepts/workflows/Workflow Orchestration.md - kb/index.md - kb/log.md - tools/CONTRACT.md - tools/README.md - tools/chemenu/catalog.py - tools/chemenu/commands/index_build.py - tools/chemenu/lint_core.py - tools/chemenu/tests/conftest.py - tools/chemenu/tests/test_cite_cmd.py - tools/chemenu/tests/test_git_publish.py - tools/chemenu/tests/test_index_build.py - tools/chemenu/tests/test_lint.py - tools/chemenu/tests/test_new_page.py - tools/chemenu/tests/test_provenance.py - tools/chemenu/tests/test_type_resolver.py - tools/chemenu/tests/test_xref.py - types/concept.md - types/type-spec.md
This commit is contained in:
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [cramming, heuristic, pages, creation]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Iteration and Cost Limits
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Regel gegen \xFCberladene Seiten: ab dem dritten Absatz zu einem Unterthema eine eigene Seite anlegen"
|
||||
---
|
||||
# Anti-Cramming Heuristic
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Die Anti-Cramming-Heuristik ist eine Entscheidungsregel, die hilft zu bestimmen, wann eine neue dedizierte Seite erstellt werden soll und wann Inhalte zu einer vorhandenen Seite hinzugefügt werden sollen. Sie verhindert das „Überladen" von zu vielen lose verbundenen Themen auf einer einzigen Seite.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Farza's Rule:** „Wenn du einen dritten Absatz über ein Unterthema zu einer vorhandenen Seite hinzufügst, verdient dieses Unterthema eine eigene Seite"[^s-llm-improvements-sonnet-analysis]
|
||||
- **Zweck:** Verhindert, dass Seiten zu unfokussierten Sammlungen lose verbundener Informationen werden
|
||||
- **Vorteile:** Verbessert die Navigierbarkeit, macht Informationen leichter zu finden, erhält Seitenkohärenz
|
||||
- **Aktuelle Lücke:** Die aktuelle CREATE- gegen UPDATE-Entscheidung basiert auf Urteilsvermögen statt auf expliziten Regeln[^s-llm-improvements-sonnet-analysis]
|
||||
- **Mechanische Prüfung:** Dies könnte als Lint-Heuristik implementiert werden, die erkennt, wenn eine Seite mehrere verschiedene Unterthemen enthält
|
||||
|
||||
## Beispiele
|
||||
|
||||
**Gute Anwendung:**
|
||||
- Du hast eine Seite über [[MQTT]]. Du möchtest Informationen über MQTT-Sicherheit hinzufügen. Du hast bereits 2 Absätze über MQTT-Sicherheit auf der MQTT-Seite. Zeit für eine dedizierte Seite zur MQTT-Sicherheit.
|
||||
|
||||
**Schlechte Anwendung (Überladen):**
|
||||
- Eine Seite über Heimautomation, die umfangreiche Abschnitte zu mehreren Protokollen enthält - jeweils mit 3+ Absätzen. Diese sollten separate Seiten sein.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Bei der Entscheidung, ob Inhalte zu einer vorhandenen Seite hinzugefügt oder eine neue erstellt werden sollen
|
||||
- Während der Seitenüberprüfung zur Identifikation überladener Seiten
|
||||
- Bei der Planung der Inhaltsorganisation
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Wenn das Unterthema inhärent Teil des Hauptthemas ist und eine Aufteilung künstlich wäre
|
||||
- Wenn der Inhalt kurz ist und die Seite gut organisiert bleibt
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,55 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Privacy and Governance
|
||||
- exemplifies: Implementation Spectrum
|
||||
- see-also: Mass-Update Gate
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Umkehrbare, protokollierte Operationen zum Massenlöschen, Exportieren, Zusammenführen oder Archivieren von Wiki-Inhalten, mit Freigabepflicht und Undo.
|
||||
---
|
||||
# Bulk Operations
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Ermöglicht sichere großflächige Änderungen, wobei jede Operation in der Audit Trail protokolliert wird, um versehentliche Datenverluste zu verhindern und die Untersuchung von Bulk-Operation-Ergebnissen zu ermöglichen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Privacy and Governance]]
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,106 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [pre-commit, hooks, automation, quality-control]
|
||||
created: 2026-08-03
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- invokes: wikitool
|
||||
- operates-on: Gitea Actions
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: 'CI/CD-Hooks vor dem Publish: ci.yml (Push/PR, Stack-Pfade, seit 1.8.1 mit Coverage-Messung ohne Schwelle) und nightly.yml (Zeitplan, schliesst die paths-ignore-Luecke fuer Content-Drift; schedule-Ausloesung seit 2026-09-01 bestaetigt) setzen Quality Gates durch'
|
||||
---
|
||||
# CI Integration
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
CI Integration bezieht sich auf die Einrichtung von Pre-Commit-Hooks und CI/CD-Pipelines, die automatisch Quality Gates durchsetzen, bevor Änderungen im Repository veröffentlicht werden. Dies stellt sicher, dass Regressionen früh abgefangen werden und das Wiki jederzeit strukturelle Integrität bewahrt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Umgesetzt, nicht mehr nur geplant:** `.gitea/workflows/ci.yml` läuft seit `1.2.0` bei jedem
|
||||
Push/PR auf Stack-Pfaden und führt `docs verify`, `instructions verify` und
|
||||
`lint --fail-on-error` aus, bevor `dist export` die Verteilung prüft.
|
||||
- **`paths-ignore` schließt Content-Commits explizit aus** (`kb/`, `raw/`, `work/`, `reports/`) -
|
||||
ein reiner Wiki-Publish löst also **keinen** CI-Lauf aus. Das ist gewollt (`publish` fasst bei
|
||||
jedem Ingest `kb/` an, die volle Suite dafür zu fahren wäre Lärm), öffnet aber eine Lücke:
|
||||
strukturelle Regression im Korpus selbst fällt zwischen zwei Content-Publishes niemandem auf.
|
||||
Siehe [[Gitea Actions]] für den Beleg, dass der Filter tatsächlich greift.
|
||||
- **Diese Lücke schließt ein zweiter, geplanter Workflow**, nicht ein Pre-Commit-Hook:
|
||||
`.gitea/workflows/nightly.yml` (seit 2026-08-31, Gitea-Issue #9) läuft `on: schedule` plus
|
||||
`workflow_dispatch` und fährt `doctor`, `docs verify`/`instructions verify`,
|
||||
`lint --fail-on-error`, `sources coverage` und `migrate status` unabhängig vom
|
||||
Push-Ereignis[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
Ein Workflow, der `doctor` auf einem frischen Checkout aufruft, braucht denselben Bootstrap
|
||||
wie ein neuer Clone (git-Identität, `instructions sync`) - sonst scheitert er an der eigenen
|
||||
Startbedingung, nicht am
|
||||
Korpus[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
~~Ob der `schedule`-Trigger auf dieser Gitea-Instanz tatsächlich feuert, ist noch
|
||||
unbeobachtet - bislang bewiesen nur, dass der Job selbst läuft~~ (Stand
|
||||
2026-08-31)[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
**Beobachtet seit 2026-09-01:** Run 90 feuerte als erster Lauf mit `"event":"schedule"`,
|
||||
exakt zur konfigurierten Cron-Zeit (`17 3 * * *` UTC), alle sieben Schritte grün - der
|
||||
Trigger funktioniert also auf diesem Gitea-1.26.1-Stand tatsächlich, Gitea-Issue #9 ist
|
||||
geschlossen.
|
||||
- **Fehlersichtbarkeit ist eine bewusste Nutzerentscheidung, kein Automatismus:** ein
|
||||
fehlgeschlagener `nightly`-Lauf meldet sich über Giteas eigene Run-Notification, nicht über ein
|
||||
automatisch angelegtes
|
||||
Issue[^s-conversation-nightly-drift-check-workflow-and-doctor-s-bootstrap-gap-session-2026-08-31].
|
||||
- Ein Pre-Commit-Hook (lokale Prüfung vor `git commit`) ist bisher **nicht** eingerichtet - beide
|
||||
bestehenden Workflows sind serverseitig.
|
||||
- **`ci.yml`s Tests-Schritt misst seit `1.8.1` Coverage und weist sie als Artefakt aus**, ohne
|
||||
Abbruchschwelle - siehe Messen vor Schwelle für die Begründung der Reihenfolge. Konfiguration
|
||||
in `tools/.coveragerc`, nicht `pytest.ini`, weil coverage.py Letzteres nicht liest.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- `ci.yml`: `docs verify` + `instructions verify` + `lint --fail-on-error` bei jedem
|
||||
Stack-Push/PR, danach `dist export` und ein Replay von `setup-instance.md` gegen die Export.
|
||||
- `nightly.yml`: dieselben Kernprüfungen auf einem Zeitplan statt auf einen Push, damit
|
||||
Korpus-Drift zwischen zwei Content-Publishes nicht unbemerkt bleibt.
|
||||
|
||||
## Implementierungshinweise
|
||||
|
||||
Beide Workflows teilen sich dieselbe Runner-Form (Debian trixie-slim, `nodejs` vor dem Checkout,
|
||||
`actions/checkout@v7`) - siehe [[Gitea Actions]] für die Begründung und die dort dokumentierten
|
||||
Fallstricke (fehlendes `node` im Image, git-Konfiguration im Job-Container, `doctor`s
|
||||
Bootstrap-Anspruch an eine Instanz statt an einen bloßen Checkout).
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- In jeder produktiven oder gemeinsam genutzten Wiki-Bereitstellung
|
||||
- Um Konsistenz über mehrere Mitwirkende durchzusetzen
|
||||
- Um Fehler vor Erreichen des Hauptzweigs abzufangen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- In früher Entwicklung, wenn sich Regeln häufig ändern
|
||||
- Für Single-Contributor-Test-Repos, bei denen manuelle Prüfungen ausreichend sind
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Lint Workflow]] (Lint ist eine Schlüssel-CI-Prüfung)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^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-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **invokes:** [[wikitool]]
|
||||
- **operates-on:** [[Gitea Actions]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [audit, checkpoint, rhythm, quality]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- see-also: Semantic Lint Automation
|
||||
- part-of: Content Quality Control
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Regelm\xE4\xDFiger Qualit\xE4tsrhythmus: Index und Backlinks alle 15 Eintr\xE4ge neu aufbauen, auf 0 neue Artikel pr\xFCfen, die 3 meistge\xE4nderten erneut lesen"
|
||||
---
|
||||
# Checkpoint Audit
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Das Checkpoint Audit definiert einen regelmäßigen Rhythmus für Qualitätssicherungsmaßnahmen, um Probleme früh zu erkennen und die Wiki-Integrität zu wahren. Es geht über strukturelle Linting hinaus und umfasst semantische Überprüfungen und Trendanalysen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Farza's Empfehlung:** Index und Rückverweise nach jedem 15. neuen Eintrag neu erstellen[^s-llm-improvements-sonnet-analysis]
|
||||
- **Überladen-Alarm:** Prüfen, ob 0 neue Artikel unerwartet erstellt wurden (deutet auf mögliches Überladen hin)[^s-llm-improvements-sonnet-analysis]
|
||||
- **Fokus-Überprüfung:** Die 3 am häufigsten geänderten Artikel vollständig erneut lesen, um Qualität sicherzustellen[^s-llm-improvements-sonnet-analysis]
|
||||
- **Aktuelle Lücke:** Die bestehende Wartungsroutine enthält nur „Vollständiges Linting alle 10 Quellen", ermangelt aber dieser tiefergehenden Qualitätsprüfungs-Komponente[^s-llm-improvements-sonnet-analysis]
|
||||
- **Zweck:** Erfasst Qualitätsprobleme, Drift und Inkonsistenzen, bevor sie sich verstärken
|
||||
|
||||
## Beispiele
|
||||
|
||||
**Nach 15 neuen Seiten:**
|
||||
- `wikitool index rebuild` ausführen, um alle Querverweise zu aktualisieren
|
||||
- Verifizieren, dass keine unerwarteten Seiten erstellt wurden (Überladen-Prüfung)
|
||||
- Die 3 am häufigsten geänderten Seiten seit der letzten Überwachung identifizieren
|
||||
- Diese 3 Seiten vollständig erneut lesen, um Qualität und Konsistenz sicherzustellen
|
||||
|
||||
**Aktueller Wiki-Status:**
|
||||
- Das Wiki hat derzeit 201+ Seiten (pro index.md)[^s-llm-improvements-sonnet-analysis]
|
||||
- Aktuelle Massenänderungen (z. B. die Lint-Operation vom 2026-07-31) erstellten 36 neue Seiten
|
||||
- Ein Checkpoint Audit nach solchen Operationen hätte Qualitätsprobleme aufgedeckt
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Nach jedem 15. hinzugefügten Seite zum Wiki
|
||||
- Nach Massenoperationen (Ingest, Lint, Update), die viele Seiten beeinflussen
|
||||
- Als Teil der regelmäßigen Wartungsroutine
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Bei einzelnen Seitenänderungen, die die Gesamtstruktur nicht beeinflussen
|
||||
- Wenn sich das Wiki in einem stabilen Zustand mit wenigen aktuellenÄnderungen befindet
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Semantic Lint Automation]] - Automatisierte Prüfungen, die manuelle Überwachung ergänzen
|
||||
- [[Content Quality Control]] - Qualitätsrahmen, den Überwachung unterstützt
|
||||
- Die bestehende Wartungsroutine - Aktueller Zeitplan, der Checkpoint Audits einbeziehen könnte
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Semantic Lint Automation]]
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [claude-code, permissions, auto-mode, harness, classifier]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related:
|
||||
- mechanism: Claude Code
|
||||
- contradicts: Diff-Reviewable Agent Edits
|
||||
sources: [Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'auto-Berechtigungsmodus von Claude Code: ein Klassifikator genehmigt Aktionen vor der Ausfuehrung statt nachzufragen; die Beschreibung stammt weit ueberwiegend aus zweiter Hand ueber einen Doku-Subagenten'
|
||||
---
|
||||
# Claude Code Auto Mode
|
||||
|
||||
**Typ:** Workflow
|
||||
|
||||
## Definition
|
||||
|
||||
`auto` ist ein Berechtigungsmodus von [[Claude Code]], kein Performance-Modus. Statt vor jeder
|
||||
Aktion eine Freigabe zu erfragen, lässt der Modus eine Aktion vorab bewerten und genehmigt sie,
|
||||
wenn sie in den erlaubten Bereich fällt. Er ist einer von sechs Werten für
|
||||
`--permission-mode`, neben `acceptEdits`, `bypassPermissions`, `manual`, `dontAsk` und
|
||||
`plan`[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
|
||||
## Belegschichten
|
||||
|
||||
Diese Seite ist ungewöhnlich uneinheitlich belegt, und das ist keine Nachlässigkeit, sondern der
|
||||
Zustand der Quelle. Wer die Seite benutzt, muss die Schicht mitlesen:
|
||||
|
||||
| Aussage | Schicht |
|
||||
|---|---|
|
||||
| Die sechs `--permission-mode`-Werte, die Version, der Inhalt von `~/.claude/settings.json`, der `dangerouslyDisableSandbox`-Parameter am Bash-Werkzeug | Lokal in der Sitzung bezeugt |
|
||||
| Klassifikator, Blocklist, Verfügbarkeit ab Version und Plan, Schaltwege, `permissions.defaultMode`-Falle, Konfigurationsschlüssel | Aus zweiter Hand: ein `claude-code-guide`-Subagent hat die Claude-Code-Dokumentation durchsucht und berichtet. Niemand in der Sitzung hat die Dokumentation selbst gelesen |
|
||||
| Ein Zusammenhang zwischen Bash-Präferenz und Sandbox | Unbelegt. Als Spekulation geäußert und vom Subagenten nicht bestätigt - steht hier nur, damit die Vermutung nicht ein zweites Mal für einen Befund gehalten wird |
|
||||
|
||||
`confidence_base` ist deshalb auf 0.50 gesetzt: eine einzelne, junge Quelle, deren
|
||||
substanzieller Teil über einen Vermittler kam.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Lokal belegt.** Auf Claude Code 2.1.251 nennt `claude --help` sechs Werte für
|
||||
`--permission-mode`; `auto` ist einer
|
||||
davon[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]. Das Bash-Werkzeug der
|
||||
Sitzung führt einen `dangerouslyDisableSandbox`-Parameter, ist also standardmäßig sandboxed,
|
||||
und das Scratchpad-Verzeichnis wird als ohne Berechtigungsabfragen nutzbar
|
||||
beschrieben[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
- **Arbeitsweise, aus zweiter Hand.** Dem Subagentenbericht zufolge lässt `auto` ein separates
|
||||
Klassifikator-Modell (voreingestellt Claude Sonnet 5) Aktionen vor der Ausführung bewerten,
|
||||
statt nachzufragen. Es genehmigt Leseoperationen und Dateiänderungen *innerhalb des
|
||||
Arbeitsverzeichnisses* selbsttätig, prüft alles übrige gegen eine feste Blocklist (Löschungen,
|
||||
Force-Pushes, Offenlegung von Zugangsdaten) und fällt bei Unsicherheit auf eine Rückfrage
|
||||
zurück - außer in nicht-interaktiven `-p`-Läufen, wo es diese Rückfrage nicht geben kann.
|
||||
- **Verfügbarkeit, aus zweiter Hand.** Eingebaute Voreinstellung auf den Plänen Pro, Max und
|
||||
Team ab Version 2.1.228 (macOS/Linux/WSL) beziehungsweise 2.1.233
|
||||
(Windows)[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
- **Umschalten.** `Shift+Tab` wechselt die Modi in einer laufenden Sitzung;
|
||||
`claude --permission-mode auto` beim Start; `permissions.defaultMode` in
|
||||
`~/.claude/settings.json` für eine Maschine, oder Managed Settings für eine Organisation.
|
||||
Einen `/auto`-Slash-Command gibt es **nicht** - die gegenteilige Behauptung fiel in derselben
|
||||
Sitzung und wurde dort zurückgenommen.
|
||||
- **Dokumentierte Falle.** Ein `"auto"` als `permissions.defaultMode` in einer *Projekt*-Datei
|
||||
`.claude/settings.json` oder `.claude/settings.local.json` wird ignoriert. Nur die globale
|
||||
Datei und Managed Settings nehmen den Wert
|
||||
an[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
- **Konfigurationsfläche** rund um den Modus: `autoMode.environment`,
|
||||
`permissions.allow`/`permissions.deny`,
|
||||
`disableAutoMode`[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
- **Die Bash-Präferenz ist nicht dokumentiert.** Der Modus injiziert eine Anweisung in die
|
||||
Sitzung, die das Bash-Werkzeug den dedizierten `Read`/`Edit`/`Write`-Werkzeugen vorzieht.
|
||||
Weder ihr Text noch eine Begründung stehen in der öffentlichen Dokumentation, und es wurde
|
||||
keine Einstellung gefunden, die sie einzeln abschaltet, ohne `auto` ganz zu verlassen. Was in
|
||||
diesem Wiki daraus folgt, steht auf [[Diff-Reviewable Agent Edits]].
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Als Standardmodus für Sitzungen an diesem Repository. Die Empfehlung der Sitzung war, in `auto`
|
||||
zu bleiben: der Ausstieg kostet Berechtigungsabfragen auf allem, während das einzige konkret
|
||||
benannte Problem - die Bash-Präferenz - durch eine stehende Arbeitsregel gelöst ist. In dieser
|
||||
Instanz enthält `~/.claude/settings.json` ohnehin nur `theme`, `inputNeededNotifEnabled` und
|
||||
`agentPushNotifEnabled` und kein
|
||||
`permissions.defaultMode`[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]; `auto`
|
||||
ist hier also die eingebaute Voreinstellung, keine getroffene Wahl.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Wenn Berechtigungsabfragen ausdrücklich auf Shell-Kommandos statt auf Edits liegen sollen. Der
|
||||
dafür genannte Gegenwert ist `permissions.defaultMode: "acceptEdits"` in der globalen
|
||||
Settings-Datei - praktisch die Umkehrung dieses Modus.
|
||||
- Als Erklärung dafür, *warum* die Bash-Präferenz existiert. Diese Seite kennt den Grund nicht,
|
||||
und eine plausible Ableitung wäre an dieser Stelle eine erfundene Tatsache.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Diff-Reviewable Agent Edits]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]: [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[Claude Code]]
|
||||
- **contradicts:** [[Diff-Reviewable Agent Edits]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [quality, lint, thresholds, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- composition: Semantic Lint Automation
|
||||
- composition: Stub Threshold
|
||||
- composition: Split Threshold
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Regeln und Schwellenwerte f\xFCr die Seitenqualit\xE4t: Mindestumfang f\xFCr Stubs, Aufteilungsschwellen und Zielwerte f\xFCr die Zeilenzahl"
|
||||
---
|
||||
# Content Quality Control
|
||||
|
||||
**Typ:** Arbeitsablauf
|
||||
|
||||
## Definition
|
||||
|
||||
Content Quality Control bezieht sich auf die Menge der Regeln, Schwellwerte und automatisierten Überprüfungen, die sicherstellen, dass Wiki-Seiten ein konsistentes Qualitäts- und Nützlichkeitsniveau beibehalten. Es umfasst Mindestanforderungen an Inhalte für Stub-Seiten, maximale Größenschwellwerte für das Aufteilen von Seiten und Stilrichtlinien für Ton und Wortlaut.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Stub-Minimum:** Farzas Skill definiert einen Stub als mindestens 3 Sätze oder 15 Zeilen Inhalt[^s-llm-improvements-sonnet-analysis]. Seiten unter diesem Schwellwert sollten entweder erweitert oder entfernt werden.
|
||||
- **Split-Schwellwert:** Seiten, die 120-150 Zeilen überschreiten, sollten in Betracht gezogen werden, um sie in mehrere fokussierte Seiten aufzuteilen[^s-llm-improvements-sonnet-analysis]. Pascalandys Schema schlägt 200 Zeilen als absolutes Maximum vor[^s-llm-improvements-sonnet-analysis].
|
||||
- **Zeilenzahl-Ziele:** Verschiedene Seitentypen können unterschiedliche ideale Zeilenzahl-Bereiche haben, obwohl die Sonnet-Analyse keine exakten Ziele über die Stub- und Split-Schwellwerte hinaus angibt.
|
||||
- **Aktuelle Lücke:** Die vorhandene lint.py überprüft strukturelle Probleme (fehlerhafte Links, verwaiste Seiten, Frontmatter), prüft aber nicht auf Seitengröße/Qualitätsschwellwerte[^s-llm-improvements-sonnet-analysis].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Eine Seite mit nur 5 Zeilen Inhalt und einem TODO-Platzhalter würde die Stub-Mindestprüfung fehlschlagen
|
||||
- Eine Seite mit 180 Zeilen, die mehrere verschiedene Themen abdeckt, würde den Split-Schwellwert überschreiten und sollte aufgeteilt werden
|
||||
- Das aktuelle index.md hat Abschnitte mit langen Tabellen (z.B. Systeme mit 20+ Einträgen), die sich den Skalierungsgrenzen nähern[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Bei der Seitenerstellung, um sicherzustellen, dass neue Seiten Mindestqualitätsstandards erfüllen
|
||||
- Bei regulären Lint-Operationen, um Seiten zu identifizieren, die Aufmerksamkeit benötigen
|
||||
- Vor Massenaktualisierungen, um zu überprüfen, dass Qualitätsschwellwerte eingehalten werden
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Seiten, die explizit als Stubs oder Platzhalter markiert sind (obwohl diese minimiert werden sollten)
|
||||
- Wenn der Inhalt von Natur aus Kürze erfordert (z.B. einfache Definitionsseiten)
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Index Scaling]] - Verwandte Skalierungsüberlegungen für die Index-Seite
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **composition:** [[Semantic Lint Automation]]
|
||||
- **composition:** [[Stub Threshold]]
|
||||
- **composition:** [[Split Threshold]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,158 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [crystallization, knowledge, distillation, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- part-of: Memory Lifecycle
|
||||
- rests-on: Event-Driven Automation
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Verdichten abgeschlossener Erkundungen, Debugging-Sitzungen und Recherchen zu strukturierten Wiki-Auszügen als eigenständige Wissensquellen.
|
||||
---
|
||||
# Crystallization
|
||||
|
||||
**Typ:** Arbeitsablauf (Wissensdestillation aus Erkundung)
|
||||
|
||||
## Definition
|
||||
|
||||
Crystallization ist der Prozess, bei dem eine **abgeschlossene Arbeitskette** (ein Forschungsthread, eine Debug-Sitzung, eine Analyse, eine Erkundung) genommen und **automatisch destilliert** wird in eine strukturierte Zusammenfassung. Das ursprüngliche Muster erwähnt, gute Antworten zurück ins Wiki zu organisieren; Crystallization geht weiter, indem es Erkundungen als erstklassige Quellen behandelt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Ohne Crystallization:
|
||||
- Wertvolle Erkenntnisse aus Erkundungssitzungen gehen verloren
|
||||
- Muster, die durch Debugging oder Forschung entdeckt werden, werden nicht erfasst
|
||||
- Jede Erkundung beginnt von vorne
|
||||
- Wissen wächst nicht aus abgeschlossener Arbeit
|
||||
|
||||
### Die Lösung
|
||||
|
||||
**Erkundungen als Quellen** behandeln - genau wie Artikel oder Arbeiten. Das Wiki sollte:
|
||||
1. Die Ergebnisse von Erkundungen aufnehmen
|
||||
2. Den Wissensgraphen aktualisieren
|
||||
3. Bestehende Aussagen stärken oder in Frage stellen
|
||||
|
||||
### Crystallization-Prozess
|
||||
|
||||
Für eine abgeschlossene Arbeitskette automatisch eine **strukturierte Zusammenfassung** erstellen:
|
||||
|
||||
**Zusammenfassungskomponenten:**
|
||||
| Komponente | Beschreibung | Beispiel |
|
||||
|-----------|-------------|---------|
|
||||
| **Frage** | Wie lautete die ursprüngliche Frage/Problem? | "Warum schlägt der Build fehl?" |
|
||||
| **Methode** | Welcher Ansatz wurde gewählt? | "Logs verfolgt, Abhängigkeiten überprüft" |
|
||||
| **Dateien/Entitäten** | Welche Dateien, Systeme, Entitäten waren beteiligt? | "Dockerfile, build.sh, Jenkins" |
|
||||
| **Erkenntnisse** | Was wurde entdeckt? | "Fehlende BuildKit-Abhängigkeit" |
|
||||
| **Lektionen** | Welche allgemeinen Lektionen ergaben sich? | "Immer BuildKit-Version überprüfen" |
|
||||
| **Ergebnis** | Wie war das Ergebnis? | "Durch Hinzufügen der BuildKit-Abhängigkeit repariert" |
|
||||
| **Verwandt** | Links zu verwandten Wiki-Seiten | "[[Docker]], [[Python]]" |
|
||||
|
||||
**Ausgabe:** Die Zusammenfassung wird zu einer **erstklassigen Wiki-Seite**, typischerweise in `kb/sources/` oder als Konzept-Seite.
|
||||
|
||||
### Was wird kristallisiert
|
||||
|
||||
| Arbeitstyp | Crystallization-Ausgabe |
|
||||
|-----------|----------------------|
|
||||
| Forschungsthread | Forschungsergebnisse-Seite |
|
||||
| Debugging-Sitzung | Debug-Analyse-Seite |
|
||||
| Analyse | Analyseergebnisse-Seite |
|
||||
| Deep Dive | Deep Dive-Zusammenfassung-Seite |
|
||||
| Vergleich | Vergleichsseite (siehe Vergleichsseite-Vorlage) |
|
||||
|
||||
### Automatisierung
|
||||
|
||||
Mit [[Event-Driven Automation]] integrieren:
|
||||
|
||||
**Trigger:** Bei Sitzungsende (oder expliziter Crystallization-Befehl)
|
||||
|
||||
**Maßnahmen:**
|
||||
1. Das Sitzungstranskript/Log analysieren
|
||||
2. Schlüsselinformationen extrahieren (Frage, Methode, Erkenntnisse, etc.)
|
||||
3. Involvierte Entitäten und Konzepte identifizieren
|
||||
4. Strukturierte Zusammenfassung erstellen
|
||||
5. Als neue Wiki-Seite organisieren
|
||||
6. Verwandte Entitäts-/Konzept-Seiten aktualisieren
|
||||
7. `kb/index.md` und `kb/log.md` aktualisieren
|
||||
8. Extrahierte Fakten zu angepassten [[Consolidation Tiers]] fördern
|
||||
|
||||
## Beispiel
|
||||
|
||||
**Sitzung:** Debugging von fehlgeschlagenen CI-Builds
|
||||
|
||||
**Crystallized Output:** `kb/sources/debug-ci-build-failure-2026-07-26.md`
|
||||
|
||||
```markdown
|
||||
# Debug: CI Build Failure - 2026-07-26
|
||||
|
||||
**Question:** Why are CI builds failing in the last 24 hours?
|
||||
|
||||
**Method:**
|
||||
- Checked CI logs for errors
|
||||
- Compared failing vs. passing builds
|
||||
- Reviewed recent changes
|
||||
- Tested locally
|
||||
|
||||
**Entities Involved:**
|
||||
- [[Docker]]
|
||||
- [[Gitea Actions]]
|
||||
|
||||
**Findings:**
|
||||
- Builds fail with "BuildKit not found" error
|
||||
- Recent update to BuildKit version in Dockerfile
|
||||
- Actions Cache Server connectivity issue
|
||||
|
||||
**Lessons:**
|
||||
- Remote BuildKit requires port 1234 to be accessible
|
||||
- Actions Cache Server needs host network mode
|
||||
- Version mismatches can cause silent failures
|
||||
|
||||
**Outcome:** Fixed by updating BuildKit configuration and network settings
|
||||
|
||||
**Related:**
|
||||
```
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Knowledge Compounding:** Erkenntnisse aus Erkundungen werden permanent erfasst
|
||||
- **Reduzierte Redundanz:** nicht die gleichen Probleme erneut debuggen
|
||||
- **Mustererkennung:** Lektionen entstehen über mehrere Crystallizations
|
||||
- **Automatische Dokumentation:** Erkundungen dokumentieren sich selbst
|
||||
- **Quellenvielfalt:** Erkundungen sind wertvolle Quellen neben Artikeln
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das für Forschung oder Debugging verwendet wird
|
||||
- Mehrseissions-Erkundungen
|
||||
- Situationen, in denen Erkundungseinsichten wertvoll sind
|
||||
- Domänen mit wiederkehrenden Problemen oder Mustern
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Triviale, einmalige Fragen
|
||||
- Situationen, in denen der Overhead nicht gerechtfertigt ist
|
||||
- Vollständig ad-hoc Erkundung (keine Struktur zum Kristallisieren)
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Consolidation Tiers]] - Wo kristallisiertes Wissen befördert wird
|
||||
- [[Knowledge Compounding]] - Der Gesamteffekt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Implementation Spectrum]] (Crystallization als erweiterte Funktion)
|
||||
- [[Quality and Self-Correction]] (Sicherung der Qualität kristallisierten Inhalts)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Event-Driven Automation]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,193 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [automation, hooks, events, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- enables: Memory Lifecycle
|
||||
- rests-on: Hooks
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Muster, das automatische Auslöser an Wiki-Lebenszyklusereignisse hängt, um manuellen Pflegeaufwand und das Risiko der Verwahrlosung zu senken.
|
||||
---
|
||||
# Event-Driven Automation
|
||||
|
||||
**Typ:** Workflow (Automatisierte Wiki-Wartung)
|
||||
|
||||
## Definition
|
||||
|
||||
Event-Driven Automation ist die Implementierung von **automatischen Triggern**, die in Reaktion auf bestimmte Ereignisse im Lebenszyklus des Wiki ausgelöst werden und die manuelle Wartungslast eliminieren, die viele Wikis zur Aufgabe führt. Dies wird in [[Source - LLM Wiki v2]] als "die größte praktische Lücke" im ursprünglichen Muster identifiziert.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Das ursprüngliche LLM-Wiki-Muster erfordert manuelle Eingriffe für:
|
||||
- Aufnahme neuer Quellen
|
||||
- Ausführung von Lint-Operationen
|
||||
- Erfassung wertvoller Antworten
|
||||
- Überprüfung auf Widersprüche
|
||||
- Aktualisierung von Querverweisen
|
||||
|
||||
Diese manuelle Belastung ist der Hauptgrund, warum Menschen Wikis aufgeben.
|
||||
|
||||
### Die Lösung
|
||||
|
||||
Implementieren von **Hooks** (Event-Listern), die automatisch Aktionen auslösen:
|
||||
|
||||
## Ereignistypen und Aktionen
|
||||
|
||||
### 1. Bei neuer Quelle
|
||||
|
||||
**Auslöser:** Datei in Verzeichnis `raw/` abgelegt oder explizit aufgenommen
|
||||
|
||||
**Aktionen:**
|
||||
- [ ] Auto-Aufnahme der Quelle (Lesen und Extrahieren von Schlüsselinformationen)
|
||||
- [ ] Extrahieren strukturierter Entitäten (Personen, Projekte, Bibliotheken, Concepts)
|
||||
- [ ] Aktualisieren des [[Knowledge Graph]] mit neuen Entitäten und Beziehungen
|
||||
- [ ] Erstellen oder Aktualisieren von Wiki-Seiten (Quellenzusammenfassung, Entity-Seiten, Concept-Seiten)
|
||||
- [ ] Aktualisieren von `kb/index.md` mit neuen Einträgen
|
||||
- [ ] Eintrag in `kb/log.md` anfügen
|
||||
- [ ] Auslösen von [[Confidence Scoring]] für neue Aussagen
|
||||
- [ ] Überprüfung auf Widersprüche mit bestehendem Wissen
|
||||
|
||||
**Implementierung:** Dateisystem-Watcher oder expliziter Ingest-Befehl
|
||||
|
||||
### 2. Beim Sitzungsstart
|
||||
|
||||
**Auslöser:** Benutzer beginnt eine neue Sitzung mit dem LLM
|
||||
|
||||
**Aktionen:**
|
||||
- [ ] Relevanten Kontext aus dem Wiki basierend auf aktueller Aktivität laden
|
||||
- [ ] Verwandte Seiten aus vorherigen Sitzungen identifizieren
|
||||
- [ ] Hochvertrauensinformationen zuerst anzeigen
|
||||
- [ ] Veraltete oder niedrig-vertrauensvolle Informationen zur Überprüfung kennzeichnen
|
||||
- [ ] Verwandte Entitäten und Concepts vorschlagen
|
||||
|
||||
**Implementierung:** Session-Initialisierungs-Hook
|
||||
|
||||
### 3. Beim Sitzungsende
|
||||
|
||||
**Auslöser:** Benutzer beendet eine Sitzung
|
||||
|
||||
**Aktionen:**
|
||||
- [ ] Sitzung in Beobachtungen verdichten
|
||||
- [ ] Hauptergebnisse und Erkenntnisse extrahieren
|
||||
- [ ] Erkenntnisse als neue Wiki-Seiten erfassen, wenn Qualitätswert > Schwellenwert
|
||||
- [ ] Relevante Entity- und Concept-Seiten aktualisieren
|
||||
- [ ] Informationen bei Bedarf zu höheren [[Consolidation Tiers]] hochstufen
|
||||
- [ ] Querverweise aktualisieren
|
||||
|
||||
**Implementierung:** Session-Teardown-Hook
|
||||
|
||||
### 4. Bei einer Abfrage
|
||||
|
||||
**Auslöser:** Benutzer stellt eine Frage
|
||||
|
||||
**Aktionen:**
|
||||
- [ ] Wiki mit [[Hybrid Search]] durchsuchen
|
||||
- [ ] Antwort mit Zitaten synthetisieren
|
||||
- [ ] Qualitätswert für die Antwort berechnen
|
||||
- [ ] Falls Qualitätswert > Schwellenwert (z.B. 0,7):
|
||||
- Antwort als neue Wiki-Seite erfassen
|
||||
- `kb/index.md` aktualisieren
|
||||
- Zu `kb/log.md` anfügen
|
||||
- [ ] Verfolgung, welche Seiten aufgerufen wurden (für [[Confidence Scoring]]-Verstärkung)
|
||||
|
||||
**Implementierung:** Query-Preprocessing- und Postprocessing-Hooks
|
||||
|
||||
### 5. Bei Speicherschreibvorgängen
|
||||
|
||||
**Auslöser:** Neue Inhalte werden in das Wiki geschrieben
|
||||
|
||||
**Aktionen:**
|
||||
- [ ] Überprüfung auf Widersprüche mit bestehendem Wissen
|
||||
- [ ] Falls Widerspruch erkannt:
|
||||
- [[Contradiction Resolution]] auslösen
|
||||
- [[Supersession]] auslösen, falls neue Aussage höheres Vertrauen hat
|
||||
- [ ] [[Confidence Scoring]] für verwandte Aussagen aktualisieren
|
||||
- [ ] Querverweise aktualisieren
|
||||
- [ ] Seitenformatierung und -struktur validieren
|
||||
|
||||
**Implementierung:** Pre-Commit- und Post-Commit-Hooks
|
||||
|
||||
### 6. Nach Plan
|
||||
|
||||
**Auslöser:** Periodischer Timer (täglich, wöchentlich, monatlich)
|
||||
|
||||
**Aktionen:**
|
||||
- [ ] [[Lint Workflow]] ausführen (Integritätsprüfung des Wiki)
|
||||
- [ ] Konsolidierung durchführen (Informationen zu höheren Tiers hochstufen)
|
||||
- [ ] Aufbewahrungsverfall anwenden (graduelles [[Forgetting]] alter Informationen)
|
||||
- [ ] [[Confidence Scoring]] neu berechnen (monatlicher Verfall)
|
||||
- [ ] Überprüfung auf veraltete Aussagen (nicht bestätigt seit >90 Tagen)
|
||||
- [ ] Querverweisintegrität überprüfen
|
||||
|
||||
**Implementierung:** Cron-Jobs oder geplante Aufgaben
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Reduzierte Belastung:** Menschen konzentrieren sich auf Denken, nicht auf Erfassung
|
||||
- **Konsistenz:** Automatische Ausführung von Wartungsaufgaben
|
||||
- **Zuverlässigkeit:** Nichts fällt durch die Maschen
|
||||
- **Skalierbarkeit:** Wiki kann wachsen, ohne dass die Wartung proportional zunimmt
|
||||
- **Vertrauen:** Benutzer wissen, dass das Wiki immer aktuell ist
|
||||
|
||||
## Automatisierungsstufen
|
||||
|
||||
| Stufe | Beschreibung | Implementierte Ereignisse |
|
||||
|-------|-------------|-------------------|
|
||||
| **Stufe 1: Manuell** | Ursprüngliches Muster - alle Operationen manuell | Keine |
|
||||
| **Stufe 2: Basis** | Minimale Automatisierung | Bei neuer Quelle |
|
||||
| **Stufe 3: Standard** | Kernautomatisierung | Bei neuer Quelle, Nach Plan |
|
||||
| **Stufe 4: Erweitert** | Vollständige Automatisierung | Alle Ereignisse |
|
||||
|
||||
## Implementierungsleitfaden
|
||||
|
||||
Mit **Stufe 2 (Basis)** beginnen und Ereignisse nach Bedarf hinzufügen:
|
||||
|
||||
1. **Zuerst:** `Bei neuer Quelle` - beseitigt den größten Schmerz
|
||||
2. **Zweitens:** `Nach Plan` - regelmäßige Wartung
|
||||
3. **Drittens:** `Beim Sitzungsende` - erfasst den Sitzungswert
|
||||
4. **Viertens:** `Bei einer Abfrage` - automatische Wissenserkennung
|
||||
5. **Fünftens:** `Bei Speicherschreibvorgängen` - Qualitätssicherung
|
||||
6. **Sechstens:** `Beim Sitzungsstart` - Kontextladen
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das aktiv genutzt wird
|
||||
- Multi-Benutzer- oder Multi-Agent-Setups
|
||||
- Große oder wachsende Wissensdatenbanken
|
||||
- Situationen, in denen Wartungsbelastung ein Anliegen ist
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Kleine, statische Wikis (manuell kann ausreichend sein)
|
||||
- Situationen, in denen vollständige menschliche Kontrolle erforderlich ist
|
||||
- Sehr frühe Explorationsphase
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
- [[Quality and Self-Correction]] - Ergänzende Qualitätsmechanismen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Confidence Scoring]] (verwaltet durch Automatisierung)
|
||||
- [[Supersession]] (ausgelöst durch Automatisierung)
|
||||
- [[Consolidation Tiers]] (hochgestuft durch Automatisierung)
|
||||
- [[Forgetting]] (angewandt durch Automatisierung)
|
||||
- [[Hybrid Search]] (verwendet in Query-Automatisierung)
|
||||
- [[Contradiction Resolution]] (ausgelöst durch Automatisierung)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **enables:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Hooks]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,149 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [automation, events, triggers, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- grounds: Event-Driven Automation
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Mechanismus von Event-Listenern, der bei Wiki-Lebenszyklusereignissen wie Quellen-Ingest, Seitenänderung und Sitzungsende automatisch Aktionen auslöst.
|
||||
---
|
||||
# Hooks
|
||||
|
||||
**Typ:** Workflow (Event-Listener-Mechanismus)
|
||||
|
||||
## Definition
|
||||
|
||||
Hooks sind **Event-Listener**, die automatische Aktionen als Reaktion auf bestimmte Ereignisse im Lebenszyklus des Wiki auslösen. Sie sind der Implementierungsmechanismus für [[Event-Driven Automation]] und ermöglichen dem Wiki, automatisch auf Änderungen zu reagieren, ohne menschliche Eingriffe.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Der Mechanismus
|
||||
|
||||
Ein Hook besteht aus:
|
||||
1. **Ereignis:** Die Auslöserbedingung (z.B. Datei erstellt, Sitzung beendet)
|
||||
2. **Listener:** Code oder Logik, die das Ereignis erkennt
|
||||
3. **Aktion:** Die automatische Reaktion auf das Ereignis
|
||||
|
||||
### Hook-Typen
|
||||
|
||||
| Hook-Typ | Auslöser | Typische Aktionen |
|
||||
|-----------|---------|----------------|
|
||||
| **Pre-Ingest** | Vor Quellenverarbeitung | Quelle validieren, auf Duplikate prüfen |
|
||||
| **Post-Ingest** | Nach Quellenverarbeitung | Index aktualisieren, Operation protokollieren, Entitäten extrahieren |
|
||||
| **Pre-Write** | Vor dem Schreiben ins Wiki | Inhalte validieren, auf Widersprüche prüfen |
|
||||
| **Post-Write** | Nach dem Schreiben ins Wiki | Querverweise aktualisieren, Vertrauen neu berechnen |
|
||||
| **Pre-Delete** | Vor dem Löschen aus Wiki | Inhalte archivieren, keine Abhängigkeiten überprüfen |
|
||||
| **Post-Delete** | Nach dem Löschen aus Wiki | Index aktualisieren, Operation protokollieren, Referenzen bereinigen |
|
||||
| **Pre-Query** | Vor Abfrageverarbeitung | Kontext laden, relevante Seiten identifizieren |
|
||||
| **Post-Query** | Nach Abfrageverarbeitung | Antwort erfassen, falls wertvoll, Zugriffszeitstempel aktualisieren |
|
||||
| **Session Start** | Benutzer/Agent startet Sitzung | Aktuellen Kontext laden, relevante Seiten anzeigen |
|
||||
| **Session End** | Benutzer/Agent beendet Sitzung | Sitzung verdichten, Erkenntnisse erfassen, Kristallisierung auslösen |
|
||||
| **Geplant** | Timer (täglich/wöchentlich/monatlich) | Lint ausführen, Vertrauen verfallen lassen, Tiers konsolidieren |
|
||||
|
||||
### Implementierungsansätze
|
||||
|
||||
**1. Dateisystem-Watcher**
|
||||
- `raw/`-Verzeichnis auf neue Dateien überwachen
|
||||
- Ingest auslösen, wenn neue Datei erkannt
|
||||
- Vorteile: Einfach, funktioniert mit jedem Dateisystem
|
||||
- Nachteile: Auf dateibasierte Ereignisse beschränkt
|
||||
|
||||
**2. API/Webhook-basiert**
|
||||
- Wiki als Service mit Webhook-Endpunkten verfügbar machen
|
||||
- Externe Systeme posten Ereignisse an Webhooks
|
||||
- Vorteile: Flexibel, funktioniert mit externen Systemen
|
||||
- Nachteile: Erfordert Service-Infrastruktur
|
||||
|
||||
**3. In-Process-Hooks**
|
||||
- Hooks in LLM-Agent-Code integriert
|
||||
- Auslösen bei internen Ereignissen (Speicherschreibvorgang, Sitzungsende, etc.)
|
||||
- Vorteile: Vollständiger Zugriff auf internen Status, effizient
|
||||
- Nachteile: Eng mit Agent-Implementierung gekoppelt
|
||||
|
||||
**4. Plugin-System**
|
||||
- Ladbare Hook-Module
|
||||
- Hooks hinzufügen/entfernen, ohne Core-Code zu ändern
|
||||
- Vorteile: Erweiterbar, modular
|
||||
- Nachteile: Komplexer zu implementieren
|
||||
|
||||
### Hook-Konfiguration
|
||||
|
||||
Beispielkonfiguration in `AGENTS.md`:
|
||||
|
||||
```yaml
|
||||
hooks:
|
||||
- event: on_new_source
|
||||
action: auto_ingest
|
||||
enabled: true
|
||||
priority: high
|
||||
|
||||
- event: on_session_end
|
||||
action: compress_and_file
|
||||
enabled: true
|
||||
priority: medium
|
||||
threshold: 0.7 # Qualitätsschwelle für automatisches Erfassen
|
||||
|
||||
- event: on_schedule
|
||||
action: run_lint
|
||||
enabled: true
|
||||
schedule: "0 2 * * *" # Täglich um 2 Uhr
|
||||
|
||||
- event: on_memory_write
|
||||
action: check_contradictions
|
||||
enabled: true
|
||||
priority: high
|
||||
```
|
||||
|
||||
### Fehlerbehandlung
|
||||
|
||||
Hooks sollten **robust** sein:
|
||||
- Fehler sollten **protokolliert**, aber nicht die Hauptoperation blockieren
|
||||
- Wiederholungslogik für vorübergehende Fehler
|
||||
- Circuit Breaker für wiederholt fehlgeschlagene Hooks
|
||||
- Manuelle Außerkraftsetzungsmöglichkeit
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Automatisierung:** Reduziert manuelle Wartungslast
|
||||
- **Konsistenz:** Stellt sicher, dass Aktionen immer ausgeführt werden
|
||||
- **Erweiterbarkeit:** Einfaches Hinzufügen neuer Verhaltensweisen
|
||||
- **Entkopplung:** Trennt Auslöser von Aktionen
|
||||
- **Nachverfolgbarkeit:** Hook-Ausführungen können protokolliert werden
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki mit [[Event-Driven Automation]]
|
||||
- Wikis, in denen Wartungslast ein Anliegen ist
|
||||
- Multi-Benutzer- oder Multi-Agent-Setups
|
||||
- Produktions-Wikis
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Kleine, einfache Wikis, wo manuell ausreicht
|
||||
- Situationen, in denen Hook-Komplexität nicht gerechtfertigt ist
|
||||
- Vollständig statische Wikis
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Memory Lifecycle]] - Was Hooks helfen zu verwalten
|
||||
- [[Quality and Self-Correction]] - Qualitätsbezogene Hooks
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Supersession]] (ausgelöst durch Hooks)
|
||||
- [[Consolidation Tiers]] (hochgestuft durch Hooks)
|
||||
- [[Forgetting]] (angewandt durch Hooks)
|
||||
- [[Confidence Scoring]] (aktualisiert durch Hooks)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **grounds:** [[Event-Driven Automation]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,83 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [index, scaling, thresholds, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Split Threshold
|
||||
- operationalized-from: pascalandy schema
|
||||
- see-also: Iteration and Cost Limits
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Skalierungsregeln f\xFCr Indexseiten: Tabellenabschnitte ab 50 Eintr\xE4gen teilen, ab 200 Seiten _meta/topic-map.md anlegen"
|
||||
---
|
||||
# Index Scaling
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Index Scaling definiert Regeln und Schwellenwerte für den Zeitpunkt und die Art der Umorganisation der index.md-Seite des Wikis mit zunehmender Anzahl von Seiten. Dies stellt sicher, dass der Index bei der Skalierung des Wikis navigierbar und nützlich bleibt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Pascalndys Regel für Table-Aufteilung:** Index-Tabellabschnitte aufteilen, wenn sie 50 Einträge überschreiten[^s-llm-improvements-sonnet-analysis]
|
||||
- **Pascalndys Regel für Topic-Map:** Eine Datei `_meta/topic-map.md` erstellen, wenn die Gesamtanzahl der Seiten 200 überschreitet[^s-llm-improvements-sonnet-analysis]
|
||||
- **Aktueller Status:** Die aktuelle index.md hat 201+ Seiten, wobei einige Abschnitte lange Tabellen aufweisen (z. B. Systems mit 20+ Einträgen)[^s-llm-improvements-sonnet-analysis]
|
||||
- **Zweck:** Erhält die Nutzbarkeit des Index und verhindert, dass er zu einer einzigen überwältigenden Seite wird
|
||||
- **Implementierung:** Der Index wird derzeit von `wikitool index rebuild` aus dem Frontmatter der Seite generiert
|
||||
|
||||
## Beispiele
|
||||
|
||||
**Aktuelle index.md-Abschnitte:**
|
||||
- Entities (mit Unterkategorien: projects, systems, tools, technologies, people)
|
||||
- Concepts
|
||||
- Sources
|
||||
- Comparisons
|
||||
|
||||
**Wenn der Abschnitt Systems 50 überschreitet:**
|
||||
- In mehrere Tabellen aufteilen: Systems A-M, Systems N-Z
|
||||
- Oder nach Typ aufteilen: Home Automation Systems, Monitoring Systems usw.
|
||||
|
||||
**Wenn die Gesamtseiten 200 überschreiten:**
|
||||
- `_meta/topic-map.md` mit hierarchischer Organisation erstellen
|
||||
- Navigation auf hoher Ebene zwischen wichtigen Themenbereichen bereitstellen
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Hinzufügen neuer Seiten, die die Anzahl der Abschnitte in die Nähe der Schwellenwerte treibt
|
||||
- Bei regelmäßiger Wartung zur Überprüfung der Index-Organisation
|
||||
- Wenn Benutzer Schwierigkeiten bei der Navigation im Index melden
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Wenn die aktuelle Organisation gut funktioniert und unter den Schwellenwerten liegt
|
||||
- Für kleine Wikis mit wenigen Seiten
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Three-Layer Architecture]] - Index ist Teil der Wiki-Ebene
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Split Threshold]]
|
||||
- **operationalized-from:** [[pascalandy schema]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [gate, safety, iteration-budget, loop-breaker]
|
||||
created: 2026-08-07
|
||||
modified: 2026-09-02
|
||||
related:
|
||||
- compares-with: Mass-Update Gate
|
||||
- see-also: Anti-Cramming Heuristic
|
||||
- see-also: Index Scaling
|
||||
- mechanism: wikitool
|
||||
- exemplifies: Structural Enforcement over Documented Rule
|
||||
- see-also: MCP-Leseserver
|
||||
sources: [Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - MCP Read Server Implementation Session 2026-09-02]
|
||||
confidence: 0.88
|
||||
confidence_base: 0.88
|
||||
provenance: sourced
|
||||
summary: Im Code durchgesetzte Obergrenze von 60 wikitool-Aufrufen je Session, Loop-Breaker bei 3 identischen Wiederholungen, Slot-Erstattung, ein gemessenes Kalibrierungsband, und Retrieval sowie der MCP-Leseserver bleiben ausgenommen
|
||||
---
|
||||
# Iteration and Cost Limits
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Eine hart in Code durchgesetzte Obergrenze für die Anzahl der Tool-Aufrufe, die eine Agent-Sitzung machen darf, bevor sie stoppen und explizite menschliche Genehmigung zum Fortfahren einholen muss - im Gegensatz zu einer nur im Prompt formulierten Anweisung wie „Nach N Schritten stoppen", die ein Agent sich selbst rationalisieren kann („nur noch ein Aufruf zur Behebung"). Das Muster hat zwei Komponenten: ein **Iteration-Budget-Gate** (eine Gesamtaufrufobergrenze pro Sitzung) und einen **Loop-Breaker** (sofortiger Abbruch, wenn die letzten Aufrufe identisch sind, unabhängig von der Gesamtanzahl).[^s-llm-improvements-production-agent-gaps-2026]
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Faustregel der Industrie:** ~5-15 Tool-Aufrufe für eine einfache, einstufige Aufgabe; ~15-25 für einen komplexen Multi-Tool-Workflow; >30 ist eine dokumentierte Warnung für schlechte Aufgabenzerlegung oder eine festgefahrene Schleife.[^s-llm-improvements-production-agent-gaps-2026]
|
||||
- **In dieser Instanz gemessen (2026-08-31, `1.5.0`):** ~5-15 Aufrufe für eine einfache Aufgabe (gemessen 5-9), ~20-35 für einen komplexen Multi-Tool-Workflow. Das ist eine eigene Behauptung über diesen Stack, nicht eine Korrektur der darüberstehenden Branchen-Faustregel: die bleibt als belegte Aussage über den Stand der Technik stehen, die hier genannten Zahlen gelten für `wikitool`-Aufrufe in diesem Repository. Belegt sind sie durch die Sitzungszähler in `tools/.wikitool_session/budget.json`: `ingest-comma-bug-2026-08-31` 30 Aufrufe, `ingest-transcript-personalization-plane` 29, `ingest-issue-triage-2026-08-31` 26, `ingest-auto-mode-2026-08-31` 24. Jeder dieser vier gewöhnlichen Ingests lag auf oder über der Decke des zuvor dokumentierten Bandes von 15-25. Nachgezogen in `run_budget.py`, `instructions/gates.md` und den Skills `wiki-ingest` und `wiki-lint`; die Obergrenze von 60 blieb unverändert, weil sie kein Ziel ist, sondern der Punkt, ab dem eine Sitzung als festgefahren gilt.[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- **Eine Richtgröße, die der Normalfall überschreitet, ist keine Richtgröße.** Sie lehrt einen Agenten, dass die Zahlen dekorativ sind - genau das Versagen, gegen das ein in Code durchgesetztes Budget immun sein soll. `instructions/gates.md` hält deshalb seit `1.5.0` auch fest, woher die Zahl kommt und wie sie neu zu messen ist, und nennt dafür `tools/.wikitool_session/budget.json`: eine Richtgröße ohne Messvorschrift veraltet still.[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- **Warum reine Prompt-Limits scheitern:** Praktisch jeden dokumentierten Fall von „Agent hat Budget über Nacht aufgebraucht" führt auf die gleiche Grundursache zurück - keine in Code durchgesetzte Obergrenze, sondern nur als Prompt-Anleitung, die der Agent rationalisieren kann.[^s-llm-improvements-production-agent-gaps-2026]
|
||||
- **Loop-Breaker-Begründung:** Erfasst den spezifischen Ausfallmodus eines Agenten, der denselben fehlgeschlagenen Vorgang in einer Sackgasse „höflich wiederholt" - identischer Befehl + Argumente N-mal hintereinander - auch wenn das Gesamtiterations-Budget noch nicht erschöpft ist.[^s-llm-improvements-production-agent-gaps-2026]
|
||||
- **Implementiert (2026-08-07) in `tools/wikitool`:** Jeder Aufruf wird aufgezeichnet und in `main()` (`cli.py`) überprüft, bevor Typer an einen Subbefehl versendet, sodass kein einzelner Befehl manuell aktiviert werden muss. Der Status lebt in der gitignorierten `tools/.wikitool_session/budget.json`, indiziert nach `WIKITOOL_SESSION_ID` (oder als Fallback die Prozess-ID des aufgerufenen Shells), sodass eine neue Terminal/Sitzung mit einem neuen Budget startet. Standardobergrenze: seit Stack-Version `1.2.0` 60 Aufrufe/Sitzung, davor 30; Loop-Breaker-Fenster unverändert 3 identische Aufrufe hintereinander.[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31] Beide werden nur mit `--override-budget` umgangen, was der aufgerufene Agent nie von sich aus hinzufügen darf - nur nach expliziter menschlicher Genehmigung. Das verwandte [[Mass-Update Gate]] ging 2026-08-28 einen anderen Weg: Statt ein Bypass-Flag verwendet es einen dedizierten Code (42) mit der Bedeutung „ein Mensch muss dies sehen", und wird mit `--confirm <token>` gelöscht, bei dem der Token die exakte Dateiliste zusammenfasst - siehe diese Seite.
|
||||
- **Auch das Zurücksetzen ist gated (2026-08-13):** `budget status` ist von der Zählung ausgenommen, sodass die Situation nach dem Gate-Auslöser meldbar bleibt, aber `budget reset` nicht - und es erfordert zusätzlich sein eigenes `--yes`. Das Ausnehmen des Befehls, der den Zähler löscht, würde das ganze Gate zur Formalität machen, die ein Agent umgehen könnte, indem er zuerst zurücksetzt.
|
||||
- **Erstattung bei abgelehntem Aufruf (2026-08-31):** Das Budget soll Iteration zählen, nicht Reibung. Die Erstattung ist deshalb nicht auf den Exit-Code 1 gekeyt - das hätte `lint --fail-on-error` gratis gemacht, sobald es etwas findet -, sondern auf `_util.fail()`. `fail()` heißt: der Befehl hat abgelehnt, ein Argument zurückgewiesen oder als lesender Check Befunde gemeldet; es ist nichts passiert, also wird der Slot zurückgegeben. Ein Befehl, der seine Arbeit getan hat und danach ein Nicht-Null-Ergebnis meldet, wirft `typer.Exit(1)` direkt und bleibt gezählt. `record_and_check()` meldet zurück, ob es belastet hat, und `cli._run_traced` ruft im `finally`-Block `run_budget.refund()`. Der Aufruf bleibt in `recent`, damit der Loop-Breaker ihn weiterhin sieht - für eine wiederholt kaputte Invokation ist er das richtige Instrument, nicht der Zähler.[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- **Verworfene Alternative:** die Schreibstellen zu markieren (35 Stellen in 15 Dateien), um die Erstattung auf „es wurde nichts geschrieben" zu keyen. Das ist fail-open: eine neue Schreibstelle, die den Marker vergisst, schwächt still ein Gate.[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- **Obergrenze 30 → 60 (2026-08-31):** Das Kalibrierungsband (5-15 Aufrufe einfach, 15-25 komplex) blieb unangetastet, weil es die Arbeit beschreibt. Die Obergrenze beschrieb nichts und lag so dicht am Band, dass der Overhead eines realen Ingests sie allein erreichte. Der Loop-Breaker wurde bewusst **nicht** mitverdoppelt: er ist ein Detektor für drei identische Aufrufe und kein Budget, und eine Verdopplung ließe einen festgefahrenen Agenten doppelt so lange kreisen.[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31] Das Band selbst wurde noch am selben Tag in `1.5.0` an realen Läufen nachgemessen - siehe den gemessenen Punkt oben.[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- **Eskalation, nicht stilles Versagen:** Ein ausgelöstes Gate ist nicht flüchtig - das Wiederholen mit denselben Argumenten schlägt absichtlich identisch fehl. Die richtige Reaktion ist, zu stoppen, Fortschritt und Blockierer dem Benutzer zusammenzufassen und auf Anweisungen zu warten (siehe AGENTS.md-Abschnitte „Tool Error Contracts" und „Iteration and Cost Limits").
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Ein `wiki-ingest`-Lauf über eine große Quelle, die über 60 `wikitool`-Aufrufe hinaus weiterhin Entity-Seiten erstellt, löst das Iteration-Budget-Gate aus.
|
||||
- Ein Agent, der nach wiederholten Fehlschlägen `xref add --a X --b Y` dreimal hintereinander wiederholt, löst den Loop-Breaker beim vierten Versuch aus, bevor er je die 60-Aufrufobergrenze erreicht.
|
||||
- `tools/wikitool budget status` (kostenlos) / `tools/wikitool budget reset --yes [--all]` - Sichtbarkeits- und Zurücksetzbefehle für den sitzungsbezogenen Zähler.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jeder agentische Workflow, der eine unbegrenzte Anzahl von Malen über eine Sammlung variabler Größe (Seiten, Entities, Dateien) iterieren kann, ohne einen natürlichen Haltepunkt in den Daten selbst eingebettet zu haben.
|
||||
- Besonders relevant für die Skills `wiki-ingest`/`wiki-lint`, die viele Entity/Concept-Seiten, Cross-References und Lint-Durchläufe für eine einzelne Quelle berühren können.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Einzelne, begrenzte Einmalvorgänge, bei denen die Aufrufen-Anzahl inhärent festgelegt ist (z. B. ein einzelner `new entity`-Aufruf) - das Gate wird dort immer noch gleichmäßig angewendet, wird aber im Wesentlichen nie ausgelöst.
|
||||
- Als Ersatz für das [[Mass-Update Gate]], das auf den *Schadensradius* eines `publish` (Dateien, die von einem einzelnen Push betroffen sind) begrenzt ist, nicht auf die *Iterationsmenge* über eine Sitzung - die beiden Gates beheben unterschiedliche Ausfallmodi und beide bleiben notwendig.
|
||||
- Im [[MCP-Leseserver]]. Das Gate begrenzt eine Agenten-Session am unbemerkten Iterieren über den
|
||||
Wiki-Zustand - deshalb ist Retrieval bereits generell ausgenommen (`SKIP_COMMANDS`) -, nicht
|
||||
einen Nutzer, der oft sucht. Ein zu häufig suchender Nutzer ist ein Ressourcenproblem, das vor
|
||||
den Serverprozess gehört (Rate Limiting), nicht in dieses Gate - beide zu vermischen würde es
|
||||
zu einem Rate Limiter verwässern.[^s-mcp-read-server-implementation-session-2026-09-02]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-production-agent-gaps-2026]: [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration 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-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **compares-with:** [[Mass-Update Gate]]
|
||||
- **see-also:** [[Anti-Cramming Heuristic]]
|
||||
- **see-also:** [[Index Scaling]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **exemplifies:** [[Structural Enforcement over Documented Rule]]
|
||||
- **see-also:** [[MCP-Leseserver]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,134 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [migration, versioning, corpus-diff, workflow]
|
||||
created: 2026-08-30
|
||||
modified: 2026-08-31
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
- rests-on: KB Stack Versioning
|
||||
- see-also: Mass-Update Gate
|
||||
- see-also: Iteration and Cost Limits
|
||||
sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Migration des KB-Inhalts entlang einer geordneten Versionskette; abgegrenzt gegen offene Instanz-Aktionen, die in den doctor-Check gehoeren statt in die Kette
|
||||
---
|
||||
# KB Migration
|
||||
|
||||
**Typ:** Workflow
|
||||
|
||||
## Definition
|
||||
|
||||
KB Migration ist der Ablauf, mit dem der **Inhalt** einer Wissensbasis auf die Form gebracht
|
||||
wird, die eine neuere Stack-Version erwartet. Die Form des Inhalts hat eine eigene Version in
|
||||
`.wikitool-kb.json`, unabhängig von der Stack-Version in `VERSION`
|
||||
([[KB Stack Versioning]])[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
Eine Instanz kann Maschinerie `1.4.0` tragen, während ihr Inhalt noch in `1.2.0`-Form vorliegt;
|
||||
genau diesen Zustand durchläuft jedes Upgrade, und er ist der Grund für die Trennung.
|
||||
|
||||
Migrationen selbst sind `manual: true`-Anweisungen unter `instructions/migrations/`. Damit
|
||||
werden sie von `dist export` ohne zweiten Exportpfad
|
||||
mitgeliefert[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Die Kette ist ein Intervall, keine Fallunterscheidung.** `migrate status` bildet
|
||||
`(kb_version, VERSION]` aus den vorhandenen Migrationsdokumenten und ordnet aufsteigend. Von
|
||||
`1.3.1` nach `2.0.0` laufen `1.4.0`, dann `1.7.0`, dann `2.0.0`. Dass keine Migration auf
|
||||
`1.3.x` zielt, ist kein Sonderfall, sondern schlicht nicht im
|
||||
Intervall[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **`migrate done` verweigert jede Version, die nicht das nächste Glied ist.** Ein Sprung wird
|
||||
dadurch unmöglich, und ein unterbrochenes mehrstufiges Upgrade ist an der Stelle fortsetzbar,
|
||||
an der es
|
||||
abbrach[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **`1.0.0` ist die Basis.** Alles Ältere wird neu exportiert, nicht
|
||||
migriert[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Eine
|
||||
bestehende Instanz ohne `.wikitool-kb.json` erhält ihren Startwert über `migrate baseline`;
|
||||
der Entwicklungsbaum selbst war der erste Fall und bekam `1.0.0`, weil sein Inhalt seiner
|
||||
Maschinerie nie
|
||||
hinterherhing[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Zählen, nie Mengen vergleichen.** `kb_scan.extract_wikilinks()` liefert ein Set. Für `lint`
|
||||
ist das richtig - die Frage lautet, ob ein Verweis auflöst. Für eine Migrationsprüfung ist es
|
||||
falsch, denn dort lautet die Frage, ob einer verschwunden ist. Drei der vier Defekte, die die
|
||||
frühere Übersetzung des Korpus fand, hatten unveränderte Link-Mengen und nur veränderte
|
||||
Zählungen[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **`lint` kann eine Migration nicht absichern.** Die Negativkontrolle: eines von zwei
|
||||
`[[Docker]]`-Vorkommen aus `kb/entities/tools/Act Runner.md` entfernt, die Link-*Menge* damit
|
||||
unverändert. `migrate verify --from HEAD --fail-on-error` meldet
|
||||
`'Docker' 2->1`, `lint --fail-on-error` endet mit Exit 0 und schweigt über alle 21
|
||||
Checks[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. `lint` liest
|
||||
eine einzige Revision; ein verschwundener Verweis hinterlässt ein Korpus, das in sich
|
||||
vollkommen stimmig ist. Darauf ruht die gesamte Strategie.
|
||||
- **„Seite" muss überall dasselbe heißen.** Der erste Lauf von `migrate verify` über 248 Seiten
|
||||
meldete 13 „entfernte Seiten", die keine sind: Die historische Seite listete jede `.md` unter
|
||||
`kb/`, die Arbeitsbaum-Seite benutzte `iter_kb_pages`, das `COLLECTION.md`, `INDEX.md` und die
|
||||
Meta-Dateien der kb-Wurzel überspringt. Behoben durch ein gemeinsames
|
||||
`kb_scan.is_page_path`, festgehalten durch einen
|
||||
Regressionstest[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Kanonischer Name plus Aliase ist das Migrationsmuster.** `sections.py` dokumentiert es im
|
||||
eigenen Docstring: Es ist das, was ein Korpus Seite für Seite statt auf einen Schlag migrieren
|
||||
lässt - und das Entfernen eines Alias ist eine Breaking Change, keine
|
||||
Aufräumarbeit[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Zwei Größen, zwei Regeln.** Einheiten werden nach dem Iterationsbudget geschnitten,
|
||||
Batches getrennt davon nach dem [[Mass-Update Gate]]. Beides zu verwechseln kostete im ersten
|
||||
Schnitt des Plans elf unnötige
|
||||
Freigaben[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Pro Einheit zuerst die Struktur:** Frontmatter, H1, Wikilink-Ziele und Cite-IDs gegen `HEAD`
|
||||
vergleichen, bevor irgendetwas anderes geprüft wird. `lint` wird über jede Einheit vollständig
|
||||
gelesen, nicht nur über die vermeintlich betroffenen Abschnitte - der Frontmatter-Fehler der
|
||||
ersten Einheit tauchte als Schema-Fehler in einem Feld auf, das niemand bearbeitet
|
||||
hatte[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Zusammenfassungen schreibt die orchestrierende Sitzung**, nie aus einem Subagenten
|
||||
übernommen: Sie schmücken aus, etwa „measuring application performance and responsiveness" zu
|
||||
„Latenz und Durchsatz unter
|
||||
Lastbedingungen"[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - stellt `migrate list`/`status`/`verify`/`done`/`baseline` bereit und trägt die
|
||||
Prüfung `corpus diff`.
|
||||
- [[Chemenu]] - erster Fall für `migrate baseline`; `1.0.0` wurde ohne Migrationsdokument
|
||||
gesetzt, mit ausdrücklicher Begründung.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Sobald eine semantische Änderung am Inhalt ansteht, die eine bestehende Instanz nicht durch ein
|
||||
bloßes Stack-Update mitbekommt - eine geänderte Abschnittsbenennung, ein umbenanntes
|
||||
Frontmatter-Feld, ein umgezogenes Verzeichnis. Der `MAJOR`-Bump ohne Migrationsdokument wird von
|
||||
`version bump`
|
||||
verweigert[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Nicht für Änderungen, die nur die Maschinerie betreffen. Ein neuer Befehl ohne Wirkung auf die
|
||||
Form des Inhalts braucht kein Migrationsdokument.
|
||||
- Nicht mit einem mechanischen Runner für Null-Migrationen. Eine DSL dafür wurde bewusst nicht
|
||||
gebaut, solange es nichts zu automatisieren
|
||||
gibt[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- Nicht mit `lint` als Absicherung - siehe die Negativkontrolle oben.
|
||||
- **Nicht für eine offene Instanz-Aktion.** Die Maschinerie ist durchgehend auf Korpus-Form
|
||||
verdrahtet: `kb_version` beschreibt die Form des Inhalts, `migrate done` nimmt `--pages`,
|
||||
`migrate verify` vergleicht `kb/`. Eine Anforderung, die eine Instanz erfüllen muss, ohne
|
||||
dass sich eine Seite ändert - etwa das Anlegen von `USER.md`/`SOUL.md` aus der
|
||||
[[Personalization Plane]] - ist deshalb keine Migration, sondern ein Fall für einen
|
||||
`doctor`-Check. Ein Migrationsdokument dafür hätte zwei Kosten: `migrate done` würde
|
||||
`kb_version` heben und damit über den Inhalt etwas behaupten, das nicht über ihn gilt, und
|
||||
eine frische Instanz bekäme die Migration nie zu sehen, weil `dist export` ihr
|
||||
`kb_version = VERSION` mitgibt. Der Health-Check ist hier zudem das schärfere
|
||||
Werkzeug, weil er selbstprüfend ist: er meldet `FAIL`, bis die Sache erledigt ist, während
|
||||
`migrate done` eine Behauptung ist, die man ohne die Arbeit aufstellen kann.
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **rests-on:** [[KB Stack Versioning]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,132 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [knowledge-management, growth, learning]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: LLM Wiki Pattern
|
||||
- see-also: Memex
|
||||
- see-also: Tolkien Gateway
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Effekt, bei dem Wissen im Wiki an Wert gewinnt, weil jede neue Quelle an bestehende, untereinander verwiesene Seiten anknüpft und sie ergänzt.
|
||||
---
|
||||
# Knowledge Compounding
|
||||
|
||||
**Typ:** Workflow (Die Auswirkung des Aufbaus von Wissen auf sich selbst)
|
||||
|
||||
## Definition
|
||||
|
||||
Wissensakkumulation ist das Phänomen, bei dem sich Wissen so ansammelt, dass jedes neue Element auf bestehendem Wissen aufbaut und dessen Wert erhöht. Im Kontext des [[LLM Wiki Pattern]] bezieht sich dies auf die Auswirkung, dass das Wiki zunehmend wertvoll wird, da mehr Quellen hinzugefügt werden, weil jede neue Quelle von bestehenden Cross-References und Synthese profitiert und zu ihnen beiträgt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Der Akkumulationseffekt
|
||||
|
||||
> "Das Wiki wird mit jeder hinzugefügten Quelle und jeder gestellten Frage reicher."
|
||||
|
||||
Im Gegensatz zu traditionellen RAG-Systemen, bei denen jede Abfrage von vorne beginnt, erzeugt das LLM Wiki Pattern einen Akkumulationseffekt:
|
||||
|
||||
1. **Erste Quelle**: Wiki enthält zusammengefasste Informationen aus einem Dokument
|
||||
2. **Zweite Quelle**: Wiki fügt nicht nur neue Informationen hinzu, sondern:
|
||||
- Erstellt Cross-References zwischen den beiden Quellen
|
||||
- Markiert alle Widersprüche
|
||||
- Stärkt die Synthese durch die Kombination von Perspektiven
|
||||
3. **Nte Quelle**: Jede neue Quelle verbindet sich mit mehreren bestehenden Seiten und erzeugt einen Netzwerkeffekt
|
||||
|
||||
### Mathematische Analogie
|
||||
|
||||
Wenn traditionelles RAG den Wert V pro Abfrage bereitstellt:
|
||||
- RAG: V + V + V + ... = n × V
|
||||
|
||||
Mit Wissensakkumulation:
|
||||
- LLM Wiki: V + (V + C₁) + (V + C₁ + C₂) + ... = n × V + ΣC
|
||||
- Wobei Cᵢ der Akkumulationswert aus Verbindungen zu bestehendem Wissen ist
|
||||
|
||||
### Beispiele
|
||||
|
||||
#### Ein Buch lesen
|
||||
Traditioneller Ansatz:
|
||||
- Kapitel 1 lesen, Notizen machen
|
||||
- Kapitel 2 lesen, separate Notizen machen
|
||||
- Um Verbindungen zu verstehen, beide Notizensätze manuell überprüfen
|
||||
|
||||
LLM Wiki-Ansatz:
|
||||
- Kapitel 1 aufnehmen → erstellt Seiten für Charaktere, Themen, Orte
|
||||
- Kapitel 2 aufnehmen → aktualisiert bestehende Seiten mit neuen Informationen, erstellt Cross-References
|
||||
- Verbindungen zwischen Kapiteln werden automatisch beibehalten
|
||||
- Am Ende haben Sie ein reiches, verlinktes Companion-Wiki
|
||||
|
||||
#### Forschungsprojekt
|
||||
Traditionelles RAG:
|
||||
- Jedes Papier wird separat indiziert
|
||||
- Abfragen rufen Teile aus relevanten Arbeiten ab
|
||||
- Verbindungen zwischen Arbeiten werden nicht explizit verfolgt
|
||||
|
||||
LLM Wiki:
|
||||
- Jedes Papier aktualisiert Entity-Seiten (Autoren, Konzepte, Methoden)
|
||||
- Cross-References zeigen, welche Arbeiten welche zitieren/beziehen
|
||||
- Widersprüche zwischen Arbeiten werden markiert
|
||||
- Die Synthese wird mit jedem Papier reichhaltiger
|
||||
|
||||
### Fan-Wiki-Beispiel
|
||||
|
||||
[[Tolkien Gateway]] demonstriert Wissensakkumulation im Maßstab:
|
||||
- Tausende verlinkter Seiten über Tolkiens Legendarium
|
||||
- Von einer Gemeinschaft über Jahre gebaut
|
||||
- Jeder neue Artikel verbindet sich mit bestehenden Charakteren, Orten, Ereignissen
|
||||
- Der Wert des Ganzen ist größer als die Summe seiner Teile
|
||||
|
||||
Mit LLM Wiki Pattern:
|
||||
- Ein Einzelner kann ähnliche Ergebnisse in Wochen/Monaten erzielen
|
||||
- Das LLM übernimmt die Cross-Referencing automatisch
|
||||
- Der Mensch konzentriert sich auf Lesen und Richtung
|
||||
|
||||
## Vorteile
|
||||
|
||||
### Für den Benutzer
|
||||
- **Schnelleres Verständnis**: Verbindungen sind explizit und auffindbar
|
||||
- **Bessere Erinnerung**: Wissen ist organisiert und cross-referenziert
|
||||
- **Tiefere Einsichten**: Muster entstehen aus dem Netzwerk von Verbindungen
|
||||
- **Langfristiger Wert**: Das Wiki wird zu einem dauerhaften Vermögenswert
|
||||
|
||||
### Für die Wissensdatenbank
|
||||
- **Zunehmende ROI**: Jede neue Quelle fügt mehr Wert hinzu als die vorherige
|
||||
- **Netzwerkeffekte**: Verbindungen erzeugen exponentiellen Wert
|
||||
- **Emergente Eigenschaften**: Neue Einsichten entstehen aus dem vernetzten Wissen
|
||||
|
||||
## Messung der Akkumulation
|
||||
|
||||
### Metriken
|
||||
- **Verbindungsdichte**: Durchschnittliche Anzahl von Cross-References pro Seite
|
||||
- **Seitenwert-Wachstum**: Wie viel Wert jede neue Seite zum System hinzufügt
|
||||
- **Abfrage-Effizienz**: Zeit, die durch Beantwortung von Fragen aufgrund der bestehenden Synthese eingespart wird
|
||||
- **Einsicht-Häufigkeit**: Anzahl der neuen Einsichten, die durch Verbindungen entdeckt werden
|
||||
|
||||
### Indikatoren
|
||||
- Alte Seiten werden häufig mit neuen Verbindungen aktualisiert
|
||||
- Abfragen können durch Verfolgung von bestehenden Cross-References beantwortet werden
|
||||
- Neue Quellen erfordern minimale zusätzliche Verarbeitung
|
||||
- Das Wiki „fühlt sich" mit der Zeit reichhaltiger und stärker vernetzt an
|
||||
|
||||
## Historie
|
||||
|
||||
- [1945] - Vannevar Bushs [[Memex]]-Konzept stellt sich Wissen mit assoziativen Pfaden vor
|
||||
- [2020er] - Digitale Wikis (Wikipedia, Fan-Wikis) zeigen community-basierte Akkumulation
|
||||
- [2023-2024] - LLM Wiki Pattern ermöglicht individuelle Wissensakkumulation
|
||||
- [2026-07-26] - Concept-Seite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Three-Layer Architecture]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memex]]
|
||||
- **see-also:** [[Tolkien Gateway]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- see-also: Event-Driven Automation
|
||||
- part-of: Quality and Self-Correction
|
||||
- grounds: Detect-Repair Asymmetry
|
||||
- grounds: Green Suite Blind Spot
|
||||
sources: [Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: Deterministischer Health-Check rund um wikitool lint; seit 1.7.2 maskiert es Code vor dem Notation-Match und zaehlt Zitat-Bloecke statt Zeilen
|
||||
---
|
||||
# Lint Workflow
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Läuft nach Zeitplan (täglich/wöchentlich) ab und kann durch Memory-Write-Ereignisse ausgelöst werden; identifiziert strukturelle Probleme, repariert automatisch, was möglich ist, und markiert unlösbare Probleme zur Überprüfung durch Menschen. In diesem Wiki wird die strukturelle Hälfte deterministisch durch `wikitool lint` implementiert.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- Strukturelle Überprüfungen sind deterministisch und durch `tools/wikitool lint` erzwungen.
|
||||
- Der Workflow umfasst nun provenance-bewusste Überprüfungen: unabgedeckte Rohdateien, fehlerhafte `raw_files`-Referenzen, fehlende Provenance-Marker und Zitats-/Frontmatter-Versatz.
|
||||
- **Seit 2026-08-31 schreibt `lint` seinen Report immer**, standardmäßig nach `reports/Lint Report <datum>.md`, und gibt den Pfad aus; `--markdown` überschreibt weiterhin das Ziel. Vorher schrieb der Lauf ohne `--markdown` gar keine Datei und kippte den vollen Report nach stdout - es gab also keinen Pfad zu nennen und keinen Weg zurück in einen übersprungenen Abschnitt außer einem zweiten Lauf. Gedruckt werden jetzt nur Abschnitte mit Befunden; `--full` druckt alles, `--json` druckt die Befunde und schreibt nichts. `wiki-lint` und `wiki-status` sagen beide, die Datei zu lesen statt `lint` erneut aufzurufen, und `wiki-status` nimmt die Hub-Statistik aus der Reportdatei, weil sie eine Statistik und kein Befund ist.[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- Die Lint-Ausgabe kann mit `lint --markdown` auf eine andere Berichtsdatei unter `reports/` gelenkt werden. Seit 2026-08-21 ist ein Bericht **keine** Wiki-Seite: `types/lint-report.md` deklariert kein `base_dir:`, die Datei ist gitignoriert und wird weder schema-validiert noch indiziert. Seine strukturelle Hälfte kann bei Bedarf neu berechnet werden, daher ist nur die semantische Überprüfung dauerhaft - und diese muss vor Ende des Durchlaufs über `log append --op lint` in `kb/log.md` eingetragen werden.
|
||||
- **Seit 1.7.2 maskiert `lint` Code, bevor es Wiki-Notation matcht** (`chemenu/markdown_code.py`, `strip_code_spans`): ein `[^cite-id]` oder `[[Wikilink]]`, das eine Seite nur in Backticks oder einem Fence zeigt, zählt nicht mehr als echte Referenz. Vorher machte genau das eine Seite, die über die eigene Zitat-Syntax schrieb, zu einem Hard-Error - der einzige Ausweg war, die Notation zu umschreiben statt zu zeigen. Zwei Grenzen bewusst gezogen: eingerückte Codeblöcke bleiben unmaskiert (meist Listenfortsetzung), Inline-Spannen nur zeilenlokal (ein vergessener Backtick soll keinen Absatz stumm maskieren). Sechs Prüfungen laufen jetzt darüber; der Korpus hatte die spiegelbildliche Gewohnheit - 12 Zitatmarker standen selbst in Codeblöcken und wurden auf `Quelle:`-Zeilen darunter verschoben.
|
||||
- **Das Zitat-Limit zählt seit 1.7.2 Zitate, nicht `>`-Zeilen** (`count_quote_blocks`): vorher zählte ein umbrochenes Einzelzitat als so viele Zeilen wie es Umbruch hatte, was Autoren dazu brachte, die Seite schlechter lesbar zu machen, um den Lint zu beruhigen. `QUOTE_LIMIT` bleibt bei 2.
|
||||
- `lint` meldet kaputte `raw_files:`-Referenzen zuverlässig, aber kein Befehl repariert sie. Diese Lücke ist als [[Detect-Repair Asymmetry]] beschrieben und als Gitea-Issue #14 offen.[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- Die semantische Überprüfung bleibt eine Urteilsphase: Widersprüche, veraltete Aussagen und Empfehlungen für Folgseiten werden vom LLM nach der strukturellen Scanausgabe abgeschlossen.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Provenance-Behebungsdurchlauf (2026-08-03): Alle Lint-Kategorien erreichten null Ergebnisse nach Quellen-Backfill, Provenance-Markierung, Zitats-Ausrichtung und Index-Neuerstellungen.
|
||||
- Die Wrapper-Verstärkung in demselben Durchlauf behob die Behandlung relativer Pfade für die Lint-Markdown-Ausgabe und verhinderte Regressionen bei der Pfadauflösung bei Aufrufen aus dem Repo-Root.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- In geplanten Wartungsintervallen (z. B. nach mehreren Aufnahmen oder wöchentlich).
|
||||
- Unmittelbar nach Bulk-Aufnahme-/Update-Vorgängen, die viele Seiten betreffen.
|
||||
- Vor Veröffentlichungsvorgängen, wenn strukturelle Korrektheit und Provenance-Integrität überprüft werden müssen.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Als Ersatz für semantische Quellenaufnahme; Lint validiert Struktur und Konsistenz, nicht vollständige thematische Vollständigkeit.
|
||||
- Nur als einmaliger Setup-Schritt; Qualität verfällt, wenn Lint und semantische Überprüfung nicht wiederkehren.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Confidence Scoring]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Event-Driven Automation]]
|
||||
- **part-of:** [[Quality and Self-Correction]]
|
||||
- **grounds:** [[Detect-Repair Asymmetry]]
|
||||
- **grounds:** [[Green Suite Blind Spot]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [gate, safety, mass-update, confirmation]
|
||||
created: 2026-08-03
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- enables: Content Quality Control
|
||||
- mechanism: wikitool
|
||||
- see-also: Iteration and Cost Limits
|
||||
- exemplifies: Structural Enforcement over Documented Rule
|
||||
- contrasts: Bulk Operations
|
||||
- see-also: Publish-Remote Gate
|
||||
- see-also: MCP-Leseserver
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.88
|
||||
confidence_base: 0.88
|
||||
provenance: sourced
|
||||
summary: 'Mass-Update Gate: publish endet mit 42 (Freigabe durch den Menschen noetig) ab 10 gezaehlten Dateien; generierte Dateien und work/ werden committet\, aber seit 1.5.0 nicht gezaehlt; freigegeben per --confirm <token>'
|
||||
---
|
||||
# Mass-Update Gate
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausiert und explizite Bestätigung anfordert, bevor mit Vorgängen fortgefahren wird, die eine große Anzahl von Seiten betreffen würden. Dies verhindert versehentliche Massenänderungen und stellt sicher, dass beabsichtigte großflächige Änderungen überprüft werden.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Farzas Regel:** „Wenn ein Vorgang ≥10 Seiten ändert, halte an und fordere Bestätigung an"[^s-llm-improvements-sonnet-analysis]
|
||||
- **Zweck:** Verhindert versehentliche Massenaktualisierungen, die schwer rückgängig zu machen wären
|
||||
- **Begründung:** Ein `git push` zu `origin/main` ist die einzige Aktion in diesem System mit echten, irreversiblen externen Auswirkungen - sie ist sofort öffentlich sichtbar (Commit-Verlauf, mögliche CI-Auslöser, andere Clients ziehen) und ein Revert birgt immer noch Risiken. Jede andere wikitool-Schreiboperation ist lokal und billig rückgängig zu machen, daher ist das Gate speziell auf `publish` begrenzt, nicht auf jeden Befehl.
|
||||
- **Implementiert (2026-08-07):** `tools/wikitool publish` zählt die Dateien, die von `git status --porcelain` nach dem Staging berührt werden. Unter der Schwelle (Standard 10, `--threshold` zum Überschreiben) committed und pusht es automatisch, genau wie zuvor - Aufnahme-/Erstellungs-/Update-Vorgänge auf einzelnen Seiten werden nicht beeinflusst und führen nie zu Aufforderungen. Bei oder über der Schwelle wird 1 mit einem `Mass-Update Gate`-Fehler beendet, der jede geänderte Datei auflistet und weigert sich zu committen oder zu pushen.
|
||||
- **`--yes` zurückgezogen für einen Clearance-Exit-Code (2026-08-28):** Das Gate öffnete sich ursprünglich mit einem `--yes`-Flag, genehmigt durch einen Menschen, aber vom Agenten eingegeben - also lebte der Genehmigungsdatensatz nur in Konversation, nicht in irgendetwas, das das Tool oder ein späterer Leser überprüfen konnte. Drei Sitzungen zeigten die gleiche Form: `publish` ausführen, beobachten, wie es sich weigert, `--yes` erneut ausführen **in derselben Wendung**, technisch den dokumentierten Befehl befolgen, während kein Mensch die Dateiliste je sah. Der Ersatz hat drei Teile:
|
||||
- **Ein eigener Exit-Code.** Ein ausgelöstes Gate beendet sich mit **42** (`EXIT_NEEDS_CLEARANCE`), nicht 1 - ein drittes Ergebnis neben Erfolg und Validierungsfehler, bedeutet „ein Mensch muss diese Ausgabe sehen, bevor irgendetwas fortgeht". Ein Agent, ein Hook, eine CI-Aufgabe oder ein Scorer können es alle von „deine Eingabe war falsch, behebe es und versuche es erneut" unterscheiden.
|
||||
- **Die Prozedur lebt in der Ausgabe, nicht in der Anweisungsschicht.** Die Weigerung druckt, was sich ändern würde, jede gezählte Datei und die genaue `--confirm <token>`-Zeile, die sie veröffentlicht. `instructions/gates.md` sagt nur „zeige dem Benutzer die Ausgabe und halte an" - ein Rezept, das im Voraus aufgeschrieben ist, ist eines, das ein Agent von Anfang bis Ende ohne einen Menschen durchführen kann, was die drei Vorfälle jeweils aussahen.
|
||||
- **Der Token bindet Genehmigung an einen Changeset.** `--confirm` nimmt eine Zusammenfassung der gezählten Dateiliste plus des Veröffentlichungsziels, daher macht das Anfassen einer weiteren Datei es ungültig und das Gate fragt wieder mit der neuen Liste. `--yes` hatte das nie: Es veröffentlichte, was immer im Arbeitsbaum war, wenn es lief, nicht unbedingt was der Mensch sah.
|
||||
|
||||
**Was dies NICHT tut**, ehrlich gesagt: es beweist nicht, dass ein Mensch irgendetwas eingegeben hat. Der Token sitzt im eigenen Kontext des Agenten, und ein Agent, der das Gate umgehen möchte, kann dies tun. Das ist ein bewusster Kompromiss - ein früheres Design, das *tatsächlich* unabhängigen Beweis erforderte (ein Ticket von einem zweiten Terminal eingelöst) war korrekt und unbrauchbar, daher bleibt die Durchsetzung hier billig und die Frage „hat ein Mensch es wirklich genehmigt?" wurde auf die Eval-Schicht verschoben, wo `clearance-was-asked-for` und `clearance-ended-the-turn` (`tools/chemenu/evals/trajectory.py`) die ganze Flugbahn statt eines einzelnen Aufrufs sehen können.
|
||||
|
||||
- **Generierte Dateien zählen nicht mehr mit (`1.5.0`, 2026-08-31):** `kb/index.md`, `kb/log.md`, `kb/provenance.md` und jede `INDEX.md` werden weiterhin gestaged, committet und gepusht, gehen aber nicht mehr in die Zählung gegen die Schwelle ein - aus demselben Grund wie `work/`: sie tragen keine Entscheidung. Jede von ihnen ist über `index rebuild` bzw. `sources rebuild-index` aus dem Baum reproduzierbar, ihre Freigabe entscheidet also nichts und erzeugt nur die Prüfermüdung, gegen die die Schwelle existiert. Die Bausteine lagen bereits vor: `is_generated()` in `git_publish.py` kannte die Liste, `GATE_EXEMPT_PREFIXES = ("work/",)` und `counted_files()` boten den Mechanismus; verbunden waren beide nie, `is_generated` gruppierte nur die Anzeige unter „rebuilt by wikitool - no review needed". Gemessen an drei realen Ingests desselben Tages: 14 Dateien 14 → 9 gezählt, 16 → 9, 11 → 5 - alle drei hätten nicht mehr angehalten. Die Schwelle selbst blieb bei 10, und ein Test hält fest, dass zehn echte Seiten weiterhin auslösen, damit die Ausnahme nicht still zur Abschaltung wird.[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- **Zwei Konsequenzen der Ausnahme:** Die Weigerungszeile führt beide Gründe getrennt auf („3 under work/ and 5 generated by wikitool committed but not counted"), weil ein Prüfer die Differenz zwischen 14 geänderten und 9 gezählten Dateien sonst für einen Fehler hält - und weil Scratch-Zustand und abgeleitete Ausgabe nicht dasselbe sind. Und der `--confirm`-Token fasst seither nur noch zusammen, was ein Mensch tatsächlich gelesen hat: eine neu gebaute `INDEX.md` macht eine erteilte Freigabe nicht mehr ungültig.[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- **Das alte Zählverhalten war ungetestet.** Alle 67 Gate-Tests liefen grün, bevor die Tests für die Ausnahme geschrieben waren - kein Test hatte je behauptet, dass generierte Dateien mitgezählt werden. Ein Teil der Erklärung, warum es so lange unbemerkt blieb.[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- **Agent-Vertrag:** Exit 42 beendet die Wendung. Dem Benutzer die Ausgabe des Befehls wörtlich zeigen, einschließlich Dateiliste, und anhalten; die Ausgabe selbst benennt den nächsten Schritt. Siehe AGENTS.md-Abschnitt „Tool error contract" und `instructions/gates.md`.
|
||||
- **Ursprünglicher Vorschlag war breiter als das Gebaute:** Die früheste Analyse-Quelle schlug Bestätigungs-Gates vor jeder riskanten Massenoperation vor - auch vor Massen-Löschungen und Massen-Umklassifizierungen, mit einem konfigurierbaren Schwellenwert.[^s-llm-improvements-codex-analysis] Gebaut wurde davon nur der `publish`-Pfad; ein Lösch- oder Umklassifizierungs-Gate existiert nicht, aus demselben Grund, aus dem das Gate oben auf `publish` begrenzt bleibt - jeder andere `wikitool`-Schreibvorgang ist lokal und billig rückgängig zu machen.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- 2026-08-31 - Der Fix für die Gitea-Issues #12 und #13 berührte 21 Dateien. `publish` endete mit 42, druckte die Aufschlüsselung nach Bereich und die `--confirm`-Zeile; der Agent gab die vollständige Liste wieder und stoppte, Torben gab frei, der bestätigte Publish erzeugte `40adbb7` mit 593 Einfügungen und 73 Löschungen. Anschließend wurde gegen das Repository geprüft, dass `HEAD` gleich `origin/main` ist und `VERSION` `1.2.0` liest, statt der Erfolgszeile des Werkzeugs zu vertrauen[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-31 - Drei gewöhnliche Ingests (Comma Bug, Issue Triage, Auto Mode) blieben nacheinander am Gate stehen, obwohl keiner eine Massenänderung war. Die Beobachtung löste die Ausnahme für generierte Dateien aus; nachgerechnet lagen die drei Changesets danach bei 9, 9 und 5 gezählten Dateien[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
**Vorgänge, die das Gate auslösen:**
|
||||
- `wikitool xref link-source --entities E1,E2,E3,E4,E5,E6,E7,E8,E9,E10` (10+ entities), wenn direkt vor einem `publish` ausgeführt wird, das alle auf einmal bereitstellt
|
||||
- Massenaufnahme mehrerer Quelldateien auf einmal
|
||||
- Bulk-Seitenerstellung bei Lint-Fixes (wie die 2026-07-31-Operation, die 36 Seiten erstellte)
|
||||
|
||||
**Gate-Verhalten (wie in `tools/wikitool publish` implementiert):**
|
||||
- `git status --porcelain` zuerst (bevor irgendetwas bereitgestellt wird), um die genaue Anzahl und Liste der geänderten Dateien zu erhalten
|
||||
- Gezählt werden nur Dateien, die eine Entscheidung tragen: alles unter `work/` und alle generierten Dateien sind seit `1.5.0` von der Zählung ausgenommen, werden aber mit committet[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- Wenn Anzahl < Schwelle: Commit und Push sofort, wie immer
|
||||
- Wenn Anzahl >= Schwelle ohne passendes `--confirm <token>`: Exit **42**, drucke die Anzahlen, das Veröffentlichungsziel, die volle gezählte Dateiliste und die genaue `--confirm`-Zeile, die es veröffentlicht; nichts wird committet oder gepusht
|
||||
- Erneutes Ausführen mit diesem Token veröffentlicht normalerweise. Ein falsches, erfundenes oder überholtes Token beendet sich wieder mit 42 mit der aktuellen Liste, statt etwas zu veröffentlichen, das der Benutzer nicht sah
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Als Sicherheitsprüfung in wikitool CLI-Befehlen
|
||||
- Für Vorgänge, die viele Seiten ändern oder referenzieren
|
||||
- Wenn der Benutzer versehentliche Massenänderungen verhindern möchte
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Vorgänge auf einzelnen Seiten
|
||||
- Wenn der Benutzer explizit mit --force umgeht
|
||||
- In automatisierten Skripten, bei denen das Gate den nicht-interaktiven Gebrauch brechen würde
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Workflow Orchestration]] - Koordinierte Vorgänge, die Gates benötigen könnten
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
[^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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **enables:** [[Content Quality Control]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
- **exemplifies:** [[Structural Enforcement over Documented Rule]]
|
||||
- **contrasts:** [[Bulk Operations]]
|
||||
- **see-also:** [[Publish-Remote Gate]]
|
||||
- **see-also:** [[MCP-Leseserver]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [multi-agent, collaboration, sync, coordination]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Memory Lifecycle
|
||||
- composition: Mesh Sync
|
||||
- composition: Shared vs Private
|
||||
- composition: Work Coordination
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
provenance: sourced
|
||||
summary: Wissensmanagement mit mehreren Agenten; erweitert das LLM-Wiki-Muster um Mesh Sync, die Trennung von geteiltem und privatem Wissen und leichtgewichtige Arbeitskoordination.
|
||||
---
|
||||
# Multi-Agent Collaboration
|
||||
|
||||
**Typ:** Workflow (Multi-Agent Knowledge Management)
|
||||
|
||||
## Definition
|
||||
|
||||
Multi-Agent Collaboration behandelt die Realität, dass viele praktische Anwendungsfälle **mehrere Agenten oder mehrere Menschen** beinhalten, die zur gleichen Knowledge Base beitragen. Das ursprüngliche LLM-Wiki-Pattern ist Single-User, Single-Agent; v2 erweitert es auf Kollaborationsszenarien.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Single-Agent-Annahmen scheitern, wenn:
|
||||
- Mehrere Agenten parallel arbeiten (verschiedene Coding-Sessions, Recherchethreads)
|
||||
- Mehrere Menschen zur gleichen Knowledge Base beitragen
|
||||
- Wissen über Sessions oder Benutzer hinweg geteilt werden muss
|
||||
- Koordination erforderlich ist, um doppelte Arbeit zu verhindern
|
||||
|
||||
### Die Lösung: Drei Komponenten
|
||||
|
||||
**1. Mesh Sync**
|
||||
Wenn mehrere Agenten parallel arbeiten, müssen ihre Beobachtungen in ein gemeinsames Wiki zusammengeführt werden:
|
||||
|
||||
- **Standardstrategie:** Last-Write-Wins in den meisten Fällen
|
||||
- **Konfliktauflösung:** Zeitstempel-basiert mit manueller Anpassung
|
||||
- **Merge-Strategie:**
|
||||
- Kein Konflikt: Beide Aktualisierungen akzeptieren
|
||||
- Konflikt: Neuere bevorzugen oder zur menschlichen Überprüfung kennzeichnen
|
||||
- Semantischer Konflikt: [[Contradiction Resolution]] auslösen
|
||||
|
||||
**Implementierung:**
|
||||
```
|
||||
Agent A writes: "API rate limit is 100 req/min" (timestamp: 10:00:00)
|
||||
Agent B writes: "API rate limit is 100 req/min" (timestamp: 10:00:05)
|
||||
Result: Accept B (last-write-wins, no conflict)
|
||||
|
||||
Agent A writes: "API rate limit is 100 req/min" (timestamp: 10:00:00)
|
||||
Agent B writes: "API rate limit is 200 req/min" (timestamp: 10:00:05)
|
||||
Result: Flag for human review (conflict)
|
||||
```
|
||||
|
||||
**2. Shared vs. Private Knowledge**
|
||||
Nicht alles Wissen sollte gleichermaßen geteilt werden:
|
||||
|
||||
| Bereich | Beschreibung | Beispiel |
|
||||
|-------|-------------|---------|
|
||||
| **Private** | Persönliche Beobachtungen, Vorlieben, Workflows | "Mein bevorzugter Editor ist VS Code" |
|
||||
| **Shared** | Team-/Projektwissen, Entscheidungen, Architektur | "Projekt X verwendet Redis zum Caching" |
|
||||
|
||||
**Promotionsmodell:**
|
||||
- Mit privaten Beobachtungen beginnen
|
||||
- Zu Shared promovieren, wenn:
|
||||
- Information über mehrere Agenten überprüft ist
|
||||
- Information allgemein nützlich ist (nicht persönlich)
|
||||
- Mensch explizit als Shared markiert
|
||||
|
||||
**3. Work Coordination**
|
||||
Einfache Koordination, um doppelte Arbeit zu verhindern und Fortschritt zu verfolgen:
|
||||
|
||||
**Verfolgung:**
|
||||
- Wer arbeitet an was
|
||||
- Was ist blockiert (und warum)
|
||||
- Was ist fertig
|
||||
- Was braucht Überprüfung
|
||||
|
||||
**Implementierung:**
|
||||
- Statusfeld auf Seiten: `in-progress`, `blocked`, `done`, `needs-review`
|
||||
- Zuständigkeitsfeld: Welcher Agent/welche Person ist verantwortlich
|
||||
- Blockierungsbeziehungen: Seite A blockiert Seite B
|
||||
|
||||
**Kein vollständiges Task-Management-System** - nur genug, um doppelte Arbeit zu verhindern.
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
1. **Mesh Sync aktivieren** mit Konfliktauflösung
|
||||
2. **Scoping implementieren** (privat vs. geteilt)
|
||||
3. **Einfache Koordinationsfelder** zu Seiten hinzufügen
|
||||
4. **Mit [[Event-Driven Automation]]** für Sync-Trigger integrieren
|
||||
5. **Alle Multi-Agent-Operationen** in [[Audit Trail]] protokollieren
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Kollaboration:** Mehrere Agenten können zur gleichen Knowledge Base beitragen
|
||||
- **Effizienz:** Verhindert doppelte Arbeit
|
||||
- **Flexibilität:** Unterstützt sowohl persönliches als auch Team-Wissen
|
||||
- **Skalierbarkeit:** Funktioniert mit beliebig vielen Agenten
|
||||
- **Transparenz:** Klare Sicht darauf, wer was tut
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Team-Umgebungen mit mehreren Benutzern
|
||||
- Multi-Agent-Setups (parallele Recherche, Coding, etc.)
|
||||
- Gemeinsame Knowledge Bases
|
||||
- Situationen, die Koordination erfordern
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Single-User, Single-Agent-Szenarien
|
||||
- Situationen, in denen Einfachheit wichtiger ist als Kollaboration
|
||||
- Sehr kleine Knowledge Bases
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Event-Driven Automation]] - Für Sync-Trigger
|
||||
- [[Audit Trail]] - Zur Verfolgung von Multi-Agent-Operationen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Privacy and Governance]] (für Zugriffskontrolle)
|
||||
- [[Quality and Self-Correction]] (zur Aufrechterhaltung der Qualität in kollaborativen Einstellungen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Mesh Sync]]
|
||||
- **composition:** [[Shared vs Private]]
|
||||
- **composition:** [[Work Coordination]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,154 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [privacy, security, governance, audit]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Filter on Ingest
|
||||
- see-also: Audit Trail
|
||||
- see-also: Bulk Operations
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Rahmenwerk zur Absicherung von Wiki-Inhalten über Datenfilterung beim Ingest, Audit-Trail-Protokollierung und umkehrbare Massenoperationen.
|
||||
---
|
||||
# Privacy and Governance
|
||||
|
||||
**Typ:** Workflow (Knowledge Security and Accountability)
|
||||
|
||||
## Definition
|
||||
|
||||
Privacy and Governance behandelt die Realität, dass **Quellen oft sensitive Informationen enthalten** (API-Schlüssel, Anmeldedaten, private Gespräche, PII) und dass Wiki-Operationen **Nachverfolgbarkeit und Umkehrbarkeit** benötigen. Das ursprüngliche Pattern erwähnt dies nicht, aber es ist kritisch für die Produktionsnutzung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Ohne Privacy und Governance:
|
||||
- Sensitive Daten (API-Schlüssel, Passwörter, Token) können in das Wiki erfasst werden
|
||||
- Private Gespräche oder PII können offengelegt werden
|
||||
- Kein Datensatz darüber, wer was und wann geändert hat
|
||||
- Keine Möglichkeit, Massenoperationen rückgängig zu machen
|
||||
- Keine Rechenschaftspflicht für Wiki-Änderungen
|
||||
|
||||
### Die Lösung: Drei Ebenen
|
||||
|
||||
**1. Filterung beim Erfassen**
|
||||
Bevor etwas in das Wiki gelangt, **sensitive Daten automatisch entfernen**:
|
||||
|
||||
**Filterkategorien:**
|
||||
- **API-Schlüssel und Token:** AWS-Schlüssel, GitHub-Token, Datenbankpasswörter, etc.
|
||||
- **Anmeldedaten:** Benutzernamen, Passwörter, Secrets
|
||||
- **PII:** Persönlich identifizierbare Informationen (E-Mail, Telefon, Adresse, SSN)
|
||||
- **Private Gespräche:** Slack-Nachrichten, interne E-Mails
|
||||
- **Markiert als privat:** Alles, das explizit als privat/vertraulich markiert ist
|
||||
|
||||
**Implementierung:**
|
||||
- Regex-basierte Mustererkennung
|
||||
- ML-basierte PII-Erkennung
|
||||
- Zulassungs-/Blockliste für spezifische Muster
|
||||
- **Automatisch, nicht manuell** - dies muss automatisch geschehen
|
||||
|
||||
**Beispielmuster zum Filtern:**
|
||||
```
|
||||
- AWS: AKIA[0-9A-Z]{16,}
|
||||
- GitHub: ghp_[0-9a-zA-Z]{36,}
|
||||
- Generic API key: [a-zA-Z0-9]{32,}
|
||||
- Email: [a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}
|
||||
- Credit card: \d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}
|
||||
```
|
||||
|
||||
**2. Audit Trail**
|
||||
Jede Operation im Wiki sollte **protokolliert** werden mit:
|
||||
|
||||
| Feld | Beschreibung | Beispiel |
|
||||
|-------|-------------|---------|
|
||||
| Zeitstempel | Wann die Operation auftrat | 2026-07-26 14:30:00 |
|
||||
| Operationstyp | ingest, edit, delete, query | ingest |
|
||||
| Benutzer/Agent | Wer die Operation durchführte | Mistral Vibe |
|
||||
| Ziel | Was wurde geändert | raw/articles/Source - LLM Wiki v2.md |
|
||||
| Beschreibung | Was geändert wurde und warum | Ingested LLM Wiki v2 article |
|
||||
| Metadaten | Zusätzlicher Kontext | Source type: article |
|
||||
|
||||
**Protokollformat:** Nur anfügen (log-Einträge niemals ändern)
|
||||
|
||||
**Implementierung:**
|
||||
- Zentrales `kb/log.md` für alle Operationen
|
||||
- Strukturiertes Format für einfaches Parsing
|
||||
- Vorher/Nachher für Änderungen einschließen
|
||||
- Link zu verwandten Seiten
|
||||
|
||||
**Anwendungsfälle:**
|
||||
- Wenn etwas falsch aussieht: "Wie ist das hierher gekommen?"
|
||||
- Bei der Untersuchung der Knowledge-Evolution
|
||||
- Beim Debugging von Wiki-Problemen
|
||||
- Für Compliance und Rechenschaftspflicht
|
||||
|
||||
**3. Massenoperationen mit Governance**
|
||||
Wenn das Wiki wächst, sind Massenoperationen durchzuführen:
|
||||
|
||||
| Operation | Beschreibung | Governance |
|
||||
|-----------|-------------|------------|
|
||||
| Massenlöschung | Alte Inhalte entfernen | Geprüft, umkehrbar |
|
||||
| Export | Subset des Wiki exportieren | Geprüft |
|
||||
| Merge | Duplizierte Entities zusammenführen | Geprüft, umkehrbar |
|
||||
| Archiv | Alte Inhalte archivieren | Geprüft, umkehrbar |
|
||||
|
||||
**Governance-Anforderungen:**
|
||||
- **Geprüft:** Jede Massenoperation im Audit Trail protokolliert
|
||||
- **Umkehrbar:** Möglichkeit, Massenoperationen rückgängig zu machen
|
||||
- **Genehmigt:** Menschliche Genehmigung für destruktive Operationen erforderlich
|
||||
- **Begrenzt:** Möglichkeit, Massenoperationen auf spezifische Kategorien zu beschränken
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]] und Produktionserfahrung:
|
||||
|
||||
1. **Filterung vor dem Erfassen:** Automatische sensitive Datenenfernung
|
||||
2. **Überprüfung nach dem Erfassen:** Manuelle Stichprobenprüfung erfasster Inhalte
|
||||
3. **Zentrales Protokollieren:** Alle Operationen zu `kb/log.md`
|
||||
4. **Umkehrbare Operationen:** Undo/Redo für alle Änderungen implementieren
|
||||
5. **Zugriffskontrolle:** Optionale Benutzer-/Agent-Berechtigungen
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Sicherheit:** Sensitive Daten betreten das Wiki nie
|
||||
- **Compliance:** Erfüllt Datenschutzanforderungen
|
||||
- **Rechenschaftspflicht:** Vollständiger Audit Trail aller Änderungen
|
||||
- **Sicherheit:** Massenoperationen sind umkehrbar
|
||||
- **Vertrauen:** Benutzer können Wiki-Integrität überprüfen
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes produktive Wiki
|
||||
- Wikis mit sensiblen Daten
|
||||
- Multi-User-Umgebungen
|
||||
- Compliance-sensitive Domänen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Persönliche, nicht-sensitive Wikis
|
||||
- Vollständig vertrauenswürdige Umgebungen
|
||||
- Situationen, in denen der Overhead nicht gerechtfertigt ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Event-Driven Automation]] - Für automatisierte Governance
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Privacy and Governance]] (diese Seite)
|
||||
- [[Multi-Agent Collaboration]] (für Multi-Agent-Sicherheit)
|
||||
- [[Quality and Self-Correction]] (für Qualitätsaspekte)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Filter on Ingest]]
|
||||
- **see-also:** [[Audit Trail]]
|
||||
- **see-also:** [[Bulk Operations]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,115 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-09-01
|
||||
modified: 2026-09-02
|
||||
related:
|
||||
- see-also: Mass-Update Gate
|
||||
- operates-on: Chemenu
|
||||
- see-also: MCP-Leseserver
|
||||
sources: [Source - Publish-Remote Gate and Issue Triage Session 2026-09-01, Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01, Source - MCP Read Server Implementation Session 2026-09-02]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: 'Drittes, im Code durchgesetztes Gate: publish bricht mit Exit 42 ab, wenn die aufgeloeste Push-URL nicht in einer optionalen, gitignoreten Allowlist steht; doctor benennt seit 2026-09-02 den Gate-Zustand statt nur die Dateiexistenz'
|
||||
---
|
||||
# Publish-Remote Gate
|
||||
|
||||
**Typ:** Workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Ein im Code durchgesetztes Gate, das einen Schreibvorgang (hier: `publish`) auf ein
|
||||
deklariertes, per Datei zugelassenes Ziel beschränkt. Der Vorgang bricht ab, wenn das
|
||||
aufgelöste Push-Ziel nicht in der Allowlist steht - unabhängig davon, unter welchem Namen der
|
||||
Remote lokal konfiguriert ist.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Geprüft wird die aufgelöste URL, nicht der Remote-Name.** Ein namensbasiertes Gate würde
|
||||
ein `publish` durchlassen, dessen `origin` zwischenzeitlich auf ein anderes Ziel umgebogen
|
||||
wurde - genau der Fall, den das Gate abfangen soll.
|
||||
- **Kein Freigabe-Token, anders als vergleichbare Gates.** Ein Gate, dessen Frage per
|
||||
Änderungssatz beantwortbar ist ("ist diese konkrete Änderung richtig?"), kann sich mit einem
|
||||
Token lösen, den ein Mensch einmalig ausstellt. Ein Gate, dessen Frage eine stehende
|
||||
Eigenschaft des Checkouts ist ("gehört dieser Inhalt grundsätzlich in dieses Ziel?"), sollte
|
||||
keinen Token haben - der einzige Weg daran vorbei ist ein bewusster Edit der Konfigurationsdatei
|
||||
durch den Menschen, nie ein automatisierter Bypass.
|
||||
- **Die Allowlist-Datei ist per Checkout, nicht Teil des versionierten Inhalts.** Sie
|
||||
beschreibt, wohin *dieser* Checkout schreiben darf - eine committete Kopie würde jedem Klon
|
||||
dieselbe Erlaubnis unterschieben, unabhängig davon, ob sie für ihn zutrifft.
|
||||
- **Fehlende Datei bedeutet unbeschränkt, kaputte Datei bedeutet Fehler.** Diese Unterscheidung
|
||||
ist wichtig: Ein Checkout ohne Beschränkungsbedarf soll nicht gezwungen sein, eine leere
|
||||
Konfigurationsdatei zu pflegen; eine beschädigte Datei darf aber nicht wie eine abwesende
|
||||
behandelt werden, sonst wird eine defekte Sicherung zu einer stillschweigend abgeschalteten.
|
||||
- **`doctor` benennt seit 2026-09-02 den Gate-*Zustand*, nicht nur, ob die Datei existiert.**
|
||||
Vorher meldete der Check nur die Anwesenheit von `.wikitool-remotes.json`; ob das
|
||||
gleichbedeutend mit "scharf" ist, musste der Leser selbst schließen. Alle drei Ausgaben
|
||||
beginnen jetzt mit `Gate armed:` bzw. `Gate not armed:` - der Ein-Remote-Fall ohne Allowlist
|
||||
bleibt `OK` (er hat nichts zu schützen), sagt aber ausdrücklich, dass jedes Push-Ziel
|
||||
durchkommt.[^s-mcp-read-server-implementation-session-2026-09-02]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Ein Checkout kann an mehr als ein Remote-Ziel schreiben, und ein Schreibvorgang an das
|
||||
falsche Ziel ist teuer oder nicht rückgängig zu machen (z. B. weil das Ziel öffentlich ist).
|
||||
- Die Menge der zulässigen Ziele ist eine stabile Eigenschaft des Checkouts, keine
|
||||
Einzelfallentscheidung pro Vorgang.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Wenn nur ein Remote existiert und kein Risiko einer Zielverwechslung besteht - dort ist die
|
||||
Allowlist reine Formalität ohne Schutzwirkung.
|
||||
- Für Entscheidungen, die tatsächlich pro Änderungssatz getroffen werden sollen (dafür ist ein
|
||||
Token-basiertes Gate wie das Mass-Update-Gate das richtige Muster).
|
||||
|
||||
## Was das Gate nicht abdeckt: Inhalt, der über einen Merge hereinkommt
|
||||
|
||||
Das Gate schützt den **Push**, nicht den **Merge**. Ein Setup, bei dem eine private Instanz
|
||||
Maschinerie von einem öffentlichen Upstream per `git merge upstream/main` zieht, hat ein
|
||||
eigenes, empirisch geprüftes Problem: Ein einfacher Merge übernimmt Upstream-Änderungen an
|
||||
bereits gelöschten Inhaltsseiten nicht sauber.
|
||||
|
||||
Gemessen an einem Wegwerf-Repo-Paar, bei dem der Upstream nach der einmaligen Löschung des
|
||||
Demo-Korpus eine Seite ändert, eine neue anlegt und eine dritte löscht:
|
||||
|
||||
- Eine **geänderte** Seite erzeugt einen `modify/delete`-Konflikt und lässt die
|
||||
Upstream-Fassung im Arbeitsbaum liegen - ein naives Auflösen mit `git add -A` holt sie zurück.
|
||||
- Eine **neu angelegte** Seite wird **stillschweigend** übernommen, ohne Konflikt und ohne
|
||||
Meldung.
|
||||
- Eine beidseitig gelöschte Seite verursacht nichts - der einzige Fall, der ohne Weiteres
|
||||
funktioniert.
|
||||
|
||||
Ein naheliegender Fix (`.gitattributes` mit `merge=ours` für die betroffenen Verzeichnisse)
|
||||
wurde ebenfalls gemessen und verworfen: Der Treiber wirkt nur bei Inhaltskonflikten auf
|
||||
beidseitig vorhandenen Dateien, nicht bei modify/delete-Paaren oder Neuanlagen.
|
||||
|
||||
Die funktionierende Prozedur hält den Merge mit `--no-commit` offen, erzwingt die
|
||||
Inhaltsverzeichnisse zurück auf den Stand vor dem Merge, solange `HEAD` noch dorthin zeigt, und
|
||||
prüft danach explizit (`git diff --name-only $BEFORE HEAD -- kb raw` muss leer sein) - eine
|
||||
Kontrolle, die nicht stillschweigend übersprungen werden kann, anders als eine bloße Behauptung
|
||||
im Text[^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]. Details, ein
|
||||
getestetes Skript und zwei Architekturvorschläge (das Verfahren als `wikitool`-Kommando bauen,
|
||||
oder den Demo-Korpus grundsätzlich von dem Branch fernhalten, von dem private Instanzen ihre
|
||||
Maschinerie ziehen) stehen in Gitea-Issue #30.
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]]
|
||||
- [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]: [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
|
||||
[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
- **see-also:** [[MCP-Leseserver]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [quality, scoring, self-healing, contradiction, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Memory Lifecycle
|
||||
- rests-on: Event-Driven Automation
|
||||
- rests-on: Confidence Scoring
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Automatische Qualitätssicherung für Wikis mit Inhaltsbewertung, Selbstheilung und Widerspruchserkennung.
|
||||
---
|
||||
# Quality and Self-Correction
|
||||
|
||||
**Typ:** Workflow (Knowledge Quality Management)
|
||||
|
||||
## Definition
|
||||
|
||||
Quality and Self-Correction ist ein Satz von Mechanismen, die sicherstellen, dass das Wiki hohe Qualität beibehält und Probleme automatisch behebt. Das ursprüngliche Pattern erwähnt das Kennzeichnen von Widersprüchen bei Lint; v2 erweitert dies auf **automatische Qualitätsbewertung und Selbstheilung**.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Ohne Qualitätskontrollen:
|
||||
- Von LLM generierte Inhalte können inkonsistent oder von niedriger Qualität sein
|
||||
- Widersprüche bleiben ohne Lösung bestehen
|
||||
- Verwaiste Seiten sammeln sich an
|
||||
- Querverweise brechen
|
||||
- Wiki-Qualität verschlechtert sich im Laufe der Zeit
|
||||
|
||||
### Die Lösung: Drei Mechanismen
|
||||
|
||||
**1. Alles bewerten**
|
||||
Jeder Inhaltsteil, den das LLM schreibt, erhält eine **Qualitätsbewertung** basierend auf:
|
||||
|
||||
| Kriterium | Gewicht | Beschreibung |
|
||||
|-----------|--------|-------------|
|
||||
| Struktur | 0-0.3 | Gut organisiert, klare Abschnitte, ordnungsgemäße Formatierung |
|
||||
| Quellenangabe | 0-0.3 | Aussagen sind ordnungsgemäß belegt und zugeordnet |
|
||||
| Konsistenz | 0-0.2 | Konsistent mit Rest des Wiki, keine Widersprüche |
|
||||
| Vollständigkeit | 0-0.2 | Behandelt das Thema angemessen |
|
||||
|
||||
**Bewertungsansatz:**
|
||||
- **Selbstbewertung:** LLM bewertet seine eigene Ausgabe anhand der Kriterien
|
||||
- **Zweiter Durchgang:** Ein anderer Prompt oder ein anderes Modell bewertet den Inhalt
|
||||
- **Schwellenwert:** Inhalte unter dem Schwellenwert (z. B. 0,6) werden zur Überprüfung gekennzeichnet oder neu geschrieben
|
||||
|
||||
**2. Selbstheilung**
|
||||
Die Lint-Operation sollte mehr tun als nur zu suggerieren - sie sollte **automatisch reparieren**, was sie kann:
|
||||
|
||||
| Problem | Automatische Reparatur |
|
||||
|-------|--------------|
|
||||
| Verwaiste Seiten | Auf verwandte Seiten verlinken oder zur Überprüfung kennzeichnen |
|
||||
| Veraltete Aussagen | Mit "stale"-Tag markieren, Konfidenz reduzieren |
|
||||
| Unterbrochene Querverweise | Links reparieren oder zur menschlichen Überprüfung kennzeichnen |
|
||||
| Fehlende Metadaten | Standardmetadaten hinzufügen |
|
||||
| Formatierungsprobleme | Auto-Format zu Wiki-Standards |
|
||||
|
||||
**Implementierung:** Selbstheilung nach Plan ausführen oder durch Memory-Schreibereignisse ausgelöst.
|
||||
|
||||
**3. Widerspruchsauflösung**
|
||||
Das Original erwähnt das Kennzeichnen von Widersprüchen. v2 fügt **automatische Auflösung** hinzu:
|
||||
|
||||
**Auflösungsalgorithmus:**
|
||||
1. Widersprüchliche Aussagen identifizieren
|
||||
2. Konfidenzwerte für jeden berechnen (siehe [[Confidence Scoring]])
|
||||
3. Vergleich basierend auf:
|
||||
- **Aktualität:** Neuere Aussage bevorzugt
|
||||
- **Autorität:** Höherwertige Quelle bevorzugt
|
||||
- **Bestätigung:** Mehr unterstützende Beobachtungen bevorzugt
|
||||
4. **Standardaktion:** Höherwertige Aussage gewinnt
|
||||
5. **Manuelle Anpassung:** Benutzer kann bei Bedarf manuell anpassen
|
||||
|
||||
**Beispiel:**
|
||||
- Aussage A: "Port ist 1234" (Konfidenz: 0,8, von 2026-06-01, 2 Quellen)
|
||||
- Aussage B: "Port ist 1235" (Konfidenz: 0,9, von 2026-07-20, 3 Quellen)
|
||||
- **Auflösung:** Aussage B gewinnt, Aussage A als ersetzt markiert
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]] und [[Event-Driven Automation]]:
|
||||
|
||||
1. **Bei Inhaltserstellung:** Qualitätsbewertung berechnen
|
||||
2. **Wenn Bewertung < Schwellenwert:** Zur Überprüfung kennzeichnen oder auto-umschreiben
|
||||
3. **Nach Plan:** Selbstheilungsdurchläufe durchführen
|
||||
4. **Bei Widerspruchserkennung:** Widerspruchsauflösung auslösen
|
||||
5. **Bei manueller Anpassung:** Anpassungsgrund für Prüfung protokollieren
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Konsistenz:** Automatische Durchsetzung von Qualitätsstandards
|
||||
- **Zuverlässigkeit:** Wiki neigt zur Gesundheit von selbst
|
||||
- **Vertrauen:** Benutzer können sich auf Wiki-Genauigkeit verlassen
|
||||
- **Skalierbarkeit:** Qualität ohne proportionalen menschlichen Aufwand aufrechterhalten
|
||||
- **Nachverfolgbarkeit:** Alle automatisierten Änderungen werden protokolliert
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki mit erwarteter von LLM generierter Inhalte
|
||||
- Multi-Autor- oder Multi-Agent-Wikis
|
||||
- Große oder wachsende Knowledge Bases
|
||||
- Situationen, in denen Inhaltsqualität kritisch ist
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Vollständig von Menschen kuratierte Wikis
|
||||
- Situationen, in denen automatisierte Änderungen nicht akzeptabel sind
|
||||
- Sehr kleine Wikis, bei denen manuelle Überprüfung möglich ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Lint Workflow]] - Die Gesundheitsprüfungsoperation
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Supersession]] (zum Handhaben aufgelöster Widersprüche)
|
||||
- [[Audit Trail]] (zum Verfolgung von Qualitätsmaßnahmen)
|
||||
- [[Self-Healing]] (der automatische Reparaturmechanismus)
|
||||
- [[Contradiction Resolution]] (der Entscheidungsprozess)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Event-Driven Automation]]
|
||||
- **rests-on:** [[Confidence Scoring]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [heuristics, stale-claims, change-density, weak-linking]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Maschinelle Heuristiken zur Priorisierung der semantischen Pr\xFCfung: veraltete Aussagen, hohe \xC4nderungsdichte und schwache Verlinkung"
|
||||
---
|
||||
# Semantic Lint Automation
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Semantic Lint Automation bezieht sich auf Maschinen-Heuristiken, die potenzielle semantische Probleme im Wiki identifizieren und eine priorisierte Liste zur menschlichen oder LLM-Überprüfung bereitstellen. Im Gegensatz zu strukturellem Linting (das auf definite Fehler wie kaputte Links prüft), nutzt semantisches Linting Muster und Metriken, um wahrscheinliche Probleme zu kennzeichnen, die Urteile erfordern.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Heuristisch-basiert:** Nutzt automatisierte Erkennung von Mustern, die mit semantischen Problemen korrelieren
|
||||
- **Priorisierung:** Ordnet Befunde nach wahrscheinlichem Schweregrad oder Auswirkungen
|
||||
- **Nicht-deterministisch:** Ergebnisse können variieren und erfordern menschliches Urteil
|
||||
- **Ergänzt strukturelles Linting:** Funktioniert neben dem bestehenden deterministischen `wikitool lint`
|
||||
|
||||
## Heuristiken
|
||||
|
||||
- **Veraltete Aussagen:** Identifiziert Fakten, die nicht kürzlich bestätigt wurden (z. B. >90 Tage)
|
||||
- **Hohe Änderungsdichte:** Kennzeichnet Seiten mit vielen neuen Änderungen, die überprüft werden müssen
|
||||
- **Schwache Verlinkung:** Findet Seiten, die Entities/Concepts erwähnen, aber nicht darauf verlinken
|
||||
- **Niedriges Vertrauen:** Identifiziert Aussagen mit Vertrauens-Scores unter Schwellenwerten
|
||||
- **Sonnet-Verbesserung:** Könnte Zeilenzahl-Ausreißer (Seitenqualitätsschwellen) und Index-Abschnittsgröße-Prüfungen einbeziehen[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Kennzeichnung: "Seite X erwähnt 'MQTT' 5 Mal, hat aber keinen [[MQTT]]-Link"
|
||||
- Kennzeichnung: "Seite Y hat 15 Änderungen in der letzten Woche - potenzial für Inkonsistenzen"
|
||||
- Kennzeichnung: "Aussage über Version 2.0.0 auf Seite Z wurde zuletzt vor 120 Tagen bestätigt"
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Während regelmäßiger Wartung
|
||||
- Vor größeren Operationen (publish, archive)
|
||||
- Um Bereiche zu identifizieren, die Aufmerksamkeit benötigen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Als Ersatz für menschliches Urteil
|
||||
- Für definitive Fehlererkennung (verwenden Sie stattdessen strukturelles Linting)
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Lint Workflow]] (vorhandenes Konzept für strukturelles Linting)
|
||||
- [[Confidence Scoring]] (wird verwendet, um Aussagen mit niedrigem Vertrauen zu identifizieren)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [preflight, context, query, update]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Verbindliche Vorabprüfung, die vor Query- und Update-Operationen einen Kontextbericht erzeugt (Index, jüngste Logs, Umfang)
|
||||
---
|
||||
# Session Orientation
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Session Orientation ist eine obligatorische Preflight-Prüfung, die einen Kontextbericht vor Query- oder Update-Operationen generiert. Dies stellt sicher, dass das LLM aktuelle, vollständige Informationen über den Wiki-Zustand (Index, aktuelle Logs, Umfang) hat, bevor es versucht, Fragen zu beantworten oder Änderungen vorzunehmen, und reduziert so das Risiko, auf veraltete oder unvollständige Informationen zu reagieren.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Kontextbericht:** Generiert einen Schnappschuss des aktuellen Wiki-Zustands einschließlich Index, aktueller Log-Einträge und Umfang möglicher Änderungen
|
||||
- **Farzaa-Stil:** Ähnlich dem context-first-Ansatz in farzaa-gist-Mustern[^s-llm-improvements-sonnet-analysis]
|
||||
- **Reduziert Query-Drift:** Stellt sicher, dass Abfragen auf Grundlage des aktuellen Wiki-Zustands beantwortet werden, nicht auf potenziell veralteter Sitzungs-Memory
|
||||
- **Verhindert Scope-Fehler:** Hilft dem LLM zu verstehen, worauf es Zugriff hat und worauf nicht
|
||||
- **Sonnet-Verbesserung:** Farzas Regel ist, Schema + Index + letzte N Log-Einträge vor *jeder* Operation zu lesen, nicht nur Query/Update[^s-llm-improvements-sonnet-analysis]
|
||||
- **Aktuelle Lücke:** AGENTS.md hat dies implizit in QUERY/LINT-Workflows, aber nicht als obligatorischer erster Schritt für alle Sitzungen[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Vor einer QUERY-Operation: Index-Zusammenfassung, aktuelle Ingests und verwandte Seiten anzeigen
|
||||
- Vor einer UPDATE-Operation: Aktuellen Seitenzustand, verwandte Seiten und potenzielle Auswirkungen anzeigen
|
||||
- Preflight-Befehl: `wikitool preflight --operation query --scope "E3DC integration"`
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Am Anfang jeder neuen Sitzung
|
||||
- Vor jeder QUERY-Operation
|
||||
- Vor jeder UPDATE-Operation
|
||||
- Wenn das LLM Kontext etablieren muss
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für einfache INGEST-Operationen, wo der Umfang explizit bereitgestellt wird
|
||||
- Für Read-Only-Operationen, wo Kontext nicht kritisch ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[AGENTS.md]] (definiert QUERY- und UPDATE-Workflows)
|
||||
- [[Workflow Orchestration]] (preflight könnte Teil von orchestrierten Workflows sein)
|
||||
- [[farzaa gist]] (Inspiration für Session-First-Ansatz)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [page-management, refactoring, link-correction, frontmatter]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Eigene Befehle zum Teilen, Zusammenführen und Umklassifizieren von Seiten, mit automatischer Korrektur von Links und Frontmatter
|
||||
---
|
||||
# Split Merge Reclassify
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Split Merge Reclassify bezieht sich auf dedizierte Befehle für strukturelle Seiten-Reorganisationsvorgänge: Aufteilen einer Seite in mehrere, Zusammenführen mehrerer Seiten in eine oder Umklassifizierung von Seiten zwischen Typen (Entity zu Concept, usw.). Diese Befehle würden automatisch die mechanischen Aspekte handhaben: Aktualisierung von Links, Frontmatter, Querverweisen und Index-Einträgen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Automatische Linkkorrektur:** Aktualisiert alle Wikilinks, die auf die alte Seite verweisen, um auf neue Seiten zu zeigen
|
||||
- **Frontmatter-Updates:** Korrigiert automatisch related:, sources: und andere Frontmatter-Arrays
|
||||
- **Index-Verwaltung:** Aktualisiert index.md-Einträge automatisch
|
||||
- **Audit-Trail:** Protokolliert die strukturelle Änderung in log.md
|
||||
|
||||
## Beispiele
|
||||
|
||||
- `wikitool page split --page "Large Topic" --parts "Part A","Part B"`
|
||||
- `wikitool page merge --pages "Topic A","Topic B" --into "Combined Topic"`
|
||||
- `wikitool page reclassify --page "Old Entity" --type concept`
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wenn eine Seite zu groß geworden ist und geteilt werden muss
|
||||
- Wenn zwei eng verwandte Seiten zusammengeführt werden sollten
|
||||
- Wenn die Klassifizierung des Seitentyps falsch ist
|
||||
- Während der Wiki-Reorganisation
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für kleine redaktionelle Änderungen
|
||||
- Wenn die Seitenstruktur noch experimentell ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Bulk Operations]] (vorhandenes Concept für geprüfte Massenvorgänge)
|
||||
- [[Entity Extraction]] (bezüglich Umklassifizierungsentscheidungen)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,75 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [split, threshold, lines, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Stub Threshold
|
||||
- see-also: Index Scaling
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Maximale Seitengr\xF6\xDFe, ab der eine Aufteilung empfohlen wird (Farza: >120-150 Zeilen, Pascalandy: 200 Zeilen)"
|
||||
---
|
||||
# Split Threshold
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Split Threshold definiert die maximale Größe, die eine Wiki-Seite erreichen sollte, bevor sie in mehrere fokussierte Seiten aufgeteilt wird. Dies verhindert, dass Seiten schwerfällig und schwierig zu navigieren werden.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Farzas Empfehlung:** Seiten mit über 120-150 Zeilen sollten aufgeteilt werden[^s-llm-improvements-sonnet-analysis]
|
||||
- **Pascalandys Empfehlung:** 200 Zeilen als absolutes Maximum[^s-llm-improvements-sonnet-analysis]
|
||||
- **Zweck:** Erhält Seitenlesbarkeit und fokussierte Inhaltsorganisation
|
||||
- **Ergänzt Stub Threshold:** Während Stub Threshold das Minimum definiert, definiert Split Threshold das Maximum für optimale Seitengröße
|
||||
- **Aktueller Stand:** Einige vorhandene Wiki-Seiten können diese Schwellenwerte überschreiten (z. B. lange Entity-Seiten mit umfangreichen Details)[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Beispiele
|
||||
|
||||
**Unter dem Schwellenwert:**
|
||||
- Eine typische Entity-Seite mit 50-80 Zeilen
|
||||
- Eine Concept-Seite mit 3-4 gut strukturierten Abschnitten
|
||||
|
||||
**Über dem Schwellenwert:**
|
||||
- Eine Seite mit 160+ Zeilen, die mehrere unterschiedliche Unterthemen abdeckt
|
||||
- Die AGENTS.md Entity-Seite selbst könnte sich diesem Schwellenwert nähern
|
||||
|
||||
**Split-Kandidat:**
|
||||
- Eine Seite über "MQTT Implementation", die auch Geschichte, Protokolldetails und Anwendungsbeispiele abdeckt, könnte in separate Seiten aufgeteilt werden
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Überprüfen vorhandener Seiten während Audits
|
||||
- Beim Erstellen neuer Seiten mit umfangreichen Inhalten
|
||||
- Beim Entscheiden zwischen Erweiterung einer Seite oder Erstellen einer neuen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Seiten, die natürlicherweise umfangreiche Inhalte erfordern (z. B. umfassende Tutorials)
|
||||
- Wenn der zusätzliche Inhalt eng verknüpft ist und eine Aufteilung die Kohärenz verringern würde
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Anti-Cramming Heuristic]] - Regel für wann neue Seiten zu erstellen sind
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Stub Threshold]]
|
||||
- **see-also:** [[Index Scaling]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,86 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [stub, minimum, quality, lines]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Split Threshold
|
||||
- see-also: Semantic Lint Automation
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Wiki v2]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: "Mindestumfang, ab dem eine Wiki-Seite nicht mehr als Stub gilt (Farza: \u22653 S\xE4tze oder 15 Zeilen)"
|
||||
---
|
||||
# Stub Threshold
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Stub Threshold definiert den Mindestinhalt, den eine Wiki-Seite haben muss, um nicht als Stub klassifiziert zu werden. Stubs sind Platzhalter-Seiten mit minimalen Informationen, die wenig Wert für Leser bieten.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Farzas Definition:** Ein Stub wird als weniger als 3 Sätze oder weniger als 15 Zeilen Inhalt definiert[^s-llm-improvements-sonnet-analysis]
|
||||
- **Zweck:** Stellt sicher, dass alle Seiten aussagekräftige Informationen bieten statt leerer Platzhalter zu sein
|
||||
- **Aktueller Status:** Das aktuelle Wiki hat einige TODO-Seiten, die während Massen-Lint-Korrektionen erstellt wurden (z. B. während der 2026-07-31 Lint-Operation, die 20 Concept-Stub-Seiten erstellte)[^s-llm-wiki-v2]
|
||||
- **Empfohlene Maßnahme:** Seiten unter diesem Schwellenwert sollten entweder mit nützlichem Inhalt erweitert oder entfernt werden, wenn sie keinen Zweck erfüllen[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Beispiele
|
||||
|
||||
**Unter Schwellenwert (Stub):**
|
||||
```markdown
|
||||
## Definition
|
||||
|
||||
TODO: clear definition.
|
||||
```
|
||||
|
||||
**Bei Schwellenwert:**
|
||||
```markdown
|
||||
## Definition
|
||||
|
||||
This is a concept page. It has at least 3 sentences.
|
||||
|
||||
This provides minimal useful information. It meets the stub threshold.
|
||||
```
|
||||
|
||||
**Über Schwellenwert:**
|
||||
```markdown
|
||||
## Definition
|
||||
|
||||
This is a well-developed concept page. It has multiple paragraphs.
|
||||
|
||||
It provides comprehensive information about the topic. It clearly exceeds the stub threshold.
|
||||
```
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Während Seitenerstellung um sicherzustellen, dass neue Seiten minimale Standards erfüllen
|
||||
- Während Lint-Operationen um Stubs zu identifizieren, die Aufmerksamkeit benötigen
|
||||
- Beim Auditing des Wiki für Inhaltsqualität
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Seiten, die absichtlich minimal sind (z. B. Redirect-Seiten)
|
||||
- Wenn der Inhalt natürlicherweise kurz aber vollständig ist
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - LLM Wiki v2]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-wiki-v2]: [[Source - LLM Wiki v2]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Split Threshold]]
|
||||
- **see-also:** [[Semantic Lint Automation]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [versioning, knowledge, updates, lifecycle]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- part-of: Memory Lifecycle
|
||||
- rests-on: Confidence Scoring
|
||||
- see-also: Knowledge Graph
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Ablösen alten Wissens durch neue, widersprechende Information; gibt dem Wiki eine Versionierung mit ausdrücklicher Verknüpfung und Erhalt der Historie.
|
||||
---
|
||||
# Supersession
|
||||
|
||||
**Typ:** Workflow (Knowledge Version Control)
|
||||
|
||||
## Definition
|
||||
|
||||
Supersession ist der Prozess des **expliziten Ersetzens** alten Wissens durch neues Wissen, wenn die neuen Informationen das Alte widersprechen oder aktualisieren. Es stellt Versionskontrolle für Wissen bereit und stellt sicher, dass das Wiki sich im Laufe der Zeit korrekt entwickelt, ohne historischen Kontext zu verlieren.
|
||||
|
||||
Dies ist eine Kernkomponente der [[Memory Lifecycle]]-Verwaltung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Ohne Supersession:
|
||||
- Alte und neue widersprechende Aussagen koexistieren ohne Anzeichen, welche aktuell ist
|
||||
- Benutzer müssen widersprechende Informationen manuell abgleichen
|
||||
- Das Wiki wird zum Friedhof veralteter Fakten
|
||||
- Keine Audit-Trail wie sich Wissen entwickelt hat
|
||||
|
||||
### Die Lösung
|
||||
|
||||
Wenn neue Informationen **eine bestehende Aussage widersprechen oder aktualisieren**:
|
||||
|
||||
1. **Erstelle die neue Aussage** mit aktuellen Informationen
|
||||
2. **Verlinke explizit** die neue Aussage mit der alten
|
||||
3. **Markiere die alte Aussage** als **supersediert** mit:
|
||||
- Zeitstempel der Supersession
|
||||
- Referenz auf die ersetzende Aussage
|
||||
- Bewahrter Inhalt (für historische Referenz)
|
||||
4. **Aktualisiere Querverweise** um auf die neue Aussage zu zeigen
|
||||
5. **Erhöhe Konfidenz** der neuen Aussage (erbt von alten + neuen Quellen)
|
||||
|
||||
### Supersession-Metadaten
|
||||
|
||||
Für jede supersedierte Aussage speichern:
|
||||
```yaml
|
||||
superseded_by: [claim_id]
|
||||
superseded_on: YYYY-MM-DD
|
||||
supersession_reason: [contradiction|update|correction]
|
||||
original_content: "..." # Preserved for history
|
||||
```
|
||||
|
||||
## Arten der Supersession
|
||||
|
||||
| Typ | Beschreibung | Beispiel |
|
||||
|------|-------------|---------|
|
||||
| **Widerspruch** | Neue Info widerspricht direkt alte | „Port ist 1234" → „Port ist 1235" |
|
||||
| **Aktualisierung** | Neue Info macht alte Info veraltet | „Nutzt Python 3.8" → „Nutzt Python 3.11" |
|
||||
| **Korrektur** | Alte Info war falsch | „Autor ist X" → „Autor ist Y" |
|
||||
| **Verfeinerung** | Neue Info fügt wichtiges Detail hinzu | „Nutzt Redis" → „Nutzt Redis 7.0 für Caching" |
|
||||
|
||||
## Implementierung
|
||||
|
||||
### Auslöser
|
||||
|
||||
Supersession kann ausgelöst werden durch:
|
||||
- **Manuell:** Benutzer markiert alte Aussage explizit als supersediert
|
||||
- **Automatisch:** [[Event-Driven Automation]] erkennt Widerspruch während Ingest
|
||||
- **Geplant:** Periodischer Lint identifiziert veraltete Aussagen
|
||||
|
||||
### Automatisierungs-Workflow
|
||||
|
||||
```
|
||||
On new source ingest:
|
||||
1. Extract claims from new source
|
||||
2. For each claim:
|
||||
a. Check for contradictions with existing claims
|
||||
b. If contradiction found:
|
||||
i. Calculate confidence of both claims
|
||||
ii. If new claim has higher confidence:
|
||||
- Create supersession relationship
|
||||
- Mark old as superseded
|
||||
iii. If old claim has higher confidence:
|
||||
- Flag for human review
|
||||
iv. If equal confidence:
|
||||
- Flag for human review
|
||||
c. If no contradiction, add as new claim
|
||||
```
|
||||
|
||||
### Konfidenz-Vererbung
|
||||
|
||||
Wenn Aussage B Aussage A ersetzt:
|
||||
- Aussage B erbt Konfidenz-Boost von Aussagen A's Quellen (falls immer noch gültig)
|
||||
- Aussage B's Konfidenz = min(1.0, B_confidence + A_confidence * inheritance_factor)
|
||||
- Typischer inheritance_factor = 0.3-0.5
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Klarheit:** Klare Anzeige von aktuellen vs. historischen Kenntnissen
|
||||
- **Nachverfolgbarkeit:** Vollständige Geschichte wie sich Wissen entwickelt hat
|
||||
- **Vertrauen:** Benutzer können die Progression des Verständnisses sehen
|
||||
- **Genauigkeit:** Alte, falsche Informationen bleiben nicht erhalten
|
||||
- **Wiederherstellung:** Kann rollback, wenn Supersession fehlerhaft war
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jede faktische Aussage, die sich mit der Zeit ändern kann
|
||||
- Technische Spezifikationen
|
||||
- Versionabhängige Informationen
|
||||
- Zeitkritisches Wissen
|
||||
- Jeder Bereich mit sich entwickelndem Verständnis
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Subjektive Meinungen
|
||||
- Historische Fakten (als-ist bewahren)
|
||||
- Definitionen, die sich nicht ändern
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Contradiction Resolution]] - Der Entscheidungsprozess für Supersession
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (für automatisierte Supersession)
|
||||
- [[Forgetting]] (komplementärer Mechanismus)
|
||||
- [[Self-Healing]] (für automatisierte Supersession-Erkennung)
|
||||
- [[Audit Trail]] (zum Nachverfolgen von Supersession-Historie)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Confidence Scoring]]
|
||||
- **see-also:** [[Knowledge Graph]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,343 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [linux, administration, security, users, groups]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- see-also: Arch Linux
|
||||
- see-also: AUR
|
||||
- see-also: Aura
|
||||
- see-also: makepkg
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Linux-Ablauf zum Anlegen, Ändern, Überwachen und Löschen von Benutzerkonten mit useradd, usermod und userdel, samt Gruppenverwaltung und sudoers-Konfiguration.
|
||||
---
|
||||
# User Management
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Benutzerverwaltung umfasst die Erstellung, Änderung, Überwachung und Löschung von Benutzerkonten auf einem Linux-System. Dies beinhaltet die Verwaltung von Passwörtern, Gruppenmitgliedschaften, Berechtigungen und Kontostatus (gesperrt/entsperrt, aktiviert/deaktiviert).
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Kernwerkzeuge:** `useradd`, `usermod`, `userdel`, `passwd`
|
||||
- **Konfiguration:** `/etc/passwd`, `/etc/shadow`, `/etc/group`, `/etc/sudoers`
|
||||
- **Kontostatus:** Aktiv, gesperrt, abgelaufen, deaktiviert
|
||||
- **Best Practice:** Principle of least privilege
|
||||
|
||||
## Sperrung von Konten
|
||||
|
||||
Die Sperrung eines Benutzerkontos verhindert die kennwortbasierte Authentifizierung, während das Konto und seine Dateien erhalten bleiben. Das Konto kann später ohne Datenverlust entsperrt werden.
|
||||
|
||||
### Methoden zum Sperren von Konten
|
||||
|
||||
#### Methode 1: usermod (Empfohlen)
|
||||
|
||||
```bash
|
||||
# Lock an account
|
||||
sudo usermod -L username
|
||||
|
||||
# Unlock an account
|
||||
sudo usermod -U username
|
||||
```
|
||||
|
||||
**Was passiert:** Fügt das Präfix `!` zum Passwort-Hash in `/etc/shadow` hinzu
|
||||
|
||||
#### Methode 2: passwd
|
||||
|
||||
```bash
|
||||
# Lock an account
|
||||
sudo passwd -l username
|
||||
|
||||
# Unlock an account
|
||||
sudo passwd -u username
|
||||
```
|
||||
|
||||
**Was passiert:** Gleiches wie `usermod -L`, fügt das Präfix `!` zum Passwort hinzu
|
||||
|
||||
### Sperrstatus überprüfen
|
||||
|
||||
```bash
|
||||
# Check if user account is locked
|
||||
passwd --status username
|
||||
```
|
||||
|
||||
**Beispielausgabe:**
|
||||
```
|
||||
username LK 2026-07-31 0 99999 7 -1 (Password set, SHA512 crypt.)
|
||||
```
|
||||
|
||||
Das Flag `LK` zeigt **G**esperrtes Konto an (Passwort gesperrt).
|
||||
|
||||
### Alle Benutzer überprüfen
|
||||
|
||||
```bash
|
||||
# List all users with account status
|
||||
passwd -a --status
|
||||
|
||||
# Alternative: check /etc/shadow
|
||||
sudo grep '^username:' /etc/shadow
|
||||
```
|
||||
|
||||
**Format für gesperrtes Passwort:** Präfix `!` oder `!!` im zweiten Feld von `/etc/shadow`
|
||||
|
||||
## Benutzer erstellen
|
||||
|
||||
### Einfache Benutzererstellung
|
||||
|
||||
```bash
|
||||
# Create user with home directory
|
||||
sudo useradd -m username
|
||||
|
||||
# Set password
|
||||
sudo passwd username
|
||||
|
||||
# Create user with custom home, shell, and comment
|
||||
sudo useradd -m -d /home/customdir -s /bin/bash -c "Full Name" username
|
||||
```
|
||||
|
||||
### Benutzer mit Ablaufdatum erstellen
|
||||
|
||||
```bash
|
||||
# Create user that expires on specific date
|
||||
sudo useradd -e 2026-12-31 username
|
||||
|
||||
# Modify expiry of existing user
|
||||
sudo usermod -e 2026-12-31 username
|
||||
```
|
||||
|
||||
### Massenerstellung von Benutzern
|
||||
|
||||
```bash
|
||||
# Create multiple users
|
||||
for user in user1 user2 user3; do
|
||||
sudo useradd -m $user
|
||||
sudo passwd $user
|
||||
done
|
||||
```
|
||||
|
||||
## Benutzer löschen
|
||||
|
||||
### Benutzer entfernen (Home-Verzeichnis behalten)
|
||||
|
||||
```bash
|
||||
sudo userdel username
|
||||
```
|
||||
|
||||
### Benutzer und Home-Verzeichnis entfernen
|
||||
|
||||
```bash
|
||||
sudo userdel -r username
|
||||
```
|
||||
|
||||
### Erzwungenes Löschen (Benutzer ist angemeldet)
|
||||
|
||||
```bash
|
||||
# Kill user processes first
|
||||
sudo pkill -u username
|
||||
sudo pkill -9 -u username
|
||||
|
||||
# Then delete
|
||||
sudo userdel -r -f username
|
||||
```
|
||||
|
||||
## Gruppenverwaltung
|
||||
|
||||
### Gruppen erstellen und verwalten
|
||||
|
||||
```bash
|
||||
# Create group
|
||||
sudo groupadd groupname
|
||||
|
||||
# Add user to group
|
||||
sudo usermod -aG groupname username
|
||||
|
||||
# Remove user from group
|
||||
sudo gpasswd -d username groupname
|
||||
|
||||
# Delete group
|
||||
sudo groupdel groupname
|
||||
```
|
||||
|
||||
### Primäre vs. ergänzende Gruppen
|
||||
|
||||
- **Primäre Gruppe:** Wird bei Anmeldung gesetzt, Standard für neue Dateien
|
||||
- **Ergänzende Gruppen:** Zusätzliche Gruppenmitgliedschaften
|
||||
|
||||
```bash
|
||||
# Set primary group
|
||||
sudo usermod -g primarygroup username
|
||||
|
||||
# Add to supplementary group
|
||||
sudo usermod -aG supplementarygroup username
|
||||
```
|
||||
|
||||
## Sudo-Konfiguration
|
||||
|
||||
### Benutzer zu Sudoers hinzufügen
|
||||
|
||||
```bash
|
||||
# Add to wheel group (most distributions)
|
||||
sudo usermod -aG wheel username
|
||||
|
||||
# Manual sudoers entry
|
||||
sudo visudo
|
||||
# Add line: username ALL=(ALL) ALL
|
||||
```
|
||||
|
||||
### Passwortloses Sudo
|
||||
|
||||
```bash
|
||||
# Add to sudoers with NOPASSWD
|
||||
sudo visudo
|
||||
# Add line: username ALL=(ALL) NOPASSWD: ALL
|
||||
|
||||
# For CI/CD containers (example from [[Arch Linux]] page)
|
||||
echo "builder ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers
|
||||
```
|
||||
|
||||
## Passwortverwaltung
|
||||
|
||||
### Passwort ändern
|
||||
|
||||
```bash
|
||||
# Change own password
|
||||
passwd
|
||||
|
||||
# Change another user's password (requires sudo)
|
||||
sudo passwd username
|
||||
```
|
||||
|
||||
### Erzwinge Passwortänderung beim nächsten Anmelden
|
||||
|
||||
```bash
|
||||
sudo passwd -e username
|
||||
```
|
||||
|
||||
### Passwortrichtlinien
|
||||
|
||||
Konfigurieren in `/etc/login.defs`:
|
||||
- `PASS_MAX_DAYS` - Maximales Paswortalter
|
||||
- `PASS_MIN_DAYS` - Minimales Paswortalter
|
||||
- `PASS_MIN_LEN` - Minimale Passwortlänge
|
||||
|
||||
## Benutzer überwachen
|
||||
|
||||
### Angemeldete Benutzer auflisten
|
||||
|
||||
```bash
|
||||
# Show logged in users
|
||||
who
|
||||
|
||||
# Show with more details
|
||||
w
|
||||
|
||||
# Show login history
|
||||
last
|
||||
|
||||
# Show user processes
|
||||
ps -u username
|
||||
```
|
||||
|
||||
### Anmeldestatus des Benutzers überprüfen
|
||||
|
||||
```bash
|
||||
# Check when user last logged in
|
||||
lastlog | grep username
|
||||
|
||||
# Check user's login shell
|
||||
getent passwd username | cut -d: -f7
|
||||
```
|
||||
|
||||
## Kontoablauf
|
||||
|
||||
### Ablauf überprüfen
|
||||
|
||||
```bash
|
||||
# Check when account expires
|
||||
chage -l username
|
||||
|
||||
# Check via /etc/shadow (field 8 = expiry date)
|
||||
sudo grep username /etc/shadow | cut -d: -f8
|
||||
```
|
||||
|
||||
### Ablauf einstellen
|
||||
|
||||
```bash
|
||||
# Set expiry date (YYYY-MM-DD)
|
||||
sudo chage -E 2026-12-31 username
|
||||
|
||||
# Set password expiry (days until must change)
|
||||
sudo chage -M 90 username
|
||||
```
|
||||
|
||||
## Deaktivieren vs. Sperren
|
||||
|
||||
| Aktion | Methode | Umkehrbar | Erhält Dateien | Erhält UID/GID |
|
||||
|--------|--------|------------|------------------|-------------------|
|
||||
| Sperren | `usermod -L` oder `passwd -l` | Ja | Ja | Ja |
|
||||
| Deaktivieren | `usermod --expiredate 1` | Ja | Ja | Ja |
|
||||
| Löschen | `userdel` | Nein | Vielleicht (mit -r) | Nein |
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Gruppen verwenden:** Berechtigungen über Gruppen verwalten, nicht über einzelne Benutzer
|
||||
2. **Least Privilege:** Nur notwendige Berechtigungen erteilen
|
||||
3. **Kontobereinigung:** Regelmäßig ungenutzte Konten entfernen
|
||||
4. **Passwortrichtlinien:** Starke Passwörter und Rotation erzwingen
|
||||
5. **Audit-Protokolle:** Benutzeraktivitätsprotokolle überwachen
|
||||
6. **Sudoers sichern:** Immer `visudo` verwenden, nie direkt bearbeiten
|
||||
7. **SSH-Schlüssel:** SSH-Schlüsselverwaltung gegenüber Passwörtern bevorzugen
|
||||
|
||||
## Häufige Probleme
|
||||
|
||||
### Benutzer kann sich nicht anmelden
|
||||
|
||||
```bash
|
||||
# Check account status
|
||||
passwd -S username
|
||||
|
||||
# Check if locked
|
||||
passwd --status username | grep LK
|
||||
|
||||
# Check if expired
|
||||
chage -l username | grep "Account expires"
|
||||
|
||||
# Check if shell is valid
|
||||
getent passwd username | cut -d: -f7
|
||||
```
|
||||
|
||||
### Berechtigung verweigert
|
||||
|
||||
```bash
|
||||
# Check group membership
|
||||
groups username
|
||||
|
||||
# Check file permissions
|
||||
ls -la /path/to/file
|
||||
|
||||
# Check effective permissions
|
||||
sudo -u username test -r /path/to/file
|
||||
```
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://wiki.archlinux.org/title/Users_and_groups
|
||||
- https://www.thegeekdiary.com/unix-linux-how-to-lock-or-disable-an-user-account/
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Arch Linux]]
|
||||
- **see-also:** [[AUR]]
|
||||
- **see-also:** [[Aura]]
|
||||
- **see-also:** [[makepkg]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [workflow, extraction, refactoring]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related:
|
||||
- see-also: Cross-platform Agent Skills
|
||||
- see-also: Context Isolation
|
||||
- see-also: Token Economics
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Herauslösen von Workflow-Abschnitten aus monolithischer Dokumentation
|
||||
---
|
||||
# Workflow Extraction
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Workflow-Extraktion ist der Prozess des Extrahierens von prozeduralen Workflow-Abschnitten aus einer monolithischen Anweisungsdatei in diskrete, in sich geschlossene Skill-Dateien, wobei jeder Schritt, jeder Befehlsaufruf und jede Hartregel genau wie im Original erhalten bleibt[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Verlustfreie Verschiebung**: Dies ist eine strukturelle Umorganisation, keine Umschreibung - der Inhalt darf sich nicht ändern[^s-copilot-skill-restructure-instructions]
|
||||
- **Wörtliche Extraktion**: Jeder nummerierte Schritt, jeder wikitool-Befehl und jede Hartregel muss erhalten bleiben[^s-copilot-skill-restructure-instructions]
|
||||
- **In sich geschlossen**: Jede Skill-Datei sollte in sich geschlossen sein und nicht erfordern, dass zuerst andere Skill-Dateien gelesen werden[^s-copilot-skill-restructure-instructions]
|
||||
- **Gemeinsamer Kontext**: Skills sollten auf die reduzierte Stammdatei AGENTS.md für querschnittliche deklarative Inhalte verweisen, nicht duplizieren[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Extraktion des INGEST-Workflows (11 Schritte) in `.agents/skills/wiki-ingest/SKILL.md`[^s-copilot-skill-restructure-instructions]
|
||||
- Extraktion von QUERY-, LINT-, CREATE-, UPDATE-Workflows auf ähnliche Weise[^s-copilot-skill-restructure-instructions]
|
||||
- Die Chemenu-Umstrukturierung nach der Ausführungscheckliste in der Quelle[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Workflow-Extraktion verwenden, wenn:
|
||||
- Eine monolithische Anweisungsdatei mit klar getrennten Workflow-Abschnitten vorliegt
|
||||
- Die Workflows unabhängig aufgerufen werden können
|
||||
- Kontextisolation für Effizienz aktiviert werden soll
|
||||
- Plattformübergreifende Kompatibilität benötigt wird
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Workflow-Extraktion vermeiden, wenn:
|
||||
- Die Anweisungen eng gekoppelt sind und nicht sauber getrennt werden können
|
||||
- Der Overhead der Verwaltung separater Skill-Dateien die Vorteile übersteigt
|
||||
- Keine klaren Grenzen zwischen verschiedenen Workflows vorhanden sind
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Cross-platform Agent Skills]]
|
||||
- **see-also:** [[Context Isolation]]
|
||||
- **see-also:** [[Token Economics]]
|
||||
<!-- /wikitool:links -->
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [automation, end-to-end, ingest, lint, update]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Orchestrierte Einzelbefehle für vollständige Operationen (ingest run, lint run, update run) mit Dry-Run-Vorschau vor dem Schreiben
|
||||
---
|
||||
# Workflow Orchestration
|
||||
|
||||
**Typ:** workflow
|
||||
|
||||
## Definition
|
||||
|
||||
Workflow-Orchestrierung ist das Konzept der Bereitstellung einzelner, orchestrierter Befehle, die komplette End-to-End-Operationen automatisch ausführen. Anstatt das LLM zu zwingen, mehrere diskrete CLI-Befehle manuell auszuführen (z. B. Quelle erstellen, Entities/Concepts identifizieren, Seiten erstellen, Querverweise hinzufügen, Index neu erstellen), behandelt ein orchestrierter Workflow-Befehl die gesamte Sequenz mit ordnungsgemäßem Error Handling und Validierung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Reduziert Agent Drift:** Weniger manuelle Schritte bedeuten weniger Gelegenheiten für das LLM, einen Schritt zu verpassen oder Befehle in der falschen Reihenfolge auszuführen
|
||||
- **Dry-Run-Vorschau:** Befehle sollten einen `--dry-run`- oder `--plan`-Modus unterstützen, der zeigt, was getan werden würde, bevor Änderungen vorgenommen werden
|
||||
- **Atomare Operationen:** Komplette Workflows sollten, wenn möglich, atomar sein - entweder alle Schritte erfolgreich oder keine
|
||||
- **Aktuelle Lücke:** AGENTS.md dokumentiert lange Schrittenketten, aber sie werden als einzelne CLI-Aufrufe ausgeführt, nicht als orchestrierte Workflows
|
||||
|
||||
## Beispiele
|
||||
|
||||
- `wikitool ingest run raw/notes/file.md` - Komplette Aufnahme: Quelle erstellen, Entities/Concepts identifizieren, Seiten erstellen, Querverweise hinzufügen, Indizes neu erstellen, an Protokoll anhängen, veröffentlichen
|
||||
- `wikitool lint run` - Komplettes Linting: strukturelle Prüfung, semantische Überprüfung, Konfidenzabfall, Indizes neu erstellen, an Protokoll anhängen
|
||||
- `wikitool update run` - Komplettes Update: Seite lesen, Änderungen identifizieren, Inhalte bewahren, Zitate hinzufügen, Querverweise aktualisieren, Indizes neu erstellen, an Protokoll anhängen, veröffentlichen
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Für wiederholte, mehrstufige Operationen, die einem definierten Muster folgen
|
||||
- Wenn Konsistenz und Vollständigkeit kritisch sind
|
||||
- Um die kognitive Belastung des LLM-Agenten zu reduzieren
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Einmal- oder explorative Operationen, bei denen Flexibilität erforderlich ist
|
||||
- Wenn der Workflow noch nicht gut verstanden oder standardisiert ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[AGENTS.md]] (definiert die Workflows, die orchestriert werden könnten)
|
||||
(sollte mit orchestrierten Workflows integriert werden)
|
||||
- [[Session Orientation]] (Preflight-Kontext für orchestrierte Operationen)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
Reference in New Issue
Block a user