Chemenu 2.1.0 - deterministischer Wissenskompiler
Chemenu kompiliert Rohnotizen zu einem verlinkten, quellengebundenen Wiki: raw/ -> types/ + tools/ -> kb/ -> reports/. Was mechanisch ist, macht tools/wikitool; was Urteil braucht, macht ein Agent unter Contracts, deren Grenzen in Code durchgesetzt sind statt im Prompt. Dieser Commit ist der Startpunkt der oeffentlichen Historie. Die vorherige Entwicklung fand in einer privaten Instanz statt und ist nicht Teil dieses Repositorys; ihre Erzaehlung steht vollstaendig in CHANGES.md, das mit 44 Eintraegen von 0.1.0 bis 2.1.0 erhalten geblieben ist. Der mitgelieferte Korpus ist ein Testbett und eine Demo: 170 Seiten ueber den Stack selbst - Gates, Lint, Versionierung, Suche, das Wiki-Muster. Er dokumentiert das Werkzeug mit den eigenen Mitteln des Werkzeugs. Lizenz: AGPL-3.0 fuer den Stack (tools/, types/), CC-BY-4.0 fuer die Inhalte. Die Grenze zwischen beiden ist der Dateiplan, den dist export berechnet - siehe NOTICE.
This commit is contained in:
+239
@@ -0,0 +1,239 @@
|
||||
# kb/ - Knowledge Layer Contract
|
||||
|
||||
The compiled knowledge layer, and the third stage of the pipeline
|
||||
`raw/` -> `kb/` -> `reports/`. Everything here is written and maintained by the LLM from
|
||||
material in `raw/`, and is expected to stay correct without being re-derived.
|
||||
|
||||
**Quality goal:** a page should answer a future question *without* re-reading the source it
|
||||
came from. If answering still requires the raw file, the page is incomplete.
|
||||
|
||||
This file holds the rules that apply in **every** collection. Each `kb/<name>/COLLECTION.md`
|
||||
declares that it inherits them and adds only what is local to its own subtree - read this file
|
||||
together with the target collection's contract before writing or editing a page.
|
||||
|
||||
Structural facts (which frontmatter fields exist, which are required, what the body skeleton
|
||||
looks like) are *not* here - they belong to the type-specs and are printed by
|
||||
`tools/wikitool types describe <type>`. Never hand-write frontmatter; scaffold with
|
||||
`tools/wikitool new <type> --name "<Name>" --set field=value ...`.
|
||||
|
||||
## Collections
|
||||
|
||||
`kb/` is a **namespace, not a collection**. It carries no `COLLECTION.md` of its own.
|
||||
|
||||
A directory under `kb/` is a **collection** exactly when it contains a `COLLECTION.md`. That
|
||||
file is the local authoring contract for every page in the subtree.
|
||||
|
||||
- A subdirectory *inside* a collection is an **area**. It inherits the enclosing contract and
|
||||
must not carry a `COLLECTION.md` of its own - `kb/entities/systems/` is an area of
|
||||
`kb/entities/`.
|
||||
- A `COLLECTION.md` nested inside another collection is invalid.
|
||||
- `COLLECTION.md` appears **nowhere outside `kb/`**. `raw/`, `types/`, `tools/`, `reports/`
|
||||
and `instructions/` are not collections and carry a `CONTRACT.md` or a root type-spec
|
||||
instead.
|
||||
|
||||
`tools/wikitool docs verify` enforces all three.
|
||||
|
||||
| Collection | Holds | Contract |
|
||||
|------------|-------|----------|
|
||||
| `kb/entities/` | Concrete things: projects, deployed systems, tools, technologies, people | [entities/COLLECTION.md](entities/COLLECTION.md) |
|
||||
| `kb/concepts/` | Architectures, patterns, protocols, workflows, decisions, recurring problems | [concepts/COLLECTION.md](concepts/COLLECTION.md) |
|
||||
| `kb/sources/` | One summary page per ingested source, carrying its `raw_files:` provenance | [sources/COLLECTION.md](sources/COLLECTION.md) |
|
||||
| `kb/comparisons/` | Structured comparisons of two or more existing pages | [comparisons/COLLECTION.md](comparisons/COLLECTION.md) |
|
||||
|
||||
**Adding a collection:** `mkdir kb/<name>` and write a `kb/<name>/COLLECTION.md`. Collections
|
||||
are discovered by contract presence, so no code change is needed. A collection only becomes
|
||||
*writable* once some type-spec declares a matching `base_dir:`.
|
||||
|
||||
**Where a page goes** is decided by its type-spec, never by hand - see
|
||||
[types/type-spec.md](../types/type-spec.md).
|
||||
|
||||
## Generated files
|
||||
|
||||
Never hand-edit these; they are produced by `tools/wikitool`:
|
||||
|
||||
| File | Produced by |
|
||||
|------|-------------|
|
||||
| `kb/index.md` | `wikitool index rebuild` - the catalog **map**: statistics, counts, links |
|
||||
| `kb/<collection>/INDEX.md` and `kb/<collection>/<area>/INDEX.md` | `wikitool index rebuild` - the page tables |
|
||||
| `kb/log.md` | `wikitool log append` |
|
||||
| `kb/provenance.md` | `wikitool sources rebuild-index` |
|
||||
|
||||
To *find* a page, search rather than read the catalog: `tools/wikitool search "<text>"`, or
|
||||
`tools/wikitool search --field <predicate>` for a structured query over frontmatter.
|
||||
|
||||
## Naming
|
||||
|
||||
- Human-readable titles with spaces: `Hybrid Search.md`, `Gitea Actions.md` - not kebab-case.
|
||||
- Singular for entities: `ha-core.md`, not `ha-cores.md`.
|
||||
- Comparison pages read as a comparison: `Go vs Rust.md`.
|
||||
- ADRs are prefixed: `adr-001-use-go-modules.md`.
|
||||
- The filename stem *is* the page title, and `[[wikilinks]]` must match it exactly.
|
||||
- Prefer readability over convention when the two conflict.
|
||||
|
||||
What to name a thing: projects use their repository or common name; systems a descriptive
|
||||
name; tools the tool's own name; technologies their standard spelling and capitalization;
|
||||
people a full name or common handle.
|
||||
|
||||
## Every page should
|
||||
|
||||
- [ ] Carry a clear, descriptive title and a summary near the top
|
||||
- [ ] Use consistent terminology with the rest of the wiki
|
||||
- [ ] Link to every entity and concept it mentions, and be linked to in return
|
||||
- [ ] Cite its hard facts (see [Provenance and citation](#provenance-and-citation))
|
||||
- [ ] Duplicate no existing page
|
||||
- [ ] Appear in the catalog (guaranteed by `wikitool index rebuild`)
|
||||
|
||||
## Tone
|
||||
|
||||
Wikipedia style: factual, neutral, specific.
|
||||
|
||||
- No buzzwords ("bahnbrechend", "hochmodern", "leistungsstark", "revolutioniert").
|
||||
- No AI filler ("es sei angemerkt", "es ist wichtig zu betonen", "in der heutigen Zeit").
|
||||
- No em-dash asides carrying parenthetical reasoning.
|
||||
- At most 2 blockquoted lines per page. `wikitool lint` reports overages as advisory, since
|
||||
exceeding the cap can be a legitimate judgment call - but the page should carry the
|
||||
knowledge itself, not delegate it to quotations. The cap is about how much of the page you
|
||||
let quotes carry; it does not apply to text you are citing verbatim from a source.
|
||||
|
||||
Good: "MQTT ist ein leichtgewichtiges Publish-Subscribe-Protokoll für Geräte mit knappen
|
||||
Ressourcen."
|
||||
|
||||
Bad: "MQTT ist ein bahnbrechendes, hochmodernes Protokoll, das die IoT-Kommunikation
|
||||
revolutioniert - und es sei angemerkt, dass es ein Publish-Subscribe-Muster verwendet."
|
||||
|
||||
## Language
|
||||
|
||||
Pages are written in **German**. This binds `kb/` and the authoring surface that shapes it -
|
||||
the page type-specs `types/entity.md`, `types/concept.md`, `types/source.md` and
|
||||
`types/comparison.md`. `raw/` is untouched ([raw/CONTRACT.md](../raw/CONTRACT.md)), and the
|
||||
control plane stays English: AGENTS.md, the stage contracts including this one, `instructions/`,
|
||||
and the type-specs for non-page artifacts.
|
||||
|
||||
Every line of a page is either **prose** or an **identifier**. Only prose is translated.
|
||||
|
||||
**Prose:** descriptions and definitions, `## Key Information` values, `## Details` body text, a
|
||||
source page's Summary / Key Takeaways / Action Items / Not Extracted, and `summary:`.
|
||||
|
||||
**Identifiers - never translated, in any language:**
|
||||
|
||||
| Identifier | Why |
|
||||
|---|---|
|
||||
| Page titles, and the H1 that repeats one | A title is the wiki's only identifier for a page and follows the subject's own established name - see [Naming](#naming). `wikitool lint` reports an H1 that stops matching its title |
|
||||
| The subtype value on the generated `**Typ:**` line | It renders a schema enum value (`technology`, `workflow`), which `search --field` filters on. The label is prose; the value is not |
|
||||
| `tags:` | Search keys, not prose |
|
||||
| Commands, paths, config keys, hostnames, code | They are what they are |
|
||||
| Quotations | Quoted verbatim in the source's own language |
|
||||
|
||||
Established English technical terms stay English inside German prose - "GitOps", "Ownership
|
||||
Model", "Reverse Proxy", "Pull Request". Translate a term only where the German one is genuinely
|
||||
the more common usage. A coined German equivalent nobody else writes makes the page harder to
|
||||
find, not more idiomatic.
|
||||
|
||||
Which terms those are, which have a settled German form, and the register the prose is written in:
|
||||
[instructions/german-terminology.md](../instructions/german-terminology.md). It is lookup material,
|
||||
not a second rule - every entry in it is a decision that was made wrong once first.
|
||||
|
||||
**A source in another language** is still summarized in the KB language: a source page is
|
||||
evidence *about* a source, not a substitute for it. Quote verbatim in the original language and
|
||||
record the raw file's language in `source_language:`.
|
||||
|
||||
### Section headings
|
||||
|
||||
Three headings are a vocabulary the tool owns rather than prose an author picks: `xref add`
|
||||
writes into Relationships and See Also, and `cite add` owns the trailing Footnotes block. They
|
||||
follow the KB language like everything else - `## Beziehungen`, `## Siehe auch`, `## Fußnoten` -
|
||||
and `tools/chemenu/sections.py` is the single place naming them.
|
||||
|
||||
Each has aliases the tool still *recognizes* but no longer writes, which is what lets the corpus
|
||||
be translated page by page: a page still carrying `## Relationships` is found and appended to
|
||||
correctly, and `cite sync` leaves an untranslated `## Footnotes` heading alone rather than
|
||||
retitling it. Renaming a heading is the translation pass's job, never a side effect of another
|
||||
command. Any *other* heading an author adds is ordinary prose and is translated with the rest.
|
||||
|
||||
## Linking
|
||||
|
||||
Every page links to what it mentions, in both directions. Cross-references are created with
|
||||
`tools/wikitool xref add --a "<A>" --b "<B>" --rel-a "<label>" --rel-b "<label>"`, never by
|
||||
hand-editing the `related:` array or the Relationships/See Also bullets.
|
||||
|
||||
Use a typed relationship label rather than a generic one:
|
||||
|
||||
`hängt ab von` · `verwendet` · `implementiert` · `erweitert` · `ersetzt` · `steht in Konflikt mit`
|
||||
· `benötigt` · `erzeugt` · `konsumiert` · `besitzt` · `pflegt` · `läuft auf` · `verwandt mit`
|
||||
(last resort)
|
||||
|
||||
The labels are prose written into a `- **label:** [[Title]]` bullet; no code matches on them, so
|
||||
an untranslated page's English label is stale wording, not a broken reference.
|
||||
|
||||
A page is expected to have at least one inbound link; `wikitool lint` reports orphans.
|
||||
Comparison pages are exempt - they are reached through the catalog.
|
||||
|
||||
Renaming a page, deleting one, or dropping a single reference are tool operations with their
|
||||
own procedure: see [instructions/page-lifecycle.md](../instructions/page-lifecycle.md).
|
||||
|
||||
## Provenance and citation
|
||||
|
||||
Every claim is either traceable to a raw file or explicitly marked as not.
|
||||
|
||||
- **`provenance:`** on every entity/concept page - `sourced` (every substantive claim traces
|
||||
to a raw file), `general` (LLM general knowledge, no raw backing), or `mixed` (both; put the
|
||||
unsourced part under a `## General Guidance (unsourced)` heading).
|
||||
- **`raw_files:`** on every source page - concrete existing file paths under `raw/`, never a
|
||||
directory and never a bare URL. For an external article also set `source_url:`, but
|
||||
`raw_files:` must still point at the local copy under `raw/articles/`.
|
||||
- **One source page may cover many raw files.** A folder of related documents becomes a single
|
||||
page listing all of them, not one page per file.
|
||||
- **A `[^cite-id]` footnote** appended to any *specific hard fact*: an IP, port, version, path,
|
||||
command, or config value. `tools/wikitool cite add --page "<Title>" --source "Source - X"
|
||||
[--file <qualifier>]` mints the id, upserts its `[[Source - X]]` (or
|
||||
`[[Source - X|storage-model.md]]` for a multi-file source) definition in the page's trailing
|
||||
`## Footnotes` block, and adds `Source - X` to `sources:` - it prints the marker to paste at
|
||||
the fact; placing it is still manual. Never hand-type a cite-id (AGENTS.md invariant 1). This
|
||||
differs from a plain `[[Source - X]]` link, which only means "related to".
|
||||
- **Notation inside code is notation, not a reference.** A `[^cite-id]` or a `[[wikilink]]`
|
||||
written in backticks or a fenced block is read as an example: the citation does not count and
|
||||
the link does not exist. That is what lets a page document this stack's own syntax. It also
|
||||
means a marker appended to a line *inside* a fence cites nothing - put it on a
|
||||
`Quelle: [^cite-id]` line under the block, where it renders as a footnote instead of
|
||||
travelling with the command when someone copies it.
|
||||
- A source cited inline must also appear in the page's frontmatter `sources:` list;
|
||||
`wikitool lint` checks this in both directions, and hard-errors on a leftover pre-migration
|
||||
`^[[...]]` marker, an undefined `[^cite-id]` reference, or an orphaned Footnotes definition.
|
||||
`tools/wikitool cite sync` reconciles a page's block after a prose edit changes which ids are
|
||||
actually referenced.
|
||||
- `tools/wikitool xref link-source --source "Source - X" --entities A,B,C` adds a new source
|
||||
to every page it backs in one pass.
|
||||
- Every raw file is expected to be claimed by some source page;
|
||||
`tools/wikitool sources coverage` lists the ones that are not.
|
||||
|
||||
If no raw file or existing page backs an answer, say so explicitly rather than synthesizing
|
||||
one - and never file the synthesized version back into the wiki.
|
||||
|
||||
## Confidence
|
||||
|
||||
`confidence_base` is the undecayed score set when a page's content is last confirmed;
|
||||
`confidence` is *derived* from it by `tools/wikitool confidence decay` and must never be
|
||||
edited directly.
|
||||
|
||||
Base score for a single source is 0.5, adjusted by:
|
||||
|
||||
- **+0.2 per supporting source** (max +0.6)
|
||||
- **+0.2** if confirmed <30 days ago, **+0.1** if <90 days
|
||||
- **+0.1** for official documentation, **+0.05** for a reputable secondary source
|
||||
- **+0.1** if multiple independent sources agree
|
||||
|
||||
Re-assess a page with `tools/wikitool touch --page "<Title>" --confidence-base <value>`.
|
||||
|
||||
In prose, hedge according to the score: below 0.6 write "möglicherweise"/"kann"; below 0.4
|
||||
write "unsicher"/"unbestätigt".
|
||||
|
||||
## What does not belong here
|
||||
|
||||
- Raw source material - it stays immutable under `raw/`.
|
||||
- Type definitions, frontmatter contracts, or templates - those live in `types/`.
|
||||
- Procedures for operating the tooling - those live in `instructions/`.
|
||||
- Rules that apply to only one collection - those belong in that collection's
|
||||
`COLLECTION.md`.
|
||||
- Hand-edited generated files - see [Generated files](#generated-files).
|
||||
- Generated lint reports - they are written to `reports/` and are not pages.
|
||||
- Answers with no source behind them.
|
||||
@@ -0,0 +1,42 @@
|
||||
# kb/comparisons/ - Collection Contract
|
||||
|
||||
Structured head-to-head evaluations of two or more things that already have pages here. A
|
||||
comparison exists so that neither subject's own page has to argue against the other.
|
||||
|
||||
**Quality goal:** decidability - a reader with a concrete situation should be able to choose.
|
||||
That needs named, checkable dimensions and a stated trade-off; a page that lists differences
|
||||
without saying what they cost has described, not compared.
|
||||
|
||||
Inherits [kb/CONTRACT.md](../CONTRACT.md) - naming, tone, linking, provenance and confidence
|
||||
are defined there and are not restated here.
|
||||
|
||||
## Types offered
|
||||
|
||||
`comparison` (`tools/wikitool types describe comparison`).
|
||||
|
||||
## Naming
|
||||
|
||||
The title reads as a comparison: `Go vs Rust.md`, `Traefik vs nginx.md`. Order the subjects as
|
||||
they are most commonly spoken, not alphabetically.
|
||||
|
||||
## Requirements
|
||||
|
||||
- **Every subject must already have its own page.** A comparison is a view over existing
|
||||
knowledge, not a place to introduce it. Create the entity or concept pages first, then
|
||||
compare them.
|
||||
- Compare on stated, checkable dimensions - a table with one row per dimension, one column per
|
||||
subject. Cite hard facts the same way any other page does.
|
||||
- State the trade-off, not a winner. Where a recommendation is genuinely warranted, scope it:
|
||||
"for X workload", not "better".
|
||||
|
||||
## Outbound linking
|
||||
|
||||
A comparison links to every subject with `related to`, and each subject links back. Comparison
|
||||
pages are **exempt from the orphan check** - they are reached through `index.md` rather than
|
||||
through inbound prose links.
|
||||
|
||||
## What does not belong here
|
||||
|
||||
- A comparison of things this wiki does not otherwise cover.
|
||||
- Feature-matrix dumps copied from a vendor page. If the material is a source, ingest it as one
|
||||
and compile the comparison from it.
|
||||
@@ -0,0 +1,12 @@
|
||||
<!-- Generated by `wikitool index rebuild`. Do not hand-edit. -->
|
||||
|
||||
# kb/comparisons/ - Index
|
||||
|
||||
1 page(s). Regenerated by `wikitool index rebuild`.
|
||||
|
||||
## All
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[amd-pstate vs acpi-cpufreq]] | comparison | Vergleich zweier AMD-CPU-Power-Management-Treiber: CPPC-basiertes amd-pstate gegenüber ACPI-basiertem acpi-cpufreq. | 2026-07-31 |
|
||||
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
type: types/comparison.md
|
||||
tags: [kernel, power-management, amd, cpu, driver]
|
||||
created: 2026-07-31
|
||||
entities: [amd-pstate, acpi-cpufreq]
|
||||
summary: "Vergleich zweier AMD-CPU-Power-Management-Treiber: CPPC-basiertes amd-pstate gegen\xFC\
|
||||
ber ACPI-basiertem acpi-cpufreq."
|
||||
---
|
||||
# Comparison: amd-pstate vs acpi-cpufreq
|
||||
|
||||
## Überblick
|
||||
|
||||
Dieser Vergleich untersucht zwei Linux-Kernel-CPU-Energieverwaltungstreiber für AMD-Prozessoren: **amd-pstate** (der neuere CPPC-basierte Treiber) und **acpi-cpufreq** (der traditionelle ACPI-basierte Treiber). Der Vergleich konzentriert sich auf ihre Funktionen, Leistungsmerkmale und Anwendungsfälle, um zu bestimmen, welcher Treiber für verschiedene Szenarien geeignet ist.
|
||||
|
||||
## Vergleichstabelle
|
||||
|
||||
| Kriterium | [[amd-pstate]] | [[acpi-cpufreq]] |
|
||||
|----------|---------------|------------------|
|
||||
| **Einführung** | Linux Kernel 5.17 (2022) | Etablierter ACPI-Treiber |
|
||||
| **Hardware-Unterstützung** | AMD-CPUs mit CPPC (neuere Generationen, Zen2, Zen3) | Alle AMD-CPUs via ACPI |
|
||||
| **Energieverwaltungs-Schnittstelle** | CPPC (Collaborative Processor Performance Control) | ACPI (Advanced Configuration and Power Interface) |
|
||||
| **Granularität** | Fein-körnig, kontinuierlicher Bereich | 3 diskrete P-States (0, 1, 2) |
|
||||
| **Feedback-Mechanismus** | Hardware bietet Ziele und Hinweise | Statische ACPI-Tabellen |
|
||||
| **Governor-Unterstützung** | schedutil, ondemand (mit CPPC-Bewusstsein) | schedutil, ondemand, conservative, powersave, performance |
|
||||
| **Energieeffizienz** | Überlegen - optimiert für Workload | Standard - generischer Ansatz |
|
||||
| **Mobiles Batterielebensdauer** | Erweitert - bessere Energieverwaltung | Standard |
|
||||
| **Leistungstuning** | Präzise, adaptiv | Grob, begrenzt |
|
||||
| **Fallback-Verhalten** | Fällt auf acpi-cpufreq bei inkompatibel Hardware zurück | N/A |
|
||||
| **Schnittstelle** | sysfs | sysfs |
|
||||
| **Kernel-Integration** | Benötigt 5.17+ | Unterstützt in allen Kerneln |
|
||||
|
||||
## Analyse
|
||||
|
||||
### Energieverwaltungs-Ansatz
|
||||
|
||||
**amd-pstate** implementiert einen kooperativen Ansatz über CPPC:
|
||||
- CPU-Hardware bietet **Leistungsziele** (optimale Betriebspunkte)
|
||||
- Hardware bietet **Hinweise** über effiziente Leistungsstatus
|
||||
- Governoren bewerten diese Ziele und Hinweise neben traditionellen Last-Metriken
|
||||
- Aktiviert **Echtzeit-Anpassung** an Workload-Merkmale
|
||||
|
||||
**acpi-cpufreq** verwendet einen traditionellen Ansatz:
|
||||
- Liest **statische P-States** aus ACPI-Tabellen
|
||||
- Nur 3 Zustände verfügbar für AMD: Vollständig, Zwischenstation, Niedrigste
|
||||
- Governoren wählen aus diesen diskreten Zuständen basierend auf Systemlast
|
||||
- **Grob-körnige** Steuerung mit begrenztem Optimierungspotential
|
||||
|
||||
### Leistungsmerkmale
|
||||
|
||||
| Aspekt | amd-pstate | acpi-cpufreq |
|
||||
|--------|------------|--------------|
|
||||
| **Reaktionsfähigkeit** | Hoch - schnelle Anpassung an Laständerungen | Mittel - Zustandsübergänge dauern länger |
|
||||
| **Stromverbrauch** | Niedriger - optimiert für Effizienz | Höher - weniger optimiert |
|
||||
| **Wärmeabgabe** | Niedriger - bessere Wärmeverwaltung | Höher - weniger effizient |
|
||||
| **Batterie-Auswirkung (Mobil)** | Positiv - verlängert Batterielebensdauer | Neutral - standard Entladung |
|
||||
| **Benchmark-Leistung** | Vergleichbar - behält Leistung | Vergleichbar - behält Leistung |
|
||||
|
||||
### Anwendungsfälle
|
||||
|
||||
#### amd-pstate ist ideal für:
|
||||
- **Moderne AMD-Systeme** (Zen2, Zen3, neuere) mit CPPC-Unterstützung
|
||||
- **Mobile Geräte**, bei denen Batterielebensdauer kritisch ist
|
||||
- **Stromempfindliche Umgebungen** (Laptops, Eingebettete Systeme)
|
||||
- **Mixed-Workload-Szenarien**, die adaptive Energieverwaltung benötigen
|
||||
- **Benutzer, die optimale Energieeffizienz anstreben** ohne Leistungseinbuße
|
||||
|
||||
#### acpi-cpufreq ist geeignet für:
|
||||
- **Ältere AMD-Systeme** ohne CPPC-Unterstützung
|
||||
- **Legacy-Hardware**-Kompatibilität
|
||||
- **Stabile, bewährte Verhaltensweise** Präferenz
|
||||
- **Fallback-Szenario**, wenn amd-pstate nicht geladen wird
|
||||
- **Systeme, auf denen amd-pstate nicht verfügbar ist** (Kernel < 5.17)
|
||||
|
||||
### Governor-Verhalten
|
||||
|
||||
Beide Treiber arbeiten mit den gleichen Governoren, aber mit unterschiedlichen Funktionen:
|
||||
|
||||
| Governor | amd-pstate | acpi-cpufreq |
|
||||
|----------|------------|--------------|
|
||||
| **schedutil** | Verwendet Scheduler-Daten + CPPC-Ziele/Hinweise | Verwendet nur Scheduler-Daten |
|
||||
| **ondemand** | Verwendet Last-Daten + CPPC-Ziele/Hinweise | Verwendet nur Last-Daten |
|
||||
| **conservative** | Konservativer mit CPPC-Bewusstsein | Standard konservatives Verhalten |
|
||||
| **powersave** | Minimale Frequenz | Minimale Frequenz |
|
||||
| **performance** | Maximale Frequenz | Maximale Frequenz |
|
||||
|
||||
### Kompatibilität und Fallback
|
||||
|
||||
**amd-pstate** enthält intelligenten Fallback:
|
||||
- Versucht, auf AMD-Hardware zu initialisieren
|
||||
- Prüft auf CPPC-Unterstützung
|
||||
- Bei Initialisierungsfehlschlag oder inkompatible Hardware: **automatischer Fallback zu acpi-cpufreq**
|
||||
- Dies gewährleistet Abwärtskompatibilität und elegante Degradation
|
||||
|
||||
**acpi-cpufreq** hat keinen Fallback-Mechanismus, da es der traditionelle Treiber ist.
|
||||
|
||||
### Migrationsbedingungen
|
||||
|
||||
Für Benutzer, die von acpi-cpufreq zu amd-pstate wechseln möchten:
|
||||
|
||||
**Vorteile:**
|
||||
- Verbesserte Energieeffizienz
|
||||
- Verlängerte Batterielebensdauer auf Laptops
|
||||
- Bessere Wärmeverwaltung
|
||||
- Responsivere Energieverwaltung
|
||||
|
||||
**Überlegungen:**
|
||||
- Benötigt Linux Kernel 5.17 oder neuere
|
||||
- Benötigt AMD-CPU mit CPPC-Unterstützung
|
||||
- Kann Boot-Parameter oder Konfiguration aktualisieren müssen
|
||||
- Systemstabilität nach dem Wechsel überwachen
|
||||
|
||||
**Überprüfung:**
|
||||
```bash
|
||||
# Check current driver
|
||||
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
|
||||
|
||||
# Check available governors
|
||||
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
|
||||
|
||||
# Check CPPC support (amd-pstate)
|
||||
ls /sys/devices/system/cpu/cpu0/cpufreq/cppc_*
|
||||
```
|
||||
|
||||
## Empfehlung
|
||||
|
||||
- **Für neue Systeme mit unterstützter Hardware:** Verwende **amd-pstate** als Standardwahl. Die verbesserte Energieverwaltung und Energieeffizienzvorteile wiegen alle Migrationsprobleme auf.
|
||||
- **Für ältere Systeme:** Weiterhin **acpi-cpufreq** verwenden oder auf den automatischen Fallback-Mechanismus verlassen.
|
||||
- **Für gemischte Umgebungen:** Der automatische Fallback von amd-pstate zu acpi-cpufreq gewährleistet Kompatibilität über vielfältige Hardware hinweg.
|
||||
|
||||
## Fazit
|
||||
|
||||
**amd-pstate** stellt einen bedeutenden Fortschritt in der CPU-Energieverwaltung für AMD-Prozessoren dar und bietet fein-körnige Steuerung, bessere Effizienz und verbessertes Batterielebensdauer. **acpi-cpufreq** bleibt ein zuverlässiger Fallback und dient weiterhin älterer Hardware. Die Wahl zwischen ihnen hängt hauptsächlich von Hardware-Unterstützung und Kernel-Version ab, wobei amd-pstate die klare Präferenz für moderne AMD-Systeme ist.
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **compares:** [[amd-pstate]]
|
||||
- **compares:** [[acpi-cpufreq]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[amd-pstate]]
|
||||
- [[acpi-cpufreq]]
|
||||
|
||||
@@ -0,0 +1,126 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: problem
|
||||
tags: [tests, ci, tooling, quality]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [Structural Enforcement over Documented Rule, Green Suite Blind Spot, wikitool, Gitea Actions]
|
||||
sources: [Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Fehlerklasse, in der ein Test gruen ist, weil die Maschine zufaellig passt statt weil der Code stimmt - abgegrenzt gegen den Green Suite Blind Spot, belegt an vier Faellen unter Gitea-Issue #8'
|
||||
---
|
||||
# Ambient Environment Dependency
|
||||
|
||||
**Typ:** Problem
|
||||
|
||||
## Definition
|
||||
|
||||
Eine Ambient Environment Dependency liegt vor, wenn Code stillschweigend Zustand von der
|
||||
Maschine liest, auf der er läuft - Umgebungsvariablen, globale Konfigurationsdateien, das
|
||||
Home-Verzeichnis - und ein Testlauf grün wird, *weil die Maschine zufällig passt* statt weil der
|
||||
Code stimmt. Der grüne Lauf misst dann die Umgebung, nicht das Verhalten.
|
||||
|
||||
Das unterscheidet sich vom [[Green Suite Blind Spot]] an genau einer Stelle, und die ist
|
||||
entscheidend: dort behauptet **kein** Test das richtige Verhalten, hier behauptet ein Test es
|
||||
sehr wohl und ist grün - aus dem falschen Grund. Der blinde Fleck ist eine Lücke in der
|
||||
Abdeckung; die Umgebungsabhängigkeit ist ein Fehlbeleg innerhalb der Abdeckung. Beide sind
|
||||
gegen die Zahl grüner Tests immun, aber nur der zweite überlebt ein "das ist doch getestet".
|
||||
|
||||
Die Tücke ist der fehlende Widerstand. Ein Test mit dieser Abhängigkeit verhält sich beim
|
||||
Schreiben, beim Review und im nächsten hundert Läufen exakt wie ein korrekter Test. Sichtbar
|
||||
wird sie erst auf einer fremden Maschine - und wenn niemand die Suite je woanders startet, nie.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Der Beleg aus diesem Stack (Gitea-Issue #8).** `config.default_author()` ruft
|
||||
`git config user.name` mit `cwd=config.ROOT` auf. Die Fixture-Wurzel ist kein Repository, also
|
||||
antwortete die *globale* git-Konfiguration desjenigen, der die Suite startete. Der erste
|
||||
CI-Lauf, der überhaupt bis `pytest` kam, meldete `2 failed, 628 passed`; auf jeder
|
||||
Entwicklermaschine war dieselbe Suite monatelang grün gewesen[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31].
|
||||
- **Sie vermehrt sich schneller, als sie gefunden wird.** Nach der Reparatur der ersten beiden
|
||||
Fälle führten zwei neue Tests dieselbe Abhängigkeit erneut ein - geschrieben von jemandem, der
|
||||
das Issue vorher gelesen hatte. Vier Fälle, zwei davon nach der Warnung[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Das ist der Grund,
|
||||
warum ein Hinweis in einem Dokument hier nicht trägt; siehe
|
||||
[[Structural Enforcement over Documented Rule]].
|
||||
- **Die Abwesenheit von Fehlern beweist nichts über den Schutz.** Vor der Härtung war die Suite
|
||||
unter leerem `HOME` und ohne git-Konfiguration bereits grün (695 Tests): die vier bekannten
|
||||
Fälle waren einzeln repariert, ein fünfter existierte gerade nicht[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Ein Schutz braucht deshalb
|
||||
seinen eigenen Nachweis, unabhängig davon, dass nach seinem Einbau alles grün bleibt.
|
||||
- **Der Nachweis führt über die Gegenprobe, nicht über den grünen Lauf.** In der Sitzung
|
||||
ausgeführt: dieselbe Funktion antwortet ohne Isolierung `'Torben Nehmer'` und mit Isolierung
|
||||
`None`[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Erst das zeigt, dass die Isolierung etwas tut.
|
||||
- **In beide Richtungen prüfen.** Der übliche Gegentest ist die leere Maschine ("übersteht die
|
||||
Suite, nichts zu haben"). Der zweite ist die *vergiftete* Maschine ("übersteht sie, das Falsche
|
||||
zu haben"): Variablen absichtlich auf Müll setzen. Eine Isolierung, die nur auf einer ohnehin
|
||||
sauberen Maschine löscht, besteht den ersten Test und fällt beim zweiten durch.
|
||||
- **Ein CI-Container ist kein verlässlicher Ersatz für Isolierung.** Das Log von Run 79 zeigt,
|
||||
dass `actions/checkout@v7` selbst eine globale git-Konfiguration im Container anlegt
|
||||
(`Copying '/root/.gitconfig' to ...`, `Temporarily overriding HOME=...`), und der
|
||||
Environment-Schritt schreibt `safe.directory` global dazu[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Die Eigenschaft "Maschine ohne
|
||||
globale Konfiguration", auf der der ursprüngliche Fund beruhte, hatte der Container
|
||||
**zufällig**. Ein Guard, der sie voraussetzt, hört still auf zu greifen.
|
||||
- **Das Gegenmittel setzt an der Ausführung an, nicht am einzelnen Test.** Eine Isolierung, die
|
||||
vor *jedem* Test greift, macht die Abhängigkeit unschreibbar, statt sie zu melden. Ein Test,
|
||||
der Identität braucht, muss sie dann explizit herstellen - was er ohnehin tun sollte.
|
||||
- **Wer isoliert, darf nicht das Verhalten mit-isolieren, das er prüfen will.** Ein pauschal
|
||||
gesetzter Default (etwa eine Autor-Identität für alle Tests) macht genau den Zweig untestbar,
|
||||
der nur auf einer Maschine ohne Identität existiert. Die Suite sieht dann grüner aus und belegt
|
||||
weniger.
|
||||
- **Die Isolierung selbst braucht Tests.** Sonst kann sie eine Variable verlieren, ohne dass ein
|
||||
Lauf rot wird - dasselbe Versagen eine Ebene höher.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - `default_author()` las die globale git-Konfiguration des Aufrufers; vier Tests
|
||||
hingen nacheinander daran, gefunden erst durch den ersten CI-Lauf, der bis `pytest` kam
|
||||
- [[Gitea Actions]] - der Job-Container als vermeintlich neutrale Maschine, die es seit
|
||||
`checkout@v7` nicht mehr ist
|
||||
- [[Green Suite Blind Spot]] - die verwandte Fehlerklasse, gegen die dieselbe Zahl grüner Tests
|
||||
ebenfalls nichts aussagt
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wenn ein Test auf einer fremden Maschine fällt, der lokal grün ist - die erste Frage ist nicht
|
||||
"was ist an der Maschine kaputt", sondern "was hat der Test von ihr gelesen".
|
||||
- Beim Schreiben eines Tests, der Identität, Pfade, Zeitzone, Locale oder Netzwerkzugang
|
||||
berührt: was davon kommt aus der Umgebung, und was stellt der Test selbst her.
|
||||
- Wenn ein grüner Lauf als Beleg für Korrektheit angeführt wird und die Suite bisher nur auf
|
||||
einer Sorte Maschine lief.
|
||||
- Bevor eine Suite an eine Stelle wandert, wo sie erstmals woanders läuft - CI, ein zweiter
|
||||
Entwickler, eine verteilte Instanz.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Tests, die die Umgebung *absichtlich* prüfen und sie dafür selbst aufbauen. Ein Test, der
|
||||
ein Fixture-Repository anlegt und darin eine lokale Identität setzt, hat keine Abhängigkeit -
|
||||
er hat ein Fixture.
|
||||
- Für Werte, die legitim von außen kommen und deren Abwesenheit sauber behandelt wird. Nicht
|
||||
jeder `os.environ.get` ist ein Defekt; der Defekt ist, wenn ein Testergebnis davon abhängt.
|
||||
- Als Argument gegen Integrationstests gegen echte Systeme. Die stützen sich bewusst auf eine
|
||||
Umgebung, und das ist deklariert - nicht still.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Green Suite Blind Spot]]
|
||||
- [[Structural Enforcement over Documented Rule]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **abzugrenzen von:** [[Green Suite Blind Spot]]
|
||||
- **behoben durch:** [[Structural Enforcement over Documented Rule]]
|
||||
- **trat auf in:** [[wikitool]]
|
||||
- **beobachtet an:** [[Gitea Actions]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[Structural Enforcement over Documented Rule]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
- [[wikitool]]
|
||||
- [[Gitea Actions]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [cramming, heuristic, pages, creation]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Content Quality Control, 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
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Content Quality Control]] - Breitere Qualitätsrichtlinie
|
||||
- [[Split Threshold]] - Größenbasierte Aufteilungsregel
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **protected by:** [[Iteration and Cost Limits]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Multi-Agent Collaboration, Privacy and Governance, Quality and Self-Correction, Source - LLM Wiki v2, Supersession]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Unveränderliches chronologisches Log aller Wiki-Operationen (Ingest, Bearbeitung, Löschung, Abfrage) mit Zeitstempel, Akteur, Ziel und Änderungsbeschreibung.
|
||||
---
|
||||
# Audit Trail
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Ermöglicht Verantwortlichkeit, Debugging und Reversibilität von Wiki-Operationen durch Verwaltung eines nur-anhängbaren (append-only) Protokolls, das mit entsprechenden Seitenversionen und Entscheidungen verlinkt ist.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Schlüsselwortbasiertes Retrieval-Verfahren, das über Termfrequenz, inverse Dokumentfrequenz und Stemming exakte oder teilweise Übereinstimmungen findet.
|
||||
---
|
||||
# BM25
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Bietet schnelle, gut verstandene Suche für technische Begriffe und exakte Treffer; wird als eine Modalität in der Hybrid Search neben Vector- und Graph-Ansätzen verwendet.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Privacy and Governance, Implementation Spectrum, 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
|
||||
|
||||
- **ergaenzt:** [[Mass-Update Gate]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Mass-Update Gate]]
|
||||
|
||||
@@ -0,0 +1,105 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [pre-commit, hooks, automation, quality-control]
|
||||
created: 2026-08-03
|
||||
modified: 2026-09-01
|
||||
related: [wikitool, 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
|
||||
|
||||
- [[wikitool]] (stellt Lint- und andere Befehle für CI bereit)
|
||||
(die Reihenfolge hinter dem Coverage-Reporting)
|
||||
(CI-Gates ergänzen Runtime-Gates)
|
||||
- [[Lint Workflow]] (Lint ist eine Schlüssel-CI-Prüfung)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **verwendet:** [[wikitool]]
|
||||
- **implementiert über:** [[Gitea Actions]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[wikitool]]
|
||||
- [[Gitea Actions]]
|
||||
|
||||
## 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]]
|
||||
@@ -0,0 +1,45 @@
|
||||
# kb/concepts/ - Collection Contract
|
||||
|
||||
Ideas rather than things: architectures, patterns, protocols, workflows, recurring problems,
|
||||
and the decisions taken about them. A concept explains *how* or *why*, where an entity page
|
||||
records *what*.
|
||||
|
||||
**Quality goal:** explanatory sufficiency - the page should answer *why it is done this way*
|
||||
without the reader having to open the entity pages that use it. If the explanation only makes
|
||||
sense once you already know the system, it is on the wrong page.
|
||||
|
||||
Inherits [kb/CONTRACT.md](../CONTRACT.md) - naming, tone, linking, provenance and confidence
|
||||
are defined there and are not restated here.
|
||||
|
||||
## Types offered
|
||||
|
||||
`concept` (`tools/wikitool types describe concept`).
|
||||
|
||||
## Decisions and ADRs
|
||||
|
||||
An architectural decision is a concept page prefixed `adr-NNN-`, e.g.
|
||||
`adr-001-use-go-modules.md`. It records:
|
||||
|
||||
- **Context** - what forced a decision.
|
||||
- **Decision** - what was chosen.
|
||||
- **Consequences** - what this costs, not only what it buys.
|
||||
- **Status** - proposed / accepted / deprecated / superseded.
|
||||
- Links to every entity the decision affects.
|
||||
|
||||
A superseded ADR is never deleted or rewritten; a new one supersedes it and both link to the
|
||||
other with `replaces` / `replaced by`.
|
||||
|
||||
## Outbound linking
|
||||
|
||||
A concept links to every entity that implements or uses it. A concept with no inbound entity
|
||||
link is usually either premature or misfiled - `wikitool lint` reports it as an orphan.
|
||||
|
||||
Where two concepts compete, do not argue the comparison inside either page; create a page in
|
||||
`kb/comparisons/` and link both to it.
|
||||
|
||||
## What does not belong here
|
||||
|
||||
- A concrete, pointable thing - that is an entity.
|
||||
- A head-to-head evaluation of alternatives - that is a comparison.
|
||||
- Generic textbook explanation with no connection to anything in this wiki. If no entity here
|
||||
uses it, the page is not earning its keep.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: protocol
|
||||
tags: [power-management, cpu, amd, hardware]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Linux Kernel, amd-pstate, Kernel PM Governors]
|
||||
sources: [Source - AMD Powermanagement CPU]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Hardwareschnittstelle Collaborative Processor Performance Control für feingranulares CPU-Power-Management zwischen Betriebssystem und AMD-Prozessor.
|
||||
---
|
||||
# CPPC
|
||||
|
||||
**Typ:** Protokoll
|
||||
|
||||
## Definition
|
||||
|
||||
**CPPC (Collaborative Processor Performance Control)** ist eine Hardware-Schnittstelle und ein Protokoll, das eine präzisere und kooperativere Energieverwaltung zwischen dem Betriebssystem und der CPU-Hardware ermöglicht. Es bietet eine standardisierte Möglichkeit für das OS, Leistungsanforderungen zu kommunizieren und Rückmeldungen von der CPU zu erhalten.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Standard:** Collaborative Processor Performance Control
|
||||
- **Zweck:** Eine feingranulare CPU-Energieverwaltung ermöglichen
|
||||
- **Entwickler:** AMD (implementiert in neueren AMD-Prozessoren)
|
||||
- **OS-Unterstützung:** Linux Kernel 5.17+ via amd-pstate-Treiber
|
||||
- **Schnittstelle:** sysfs-exponierte Steuerelemente
|
||||
|
||||
## Features
|
||||
|
||||
CPPC bietet mehrere Schlüsselmöglichkeiten:
|
||||
|
||||
- **Leistungsziele:** Hardware kommuniziert optimale Leistungsziele an das OS
|
||||
- **Performance-Hinweise:** Hardware bietet Hinweise zu effizienten Betriebspunkten
|
||||
- **Rückmelde-Mechanismus:** Bidirektionale Kommunikation zwischen OS und Hardware
|
||||
- **Feinkörnige Kontrolle:** Körnigere Kontrolle als traditionelle P-States
|
||||
- **Dynamische Anpassung:** Ermöglicht Echtzeit-Anpassung basierend auf Arbeitslast-Charakteristiken
|
||||
|
||||
## Wie es funktioniert
|
||||
|
||||
1. **Hardware-Fähigkeiten:** CPPC-fähige CPUs stellen ihre Leistungscharakteristiken zur Verfügung
|
||||
2. **OS-Abfrage:** Das Betriebssystem (via amd-pstate) fragt CPPC nach verfügbaren Leistungszuständen ab
|
||||
3. **Regulator-Bewertung:** Kernel-Regulatoren (schedutil, ondemand) bewerten CPPC-Ziele und Hinweise
|
||||
4. **Zustandsauswahl:** Regulatoren wählen angepasste Leistungszustände basierend auf Arbeitslast und CPPC-Anleitung
|
||||
5. **Hardware-Antwort:** CPU passt ihre Betriebsparameter entsprechend an
|
||||
|
||||
## Vorteile gegenüber traditionellem ACPI
|
||||
|
||||
| Merkmal | CPPC (amd-pstate) | ACPI (acpi-cpufreq) |
|
||||
|---------|-------------------|---------------------|
|
||||
| Granularität | Feingranular | 3 P-States |
|
||||
| Rückmeldung | Hardware-Hinweise und Ziele | Statische Tabellen |
|
||||
| Effizienz | Optimiert für aktuelle Arbeitslast | Generisch |
|
||||
| Energieeinsparung | Überlegen | Begrenzt |
|
||||
| Mobiler Vorteil | Erweiterte Akkulaufzeit | Standard |
|
||||
|
||||
## Anwendungsfälle
|
||||
|
||||
- **Mobile Geräte:** Erweiterte Akkulaufzeit durch optimierte Energieverwaltung
|
||||
- **Server:** Bessere Energieeffizienz in Rechenzentren
|
||||
- **Desktops:** Responsive Leistung mit reduziertem Stromverbrauch
|
||||
- **Gemischte Arbeitslasten:** Intelligente Anpassung an wechselnde Arbeitslast-Anforderungen
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[amd-pstate]] - Linux-Kernel-Treiber, der CPPC für AMD-Prozessoren implementiert
|
||||
- [[Kernel PM Governors]] - CPPC-Ziele und Hinweise für Entscheidungsfindung verwenden
|
||||
- [[Linux Kernel]] 5.17+ - Enthält amd-pstate-Treiber mit CPPC-Unterstützung
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- Energieverwaltung
|
||||
- Leistungszustände (P-States)
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[amd-pstate]]
|
||||
- [[acpi-cpufreq]]
|
||||
- [[Kernel PM Governors]]
|
||||
- [[Linux Kernel]]
|
||||
@@ -0,0 +1,66 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [audit, checkpoint, rhythm, quality]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Semantic Lint Automation, 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]]
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [claude-code, permissions, auto-mode, harness, classifier]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [Claude Code, 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
|
||||
|
||||
- **wird umgesetzt von:** [[Claude Code]]
|
||||
- **steht in Konflikt mit:** [[Diff-Reviewable Agent Edits]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Claude Code]]
|
||||
- [[Diff-Reviewable Agent Edits]]
|
||||
- [[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]]
|
||||
@@ -0,0 +1,121 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: [wikitool, cli, idempotenz, tooling, datenintegritaet]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Self-Healing, Detect-Repair Asymmetry, Green Suite Blind Spot, Write-Once Frontmatter Fields]
|
||||
sources: [Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Anforderung, dass zwei Befehle auf derselben Datei in jeder Reihenfolge zusammenpassen und jeder erzeugte Zustand einen Gegenbefehl hat - 2026-08-31 in wikitool zweimal verletzt
|
||||
---
|
||||
# Command Round-Trip Integrity
|
||||
|
||||
**Typ:** Pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Command Round-Trip Integrity ist die Anforderung, dass zwei Befehle, die dieselbe Datei
|
||||
schreiben, in jeder Reihenfolge zusammenpassen und dass ein Befehl, der einen Zustand erzeugt,
|
||||
einen Gegenbefehl hat, der ihn vollständig zurücknimmt. Verletzt ist sie in zwei Formen: die
|
||||
**Reihenfolge entscheidet über den Inhalt** - der zweite Aufruf zerstört, was der erste
|
||||
geschrieben hat -, oder ein Befehl erzeugt einen Zustand, den **kein anderer Befehl mehr
|
||||
erreicht**.
|
||||
|
||||
Beide Formen sind auf Kommandoebene unsichtbar. Jeder einzelne Aufruf gelingt, meldet Erfolg
|
||||
und tut für sich genommen das Richtige; der Schaden entsteht erst aus der Kombination. In einem
|
||||
Stack, dessen Regeln jede Handeditierung ausschließen, ist die zweite Form die schwerere: eine
|
||||
Seite, die kein Befehl mehr reparieren kann, ist eine Sackgasse.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Der Anlassfall, Form 1 (Reihenfolge):** `split_cite_block()` in [[wikitool]] nahm alles von
|
||||
der Überschrift `## Fußnoten` bis zum Dateiende als Fußnotenblock und behielt daraus nur die
|
||||
Zitatdefinitionszeilen. Weil `xref add` seine Abschnitte ans Dateiende hängt, entschied allein die
|
||||
Reihenfolge von `xref add` und `cite add`, ob eine Seite ihre Querverweise behielt. Betroffen
|
||||
waren `cite add`, `cite sync` und `rename`; 8 Seiten mit 74 Zeilen standen in der gefährdeten
|
||||
Position[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Der Anlassfall, Form 2 (kein Gegenbefehl):** `xref add` schrieb auf einer Source-Seite ein
|
||||
`related:`, das `types/source.md` nicht deklariert, und `strip_frontmatter_ref()` räumte nur
|
||||
deklarierte Felder. `xref remove` konnte den Rest also nicht entfernen - ein Kommando erzeugte
|
||||
einen Zustand, den ein anderes nicht rückgängig machen konnte[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Die Reparatur ordnet die Ausgabe, statt die Aufrufer zu disziplinieren.** Der Fußnotenblock
|
||||
endet seit `1.5.1` an der nächsten Überschrift und wird immer zuletzt gerendert. Damit muss
|
||||
`xref add` sein Anhängen am Dateiende nicht ändern: der Widerspruch ist aufgelöst, nicht
|
||||
umgangen. Eine Regel „erst `xref`, dann `cite`" wäre eine Regel gewesen, an die sich jeder
|
||||
künftige Aufrufer hätte erinnern müssen[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Daraus folgt Selbstheilung.** Weil der Block immer zuletzt ausgegeben wird, bringt die erste
|
||||
Zitatoperation eine bereits verrutschte Seite von selbst wieder in Ordnung. Der Fix repariert
|
||||
nicht nur künftige Aufrufe, sondern den bestehenden Korpus im laufenden Betrieb - siehe
|
||||
[[Self-Healing]][^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Der Beleg ist Byte-Gleichheit, nicht ein grüner Test.** Nach `xref remove` und
|
||||
anschließendem `xref link-source` kam die referenzierende Concept-Seite byteidentisch aus dem
|
||||
Zyklus zurück. Erst das zeigt, dass die beiden Kommandos Inversen sind; ein Test, der nur
|
||||
prüft, dass hinterher wieder eine Referenz dasteht, würde eine umformatierte Seite
|
||||
durchlassen[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Vor dem Schreiben beide Seiten prüfen.** `xref add` validiert seit `1.6.0` beide Seiten,
|
||||
bevor es eine schreibt, damit eine Ablehnung keine halbe Verknüpfung hinterlässt. Eine
|
||||
abgebrochene bidirektionale Operation ist selbst ein Zustand ohne Gegenbefehl[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Die Feldwahl folgt der Collection, nicht einer Tabelle.** `xref link-source` legt ein Ziel
|
||||
aus `kb/entities/` in `entities:` und eines aus `kb/concepts/` in `concepts:` ab. Das
|
||||
Verzeichnis ist der Feldname, also braucht eine neue Collection keine Codeänderung, sondern
|
||||
einen Typ, der das passende Feld deklariert. Eine Typ-zu-Feld-Zuordnung wurde verworfen, weil
|
||||
sie eine zweite Kopie dessen wäre, was die Type-Specs schon sagen[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Abgrenzung zu [[Detect-Repair Asymmetry]]:** dort meldet ein Check einen Defekt, für den es
|
||||
keinen Reparaturbefehl gibt. Hier meldet niemand etwas - jeder beteiligte Aufruf endet mit
|
||||
Erfolg, und der Defekt zeigt sich erst an dem, was hinterher in der Datei fehlt.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - `cite add`/`xref add` (Gitea-Issue #17, geschlossen mit `1.5.1`) und
|
||||
`xref add`/`xref remove` auf einer Source-Seite (Issue #18, geschlossen mit `1.6.0`)
|
||||
- [[Self-Healing]] - die Eigenschaft, die aus der gewählten Reparatur folgt
|
||||
- [[Write-Once Frontmatter Fields]] - der Endzustand, wenn der Gegenbefehl fehlt, statt nur
|
||||
falsch zu greifen
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Entwurf eines Befehls, der eine Datei schreibt, die schon ein anderer Befehl schreibt:
|
||||
beide Reihenfolgen durchspielen, nicht nur die geplante.
|
||||
- Bei jedem Befehl, der einen Zustand *erzeugt*: benennen, welcher Befehl ihn wieder entfernt,
|
||||
und den Zyklus einmal vollständig durchlaufen - der Vergleich ist Byte-Gleichheit.
|
||||
- Bei einer Ablehnung, die auf ein anderes Kommando verweist: sie ist eine Behauptung über
|
||||
dessen Fähigkeiten und gehört mit dem Test ausgeliefert, der sie belegt (siehe
|
||||
[[Denylist over Allowlist]]).
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Befehle, die bewusst nicht umkehrbar sind, weil die Umkehrung eine andere Operation ist:
|
||||
`publish` schreibt Historie, und die Rücknahme eines Commits ist ein eigener Vorgang, keine
|
||||
fehlende Inverse.
|
||||
- Als Argument gegen anhängende Schreibvorgänge überhaupt. Das Problem war nicht das Anhängen
|
||||
am Dateiende, sondern ein Leser, der alles dahinter als seinen Bereich betrachtete.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Self-Healing]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **tritt auf in:** [[wikitool]]
|
||||
- **erzeugt:** [[Self-Healing]]
|
||||
- **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
|
||||
- **wird begünstigt durch:** [[Green Suite Blind Spot]]
|
||||
- **abgegrenzt gegen:** [[Write-Once Frontmatter Fields]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[wikitool]]
|
||||
- [[Self-Healing]]
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
- [[Write-Once Frontmatter Fields]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: [confidence, scoring, reliability, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memory Lifecycle, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Mechanismus, der faktischen Aussagen quantitative Werte nach Quellenzahl, Aktualität, Qualität und Bestätigung zuweist, um gut gestütztes Wissen zu erkennen.
|
||||
---
|
||||
# Confidence Scoring
|
||||
|
||||
**Typ:** Pattern (Wissens-Zuverlässigkeitsbeurteilung)
|
||||
|
||||
## Definition
|
||||
|
||||
Confidence Scoring ist ein Mechanismus zur Zuweisung einer **quantitativen Konfidenz-Bewertung** zu jedem faktische Aussage im Wiki, der es dem LLM ermöglicht, zwischen gut gestütztem Wissen und vorläufigen Beobachtungen zu unterscheiden. Dies ist eine Kernkomponente der [[Memory Lifecycle]]-Verwaltung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Die Scoring-Formel
|
||||
|
||||
Die Konfidenz-Bewertung jedes faktischen Aussage wird berechnet aus:
|
||||
|
||||
| Faktor | Gewichtung | Beschreibung |
|
||||
|--------|--------|-------------|
|
||||
| Basis-Konfidenz | +0.5 | Standard für jeden Aussage aus einer einzigen Quelle |
|
||||
| Quellenanzahl | +0.2 pro Quelle (max +0.6) | Mehr Quellen = höhere Konfidenz |
|
||||
| Aktualität | +0.2 (<30 Tage), +0.1 (<90 Tage) | Aktuelle Bestätigungen erhöhen Konfidenz |
|
||||
| Quellenqualität | +0.1 (Amtliche Dokumente), +0.05 (Reputabel) | Bessere Quellen = höhere Konfidenz |
|
||||
| Bestätigung | +0.1 | Mehrere unabhängige Quellen stimmen überein |
|
||||
| **Maximum** | **1.0** | Vollständige Konfidenz (selten) |
|
||||
|
||||
### Konfidenz-Verfall
|
||||
|
||||
Die Konfidenz **verfällt um 1% pro Monat** seit der letzten Bestätigung, mit einem **Minimum von 0.2**.
|
||||
|
||||
Dies modelliert die natürliche Erosion der Wissenssicherheit im Laufe der Zeit.
|
||||
|
||||
### Konfidenz-Schwellwerte für Sprache
|
||||
|
||||
Bei der Synthese von Antworten sollte der LLM Konfidenz-Bewertungen verwenden, um Aussagen zu qualifizieren:
|
||||
|
||||
- **Konfidenz ≥ 0.6:** Als Tatsache angeben („Projekt X verwendet Redis")
|
||||
- **0.4 ≤ Konfidenz < 0.6:** Versuchsweise Sprache verwenden („möglicherweise", „kann")
|
||||
- **0.2 ≤ Konfidenz < 0.4:** Als unsicher markieren („unsicher", „unbestätigt")
|
||||
- **Konfidenz < 0.2:** Sollte nicht in Antworten verwendet werden
|
||||
|
||||
## Implementierung
|
||||
|
||||
### Zu verfolgbende Metadaten
|
||||
|
||||
Für jede Aussage speichern:
|
||||
```yaml
|
||||
source: [list of source IDs]
|
||||
source_dates: [list of dates]
|
||||
last_confirmed: YYYY-MM-DD
|
||||
confidence: 0.XX
|
||||
quality_flags: [official, reputable, etc.]
|
||||
```
|
||||
|
||||
### Automation
|
||||
|
||||
Confidence Scoring funktioniert am besten mit [[Event-Driven Automation]]:
|
||||
|
||||
- **Bei Quellenaufnahme:** Anfängliche Konfidenz für extrahierte Aussagen berechnen
|
||||
- **Bei Zugriff auf Aussagen:** Konfidenz erhöhen (Verstärkung)
|
||||
- **Bei neuer bestätigender Quelle:** Konfidenz erhöhen, Quellen aktualisieren
|
||||
- **Bei Widerspruch:** [[Supersession]] oder [[Contradiction Resolution]] auslösen
|
||||
- **Nach Zeitplan (monatlich):** Alle Konfidenz-Scores verfallen lassen
|
||||
|
||||
## Beispiele
|
||||
|
||||
Aussage: „Das CI-System verwendet BuildKit auf Port 1234"
|
||||
|
||||
- **Quelle 1:** Interne Dokumentation (Amtlich) - datiert 2026-07-01
|
||||
- **Quelle 2:** Team-Besprechungsnotizen (Reputabel) - datiert 2026-07-15
|
||||
- **Zuletzt bestätigt:** 2026-07-20
|
||||
- **Aktuelles Datum:** 2026-07-26
|
||||
|
||||
Berechnung:
|
||||
- Basis: +0.5
|
||||
- Quellenanzahl (2): +0.4 (begrenzt auf +0.6, also +0.4)
|
||||
- Aktualität: +0.2 (Quelle 2 < 30 Tage)
|
||||
- Quellenqualität: +0.1 (Quelle 1 ist Amtlich)
|
||||
- **Zwischensumme:** 1.2 → **Begrenzt auf 1.0**
|
||||
- Verfall: 6 Tage seit letzter Bestätigung ≈ 0.2% Verfall
|
||||
- **Endgültige Konfidenz:** 0.996 ≈ **0.996**
|
||||
|
||||
Aussage: „Das CI-System verwendet BuildKit auf Port 1234." (als Tatsache angegeben)
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Transparenz:** Benutzer wissen, wie zuverlässig jeder Aussage ist
|
||||
- **Priorisierung:** Hochkonfidenz-Informationen erscheinen zuerst
|
||||
- **Vertrauen:** Stärkt das Vertrauen der Benutzer in die Wiki-Genauigkeit
|
||||
- **Selbstkorrektur:** Aussagen mit niedriger Konfidenz erhalten Aufmerksamkeit zur Überprüfung
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Alle faktischen Aussagen im Wiki
|
||||
- Besonders wichtig für:
|
||||
- Technische Spezifikationen
|
||||
- Architekturentscheidungen
|
||||
- Sicherheitsbezogene Informationen
|
||||
- Zeitempfindliches Wissen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Meinungen oder subjektive Aussagen
|
||||
- Definitionen, die sich nicht ändern
|
||||
- Reine deskriptive Metadaten
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Memory Lifecycle]] - Übergeordnetes Konzept
|
||||
- [[Supersession]] - Umgang mit widersprochenen Aussagen
|
||||
- [[Forgetting]] - Komplementärer Mechanismus für alte Aussagen
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
- [[Quality Scoring]] - Komplementäre Qualitätsmetriken
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (für automatisierte Konfidenz-Updates)
|
||||
- [[Contradiction Resolution]] (für Konfliktbehandlung)
|
||||
- [[Self-Healing]] (für automatisierte Konfidenz-Reparatur)
|
||||
@@ -0,0 +1,205 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [memory, tiers, consolidation, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memory Lifecycle, Working Memory, Episodic Memory, Semantic Memory, Procedural Memory, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Hierarchische Speicherarchitektur, die Informationen durch zunehmend verdichtete Schichten vom Working Memory bis zum Semantic und Procedural Memory befördert.
|
||||
---
|
||||
# Consolidation Tiers
|
||||
|
||||
**Typ:** Architektur (Tiered Knowledge Consolidation)
|
||||
|
||||
## Definition
|
||||
|
||||
Consolidation Tiers ist eine **hierarchische Speicherarchitektur**, die Informationen durch progressiv stärker komprimierte, bestätigte und langfristig verfügbare Schichten fördert. Dies adressiert das Problem, alle Beobachtungen gleich zu behandeln, und ermöglicht dem Wiki, zwischen Tentativbeobachtungen und gut etablierten Fakten zu unterscheiden.
|
||||
|
||||
Dies ist eine Kernkomponente des [[Memory Lifecycle]]-Managements, inspiriert durch kognitive Psychologie und implementiert in [[Agent Memory]].
|
||||
|
||||
## Tier-Struktur
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ PROCEDURAL MEMORY │
|
||||
│ Workflows, patterns, best practices, automated procedures │
|
||||
│ Longest-lived, highest confidence, most compressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Promote (extract patterns)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ SEMANTIC MEMORY │
|
||||
│ Cross-session facts, consolidated from multiple episodes │
|
||||
│ Long-lived, high confidence, moderately compressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Promote (consolidate facts)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ EPISODIC MEMORY │
|
||||
│ Session summaries, compressed from raw observations │
|
||||
│ Medium-lived, medium confidence, lightly compressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Promote (summarize session)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ WORKING MEMORY │
|
||||
│ Recent observations, not yet processed │
|
||||
│ Short-lived, low confidence, uncompressed │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Ingest (raw source)
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ RAW SOURCES │
|
||||
│ Immutable source documents (articles, notes, data) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Tier-Details
|
||||
|
||||
### Working Memory
|
||||
|
||||
**Zweck:** Aktuelle, unverarbeitete Beobachtungen halten
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Tage bis Wochen (kurzlebig)
|
||||
- **Konfidenz:** Niedrig (vorläufig, unbestätigt)
|
||||
- **Komprimierung:** Keine (rohe Beobachtungen)
|
||||
- **Zugriff:** Häufig zugegriffen während aktiver Arbeit
|
||||
- **Förderungstrigger:** Sitzungsabschluss, manuelle Überprüfung
|
||||
|
||||
**Inhalte:**
|
||||
- Aktuelle Quellenausschnitte
|
||||
- Vorläufige Erkenntnisse
|
||||
- Laufende Analysen
|
||||
- Unbestätigte Aussagen
|
||||
|
||||
**Beispiel:** "Beobachtet, dass das API-Ratelimit möglicherweise 100 req/min beträgt"
|
||||
|
||||
### Episodic Memory
|
||||
|
||||
**Zweck:** Sitzungsbezogene Zusammenfassungen und Erkenntnisse speichern
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Wochen bis Monate
|
||||
- **Konfidenz:** Mittel (in der Sitzung verifiziert)
|
||||
- **Komprimierung:** Leicht (aus Working Memory zusammengefasst)
|
||||
- **Zugriff:** Sitzungsbasierter Abruf
|
||||
- **Förderungstrigger:** Sitzungsübergreifende Bestätigung
|
||||
|
||||
**Inhalte:**
|
||||
- Sitzungszusammenfassungen
|
||||
- Haupterkenntnisse aus einzelnen Quellen
|
||||
- Sitzungsspezifischer Kontext
|
||||
- Verifizierte Fakten innerhalb der Sitzung
|
||||
|
||||
**Beispiel:** "Sitzung 2026-07-20: API-Ratelimit für Endpoint X bestätigt ist 100 req/min"
|
||||
|
||||
### Semantic Memory
|
||||
|
||||
**Zweck:** Sitzungsübergreifende allgemeine Fakten beibehalten
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Monate bis Jahre
|
||||
- **Konfidenz:** Hoch (sitzungsübergreifend bestätigt)
|
||||
- **Komprimierung:** Moderat (aus episodischem Speicher destilliert)
|
||||
- **Zugriff:** Allgemeiner Abfrageabruf
|
||||
- **Förderungstrigger:** Mustererkennung, wiederholte Beobachtung
|
||||
|
||||
**Inhalte:**
|
||||
- Etablierte Fakten
|
||||
- Querverweisenes Wissen
|
||||
- Domänenspezifische Informationen
|
||||
- Gut verifizierte Aussagen
|
||||
|
||||
**Beispiel:** "Das API-Ratelimit beträgt 100 req/min für Standard-Endpoints, 500 req/min für Premium"
|
||||
|
||||
### Procedural Memory
|
||||
|
||||
**Zweck:** Arbeitsabläufe, Muster und Best Practices erfassen
|
||||
|
||||
**Charakteristiken:**
|
||||
- **Lebensdauer:** Jahre (am längsten verfügbar)
|
||||
- **Konfidenz:** Sehr hoch (durch Wiederholung bewiesen)
|
||||
- **Komprimierung:** Hoch (abstrahierte Muster)
|
||||
- **Zugriff:** Arbeitsablauf- und Mustenabruf
|
||||
- **Förderungstrigger:** Mustererkennung aus semantischem Speicher
|
||||
|
||||
**Inhalte:**
|
||||
- Arbeitsabläufe und Verfahren
|
||||
- Entwurfsmuster
|
||||
- Best Practices
|
||||
- Automatisierte Verfahren
|
||||
- Bewährte Lösungen für wiederkehrende Probleme
|
||||
|
||||
**Beispiel:** "Beim Treffen von Ratelimits: 1) Endpoint-Tier prüfen, 2) Backoff implementieren, 3) Antworten cachen, 4) Kontingent-Erhöhung anfordern"
|
||||
|
||||
## Förderungskriterien
|
||||
|
||||
Informationen werden von einer Ebene zur nächsten befördert, wenn:
|
||||
|
||||
| Von → Zu | Kriterien |
|
||||
|-----------|----------|
|
||||
| Working → Episodic | Sitzung abgeschlossen, Beobachtungen zusammengefasst |
|
||||
| Episodic → Semantic | Fakt beobachtet in ≥2 unabhängigen Sitzungen, keine Widersprüche |
|
||||
| Semantic → Procedural | Muster erkannt über ≥5 Instanzen, bewiesenerweise wirksam |
|
||||
|
||||
## Aufbewahrung und Verfall
|
||||
|
||||
Jede Ebene hat unterschiedliche **Aufbewahrungsrichtlinien**:
|
||||
|
||||
| Ebene | Aufbewahrung | Verfallsrate | Archiv nach |
|
||||
|------|-----------|------------|---------------|
|
||||
| Working Memory | Aggressiv | Schnell | 30 Tage |
|
||||
| Episodic Memory | Moderat | Mittel | 90 Tage |
|
||||
| Semantic Memory | Konservativ | Langsam | 1 Jahr |
|
||||
| Procedural Memory | Dauerhaft | Sehr langsam | Nie |
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Effizienz:** Höhere Ebenen ermöglichen schnellere und zuverlässigere Abfragen
|
||||
- **Klarheit:** Unterscheidet zwischen vorläufigem und bewiesenem Wissen
|
||||
- **Skalierbarkeit:** Komprimierung reduziert Speicher- und Suchaufwand
|
||||
- **Lernen:** Ermöglicht Mustererkennung und Arbeitsablauf-Automatisierung
|
||||
- **Anpassungsfähigkeit:** Ebenenstruktur ermöglicht Wissensentwicklung
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
1. **Automatische Förderung:** [[Event-Driven Automation]] verwenden, um Förderungen beim Sitzungsabschluss auszulösen
|
||||
2. **Konfidenz-Verfolgung:** Mit [[Confidence Scoring]] für jede Ebene integrieren
|
||||
3. **Komprimierungsalgorithmen:** Inhalt automatisch zusammenfassen und destillieren beim Fördern
|
||||
4. **Querverweis-Verwaltung:** Sicherstellen, dass Links über Ebenen funktionieren
|
||||
5. **Suchoptimierung:** Höhere Ebenen in Suchergebnissen priorisieren
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das diverse Arten von Wissen verarbeiten soll
|
||||
- Domänen mit flüchtigen und permanenten Informationen
|
||||
- Situationen, in denen Wissensreife wichtig ist
|
||||
- Sitzungsübergreifende Forschungs- oder Entwicklungsprojekte
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Memory Lifecycle]] - Übergeordnetes Konzept
|
||||
- [[Working Memory]] - Ebene 1
|
||||
- [[Episodic Memory]] - Ebene 2
|
||||
- [[Semantic Memory]] - Ebene 3
|
||||
- [[Procedural Memory]] - Ebene 4
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Agent Memory]] - Produktive Implementierung
|
||||
- [[Forgetting]] - Ergänzender Aufbewahrungsmechanismus
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Confidence Scoring]] (für ebenenspezifische Konfidenz)
|
||||
- [[Event-Driven Automation]] (für Förderungstrigger)
|
||||
- [[Knowledge Graph]] (für ebenenübergreifende Beziehungen)
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [quality, lint, thresholds, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Semantic Lint Automation, Stub Threshold, 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
|
||||
|
||||
- [[Semantic Lint Automation]] - Automatisierte semantische Überprüfungen, die Qualitätsschwellwerte beinhalten könnten
|
||||
- [[Stub Threshold]] - Spezifische Mindestanforderung an Inhalte
|
||||
- [[Split Threshold]] - Spezifische maximale Größe vor dem Aufteilen
|
||||
- [[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]]
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [context, isolation, efficiency]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Grundsatz, für jede Aufgabe nur den jeweils benötigten Kontext zu laden
|
||||
---
|
||||
# Context Isolation
|
||||
|
||||
**Typ:** Architektur
|
||||
|
||||
## Definition
|
||||
|
||||
Context Isolation ist das Prinzip, nur die relevanten Anweisungen und Kontexte für jede spezifische Aufgabe zu laden, anstatt einen gesamten monolithischen Anweisungssatz unabhängig von der ausgeführten Aufgabe zu laden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Task-spezifisches Laden**: Nur das für die aktuelle Aufgabe relevante Skill wird in den Kontext geladen
|
||||
- **Reduzierte Token-Nutzung**: Signifikant niedrigere Token-Kosten im Vergleich zu monolithischen Ansätzen[^s-copilot-skill-restructure-instructions]
|
||||
- **Verbesserte Qualität**: LLMs können sich auf die spezifische Aufgabe konzentrieren, ohne von irrelevanten Anweisungen abgelenkt zu werden
|
||||
- **Gemeinsames Verzeichnismuster**: Erreicht durch `.agents/skills/`-Verzeichnis mit Tool-spezifischer Verdrahtung[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Nur `wiki-ingest` Skill beim Ausführen einer Ingest-Operation laden
|
||||
- Nur `wiki-query` Skill beim Beantworten einer Abfrage laden
|
||||
- Der RTFM/Abruf-Schicht-Ansatz, der zuerst Metadaten bereitstellt und nur bei Bedarf erweitert[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Context Isolation verwenden, wenn:
|
||||
- der Anweisungssatz mehrere unterschiedliche Arbeitsabläufe enthält
|
||||
- Token-Nutzung zu optimieren und Kosten zu senken ist
|
||||
- Aufgaben mit minimaler Überschneidung sauber getrennt werden können
|
||||
- mehrere LLM-Tools mit unterschiedlichen Kontextfenstern angewendet werden
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Context Isolation ist weniger wirksam, wenn:
|
||||
- Aufgaben stark voneinander abhängig sind und erfordern ein Verständnis mehrerer Arbeitsabläufe gleichzeitig
|
||||
- Der Overhead für die Verwaltung separater Kontexte die Vorteile überwiegt
|
||||
- Ihr Anweisungssatz klein genug ist, dass das Laden von allem kein Problem darstellt
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Token Economics]]
|
||||
- [[Scale Ceiling]]
|
||||
- [[Workflow Extraction]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Confidence Scoring, Event-Driven Automation, Multi-Agent Collaboration, Quality and Self-Correction, Source - LLM Wiki v2, Supersession]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Automatisches Erkennen und Auflösen widersprüchlicher Aussagen anhand von Konfidenz, Aktualität und Autorität der Quelle.
|
||||
---
|
||||
# Contradiction Resolution
|
||||
|
||||
**Typ:** Muster
|
||||
|
||||
## Definition
|
||||
|
||||
Wenn zwei Seiten widersprüchliche Fakten behaupten, bestimmt die Contradiction Resolution, welcher Aussage besser gestützt ist (über Aktualität, Quellqualität, Bestätigung), und markiert den Aussage mit niedrigerem Vertrauen als überlagert, während er für historische Referenzen erhalten bleibt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,84 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [skills, agents, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Architektur fuer Agent-Skills, die ueber mehrere LLM-Werkzeuge hinweg funktionieren; in Chemenu selbst am 2026-08-04 umgesetzt und ueberprueft
|
||||
---
|
||||
# Cross-platform Agent Skills
|
||||
|
||||
**Typ:** Architektur
|
||||
|
||||
## Definition
|
||||
|
||||
Cross-platform Agent Skills ist ein Architekturmuster, bei dem diskrete, aufrufbare Agent-Anweisungen einmal geschrieben und mehreren LLM-Tools (wie GitHub Copilot, Claude Code, Codex CLI und Mistral Vibe) über eine gemeinsame Verzeichnisstruktur und Tool-spezifische Verdrahtung zur Verfügung gestellt werden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Einzelne Quelle der Wahrheit**: Skills werden einmal an einem gemeinsamen Ort (`.agents/skills/`) definiert und von allen Tools referenziert
|
||||
- **Tool-spezifische Verdrahtung**: Jedes LLM-Tool hat seine eigene Art, Skills zu entdecken, die über Symlinks oder Konfiguration einheitlich gestaltet werden können
|
||||
- **Context Isolation**: Jeder Skill wird nur bei Aufruf geladen, was die Token-Nutzung im Vergleich zu monolithischen Anweisungsdateien reduziert
|
||||
- **Lossless Extraction**: Workflow-Logik wird wörtlich aus monolithischen Dateien in diskrete Skills extrahiert, ohne die Substanz zu ändern
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wiki-skills]] - Sechs eigenständige Claude Code Skills, die das Muster demonstrieren
|
||||
- [[wiki-skills-vanillaflava]] - Referenzimplementierung für Cross-Platform-Verteilung
|
||||
- [[llm-wiki-skills]] - Eine weitere Cross-Platform-Implementierung
|
||||
- [[Chemenu]] - **Implementiertes Muster am 2026-08-04**: 5 Skills
|
||||
(`wiki-ingest`/`wiki-query`/`wiki-lint`/`wiki-manage`/`wiki-status`) unter `.agents/skills/`,
|
||||
gespiegelt zu `.claude/skills/` via `tools/wikitool skills sync`[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]
|
||||
|
||||
## Überprüfte Tool-Unterstützung (2026-08-04)
|
||||
|
||||
Direkte Bestätigung pro Tool, korrigiert/überlagernd die unverifizierten Aussagen aus dem Original
|
||||
Ingest[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]:
|
||||
|
||||
- **GitHub Copilot** (VS Code): liest nativ `.github/skills/`, `.agents/skills/` und
|
||||
`.claude/skills/` im Projektumfang - kein Symlink oder zusätzliche Konfiguration in den
|
||||
gebündelten Dokumentationen bestätigt.
|
||||
- **Codex CLI**: liest nativ `.agents/skills` (CWD bis zum Repo-Stamm) plus
|
||||
`$HOME/.agents/skills` - **nicht** `~/.codex/skills/` wie ursprünglich behauptet; kein Symlink erforderlich.
|
||||
- **Mistral Vibe**: liest nativ `.vibe/skills/` und `.agents/skills/` (Projekt,
|
||||
vertrauensordner-gated) plus die Benutzerumfang-Entsprechungen - direkt aus der Quelle bestätigt.
|
||||
- **Claude Code**: liest nur `.claude/skills/` (Projekt) oder `~/.claude/skills/` (persönlich) -
|
||||
liest **nicht** nativ `.agents/skills/`, daher ist es das einzige Tool, das einen generierten
|
||||
Spiegel benötigt.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Cross-Platform Agent Skills verwenden, wenn:
|
||||
- die gleichen Workflows über mehrere LLM-Tools hinweg erforderlich sind
|
||||
- der Anweisungssatz groß genug ist, dass das Laden von allem für jede Aufgabe ineffizient ist
|
||||
- eine einzige Quelle der Wahrheit für die Agent-Anweisungen beibehalten werden soll
|
||||
- Workflows sauber in diskrete, selbstständige Operationen unterteilt werden können
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Dieses Muster vermeiden, wenn:
|
||||
- nur ein einzelnes LLM-Tool verwendet wird und keine Cross-Platform-Kompatibilität erforderlich ist
|
||||
- Workflows so eng gekoppelt sind, dass sie nicht sauber unterteilt werden können
|
||||
- der Overhead für die Verwaltung der Skill-Struktur die Vorteile überwiegt
|
||||
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Token Economics]]
|
||||
- [[Scale Ceiling]]
|
||||
- [[Context Isolation]]
|
||||
- [[Workflow Extraction]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
@@ -0,0 +1,150 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [crystallization, knowledge, distillation, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, 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
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Memory Lifecycle]] - Wie kristallisiertes Wissen verwaltet wird
|
||||
- [[Event-Driven Automation]] - Für automatische Crystallization
|
||||
- [[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)
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: decision
|
||||
tags: [schema, tooling, cli, design-rule]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Write-Once Frontmatter Fields, AGENTS.md, Green Suite Blind Spot]
|
||||
sources: [Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Entscheidung, schreibbare Felder als Schema minus kurzer Sperrliste zu bestimmen statt als gepflegte Positivliste, weil die Positivliste eine zweite Kopie des Schemas waere
|
||||
---
|
||||
# Denylist over Allowlist
|
||||
|
||||
**Typ:** Decision
|
||||
|
||||
## Definition
|
||||
|
||||
Wenn ein Befehl entscheiden muss, welche Felder er schreiben darf, wird die Menge als **Schema
|
||||
minus kurzer Sperrliste** bestimmt, nicht als gepflegte Positivliste. Die Sperrliste nennt zu
|
||||
jedem Eintrag den Befehl, dem das Feld stattdessen gehört.
|
||||
|
||||
## Kontext
|
||||
|
||||
`touch --set` brauchte eine Antwort auf die Frage, welche Frontmatter-Felder es schreiben darf.
|
||||
Torben wurden drei Varianten mit ihren Folgen vorgelegt: Denylist, Allowlist, und eine Denylist,
|
||||
die zusätzlich die Felder sperrt, für die es bereits eigene Optionen gibt
|
||||
(`summary`, `provenance`, `confidence_base`)[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Denylist. Das Argument, das den Ausschlag gab: eine gepflegte Allowlist ist eine zweite Kopie
|
||||
des Schemas, und die Kopie ist die Seite, die driftet - Invariante 8 aus `AGENTS.md`, angewandt
|
||||
auf eine Konstante im
|
||||
Code[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
|
||||
Gesperrt sind in [[wikitool]] vier Gruppen, jede mit einer Zuständigkeit als Begründung:
|
||||
|
||||
- `type:` - ändert Schema *und* Verzeichnis der Seite; das ist der Seiten-Lebenszyklus, kein
|
||||
Feldschreibvorgang.
|
||||
- `confidence:` - aus `confidence_base` durch Decay abgeleitet, nicht autorisiert.
|
||||
- `related:`, `sources:`, `entities:`, `concepts:` - gehören `xref`, das auch die Gegenrichtung
|
||||
und die Body-Bullets pflegt; ein blanker Frontmatter-Schreibvorgang ließe die andere Hälfte
|
||||
stehen.
|
||||
|
||||
Die dritte Variante - zusätzlich `summary`, `provenance` und `confidence_base` zu sperren, damit
|
||||
es für eine Sache nur einen Weg gibt - wurde nicht gewählt: die Ersparnis wäre eine
|
||||
Verweigerung, die für den Nutzer überraschend
|
||||
aussieht[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- **Ein neues Schema-Feld ist sofort schreibbar,** ohne Codeänderung. Das ist der Zweck der
|
||||
Entscheidung und zugleich ihr Risiko: ein Feld, das eigentlich einen eigenen Befehl bräuchte,
|
||||
wird schreibbar ausgeliefert, wenn niemand daran denkt, es zu sperren.
|
||||
- **Die Sperrliste muss ihre Gründe mitführen.** Jeder Eintrag nennt den zuständigen Befehl,
|
||||
weil die Ablehnung sonst nur "nein" sagt statt zu routen. Eine gesperrte Zuständigkeit ist
|
||||
ein Routing-Problem; ein unbekanntes Feld dagegen ist ein Tippfehler, und die Meldung listet
|
||||
dort auf, welche Felder die Seite tatsächlich hat.
|
||||
- **Der Verweis in einer Ablehnung ist eine Behauptung über ein anderes Kommando.** Die
|
||||
Sperrliste aus `1.4.0` lehnte die Seiten-Referenz-Felder mit dem Hinweis auf `xref add` und
|
||||
`xref remove` ab. Die Sperre war richtig, das Verweisziel nicht: für die `entities:` und
|
||||
`concepts:` einer Source-Seite konnte `xref add` gar nicht schreiben, und was es dort
|
||||
schrieb, bekam `xref remove` nicht wieder weg. Eine Ablehnung, die weiterroutet, gehört
|
||||
deshalb mit einem Test ausgeliefert, der zeigt, dass das genannte Kommando den Fall
|
||||
abdeckt - andernfalls schickt sie den Aufrufer in eine Sackgasse und sieht dabei aus wie
|
||||
Hilfe. Behoben mit `1.6.0` (Gitea-Issue #18), nicht durch eine Änderung an der
|
||||
Sperrliste[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]
|
||||
- **Der Ansatz überträgt sich auf jeden schemagetriebenen Befehl,** nicht nur auf `touch`. Wo
|
||||
eine Positivliste dieselbe Information ein zweites Mal aufschreiben würde, ist die Sperrliste
|
||||
die kleinere Kopie.
|
||||
- **Er ist kein Sicherheitsmuster.** Für eine Vertrauensgrenze gilt fail-closed, also die
|
||||
Allowlist. Diese Entscheidung betrifft eine Zuständigkeitsverteilung innerhalb eines
|
||||
Werkzeugs, das ohnehin alle Felder schreiben kann.
|
||||
|
||||
## Status
|
||||
|
||||
Angenommen (2026-08-31) mit Stack-Version `1.4.0`, Commit
|
||||
`dbe2f73`[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **umgesetzt in:** [[wikitool]]
|
||||
- **begründet die Lösung von:** [[Write-Once Frontmatter Fields]]
|
||||
- **beruft sich auf:** [[AGENTS.md]]
|
||||
- **verwandt mit:** [[Green Suite Blind Spot]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[Write-Once Frontmatter Fields]]
|
||||
- [[AGENTS.md]]
|
||||
- [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
@@ -0,0 +1,135 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: problem
|
||||
tags: [tooling, lint, provenance, hand-edit, gap]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Lint Workflow, Self-Healing, Issue Label Scheme, Write-Once Frontmatter Fields, Command Round-Trip Integrity]
|
||||
sources: [Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: Werkzeugluecke, in der ein Check einen Defekt zuverlaessig meldet, aber kein Befehl ihn behebt - womit die Handeditierung der einzige verbleibende Ausweg ist
|
||||
---
|
||||
# Detect-Repair Asymmetry
|
||||
|
||||
**Typ:** Problem
|
||||
|
||||
## Definition
|
||||
|
||||
Detect-Repair Asymmetry beschreibt den Zustand, in dem ein Werkzeug einen Defekt zuverlässig
|
||||
**meldet**, aber keinen Befehl anbietet, der ihn **behebt**. Der Agent, dem das Werkzeug den
|
||||
Befund vorlegt, hat dann genau zwei Auswege: den Defekt stehen lassen oder ihn von Hand
|
||||
reparieren. In einem Stack, dessen Kernprinzip lautet, dass Mechanisches das Werkzeug erledigt
|
||||
und niemals die Hand, führt eine solche Lücke die Handeditierung als einzige verbleibende
|
||||
Option wieder ein - an genau der Stelle, an der die Regeln sie am dringendsten ausschließen
|
||||
wollen.
|
||||
|
||||
Die Asymmetrie ist keine Regelverletzung, sondern ein Konstruktionsfehler in der
|
||||
Werkzeugoberfläche. Sie fällt erst auf, wenn der gemeldete Defekt zum ersten Mal wirklich
|
||||
auftritt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Melden und Reparieren sind getrennte Fähigkeiten.** Ein Check zu schreiben ist billig, ein
|
||||
Reparaturbefehl teuer, weil er den korrekten Zielzustand kennen und atomar herstellen muss.
|
||||
Deshalb entsteht die Lücke nicht aus Nachlässigkeit, sondern aus dem Kostengefälle zwischen
|
||||
beiden.
|
||||
- **Der Befund selbst erzeugt den Druck.** Solange niemand die kaputte Referenz sieht, gibt es
|
||||
keinen Anlass, sie von Hand zu korrigieren. Sobald `lint` sie in jedem Lauf meldet, ist die
|
||||
Handeditierung der kürzeste Weg zu einem sauberen Lauf.
|
||||
- **Fall aus diesem Wiki (2026-08-31):** `lint` und `sources coverage` melden kaputte
|
||||
`raw_files:`-Referenzen zuverlässig, aber kein `wikitool`-Befehl schreibt `raw_files:` auf
|
||||
einer bestehenden Seite. `touch` deckt die Felder ab, die die Seite selbst beschreiben,
|
||||
`xref` die Seiten-Referenz-Arrays; `raw_files:` ist keines von beidem, weil es auf einen Pfad
|
||||
zeigt und nicht auf einen Seitentitel. `new source --set raw_files=…` schreibt das Feld genau
|
||||
einmal, bei der Erstellung[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31].
|
||||
- **Formal erlaubt ist nicht dasselbe wie beabsichtigt.** Invariante 1 aus `AGENTS.md` zählt
|
||||
Katalog, `log.md`, `provenance.md`, die Skill-Verzeichnisse, die beiden JSON-Dateien und die
|
||||
Seiten-Referenz-Arrays auf. `raw_files:` steht in keiner dieser Aufzählungen, die
|
||||
Handeditierung ist also nicht verboten - sie widerspricht nur dem Kernprinzip, aus dem die
|
||||
Aufzählung
|
||||
stammt[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31].
|
||||
- **Die Reparatur gehört dorthin, wo der Zwischenzustand nie existiert.** Für den konkreten
|
||||
Fall wurde `raw rename` vorgeschlagen, das `git mv` und jede referenzierende Source-Seite in
|
||||
einem Schritt erledigt, statt eines nachgelagerten `sources relink`: nur in der gebündelten
|
||||
Form gibt es keinen Moment, in dem die Datei weg ist und die Referenz
|
||||
hängt[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31].
|
||||
- **Der Fall wurde am selben Tag geschlossen, und wie er geschlossen wurde, ist die
|
||||
Verallgemeinerung.** `1.4.0` (Commit `dbe2f73`) gab `touch` ein `--set`/`--add`/`--remove`,
|
||||
das jedes vom Schema deklarierte Feld erreicht statt nur `raw_files:`. Der Reparaturbefehl
|
||||
wurde also nicht auf den gemeldeten Befund zugeschnitten, sondern auf die Feldklasse, zu der
|
||||
er gehört - siehe
|
||||
[[Write-Once Frontmatter Fields]][^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
- **Die gebündelte Form blieb trotzdem offen.** `raw rename`, das `git mv` und jede
|
||||
referenzierende Source-Seite in einem Schritt erledigt, wurde als Issue #16 abgespalten. Der
|
||||
Zwischenzustand „Datei weg, Referenz hängt" existiert seit `1.4.0` also kürzer - zwei Befehle
|
||||
statt einer Handeditierung -, aber er existiert noch[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
- **Zweiter Fall, andere Herkunft (2026-08-31):** auf einer Source-Seite stand ein `related:`,
|
||||
das `types/source.md` nicht deklariert. `lint` meldete den Schema-Fehler zuverlässig, aber
|
||||
`xref remove` räumte nur deklarierte Felder und erreichte ihn nicht. Die Asymmetrie entstand
|
||||
hier nicht aus einer fehlenden Fähigkeit, sondern daraus, dass ein Schwesterbefehl einen
|
||||
Zustand schreiben konnte, den der Gegenbefehl nicht kannte - geschlossen mit `1.6.0`
|
||||
(Gitea-Issue #18). Die Klasse dieser Kombination ist
|
||||
[[Command Round-Trip Integrity]][^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]
|
||||
- **Verwandt, aber nicht dasselbe wie [[Self-Healing]]:** Self-Healing beschreibt, dass ein
|
||||
Lauf gefundene Mängel automatisch behebt. Detect-Repair Asymmetry beschreibt den Fall davor -
|
||||
dass es den Befehl, den ein Self-Healing-Lauf aufrufen müsste, überhaupt nicht gibt.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - `lint` und `sources coverage` meldeten kaputte `raw_files:`-Referenzen, ohne
|
||||
dass ein Befehl sie korrigierte (Gitea-Issue #14, geschlossen mit `1.4.0`); die gebündelte
|
||||
Reparatur `raw rename` ist als Issue #16 offen
|
||||
- [[Lint Workflow]] - der Lauf, der den Befund erzeugt und damit den Druck, ihn von Hand
|
||||
wegzuräumen
|
||||
- [[wikitool]] - `lint` meldete das undeklarierte `related:` auf einer Source-Seite, das kein
|
||||
Befehl entfernen konnte (Gitea-Issue #18, geschlossen mit `1.6.0`)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Entwurf eines neuen Checks: prüfen, ob es für jeden Befund, den er erzeugen kann, einen
|
||||
Befehl gibt, der ihn behebt. Wenn nicht, ist der Check ohne den zugehörigen Reparaturbefehl
|
||||
unvollständig ausgeliefert.
|
||||
- Bei der Bewertung einer wiederkehrenden Handeditierung: die Frage ist nicht, warum der Agent
|
||||
sie vorgenommen hat, sondern welcher Befehl fehlte.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Befunde, die ein Urteil verlangen und deshalb gar keinen deterministischen Zielzustand
|
||||
haben - ein Widerspruch zwischen zwei Seiten oder eine veraltete Aussage sind semantische
|
||||
Befunde, kein fehlender Befehl.
|
||||
- Als Begründung, einen Check wegzulassen, bis die Reparatur fertig ist. Ein gemeldeter Defekt
|
||||
ohne Reparatur ist immer noch besser als ein unbemerkter.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Self-Healing]]
|
||||
- [[Lint Workflow]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **abgegrenzt gegen:** [[Write-Once Frontmatter Fields]]
|
||||
- **tritt auf in:** [[wikitool]]
|
||||
- **wird sichtbar durch:** [[Lint Workflow]]
|
||||
- **abgegrenzt gegen:** [[Self-Healing]]
|
||||
- **verwandt mit:** [[Issue Label Scheme]]
|
||||
- **abgegrenzt gegen:** [[Command Round-Trip Integrity]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Write-Once Frontmatter Fields]]
|
||||
- [[wikitool]]
|
||||
- [[Lint Workflow]]
|
||||
- [[Self-Healing]]
|
||||
- [[Issue Label Scheme]]
|
||||
- [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[Command Round-Trip Integrity]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
|
||||
[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
@@ -0,0 +1,91 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: decision
|
||||
tags: [agent-workflow, context-engineering, tooling]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [Claude Code Auto Mode, Claude Code, Write-Once Frontmatter Fields]
|
||||
sources: [Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Entscheidung, Dateiaenderungen ueber Edit/Write statt ueber Shell-Heredocs zu fahren, weil nur das erste eine pruefbare Diff hinterlaesst
|
||||
---
|
||||
# Diff-Reviewable Agent Edits
|
||||
|
||||
**Typ:** Decision
|
||||
|
||||
## Definition
|
||||
|
||||
Ein Agent ändert Dateien über die dedizierten Werkzeuge `Edit` und `Write`, nicht über
|
||||
Shell-Konstrukte wie `sed -i`, Heredocs oder eingebettete Skripte. Die Shell bleibt für alles
|
||||
zuständig, was keine Datei umschreibt: `git`, `pytest`, [[wikitool]], `grep`, `find`, und Lesen
|
||||
mit `cat` oder `sed -n`.
|
||||
|
||||
## Kontext
|
||||
|
||||
Der aktive Berechtigungsmodus [[Claude Code Auto Mode]] injiziert eine Anweisung in die Sitzung,
|
||||
die genau das Gegenteil verlangt: Arbeit möglichst über das Bash-Werkzeug erledigen und auf ein
|
||||
dediziertes Werkzeug erst zurückfallen, wenn Bash die Aufgabe nicht bewältigt. Der Assistent war
|
||||
ihr gefolgt und hatte `lint.py`, `frontmatter_io.py` und `run_budget.py` über heredoc'te
|
||||
`python3 - <<'PY'`-Blöcke mit `s.replace(old, new)`
|
||||
umgeschrieben[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]. Torben hat das
|
||||
abgestellt:
|
||||
*"Warum verwendest du seit neuestem immer die Shell um Dateien zu editieren anstelle der file
|
||||
edit Tools? Das macht die Session schwer nachvollziehbar."*
|
||||
|
||||
## Entscheidung
|
||||
|
||||
`Edit`/`Write` für Dateiänderungen, Bash für Prozesse. Die Regel wurde in das dauerhafte
|
||||
Gedächtnis des Assistenten geschrieben, damit sie die Sitzung
|
||||
überdauert[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31].
|
||||
|
||||
Zwei Gründe tragen sie, und der zweite ist der belastbarere:
|
||||
|
||||
1. **Die ausdrückliche Anweisung des Nutzers rangiert über einer Modus-Voreinstellung.**
|
||||
2. **Die Anweisung des Modus schlägt sich selbst.** Ihr Qualifikator lautet *"wherever it can
|
||||
accomplish the job"*. Ein `s.replace(old, new)` in einem Heredoc zeigt dem Leser zwei
|
||||
String-Literale und keine Änderungsansicht: was vorher in der Datei stand und was jetzt darin
|
||||
steht, ist nicht sichtbar. Ein Edit, dessen Diff niemand prüfen kann, erfüllt die Aufgabe
|
||||
nicht - also greift der Vorrang der Shell an dieser Stelle gar nicht erst.
|
||||
|
||||
## Konsequenzen
|
||||
|
||||
- Die Grenze verläuft zwischen **Lesen** und **Schreiben**, nicht zwischen Shell und Werkzeug.
|
||||
`cat`, `head`, `sed -n`, `grep` und `find` bleiben unverändert zulässig.
|
||||
- Sie verläuft nicht bei jeder Änderung gleich scharf: bei einem einzeiligen `sed` ist der
|
||||
Unterschied unerheblich, beim Mehrblock-Umbau eines Compiler-Moduls nicht. Die Regel wird
|
||||
trotzdem einheitlich angewandt, weil die Einschätzung "das ist klein genug" genau die ist, die
|
||||
im Zweifelsfall zugunsten der Bequemlichkeit ausfällt.
|
||||
- Der Modus lässt sich nicht so einstellen, dass nur diese Präferenz entfällt; es wurde keine
|
||||
solche Einstellung
|
||||
gefunden[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]. Die Regel muss also
|
||||
als Verhaltensregel getragen werden, nicht als Konfiguration.
|
||||
- In diesem Repository fällt die Entscheidung mit den Interessen des Stacks zusammen: was
|
||||
`wikitool` erzeugt, wird ohnehin nie von Hand geschrieben, und was von Hand geschrieben wird,
|
||||
soll im Publish-Diff nachlesbar sein.
|
||||
|
||||
## Status
|
||||
|
||||
Angenommen (2026-08-31), auf Anweisung des Nutzers, für Sitzungen an diesem Repository.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Claude Code Auto Mode]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **korrigiert:** [[Claude Code Auto Mode]]
|
||||
- **gilt für:** [[Claude Code]]
|
||||
- **war betroffen von:** [[Write-Once Frontmatter Fields]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Claude Code Auto Mode]]
|
||||
- [[Claude Code]]
|
||||
- [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
- [[Write-Once Frontmatter Fields]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-auto-mode-and-tool-choice-session-2026-08-31]: [[Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Knowledge Graph, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Erkennen und Strukturieren von Entities (Personen, Projekte, Bibliotheken, Concepts, Dateien, Entscheidungen, Systeme, Werkzeuge) samt typspezifischer Attribute aus Rohquellen.
|
||||
---
|
||||
# Entity Extraction
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Beim Ingest füllen extrahierte Entitäten den Knowledge Graph mit Typen und Attributen, was strukturierte Abfragen und typisierte Beziehungserstellung neben narrativen Wiki-Seiten ermöglicht.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Speicherschicht für verdichtete Sitzungszusammenfassungen und Befunde; Brücke zwischen rohem Working Memory und langlebigem Semantic Memory.
|
||||
---
|
||||
# Episodic Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Enthält mittelfristig beständiges Wissen mit mittlerem Vertrauen und leichter Komprimierung; wird aus dem Arbeitsgedächtnis beim Sitzungsende hochgestuft und ins Semantische Gedächtnis konsolidiert, wenn Muster entstehen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,185 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [automation, hooks, events, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, 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
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Memory Lifecycle]] - Was Automatisierung verwaltet
|
||||
- [[Hooks]] - Der Implementierungsmechanismus
|
||||
- [[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)
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Privacy and Governance]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Automatisches Erkennen und Entfernen sensibler Daten (API-Schlüssel, Token, Credentials, personenbezogene Daten) vor der Aufnahme ins Wiki, per Regex und ML-Erkennung.
|
||||
---
|
||||
# Filter on Ingest
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Entfernt Muster wie AWS-Schlüssel, GitHub-Tokens, E-Mail-Adressen und als private markierte Inhalte, um sicherzustellen, dass das Wiki sicher für kollaborative und nachverfolgbare Nutzung ohne manuelle Bereinigung bleibt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,161 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: [memory, retention, decay, ebbinghaus]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memory Lifecycle, Confidence Scoring, Consolidation Tiers]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Muster zur Wissensbindung, das selten abgerufene Fakten schrittweise zurückstuft, modelliert nach der Ebbinghausschen Vergessenskurve.
|
||||
---
|
||||
# Forgetting
|
||||
|
||||
**Typ:** Pattern (Wissensspeicherungsverwaltung)
|
||||
|
||||
## Definition
|
||||
|
||||
Forgetting ist der Mechanismus, durch den **Fakten, die einmal wichtig waren, aber seit Monaten nicht aufgerufen oder verstärkt wurden, allmählich aus der Bedeutung im Wiki verschwinden**. Dies implementiert eine Aufbewahrungskurve, die sich von Ebbinghaus' Vergessenskurve aus der kognitiven Psychologie inspiriert.
|
||||
|
||||
Dies ist eine Kernkomponente der Verwaltung des [[Memory Lifecycle]] und stellt sicher, dass das Wiki nicht zu einem lauten Friedhof veralteter Informationen wird.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Ohne Vergessen:
|
||||
- Jedes Wissensstück wird für immer als gleich wichtig behandelt
|
||||
- Alte, irrelevante Informationen verstopfen das Wiki
|
||||
- Suchergebnisse werden mit veralteten Inhalten verunreinigt
|
||||
- Das Wiki wird zu einer Rumpelkammer
|
||||
|
||||
### Die Lösung
|
||||
|
||||
**Allmähliche Herabstufung** statt Löschung implementieren:
|
||||
|
||||
- Fakten werden **nicht gelöscht** (historischer Datensatz bleibt erhalten)
|
||||
- Fakten werden **in Suche und Synthese herabgestuft**
|
||||
- Herabstufung ist **allmählich** (nicht plötzlich)
|
||||
- Unterschiedliche **Verfallsraten** für verschiedene Wissenstypen
|
||||
|
||||
### Aufbewahrungskurve
|
||||
|
||||
Inspiriert von Ebbinghaus' Vergessenskurve:
|
||||
|
||||
```
|
||||
Vertrauen/Priorität
|
||||
1.0 │ *
|
||||
│ *
|
||||
│ *
|
||||
│ *
|
||||
0.8 │ *
|
||||
│ *
|
||||
│ *
|
||||
│ *
|
||||
0.6 │ *
|
||||
│ *
|
||||
│ *
|
||||
│ *
|
||||
0.4 │ *
|
||||
│ *
|
||||
│*
|
||||
0.2 ┼───────────────────────────────── Zeit
|
||||
0 1m 3m 6m 1j 2j
|
||||
```
|
||||
|
||||
**Grundsatz:** Jede **Verstärkung** (Zugriff, Bestätigung aus neuer Quelle) **setzt die Kurve** für diesen Fakt **zurück**.
|
||||
|
||||
### Verfallsraten nach Wissenstyp
|
||||
|
||||
| Wissenstyp | Verfallsrate | Begründung |
|
||||
|----------------|------------|-----------|
|
||||
| Architekturentscheidungen | Sehr langsam (1% alle 6 Monate) | Langzeitwirkung, ändern sich selten |
|
||||
| Systemkonfigurationen | Langsam (1% pro Monat) | Stabil, aber kann sich ändern |
|
||||
| Bug-Berichte | Schnell (5% pro Monat) | Vorübergehend, oft behoben |
|
||||
| Notizen aus Meetings | Schnell (5% pro Monat) | Zeitkritischer Kontext |
|
||||
| Forschungsergebnisse | Mittel (2% pro Monat) | Kann veraltet werden |
|
||||
| Best Practices | Sehr langsam (1% alle 3 Monate) | Im Laufe der Zeit bewährt |
|
||||
|
||||
### Implementierung
|
||||
|
||||
**Zu verfolgene Metadaten:**
|
||||
```yaml
|
||||
last_accessed: YYYY-MM-DD
|
||||
last_reinforced: YYYY-MM-DD # Zugriff oder Bestätigung neuer Quelle
|
||||
creation_date: YYYY-MM-DD
|
||||
knowledge_type: [architecture|config|bug|meeting|research|best-practice]
|
||||
current_priority: 0.XX # 0.0-1.0
|
||||
```
|
||||
|
||||
**Verfallsberechnung:**
|
||||
```
|
||||
months_since_reinforcement = (today - last_reinforced).months
|
||||
decay_rate = get_decay_rate(knowledge_type)
|
||||
priority = max(0.2, initial_priority - (months_since_reinforcement * decay_rate))
|
||||
```
|
||||
|
||||
**Verstärkungsauslöser:**
|
||||
- Seite wird aufgerufen/gelesen
|
||||
- Neue Quelle bestätigt die Information
|
||||
- Mensch verstärkt explizit
|
||||
- Verwandte Information wird aufgerufen
|
||||
|
||||
### Integration mit anderen Mechanismen
|
||||
|
||||
**Mit [[Confidence Scoring]]:**
|
||||
- Vergessen beeinträchtigt **Priorität** in der Suche
|
||||
- Vertrauens-Scoring beeinträchtigt **Zuverlässigkeit** des Fakts
|
||||
- Beide funktionieren zusammen: niedrig-vertrauen, niedrig-priorität Fakten erscheinen zuletzt
|
||||
|
||||
**Mit [[Consolidation Tiers]]:**
|
||||
- Höhere Tiers haben **langsamere Verfallsraten**
|
||||
- Prozedurales Gedächtnis (Tier 4) kann **keinen Verfall** haben
|
||||
- Arbeitsgedächtnis (Tier 1) hat **schnellsten Verfall**
|
||||
|
||||
**Mit [[Supersession]]:**
|
||||
- Verdrängte Fakten **verfallen sofort** auf Mindestpriorität
|
||||
- Aber werden **zu historischen Referenzen bewahrt**
|
||||
|
||||
### Suchintegration
|
||||
|
||||
Fakten mit niedrigerer Priorität:
|
||||
- Erscheinen **später** in Suchergebnissen
|
||||
- Werden **mit geringerer Wahrscheinlichkeit** in die Synthese einbezogen
|
||||
- Erfordern **explizitere** Abfragen zum Auftauchen
|
||||
- Können **unterhalb eines bestimmten Schwellenwerts verborgen** sein (konfigurierbar)
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Relevanz:** Benutzer sehen zuerst die wichtigsten Informationen
|
||||
- **Sauberkeit:** Wiki wird nicht mit alten Informationen verstopft
|
||||
- **Erhaltung:** Historische Informationen sind noch zugänglich
|
||||
- **Anpassungsfähigkeit:** Wiki entwickelt sich mit sich ändernden Bedürfnissen
|
||||
- **Effizienz:** Suche und Synthese sind effizienter
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das im Laufe der Zeit wachsen soll
|
||||
- Bereiche mit sich entwickelndem Wissen
|
||||
- Situationen, in denen sich die Relevanz von Informationen ändert
|
||||
- Große Wissensdatenbanken
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Kleine, statische Wikis
|
||||
- Bereiche, in denen alle Informationen gleich wichtig sind
|
||||
- Situationen, in denen historische Vollständigkeit entscheidend ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Memory Lifecycle]] - Übergeordnetes Concept
|
||||
- [[Confidence Scoring]] - Ergänzender Zuverlässigkeitsmechanismus
|
||||
- [[Consolidation Tiers]] - Tier-spezifische Verfallsraten
|
||||
- [[Supersession]] - Umgang mit veralteten Informationen
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (für automatisiertes Verstärkungstracking)
|
||||
- [[Quality and Self-Correction]] (für verwandte Qualitätsmechanismen)
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, Knowledge Graph, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Verfahren, verbundene Entities im Wissensgraphen über typisierte Beziehungen (uses, depends-on, contradicts, caused) zu finden und strukturelle Fragen zu beantworten.
|
||||
---
|
||||
# Graph Traversal
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Ermöglicht Abfragen wie "Was ist die Auswirkung eines Redis-Upgrades?" durch das Durchlaufen von Abhängigkeitskanten und das Auffinden aller betroffenen Komponenten.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,139 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: problem
|
||||
tags: [tests, regression, tooling, quality]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [Command Round-Trip Integrity, wikitool, Denylist over Allowlist, Ambient Environment Dependency, Lint Workflow]
|
||||
sources: [Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Defekt, der eine vollstaendig gruene Testsuite ueberlebt, weil nie ein Test das richtige Verhalten behauptet hat - belegt an drei prio/1-2-Defekten (Round-Trip, Zitat-Notation-als-Code, Zitat-Limit)
|
||||
---
|
||||
# Green Suite Blind Spot
|
||||
|
||||
**Typ:** Problem
|
||||
|
||||
## Definition
|
||||
|
||||
Ein Green Suite Blind Spot ist ein Defekt, der eine vollständig grüne Testsuite überlebt, weil
|
||||
nie ein Test das *richtige* Verhalten behauptet hat. Die Suite ist nicht falsch und sie ist
|
||||
nicht kaputt - sie prüft nur, wovon sie weiß. Ein nie formuliertes Verhalten kann nicht
|
||||
fehlschlagen, also meldet ein grüner Lauf für diesen Bereich nichts, und die Grünfärbung wird
|
||||
als Aussage über den gesamten Code gelesen statt über den abgedeckten Ausschnitt.
|
||||
|
||||
Die Lücke wächst dort am schnellsten, wo zwei Komponenten sich erst in der Kombination
|
||||
widersprechen: jede für sich ist getestet, das Zusammenspiel hat nie jemand aufgeschrieben.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Der Beleg aus diesem Stack (2026-08-31):** zwei `prio/1`-Datenintegritätsdefekte lagen unter
|
||||
einer vollständig grünen Suite. 678 Tests waren grün, bevor die Zitat-Tests zu Gitea-Issue #17
|
||||
geschrieben wurden; 67 Gate-Tests waren grün vor der Zählungsänderung desselben Tages. In
|
||||
keinem der beiden Fälle hatte je ein Test das falsche Verhalten festgehalten - genau deshalb
|
||||
hat es überlebt[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Die Zahl der grünen Tests sagt nichts über den ungetesteten Bereich.** Sie misst, wie viel
|
||||
bekanntes Verhalten abgesichert ist. Ein Defekt in unbekanntem Verhalten ist von einer
|
||||
grünen 678er-Suite genauso wenig ausgeschlossen wie von einer grünen 60er-Suite[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Das ist etwas anderes als eine falsche Zusicherung.** Ein Test, der das falsche Verhalten
|
||||
festschreibt, wird beim Fix rot und zwingt zur Entscheidung. Der blinde Fleck erzeugt gar
|
||||
keinen Widerstand: der Fix ändert Verhalten, das nie jemand behauptet hat, und die Suite
|
||||
bleibt grün - vorher wie nachher[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Gegenmittel 1 - den neuen Test rot beweisen, bevor man ihm glaubt.** Bei der Reparatur von
|
||||
Issue #17 wurde nicht behauptet, der neue Test hätte den Defekt gefangen: die alte
|
||||
Implementierung wurde rekonstruiert und gegen ihn laufen gelassen
|
||||
(`ALTER Code -> Beziehungen erhalten: False`, `NEUER Code -> Beziehungen erhalten:
|
||||
True`)[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Gegenmittel 2 - den Umfang messen statt schätzen.** Der Scan über den Korpus ergab 8 Seiten
|
||||
mit 74 Zeilen in der gefährdeten Position und hielt damit einen laufenden Ingest an, der
|
||||
`cite add` auf genau diese Seiten aufgerufen hätte. Eine Schätzung hätte diese Entscheidung
|
||||
nicht getragen[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Gegenmittel 3 - einen Bericht aus zweiter Hand nachstellen, nicht übernehmen.** Die
|
||||
Meldungen eines Subagenten wurden am Code nachvollzogen, bevor etwas geändert wurde, und die
|
||||
Prüfung erweiterte den Umfang zweimal: um `rename` und den `cite sync`-Verlustpfad beim
|
||||
ersten Defekt, und um die Feststellung, dass `xref remove` das undeklarierte Feld gar nicht
|
||||
erreichen konnte, beim zweiten[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Ein dritter Beleg: `lint` maß Zeilenbreite statt Zitat-Anzahl, und niemand hatte je über die
|
||||
eigene Zitat-Syntax geschrieben.** Gitea-Issue #20 stellte selbst fest: "auch dieser Fall war
|
||||
von keinem Test abgedeckt, weil bisher niemand eine Seite über die Zitat-Notation geschrieben
|
||||
hatte." Das Zitat-Limit (Issue #22) zählte parallel `>`-Zeilen statt Zitate - ein Defekt, den
|
||||
eine einzige Testseite mit einem umbrochenen Zitat sofort zeigt, aber den niemand geschrieben
|
||||
hatte, bis eine reale Seite genau das tat. Beide behoben in
|
||||
`1.7.2`.
|
||||
Gegenmittel 1 griff erneut: acht neue Tests wurden gegen eine auf No-op zurückgesetzte
|
||||
Implementierung scharf geprüft und liefen rot, bevor der Fix als bewiesen
|
||||
galt.
|
||||
- **Eine Ablehnung, die auf ein anderes Kommando verweist, ist selbst ein blinder Fleck.** Die
|
||||
Denylist aus `1.4.0` war richtig, ihr Verweisziel nicht: sie behauptete ungeprüft, `xref add`
|
||||
und `xref remove` deckten die Seiten-Referenz-Felder ab, was für eine Source-Seite falsch war.
|
||||
Die Regel dazu steht bei [[Denylist over Allowlist]][^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Der Befund stützt die Prämisse von Gitea-Issue #8** - dass eine grüne Suite kein Beleg für
|
||||
Vollständigkeit ist und ein Bereich seinen eigenen Nachweis braucht[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31].
|
||||
- **Issue #8 wurde am 2026-08-31 mit `1.7.1` geschlossen, und zwar über eine Isolierung der
|
||||
Testausführung statt über weitere Einzeltests**[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Der dort behandelte Fall ist aber
|
||||
eine eigene Klasse und kein blinder Fleck: dort behauptete ein Test das richtige Verhalten und
|
||||
war grün, weil die Umgebung lieferte, was der Code hätte liefern müssen. Abgrenzung und Beleg
|
||||
bei [[Ambient Environment Dependency]].
|
||||
- **Gegenmittel 1 hat sich dort erneut bewährt.** Vor der Härtung war die Suite unter der
|
||||
gehärteten Umgebung bereits grün (695 Tests), der Schutz also durch keinen roten Lauf belegt.
|
||||
Erst die Gegenprobe - dieselbe Funktion antwortet ohne Isolierung mit dem globalen git-Namen
|
||||
des Entwicklers, mit Isolierung `None` - zeigte, dass er greift[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - Issue #17 (`cite add` löschte Inhalt hinter dem Fußnotenblock) und Issue #18
|
||||
(Referenz-Arrays einer Source-Seite unerreichbar), beide unter grüner Suite entstanden und
|
||||
beide durch einen Ingest, nicht durch einen Testlauf, gefunden
|
||||
- [[Command Round-Trip Integrity]] - die Defektklasse, die besonders anfällig ist, weil jeder
|
||||
beteiligte Aufruf für sich getestet und für sich korrekt ist
|
||||
- [[Lint Workflow]] - Issue #20 (`[^cite-id]`/`[[Wikilink]]` in Backticks oder einem Fence zählte
|
||||
als echte Referenz) und Issue #22 (Zitat-Limit zählte `>`-Zeilen statt Zitate), beide gefunden
|
||||
bei einer Seite, die tatsächlich über die eigene Notation schrieb, nicht durch einen Testlauf
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wenn eine grüne Suite als Argument für die Korrektheit einer Änderung angeführt wird: die
|
||||
Frage ist nicht, wie viele Tests grün sind, sondern welcher Test rot geworden wäre.
|
||||
- Beim Schreiben eines Regressionstests: erst gegen den alten Code laufen lassen. Ein Test, der
|
||||
nie rot war, belegt nichts.
|
||||
- Wenn ein Defekt im Betrieb auffällt statt im Testlauf: die Frage nach dem fehlenden Test
|
||||
gehört zur Ursachenanalyse, nicht zur Nacharbeit.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Als Argument gegen Testabdeckung. Der Befund entwertet keinen einzigen der 678 grünen Tests;
|
||||
er bestreitet nur, dass ihre Zahl eine Aussage über das trifft, was niemand aufgeschrieben
|
||||
hat.
|
||||
- Für Defekte, die ein Test sehr wohl abgedeckt hätte und die durch einen übersprungenen oder
|
||||
nicht ausgeführten Lauf durchgerutscht sind. Das ist ein Prozessfehler, kein blinder Fleck.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Command Round-Trip Integrity]]
|
||||
- [[Denylist over Allowlist]]
|
||||
- [[Ambient Environment Dependency]]
|
||||
- [[Structural Enforcement over Documented Rule]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **begünstigt:** [[Command Round-Trip Integrity]]
|
||||
- **trat auf in:** [[wikitool]]
|
||||
- **belegt an:** [[Denylist over Allowlist]]
|
||||
- **abzugrenzen von:** [[Ambient Environment Dependency]]
|
||||
- **belegt an:** [[Lint Workflow]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[Command Round-Trip Integrity]]
|
||||
- [[wikitool]]
|
||||
- [[Denylist over Allowlist]]
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[Ambient Environment Dependency]]
|
||||
- [[Lint Workflow]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
@@ -0,0 +1,142 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [automation, events, triggers, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Event-Driven Automation, 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
|
||||
|
||||
- [[Event-Driven Automation]] - Das Gesamtautomatisierungs-Framework
|
||||
- [[LLM Wiki Pattern]] - Das übergeordnete Muster
|
||||
- [[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)
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [search, bm25, vector, graph, scalability]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, BM25, Vector Search, Reciprocal Rank Fusion, Knowledge Graph, Graph Traversal]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Multimodale Suche, die BM25-Schlüsselwortabgleich, Vektor-Embeddings und Graph Traversal verbindet, um Wissensabruf im Wiki skalierbar zu machen.
|
||||
---
|
||||
# Hybrid Search
|
||||
|
||||
**Typ:** Architecture (Multi-Modal-Suchsystem)
|
||||
|
||||
## Definition
|
||||
|
||||
Hybrid Search kombiniert **drei komplementäre Suchansätze**, um skalierbare und genaue Wissensbeschaffung in Wikis zu ermöglichen, die ~100-200 Seiten übersteigen. Dies adressiert die Einschränkung des ursprünglichen Musters, das sich ausschließlich auf `index.md` für die Entdeckung verlässt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Der ursprüngliche `index.md`-Katalog funktioniert bis zu ~100-200 Seiten. Darüber hinaus:
|
||||
- Der Index selbst wird zu lang, um vom LLM in einem Durchgang gelesen zu werden
|
||||
- Schlüsselwortabgleich vermisst semantische Ähnlichkeit
|
||||
- Flache Suche kann strukturelle Beziehungen nicht erfassen
|
||||
- Unimodale Suche hat Blindstellen
|
||||
|
||||
### Die Lösung: Drei-Stream-Fusion
|
||||
|
||||
**1. BM25 (Schlüsselwortabgleich)**
|
||||
- Traditionelle Informationsbeschaffung mit Stammformreduktion und Synonymerweiterung
|
||||
- **Stärken:** Findet genaue Begriffe, schnell, gut verstanden
|
||||
- **Schwächen:** Vermisst semantische Ähnlichkeit, erfordert genaue Begriffsabgleiche
|
||||
- **Anwendungsfall:** "Alle Seiten über Docker finden"
|
||||
|
||||
**2. Vector Search (Semantische Ähnlichkeit)**
|
||||
- Nutzt Embeddings, um semantisch ähnliche Inhalte zu finden
|
||||
- **Stärken:** Findet verwandte Konzepte, auch ohne genaue Begriffsabgleiche
|
||||
- **Schwächen:** Kann präzise technische Begriffe verpassen, rechentechnisch teuer
|
||||
- **Anwendungsfall:** "Informationen über Container-Plattformen finden" (passt Docker, Podman, etc.)
|
||||
|
||||
**3. Graph Traversal (Strukturelle Verbindungen)**
|
||||
- Durchläuft den [[Knowledge Graph]] durch typisierte Beziehungen
|
||||
- **Stärken:** Findet strukturelle Verbindungen, die Schlüsselwort- und Vector-Suche verfehlen
|
||||
- **Schwächen:** Erfordert gut gepflegten Graph, findet nur verbundene Entitäten
|
||||
- **Anwendungsfall:** "Was ist die Auswirkung eines Redis-Upgrades?" (findet alle abhängigen Services)
|
||||
|
||||
### Fusion mit Reciprocal Rank Fusion (RRF)
|
||||
|
||||
Anstatt einen Ansatz zu wählen, **alle drei mit RRF fusionieren**:
|
||||
1. Alle drei Suchen parallel ausführen
|
||||
2. Jede gibt eine rangierte Liste von Ergebnissen zurück
|
||||
3. RRF kombiniert die Rankings mit gegenseitigen Rang-Scores
|
||||
4. Ergebnis: Bessere Gesamtrangierung als bei einem einzelnen Ansatz
|
||||
|
||||
**Warum RRF?**
|
||||
- Einfach und effektiv
|
||||
- Keine Notwendigkeit, Gewichte zwischen Modi zu tunen
|
||||
- Robust gegen Unterschiede in der Ergebnisqualität
|
||||
- Funktioniert auch, wenn ein Modus schlecht abschneidet
|
||||
|
||||
## Implementierung
|
||||
|
||||
### Architektur
|
||||
|
||||
```
|
||||
Abfrage: "Wie funktioniert das Auth-System?"
|
||||
│
|
||||
├── BM25-Suche → [Seiten mit "Auth", "Authentication", "Login"]
|
||||
│
|
||||
├── Vector Search → [semantisch mit Authentication verbundene Seiten]
|
||||
│
|
||||
└── Graph Traversal → [Seiten, die mit Auth-Entitäten im Graph verbunden sind]
|
||||
│
|
||||
└── Reciprocal Rank Fusion → Kombinierte, rangierte Ergebnisse
|
||||
```
|
||||
|
||||
### Wann wechseln
|
||||
|
||||
| Wiki-Größe | Primärer Suchmechanismus |
|
||||
|-----------|--------------------------|
|
||||
| < 100 Seiten | `index.md` (manuell) |
|
||||
| 100-200 Seiten | `index.md` + grundlegende Suche |
|
||||
| 200-1000 Seiten | Hybrid-Suche (BM25 + Vector) |
|
||||
| 1000+ Seiten | Hybrid-Suche (BM25 + Vector + Graph) |
|
||||
|
||||
**Empfehlung:** `index.md` als für Menschen lesbaren Katalog auch mit Hybrid-Suche bewahren. Es dient verschiedenen Zwecken:
|
||||
- `index.md`: Menschliche Navigation, Überblick
|
||||
- Hybrid-Suche: LLM-Abfragelösung
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Skalierbarkeit:** Funktioniert von 100 bis 10.000+ Seiten
|
||||
- **Genauigkeit:** Jeder Modus erfasst, was andere vermissen
|
||||
- **Robustheit:** Kein Single Point of Failure
|
||||
- **Flexibilität:** Passt sich verschiedenen Abfragetypen an
|
||||
- **Zukunftssicher:** Kann weitere Modi hinzufügen (z.B. Zeitsuche)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wikis, von denen erwartet wird, dass sie über 200 Seiten hinauswachsen
|
||||
- Bereiche mit vielfältigen Abfragetypen
|
||||
- Situationen, die hohen Recall erfordern
|
||||
- Multi-modale Wissensdatenbanken
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Kleine Wikis (<100 Seiten) - `index.md` ist ausreichend
|
||||
- Einfache, gleichmäßige Inhalte
|
||||
- Situationen, in denen die Implementierungskomplexität nicht gerechtfertigt ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[BM25]] - Schlüsselwortabgleich-Komponente
|
||||
- [[Vector Search]] - Semantische Ähnlichkeits-Komponente
|
||||
- [[Reciprocal Rank Fusion]] - Fusionsalgorithmus
|
||||
- [[Knowledge Graph]] - Graph-Traversal-Komponente
|
||||
- [[Graph Traversal]] - Der Graph-Suchmechanismus
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (für automatisierte Indizierung)
|
||||
- Scalable Search (verwandtes Concept)
|
||||
@@ -0,0 +1,87 @@
|
||||
<!-- Generated by `wikitool index rebuild`. Do not hand-edit. -->
|
||||
|
||||
# kb/concepts/ - Index
|
||||
|
||||
76 page(s). Regenerated by `wikitool index rebuild`.
|
||||
|
||||
## All
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[Ambient Environment Dependency]] | problem | Fehlerklasse, in der ein Test gruen ist, weil die Maschine zufaellig passt statt weil der Code stimmt - abgegrenzt gegen den Green Suite Blind Spot, belegt an vier Faellen unter Gitea-Issue #8 | 2026-08-31 |
|
||||
| [[Anti-Cramming Heuristic]] | workflow | Regel gegen überladene Seiten: ab dem dritten Absatz zu einem Unterthema eine eigene Seite anlegen | 2026-08-29 |
|
||||
| [[Audit Trail]] | pattern | Unveränderliches chronologisches Log aller Wiki-Operationen (Ingest, Bearbeitung, Löschung, Abfrage) mit Zeitstempel, Akteur, Ziel und Änderungsbeschreibung. | 2026-08-29 |
|
||||
| [[BM25]] | pattern | Schlüsselwortbasiertes Retrieval-Verfahren, das über Termfrequenz, inverse Dokumentfrequenz und Stemming exakte oder teilweise Übereinstimmungen findet. | 2026-08-29 |
|
||||
| [[Bulk Operations]] | workflow | Umkehrbare, protokollierte Operationen zum Massenlöschen, Exportieren, Zusammenführen oder Archivieren von Wiki-Inhalten, mit Freigabepflicht und Undo. | 2026-08-29 |
|
||||
| [[Checkpoint Audit]] | workflow | Regelmäßiger Qualitätsrhythmus: Index und Backlinks alle 15 Einträge neu aufbauen, auf 0 neue Artikel prüfen, die 3 meistgeänderten erneut lesen | 2026-08-29 |
|
||||
| [[CI Integration]] | workflow | 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 | 2026-09-01 |
|
||||
| [[Claude Code Auto Mode]] | workflow | 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 | 2026-08-31 |
|
||||
| [[Command Round-Trip Integrity]] | pattern | Anforderung, dass zwei Befehle auf derselben Datei in jeder Reihenfolge zusammenpassen und jeder erzeugte Zustand einen Gegenbefehl hat - 2026-08-31 in wikitool zweimal verletzt | 2026-08-31 |
|
||||
| [[Confidence Scoring]] | pattern | Mechanismus, der faktischen Aussagen quantitative Werte nach Quellenzahl, Aktualität, Qualität und Bestätigung zuweist, um gut gestütztes Wissen zu erkennen. | 2026-08-29 |
|
||||
| [[Consolidation Tiers]] | architecture | Hierarchische Speicherarchitektur, die Informationen durch zunehmend verdichtete Schichten vom Working Memory bis zum Semantic und Procedural Memory befördert. | 2026-08-29 |
|
||||
| [[Content Quality Control]] | workflow | Regeln und Schwellenwerte für die Seitenqualität: Mindestumfang für Stubs, Aufteilungsschwellen und Zielwerte für die Zeilenzahl | 2026-08-29 |
|
||||
| [[Context Isolation]] | architecture | Grundsatz, für jede Aufgabe nur den jeweils benötigten Kontext zu laden | 2026-08-29 |
|
||||
| [[Contradiction Resolution]] | pattern | Automatisches Erkennen und Auflösen widersprüchlicher Aussagen anhand von Konfidenz, Aktualität und Autorität der Quelle. | 2026-08-29 |
|
||||
| [[CPPC]] | protocol | Hardwareschnittstelle Collaborative Processor Performance Control für feingranulares CPU-Power-Management zwischen Betriebssystem und AMD-Prozessor. | 2026-08-29 |
|
||||
| [[Cross-platform Agent Skills]] | architecture | Architektur fuer Agent-Skills, die ueber mehrere LLM-Werkzeuge hinweg funktionieren; in Chemenu selbst am 2026-08-04 umgesetzt und ueberprueft | 2026-09-01 |
|
||||
| [[Crystallization]] | workflow | Verdichten abgeschlossener Erkundungen, Debugging-Sitzungen und Recherchen zu strukturierten Wiki-Auszügen als eigenständige Wissensquellen. | 2026-08-29 |
|
||||
| [[Denylist over Allowlist]] | decision | Entscheidung, schreibbare Felder als Schema minus kurzer Sperrliste zu bestimmen statt als gepflegte Positivliste, weil die Positivliste eine zweite Kopie des Schemas waere | 2026-08-31 |
|
||||
| [[Detect-Repair Asymmetry]] | problem | Werkzeugluecke, in der ein Check einen Defekt zuverlaessig meldet, aber kein Befehl ihn behebt - womit die Handeditierung der einzige verbleibende Ausweg ist | 2026-08-31 |
|
||||
| [[Diff-Reviewable Agent Edits]] | decision | Entscheidung, Dateiaenderungen ueber Edit/Write statt ueber Shell-Heredocs zu fahren, weil nur das erste eine pruefbare Diff hinterlaesst | 2026-08-31 |
|
||||
| [[Entity Extraction]] | pattern | Erkennen und Strukturieren von Entities (Personen, Projekte, Bibliotheken, Concepts, Dateien, Entscheidungen, Systeme, Werkzeuge) samt typspezifischer Attribute aus Rohquellen. | 2026-08-29 |
|
||||
| [[Episodic Memory]] | architecture | Speicherschicht für verdichtete Sitzungszusammenfassungen und Befunde; Brücke zwischen rohem Working Memory und langlebigem Semantic Memory. | 2026-08-29 |
|
||||
| [[Event-Driven Automation]] | workflow | Muster, das automatische Auslöser an Wiki-Lebenszyklusereignisse hängt, um manuellen Pflegeaufwand und das Risiko der Verwahrlosung zu senken. | 2026-08-29 |
|
||||
| [[Filter on Ingest]] | pattern | Automatisches Erkennen und Entfernen sensibler Daten (API-Schlüssel, Token, Credentials, personenbezogene Daten) vor der Aufnahme ins Wiki, per Regex und ML-Erkennung. | 2026-08-29 |
|
||||
| [[Forgetting]] | pattern | Muster zur Wissensbindung, das selten abgerufene Fakten schrittweise zurückstuft, modelliert nach der Ebbinghausschen Vergessenskurve. | 2026-08-29 |
|
||||
| [[Graph Traversal]] | pattern | Verfahren, verbundene Entities im Wissensgraphen über typisierte Beziehungen (uses, depends-on, contradicts, caused) zu finden und strukturelle Fragen zu beantworten. | 2026-08-29 |
|
||||
| [[Green Suite Blind Spot]] | problem | Defekt, der eine vollstaendig gruene Testsuite ueberlebt, weil nie ein Test das richtige Verhalten behauptet hat - belegt an drei prio/1-2-Defekten (Round-Trip, Zitat-Notation-als-Code, Zitat-Limit) | 2026-08-31 |
|
||||
| [[Hooks]] | workflow | Mechanismus von Event-Listenern, der bei Wiki-Lebenszyklusereignissen wie Quellen-Ingest, Seitenänderung und Sitzungsende automatisch Aktionen auslöst. | 2026-08-29 |
|
||||
| [[Hybrid Search]] | architecture | Multimodale Suche, die BM25-Schlüsselwortabgleich, Vektor-Embeddings und Graph Traversal verbindet, um Wissensabruf im Wiki skalierbar zu machen. | 2026-08-29 |
|
||||
| [[Implementation Spectrum]] | architecture | Modularer Einführungspfad für die Funktionen von LLM Wiki v2, vom minimal tragfähigen Wiki bis zur vollen Umsetzung mit Automatisierung und Governance. | 2026-08-29 |
|
||||
| [[Index Scaling]] | workflow | Skalierungsregeln für Indexseiten: Tabellenabschnitte ab 50 Einträgen teilen, ab 200 Seiten _meta/topic-map.md anlegen | 2026-08-29 |
|
||||
| [[Issue Label Scheme]] | decision | Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und size/XS..L, bewusst keine dritte Achse; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf | 2026-08-31 |
|
||||
| [[Iteration and Cost Limits]] | workflow | Im Code durchgesetzte Obergrenze von 60 wikitool-Aufrufen je Session\, Loop-Breaker bei 3 identischen Wiederholungen\, Slot-Erstattung bei abgelehntem Aufruf und ein seit 1.5.0 gemessenes Kalibrierungsband von 5-15 (einfach) bzw. 20-35 (komplex) Aufrufen | 2026-08-31 |
|
||||
| [[KB Migration]] | workflow | Migration des KB-Inhalts entlang einer geordneten Versionskette; abgegrenzt gegen offene Instanz-Aktionen, die in den doctor-Check gehoeren statt in die Kette | 2026-08-31 |
|
||||
| [[KB Stack Versioning]] | decision | Semantische Versionierung des Wiki-Stacks: VERSION beschreibt die Maschinerie, Kompatibilitaet ist die linkeste Nicht-Null-Komponente, und drei getrennte Dateien trennen Maschinerie, Herkunft und Content-Form | 2026-08-30 |
|
||||
| [[Knowledge Compounding]] | workflow | Effekt, bei dem Wissen im Wiki an Wert gewinnt, weil jede neue Quelle an bestehende, untereinander verwiesene Seiten anknüpft und sie ergänzt. | 2026-08-29 |
|
||||
| [[Knowledge Graph]] | architecture | Typisierte Schicht aus Entities und Beziehungen über den Wiki-Seiten, die eine reichere Wissensdarstellung und graphbasierte Abfragen ermöglicht. | 2026-08-29 |
|
||||
| [[Lint Workflow]] | workflow | Deterministischer Health-Check rund um wikitool lint; seit 1.7.2 maskiert es Code vor dem Notation-Match und zaehlt Zitat-Bloecke statt Zeilen | 2026-09-01 |
|
||||
| [[LLM Wiki Pattern]] | architecture | Methodik für persönliches Wissensmanagement, bei der ein LLM aus Rohquellen ein dauerhaftes Wiki aufbaut - Wissen wird kompiliert statt per RAG neu hergeleitet. | 2026-08-29 |
|
||||
| [[Mass-Update Gate]] | workflow | 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> | 2026-09-01 |
|
||||
| [[Memory Lifecycle]] | architecture | Architektur des Wissenslebenszyklus mit Confidence Scoring, Supersession, Forgetting und Consolidation Tiers zur Pflege von Fakten über die Zeit. | 2026-08-29 |
|
||||
| [[Mesh Sync]] | pattern | Abgleichsmechanismus, der Beobachtungen paralleler Agenten in ein gemeinsames Wiki überführt; Last-Write-Wins mit Konflikterkennung und manuellem Eingriff. | 2026-08-29 |
|
||||
| [[Modbus]] | protocol | Industrielles Kommunikationsprotokoll von 1979 zur Anbindung speicherprogrammierbarer Steuerungen und Geräte über serielle oder TCP-Netze. | 2026-08-29 |
|
||||
| [[Multi-Agent Collaboration]] | workflow | Wissensmanagement mit mehreren Agenten; erweitert das LLM-Wiki-Muster um Mesh Sync, die Trennung von geteiltem und privatem Wissen und leichtgewichtige Arbeitskoordination. | 2026-08-29 |
|
||||
| [[Naming Convention Conflict]] | problem | Widerspruch zwischen README.md (kebab-case) und AGENTS.md (lesbar mit Leerzeichen), der zu Drift bei der Validierung führt | 2026-08-29 |
|
||||
| [[OKF Compatibility]] | architecture | Optionale Kompatibilität zum Open Knowledge Framework als Export- und Prüfmodus, ohne das interne Modell zu ersetzen | 2026-08-29 |
|
||||
| [[Optional Instance Context File]] | architecture | Muster fuer eine Datei, die eine Instanz ueber ihre Umgebung informiert, ohne Betriebsvoraussetzung zu sein: Health-Check meldet ohne zu scheitern, pro Checkout statt pro Repo | 2026-08-31 |
|
||||
| [[Personalization Plane]] | architecture | Schicht fuer Instanz-Identitaet: USER.md/SOUL.md werden als Template ausgeliefert, im Setup-Interview woertlich befuellt und vom doctor-Check auf fehlend wie unbefuellt geprueft | 2026-08-31 |
|
||||
| [[Privacy and Governance]] | workflow | Rahmenwerk zur Absicherung von Wiki-Inhalten über Datenfilterung beim Ingest, Audit-Trail-Protokollierung und umkehrbare Massenoperationen. | 2026-08-29 |
|
||||
| [[Procedural Memory]] | architecture | Langlebigste Speicherschicht für Abläufe, Muster, bewährte Vorgehensweisen und Rezepte, gewonnen aus wiederholten semantischen Beobachtungen. | 2026-08-29 |
|
||||
| [[Quality and Self-Correction]] | workflow | Automatische Qualitätssicherung für Wikis mit Inhaltsbewertung, Selbstheilung und Widerspruchserkennung. | 2026-08-29 |
|
||||
| [[Quality Scoring]] | pattern | Quantitative Bewertung aller vom LLM geschriebenen Inhalte nach struktureller Qualität, Vollständigkeit der Quellenangaben, Konsistenz mit dem Wiki und Themenabdeckung. | 2026-08-29 |
|
||||
| [[RAG]] | architecture | Architekturmuster, bei dem LLMs die Generierung um Dokumente aus einer Wissensbasis anreichern. | 2026-08-29 |
|
||||
| [[Reciprocal Rank Fusion]] | pattern | Verfahren, das Ergebnislisten mehrerer Suchmodalitäten zu einem gemeinsamen Ranking verbindet, ohne Gewichte zwischen den Modalitäten justieren zu müssen. | 2026-08-29 |
|
||||
| [[Scale Ceiling]] | architecture | Punkt, ab dem Wiki-Ansätze mit einem einzigen Kontext qualitativ abfallen | 2026-09-01 |
|
||||
| [[Self-Healing]] | pattern | Automatisches Beheben von Mängeln, die beim Lint auffallen: verwaiste Seiten, veraltete Aussagen, kaputte Links und Formatverstöße. | 2026-08-29 |
|
||||
| [[Semantic Lint Automation]] | workflow | Maschinelle Heuristiken zur Priorisierung der semantischen Prüfung: veraltete Aussagen, hohe Änderungsdichte und schwache Verlinkung | 2026-08-29 |
|
||||
| [[Semantic Memory]] | architecture | Langlebige Schicht für sitzungsübergreifend verdichtete Fakten aus mehreren Episoden, mit höherer Konfidenz und stärkerer Verdichtung als episodische Erinnerungen. | 2026-08-29 |
|
||||
| [[Session Orientation]] | workflow | Verbindliche Vorabprüfung, die vor Query- und Update-Operationen einen Kontextbericht erzeugt (Index, jüngste Logs, Umfang) | 2026-08-29 |
|
||||
| [[Shared vs Private]] | pattern | Abgrenzung persönlicher Beobachtungen (privat) von Team- und Projektwissen (geteilt), mit Regeln zum Hochstufen geprüften Wissens. | 2026-08-29 |
|
||||
| [[Split Merge Reclassify]] | workflow | Eigene Befehle zum Teilen, Zusammenführen und Umklassifizieren von Seiten, mit automatischer Korrektur von Links und Frontmatter | 2026-08-29 |
|
||||
| [[Split Threshold]] | workflow | Maximale Seitengröße, ab der eine Aufteilung empfohlen wird (Farza: >120-150 Zeilen, Pascalandy: 200 Zeilen) | 2026-08-29 |
|
||||
| [[SSD TRIM]] | protocol | Datenträgerbefehl, mit dem SSDs ungenutzte Blöcke zurückgewinnen - für gleichbleibende Leistung und längere Lebensdauer. | 2026-08-29 |
|
||||
| [[Structural Enforcement over Documented Rule]] | decision | Entscheidung, eine wiederkehrende Fehlerregel in die Ausfuehrung einzubauen statt sie aufzuschreiben - Rangfolge erzwingen vor melden vor erinnern, belegt an einer Regel, die gelesen wurde und nicht wirkte | 2026-08-31 |
|
||||
| [[Stub Threshold]] | workflow | Mindestumfang, ab dem eine Wiki-Seite nicht mehr als Stub gilt (Farza: ≥3 Sätze oder 15 Zeilen) | 2026-08-29 |
|
||||
| [[Supersession]] | workflow | Ablösen alten Wissens durch neue, widersprechende Information; gibt dem Wiki eine Versionierung mit ausdrücklicher Verknüpfung und Erhalt der Historie. | 2026-08-29 |
|
||||
| [[Three-Layer Architecture]] | architecture | Strukturmodell des LLM-Wiki-Musters mit drei Schichten: unveränderliche Rohquellen, vom LLM gepflegtes Wiki und Schemakonfiguration, die Knowledge Compounding trägt. | 2026-08-29 |
|
||||
| [[Token Economics]] | architecture | Kosten- und Effizienzüberlegungen zum Tokenverbrauch von LLMs - die genannten Werte 5-8x/61%/100% sind unbestätigt, keine gesicherten Fakten | 2026-09-01 |
|
||||
| [[Typed Relationships]] | pattern | Verwendung semantisch aussagekräftiger Beziehungstypen (uses, depends-on, contradicts, caused, fixed, supersedes, replaces) statt undifferenzierter Wikilinks. | 2026-08-29 |
|
||||
| [[User Management]] | workflow | Linux-Ablauf zum Anlegen, Ändern, Überwachen und Löschen von Benutzerkonten mit useradd, usermod und userdel, samt Gruppenverwaltung und sudoers-Konfiguration. | 2026-08-29 |
|
||||
| [[Vector Search]] | pattern | Semantische Ähnlichkeitssuche über Embedding-Vektoren, die inhaltlich verwandte Seiten auch ohne exakte Schlüsselwortübereinstimmung findet. | 2026-08-29 |
|
||||
| [[Work Coordination]] | pattern | Leichtgewichtige Erfassung von Aufgabenstatus (in Arbeit, blockiert, erledigt, prüfbedürftig) und Zuweisung, um Doppelarbeit bei mehreren Agenten zu vermeiden. | 2026-08-29 |
|
||||
| [[Workflow Extraction]] | workflow | Herauslösen von Workflow-Abschnitten aus monolithischer Dokumentation | 2026-09-01 |
|
||||
| [[Workflow Orchestration]] | workflow | Orchestrierte Einzelbefehle für vollständige Operationen (ingest run, lint run, update run) mit Dry-Run-Vorschau vor dem Schreiben | 2026-08-29 |
|
||||
| [[Working Memory]] | architecture | Kurzlebige Speicherschicht für jüngste Beobachtungen und vorläufige Befunde vor der Verdichtung; niedrigste Konfidenz, keine Verdichtung, wird zum Sitzungsende erneuert. | 2026-08-29 |
|
||||
| [[Write-Once Frontmatter Fields]] | problem | Defektklasse, in der ein Feld nur beim Anlegen der Seite schreibbar ist und danach unerreichbar bleibt, weil kein Mutationsbefehl es kennt und new nicht idempotent ist | 2026-08-31 |
|
||||
|
||||
@@ -0,0 +1,239 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [implementation, modular, levels, adoption]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, Knowledge Graph, Event-Driven Automation, Multi-Agent Collaboration, Privacy and Governance, Crystallization]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Modularer Einführungspfad für die Funktionen von LLM Wiki v2, vom minimal tragfähigen Wiki bis zur vollen Umsetzung mit Automatisierung und Governance.
|
||||
---
|
||||
# Implementation Spectrum
|
||||
|
||||
**Typ:** Architecture (Modularer Adoptionspfad)
|
||||
|
||||
## Definition
|
||||
|
||||
Das Implementation Spectrum erkennt an, dass **alle Features des LLM Wiki v2 modular sind** - nicht alles ist am ersten Tag erforderlich. Dies bietet einen **progressiven Adoptionspfad** von minimalem praktikablem Wiki bis zu einem vollständig ausgestatteten Wissensmanagementsystem.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Spektrum
|
||||
|
||||
Alle Features in [[LLM Wiki Pattern]] v2 können schrittweise eingeführt werden:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ VOLLSTÄNDIGE IMPLEMENTIERUNG │
|
||||
│ Memory Lifecycle + Knowledge Graph + Skalierbare Suche + │
|
||||
│ Event-Driven Automation + Qualitätskontrollen + │
|
||||
│ Multi-Agent-Zusammenarbeit + Datenschutz & Governance + │
|
||||
│ Kristallisierung + Implementation Spectrum │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Zusammenarbeit hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ SKALIERUNG HINZUFÜGEN │
|
||||
│ Hybrid Search + Consolidation Tiers + Qualitätsbewertung │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Automatisierung hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ AUTOMATISIERUNG HINZUFÜGEN │
|
||||
│ Hooks für Auto-Ingest, Auto-Lint, Context Injection │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Struktur hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ STRUKTUR HINZUFÜGEN │
|
||||
│ Entity Extraction + Typisierte Beziehungen + Knowledge Graph│
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Lebenszyklus hinzufügen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ LEBENSZYKLUS HINZUFÜGEN │
|
||||
│ Confidence Scoring + Supersession + Grundlegender Verfall │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
↑
|
||||
│ Hier beginnen
|
||||
↓
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ MINIMALES PRAKTIKABLES WIKI │
|
||||
│ Raw-Quellen + Wiki-Seiten + index.md + Schema (AGENTS.md) │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Level-Details
|
||||
|
||||
#### Level 0: Minimales praktikables Wiki
|
||||
**Hier beginnen** - Dies ist ungefähr das, was das ursprüngliche [[LLM Wiki Pattern]] beschreibt.
|
||||
|
||||
**Komponenten:**
|
||||
- `raw/` - Unveränderbare Quelldokumente
|
||||
- `kb/` - Von LLM generierte Markdown-Seiten
|
||||
- `kb/index.md` - Inhaltskatalog
|
||||
- `kb/log.md` - Chronologischer Datensatz
|
||||
- `AGENTS.md` - Schema zur Definition von Workflows
|
||||
|
||||
**Operationen:** Manueller Ingest, Abfrage, Lint
|
||||
|
||||
**Wann nutzen:** Einstieg, kleine Wikis, Mustererlernung
|
||||
|
||||
**Seiten:** ~1-100
|
||||
|
||||
---
|
||||
|
||||
#### Level 1: Lebenszyklus hinzufügen
|
||||
Verhindert, dass das Wiki zu einer Rumpelkammer wird.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Confidence Scoring]] - Jeder Fakt trägt eine Zuverlässigkeitsbewertung
|
||||
- [[Supersession]] - Neue Informationen ersetzen explizit alte
|
||||
- Grundlegendes [[Forgetting]] - Aufbewahrungsverfall für alte Informationen
|
||||
|
||||
**Wann hinzufügen:** Wenn bemerkt wird, dass veraltete Informationen persistieren
|
||||
|
||||
**Seiten:** ~100-500
|
||||
|
||||
---
|
||||
|
||||
#### Level 2: Struktur hinzufügen
|
||||
Verbessert Abfragen und enthüllt Verbindungen, die bei flachen Seiten vermisst würden.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Entity Extraction]] - Strukturierte Entitäten aus Quellen extrahieren
|
||||
- [[Typed Relationships]] - Typisierte Links verwenden (hängt ab von, nutzt, etc.)
|
||||
- [[Knowledge Graph]] - Graph-Ebene für Navigation und Entdeckung
|
||||
|
||||
**Wann hinzufügen:** Wenn Verbindungen über viele Seiten hinweg gefunden werden müssen
|
||||
|
||||
**Seiten:** ~500-2000
|
||||
|
||||
---
|
||||
|
||||
#### Level 3: Automatisierung hinzufügen
|
||||
Wo die Wartungslast auf nahe Null sinkt.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Event-Driven Automation]] - Hooks für Auto-Ingest, Auto-Lint, etc.
|
||||
- [[Hooks]] - Event-Listener für verschiedene Auslöser
|
||||
|
||||
**Wann hinzufügen:** Wenn manuelle Wartung zur Last wird
|
||||
|
||||
**Seiten:** Beliebige Größe
|
||||
|
||||
---
|
||||
|
||||
#### Level 4: Skalierung hinzufügen
|
||||
Was benötigt wird, wenn das Wiki über ein paar hundert Seiten hinauswächst.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Hybrid Search]] - BM25 + Vector + Graph Traversal
|
||||
- [[Consolidation Tiers]] - Gestaffelte Memory-Architektur
|
||||
- [[Quality Scoring]] - Qualitätskennzahlen für alle Inhalte
|
||||
|
||||
**Wann hinzufügen:** Wenn die Suchleistung degradiert oder index.md unhandlich wird
|
||||
|
||||
**Seiten:** ~1000+
|
||||
|
||||
---
|
||||
|
||||
#### Level 5: Zusammenarbeit hinzufügen
|
||||
Für Teams oder Multi-Agent-Setups.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Multi-Agent Collaboration]] - Mesh Sync, gemeinsame/private Gültigkeitsbereiche
|
||||
- [[Mesh Sync]] - Beobachtungen von parallelen Agenten zusammenführen
|
||||
- [[Work Coordination]] - Leichte Aufgabenverfolgung
|
||||
|
||||
**Wann hinzufügen:** Wenn mehrere Agenten oder Personen beitragen
|
||||
|
||||
**Seiten:** Beliebige Größe, mehrere Mitwirkende
|
||||
|
||||
---
|
||||
|
||||
#### Level 6: Governance hinzufügen
|
||||
Für Produktionsumgebungen.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Privacy and Governance]] - Filter beim Ingest, Audit Trail
|
||||
- [[Filter on Ingest]] - Sensible Daten automatisch entfernen
|
||||
- [[Audit Trail]] - Alle Operationen protokollieren
|
||||
- [[Bulk Operations]] - Geprüfte, reversible Massenoperationen
|
||||
|
||||
**Wann hinzufügen:** Bei sensiblen Daten oder Compliance-Anforderungen
|
||||
|
||||
**Seiten:** Beliebige Größe, sensible Daten
|
||||
|
||||
---
|
||||
|
||||
#### Level 7: Kristallisierung hinzufügen
|
||||
Maximale Wissensverflechtung.
|
||||
|
||||
**Hinzufügen:**
|
||||
- [[Crystallization]] - Erkundungen in strukturiertes Wissen destillieren
|
||||
|
||||
**Wann hinzufügen:** Wenn maximale Rendite aus Forschungs-/Debug-Sitzungen gewünscht wird
|
||||
|
||||
**Seiten:** Beliebige Größe, forschungsintensiv
|
||||
|
||||
## Anleitung zur Einführung
|
||||
|
||||
### Den Eintrittspunkt wählen
|
||||
|
||||
Die Startebene basierend auf den Anforderungen wählen:
|
||||
|
||||
| Bedarf | Start bei | Dann hinzufügen |
|
||||
|------|----------|----------|
|
||||
| Persönliches Wissensmanagement | Level 0 | Level 1, dann je nach Bedarf |
|
||||
| Team-Dokumentation | Level 0 oder 1 | Level 5, dann Level 6 |
|
||||
| Forschungsprojekt | Level 0 | Level 2, dann Level 7 |
|
||||
| Produktions-Wissensdatenbank | Level 1 | Level 3, dann Level 6 |
|
||||
| Großes Wiki | Level 3 | Level 4, dann andere |
|
||||
|
||||
### Migrationspfad
|
||||
|
||||
Sie können jederzeit zwischen Ebenen migrieren. Jede Ebene **baut auf** der vorherigen auf:
|
||||
|
||||
```
|
||||
Level 0 → Level 1 → Level 2 → Level 3 → Level 4 → Level 5 → Level 6 → Level 7
|
||||
```
|
||||
|
||||
**Hinweis:** Level 2, 4 und 5 haben externe Abhängigkeiten (Graphdatenbank, Vektorsuche, etc.), die möglicherweise zusätzliche Infrastruktur erfordern.
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Niedrige Eintrittsbarriere:** Einfach beginnen, bei Bedarf Komplexität hinzufügen
|
||||
- **Flexibilität:** Nur die Features wählen, die erforderlich sind
|
||||
- **Skalierbarkeit:** Jede Ebene verarbeitet mehr Skala als die vorherige
|
||||
- **Zukunftssicher:** Features können schrittweise hinzugefügt werden
|
||||
- **Kostengünstig:** Nicht für Komplexität zahlen, die nicht erforderlich ist
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- **Immer:** Auf Level 0 oder 1 starten
|
||||
- **Je nach Bedarf:** Ebenen hinzufügen, wenn auf Grenzen gestoßen wird
|
||||
- **Nie:** Nicht alle Ebenen auf einmal implementieren (zu viel Komplexität)
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Memory Lifecycle]] - Level-1-Erweiterung
|
||||
- [[Knowledge Graph]] - Level-2-Erweiterung
|
||||
- [[Event-Driven Automation]] - Level-3-Erweiterung
|
||||
- [[Hybrid Search]] - Level-4-Erweiterung
|
||||
- [[Multi-Agent Collaboration]] - Level-5-Erweiterung
|
||||
- [[Privacy and Governance]] - Level-6-Erweiterung
|
||||
- [[Crystallization]] - Level-7-Erweiterung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Three-Layer Architecture]] (Grundlage für alle Ebenen)
|
||||
- [[Agent Memory]] (Implementierung höherer Ebenen)
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [index, scaling, thresholds, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Content Quality Control, Split Threshold, pascalandy schema, 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
|
||||
|
||||
- [[Content Quality Control]] - Umfassenderes Qualitätssystem
|
||||
- [[Split Threshold]] - Ähnliches Konzept für einzelne Seiten
|
||||
- [[pascalandy schema]] - Quelle der Skalierungsempfehlungen
|
||||
- [[Three-Layer Architecture]] - Index ist Teil der Wiki-Ebene
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **geschützt durch:** [[Iteration and Cost Limits]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
@@ -0,0 +1,126 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: decision
|
||||
tags: [issues, gitea, triage, labels, backlog]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [Chemenu, Gitea MCP Server, KB Stack Versioning, Detect-Repair Asymmetry]
|
||||
sources: [Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: 'Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und size/XS..L, bewusst keine dritte Achse; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf'
|
||||
---
|
||||
# Issue Label Scheme
|
||||
|
||||
**Typ:** Decision
|
||||
|
||||
## Definition
|
||||
|
||||
Issue Label Scheme ist die Entscheidung, offene Arbeit an diesem Stack ausschließlich als
|
||||
Gitea-Issues zu führen und jedes Issue mit genau zwei Pflicht-Labels zu versehen: einer
|
||||
Priorität `prio/1..3` und einer Größe `size/XS..L`. Eine dritte Achse gibt es bewusst nicht.
|
||||
Getroffen wurde die Entscheidung am 2026-08-31, gemeinsam mit der Löschung von `TODO.md`[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
| Priorität | Bedeutung |
|
||||
|---|---|
|
||||
| `prio/1` | Blockiert oder beschädigt laufende Arbeit. Als Nächstes. |
|
||||
| `prio/2` | Sammelt Zinsen. Eingeplant. |
|
||||
| `prio/3` | Lohnend, wartet auf einen benannten Auslöser. |
|
||||
|
||||
| Größe | Bedeutung |
|
||||
|---|---|
|
||||
| `size/XS` | Minuten. Oft nur eine Entscheidung oder eine Beobachtung. |
|
||||
| `size/S` | Eine Sitzung, ein Publish, ein klarer Schnitt. |
|
||||
| `size/M` | Mehrere Dateien; eine Contract- oder Instruction-Änderung; eigener Testaufwand. |
|
||||
| `size/L` | Mehrere Sitzungen, oder offene Entwurfsfragen vor dem ersten Commit. |
|
||||
|
||||
Die sieben Labels wurden angelegt und auf alle zehn zu dem Zeitpunkt offenen Issues
|
||||
angewandt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Beide Achsen sind Pflicht, weil eine Priorität ohne Kosten eine halbe Entscheidung ist.**
|
||||
Größe ist Aufwand und nicht Wichtigkeit, deshalb ist `prio/1 size/XS` das Beste, was auf
|
||||
einem Board stehen kann, und `prio/3 size/L` etwas, worüber gesprochen wird, bevor jemand
|
||||
anfängt.
|
||||
- **`prio/3` ist kein Friedhof.** Der Auslöser muss im Issue benannt sein, sonst ist das Label
|
||||
ein höfliches Nein[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
- **Keine dritte Achse.** Art, Bereich oder Status wurden verworfen als der Punkt, ab dem eine
|
||||
Taxonomie eigene Pflege braucht. Das Board hat einen einzigen Betreuer.
|
||||
- **Priorisiert wird nach Schaden, nicht nach Aufwand.** Das Kriterium der ersten Triage
|
||||
lautete: was blockiert oder beschädigt laufende Arbeit. Ein Werkzeugfehler, der seinen
|
||||
Benutzer gegen eine Invariante des Stacks drückt, rangiert deshalb vor einer fehlenden
|
||||
Fähigkeit, so gut das Issue dazu auch geschrieben ist.
|
||||
- **Ein Issue ohne Abnahmekriterium ist kein Arbeitspaket.** Beim Portieren der
|
||||
Recherche-Notiz nach Issue #15 wurden Abnahmekriterien ergänzt, weil die Prosa-Notiz keine
|
||||
hatte[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
- **`TODO.md` wurde gelöscht statt gepflegt.** Ihr erster Abschnitt war ohnehin nur noch eine
|
||||
Linkliste auf Issues; der zweite, die Recherche-Notiz, ging vollständig nach #15. Danach gab
|
||||
es nichts mehr in der Datei, was nicht auf Gitea stand.
|
||||
|
||||
## Wo die Regel liegt
|
||||
|
||||
Die Platzierung war die tragende Entscheidung, nicht das Schema selbst. `README.md` und
|
||||
`AGENTS.md` gehen in jede über `wikitool dist export` ausgelieferte Instanz, und eine solche
|
||||
Instanz hat kein Issue-Board auf `gitea.nehmer.net`. Eine dort mitgelieferte Label-Regel wäre
|
||||
eine Anweisung ins Leere.
|
||||
|
||||
`instructions/dev/` ist der einzige Ort, der beides ist: von Agenten lesbar und nie
|
||||
ausgeliefert, weil `dist export` das Verzeichnis vollständig ausschließt. Das Schema steht
|
||||
deshalb in `instructions/dev/issue-tracking.md` und ist aus Schritt 2 des `stack-dev`-Skills
|
||||
verlinkt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
Aus demselben Grund war der Release ein PATCH (`1.2.1`) und kein MINOR: für eine bestehende
|
||||
Instanz ändert sich nichts. Das CI-Versions-Gate verlangte den Bump trotzdem, weil sein Muster
|
||||
auf `instructions/` passt und `instructions/dev/` darunter liegt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]. Siehe
|
||||
[[KB Stack Versioning]].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[Chemenu]] - das Repository, dessen Board nach dem Schema geführt wird; sieben Labels
|
||||
wurden angelegt und auf alle zehn offenen Issues angewandt
|
||||
- [[Gitea MCP Server]] - der Weg, auf dem Issues und Labels gelesen und geschrieben werden, da
|
||||
das Origin-Repository privat ist
|
||||
- [[Detect-Repair Asymmetry]] - Issue #14 ist der Fall, den dieses Concept beschreibt, und
|
||||
trägt `prio/2 size/S`
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Auf einem Board mit einem einzigen Betreuer, das eine erkennbare Reihenfolge braucht, aber
|
||||
keinen Prozess.
|
||||
- Sobald offene Arbeit sonst in Prosa-Dateien wandert, die niemand als Board liest und die
|
||||
gegen den Tracker driften.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Nicht auf einem Board mit mehreren Teams, wo Zuständigkeit und Bereich echte Information
|
||||
tragen. Dann ist die dritte Achse keine Taxonomie-Pflege, sondern Routing.
|
||||
- Nicht als Ersatz für die Abnahmekriterien im Issue-Text. Die Labels ordnen ein Issue ein; ob
|
||||
es fertig ist, sagen sie nicht.
|
||||
- Nicht in einer ausgelieferten Instanz. Das Schema beschreibt das Entwicklungs-Repository und
|
||||
hat außerhalb davon keinen Gegenstand.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Stack Versioning]]
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **gilt für:** [[Chemenu]]
|
||||
- **umgesetzt über:** [[Gitea MCP Server]]
|
||||
- **verwandt mit:** [[KB Stack Versioning]]
|
||||
- **verwandt mit:** [[Detect-Repair Asymmetry]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Chemenu]]
|
||||
- [[Gitea MCP Server]]
|
||||
- [[KB Stack Versioning]]
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [gate, safety, iteration-budget, loop-breaker]
|
||||
created: 2026-08-07
|
||||
modified: 2026-08-31
|
||||
related: [Mass-Update Gate, Anti-Cramming Heuristic, Index Scaling, wikitool, Structural Enforcement over Documented Rule]
|
||||
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]
|
||||
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 bei abgelehntem Aufruf und ein seit 1.5.0 gemessenes Kalibrierungsband von 5-15 (einfach) bzw. 20-35 (komplex) Aufrufen
|
||||
---
|
||||
# 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.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Mass-Update Gate]] - das verwandte Sicherheitsgate, das dieses Muster spiegelt, begrenzt auf Veröffentlichungsgröße statt Sitzungsiterationsvolumen
|
||||
- [[Anti-Cramming Heuristic]] - eines der Wiki-Qualitätsprobleme, die ein unbegrenzter Ingest-Lauf sonst verletzen könnte
|
||||
- [[Index Scaling]] - das andere Wiki-Qualitätsproblem, das durch unkontrolliertes Seitenwachstum gefährdet ist
|
||||
- [[wikitool]] - die CLI, die dieses Gate implementiert
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **spiegelt das gleiche Muster wie:** [[Mass-Update Gate]]
|
||||
- **schützt:** [[Anti-Cramming Heuristic]]
|
||||
- **schützt:** [[Index Scaling]]
|
||||
- **implementiert durch:** [[wikitool]]
|
||||
- **wendet an:** [[Structural Enforcement over Documented Rule]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Mass-Update Gate]]
|
||||
- [[Anti-Cramming Heuristic]]
|
||||
- [[Index Scaling]]
|
||||
- [[wikitool]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
- [[Structural Enforcement over Documented Rule]]
|
||||
|
||||
## 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]]
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [migration, versioning, corpus-diff, workflow]
|
||||
created: 2026-08-30
|
||||
modified: 2026-08-31
|
||||
related: [wikitool]
|
||||
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.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Stack Versioning]]
|
||||
- [[Mass-Update Gate]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
|
||||
@@ -0,0 +1,111 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: decision
|
||||
tags: [versioning, semver, release, stack]
|
||||
created: 2026-08-30
|
||||
modified: 2026-08-30
|
||||
related: [wikitool, Issue Label Scheme]
|
||||
sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: 'Semantische Versionierung des Wiki-Stacks: VERSION beschreibt die Maschinerie, Kompatibilitaet ist die linkeste Nicht-Null-Komponente, und drei getrennte Dateien trennen Maschinerie, Herkunft und Content-Form'
|
||||
---
|
||||
# KB Stack Versioning
|
||||
|
||||
**Typ:** Decision
|
||||
|
||||
## Definition
|
||||
|
||||
KB Stack Versioning ist die Entscheidung, den Wiki-**Stack** semantisch zu versionieren und
|
||||
diese Version strikt von der Form des Inhalts zu trennen. Die Stack-Version steht in der
|
||||
Wurzeldatei `VERSION` und wird ausschließlich von `wikitool version bump`
|
||||
geschrieben[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Sie
|
||||
beantwortet genau eine Frage: welche Maschinerie installiert ist.
|
||||
|
||||
Ein automatischer Bump aus Commit-Nachrichten wurde verworfen. `wikitool publish --message
|
||||
"ingest: ..."` schreibt Content-Commits in dasselbe Repository, sodass eine
|
||||
Conventional-Commit-Auswertung jeden Ingest zu einem Release
|
||||
machte[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Der Bump ist
|
||||
deshalb eine ausdrückliche Handlung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Drei Fakten, drei Dateien.** `VERSION` trägt die Stack-Version und wird von `version bump`
|
||||
geschrieben; `.wikitool-release.json` ist der Release-Stempel, den `dist export` in jeden
|
||||
Export legt und der beantwortet, woher die Maschinerie stammt; `.wikitool-kb.json` trägt die
|
||||
KB-Version und wird von `migrate done`
|
||||
geschrieben[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Die
|
||||
Trennung ist keine Aufteilung aus Bequemlichkeit: Der Stempel ist erzeugt und darf nie von
|
||||
Hand geändert werden, der KB-Zustand dagegen ist veränderlicher Instanzzustand.
|
||||
- **Kompatibilität ist die linkeste Nicht-Null-Komponente** - dieselbe Regel, die Cargos
|
||||
Caret-Ranges
|
||||
verwenden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Sie gilt
|
||||
einheitlich für `0.x` und `1.x`, sodass unter `0.x` der Schritt `0.1.x` -> `0.2.0` dasselbe
|
||||
Migrationssignal trägt wie `MAJOR` ab `1.0.0`. Der Code für den `compat_key` ist deshalb
|
||||
einheitlich formuliert und musste beim Wechsel auf `1.0.0` nicht angefasst
|
||||
werden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **`x.y.z` ist die maximale Granularität. Keine Pre-Release-Suffixe.** Eine zweite
|
||||
Ordnungsregel müsste vom Release-Feed, von der Migrationskette und von der
|
||||
Kompatibilitätsprüfung gleichermaßen befolgt
|
||||
werden[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Der Einstieg bei `1.0.0` statt `0.1.0`** beseitigte einen Selbstwiderspruch: Die Anleitung
|
||||
in `stack-dev/SKILL.md` wies `--minor` sowohl „neue Fähigkeit" als auch „erfordert Migration"
|
||||
zu, was unter `0.x` nicht beides zugleich stimmen
|
||||
kann[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Aktualisierungserkennung über einen Stempel, nicht über eine Prüfsumme.**
|
||||
`wikitool version check` darf als einziger Befehl einen Netzaufruf machen: eigener Befehl,
|
||||
kein Schlüssel, Timeout, injizierbarer Fetch, damit Tests nie ein Netz
|
||||
berühren[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Der
|
||||
Aktualisierungspfad selbst (`dist upgrade`) wurde bewusst zurückgestellt: erst Erkennung, dann
|
||||
Ausführung.
|
||||
- **CI wird nicht mitgeliefert.** `runs-on: linux-docker` ist ein standortspezifisches
|
||||
Runner-Label und gehört nicht in eine verteilte
|
||||
Instanz[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
- **Die Grenze wird an zwei Stellen erzwungen:** in `version bump` und in `docs verify`, ergänzt
|
||||
um einen `kb-version`-Check in
|
||||
`doctor`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[Chemenu]] - erste Instanz; `1.0.0` ist die Migrationsbasis, `1.0.1` das erste über
|
||||
die Pipeline veröffentlichte Release.
|
||||
- [[wikitool]] - trägt die Befehlsgruppen `version` und `migrate`, die die drei Dateien
|
||||
schreiben und lesen.
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Sobald eine Wissensbasis als installierbares Artefakt an mehr als eine Stelle geht und
|
||||
Aktualisierungen erkennbar sein müssen. Die Trennung von Stack- und Content-Version lohnt sich
|
||||
ab dem Moment, in dem eine Instanz existiert, deren Inhalt hinter der Maschinerie zurückbleiben
|
||||
kann.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Nicht für den Inhalt. Eine Version, die Stack und Content zugleich beschreibt, macht den
|
||||
Zustand „Maschinerie `1.4.0`, Inhalt in `1.2.0`-Form" unabbildbar - und das ist der Zustand,
|
||||
den jedes Upgrade
|
||||
durchläuft[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Dafür
|
||||
ist [[KB Migration]] zuständig.
|
||||
- Nicht als automatischer Bump aus Commit-Nachrichten, solange Content-Commits und
|
||||
Stack-Commits im selben Repository liegen.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Migration]]
|
||||
- [[CI Integration]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **umgesetzt von:** [[wikitool]]
|
||||
- **verwandt mit:** [[Issue Label Scheme]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[Issue Label Scheme]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [knowledge-management, growth, learning]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memex, 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
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Memex]]
|
||||
- [[Tolkien Gateway]]
|
||||
- [[Three-Layer Architecture]]
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [graph, entities, relationships, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, Entity Extraction, Typed Relationships, Graph Traversal]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Typisierte Schicht aus Entities und Beziehungen über den Wiki-Seiten, die eine reichere Wissensdarstellung und graphbasierte Abfragen ermöglicht.
|
||||
---
|
||||
# Knowledge Graph
|
||||
|
||||
**Typ:** Architektur (Strukturierte Wissensrepräsentation)
|
||||
|
||||
## Definition
|
||||
|
||||
Ein Knowledge Graph ist eine **typisierte, strukturierte Ebene** über Wiki-Seiten, die Entities und ihre Beziehungen darstellt. Während das ursprüngliche LLM Wiki Seiten mit Wikilinks verwendet (was funktioniert), erfasst das Hinzufügen einer Knowledge-Graph-Ebene eine reichere Struktur, die bessere Abfrage und Entdeckung ermöglicht.
|
||||
|
||||
Dieses Konzept wird in [[LLM Wiki Pattern]] v2 als Verbesserung der ursprünglichen flachen Seitenstruktur eingeführt.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Was das Original richtig macht
|
||||
|
||||
Seiten mit Wikilinks sind:
|
||||
- Menschenlesbar
|
||||
- Einfach zu erstellen und zu pflegen
|
||||
- Gut für Narrativ-Informationen
|
||||
- Funktionieren gut für kleine bis mittlere Wikis
|
||||
|
||||
### Was fehlt
|
||||
|
||||
Wikilinks allein erfassen nicht:
|
||||
- **Entity-Typen** (person, project, concept usw.)
|
||||
- **Beziehungstypen** (uses, depends on, contradicts usw.)
|
||||
- **Beziehungssemantik** (Richtung, Stärke, Vertrauen)
|
||||
- **Strukturelle Verbindungen**, die Keyword-Suche vermisst
|
||||
|
||||
### Die Knowledge-Graph-Lösung
|
||||
|
||||
Der Graph **ergänzt** (ersetzt nicht) Wiki-Seiten durch:
|
||||
|
||||
**1. Entity Extraction**
|
||||
Bei der Aufnahme einer Quelle strukturierte Entities extrahieren:
|
||||
- **Typen:** People, projects, libraries, concepts, files, decisions, systems, tools, technologies
|
||||
- **Attribute:** Für jede Entity typspezifische Metadaten speichern
|
||||
- **Beispiele:** "React" (type: library), "Auth migration" (type: project), "Sarah" (type: person)
|
||||
|
||||
**2. Typed Relationships**
|
||||
Nicht alle Verbindungen sind gleich. Typisierte Beziehungen mit semantischem Gewicht verwenden:
|
||||
|
||||
| Beziehung | Gewicht | Beschreibung |
|
||||
|--------------|--------|-------------|
|
||||
| depends on | Hoch | Funktionale Abhängigkeit |
|
||||
| uses | Mittel | Tool/Library-Nutzung |
|
||||
| implements | Hoch | Schnittstellen-/Spec-Implementierung |
|
||||
| extends | Mittel | Vererbung/Erweiterung |
|
||||
| replaces | Mittel | Austauschbeziehung |
|
||||
| conflicts with | Hoch | Inkompatibilität |
|
||||
| requires | Hoch | Voraussetzung |
|
||||
| produces | Mittel | Ausgabe/Artefakt |
|
||||
| consumes | Mittel | Eingabe/Ressource |
|
||||
| owns | Mittel | Verantwortung |
|
||||
| maintains | Mittel | Wartungsverantwortung |
|
||||
| causes | Hoch | Kausalität |
|
||||
| fixed | Hoch | Behebung |
|
||||
| supersedes | Hoch | Versionskontrolle für Wissen |
|
||||
| contradicts | Hoch | Gegensätzliche Aussagen |
|
||||
| relates to | Niedrig | Allgemeine Beziehung |
|
||||
|
||||
**3. Graph-Traversal für Abfragen**
|
||||
Statt nur Keyword-Suche kann das LLM:
|
||||
- Bei einem Entity-Knoten beginnen (z. B. Redis)
|
||||
- Durch Beziehungskanten nach außen gehen
|
||||
- Alles Nachgelagerte finden (z. B. alle Services, die von Redis abhängen)
|
||||
- Verbindungen erfassen, die Keyword-Suche vermisst
|
||||
|
||||
**Beispiel-Abfrage:** „Wie wirkt sich ein Redis-Upgrade aus?"
|
||||
- Bei Redis-Knoten beginnen
|
||||
- „depends on"-Kanten nach außen folgen
|
||||
- Finde: Service A, Service B, Service C
|
||||
- „uses"-Kanten von diesen Services folgen
|
||||
- Finde: Deployment X, Deployment Y
|
||||
- Ergebnis: Vollständige Auswirkungsanalyse
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]] und [[iii Engine]]:
|
||||
|
||||
1. **Entities extrahieren** bei Quellaufnahme
|
||||
2. **Im Graph-Datenbank** oder strukturiertem Format speichern
|
||||
3. **Bidirektionale Links pflegen** zwischen Graph-Knoten und Wiki-Seiten
|
||||
4. **Graph-Traversal aktivieren** für komplexe Abfragen
|
||||
5. **Graph visualisieren** für menschliches Verständnis
|
||||
|
||||
## Graph vs. Seiten
|
||||
|
||||
| Aspekt | Seiten | Graph |
|
||||
|--------|-------|-------|
|
||||
| Zweck | Lesen, Narration | Navigation, Entdeckung |
|
||||
| Stärke | Menschenlesbar, reichhaltiger Kontext | Maschinenlesbar, präzise Beziehungen |
|
||||
| Anwendungsfall | Ein Thema verstehen | Verbindungen finden, Auswirkungsanalyse |
|
||||
| Wartung | LLM schreibt Prosa | LLM extrahiert Struktur |
|
||||
|
||||
**Best Practice:** Beide verwenden. Seiten zum Lesen, Graph zur Navigation und Entdeckung.
|
||||
|
||||
## Vorteile
|
||||
|
||||
- **Bessere Abfragen:** Verbindungen finden, die Keyword-Suche vermisst
|
||||
- **Auswirkungsanalyse:** Abhängigkeiten und Beziehungen nachverfolgen
|
||||
- **Entdeckung:** Verwandte Entities automatisch anzeigen
|
||||
- **Präzision:** Typisierte Beziehungen sind aussagekräftiger als untypierte Links
|
||||
- **Skalierbarkeit:** Graph-Struktur ermöglicht effizientes Traversal
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Wikis mit >100 Seiten (wo Keyword-Suche zu fehlschlagen beginnt)
|
||||
- Domänen mit komplexen Beziehungen (Softwaresysteme, Organisationen)
|
||||
- Situationen, die Auswirkungsanalyse oder Abhängigkeitsverfolgung erfordern
|
||||
- Multi-Hop-Abfragen (finde X, das sich auf Y bezieht, das sich auf Z bezieht)
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Kleine Wikis (<100 Seiten) - Wikilinks könnten ausreichend sein
|
||||
- Einfache, lineare Wissensbereiche
|
||||
- Situationen, in denen der Overhead nicht gerechtfertigt ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtes Muster
|
||||
- [[Entity Extraction]] - Füllung des Graphen
|
||||
- [[Typed Relationships]] - Die Beziehungstypen
|
||||
- [[Graph Traversal]] - Abfragemechanismus
|
||||
- [[Memory Lifecycle]] - Komplementäres Wissensmanagement
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Hybrid Search]] (nutzt Graph-Traversal als einen Stream)
|
||||
- [[Event-Driven Automation]] (für automatische Graph-Updates)
|
||||
- [[Supersession]] (als Graph-Beziehung verfolgt)
|
||||
@@ -0,0 +1,239 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [knowledge-management, llm, wiki, pattern]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Three-Layer Architecture, Knowledge Compounding, RAG, Memex, Vannevar Bush, Memory Lifecycle]
|
||||
sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Methodik für persönliches Wissensmanagement, bei der ein LLM aus Rohquellen ein dauerhaftes Wiki aufbaut - Wissen wird kompiliert statt per RAG neu hergeleitet.
|
||||
---
|
||||
# LLM Wiki Pattern
|
||||
|
||||
**Typ:** Architektur (Muster für Personal Knowledge Management)
|
||||
|
||||
## Definition
|
||||
|
||||
Das LLM Wiki Pattern ist eine Methodik zum Aufbau persönlicher Wissensdatenbanken, bei der ein Large Language Model (LLM) schrittweise einen persistenten, strukturierten Wiki aus Raw-Source-Dokumenten aufbaut und verwaltet. Im Gegensatz zu traditionellen RAG-Systemen (Retrieval Augmented Generation), die Wissen bei jeder Abfrage von Grund auf neu ableiten, kompiliert das LLM Wiki Pattern Wissen einmal und hält es aktuell.
|
||||
|
||||
**Dieses Wiki selbst implementiert das LLM Wiki Pattern.**
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Kernproblem
|
||||
Traditionelle RAG-Ansätze (exemplifiziert durch [[NotebookLM]], [[ChatGPT]] Datei-Uploads) leiden unter:
|
||||
- Wissen wird bei jeder Abfrage von Grund auf neu entdeckt
|
||||
- Keine Ansammlung von synthetisiertem Verständnis
|
||||
- Subtile Fragen, die Synthese mehrerer Dokumente erfordern, müssen jedes Mal neu abgeleitet werden
|
||||
- Keine persistenten Cross-References oder Widerspruchsmarkierung
|
||||
- Kein Akkumulationseffekt durch das Hinzufügen neuer Quellen
|
||||
|
||||
### Die Lösung
|
||||
Das LLM Wiki Pattern führt eine **persistente Wiki-Ebene** zwischen dem Benutzer und den Rohdatenquellen ein:
|
||||
- Wissen wird einmal aus jeder Quelle kompiliert
|
||||
- Das Wiki wird durch Updates aktuell gehalten, wenn neue Quellen ankommen
|
||||
- Cross-References werden automatisch verwaltet
|
||||
- Widersprüche werden bei Erkennung markiert
|
||||
- Wissen sammelt sich an, wenn mehr Quellen hinzugefügt werden
|
||||
|
||||
### Wichtige Einsicht
|
||||
> "Das Wiki ist ein persistentes, akkumulierendes Artefakt. Die Cross-References sind bereits vorhanden. Die Widersprüche wurden bereits markiert. Die Synthese spiegelt bereits alles wider, was Sie gelesen haben. Das Wiki wird mit jeder hinzugefügten Quelle und jeder gestellten Frage reicher."
|
||||
|
||||
## V2-Erweiterungen
|
||||
|
||||
Das ursprüngliche Muster wurde in **LLM Wiki v2** (von [[Rohit Gupta]], aufgebaut auf [[Andrej Karpathy]]s Original) mit Produktionslektionen aus [[Agent Memory]] erweitert. Diese Ergänzungen behandeln, was in der Skalierung bricht und was ein Wiki unterscheidet, das nützlich bleibt, von einem, das verfällt.
|
||||
|
||||
### Kernverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Memory Lifecycle** | Wissen hat einen Lebenszyklus - er muss verwaltet werden | [[Memory Lifecycle]] |
|
||||
| **Confidence Scoring** | Jede Tatsache trägt eine Zuverlässigkeitsbewertung | [[Confidence Scoring]] |
|
||||
| **Supersession** | Neue Informationen ersetzen explizit alte (Versionskontrolle für Wissen) | [[Supersession]] |
|
||||
| **Forgetting** | Alte, irrelevante Informationen verblassen (nicht gelöscht) | [[Forgetting]] |
|
||||
| **Consolidation Tiers** | Informationen fördern durch Tiers, wenn Beweise ansammeln | [[Consolidation Tiers]] |
|
||||
|
||||
### Strukturverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Knowledge Graph** | Typisierte Entities und Beziehungen auf Seiten | [[Knowledge Graph]] |
|
||||
| **Entity Extraction** | Strukturierte Entities aus Quellen extrahieren | Teil von [[Knowledge Graph]] |
|
||||
| **Typed Relationships** | Nicht alle Links sind gleich (depends on, uses, contradicts usw.) | [[Knowledge Graph]] |
|
||||
| **Graph Traversal** | Durch den Graphen gehen für komplexe Abfragen | [[Graph Traversal]] |
|
||||
|
||||
### Skalierungsverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Hybrid Search** | BM25, Vektorsuche und Graph-Traversal kombinieren | [[Hybrid Search]] |
|
||||
| **BM25** | Keyword-Matching mit Stemming | [[BM25]] |
|
||||
| **Vector Search** | Semantische Ähnlichkeit durch Einbettungen | [[Vector Search]] |
|
||||
| **Reciprocal Rank Fusion** | Sucherergebnisse aus mehreren Modalitäten zusammenführen | [[Reciprocal Rank Fusion]] |
|
||||
|
||||
### Automatisierungsverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Event-Driven Automation** | Hooks für Auto-Ingest, Auto-Lint usw. | [[Event-Driven Automation]] |
|
||||
| **Hooks** | Event-Listener, die Aktionen auslösen | [[Hooks]] |
|
||||
|
||||
### Qualitätsverbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Quality Scoring** | Score aller von LLM geschriebenen Inhalte | [[Quality and Self-Correction]] |
|
||||
| **Self-Healing** | Automatisch beheben, was Lint kann | [[Quality and Self-Correction]] |
|
||||
| **Contradiction Resolution** | Automatisch Widersprüche beheben | [[Quality and Self-Correction]] |
|
||||
|
||||
### Zusammenarbeit-Verbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Multi-Agent Collaboration** | Mehrere Agenten tragen zum gleichen Wiki bei | [[Multi-Agent Collaboration]] |
|
||||
| **Mesh Sync** | Beobachtungen von parallelen Agenten zusammenführen | [[Multi-Agent Collaboration]] |
|
||||
| **Shared vs Private** | Wissen angemessen scoping | [[Multi-Agent Collaboration]] |
|
||||
| **Work Coordination** | Doppelte Arbeit verhindern | [[Multi-Agent Collaboration]] |
|
||||
|
||||
### Governance-Verbesserungen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Privacy and Governance** | Sicherheit und Rechenschaftspflicht | [[Privacy and Governance]] |
|
||||
| **Filter on Ingest** | Sensitive Daten automatisch entfernen | [[Privacy and Governance]] |
|
||||
| **Audit Trail** | Alle Vorgänge protokollieren | [[Privacy and Governance]] |
|
||||
| **Bulk Operations** | Geprüfte, reversible Massenvorgänge | [[Privacy and Governance]] |
|
||||
|
||||
### Erweiterte Funktionen
|
||||
|
||||
| Verbesserung | Zweck | Concept-Seite |
|
||||
|-------------|---------|--------------|
|
||||
| **Crystallization** | Erkundungen zu strukturiertem Wissen destillieren | [[Crystallization]] |
|
||||
| **Implementation Spectrum** | Modularer Adoptionspfad von minimal bis voll | [[Implementation Spectrum]] |
|
||||
|
||||
Für einen geführten Adoptionspfad siehe [[Implementation Spectrum]].
|
||||
|
||||
## Architektur
|
||||
|
||||
Siehe [[Three-Layer Architecture]] für Details:
|
||||
|
||||
1. **Rohdatenquellen** — Unveränderliche kuratierte Sammlung von Quelldokumenten (Artikel, Papiere, Bilder, Datendateien)
|
||||
2. **Das Wiki** — Verzeichnis von LLM-generierten Markdown-Dateien (Zusammenfassungen, Entity-Seiten, Concept-Seiten, Vergleiche, Index, Log)
|
||||
3. **Das Schema** — Konfigurationsdokument (z. B. AGENTS.md), das Struktur, Konventionen und Workflows definiert
|
||||
|
||||
## Vorgänge
|
||||
|
||||
### Aufnahme-Workflow
|
||||
1. Benutzer legt neue Quelle in Rohdatensammlung ab
|
||||
2. LLM liest die Quelle
|
||||
3. LLM diskutiert wichtige Erkenntnisse mit Benutzer
|
||||
4. LLM schreibt Zusammenfassungsseite im Wiki
|
||||
5. LLM aktualisiert relevante Entity- und Concept-Seiten im gesamten Wiki
|
||||
6. LLM aktualisiert index.md
|
||||
7. LLM fügt Eintrag zu log.md hinzu
|
||||
|
||||
**Ergebnis**: Eine einzelne Quelle könnte 10-15 Wiki-Seiten berühren.
|
||||
|
||||
### Abfrage-Workflow
|
||||
1. Benutzer stellt eine Frage
|
||||
2. LLM durchsucht index.md nach relevanten Seiten
|
||||
3. LLM liest relevante Entity- und Concept-Seiten
|
||||
4. LLM folgt Cross-References zu verwandten Seiten
|
||||
5. LLM synthetisiert Antwort mit Zitaten
|
||||
6. Wertvolle Antworten werden als neue Wiki-Seiten eingereicht
|
||||
|
||||
### Lint-Workflow
|
||||
Periodische Gesundheitsprüfung zu:
|
||||
- Widersprüche zwischen Seiten finden
|
||||
- Veraltete Aussagen identifizieren
|
||||
- Verwaiste Seiten lokalisieren
|
||||
- Fehlende Seiten finden
|
||||
- Fehlende Cross-References identifizieren
|
||||
- Verbesserungen vorschlagen
|
||||
|
||||
## Schlüsselkomponenten
|
||||
|
||||
### Indizierung und Protokollierung
|
||||
- **index.md**: Inhaltsgerichteter Katalog, nach Kategorie organisiert. Einstiegspunkt des LLM zum Finden relevanter Seiten.
|
||||
- **log.md**: Chronologischer Append-Only-Datensatz aller Vorgänge.
|
||||
|
||||
### Seitentypen
|
||||
- **Source-Seiten**: Zusammenfassungen aufgenommener Quellen
|
||||
- **Entity-Seiten**: Projekte, Systeme, Tools, Technologien, Menschen
|
||||
- **Concept-Seiten**: Architekturen, Muster, Protokolle, Workflows, Entscheidungen, Probleme
|
||||
- **Vergleichs-Seiten**: Nebeneinander-Analyse von Entities
|
||||
|
||||
## Rollen
|
||||
|
||||
### Menschliche Verantwortungen
|
||||
- Quellen kuratieren (Qualitätsdokumente finden und auswählen)
|
||||
- Die Analyse leiten (LLM anleiten, worauf zu betonen ist)
|
||||
- Gute Fragen stellen (Wissenssynthese vorantreiben)
|
||||
- Über die Bedeutung nachdenken (synthetisiertes Wissen interpretieren)
|
||||
|
||||
### LLM-Verantwortungen
|
||||
- Schlüsselinformationen aus Quellen lesen und extrahieren
|
||||
- Alle Wiki-Inhalte schreiben und verwalten
|
||||
- Cross-References erstellen und aktualisieren
|
||||
- Konsistenz über Seiten aufrechterhalten
|
||||
- Widersprüche und Lücken markieren
|
||||
- Buchführung durchführen (Ablage, Index-Aktualisierung, Protokollierung)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Personal Knowledge Management im Laufe der Zeit
|
||||
- Tiefe Forschung zu einem Thema (Wochen oder Monate)
|
||||
- Bücher mit vielen Cross-References lesen
|
||||
- Geschäfts-/Team-interne Dokumentation
|
||||
- Konkurrenzanalyse, Due Diligence
|
||||
- Reiseplanung, Kursnotizen, Hobby-Tieftauchgänge
|
||||
- Jede Domäne, in der Wissen angesammelt und organisiert werden soll
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Einfache, einmalige Fragen (traditionelles RAG reicht aus)
|
||||
- Notwendigkeit von Echtzeit-Updates aus Live-Datenquellen
|
||||
- Domänen, in denen strukturierte Abfrage (SQL) angemessener ist
|
||||
- Wenn der Overhead der Wiki-Wartung den Vorteil überwiegt
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[RAG]]: Der traditionelle Ansatz, den dieses Muster verbessert
|
||||
- [[Knowledge Compounding]]: Die Auswirkung des Aufbaus von Wissen auf sich selbst
|
||||
- [[Three-Layer Architecture]]: Die architektonische Grundlage
|
||||
- [[Memex]]: Vannevar Bushs 1945er Vision, die dieses Muster inspirierte
|
||||
|
||||
## Beispiele
|
||||
|
||||
- **Persönlich**: Ziele, Gesundheit, Psychologie, Selbstverbesserung verfolgen
|
||||
- **Forschung**: Tiefer in ein Thema eintauchen, Papiere lesen, umfassendes Wiki aufbauen
|
||||
- **Lesen**: Jedes Kapitel ablegen, Seiten für Charaktere, Themen, Handlungsfäden erstellen
|
||||
- **Geschäft**: Internes Wiki mit Slack-Threads, Meetingtransskripten, Projektdokumenten gefüttert
|
||||
- **Fan-Wikis**: Wie [[Tolkien Gateway]] — Tausende verlinkter Seiten
|
||||
|
||||
## Tools
|
||||
|
||||
- [[Obsidian]]: Die IDE zum Durchsuchen von Wiki-Inhalten
|
||||
- [[qmd]]: Optionale Suchmaschine für größere Wikis
|
||||
- [[Marp]]: Zum Erstellen von Präsentationen aus Wiki-Inhalten
|
||||
- [[Dataview]]: Für dynamische Tabellen und Listen
|
||||
- [[Obsidian Web Clipper]]: Zum schnellen Aufnehmen von Quellen in die Rohdatensammlung
|
||||
|
||||
## Historie
|
||||
|
||||
- [1945] - Vannevar Bush schlägt [[Memex]]-Konzept vor
|
||||
- [2023-2024] - LLM-Agenten werden fähig genug, das Muster zu implementieren
|
||||
- [2026-07-26] - Concept-Seite erstellt; dieses Wiki implementiert das Muster
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Three-Layer Architecture]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[RAG]]
|
||||
- [[Memex]]
|
||||
- [[Vannevar Bush]]
|
||||
- [[Obsidian]]
|
||||
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-09-01
|
||||
related: [Event-Driven Automation, Quality and Self-Correction, Detect-Repair Asymmetry, 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
|
||||
|
||||
- [[Quality and Self-Correction]]
|
||||
- [[Confidence Scoring]]
|
||||
- [[Event-Driven Automation]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **macht sichtbar:** [[Detect-Repair Asymmetry]]
|
||||
- **abgesichert von:** [[Green Suite Blind Spot]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
|
||||
## 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]]
|
||||
@@ -0,0 +1,95 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [gate, safety, mass-update, confirmation]
|
||||
created: 2026-08-03
|
||||
modified: 2026-09-01
|
||||
related: [Content Quality Control, wikitool, Iteration and Cost Limits, Structural Enforcement over Documented Rule, Bulk Operations]
|
||||
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
|
||||
|
||||
- [[Content Quality Control]] - Qualitätsrahmen, den Massenaktualisierungen bewahren sollten
|
||||
- [[wikitool]] - Das CLI-Tool, das dieses Gate implementieren könnte
|
||||
- [[Workflow Orchestration]] - Koordinierte Vorgänge, die Gates benötigen könnten
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **wird gespiegelt durch:** [[Iteration and Cost Limits]]
|
||||
- **wendet an:** [[Structural Enforcement over Documented Rule]]
|
||||
- **grenzt ab gegen:** [[Bulk Operations]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
- [[Structural Enforcement over Documented Rule]]
|
||||
- [[Bulk Operations]]
|
||||
|
||||
## 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]]
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [memory, lifecycle, confidence, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Confidence Scoring, Supersession, Consolidation Tiers, Forgetting, Knowledge Compounding]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Architektur des Wissenslebenszyklus mit Confidence Scoring, Supersession, Forgetting und Consolidation Tiers zur Pflege von Fakten über die Zeit.
|
||||
---
|
||||
# Memory Lifecycle
|
||||
|
||||
**Typ:** Architektur (Knowledge-Management-Muster)
|
||||
|
||||
## Definition
|
||||
|
||||
Memory Lifecycle ist die Erkenntnis, dass **Wissen einen Lebenszyklus hat** und entsprechend verwaltet werden muss. Im Gegensatz zum ursprünglichen LLM Wiki Pattern, das alle Wiki-Inhalte für immer gleich gültig behandelt, erkennt der Memory-Lifecycle-Ansatz an, dass Tatsachen unterschiedliche Bedeutung, Aktualität und Zuverlässigkeit haben, die sich im Laufe der Zeit ändern.
|
||||
|
||||
Dieses Konzept ist eine primäre Verbesserung, die in [[LLM Wiki Pattern]] v2 eingeführt wurde, basierend auf Produktionslektionen aus [[Agent Memory]].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Das Problem
|
||||
|
||||
Die flache Behandlung aller Wissenstypen des ursprünglichen Musters führt zu:
|
||||
- Alte, möglicherweise veraltete Informationen neben neuen, verifizierten Tatsachen
|
||||
- Keine Möglichkeit, zwischen etabliertem Wissen und vorläufigen Beobachtungen zu unterscheiden
|
||||
- Wissensdatenbanken, die im Laufe der Zeit laut und schwer zu navigieren werden
|
||||
- Kein Mechanismus, damit sich Wissen entwickelt oder überholt wird
|
||||
|
||||
### Die Lösung: Vier Säulen
|
||||
|
||||
**1. Confidence Scoring**
|
||||
Jede Tatsache im Wiki trägt einen Confidence-Score, der widerspiegelt:
|
||||
- **Quellenanzahl:** +0,2 pro unterstützende Quelle (Max +0,6)
|
||||
- **Aktualität:** +0,2 wenn <30 Tage, +0,1 wenn <90 Tage
|
||||
- **Quellenqualität:** +0,1 für offizielle Dokumente, +0,05 für seriöse Quellen
|
||||
- **Bestätigung:** +0,1 wenn mehrere unabhängige Quellen zustimmen
|
||||
- **Basis-Confidence:** 0,5 (Standard für einzelne Quelle)
|
||||
|
||||
Confidence fällt mit 1% pro Monat seit letzter Bestätigung, Minimum 0,2.
|
||||
|
||||
**2. Supersession**
|
||||
Wenn neue Informationen einen bestehenden Aussage widersprechen oder aktualisieren:
|
||||
- Der neue Aussage **ersetzt** explizit den alten
|
||||
- Beide sind mit Zeitstempeln verlinkt
|
||||
- Die alte Version wird bewahrt, aber **als veraltet markiert**
|
||||
- Dies ist Versionskontrolle für Wissen, nicht nur für Dateien
|
||||
|
||||
**3. Vergessen (Retention Curve)**
|
||||
Nicht alles sollte für immer leben. Eine Retention Curve inspiriert von Ebbinghaus implementieren:
|
||||
- Tatsachen, die Monate lang nicht aufgerufen oder verstärkt wurden, **verblassen allmählich**
|
||||
- Nicht gelöscht, aber **deprioritiert** bei Suche und Synthese
|
||||
- Unterschiedliche Verfallsraten für verschiedene Typen:
|
||||
- Architekturentscheidungen verfallen **langsam**
|
||||
- Vorübergehende Fehler verfallen **schnell**
|
||||
- Das LLM-Äquivalent von etwas in eine untere Schublade verschieben
|
||||
|
||||
**4. Consolidation Tiers**
|
||||
Eine Pipeline, die Informationen fördert, wenn sich Beweise ansammeln:
|
||||
|
||||
```
|
||||
Rohe Beobachtungen
|
||||
↓ (compress)
|
||||
Working Memory → aktuelle Beobachtungen, noch nicht verarbeitet
|
||||
↓ (compress)
|
||||
Episodic Memory → Sitzungszusammenfassungen, komprimiert aus rohen Beobachtungen
|
||||
↓ (compress)
|
||||
Semantic Memory → Sitzungsübergreifende Tatsachen, konsolidiert aus Episoden
|
||||
↓ (compress)
|
||||
Procedural Memory → Workflows und Muster, extrahiert aus wiederholter Semantik
|
||||
```
|
||||
|
||||
Jede Ebene ist:
|
||||
- Mehr **komprimiert** als die darunter
|
||||
- Mehr **confident** (höherwertige Beweise)
|
||||
- **Länger lebend** als die darunter
|
||||
|
||||
Von „Ich habe das einmal gesehen" zu „So funktionieren die Dinge" gehen.
|
||||
|
||||
## Implementierung
|
||||
|
||||
Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
1. **Metadaten verfolgen** für jede Aussage: Quelle, Datum, Confidence-Score, verwandte Entities
|
||||
2. **Automatisch verfallen** Confidence-Scores basierend auf Zeit
|
||||
3. **Confidence erhöhen** wenn Aussagen aufgerufen oder bestätigt werden
|
||||
4. **Supersession markieren** mit expliziten Links und Zeitstempeln
|
||||
5. **Gestuffelt Speicherung** mit unterschiedlichen Aufbewahrungsrichtlinien implementieren
|
||||
6. **Hochwertige** Informationen bevorzugt in Abfragen anzeigen
|
||||
|
||||
## Vorteile
|
||||
|
||||
- Wiki bleibt **nützlich**, während es wächst (verfällt nicht)
|
||||
- Benutzer können **der Information vertrauen** (Confidence ist explizit)
|
||||
- Wissen **entwickelt sich** natürlich (Supersession)
|
||||
- Irrelevante Informationen **verblassen** (Vergessen)
|
||||
- Muster **entstehen** (Consolidation Tiers)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Jedes Wiki, das über mehrere hundert Seiten hinauswachsen soll
|
||||
- Domänen, in denen sich Wissen im Laufe der Zeit ändert (Technologie, Forschung)
|
||||
- Situationen, in denen die Zuverlässigkeit von Informationen variiert
|
||||
- Multi-Quellen-Wissensdatenbanken
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Confidence Scoring]] - Der Scoring-Mechanismus
|
||||
- [[Supersession]] - Der Versionskontroll-Mechanismus
|
||||
- [[Forgetting]] - Der Retention-Curve-Mechanismus
|
||||
- [[Consolidation Tiers]] - Die Promotions-Pipeline
|
||||
- [[Knowledge Compounding]] - Die Gesamtauswirkung
|
||||
- [[LLM Wiki Pattern]] - Das übergeordnete Muster
|
||||
- [[Agent Memory]] - Produktionsimplementierung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Event-Driven Automation]] (Trigger für Lebenszyklus-Management)
|
||||
- [[Quality Scoring]] (komplementäre Qualitätsmetriken)
|
||||
- [[Knowledge Graph]] (Struktur zur Verfolgung von Beziehungen)
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Multi-Agent Collaboration, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Abgleichsmechanismus, der Beobachtungen paralleler Agenten in ein gemeinsames Wiki überführt; Last-Write-Wins mit Konflikterkennung und manuellem Eingriff.
|
||||
---
|
||||
# Mesh Sync
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Wenn mehrere Agenten parallel arbeiten, akzeptiert Mesh Sync automatisch nicht-konfligierende Updates und markiert semantische Konflikte zur Überprüfung durch Menschen und ermöglicht so kollaboratives Wissensaufbau.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,261 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: protocol
|
||||
tags: [industrial, automation, communication, serial]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, ha-core, Home Assistant]
|
||||
sources: []
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: general
|
||||
summary: Industrielles Kommunikationsprotokoll von 1979 zur Anbindung speicherprogrammierbarer Steuerungen und Geräte über serielle oder TCP-Netze.
|
||||
---
|
||||
# Modbus
|
||||
|
||||
**Typ:** Protokoll (Kommunikationsprotokoll)
|
||||
|
||||
## Definition
|
||||
|
||||
Modbus ist ein serielles Kommunikationsprotokoll, das 1979 von Modicon (jetzt Schneider Electric) veröffentlicht wurde und für die Verwendung mit seinen programmierbaren Steuerungsgeräten (PLCs) bestimmt ist. Es ist seitdem zu einem De-facto-Standard-Kommunikationsprotokoll in industriellen Umgebungen geworden und ist jetzt die am häufigsten verfügbare Mittel zum Verbinden industrieller elektronischer Geräte.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Offener Standard** - Öffentlich verfügbar, keine Lizenzgebühren
|
||||
- **Serielles Protokoll** - Ursprünglich für serielle (RS-232/RS-485) Kommunikation konzipiert
|
||||
- **Client-Server-Modell** - Ein Master, mehrere Slaves (Geräte)
|
||||
- **Einfaches Frame-Format** - Leicht auf eingebetteten Geräten zu implementieren
|
||||
- **Weit verbreitet** - Wird in vielen Branchen und Gerätetypen verwendet
|
||||
|
||||
## Varianten
|
||||
|
||||
### Modbus RTU
|
||||
|
||||
- **Transport:** Seriell (RS-232, RS-485)
|
||||
- **Kodierung:** Binär (RTU = Remote Terminal Unit)
|
||||
- **Prüfsumme:** CRC
|
||||
- **Anwendungsfall:** Industrielle Umgebungen, lange Entfernungen
|
||||
- **Geschwindigkeit:** Bis zu 115200 Baud
|
||||
- **Entfernung:** Bis zu 1200 Meter (RS-485)
|
||||
|
||||
### Modbus ASCII
|
||||
|
||||
- **Transport:** Seriell (RS-232, RS-485)
|
||||
- **Kodierung:** ASCII-Zeichen
|
||||
- **Prüfsumme:** LRC (Longitudinal Redundancy Check)
|
||||
- **Anwendungsfall:** Menschenlesbar, langsamer aber robuster in lauten Umgebungen
|
||||
- **Geschwindigkeit:** Langsamer als RTU aufgrund der ASCII-Kodierung
|
||||
|
||||
### Modbus TCP
|
||||
|
||||
- **Transport:** Ethernet TCP/IP
|
||||
- **Kodierung:** Wie Modbus RTU (binär)
|
||||
- **Port:** 502 (Standard)
|
||||
- **Anwendungsfall:** Moderne Netzwerke, Integration mit IT-Systemen
|
||||
- **Adressierung:** Verwendet IP-Adressen statt Slave-IDs
|
||||
- **Vorteil:** Keine serielle-zu-Ethernet-Konverter erforderlich
|
||||
|
||||
### Modbus over TCP/IP (Modbus/TCP)
|
||||
|
||||
Wie Modbus TCP - die häufigste TCP-Variante.
|
||||
|
||||
## Adressierung
|
||||
|
||||
### Geräte-Adressierung
|
||||
|
||||
- **Slave ID:** 1-247 (0 ist Broadcast, 248-255 sind reserviert)
|
||||
- **TCP:** IP-Adresse ersetzt Slave ID, aber Slave ID ist noch im Protokoll-Frame
|
||||
|
||||
### Daten-Adressierung
|
||||
|
||||
Modbus organisiert Daten in vier primäre Tabellen:
|
||||
|
||||
| Tabelle | Code | Beschreibung |
|
||||
|-------|------|-------------|
|
||||
| Discrete Inputs | 0x | Schreibgeschützt, 1-Bit (digitale Eingänge) |
|
||||
| Coils | 01 | Lesen-Schreiben, 1-Bit (digitale Ausgänge) |
|
||||
| Input Registers | 04 | Schreibgeschützt, 16-Bit (analoge Eingänge) |
|
||||
| Holding Registers | 03 | Lesen-Schreiben, 16-Bit (analoge Ausgänge, Konfiguration) |
|
||||
|
||||
**Hinweis:** Adressen werden oft mit einem Präfix referenziert:
|
||||
- `0:` oder `I:` für Input (Discrete Inputs, Input Registers)
|
||||
- `1:` oder `Q:` für Output (Coils, Holding Registers)
|
||||
- `4:` für Holding Registers (häufige Konvention)
|
||||
|
||||
## Datentypen
|
||||
|
||||
Modbus überträgt 16-Bit-Werte. Größere Werte werden als mehrere Register übertragen:
|
||||
|
||||
| Datentyp | Register | Byte-Reihenfolge |
|
||||
|-----------|-----------|------------|
|
||||
| INT16 | 1 | Big-Endian |
|
||||
| UINT16 | 1 | Big-Endian |
|
||||
| INT32 | 2 | Konfigurierbar |
|
||||
| UINT32 | 2 | Konfigurierbar |
|
||||
| FLOAT32 | 2 | IEEE 754, konfigurierbar |
|
||||
| FLOAT64 | 4 | IEEE 754, konfigurierbar |
|
||||
|
||||
**Byte-Reihenfolge (Endianness):**
|
||||
- Big-Endian: Höchstwertiges Byte zuerst
|
||||
- Little-Endian: Niedrigstwertiges Byte zuerst
|
||||
- Wort-Reihenfolge: Hochwort zuerst oder Niedrigwort zuerst
|
||||
|
||||
Häufige Kombinationen: 1211 (Big-Endian-Wort, Big-Endian-Byte), 2143, 4321 usw.
|
||||
|
||||
## Funktionscodes
|
||||
|
||||
Häufige Modbus-Funktionscodes:
|
||||
|
||||
| Code | Name | Beschreibung |
|
||||
|------|------|-------------|
|
||||
| 01 | Read Coils | Mehrere Coil-Status lesen |
|
||||
| 02 | Read Discrete Inputs | Mehrere diskrete Eingänge lesen |
|
||||
| 03 | Read Holding Registers | Mehrere Holding Registers lesen |
|
||||
| 04 | Read Input Registers | Mehrere Input Registers lesen |
|
||||
| 05 | Write Single Coil | Ein einzelnes Coil schreiben |
|
||||
| 06 | Write Single Register | Ein einzelnes Holding Register schreiben |
|
||||
| 07 | Read Exception Status | Gerätekennstatus lesen |
|
||||
| 08 | Diagnostics | Diagnose-Funktionen |
|
||||
| 15 | Write Multiple Coils | Mehrere Coil-Status schreiben |
|
||||
| 16 | Write Multiple Registers | Mehrere Holding Registers schreiben |
|
||||
| 17 | Report Slave ID | Slave ID und zusätzliche Informationen melden |
|
||||
|
||||
## Verwendung in Ihren Projekten
|
||||
|
||||
Basierend auf der Repository-Struktur wird Modbus wahrscheinlich verwendet von:
|
||||
|
||||
- [[E3DC]]-Systeme stellen Modbus-TCP-Schnittstellen bereit
|
||||
- [[ha-core]] kann Modbus verwenden, um mit E3DC-Wechselrichtern zu kommunizieren
|
||||
- [[Home Assistant]]-Integrationen verwenden häufig Modbus zur Gerätekommunikation
|
||||
|
||||
### Beispiel: Lesen von E3DC-Daten über Modbus TCP
|
||||
|
||||
```python
|
||||
# Python example using pymodbus
|
||||
from pymodbus.client import ModbusTcpClient
|
||||
|
||||
client = ModbusTcpClient('192.168.1.100', port=502)
|
||||
client.connect()
|
||||
|
||||
# Read battery SOC (Holding Register 40000, assuming INT16)
|
||||
response = client.read_holding_registers(0, 1, slave=1)
|
||||
soc = response.registers[0]
|
||||
|
||||
print(f"Battery SOC: {soc}%")
|
||||
client.close()
|
||||
```
|
||||
|
||||
```go
|
||||
// Go example using a Modbus library
|
||||
package main
|
||||
|
||||
import (
|
||||
"fmt"
|
||||
"github.com/goburrow/modbus"
|
||||
)
|
||||
|
||||
func main() {
|
||||
handler := modbus.NewTCPClientHandler("192.168.1.100:502")
|
||||
handler.SlaveId = 1
|
||||
handler.Timeout = 5000 * time.Millisecond
|
||||
|
||||
client := modbus.NewClient(handler)
|
||||
if err := client.Connect(); err != nil {
|
||||
panic(err)
|
||||
}
|
||||
defer client.Close()
|
||||
|
||||
// Read holding register 0
|
||||
results, err := client.ReadHoldingRegisters(0, 1)
|
||||
if err != nil {
|
||||
panic(err)
|
||||
}
|
||||
|
||||
fmt.Printf("Value: %d\n", results[0])
|
||||
}
|
||||
```
|
||||
|
||||
## Häufige Probleme
|
||||
|
||||
1. **Endianness-Fehler** - Daten erscheinen mit falschen Werten
|
||||
2. **Register-Adressierung um Eins daneben** - Verschiedene Hersteller verwenden unterschiedliche Adressierung
|
||||
3. **Baud-Raten-Fehler** - Für serielle Verbindungen
|
||||
4. **Parität/Stop-Bits** - Serielle Konfigurationsprobleme
|
||||
5. **Slave-ID-Konflikte** - Mehrere Geräte mit gleicher ID auf demselben Bus
|
||||
6. **Timeout-Probleme** - Gerät reagiert nicht innerhalb des Timeout-Zeitraums
|
||||
7. **Byte-Reihenfolge-Verwirrung** - Unterschiedliche Interpretationen von Register-Paaren
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Die Modbus-Map immer dokumentieren** - Welche Register enthalten welche Daten
|
||||
2. **Zuerst mit Modbus-Tools testen** - Modbus Poll, QModMaster oder ähnliches verwenden
|
||||
3. **Timeouts elegant verarbeiten** - Geräte können vorübergehend nicht verfügbar sein
|
||||
4. **Werte zwischenspeichern** - Nicht zu häufig abfragen
|
||||
5. **Daten validieren** - Auf angemessene Bereiche prüfen
|
||||
6. **Ordnungsgemäße Fehlerbehandlung verwenden** - Nicht davon ausgehen, dass Lesevorgänge erfolgreich sind
|
||||
7. **Endianness dokumentieren** - Byte- und Wort-Reihenfolge angeben
|
||||
|
||||
## Tools
|
||||
|
||||
- **Modbus Poll** - Windows GUI-Tool zum Testen
|
||||
- **QModMaster** - Cross-Plattform-Modbus-Master
|
||||
- **modbus-palette** - Node-RED-Knoten für Modbus
|
||||
- **pymodbus** - Python-Bibliothek
|
||||
- **goburrow/modbus** - Go-Bibliothek
|
||||
- **libmodbus** - C-Bibliothek
|
||||
- **Wireshark** - Mit Modbus-Dissektor für Analyse
|
||||
|
||||
## Wann Modbus zu verwenden
|
||||
|
||||
- Verbindung zu industriellen Geräten (PLCs, Wechselrichter, Sensoren)
|
||||
- Wenn Ethernet oder Seriell verfügbar ist
|
||||
- Für einfache, zuverlässige Kommunikation
|
||||
- Wenn das Gerät Modbus nativ unterstützt
|
||||
|
||||
## Wann Modbus NICHT zu verwenden
|
||||
|
||||
- Wenn höherwertige Protokolle verfügbar sind (MQTT, HTTP REST)
|
||||
- Für komplexe Datenstrukturen
|
||||
- Wenn Sicherheit ein Problem ist (Modbus hat keine eingebaute Sicherheit)
|
||||
- Für Hochgeschwindigkeits-Datenübertragung mit hohem Volumen
|
||||
|
||||
## Sicherheitsaspekte
|
||||
|
||||
**Modbus hat keine eingebaute Sicherheit:**
|
||||
- Keine Authentifizierung
|
||||
- Keine Verschlüsselung
|
||||
- Keine Integritätsprüfung
|
||||
|
||||
**Abhilfemaßnahmen:**
|
||||
- Auf isolierten Netzwerken verwenden (nicht dem Internet ausgesetzt)
|
||||
- VPNs oder Firewalls zum Einschränken des Zugriffs verwenden
|
||||
- Modbus Security (TLS) in Betracht ziehen, falls verfügbar
|
||||
- Netzwerksegmentierung verwenden
|
||||
|
||||
## Leistung
|
||||
|
||||
- **Latenz:** Normalerweise 10-100ms pro Anfrage
|
||||
- **Durchsatz:** 10-100 Anfragen/Sekunde (hängt vom Netzwerk und den Geräten ab)
|
||||
- **Nachrichtengröße:** Durch Protokoll begrenzt (normalerweise < 260 Bytes)
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[MQTT]] - Alternatives Protokoll für IoT/Industrie
|
||||
- [[OPC UA]] - Modernes Industrieprotokoll mit Sicherheit
|
||||
- Industrial-Automation-Konzept
|
||||
- [[E3DC]] - Verwendet Modbus zur Kommunikation
|
||||
|
||||
## Historie
|
||||
|
||||
- [1979] - Ursprünglich von Modicon veröffentlicht
|
||||
- [2004] - Modbus IDA (Modbus Industrial Automation) gegründet
|
||||
- [2006] - Modbus/TCP-Spezifikation veröffentlicht
|
||||
- [2007] - Modbus-Organisation gegründet
|
||||
- [2026-07-25] - Concept-Seite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [Modbus Organization](https://modbus.org/)
|
||||
- [Modbus Specifications](https://modbus.org/specifications/)
|
||||
- [[E3DC]] - Verwendet Modbus TCP
|
||||
- [[ha-core]] - Kann Modbus verwenden
|
||||
@@ -0,0 +1,129 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [multi-agent, collaboration, sync, coordination]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, Mesh Sync, Shared vs Private, 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
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Mesh Sync]] - Der Synchronisationsmechanismus
|
||||
- [[Shared vs Private]] - Der Scoping-Mechanismus
|
||||
- [[Work Coordination]] - Der Koordinationsmechanismus
|
||||
- [[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)
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: problem
|
||||
tags: [bug, drifts, kebab-case, human-readable]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [AGENTS.md]
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Widerspruch zwischen README.md (kebab-case) und AGENTS.md (lesbar mit Leerzeichen), der zu Drift bei der Validierung führt
|
||||
---
|
||||
# Naming Convention Conflict
|
||||
|
||||
**Typ:** problem
|
||||
|
||||
## Definition
|
||||
|
||||
Naming Convention Conflict ist ein spezifischer Drift/Bug, bei dem README.md und AGENTS.md unterschiedliche Benennungskonventionen für Wiki-Dateien angeben. README.md erfordert kebab-case (z. B. `hybrid-search.md`), während AGENTS.md benutzerfreundliche Titel mit Leerzeichen erfordert (z. B. `Hybrid Search.md`). Diese Inkonsistenz verursacht Validierungsdrift und macht es unmöglich, beide Anforderungen gleichzeitig zu erfüllen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **README.md-Anforderung:** kebab-case-Dateinamen (z. B. `my-page.md`)
|
||||
- **AGENTS.md-Anforderung:** Benutzerfreundliche Titel mit Leerzeichen (z. B. `My Page.md`)
|
||||
- **Auswirkung:** Verursacht Validierungsinkonsistenzen und verwirrt sowohl Menschen als auch automatisierte Tools
|
||||
- **Entdeckung:** Während der Codex-Analyse von Repo-Drift identifiziert
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Konflikt: Sollte `CI/CD Architecture.md` sein wie `CI/CD Architecture.md` (AGENTS.md) oder `ci-cd-architecture.md` (README.md)?
|
||||
- Ergebnis: Einige Seiten folgen einer Konvention, andere folgen der anderen und erzeugen Inkonsistenz
|
||||
|
||||
## Lösungsoptionen
|
||||
|
||||
1. **Einen Standard auswählen:** Für kebab-case oder Namen mit Leerzeichen entscheiden und alle Dokumentation aktualisieren
|
||||
2. **Beide unterstützen:** Die Tooling so gestalten, dass beide Konventionen akzeptiert werden (komplex, nicht empfohlen)
|
||||
3. **Migrationspfad:** Eine Zielkonvention wählen und alle vorhandenen Seiten migrieren
|
||||
|
||||
## Status
|
||||
|
||||
- **Identifiziert:** 2026-08-03 (Codex-Analyse)
|
||||
- **Schweregrad:** Mittel - verursacht Drift, aber Wiki funktioniert immer noch
|
||||
- **Geplant:** Sollte vor dem Sonnet-Analyse-Vergleich gelöst werden
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[AGENTS.md]] (gibt benutzerfreundliche Titel mit Leerzeichen an)
|
||||
- README.md (gibt kebab-case an)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **beeinflusst:** [[AGENTS.md]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[AGENTS.md]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [interoperability, export, validate, okf-profile]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [awesome-llm-wiki]
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Optionale Kompatibilität zum Open Knowledge Framework als Export- und Prüfmodus, ohne das interne Modell zu ersetzen
|
||||
---
|
||||
# OKF Compatibility
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
OKF (Open Knowledge Framework) Compatibility ist das Konzept, einen Export-/Validierungsmodus hinzuzufügen, der OKF-kompatible Formate lesen und schreiben kann, um Interoperabilität mit anderen Tools und Wikis zu ermöglichen, ohne das interne Schema oder Modell zu ersetzen. Dies ermöglicht es dem Wiki, am breiteren OKF-Ökosystem teilzunehmen und gleichzeitig seine eigenen deterministischen Grundlagen beizubehalten.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Export-Modus:** Wiki-Seiten in OKF-kompatibles Format konvertieren
|
||||
- **Validierungsmodus:** OKF-Kompatibilität vorhandener Inhalte überprüfen
|
||||
- **Kein Ersatz:** Ersetzt nicht das interne AGENTS.md-Schema oder wikitool
|
||||
- **Interoperabilität:** Ermöglicht Datenaustausch mit anderen OKF-kompatiblen Systemen
|
||||
|
||||
## Beispiele
|
||||
|
||||
- `wikitool export --format okf --output wiki-okf/`
|
||||
- `wikitool validate --format okf`
|
||||
- Interoperabilität mit Tools aus dem awesome-llm-wiki-Repository
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Interagieren mit externen OKF-kompatiblen Systemen
|
||||
- Für Datenmigration oder Austausch
|
||||
- Um am OKF-Ökosystem teilzunehmen
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Als Ersatz für das interne Schema
|
||||
- Wenn OKF-Kompatibilität nicht erforderlich ist
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[awesome-llm-wiki]] (OKF ist ein großes Thema in diesem Repository)
|
||||
- [[Three-Layer Architecture]] (OKF-Export würde eine zusätzliche Ebene oder einen Modus darstellen)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **vorgestellt in:** [[awesome-llm-wiki]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[awesome-llm-wiki]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [ENVIRONMENT.md, Personalization Plane, wikitool, Chemenu]
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Muster fuer eine Datei, die eine Instanz ueber ihre Umgebung informiert, ohne Betriebsvoraussetzung zu sein: Health-Check meldet ohne zu scheitern, pro Checkout statt pro Repo'
|
||||
---
|
||||
# Optional Instance Context File
|
||||
|
||||
**Typ:** Architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Eine **Optional Instance Context File** ist eine Datei, die eine Instanz über ihre eigene
|
||||
Umgebung informiert, ohne Betriebsvoraussetzung zu sein: sie erspart einer Sitzung Fragen, deren
|
||||
Antworten sich selten ändern, und ihr Fehlen kostet Zeit, aber keine Korrektheit.
|
||||
|
||||
Das Muster ist die schwächere Schwester der [[Personalization Plane]]. Beide liefern ein
|
||||
Template aus, beide füllen es in einem Setup-Schritt, beide prüfen das Ergebnis mit einem
|
||||
Health-Check. Der Unterschied liegt darin, was der Check tut, wenn die Datei fehlt — und dieser
|
||||
eine Unterschied entscheidet, ob „optional" hält oder nur behauptet ist.
|
||||
|
||||
Erste Umsetzung: [[ENVIRONMENT.md]] in [[Chemenu]], Stack-Version `1.8.0`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Der Health-Check meldet, aber scheitert nie.** Eine fehlende Datei ergibt `OK` mit dem
|
||||
Vermerk „absent (optional)", kein `FAIL`. Ein `FAIL` würde die Datei durch die Hintertür
|
||||
verpflichtend machen und damit die Eigenschaft aufheben, um derentwillen sie entworfen wurde.
|
||||
Der Preis ihres Fehlens sind ein paar Fragen, keine falsche Ausgabe — und ein Check, der
|
||||
darauf rot wird, sortiert die beiden Kosten falsch ein.
|
||||
- **Genau ein Zustand ist meldenswert, und zwar als `WARN`:** ein umbenanntes, nie ausgefülltes
|
||||
Template. Diese Datei ist vorhanden, wird in jeder Sitzung mitgeladen und beantwortet nichts —
|
||||
schlechter als Abwesenheit, weil Abwesenheit ehrlich ist. Eine reine Existenzprüfung würde sie
|
||||
durchwinken; erkennbar wird sie über einen Sentinel im Template.
|
||||
- **Pro Checkout, nicht pro Repo.** Was hier steht, gilt einer Arbeitskopie: zwei Clones
|
||||
desselben Repos sind zwei Umgebungen. Deshalb ist die Datei gitignored, und deshalb ist eine
|
||||
committete Fassung schädlicher als gar keine — sie gibt dem zweiten Clone Antworten, die
|
||||
falsch sind statt zu fehlen, und eine falsche Angabe wird geglaubt.
|
||||
- **Das Ignore-Muster muss die Datei von ihrem Template trennen.** Das naheliegende
|
||||
`<Name>.md*` schluckt beides und nimmt der Distribution die Vorlage. Der Ausschluss gehört
|
||||
verankert und in beide Richtungen geprüft: die Datei muss ignoriert sein, das Template darf es
|
||||
nicht.
|
||||
- **Kontext, keine Autorität.** Die Datei beschreibt, was vorhanden ist, nicht, was erlaubt ist.
|
||||
Ein aufgeführter Remote autorisiert keinen Push an den Gates vorbei, ein aufgeführter Dienst
|
||||
öffnet kein Gate, und nichts darin ist eine Quelle für einen Wiki-Eintrag. Zugangsdaten
|
||||
gehören nicht hinein: die Datei liegt im Klartext und geht in jeden Agenten-Kontext.
|
||||
- **Raten ist schlimmer als Lücken lassen.** Der Setup-Schritt trägt ein, was aus dem Checkout
|
||||
ablesbar ist, fragt einmal nach dem Rest und akzeptiert „weiß ich nicht" — ein leerer
|
||||
Abschnitt wird gelöscht, nicht mit Plausiblem gefüllt. Eine geratene Zeile kostet mehr als die
|
||||
fehlende, aus demselben Grund, aus dem die Datei nicht committet wird.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[ENVIRONMENT.md]] — erste und bislang einzige Umsetzung: Harness, Skills, MCP-Server,
|
||||
Connectoren, Remotes, CI-Ort
|
||||
- [[wikitool]] — trägt den `environment`-Check in `doctor` und liefert das Template über
|
||||
`dist export` aus
|
||||
- [[CLAUDE.md]] — bindet die Datei als Import ein und trägt damit den Fall „Import, der legitim
|
||||
nie auflöst"
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Wenn eine Angabe drei Eigenschaften zugleich hat: sie ändert sich selten, sie wird trotzdem
|
||||
immer wieder erfragt, und ihr Fehlen macht die Arbeit langsamer statt falsch. Dann lohnt eine
|
||||
Datei, und dann darf sie optional sein.
|
||||
|
||||
Das Muster verlangt vier Dinge, die zusammengehören: ein ausgeliefertes Template, einen
|
||||
Setup-Schritt, der es anbietet statt es zu verlangen, einen Health-Check, der meldet ohne zu
|
||||
scheitern, und einen mechanisch geprüften Ausschluss aus der Versionskontrolle. Fehlt der
|
||||
Check, verrottet die Datei unbemerkt; fehlt der geprüfte Ausschluss, wandert eine Arbeitskopie
|
||||
in das Repo aller anderen.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- **Für Betriebsvoraussetzungen.** Was eine Instanz zum Funktionieren braucht, gehört in die
|
||||
[[Personalization Plane]] oder in einen echten `FAIL`. „Optional" ist eine Aussage über die
|
||||
Folgen des Fehlens, keine Höflichkeitsform.
|
||||
- **Für Angaben, die eine Maschine ermitteln kann.** `git remote -v` beantwortet sich selbst;
|
||||
aufgeschrieben wird, was sonst erfragt würde, nicht was ohnehin abrufbar ist. Ein
|
||||
aufgeschriebener Wert, den ein Kommando widerlegen kann, ist eine Kopie, die driftet.
|
||||
- **Für Regeln.** Wer Normatives hineinschreibt, erzeugt die zweite Kopie, die Invariante 8 von
|
||||
[[AGENTS.md]] verbietet.
|
||||
- **Für Geheimnisse.** Tokens und Passwörter gehören in die Shell-Konfiguration, nicht in eine
|
||||
Datei, die jede Sitzung mitliest.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Personalization Plane]] — dasselbe Muster als Pflicht: dort `FAIL` bei fehlender Datei, hier
|
||||
nie
|
||||
- [[KB Stack Versioning]] — das Muster kam mit `1.8.0`, ohne Kompatibilitätsbruch
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **umgesetzt von:** [[wikitool]]
|
||||
- **verwendet von:** [[Chemenu]]
|
||||
- **umgesetzt von:** [[ENVIRONMENT.md]]
|
||||
- **verwandt mit:** [[Personalization Plane]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[ENVIRONMENT.md]]
|
||||
- [[Personalization Plane]]
|
||||
- [[wikitool]]
|
||||
- [[Chemenu]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
@@ -0,0 +1,107 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Chemenu, Optional Instance Context File]
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: 'Schicht fuer Instanz-Identitaet: USER.md/SOUL.md werden als Template ausgeliefert, im Setup-Interview woertlich befuellt und vom doctor-Check auf fehlend wie unbefuellt geprueft'
|
||||
---
|
||||
# Personalization Plane
|
||||
|
||||
**Typ:** Architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Die Personalization Plane ist die Schicht eines verteilbaren Agenten-Stacks, die festhält, **wer
|
||||
eine Instanz bedient** und **wie sie klingt** - in `USER.md` und `SOUL.md` im Repo-Wurzelverzeichnis.
|
||||
Sie löst einen Zielkonflikt, der bei jeder verteilbaren Software mit persönlicher Konfiguration
|
||||
auftritt: die beiden Dateien sind Betriebsvoraussetzung und werden in jeder Sitzung gelesen,
|
||||
ihr Inhalt gehört aber genau einer Person und darf nicht in jede exportierte Kopie.
|
||||
|
||||
Die Auflösung ist nicht „ausliefern oder nicht", sondern eine Dreiteilung: die Distribution
|
||||
trägt `USER.md.template` und `SOUL.md.template`, die Installation befüllt sie im Interview, und
|
||||
ein Health-Check prüft beides. In [[Chemenu]] eingeführt mit Stack-Version `1.1.0`.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Template statt Inhalt.** Ausgeliefert werden nur die `.template`-Dateien. Dass die
|
||||
befüllten Fassungen nicht mitgehen, ist keine zusätzliche Regel, sondern Folge der
|
||||
bestehenden Root-Allowlist in `dist_cmd.py`: kopiert wird, was dort namentlich steht.
|
||||
- **Sentinel statt Existenzprüfung.** Jedes Template trägt eine Zeile mit dem Token
|
||||
`wikitool:template-unfilled`. Damit lässt sich „umbenannt" von „ausgefüllt" unterscheiden -
|
||||
eine reine Existenzprüfung würde eine Datei durchwinken, die vorhanden ist und nichts
|
||||
beantwortet.
|
||||
- **Interview statt Ableitung.** Der Installationsschritt befragt den Nutzer entlang der
|
||||
Template-Abschnitte und schreibt die Antworten wörtlich mit. Zwei Angaben darf ein Agent
|
||||
nicht raten: den Persona-Namen und die Themen, die bewusst draußen bleiben.
|
||||
- **Keine neue Autorität.** `USER.md` ist Kontext über den Nutzer, keine Instruktionsquelle;
|
||||
`SOUL.md` bestimmt nur Ton und Stimme und verliert gegen [[AGENTS.md]], die Contracts, Gates
|
||||
und Schemas. Eine Nutzeraussage ist keine Quelle und wandert nie ohne den normalen
|
||||
Quelle/Provenance/Confidence-Prozess nach `kb/`.
|
||||
- **Durchsetzung über den Health-Check.** `wikitool doctor` meldet `personalization: FAIL` bei
|
||||
fehlender Datei und bei einer, die noch den Sentinel trägt.
|
||||
- **Persona als Instanz-Eigenschaft.** Die Persona von [[Chemenu]] heißt **Thoth**,
|
||||
passend zur ägyptischen Namensgebung des Stacks selbst. Der Name ist eine
|
||||
Nutzerentscheidung, keine Vorgabe des Stacks: das Template schlägt keinen vor.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[Chemenu]] - erste Instanz mit befüllter Personalization Plane, Persona Thoth
|
||||
- [[wikitool]] - liefert die Templates über `dist export` aus und prüft sie über `doctor`
|
||||
- [[AGENTS.md]] - Abschnitt „Personalization"; die Kontrollebene behält den Vorrang
|
||||
- [[CLAUDE.md]] - importiert beide Dateien, damit sie unter Claude Code überhaupt geladen werden
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Wenn eine Datei gleichzeitig Betriebsvoraussetzung und persönlicher Inhalt ist. Das Muster
|
||||
verlangt drei Dinge, die zusammengehören: ein ausgeliefertes Template, einen
|
||||
Installationsschritt, der es befüllt, und einen mechanischen Check, der beide Fehlerfälle
|
||||
trennt. Fehlt der Check, ist der Installationsschritt eine Bitte; fehlt das Template, muss die
|
||||
Installation die Struktur raten.
|
||||
|
||||
Der Ansatz ist zugleich das Gegenmodell zu einer Instanz-Aktion als Migration: eine offene
|
||||
Personalization ist keine Korpus-Änderung und gehört nicht in die Kette aus [[KB Migration]],
|
||||
sondern in den Health-Check.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Angaben, die eine Maschine ermitteln kann. Autor-Identität kommt aus `git config`, nicht
|
||||
aus einem Interview.
|
||||
- Für Regeln. Wer Normatives in `SOUL.md` schreibt, erzeugt die zweite Kopie, die Invariante 8
|
||||
verbietet; Regeln stehen in [[AGENTS.md]] und den Contracts.
|
||||
- Für Wissen. Was der Nutzer im Interview sagt, ist Kontext, keine belegte Aussage - es
|
||||
begründet keinen Eintrag in `kb/`.
|
||||
- Für harness-spezifische Dateien. Eine Instanz, die ein bestimmtes Harness nicht benutzt,
|
||||
braucht dessen Konfiguration nicht, und ein `FAIL` dafür wäre falsch.
|
||||
- Für Angaben, deren Fehlen nur Zeit kostet. Wo ein `FAIL` unangemessen wäre, weil die Datei
|
||||
eine Sitzung beschleunigt statt sie zu ermöglichen, greift das schwächere Muster
|
||||
[[Optional Instance Context File]][^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31].
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Migration]] - Abgrenzung: dort Korpus-Form, hier Instanz-Zustand
|
||||
- [[Optional Instance Context File]] - dasselbe Muster ohne Pflicht: dort meldet der
|
||||
Health-Check nur, hier scheitert er[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- [[KB Stack Versioning]] - die Plane kam mit `1.1.0`, ohne Kompatibilitätsbruch
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **umgesetzt von:** [[wikitool]]
|
||||
- **verwendet von:** [[Chemenu]]
|
||||
- **verwandt mit:** [[Optional Instance Context File]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[Chemenu]]
|
||||
- [[Optional Instance Context File]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
@@ -0,0 +1,145 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [privacy, security, governance, audit]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Filter on Ingest, Audit Trail, 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
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Filter on Ingest]] - Der Filtermechanismus
|
||||
- [[Audit Trail]] - Der Protokollierungsmechanismus
|
||||
- [[Bulk Operations]] - Gouvernanzoperationen
|
||||
- [[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)
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Langlebigste Speicherschicht für Abläufe, Muster, bewährte Vorgehensweisen und Rezepte, gewonnen aus wiederholten semantischen Beobachtungen.
|
||||
---
|
||||
# Procedural Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Höchste Konfidenz und am stärksten komprimiert der Tiers; wird langsam aktualisiert, wenn neue Muster entstehen, und informiert automatisierte Entscheidungsfindung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Confidence Scoring, Implementation Spectrum, Memory Lifecycle, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Quantitative Bewertung aller vom LLM geschriebenen Inhalte nach struktureller Qualität, Vollständigkeit der Quellenangaben, Konsistenz mit dem Wiki und Themenabdeckung.
|
||||
---
|
||||
# Quality Scoring
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Inhalte unter einem Konfidenz-Schwellenwert (z. B. 0,6) werden zur Überprüfung gekennzeichnet oder automatisch umgeschrieben, um sicherzustellen, dass Wiki-Inhalte Qualitätsstandards erfüllen, ohne proportionalen menschlichen Aufwand.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [quality, scoring, self-healing, contradiction, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, Event-Driven Automation, 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
|
||||
|
||||
- [[LLM Wiki Pattern]] - Gesamtmuster
|
||||
- [[Memory Lifecycle]] - Ergänzende Knowledge Management
|
||||
- [[Confidence Scoring]] - Für Aussage-Level-Konfidenz
|
||||
- [[Event-Driven Automation]] - Für Auslösen von Qualitätsprüfungen
|
||||
- [[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)
|
||||
|
||||
@@ -0,0 +1,113 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [ai, retrieval, generation, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, NotebookLM, ChatGPT]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Architekturmuster, bei dem LLMs die Generierung um Dokumente aus einer Wissensbasis anreichern.
|
||||
---
|
||||
# RAG
|
||||
|
||||
**Typ:** Architecture (Retrieval Augmented Generation)
|
||||
|
||||
## Definition
|
||||
|
||||
RAG (Retrieval Augmented Generation) ist ein KI-Architekturmuster, bei dem ein großes Sprachmodell (LLM) relevante Informationen aus einer Knowledge Base abruft, bevor es eine Antwort generiert. Dies ermöglicht dem LLM, Antworten bereitzustellen, die in externen Dokumenten verankert sind, anstatt sich ausschließlich auf seine Trainingsdaten zu verlassen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Wie RAG funktioniert
|
||||
|
||||
1. **Indexierung**: Dokumente werden verarbeitet und für die Suche indexiert
|
||||
2. **Abruf**: Bei jeder Abfrage werden relevante Chunks aus dem Index abgerufen
|
||||
3. **Augmentation**: Abgerufene Chunks werden zum LLM-Kontext/Prompt hinzugefügt
|
||||
4. **Generierung**: LLM generiert eine Antwort basierend auf seinem Wissen und den abgerufenen Chunks
|
||||
|
||||
### Traditionelle RAG-Systeme
|
||||
|
||||
Beispiele sind:
|
||||
- [[NotebookLM]] (Google)
|
||||
- [[ChatGPT]] Datei-Uploads (OpenAI)
|
||||
- Die meisten kommerziellen RAG-Implementierungen
|
||||
|
||||
### Begrenzungen von traditionellem RAG
|
||||
|
||||
Laut dem [[LLM Wiki Pattern]]-Artikel:
|
||||
|
||||
1. **Keine Knowledge Accumulation**: Wissen wird bei jeder Abfrage von Grund auf neu abgeleitet
|
||||
2. **Keine persistente Synthese**: Verbindungen zwischen Dokumenten werden nicht aufrechterhalten
|
||||
3. **Keine Querverweise**: Keine expliziten Links zwischen verwandten Konzepten über Quellen hinweg
|
||||
4. **Keine Widerspruchserkennung**: Konfliktinformationen werden nicht gekennzeichnet
|
||||
5. **Kein Compounding**: Das Hinzufügen neuer Quellen baut nicht auf vorherigem Verständnis auf
|
||||
6. **Ineffizient für komplexe Abfragen**: Subtile Fragen, die eine Synthese mehrerer Dokumente erfordern, müssen jedes Mal neu abgeleitet werden
|
||||
|
||||
### Wann RAG geeignet ist
|
||||
|
||||
- Bei einfachen, einmaligen Fragen
|
||||
- Für schnelle Informationssuche
|
||||
- Wenn Persistenz und Compounding nicht erforderlich sind
|
||||
- Wenn der Aufwand für Wiki-Wartung nicht gerechtfertigt ist
|
||||
|
||||
### Wann über RAG hinausgehen
|
||||
|
||||
Das [[LLM Wiki Pattern]] in Betracht ziehen, wenn:
|
||||
- Wissen im Laufe der Zeit angesammelt werden soll
|
||||
- Persistente Querverweise benötigt werden
|
||||
- Widersprüche zwischen Quellen gekennzeichnet werden sollen
|
||||
- Wissen benötigt wird, das zusammengesetzt wird, wenn neue Quellen hinzugefügt werden
|
||||
- Komplexe Abfragen, die Multi-Dokument-Synthese erfordern, häufig vorkommen
|
||||
|
||||
## RAG vs. LLM-Wiki-Pattern
|
||||
|
||||
| Aspekt | RAG | LLM-Wiki-Pattern |
|
||||
|--------|-----|-------------------|
|
||||
| Knowledge Accumulation | Nein | Ja |
|
||||
| Persistente Querverweise | Nein | Ja |
|
||||
| Widerspruchserkennung | Nein | Ja |
|
||||
| Knowledge Compounding | Nein | Ja |
|
||||
| Wartung | Automatisch | LLM-gepflegt |
|
||||
| Abfrage-Geschwindigkeit | Schnell | Schnell (nach Kompilierung) |
|
||||
| Setup-Komplexität | Niedrig | Mittel |
|
||||
| Am besten für | Einmalige Abfragen | Laufende Knowledge Accumulation |
|
||||
|
||||
## Implementierungen
|
||||
|
||||
### RAG-Varianten
|
||||
- Naive RAG: Einfache Ähnlichkeitssuche
|
||||
- Vector RAG: Embedding-basierter Abruf
|
||||
- Hybrid RAG: Kombiniert Schlüsselwort- und Vector-Suche
|
||||
- Graph RAG: Verwendet Knowledge Graphs für Abruf
|
||||
|
||||
### LLM-Wiki-Pattern als verbessertes RAG
|
||||
Das [[LLM Wiki Pattern]] kann als eine Verbesserung zu RAG angesehen werden, die hinzufügt:
|
||||
- Persistenz-Schicht (das Wiki)
|
||||
- Automatische Querverweise
|
||||
- Widerspruchserkennung
|
||||
- Knowledge Compounding
|
||||
- Menschliche Kuratierung in der Schleife
|
||||
|
||||
## Tools, die RAG verwenden
|
||||
|
||||
- [[NotebookLM]]
|
||||
- [[ChatGPT]] (mit Datei-Uploads)
|
||||
- Viele unternehmensweite Knowledge-Management-Systeme
|
||||
- Verschiedene Open-Source-RAG-Frameworks (LangChain, LlamaIndex, etc.)
|
||||
|
||||
## Geschichte
|
||||
|
||||
- [2020] - Frühe RAG-Papers und -Implementierungen
|
||||
- [2023] - Kommerzielle RAG-Systeme entstehen (NotebookLM, ChatGPT Datei-Uploads)
|
||||
- [2023-2024] - LLM-Wiki-Pattern entwickelt als Verbesserung zu RAG
|
||||
- [2026-07-26] - Konzeptseite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[NotebookLM]]
|
||||
- [[ChatGPT]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Verfahren, das Ergebnislisten mehrerer Suchmodalitäten zu einem gemeinsamen Ranking verbindet, ohne Gewichte zwischen den Modalitäten justieren zu müssen.
|
||||
---
|
||||
# Reciprocal Rank Fusion
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Verschmelzt Ergebnisse von BM25 (Schlüsselwort), Vector (semantisch) und Graph (strukturell) Suchen, um ein besseres Gesamtranking zu erreichen, als jeder einzelne Ansatz allein.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,190 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: protocol
|
||||
tags: [storage, ssd, performance, optimization, linux]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Disk Encryption, LVM, Arch Linux]
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: Datenträgerbefehl, mit dem SSDs ungenutzte Blöcke zurückgewinnen - für gleichbleibende Leistung und längere Lebensdauer.
|
||||
---
|
||||
# SSD TRIM
|
||||
|
||||
**Typ:** protocol
|
||||
|
||||
## Definition
|
||||
|
||||
TRIM (oder Discard) ist ein Befehl, der einem Betriebssystem ermöglicht, eine Solid-State Drive (SSD) darüber zu informieren, welche Datenblöcke nicht mehr in Gebrauch sind und intern gelöscht werden können. Dies ist entscheidend für die Erhaltung der SSD-Leistung und Lebensdauer, da es der Garbage Collection der SSD ermöglicht, ungenutzte Blöcke freizugeben.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Zweck:** Erhaltung der SSD-Leistung und Verlängerung der Lebensdauer
|
||||
- **Mechanismus:** OS benachrichtigt SSD über ungenutzte Blöcke
|
||||
- **Vorteil:** Verhindert Schreibverstärkung und Leistungsabbau
|
||||
- **Protokoll:** Teil des ATA- und SCSI-Befehlssatzes
|
||||
|
||||
## Wie TRIM funktioniert
|
||||
|
||||
### Ohne TRIM
|
||||
1. SSD schreibt Daten in einen Block
|
||||
2. Block wird „belegt"
|
||||
3. Datei wird vom OS gelöscht
|
||||
4. OS markiert Block als „frei", aber SSD weiß das nicht
|
||||
5. Nächster Schreibvorgang erfordert: alte Daten lesen → ändern → löschen → neue Daten schreiben
|
||||
6. Leistung verschlechtert sich im Laufe der Zeit
|
||||
|
||||
### Mit TRIM
|
||||
1. SSD schreibt Daten in einen Block
|
||||
2. Block wird „belegt"
|
||||
3. Datei wird vom OS gelöscht
|
||||
4. **OS sendet TRIM-Befehl:** „Block X wird nicht mehr verwendet"
|
||||
5. SSD markiert Block intern als „veraltet"
|
||||
6. Nächster Schreibvorgang: SSD kann direkt in vorgelöschten Block schreiben
|
||||
7. Leistung bleibt konsistent
|
||||
|
||||
## TRIM unter Linux aktivieren
|
||||
|
||||
### TRIM-Unterstützung überprüfen
|
||||
|
||||
```bash
|
||||
# Check if SSD supports TRIM
|
||||
lsblk -D | grep -i discard
|
||||
|
||||
# Check if filesystem supports TRIM
|
||||
lsblk -f | grep -i discard
|
||||
```
|
||||
|
||||
### Manuelles TRIM
|
||||
|
||||
```bash
|
||||
# Run TRIM manually on a mount point
|
||||
fstrim /mount/point
|
||||
|
||||
# Run TRIM on all mounted filesystems
|
||||
fstrim -a
|
||||
|
||||
# Verbose output
|
||||
fstrim -v /mount/point
|
||||
```
|
||||
|
||||
### Automatisches TRIM
|
||||
|
||||
**systemd-Timer (empfohlen):**
|
||||
```bash
|
||||
# Enable weekly TRIM timer
|
||||
systemctl enable fstrim.timer
|
||||
systemctl start fstrim.timer
|
||||
|
||||
# Check status
|
||||
systemctl status fstrim.timer
|
||||
|
||||
# Manual trigger
|
||||
systemctl start fstrim.service
|
||||
```
|
||||
|
||||
**Cron-Job (Alternative):**
|
||||
```bash
|
||||
# Add to root's crontab
|
||||
0 3 * * 0 fstrim -a
|
||||
```
|
||||
|
||||
## TRIM mit Verschlüsselung
|
||||
|
||||
Beim Einsatz von Laufwerksverschlüsselung (dm-crypt/LUKS) erfordert TRIM-Unterstützung besondere Aufmerksamkeit wegen Sicherheitsauswirkungen.
|
||||
|
||||
### Sicherheitsaspekte
|
||||
|
||||
**Warnung:** Das Zulassen von Discard (TRIM) auf verschlüsselten Geräten kann Informationen offenlegen über:
|
||||
- Welche Blöcke in Gebrauch sind
|
||||
- Dateisystem-Nutzungsmuster
|
||||
- Potenziell vertrauliche Metadaten
|
||||
|
||||
### Optionen für verschlüsselte SSDs
|
||||
|
||||
#### Option 1: Discard auf LUKS-Ebene zulassen
|
||||
```bash
|
||||
# For new encryption
|
||||
cryptsetup luksFormat --allow-discards /dev/sdX
|
||||
|
||||
# For existing encryption (requires reencryption)
|
||||
cryptsetup reencrypt --encrypt --reduce-device-size 16M --allow-discards /dev/sdX
|
||||
```
|
||||
|
||||
#### Option 2: Periodisches fstrim (Empfohlen für Sicherheit)
|
||||
```bash
|
||||
# Disable discard in crypttab
|
||||
# /dev/sdX1 /mnt/crypt ext4 defaults 0 2
|
||||
|
||||
# Manually run fstrim after unlocking
|
||||
fstrim /mnt/crypt
|
||||
|
||||
# Or use systemd timer (runs after boot)
|
||||
systemctl enable fstrim.timer
|
||||
```
|
||||
|
||||
#### Option 3: Hybrid-Ansatz
|
||||
- Discard für unverschlüsselte Metadatenbereiche zulassen
|
||||
- Periodisches fstrim für Datenbereiche verwenden
|
||||
|
||||
**Referenz:** https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
|
||||
|
||||
## TRIM-Status überprüfen
|
||||
|
||||
```bash
|
||||
# Check if discard is enabled for device
|
||||
lsblk -D /dev/sdX
|
||||
|
||||
# Check mount options
|
||||
mount | grep discard
|
||||
|
||||
# Check filesystem support
|
||||
lsblk -o NAME,FSTYPE,DISC-GRAN,DISC-MAX
|
||||
```
|
||||
|
||||
## Dateisystem-Unterstützung
|
||||
|
||||
| Dateisystem | TRIM-Unterstützung | Hinweise |
|
||||
|------------|---------------|-------|
|
||||
| ext4 | Ja | Standard in modernen Kerneln |
|
||||
| XFS | Ja | Online-Discard unterstützt |
|
||||
| Btrfs | Ja | Subvolume-fähig |
|
||||
| NTFS | Ja | Via ntfs-3g |
|
||||
| FAT32 | Nein | Keine TRIM-Unterstützung |
|
||||
|
||||
## Leistungsauswirkung
|
||||
|
||||
- **Ohne TRIM:** Leistung kann sich nach längerer Verwendung um 30-50 % verschlechtern
|
||||
- **Mit TRIM:** Leistung bleibt nah bei Neu-Niveau
|
||||
- **Overhead:** TRIM-Befehle verursachen minimalen Overhead (~1-2%)
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- **Immer:** Auf SSD-Speichergeräten
|
||||
- **Empfohlen:** Auf NVMe-Laufwerken (TRIM ist noch kritischer)
|
||||
- **Erwägen:** Auf Hybrid-SSHD-Laufwerken
|
||||
- **Nicht nötig:** Auf HDD (rotierenden) Laufwerken
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Auf HDD (rotierenden) Laufwerken - kein Nutzen
|
||||
- In hochsicheren Umgebungen, in denen Informationsverlust inakzeptabel ist (Kompromisse erwägen)
|
||||
- Auf Dateisystemen, die TRIM nicht unterstützen
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[Disk Encryption]] (dm-crypt/LUKS)
|
||||
- **Ergänzt:** [[LVM]] (Logical Volume Manager)
|
||||
- **Läuft auf:** [[Arch Linux]] und anderen Distributionen
|
||||
- **Wirkt sich aus auf:** Speicherleistung SSD-gestützter Systeme
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Disk Encryption]]
|
||||
- [[LVM]]
|
||||
- [[Arch Linux]]
|
||||
- [[Source - Arch Linux Cheat Sheet]]
|
||||
- https://wiki.archlinux.org/title/Solid_State_Drives
|
||||
- https://wiki.archlinux.org/title/Dm-crypt/Specialties#Discard/TRIM_support_for_solid_state_drives_(SSD)
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [scale, limitations]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Punkt, ab dem Wiki-Ansätze mit einem einzigen Kontext qualitativ abfallen
|
||||
---
|
||||
# Scale Ceiling
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Scale Ceiling ist der Punkt, an dem Single-Context-Wiki-Ansätze (eine große Anweisungsdatei, vollständiger Index wird jede Sitzung neu gelesen) an Qualität degradieren, typischerweise sobald ein Wiki etwa 100-200 Seiten überschreitet[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Qualitätsverschlechterung**: Mit wachsendem Wiki verlieren LLMs Verbindungen und die Qualität sinkt mit Single-Context-Ansätzen[^s-copilot-skill-restructure-instructions]
|
||||
- **Schwellenwert**: Evidenz deutet darauf hin, dass die Verschlechterung um die 100-200 Seiten beginnt[^s-copilot-skill-restructure-instructions]
|
||||
- **Symptom**: Das LLM verliert Verbindungen zwischen verwandten Informationen
|
||||
- **Lösung**: Zu kontextisoliert, Skill-basierten Ansätzen übergehen
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Dokumentierter Fall: RTFM/Retrieval-Layer-Ansatz bei einem 8.260-Datei-Corpus erreichte 100% Erfolgsquote (von ~55-64%) durch Bereitstellung von Metadaten zuerst und Erweiterung nur das Notwendige[^s-copilot-skill-restructure-instructions]
|
||||
- Das Chemenu-Repository nähert sich dem Scale Ceiling mit monolithischer AGENTS.md[^s-copilot-skill-restructure-instructions]
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Scale Ceiling beachten, wenn:
|
||||
- Das Wiki sich 100 Seiten nähert oder überschreitet
|
||||
- Das LLM Verbindungen zwischen verwandtem Inhalt vermisst
|
||||
- Die Abfragequalität inkonsistent oder verschlechtert ist
|
||||
- Für langfristiges Wiki-Wachstum geplant wird
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Scale Ceiling ist kein Problem wenn:
|
||||
- Das Wiki klein ist und klein bleiben soll
|
||||
- Retrieval-Augmented-Ansätze genutzt werden, die alles in den Kontext laden vermeiden
|
||||
- Die Workflows kein Verständnis von Verbindungen über das gesamte Wiki erfordern
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Token Economics]]
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Context Isolation]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Confidence Scoring, Quality and Self-Correction, Source - LLM Wiki v2, Supersession, Detect-Repair Asymmetry, Command Round-Trip Integrity]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: "Automatisches Beheben von M\xE4ngeln, die beim Lint auffallen: verwaiste Seiten, veraltete Aussagen, kaputte Links und Formatverst\xF6\xDFe."
|
||||
---
|
||||
# Self-Healing
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Ausgelöst durch geplante Wartung oder Speicherschreib-Events, verwandelt Self-Healing Probleme, die von lint gefunden werden, in automatische Korrektionen, um die Wiki-Gesundheit ohne manuelle Eingriffe zu erhalten.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
|
||||
- **folgt aus:** [[Command Round-Trip Integrity]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Command Round-Trip Integrity]]
|
||||
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [heuristics, stale-claims, change-density, weak-linking]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [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)
|
||||
- [[wikitool]] (implementiert strukturelles Linting, könnte semantische Heuristiken hinzufügen)
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **implementiert von:** [[wikitool]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[wikitool]]
|
||||
- [[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]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Langlebige Schicht für sitzungsübergreifend verdichtete Fakten aus mehreren Episoden, mit höherer Konfidenz und stärkerer Verdichtung als episodische Erinnerungen.
|
||||
---
|
||||
# Semantic Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Ergebnisse der Konsolidierung wiederholter Beobachtungen über Sitzungen hinweg; verwendet um das Reasoning zu unterstützen und dient als Grundlage für die Muster-Extraktion in prozeduralem Gedächtnis.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [preflight, context, query, update]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [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
|
||||
|
||||
- **würde implementiert von:** [[wikitool]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[wikitool]]
|
||||
- [[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]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Multi-Agent Collaboration]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Abgrenzung persönlicher Beobachtungen (privat) von Team- und Projektwissen (geteilt), mit Regeln zum Hochstufen geprüften Wissens.
|
||||
---
|
||||
# Shared vs Private
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Startet als private Beobachtung; wird zu Shared befördert, wenn es über mehrere Agenten hinweg verifiziert oder explizit gekennzeichnet ist, was kollaborative Wikis ermöglicht, ohne all das Wissen öffentlich zu machen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [page-management, refactoring, link-correction, frontmatter]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [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
|
||||
|
||||
- [[wikitool]] (Werkzeug, das diese Befehle implementieren würde)
|
||||
- [[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
|
||||
|
||||
- **würde implementiert durch:** [[wikitool]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[wikitool]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [split, threshold, lines, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Content Quality Control, Stub Threshold, 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
|
||||
|
||||
- [[Content Quality Control]] - Breiteres Framework
|
||||
- [[Stub Threshold]] - Mindestgröße-Ergänzung
|
||||
- [[Index Scaling]] - Verwandte Skalierung für Index-Seiten
|
||||
- [[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]]
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: decision
|
||||
tags: [quality, tooling, tests, governance]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [Ambient Environment Dependency, wikitool, Iteration and Cost Limits, Mass-Update Gate]
|
||||
sources: [Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: sourced
|
||||
summary: Entscheidung, eine wiederkehrende Fehlerregel in die Ausfuehrung einzubauen statt sie aufzuschreiben - Rangfolge erzwingen vor melden vor erinnern, belegt an einer Regel, die gelesen wurde und nicht wirkte
|
||||
---
|
||||
# Structural Enforcement over Documented Rule
|
||||
|
||||
**Typ:** Decision
|
||||
|
||||
## Definition
|
||||
|
||||
Wo ein Fehler sich wiederholt, wird die Regel dagegen **in die Ausführung eingebaut**, statt sie
|
||||
aufzuschreiben. Eine aufgeschriebene Regel wirkt nur, solange jemand sie liest, sie im richtigen
|
||||
Moment erinnert und sie befolgt; eine strukturell durchgesetzte Regel macht den Fehler
|
||||
unschreibbar oder bricht sichtbar ab.
|
||||
|
||||
Die Entscheidung ist nicht "Dokumentation ist wertlos". Sie ist eine Rangordnung für den Fall,
|
||||
dass beides möglich wäre: **erst erzwingen, dann dokumentieren, warum erzwungen wird.** Die
|
||||
Dokumentation erklärt die Regel und ihre Ausnahmen; sie trägt aber nicht die Durchsetzung.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Der harte Beleg: eine gelesene Regel hat den Fehler nicht verhindert.** Bei Gitea-Issue #8
|
||||
führten zwei neue Tests dieselbe Umgebungsabhängigkeit erneut ein - geschrieben von jemandem,
|
||||
der das Issue vorher gelesen hatte[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Das ist kein Sorgfaltsmangel, sondern die Aussage über die
|
||||
Wirksamkeit von Prosa in diesem Fall: sie wurde gelesen und wirkte nicht.
|
||||
- **Der Stack wendet dasselbe Prinzip schon an anderer Stelle an.** Die Gates sind bewusst im
|
||||
Code durchgesetzt und nicht als Anweisung formuliert - ein Prompt-Limit ist eines, an dem ein
|
||||
Agent sich vorbeireden kann. Siehe [[Iteration and Cost Limits]] und [[Mass-Update Gate]].
|
||||
Die Fixture-Entscheidung ist derselbe Grundsatz, angewandt auf die Testsuite.
|
||||
- **Erzwingen schlägt Melden, und beides schlägt Erinnern.** Rangfolge: (1) den Fehler unmöglich
|
||||
machen, (2) ihn beim Auftreten sichtbar abbrechen lassen, (3) ihn dokumentieren. Bei #8 war
|
||||
Option 1 die Fixture (die Abhängigkeit kann nicht mehr entstehen), Option 2 der zweite
|
||||
CI-Schritt (meldet nach dem Push), Option 3 der Satz im Issue - der bereits gescheitert war.
|
||||
- **Ein Guard, der erst nach dem Push meldet, schützt nicht dort, wo die Fehler entstehen.** Der
|
||||
verworfene zweite CI-Job hätte den Lauf des Entwicklers nie berührt. Geschrieben werden die
|
||||
Fälle aber genau dort.
|
||||
- **Ein Guard darf nicht auf einer zufälligen Eigenschaft seiner Umgebung beruhen.** Der
|
||||
CI-Container galt als "Maschine ohne globale git-Konfiguration"; seit `actions/checkout@v7`
|
||||
legt der Checkout selbst eine an[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Ein Guard mit dieser Voraussetzung hätte still aufgehört zu
|
||||
greifen, ohne roten Lauf. Die strukturelle Variante hängt an nichts dergleichen.
|
||||
- **Die Entscheidung wird begründet dort hinterlegt, wo jemand sie rückgängig machen würde.** Der
|
||||
Kommentar am CI-Tests-Schritt hält fest, warum es beim einen Lauf bleibt - sonst rüstet
|
||||
irgendwann jemand den zweiten aus dem alten Grund nach. Das ist die Rolle, die der
|
||||
Dokumentation bleibt: nicht die Regel tragen, sondern ihre Aufhebung teuer machen.
|
||||
- **Das Prinzip gilt rekursiv, und dort liegt seine offene Flanke.** Die Fixture aus `1.7.1`
|
||||
pflegt ihre Variablenliste von Hand, und die Pflicht zum Nachtragen steht - in Prosa. Das ist
|
||||
exakt dasselbe Muster eine Ebene höher und als Gitea-Issue #23 offen[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]. Wer dieses Concept
|
||||
anwendet, sollte prüfen, ob sein Guard selbst nur durch eine Regel zusammengehalten wird.
|
||||
- **Der Preis ist Aufwand vor dem Nutzen.** Erzwingen kostet Code, Tests für den Guard und einen
|
||||
Nachweis, dass er greift. Aufschreiben kostet einen Absatz. Der Tausch lohnt sich, wenn der
|
||||
Fehler wiederkehrt oder sein Schaden still ist - nicht bei jedem Einzelfall.
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - die autouse-Fixture aus `1.7.1`, die die Umgebungsabhängigkeit unschreibbar
|
||||
macht, statt in `instructions/dev/testing-conventions.md` davor zu warnen
|
||||
- [[Iteration and Cost Limits]] - 60 Aufrufe je Session und der Loop-Breaker, im Code
|
||||
durchgesetzt statt als Anweisung formuliert
|
||||
- [[Mass-Update Gate]] - Exit 42 mit Freigabe-Token statt der Bitte, vorsichtig zu sein
|
||||
- [[AGENTS.md]] - Invariante 8 ("eine Regel, ein Ort") ist die dokumentarische Hälfte desselben
|
||||
Anliegens: eine Regel kann nur erzwungen werden, wenn sie genau eine Fassung hat
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Ein Fehler ist zum zweiten Mal aufgetreten, besonders wenn der Verursacher die Regel dagegen
|
||||
kannte.
|
||||
- Der Fehler ist beim Entstehen unsichtbar und wird erst später und woanders sichtbar.
|
||||
- Die Regel wäre in einem Dokument abgelegt, das im entscheidenden Moment niemand offen hat.
|
||||
- Es gibt eine mechanische Prüfung, die den Fehler eindeutig erkennt - ohne die bleibt nur die
|
||||
Dokumentation.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Urteilsfragen. Was auf eine Seite gehört, welcher Ton angemessen ist, ob ein Befund eine
|
||||
eigene Seite verdient - dafür gibt es keine mechanische Prüfung, und eine erzwungene Näherung
|
||||
wäre schlechter als eine gute Anleitung.
|
||||
- Für Einzelfälle ohne Wiederholungsrisiko. Ein Guard, der nie greift, ist Code, der gewartet
|
||||
werden muss und nichts trägt.
|
||||
- Wenn die Durchsetzung mehr Fehlalarme produziert als Funde. Ein Guard, dessen Meldungen man
|
||||
gewohnheitsmäßig überliest, hat den Schutz bereits verloren und kostet weiter.
|
||||
- Als Ersatz für die Begründung. Ein erzwungener Check ohne erklärenden Kommentar wird beim
|
||||
ersten Widerstand entfernt.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Ambient Environment Dependency]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Mass-Update Gate]]
|
||||
- [[Green Suite Blind Spot]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Gegenmittel zu:** [[Ambient Environment Dependency]]
|
||||
- **angewandt in:** [[Iteration and Cost Limits]]
|
||||
- **angewandt in:** [[Mass-Update Gate]]
|
||||
- **umgesetzt in:** [[wikitool]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[Ambient Environment Dependency]]
|
||||
- [[wikitool]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Mass-Update Gate]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-hardening-the-test-suite-against-silent-environment-dependencies-session-2026-08-31]: [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [stub, minimum, quality, lines]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Content Quality Control, Split Threshold, 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
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Content Quality Control]] - Das breitere Framework, das Stub-Schwellenwerte enthält
|
||||
- [[Split Threshold]] - Die obere Grenze-Ergänzung zu Stub-Schwellenwert
|
||||
- [[Semantic Lint Automation]] - Könnte Stub-Erkennung einbinden
|
||||
|
||||
## 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]]
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [versioning, knowledge, updates, lifecycle]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memory Lifecycle, Confidence Scoring, Knowledge Graph, 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
|
||||
|
||||
- [[Memory Lifecycle]] - Übergeordnetes Concept
|
||||
- [[Confidence Scoring]] - Bestimmt welche Aussage in Widerspruch gewinnt
|
||||
- [[Contradiction Resolution]] - Der Entscheidungsprozess für Supersession
|
||||
- [[Knowledge Graph]] - Struktur zur Verfolgung von Supersession-Beziehungen
|
||||
- [[LLM Wiki Pattern]] - Gesamtes Pattern
|
||||
|
||||
## 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)
|
||||
@@ -0,0 +1,266 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [llm-wiki, layers, structure]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, RAG, Memory Lifecycle, Knowledge Graph]
|
||||
sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: "Strukturmodell des LLM-Wiki-Musters mit drei Schichten: unver\xE4nderliche Rohquellen, vom LLM gepflegtes Wiki und Schemakonfiguration, die Knowledge Compounding tr\xE4gt."
|
||||
---
|
||||
# Three-Layer Architecture
|
||||
|
||||
**Typ:** Architecture (Foundation of LLM Wiki Pattern)
|
||||
|
||||
## Definition
|
||||
|
||||
Die Three-Layer Architecture ist die strukturelle Grundlage des [[LLM Wiki Pattern]], bestehend aus drei unterschiedlichen Schichten: Rohquellen, Das Wiki und Das Schema. Jede Schicht hat eine spezifische Rolle und behält Separation of Concerns bei um die Wissens-Kompoundierungs-Effekte des Patterns zu ermöglichen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
### Schicht 1: Rohquellen
|
||||
|
||||
**Zweck:** Unveränderliche Quelle der Wahrheit
|
||||
|
||||
**Merkmale:**
|
||||
- Kuratierte Sammlung von Quelldokumenten
|
||||
- Read-only aus der Perspektive des LLM
|
||||
- Enthält: Artikel, Papiere, Bilder, Datendateien, Notizen, Spezifikationen
|
||||
- **Niemals verändert** durch das LLM
|
||||
- Human-verwaltet: Benutzer fügt Quellen hinzu und organisiert sie
|
||||
|
||||
**Verzeichnis:** `raw/`
|
||||
|
||||
**Unterverzeichnisse:**
|
||||
- `raw/articles/` — Web-Artikel, Blog-Beiträge
|
||||
- `raw/documents/` — PDFs, Spezifikationen, Handbücher
|
||||
- `raw/notes/` — Persönliche Notizen, Besprechungstranskriptionen
|
||||
- `raw/assets/` — Bilder, Diagramme, Binärdateien
|
||||
|
||||
**Begründung:**
|
||||
- Erhält Originalmaterial der Quelle
|
||||
- Stellt Audit-Trail zurück zu primären Quellen bereit
|
||||
- Ermöglicht Neuverarbeitung, wenn nötig
|
||||
- Benutzer behält Kontrolle über Quellenauswahl
|
||||
|
||||
---
|
||||
|
||||
### Schicht 2: Das Wiki
|
||||
|
||||
**Zweck:** LLM-gepflegte Wissens-Synthese
|
||||
|
||||
**Merkmale:**
|
||||
- Verzeichnis von LLM-generierten Markdown-Dateien
|
||||
- **Vollständig besessen und gepflegt durch das LLM**
|
||||
- Human liest es; LLM schreibt es
|
||||
- Enthält: Zusammenfassungen, Entity-Seiten, Concept-Seiten, Vergleiche, Index, Log
|
||||
- Dynamisch aktualisiert, während neue Quellen ingested werden
|
||||
|
||||
**Verzeichnis:** `kb/`
|
||||
|
||||
**Collections:** Ein Verzeichnis unter `kb/` ist eine Collection genau dann, wenn es eine
|
||||
`COLLECTION.md` trägt; ein Unterverzeichnis darin ist ein Bereich, der sie erbt.
|
||||
|
||||
- `kb/entities/` — Entity-Seiten (Projekte, Systeme, Tools, Technologien, Personen)
|
||||
- `kb/concepts/` — Concept-Seiten (Architekturen, Patterns, Protokolle, Workflows)
|
||||
- `kb/sources/` — Zusammenfassungen von ingested Quellen
|
||||
- `kb/comparisons/` — Vergleichstabellen und Analysen
|
||||
- `kb/CONTRACT.md` — Regeln, die von jeder Collection geteilt werden
|
||||
- `kb/index.md` — Katalog aller Seiten
|
||||
- `kb/log.md` — Chronologisches Audit-Log
|
||||
|
||||
In diesem Repository wurde die Wiki-Schicht am 2026-08-21 von `wiki/` zu `kb/` umbenannt, wenn jedes
|
||||
seiner Unterverzeichnisse zu einer First-Class-Collection mit eigenem Contract befördert wurde. Eine vierte
|
||||
Phase, `reports/`, hält generierten Lint-Output außerhalb des Knowledge-Baums und ist gitignoriert.
|
||||
|
||||
**Seitentypen:**
|
||||
- **Source-Seiten**: Zusammenfassungen mit Metadaten, Kernpunkte, Aufgaben
|
||||
- **Entity-Seiten**: Strukturierte Informationen über spezifische Elemente
|
||||
- **Concept-Seiten**: Definitionen, Beispiele, wann zu verwenden
|
||||
- **Vergleichs-Seiten**: Nebeneinander-Analyse
|
||||
- **Index**: Content-oriented Katalog
|
||||
- **Log**: Chronologischer Betriebsdatensatz
|
||||
|
||||
**Begründung:**
|
||||
- Trennt synthetisiertes Wissen von Rohquellen
|
||||
- Ermöglicht Querverweise und Verbindungen
|
||||
- Erlaubt LLM Konsistenz zu wahren
|
||||
- Bietet Mensch-lesbare Struktur
|
||||
|
||||
---
|
||||
|
||||
### Schicht 3: Das Schema
|
||||
|
||||
**Zweck:** Konfiguration und Betriebsanweisungen für das LLM
|
||||
|
||||
**Merkmale:**
|
||||
- Definiert wie das Wiki strukturiert ist
|
||||
- Dokumentiert Konventionen und Seitenformate
|
||||
- Spezifiziert Workflows (Ingest, Abfrage, Lint)
|
||||
- **Co-entwickelt** durch Mensch und LLM über Zeit
|
||||
- Normalerweise eine einzelne Konfigurationsdatei
|
||||
|
||||
**Datei:** `AGENTS.md` (oder `CLAUDE.md` für Claude Code)
|
||||
|
||||
**Inhalt:**
|
||||
- Verzeichnis-Struktur-Definitionen
|
||||
- Seitenformat-Templates
|
||||
- Workflow-Beschreibungen
|
||||
- Namenskonventionen
|
||||
- Qualitätsstandards
|
||||
- Wartungsplanung
|
||||
- Benutzereinstellungen
|
||||
|
||||
**Begründung:**
|
||||
- Macht LLM zu disziplinertem Wiki-Verwalter statt generischem Chatbot
|
||||
- Mensch und LLM arbeiten zusammen bei Schema-Entwicklung
|
||||
- Stellt Konsistenz über Sessions sicher
|
||||
- Dokumentiert das System für zukünftige Referenz
|
||||
|
||||
---
|
||||
|
||||
## Architekturdiagramm
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ THREE-LAYER ARCHITECTURE │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌─────────────────┐ ┌─────────────────┐ ┌───────────┐ │
|
||||
│ │ LAYER 1: │ │ LAYER 2: │ │ LAYER 3: │ │
|
||||
│ │ Raw Sources │───▶│ The Wiki │◀───│ The │ │
|
||||
│ │ │ │ │ │ Schema │ │
|
||||
│ │ - Immutable │ │ - LLM-maintained│ │ │ │
|
||||
│ │ - Human-curated│ │ - Dynamic │ │ - Config │ │
|
||||
│ │ - Source truth │ │ - Synthesized │ │ - Workflows││
|
||||
│ └─────────────────┘ └─────────────────┘ └───────────┘ │
|
||||
│ │
|
||||
│ User ↔ AGENTS.md (Layer 3) ↔ LLM ↔ Wiki (Layer 2) ← Raw (Layer 1)│
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Datenfluss
|
||||
|
||||
### Ingest-Ablauf
|
||||
```
|
||||
User adds file to raw/
|
||||
↓
|
||||
LLM reads source (Layer 1)
|
||||
↓
|
||||
LLM follows AGENTS.md instructions (Layer 3)
|
||||
↓
|
||||
LLM creates/updates pages in kb/ (Layer 2)
|
||||
↓
|
||||
LLM updates index.md and log.md
|
||||
```
|
||||
|
||||
### Abfrage-Ablauf
|
||||
```
|
||||
User asks question
|
||||
↓
|
||||
LLM reads index.md (Layer 2) to find relevant pages
|
||||
↓
|
||||
LLM reads relevant wiki pages (Layer 2)
|
||||
↓
|
||||
LLM follows cross-references
|
||||
↓
|
||||
LLM synthesizes answer with citations
|
||||
↓
|
||||
Valuable answers filed back into kb/ (Layer 2)
|
||||
```
|
||||
|
||||
## Vorteile dieser Architektur
|
||||
|
||||
### Separation of Concerns
|
||||
- **Rohquellen**: Human-Verantwortung (Kurationen, Organisation)
|
||||
- **Das Wiki**: LLM-Verantwortung (Wartung, Querverweise)
|
||||
- **Das Schema**: Gemeinsame Verantwortung (Entwicklung, Verfeinerung)
|
||||
|
||||
### Ermöglicht Wissens-Compounding
|
||||
- Rohquellen bleiben stabil für Neuverarbeitung
|
||||
- Wiki wächst und verbindet sich ohne Quellen zu ändern
|
||||
- Schema verbessert sich, wenn Mensch und LLM lernen, was funktioniert
|
||||
|
||||
### Wartbarkeit
|
||||
- Klare Grenzen zwischen Schichten
|
||||
- Jede Schicht kann sich unabhängig entwickeln
|
||||
- Einfach zu debuggen und zu verstehen
|
||||
|
||||
### Flexibilität
|
||||
- Funktioniert mit jedem LLM-Agent (Claude, Codex, etc.)
|
||||
- Anpassbar an verschiedene Domänen
|
||||
- Modulare Komponenten können ausgetauscht werden
|
||||
|
||||
## Vergleich mit anderen Architekturen
|
||||
|
||||
| Feature | Three-Layer | Traditional RAG | Simple Wiki | Database |
|
||||
|---------|-------------|----------------|-------------|----------|
|
||||
| Persistenz | Ja | Nein | Ja | Ja |
|
||||
| Automatisierung | LLM | LLM | Manuell | Manuell |
|
||||
| Querverweise | Automatisch | Nein | Manuell | Manuell |
|
||||
| Quellen-Trennung | Ja | Teilweise | Variiert | Nein |
|
||||
| Skalierbarkeit | Hoch | Mittel | Niedrig | Hoch |
|
||||
|
||||
## Implementierungshinweise
|
||||
|
||||
### Für dieses Wiki
|
||||
- **Schicht 1**: `raw/` Verzeichnis mit Artikeln, Notizen, usw.
|
||||
- **Schicht 2**: `kb/` Verzeichnis mit allen generierten Inhalten
|
||||
- **Schicht 3**: `AGENTS.md` am Repository-Root
|
||||
|
||||
### Anpassung an andere Domänen
|
||||
- Modifiziere Schema (Schicht 3) um Domänen-Konventionen zu erfüllen
|
||||
- Passe Entity/Concept-Typen im Wiki an (Schicht 2)
|
||||
- Quellen-Schicht (Schicht 1) bleibt weitgehend gleich
|
||||
|
||||
## V2-Erweiterungen
|
||||
|
||||
Die ursprüngliche Three-Layer Architecture bleibt die Grundlage. [[Source - LLM Wiki v2]] (siehe [[Source - LLM Wiki v2]]) addiert zusätzliche Schichten und Erweiterungen, die auf dieser Grundlage aufbauen:
|
||||
|
||||
### Zusätzliche Schichten
|
||||
|
||||
**Schicht 4: Knowledge Graph** (Optional)
|
||||
- Strukturierte Darstellung von Entities und Beziehungen
|
||||
- Erweitert Schicht 2 (Das Wiki) mit Maschinen-lesbarer Struktur
|
||||
- Ermöglicht Graph-Traversal-Abfragen
|
||||
- Siehe: [[Knowledge Graph]]
|
||||
|
||||
**Schicht 5: Memory Tiers** (Optional)
|
||||
- Working Memory, Episodic Memory, Semantic Memory, Procedural Memory
|
||||
- Gestaffelte Speicherung mit verschiedenen Aufbewahrung und Zugriffsmuster
|
||||
- Siehe: [[Consolidation Tiers]], [[Memory Lifecycle]]
|
||||
|
||||
### Erweiterte Schichten
|
||||
|
||||
**Erweiterte Schicht 2 (Das Wiki):**
|
||||
- Kann nun Vertrauens-Scores für Fakten enthalten (siehe [[Confidence Scoring]])
|
||||
- Unterstützt Supersession-Beziehungen (siehe [[Supersession]])
|
||||
- Implementiert Vergessen/Aufbewahrung-Kurven (siehe [[Forgetting]])
|
||||
|
||||
**Erweiterte Schicht 3 (Das Schema):**
|
||||
- Kann Hooks und Automatisierungs-Regeln definieren (siehe [[Event-Driven Automation]], [[Hooks]])
|
||||
- Kann Qualitäts-Standards und Scoring spezifizieren (siehe [[Quality and Self-Correction]])
|
||||
- Kann Datenschutz- und Governance-Richtlinien konfigurieren (siehe [[Privacy and Governance]])
|
||||
|
||||
Die Three-Layer Architecture bleibt gültig und ausreichend für viele Anwendungsfälle. Die v2-Erweiterungen sind optionale Verbesserungen, die nach Bedarf übernommen werden können (siehe [[Implementation Spectrum]]).
|
||||
|
||||
## Geschichte
|
||||
|
||||
- [1945] - Vannevar Bushs [[Memex]]-Konzept deutet auf gestaffelte Wissensverwaltung hin
|
||||
- [2023-2024] - LLM Wiki Pattern formalisiert Three-Layer Architecture
|
||||
- [2026-07-26] - Concept-Seite erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- AGENTS.md
|
||||
- [[RAG]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[Memory Lifecycle]]
|
||||
- [[Knowledge Graph]]
|
||||
- [[Implementation Spectrum]]
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: [tokens, cost, efficiency]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.60
|
||||
confidence_base: 0.60
|
||||
provenance: mixed
|
||||
summary: Kosten- und Effizienzüberlegungen zum Tokenverbrauch von LLMs - die genannten Werte 5-8x/61%/100% sind unbestätigt, keine gesicherten Fakten
|
||||
---
|
||||
# Token Economics
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Token Economics bezieht sich auf Kosten- und Effizienzüberlegungen zur Nutzung des LLM-Kontextfensters, insbesondere darauf, wie die Menge der geladenen Anweisungen und des Kontexts Leistung, Kosten und Qualität beeinflusst[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Kostenmultiplikator:** Eine vollständige Aufnahme gegen ein kompiliertes Wiki liest mehr Token als eine Abfrage, weil die Aufnahme viele Seiten berührt, während eine Abfrage normalerweise nur eine Handvoll liest - dies ist grundsätzlich korrekt, aber die spezifische „~5-8x die Quellen-Token-Anzahl"-Zahl aus der Anweisungsmenge, die dieses Konzept einführte, hat **keine auffindbaren Quelle** und sollte nicht als Fakt wiederholt werden[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Abfrage-Effizienz**: Eine Abfrage gegen nur einen Index plus 2-4 Seiten kostet einen Bruchteil der vollständigen Aufnahmekosten[^s-copilot-skill-restructure-instructions]
|
||||
- **Monolithischer Overhead**: Das Laden eines vollständigen Anweisungssatzes (wie AGENTS.md) bei jedem Task zahlt auch für einfache Abfragen den höheren Preis[^s-copilot-skill-restructure-instructions]
|
||||
- **Kontextisolations-Vorteil**: Diskrete Skills, die nur bei Aufruf geladen werden, reduzieren die Token-Nutzung erheblich
|
||||
|
||||
## Allgemeine Hinweise (unbelegt)
|
||||
|
||||
Die „RTFM/Abruf-Schicht"-Statistik unten (61% Token-Reduktion, 100%-Lösungsquote auf einem 8.260-Datei-Korpus) konnte während der Faktenprüfung nicht auf eine auffindbaren Quelle zurückgeführt werden und sollte als illustrativer, unverifizierter Aussage statt als bestätigter Fakt behandelt werden[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- Das Chemenu-Repository mit monolithischem AGENTS.md (ursprünglich ~745 Zeilen), das bei jeder Operation geladen wird - **direkt bestätigt**: 745 Zeilen, gemessen über `grep`, vollständig unabhängig von der Task angehängt, bevor es am 2026-08-04 in 5 Skills aufgeteilt wurde[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- ~~Der RTFM/Abruf-Schicht-Ansatz, der die Token-Nutzung um 61% auf einem 8.260-Datei-Korpus reduzierte~~ **unverifiziert** - keine Quelle für diese Statistik gefunden[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
Token Economics in Betracht ziehen, wenn:
|
||||
- Der Anweisungssatz das Kontextfenster des LLM überschreitet
|
||||
- Sie eine Qualitätsverschlechterung bemerken, wenn das Wiki über ~100-200 Seiten wächst
|
||||
- Einfache Abfragen unverhältnismäßig lange oder kostspielig werden
|
||||
- Sie Zuständigkeiten in diskrete, unabhängig aufrufbare Vorgänge trennen können
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
Token Economics ist weniger entscheidend, wenn:
|
||||
- Das Wiki klein (<100 Seiten) ist und bequem in den Kontext passt
|
||||
- Die Workflows inhärent gekoppelt sind und nicht getrennt werden können
|
||||
- Der Entwicklungsaufwand der Kontextoptimierung die Vorteile übersteigt
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Scale Ceiling]]
|
||||
- [[Context Isolation]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Knowledge Graph, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Verwendung semantisch aussagekräftiger Beziehungstypen (uses, depends-on, contradicts, caused, fixed, supersedes, replaces) statt undifferenzierter Wikilinks.
|
||||
---
|
||||
# Typed Relationships
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Ermöglicht reichhaltigere Knowledge-Graph-Abfragen und besseres strukturelles Verständnis; jede Beziehung trägt semantisches Gewicht, das Ermittlung und Auswirkungsanalyse informiert.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,339 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [linux, administration, security, users, groups]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Arch Linux, AUR, Aura, 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
|
||||
|
||||
- **Verwendet in:** [[Arch Linux]]-Paketentwicklung (Non-Root-Builder-Benutzer)
|
||||
- **Verwendet von:** [[AUR]] und [[Aura]] für Paketverwaltung
|
||||
- **Verwendet mit:** [[makepkg]] in CI/CD-Workflows
|
||||
und andere Systeme
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Arch Linux]]
|
||||
- [[AUR]]
|
||||
- [[Aura]]
|
||||
- [[makepkg]]
|
||||
- [[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/
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Semantische Ähnlichkeitssuche über Embedding-Vektoren, die inhaltlich verwandte Seiten auch ohne exakte Schlüsselwortübereinstimmung findet.
|
||||
---
|
||||
# Vector Search
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Ergänzt BM25 durch die Ermittlung von Seiten zu verwandten Konzepten (z. B. „Container-Plattformen" passt zu Docker, Podman, Kubernetes), ohne dass eine genaue Begriffsüberlappung erforderlich ist.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Multi-Agent Collaboration]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Leichtgewichtige Erfassung von Aufgabenstatus (in Arbeit, blockiert, erledigt, prüfbedürftig) und Zuweisung, um Doppelarbeit bei mehreren Agenten zu vermeiden.
|
||||
---
|
||||
# Work Coordination
|
||||
|
||||
**Typ:** pattern
|
||||
|
||||
## Definition
|
||||
|
||||
Agents fragen den Arbeitsstatus ab, bevor sie Aufgaben starten, und aktualisieren den Status nach Abschluss, was Transparenz bietet, ohne vollständigen Projektmanagement-Overhead einzuführen.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [workflow, extraction, refactoring]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: 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
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Context Isolation]]
|
||||
- [[Token Economics]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: workflow
|
||||
tags: [automation, end-to-end, ingest, lint, update]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [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)
|
||||
- [[wikitool]] (das Tool, das die Orchestrierung implementieren würde)
|
||||
(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
|
||||
|
||||
- **implementiert durch:** [[wikitool]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - LLM Improvements Codex Analysis]]
|
||||
- [[wikitool]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Kurzlebige Speicherschicht für jüngste Beobachtungen und vorläufige Befunde vor der Verdichtung; niedrigste Konfidenz, keine Verdichtung, wird zum Sitzungsende erneuert.
|
||||
---
|
||||
# Working Memory
|
||||
|
||||
**Typ:** architecture
|
||||
|
||||
## Definition
|
||||
|
||||
Die erste Stufe in der Konsolidierungs-Pipeline; speichert Rohbefunde, bevor sie mit umfassenderen Kenntnissen integriert werden, und werden automatisch am Ende der Session zu episodischem Gedächtnis heraufgestuft.
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- TODO
|
||||
|
||||
## Beispiele
|
||||
|
||||
- TODO
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,124 @@
|
||||
---
|
||||
type: types/concept.md
|
||||
concept_type: problem
|
||||
tags: [wikitool, frontmatter, tooling, idempotenz, repair]
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Denylist over Allowlist, Detect-Repair Asymmetry, Diff-Reviewable Agent Edits, Command Round-Trip Integrity]
|
||||
sources: [Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: sourced
|
||||
summary: Defektklasse, in der ein Feld nur beim Anlegen der Seite schreibbar ist und danach unerreichbar bleibt, weil kein Mutationsbefehl es kennt und new nicht idempotent ist
|
||||
---
|
||||
# Write-Once Frontmatter Fields
|
||||
|
||||
**Typ:** Problem
|
||||
|
||||
## Definition
|
||||
|
||||
Ein Write-Once-Feld ist ein Frontmatter-Feld, das der Anlegebefehl schreibt und danach kein
|
||||
Befehl mehr ändern kann. Es entsteht nicht durch eine Regel, sondern durch eine Lücke: das
|
||||
Schema deklariert das Feld, das Gerüst füllt es, und die Mutationsbefehle decken es nicht ab.
|
||||
Der Wert, den der erste Aufruf gesetzt hat, ist damit der endgültige.
|
||||
|
||||
Die drei Auswege, die einem Agenten dann bleiben, schließen sich gegenseitig aus. Handeditierung
|
||||
ist das, was der Stack verhindern soll. Die Seite zu löschen und neu anzulegen zerreißt jede
|
||||
Referenz, die schon auf sie zeigt - Wikilinks, Fußnoten-Zitate und die Referenz-Arrays
|
||||
anderer Seiten hängen am Titel. Und der Anlegebefehl selbst ist nicht idempotent, lässt sich
|
||||
also nicht einfach mit korrigierten Werten wiederholen. Das Fenster für den richtigen Wert ist
|
||||
genau einen Befehl
|
||||
breit[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
|
||||
## Kernpunkte
|
||||
|
||||
- **Die Lücke ist eine Kombination, kein einzelner Defekt.** Erst Schema plus fehlender
|
||||
Mutationsbefehl plus nicht-idempotentes `new` plus Referenzbindung an den Titel machen einen
|
||||
Tippfehler dauerhaft. Jede dieser Eigenschaften für sich ist harmlos.
|
||||
- **Sie trifft die Felder, die keiner Seite und keinem Seitentitel gehören.** `touch` deckte
|
||||
die Felder ab, die die Seite selbst beschreiben (`modified`, `summary`, `provenance`,
|
||||
`confidence_base`), `xref` die Seiten-Referenz-Arrays. `tags:`, `raw_files:` und `source_url:`
|
||||
sind
|
||||
keines von beidem[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
- **Der Beleg, dass es eine Rate ist und kein Unfall:** drei Fehlschläge in drei
|
||||
aufeinanderfolgenden Ingests desselben Tages, an zwei verschiedenen Feldern, von drei
|
||||
verschiedenen Agenten. Einer davon war ein nachgestelltes Komma im `--set
|
||||
tags=`-Wert[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
- **Der Fall, an dem es sichtbar wurde:** [[Diff-Reviewable Agent Edits]] behielt nach einem
|
||||
solchen Ingest dauerhaft nur `[agent-workflow]`. Der zuständige Agent prüfte alle drei
|
||||
Auswege und verwarf jeden mit dem richtigen Grund - genau das Verhalten, das die Regeln
|
||||
verlangen, und genau der Punkt, an dem sie ohne Werkzeug in eine Sackgasse
|
||||
führen[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
- **Geschlossen in Stack `1.4.0` (Commit `dbe2f73`) durch `touch --set/--add/--remove`:**
|
||||
schreibbar ist, was das Schema des Seitentyps deklariert, abzüglich einer kurzen Sperrliste
|
||||
(siehe [[Denylist over Allowlist]]). `--add` und `--remove` arbeiten auf einzelnen Elementen
|
||||
eines Listenfelds, `--remove` gelingt auch bei einem nicht vorhandenen Element und meldet
|
||||
das - idempotent, weil ein Reparaturbefehl, der sich beim zweiten Lauf verweigert, nicht
|
||||
skriptbar ist, aber nie still, weil ein stiller No-op wie eine gelungene Entfernung
|
||||
aussieht[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
- **Die Klasse kehrte am selben Tag an einer anderen Feldgruppe wieder.** `new source --set
|
||||
entities=…` schrieb die Referenz-Arrays einer Source-Seite genau einmal; `xref link-source`
|
||||
fasste sie nicht an, `xref add` lehnte sie ab, und `touch` sperrt sie über seine Denylist.
|
||||
Damit war eine Source-Seite nach dem Anlegen in ihren eigenen `entities:`/`concepts:`
|
||||
unerreichbar - dieselbe Lücke wie bei `tags:`, nur an den Feldern, die eine andere
|
||||
Zuständigkeit haben. Geschlossen mit `1.6.0` (Commit `ce03749`, Gitea-Issue #18), indem
|
||||
`xref link-source` beide Richtungen schreibt[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]
|
||||
- **Abgrenzung zu [[Detect-Repair Asymmetry]]:** Dort meldet ein Check einen Defekt, für den es
|
||||
keinen Reparaturbefehl gibt. Hier gibt es nicht einmal zwingend einen Befund - ein falsches
|
||||
`tags:` fällt keinem Check auf. Der `raw_files:`-Fall gehört zu beiden: er wird gemeldet
|
||||
*und* war nicht reparierbar.
|
||||
- **Der Existenzcheck bleibt am Feld, nicht am Schema.** Ein per `touch` geschriebenes
|
||||
`raw_files:` wird gegen das Dateisystem geprüft wie beim Anlegen. Das ist I/O und keine
|
||||
Datenform, also kann kein Schema es
|
||||
ausdrücken[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31].
|
||||
|
||||
## Beispiele
|
||||
|
||||
- [[wikitool]] - `tags:` und `raw_files:` waren bis `1.4.0` nur beim Anlegen schreibbar
|
||||
(Gitea-Issue #14, geschlossen)
|
||||
- [[Diff-Reviewable Agent Edits]] - die Seite, die stundenlang unreparierbar war und den Fall
|
||||
belegt
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Beim Ergänzen eines Schema-Felds: prüfen, welcher Befehl es nach dem Anlegen noch ändert.
|
||||
Gibt es keinen, ist das Feld write-once ausgeliefert.
|
||||
- Bei der Bewertung eines nicht-idempotenten Anlegebefehls: die Frage ist nicht, wie oft er
|
||||
falsch aufgerufen wird, sondern was ein einziger falscher Aufruf dauerhaft festschreibt.
|
||||
|
||||
## Wann NICHT zu verwenden
|
||||
|
||||
- Für Felder, die absichtlich unveränderlich sind, weil ihre Änderung eine andere Operation
|
||||
ist: `type:` ändert Schema und Verzeichnis der Seite und gehört in den Seiten-Lebenszyklus,
|
||||
`confidence:` ist abgeleitet und nicht autorisiert. Eine gesperrte Zuständigkeit ist keine
|
||||
Lücke.
|
||||
- Für generierte Dateien. Dass `kb/index.md` nicht von Hand geschrieben wird, ist Invariante 1
|
||||
und kein Defekt.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Denylist over Allowlist]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **trat auf in:** [[wikitool]]
|
||||
- **gelöst mit:** [[Denylist over Allowlist]]
|
||||
- **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
|
||||
- **belegt durch:** [[Diff-Reviewable Agent Edits]]
|
||||
- **abgegrenzt gegen:** [[Command Round-Trip Integrity]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[Denylist over Allowlist]]
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Diff-Reviewable Agent Edits]]
|
||||
- [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[Command Round-Trip Integrity]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
@@ -0,0 +1,52 @@
|
||||
# kb/entities/ - Collection Contract
|
||||
|
||||
Concrete things that exist: a project, a deployed system, a CLI tool, a technology, a person or
|
||||
an organization. If it can be pointed at, it is an entity.
|
||||
|
||||
**Quality goal:** pointability + currency - a reader should come away knowing what the thing
|
||||
is, where it actually is, and whether that is still true. An entity page that describes a
|
||||
system correctly but names no host, path, version or status has not earned its keep.
|
||||
|
||||
Inherits [kb/CONTRACT.md](../CONTRACT.md) - naming, tone, linking, provenance and confidence
|
||||
are defined there and are not restated here.
|
||||
|
||||
## Types offered
|
||||
|
||||
`entity` (`tools/wikitool types describe entity`). The `entity_type:` field selects the area:
|
||||
|
||||
| Area | Holds |
|
||||
|------|-------|
|
||||
| `projects/` | Codebases and initiatives, named after their repository or common name |
|
||||
| `systems/` | Deployed and running systems, given a descriptive name |
|
||||
| `tools/` | CLI and desktop tools, named as the tool names itself |
|
||||
| `technologies/` | Protocols, languages, formats, in their standard spelling and capitalization |
|
||||
| `people/` | People and organizations, by full name or common handle |
|
||||
|
||||
These are areas, not collections: they inherit this contract and carry no `COLLECTION.md`.
|
||||
|
||||
## Per-area emphasis
|
||||
|
||||
- **Projects** - purpose, status, language/stack, owner, repository, dependencies on other
|
||||
projects and systems, architectural decisions.
|
||||
- **Systems** - purpose, components, dependencies, configuration locations, deployment,
|
||||
operational status, monitoring.
|
||||
- **Technologies** - purpose, use cases, trade-offs, version compatibility, which projects and
|
||||
systems use it.
|
||||
- **Tools** - purpose, installation, usage, notable options, which projects use it.
|
||||
- **People** - role, affiliation, and the projects or decisions they are connected to. Nothing
|
||||
personal beyond what the source states.
|
||||
|
||||
## Outbound linking
|
||||
|
||||
An entity links to the technologies it uses, the systems it runs on, the projects that depend
|
||||
on it, and the concepts it implements.
|
||||
|
||||
An entity that mentions a concept without linking it is incomplete; the concept page is where
|
||||
the *why* lives, and the entity page should not restate it.
|
||||
|
||||
## What does not belong here
|
||||
|
||||
- A pattern, protocol, architecture or decision - those are concepts, even when only one entity
|
||||
uses them.
|
||||
- A page about a source document - that is a `source` page in `kb/sources/`.
|
||||
- Singular naming is required: `ha-core.md`, not `ha-cores.md`.
|
||||
@@ -0,0 +1,103 @@
|
||||
<!-- Generated by `wikitool index rebuild`. Do not hand-edit. -->
|
||||
|
||||
# kb/entities/ - Index
|
||||
|
||||
72 page(s). Regenerated by `wikitool index rebuild`.
|
||||
|
||||
## Personen
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[Andrej Karpathy]] | person | KI-Forscher, der das grundlegende LLM-Wiki-Muster geprägt und damit die Methodik der Wissenskompilierung etabliert hat. | 2026-08-29 |
|
||||
| [[E3DC GmbH]] | person | Deutscher Hersteller von Energiespeichersystemen für Wohn- und Gewerbegebäude. | 2026-08-29 |
|
||||
| [[Rohit Gupta]] | person | Urheber von agentmemory, einem persistenten Speicher für KI-Coding-Agenten mit über 20000 GitHub-Stars. | 2026-08-29 |
|
||||
| [[Vannevar Bush]] | person | Amerikanischer Ingenieur und Wissenschaftsadministrator, der 1945 das Memex-Konzept ersann: ein persönlicher, kuratierter Wissensspeicher mit assoziativen Dokumentpfaden. | 2026-08-29 |
|
||||
|
||||
## Projekte
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[andybalholm-edl]] | project | Go-basierte EDL-Bibliothek für die Kommunikation mit eingebetteten Geräten. | 2026-08-29 |
|
||||
| [[BCDModule]] | project | Go-Modul, das die Entscheidungslogik für die Batterieladung umsetzt. | 2026-08-29 |
|
||||
| [[Chemenu]] | project | Persoenliches IT-Wissenswiki, gepflegt von LLM-Agenten; seit 1.0.0 versioniert, seit 1.1.0 Personalization Plane, seit 1.8.0 ENVIRONMENT.md, seit 2.0.0 unter dem Namen Chemenu (vorher llm-wiki-test1) mit dem Python-Paket chemenu | 2026-09-01 |
|
||||
| [[goresponsiveness]] | project | Go-Werkzeug zur Messung von Anwendungsleistung und Responsiveness. | 2026-08-29 |
|
||||
| [[ha-core]] | project | Kern-Integrationsbibliothek für Home-Assistant-E3DC-Systeme; stellt die E3DC-Kommunikationsprotokolle und den Home-Assistant-Integrationscode bereit. | 2026-08-29 |
|
||||
| [[hacs-e3dc]] | project | Home Assistant Custom Component zur Überwachung von E3DC-Energiesystemen. | 2026-08-29 |
|
||||
| [[hacs-integration-blueprint]] | project | Home-Assistant-Automatisierungs-Blueprints für das E3DC-Energiemanagement. | 2026-08-29 |
|
||||
| [[llm-wiki-skills]] | project | Plattformübergreifende LLM-Wiki-Skills von yugasun | 2026-08-29 |
|
||||
| [[plugnburn-edl]] | project | Go-basiertes EDL-Werkzeug zur Firmware-Programmierung eingebetteter Geräte. | 2026-08-29 |
|
||||
| [[wiki-skills]] | project | Umsetzung der Wiki-Skills für Claude Code von kfchou | 2026-09-01 |
|
||||
| [[wiki-skills-vanillaflava]] | project | Referenzimplementierung plattformübergreifender LLM-Wiki-Skills | 2026-09-01 |
|
||||
|
||||
## Systeme
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[AGENTS.md]] | system | Kontrollebene des LLM-Wikis: Invarianten, Dateibenennung, Routing, Gates, seit 1.1.0 Personalization und seit 1.8.0 der Environment-Abschnitt; erreicht Claude Code nur ueber den Import in CLAUDE.md | 2026-08-31 |
|
||||
| [[CLAUDE.md]] | system | Datei, die Claude Code beim Sitzungsstart laedt; importiert AGENTS.md/USER.md/SOUL.md und seit 1.8.0 ENVIRONMENT.md, traegt selbst keine Regeln | 2026-09-01 |
|
||||
| [[E3DC]] | system | Deutsches Heim-Energiespeichersystem, das Solarstromerzeugung mit Lithium-Batteriespeicher für Eigenverbrauch und Notstrom verbindet. | 2026-08-29 |
|
||||
| [[ENVIRONMENT.md]] | system | Optionale, gitignorete Root-Datei: Harness, Skills, MCP-Server, Connectoren, Remotes und CI-Ort eines Checkouts; doctor meldet sie, scheitert aber nie an ihr | 2026-08-31 |
|
||||
| [[Memex]] | system | Vannevar Bushs Konzept eines Wissensmanagementsystems von 1945 mit assoziativen Pfaden und Hypertext; geistiger Vorläufer moderner Wikis. | 2026-08-29 |
|
||||
| [[Tolkien Gateway]] | system | Von Fans erstelltes Wiki mit Tausenden verlinkten Seiten zum Tolkien-Legendarium; Beispiel für den Aufbau einer persönlichen Wissensbasis durch schrittweise Anhäufung. | 2026-08-29 |
|
||||
|
||||
## Technologien
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[acpi-cpufreq]] | technology | Linux-Kerneltreiber für die CPU-Frequenzskalierung von Prozessoren nach dem ACPI-Standard. | 2026-08-29 |
|
||||
| [[amd-pstate]] | technology | Linux-Kerneltreiber für das Power Management von AMD-Prozessoren über die CPPC-Schnittstelle; löst acpi-cpufreq ab. | 2026-08-29 |
|
||||
| [[Arch Linux]] | technology | Schlanke Rolling-Release-Linux-Distribution, genutzt als Basis für CI/CD-Paketbau-Umgebungen und Infrastruktur. | 2026-08-29 |
|
||||
| [[Disk Encryption]] | technology | Schutz ruhender Daten über das Kernelmodul dm-crypt und die LUKS-Schlüsselverwaltung zur transparenten Verschlüsselung von Speichergeräten unter Linux. | 2026-08-29 |
|
||||
| [[Docker]] | technology | Container-Plattform als Industriestandard für CI/CD-Infrastruktur, mit BuildKit-Daemon und entfernter Docker-Verwaltung über SSH. | 2026-09-01 |
|
||||
| [[Gitea]] | technology | Selbst gehosteter Git-Dienst auf docker-host.example.net; bietet Repository-Verwaltung und CI/CD über Gitea Actions mit Act Runner. | 2026-08-29 |
|
||||
| [[Gitea Actions]] | technology | CI/CD-Workflow-Plattform, in Gitea integriert; fuehrt YAML-Workflows ueber den Act Runner aus, samt Release-Pipeline, belegten paths-ignore-Filtern und einem nightly.yml-Drift-Check, dessen schedule-Ausloesung seit 2026-09-01 (Run 90) belegt ist | 2026-09-01 |
|
||||
| [[Go]] | technology | Quelloffene Programmiersprache von Google für Systemprogrammierung und Backend-Dienste, mit eingebauter Nebenläufigkeit über Goroutines und Channels. | 2026-08-29 |
|
||||
| [[GRUB]] | technology | GNU-Bootloader für Linux-Systeme; übernimmt das Laden des Kernels und die Boot-Konfiguration. | 2026-08-29 |
|
||||
| [[Home Assistant]] | technology | Quelloffene Plattform zum Aufbau von Hausautomationssystemen mit Gerätesteuerung und Automatisierung. | 2026-08-29 |
|
||||
| [[iii Engine]] | technology | Kern-Engine, die die Infrastruktur für persistente Speicher von KI-Agenten und die Umsetzung des Wissensgraphen bereitstellt. | 2026-08-29 |
|
||||
| [[Kernel PM Governors]] | technology | Power-Management-Module des Linux-Kernels, die die CPU-Frequenz dynamisch nach Systemlast und Leistungsanforderung skalieren. | 2026-08-29 |
|
||||
| [[Linux Kernel]] | technology | Quelloffener Betriebssystemkern; verwaltet Systemressourcen und Hardware-Abstraktion, einschließlich Power Management und CPU-Frequenzskalierung. | 2026-08-29 |
|
||||
| [[LVM]] | technology | Device-Mapper-Framework unter Linux für flexible Datenträgerverwaltung mit Logical Volumes, Snapshots und Online-Vergrößerung jenseits klassischer Partitionierung. | 2026-08-29 |
|
||||
| [[MQTT]] | technology | Leichtgewichtiges Publish-Subscribe-Protokoll für die Kommunikation von IoT-Geräten über TCP/IP-Netze. | 2026-08-28 |
|
||||
| [[OPC UA]] | technology | Industrieprotokoll für sichere, standardisierte Gerätekommunikation mit semantischer Datenmodellierung. | 2026-08-29 |
|
||||
| [[Python]] | technology | Interpretierte Programmiersprache, weit verbreitet für Backend-Dienste und Hausautomationsplattformen. | 2026-08-29 |
|
||||
| [[Rust]] | technology | Systemprogrammiersprache, die Speichersicherheit ohne Garbage Collection bietet. | 2026-08-29 |
|
||||
| [[Wine GE]] | technology | Eigene Wine-Builds von GloriousEggroll mit zusätzlichen Patches und Optimierungen für bessere Kompatibilität von Windows-Anwendungen und -Spielen unter Linux. | 2026-08-29 |
|
||||
| [[Wine-Staging]] | technology | Experimenteller Entwicklungszweig von Wine mit ungetesteten Patches und Funktionen vor der Aufnahme upstream; dient als Erprobungsfeld für neue Wine-Funktionalität. | 2026-08-29 |
|
||||
|
||||
## Werkzeuge
|
||||
|
||||
| Page | Type | Summary | Last Modified |
|
||||
|------|------|---------|----------------|
|
||||
| [[Act Runner]] | tool | Offizieller Gitea-Actions-Runner, der CI/CD-Workflows in Docker-Containern auf einer dedizierten Runner-VM ausführt; JavaScript-Actions brauchen node im Job-Container | 2026-09-01 |
|
||||
| [[Agent Memory]] | tool | Persistenter Speicher für KI-Coding-Agenten; setzt Wissensgraph- und Lifecycle-Management-Muster um. | 2026-08-29 |
|
||||
| [[AUR]] | tool | Gemeinschaftlich gepflegtes Repository für Arch-Linux-Pakete, gebaut aus PKGBUILD-Quellbeschreibungen. | 2026-09-01 |
|
||||
| [[Aura]] | tool | In Rust geschriebener AUR-Helper mit sicherer Paketverwaltung und eigenem Build-Verzeichnis für Arch Linux. | 2026-08-29 |
|
||||
| [[awesome-llm-wiki]] | tool | Externes GitHub-Repository (gavischneider/awesome-llm-wiki) mit verschiedenen Umsetzungen und Mustern für LLM-Wiki-Skills | 2026-08-29 |
|
||||
| [[Bottles]] | tool | Grafisches Werkzeug zur Verwaltung von Wine-Präfixen und zum Ausführen von Windows-Anwendungen unter Linux mit mehreren Runtimes. | 2026-08-29 |
|
||||
| [[ChatGPT]] | tool | KI-Chatbot von OpenAI mit Datei-Upload für RAG-artige Dokumentabfragen, ohne dauerhafte Wissensanhäufung oder Querverweis-Synthese. | 2026-08-29 |
|
||||
| [[Claude Code]] | tool | KI-Coding-Assistent von Anthropic; liest ganze Codebasen, erzeugt Code und ändert Dateien, konfiguriert über CLAUDE.md; liest Agent Skills ausschließlich aus .claude/skills/; steuert Freigaben über sechs --permission-mode-Werte. | 2026-08-31 |
|
||||
| [[Codex CLI]] | tool | Kommandozeilenschnittstelle für das Coding-Modell Codex | 2026-08-29 |
|
||||
| [[Dataview]] | tool | Obsidian-Plugin für Abfragen über das Frontmatter von Seiten; erzeugt dynamische Tabellen, Listen und strukturierte Sichten auf Wiki-Inhalte. | 2026-08-29 |
|
||||
| [[farzaa gist]] | tool | Externes Gist (farzaa/c35ac0cfbeb957788650e36aabea836d) mit Ideen und Umsetzungen zum LLM-Wiki-Muster | 2026-08-29 |
|
||||
| [[gdeploy]] | tool | In Go geschriebenes CLI-Werkzeug zur Automatisierung von Anwendungs-Deployment, Konfigurationsverwaltung und Infrastruktur. | 2026-08-29 |
|
||||
| [[Gitea MCP Server]] | tool | MCP-Server fuer die Gitea-API; liest Actions-Laeufe, Logs, Releases und Issues, ist bei privatem Repository der einzige belastbare Blick auf den CI-Zustand und traegt seit 2026-08-31 auch die Board-Triage | 2026-08-31 |
|
||||
| [[GitHub Copilot]] | tool | KI-gestützte Code-Vervollständigung auf Basis der OpenAI-Modelle, in Entwickler-Editoren integriert; unterstützt in VS Code die native Erkennung von Agent Skills (SKILL.md). | 2026-08-29 |
|
||||
| [[GPG]] | tool | GNU Privacy Guard zum Verschlüsseln und Signieren; unverzichtbar für die Prüfung von AUR-Paketen und kryptografische Operationen unter Arch Linux. | 2026-08-29 |
|
||||
| [[Lutris]] | tool | Quelloffene Spieleplattform für Linux mit einheitlicher Oberfläche für Installation und Start von Spielen über die Wine-Kompatibilitätsschicht. | 2026-08-29 |
|
||||
| [[makepkg]] | tool | Build-Werkzeug von Arch Linux; wertet PKGBUILD-Dateien aus, um Quellcode zu übersetzen und installierbare Pakete zu erzeugen. | 2026-08-29 |
|
||||
| [[Marp]] | tool | Markdown-basiertes Format für Foliensätze; erzeugt Präsentationen direkt aus Markdown, mit Themes und PDF-Export. | 2026-08-29 |
|
||||
| [[Mistral Vibe]] | tool | CLI-Coding-Agent von Mistral AI | 2026-08-29 |
|
||||
| [[NotebookLM]] | tool | RAG-basiertes KI-Wissenswerkzeug von Google; beantwortet Fragen aus hochgeladenen Dokumenten, ohne Wissen dauerhaft anzuhäufen. | 2026-08-29 |
|
||||
| [[Obsidian]] | tool | Markdown-basierte Notizanwendung mit bidirektionaler Verlinkung, Wissensgraph-Darstellung und Plugin-Ökosystem für persönliche Wikis. | 2026-08-29 |
|
||||
| [[Obsidian Web Clipper]] | tool | Browser-Erweiterung, die Webartikel als Markdown direkt in Obsidian-Vaults ablegt, für die schnelle Aufnahme in Wissens-Workflows. | 2026-08-29 |
|
||||
| [[OpenAI Codex]] | tool | Coding-Modell von OpenAI, das GitHub Copilot antreibt; versteht, erzeugt und ändert Code in mehreren Sprachen. | 2026-08-29 |
|
||||
| [[OpenCode]] | tool | KI-Coding-Assistent für Codeerzeugung und -analyse; kann das LLM-Wiki-Muster für dauerhafte Wissensverwaltung umsetzen. | 2026-08-29 |
|
||||
| [[pascalandy schema]] | tool | Von der Community beigesteuertes Wiki Schema (Global) aus pascalandys Kommentar in Farzas Gist, mit alternativer Tag-Taxonomie (area/kind/topic/status/pty) | 2026-08-29 |
|
||||
| [[Pi]] | tool | Assistenz-Agent von Inflection AI; kann das LLM-Wiki-Muster wie andere LLM-Agenten umsetzen. | 2026-08-29 |
|
||||
| [[Proton]] | tool | Wine-basierte Kompatibilitätsschicht von Valve; lässt Windows-Spiele über Steam unter Linux laufen, mit optimierter DirectX-Übersetzung. | 2026-08-29 |
|
||||
| [[qmd]] | tool | Lokale Suchmaschine für Markdown-Dateien mit hybrider BM25-Vektor-Suche und LLM-Reranking. | 2026-08-29 |
|
||||
| [[Steam]] | tool | Valves Plattform für digitalen Spielevertrieb und Spielebibliothek auf dem PC. | 2026-08-29 |
|
||||
| [[wikitool]] | tool | Deterministisches CLI fuer alle mechanischen Wiki-Operationen; seit 2.0.0 liegt es im Python-Paket chemenu, das Kommando heisst weiterhin wikitool | 2026-09-01 |
|
||||
| [[Wine]] | tool | Kompatibilitätsschicht, die Windows-API-Aufrufe nach POSIX übersetzt und Windows-Anwendungen unter Linux, BSD und macOS ohne Virtualisierung oder Emulation ausführt. | 2026-08-29 |
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: [researcher, ai, machine-learning, open-source]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Three-Layer Architecture, Knowledge Compounding, RAG]
|
||||
sources: [Source - LLM Wiki v2, Source - LLM Wiki Pattern]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: KI-Forscher, der das grundlegende LLM-Wiki-Muster geprägt und damit die Methodik der Wissenskompilierung etabliert hat.
|
||||
---
|
||||
# Andrej Karpathy
|
||||
|
||||
**Typ:** Person (AI Researcher, Engineer)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Andrej Karpathy ist ein KI-Forscher und Ingenieur, bekannt für seine Arbeiten zu großen Sprachmodellen und neuronalen Netzen. Er erstellte das ursprüngliche [LLM Wiki Gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), das das Grundmuster für den Aufbau persönlicher Wissensdatenbanken mit LLMs etablierte.
|
||||
|
||||
Seine ursprüngliche Einsicht - "stop re-deriving, start compiling" - bildet die Kernphilosophie des LLM-Wiki-Musters. Das Muster adressiert die Limitierungen traditioneller RAG-Systeme durch die Einführung einer persistenten Wiki-Schicht, die Wissen im Laufe der Zeit akkumuliert und verstärkt.
|
||||
|
||||
## Kernbeiträge
|
||||
|
||||
- **Ursprüngliches LLM Wiki Gist:** Grundlegendes Musterdokument, das die dreischichtige Architektur (Rohdatenquellen, Wiki, Schema) etabliert
|
||||
- **Kernphilosophie:** Wissen sollte einmal kompiliert und aktuell gehalten werden, nicht bei jeder Abfrage neu abgeleitet
|
||||
- **Operatives Framework:** Definierte Ingest-, Query- und Lint-Operationen
|
||||
- **Architektur:** Etablierte das Rohdaten - Wiki - Schema-Schichting
|
||||
|
||||
## Philosophie
|
||||
|
||||
> "The wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you've read. The wiki keeps getting richer with every source you add and every question you ask."
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erstellt:** [[LLM Wiki Pattern]] (original)
|
||||
- **Erweitert durch:** [[Rohit Gupta]] (LLM Wiki v2)
|
||||
- **Definiert:** [[Three-Layer Architecture]]
|
||||
- **Verwandt mit:** [[Knowledge Compounding]]
|
||||
- **Im Kontrast zu:** [[RAG]] (traditioneller Ansatz)
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Three-Layer Architecture]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[RAG]]
|
||||
- [[Rohit Gupta]]
|
||||
- [[Agent Memory]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Deutscher Hersteller von Energiespeichersystemen für Wohn- und Gewerbegebäude.
|
||||
---
|
||||
# E3DC GmbH
|
||||
|
||||
**Typ:** person
|
||||
|
||||
## Beschreibung
|
||||
|
||||
E3DC GmbH ist ein deutsches Unternehmen, das Hybrid-Wechselrichter-Systeme herstellt, die Solarstromerzeugung mit Lithium-Ionen-Batteriespeichern kombinieren. Ihre Systeme sind über Home-Assistant-Integrationen wie ha-core in die Hausautomation integriert.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite über wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,49 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: [developer, ai, memory, open-source]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [iii Engine, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
provenance: sourced
|
||||
summary: Urheber von agentmemory, einem persistenten Speicher für KI-Coding-Agenten mit über 20000 GitHub-Stars.
|
||||
---
|
||||
# Rohit Gupta
|
||||
|
||||
**Typ:** Person (Developer, Open Source Contributor)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Rohit Gupta ist der Schöpfer von [agentmemory](https://github.com/rohitg00/agentmemory), ein persistentes Speichermodul für KI-Coding-Agenten mit über 20.000 Stars auf GitHub. Er ist ein Schlüsselbeitragender zur Entwicklung des LLM-Wiki-Musters, insbesondere durch seine Arbeit an agentmemory, die Andrej Karpathys ursprüngliches Konzept mit produktionserprobten Verbesserungen erweitert.
|
||||
|
||||
Seine Arbeit an agentmemory und das zugehörige [LLM Wiki v2](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)-Dokument bietet praktische Erkenntnisse darüber, was funktioniert und was nicht, wenn man Wissensmanagementsysteme in großem Maßstab implementiert.
|
||||
|
||||
## Kernbeiträge
|
||||
|
||||
- **agentmemory:** Persistentes Speichermodul für KI-Coding-Agenten (20K+ Stars)
|
||||
- **LLM Wiki v2:** Erweiterung des ursprünglichen LLM-Wiki-Musters mit Produktionslektionen
|
||||
- **Wichtige Innovationen:** Speicher-Lebenszyklus-Management, Knowledge Graphs, Event-Driven Automation, Hybrid Search
|
||||
|
||||
## Projekte
|
||||
|
||||
- **[agentmemory](https://github.com/rohitg00/agentmemory)** - Persistentes Speichermodul für KI-Agenten
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erstellt:** [[Agent Memory]]
|
||||
- **Verwendet:** [[iii Engine]]
|
||||
- **Erweitert Arbeit von:** [[Andrej Karpathy]] (LLM Wiki original)
|
||||
- **Trägt bei zu:** [[LLM Wiki Pattern]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Agent Memory]]
|
||||
- [[iii Engine]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Andrej Karpathy]]
|
||||
- [[Memory Lifecycle]]
|
||||
- [[Knowledge Graph]]
|
||||
- [[Event-Driven Automation]]
|
||||
@@ -0,0 +1,74 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: person
|
||||
tags: [history, computer-science, knowledge-management, '1945']
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memex, LLM Wiki Pattern]
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: "Amerikanischer Ingenieur und Wissenschaftsadministrator, der 1945 das Memex-Konzept ersann: ein pers\xF6nlicher, kuratierter Wissensspeicher mit assoziativen Dokumentpfaden."
|
||||
---
|
||||
# Vannevar Bush
|
||||
|
||||
**Typ:** Person (American Engineer and Science Administrator)
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Vannevar Bush (1890-1974) war ein amerikanischer Ingenieur, Erfinder und Wissenschaftsadministrator, der bedeutende Beiträge zur Entwicklung von Analogrechnern und zur Organisation der Forschung in den USA leistete. Er ist vor allem für seinen 1945er Artikel "As We May Think" bekannt, in dem er das Konzept der **Memex** vorschlug.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Vollständiger Name:** Vannevar Bush
|
||||
- **Geboren:** 11. März 1890
|
||||
- **Gestorben:** 28. Juni 1974
|
||||
- **Nationalität:** Amerikanisch
|
||||
- **Fachbereiche:** Engineering, Computer Science, Science Administration
|
||||
- **Bekannte Arbeiten:** "As We May Think" (1945)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erfand:** [[Memex]]
|
||||
- **Inspiration für:** [[LLM Wiki Pattern]] (geistiger Vorläufer)
|
||||
|
||||
## Beiträge
|
||||
|
||||
### Memex-Konzept (1945)
|
||||
Bushs berühmtester Beitrag zum Wissensmanagement ist das **Memex** (Memory Extender), beschrieben in seinem 1945er Artikel "As We May Think" in Atlantic Monthly. Das Memex war gedacht als:
|
||||
|
||||
- Ein persönliches, kuratiertes Wissensspeicher
|
||||
- Mit assoziativen Verbindungen zwischen Dokumenten
|
||||
- Privat und aktiv vom Benutzer kuratiert
|
||||
- Wo Verbindungen zwischen Dokumenten genauso wertvoll sind wie die Dokumente selbst
|
||||
|
||||
### Wissenschaftliche Führung
|
||||
- Direktor des Office of Scientific Research and Development (OSRD) während des Zweiten Weltkriegs
|
||||
- Übersicht über das Manhattan-Projekt und andere Kriegsforschung
|
||||
- Ratgeber bei der Schaffung der National Science Foundation
|
||||
- Präsident des MIT (1923-1932)
|
||||
|
||||
## Verbindung zum LLM-Wiki-Muster
|
||||
|
||||
Laut dem Artikel [[LLM Wiki Pattern]] war Bushs Memex-Vision:
|
||||
- Näher im Geist zum LLM-Wiki-Muster als zu dem, was das Web wurde
|
||||
- Privat und aktiv kuratiert (vs. öffentliches, passiv konsumiertes Web)
|
||||
- Geschätzte assoziative Verbindungen zwischen Dokumenten
|
||||
- **Das, was er nicht lösen konnte**: Wer macht die Wartung? Das LLM übernimmt das.
|
||||
|
||||
## Zitate
|
||||
|
||||
> "The human mind... operates by association. With one item in its grasp, it snaps instantly to the next that is suggested by the association of thoughts, in accordance with some intricate web of trails carried by the cells of the brain."
|
||||
> — Vannevar Bush, "As We May Think"
|
||||
|
||||
## Historie
|
||||
|
||||
- [1945] - Veröffentlicht "As We May Think" mit Beschreibung von Memex
|
||||
- [2026-07-26] - Entity-Seite während der Aufnahme des LLM-Wiki-Muster-Artikels erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Memex]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Compounding]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-Modul, das die Entscheidungslogik für die Batterieladung umsetzt.
|
||||
---
|
||||
# BCDModule
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
BCDModule ist eine Go-Bibliothek, die Algorithmen zur Batterieladungsentscheidung für Energiemanagementsysteme bereitstellt, die in der E3DC-Integration verwendet wird, um Batterie-Lade-/Entlade-Zyklen zu optimieren.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite über wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,208 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, llm, knowledge-base]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: [Personalization Plane, Issue Label Scheme, Optional Instance Context File]
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: mixed
|
||||
summary: Persoenliches IT-Wissenswiki, gepflegt von LLM-Agenten; seit 1.0.0 versioniert, seit 1.1.0 Personalization Plane, seit 1.8.0 ENVIRONMENT.md, seit 2.0.0 unter dem Namen Chemenu (vorher llm-wiki-test1) mit dem Python-Paket chemenu
|
||||
---
|
||||
# Chemenu
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Chemenu ist das persönliche IT-Wissens-Wiki-Repository, das Gegenstand der Skill-Umstrukturierung ist, die in den Copilot Skill Restructure Instructions beschrieben wird[^s-copilot-skill-restructure-instructions]. Es hat derzeit eine monolithische `AGENTS.md`-Datei (~30KB), die fünf Workflows (INGEST, QUERY, LINT, CREATE, UPDATE), das Frontmatter-Schema des Wikis, Entity/Concept-Typ-Tabellen, Provenance/Citation-Regeln, Naming-Konventionen und eine Konfidenz-Scoring-Formel beschreibt[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
**Der Name.** Bis zum 2026-09-01 hieß das Projekt `llm-wiki-test1` - ein Arbeitstitel mit einer
|
||||
Ordnungszahl darin, kein Name. **Chemenu** ist die deutsche Wikipedia-Schreibweise des
|
||||
altägyptischen Namens von Hermopolis Magna, Hauptkultort des Thoth und „Stadt der Acht" der
|
||||
Ogdoade. Der Ort, nicht der Gott: die Persona dieser Instanz heißt Thoth, und Chemenu ist das,
|
||||
worin sie schreibt. Ältere Quellen, Logeinträge und Transkripte führen weiterhin den alten
|
||||
Namen - sie sind Aufzeichnungen dessen, was zu ihrer Zeit galt.
|
||||
|
||||
Das Repository hat bereits ein deterministisches CLI, `tools/wikitool` (Python, unterstützt durch das Paket `tools/chemenu/`), das alle mechanischen Operationen handhabt. Die Aufgabe des LLMs ist Prosa und Urteilsfindung, während `wikitool` strukturelle Korrektheit garantiert[^s-copilot-skill-restructure-instructions]. Die Skill-Umstrukturierung zielt darauf ab, die prozeduralen Workflows von den deklarativen Regeln zu trennen, Workflow-Abschnitte in diskrete Skills in `.agents/skills/` zu extrahieren, während Schema und Richtlinien in der Root `AGENTS.md` bleiben.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Persönliche IT-Wissensbasis
|
||||
- **Status:** Aktiv - Skill-Umstrukturierung abgeschlossen 2026-08-04
|
||||
- **Verantwortlich:** Torben
|
||||
- **Repository:** `torben/chemenu` auf gitea.nehmer.net; bis 2026-09-01 `torben/llm-wiki-test1`
|
||||
- **Architektur:** Dreilagig: raw/ (Quelle), wiki/ (Wissen), tools/ (deterministisches CLI)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet:** [[wikitool]] für deterministische Operationen
|
||||
- **Enthält:** [[AGENTS.md]] (Wiki-Betriebssystem)
|
||||
- **Vorlagen:** [[wiki-skills]], [[wiki-skills-vanillaflava]], [[llm-wiki-skills]]
|
||||
- **Zielplattformen:** [[GitHub Copilot]], [[Claude Code]], [[Codex CLI]], [[Mistral Vibe]]
|
||||
- **verwendet:** [[Personalization Plane]]
|
||||
- **verwendet:** [[Issue Label Scheme]]
|
||||
- **verwendet:** [[Optional Instance Context File]]
|
||||
|
||||
## Details
|
||||
|
||||
Die Repository-Struktur umfasst:
|
||||
- `raw/` - Unveränderliche Rohmaterialien (Artikel, Dokumente, Notizen, Assets)
|
||||
- `kb/` - Von LLM gepflegtes Wissen (Entities, Concepts, Quellen, Vergleiche, Katalog, Log)
|
||||
- `types/` - Die globale Typ-Oberfläche: eine Typ-Spezifikation pro Artefakt-Typ
|
||||
- `tools/` - Deterministische CLI-Tools (Kommando `wikitool`, Paket `chemenu`)
|
||||
- `instructions/` - Agent-gerichtete Prozedur: flache Anweisungen plus Skill-Verzeichnisse
|
||||
- ~~`.agents/skills/` - Kanonischer Ort für die 5 extrahierten Workflow-Skills (erstellt
|
||||
2026-08-04), gespiegelt zu `.claude/skills/` für Claude Code via `tools/wikitool skills sync`~~[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]
|
||||
Überwunden 2026-08-22: die Quelle der Skills wurde zu `instructions/<name>/` verschoben, und sowohl
|
||||
`.agents/skills/` als auch `.claude/skills/` wurden zu gitignorierten Kopien, die von
|
||||
`tools/wikitool instructions sync` veröffentlicht werden.
|
||||
|
||||
Die Umstrukturierung befasste sich mit Token-Ökonomie und Skalierungsgrenzen-Bedenken durch die Aufteilung der
|
||||
monolithischen AGENTS.md (745 Zeilen) in 5 diskrete Skills: `wiki-ingest`, `wiki-query`,
|
||||
`wiki-lint`, `wiki-manage` (CREATE+UPDATE zusammengefasst) und `wiki-status` (neu, nur-Lesezugriff) -
|
||||
finalisiert als 5, nicht das ursprünglich vorgeschlagene "wiki-create, wiki-update, optional wiki-status"[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
|
||||
### Versionierung, CI und Releases
|
||||
|
||||
Seit 2026-08-30 ist der Stack versioniert und die CI-Pipeline in Betrieb. Der Zuschnitt folgt [[KB Stack Versioning]] und
|
||||
[[KB Migration]][^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]:
|
||||
|
||||
| Fakt | Datei | Geschrieben von |
|
||||
|---|---|---|
|
||||
| Stack-Version | `VERSION` | `wikitool version bump` |
|
||||
| Release-Stempel | `.wikitool-release.json` | `wikitool dist export` |
|
||||
| KB-Version | `.wikitool-kb.json` | `wikitool migrate done` |
|
||||
|
||||
Zwei Workflows unter `.gitea/workflows/`: `ci.yml` mit Tests, Version-Gate und Export-Smoke-Test,
|
||||
und `release.yml`, das bei einer Änderung an `VERSION` einen Tag setzt und ein
|
||||
`dist export`-Tarball samt `.sha256`
|
||||
veröffentlicht[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Beide
|
||||
laufen wegen `paths-ignore` nicht bei reinen Content-Änderungen; `kb/CONTRACT.md` ist von der
|
||||
Ausnahme absichtlich ausgenommen, weil es unter einem Content-Verzeichnis liegt, aber zum Stack
|
||||
gehört[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30].
|
||||
|
||||
Der Entwicklungsbaum war der erste Fall für `migrate baseline` und bekam `1.0.0`, weil er zwar
|
||||
älter als `.wikitool-kb.json` ist, sein Inhalt der Maschinerie aber nie
|
||||
hinterherhing[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Das
|
||||
Origin-Repository ist privat; Läufe werden über den [[Gitea MCP Server]] gelesen, und die
|
||||
offenen Ausbaustufen liegen als Gitea-Issues statt als Prosa in
|
||||
`TODO.md`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]. Seit
|
||||
2026-08-31 ist das nicht mehr nur eine Gewichtung, sondern der einzige Weg: `TODO.md` wurde
|
||||
gelöscht, ihr letzter substantieller Inhalt ging als Issue #15 nach Gitea, und offene Arbeit
|
||||
existiert nur noch als Issue mit Priorität und Größe nach dem
|
||||
[[Issue Label Scheme]][^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31].
|
||||
|
||||
### Personalization und Harness-Anbindung
|
||||
|
||||
Mit `1.1.0` bekam die Instanz eine [[Personalization Plane]]: `USER.md` hält fest, wer sie
|
||||
bedient, `SOUL.md`, wie sie klingt. Ausgeliefert werden nur die beiden `.template`-Dateien; die
|
||||
befüllten Fassungen bleiben in dieser Instanz, und `wikitool doctor` prüft sie über den
|
||||
`personalization`-Check. Die Persona heißt **Thoth** - gewählt passend zur
|
||||
ägyptischen Namensgebung des Stacks selbst; der Name
|
||||
ist eine Nutzerentscheidung, und das Template schlug bis `1.8.1` ausdrücklich keinen
|
||||
vor. Seit `2.0.0` nennt
|
||||
es Thoth als Startpunkt - der Repo-Name Chemenu ist Thoths Kultort, also gehören beide zusammen -
|
||||
ohne die Frage zu ersetzen: gefragt wird trotzdem, und ein anderer Name gewinnt. Verzeichnet in
|
||||
`CHANGES.md` (`2.0.0`).
|
||||
|
||||
Mit `1.1.1` kam [[CLAUDE.md]] dazu. Bis dahin erreichte [[AGENTS.md]] [[Claude Code]] nie,
|
||||
weil dieses Harness nur `CLAUDE.md` automatisch lädt, während [[Codex CLI]] und
|
||||
[[GitHub Copilot]] `AGENTS.md` nativ lesen. Jede Claude-Code-Sitzung lief bis dahin ohne
|
||||
Invarianten, Routing und Gate-Regeln, sofern der Agent die Datei nicht selbst öffnete.
|
||||
|
||||
## Allgemeine Hinweise (unbelegt)
|
||||
|
||||
Ab 2026-08-22 ist das Repository eine vierstufige Pipeline - `raw/` -> `types/` + `tools/` ->
|
||||
`kb/` -> `reports/` - mit `instructions/` und `AGENTS.md` daneben als Kontrollrahmen.
|
||||
Die Abfrage läuft durch `tools/wikitool search` anstelle des Katalogs, und
|
||||
`kb/index.md` ist eine Karte, die auf pro-Kollektion `INDEX.md` Shards verlinkt. Dies sind Eigenschaften des
|
||||
Repositorys selbst und keine Aussagen aus einer Rohdatenquelle; der Änderungsdatensatz ist
|
||||
`CHANGES.md`, und das Operationslog ist `kb/log.md`.
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-09-01 - `2.0.0` (Commit `9a7abe6`, 121 Dateien, 730 Tests grün): Rebranding von
|
||||
`llm-wiki-test1` auf **Chemenu** nach Gitea-Issue #3 - Repo-Rename, Produktname,
|
||||
Release-Artefakt (`chemenu-stack-<version>.tar.gz`), Release-Feed, und das Python-Paket
|
||||
`wiki_tools` → `chemenu` bei unverändertem Kommando `wikitool`. MAJOR nicht wegen einer
|
||||
Inhaltsmigration - `kb/` bleibt auf Shape `1.0.0`, der Bump trägt `--no-migration` - sondern
|
||||
weil der Update-Pfad bricht: das `update_url` in jeder älteren `.wikitool-release.json` zeigt
|
||||
auf den alten Repo-Pfad und lässt sich per Invariante 1 nicht von Hand reparieren. Die
|
||||
erste Einschätzung lautete `1.9.0` und wurde von Torben korrigiert; die Lücke in der Doku,
|
||||
die dazu führte - MAJOR ist dort als Inhaltsmigration statt als Kompatibilitätsbruch
|
||||
beschrieben - liegt als Issue #26. Verzeichnet in `CHANGES.md` (`2.0.0`).
|
||||
- 2026-08-31 - `1.8.1` (Commit `a243a4a`, Korrektur `2b7b3cb`): Test-Coverage wird in CI
|
||||
gemessen und als Artefakt ausgewiesen, ohne `--cov-fail-under` - siehe
|
||||
Messen vor Schwelle. Die Messung deckte einen `dist export`-Fehler auf: Coverage-Ausgabe
|
||||
wurde mitausgeliefert, weil `TOOLS_EXCLUDE_DIRS` nur Verzeichnisse prunet und zwei Drittel der
|
||||
Ausgabe als Dateien neben dem Code liegen
|
||||
- 2026-08-31 - `1.5.1` (Commit `bb4123b`) und `1.6.0` (Commit `ce03749`, 689 Tests grün):
|
||||
zwei Datenintegritätsdefekte, beide `prio/1`, beide von einem Ingest gefunden und am selben
|
||||
Tag geschlossen. `cite add` löschte Inhalt hinter dem Fußnotenblock (Issue #17), und die
|
||||
Referenz-Arrays einer Source-Seite waren unerreichbar, während `xref add` dort ein Feld
|
||||
schrieb, das `xref remove` nicht räumen konnte (Issue #18). Der Korpus wurde mit dem
|
||||
Werkzeug repariert: `cite sync --all` normalisierte elf Seiten, danach 0 Seiten mit Inhalt
|
||||
hinter dem Block. Der bleibende Befund über den beiden Fixes: beide Defekte lebten unter
|
||||
einer vollständig grünen Suite, weil nie ein Test das richtige Verhalten behauptet hatte -
|
||||
siehe [[Green Suite Blind Spot]][^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]
|
||||
- 2026-08-31 - `1.5.0` (Commit `3166c31`, 9 Dateien, 678 Tests grün): zwei nie gemessene
|
||||
Grenzen wurden an realen Läufen kalibriert, angestoßen von Torbens Beobachtung, dass drei
|
||||
gewöhnliche Ingests nacheinander am [[Mass-Update Gate]] stehen blieben. Generierte
|
||||
Dateien zählen seither nicht mehr gegen die Gate-Schwelle, und das Kalibrierungsband für
|
||||
komplexe Workflows steigt von 15-25 auf 20-35 `wikitool`-Aufrufe. Die Messwerte lagen
|
||||
bereits im Repository - in den Changesets der drei Ingests und in
|
||||
`tools/.wikitool_session/budget.json`[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]
|
||||
- 2026-08-31 - `1.4.0` (Commit `dbe2f73`, 9 Dateien, 674 Tests grün): `touch --set/--add/--remove`
|
||||
schließt Gitea-Issue #14 und macht Felder reparierbar, die zuvor nur beim Anlegen schreibbar
|
||||
waren. Torben entschied dabei drei Punkte: Denylist statt Allowlist für die schreibbaren
|
||||
Felder, Ersetzen plus `--add`/`--remove` für Listenfelder, und einen engen Auslieferungsschnitt,
|
||||
der `raw rename` als Issue #16 (`prio/2`, `size/S`) abspaltet. Die Korpus-Seite
|
||||
[[Diff-Reviewable Agent Edits]], die den Defekt ausgelöst hatte, wurde damit im selben Lauf
|
||||
repariert[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]
|
||||
- 2026-08-31 - `1.2.1` (Commit `9fa70f3`, 5 Dateien): `TODO.md` gelöscht,
|
||||
`instructions/dev/issue-tracking.md` angelegt, sieben `prio/`- und `size/`-Labels auf allen
|
||||
zehn offenen Issues. PATCH, weil die Regel unter `instructions/dev/` liegt und keine
|
||||
ausgelieferte Instanz erreicht. In derselben Sitzung wurde Issue #11 mit dem Beleg
|
||||
geschlossen, dass `paths-ignore` greift; #14 und #15 wurden
|
||||
eröffnet[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]
|
||||
- 2026-08-31 - `1.2.0` (Commit `40adbb7`): Arraywerte mit Komma in `--set`, korrektes Flow-Quoting im Frontmatter, Budget-Erstattung für abgelehnte Aufrufe, Obergrenze 60 und ein `lint`, das seinen Reportpfad nennt. Danach `5426a6e` als Inhaltskorrektur: die beim Ingest vom 2026-08-30 umbenannte Rohdatei bekam ihren ursprünglichen Namen zurück[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-30 - Personalization Plane als Setup-Schritt ausgeliefert (`1.1.0`, Commit
|
||||
`6f54c31`), danach `CLAUDE.md` ergänzt, nachdem auffiel, dass die Kontrollebene Claude Code
|
||||
nie erreicht hatte (`1.1.1`, Commit `adfa220`)
|
||||
- 2026-08-30 - Stack-Versionierung, KB-Versionierung mit Migrationskette und die
|
||||
Gitea-Actions-Pipeline in Betrieb; `1.0.0` als Migrationsbasis gesetzt, `1.0.1` als erstes
|
||||
über die Pipeline veröffentlichtes Release mit Tarball und
|
||||
`.sha256`[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]
|
||||
- 2026-08-22 - Abfrage, Katalog-Sharding und die `instructions/`-Ebene eingeführt; Agent-seitige
|
||||
Verträge umbenannt zu `CONTRACT.md`. Verzeichnet in `CHANGES.md`.
|
||||
- 2026-08-04 - Skill-Umstrukturierung abgeschlossen: 5 Skills erstellt unter `.agents/skills/`, gespiegelt zu `.claude/skills/`, AGENTS.md geschlankt auf ~573 Zeilen, veröffentlicht bei Commit `ae2024d`[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[AGENTS.md]]
|
||||
- [[wikitool]]
|
||||
- [[Personalization Plane]]
|
||||
- [[Issue Label Scheme]]
|
||||
- [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
- [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
- [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
- [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[Optional Instance Context File]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-08-30]: [[Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]]
|
||||
[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
[^s-conversation-two-round-trip-defects-found-by-an-ingest-session-2026-08-31]: [[Source - Conversation - Two Round-Trip Defects Found by an Ingest Session 2026-08-31]]
|
||||
[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-08-31]: [[Source - Conversation - Write-Once Frontmatter Fields and touch --set Session 2026-08-31]]
|
||||
[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-basierte EDL-Bibliothek für die Kommunikation mit eingebetteten Geräten.
|
||||
---
|
||||
# andybalholm-edl
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
andybalholm-edl ist eine Go-Bibliothek, die eine EDL-Protokoll-Implementierung für die Kommunikation mit eingebetteten Geräten und Mikrocontrollern bereitstellt und eine Grundlage für Geräteprogrammierungs- und Konfigurationsabläufe bildet.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite über wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-Werkzeug zur Messung von Anwendungsleistung und Responsiveness.
|
||||
---
|
||||
# goresponsiveness
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
goresponsiveness ist ein in Go geschriebenes Performance-Test-Dienstprogramm, das Anwendungslatenz, Antwortzeiten und Durchsatz unter verschiedenen Lastbedingungen misst.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite über wikitool erstellt
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [home-automation, e3dc, go, python]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [hacs-e3dc, hacs-integration-blueprint, E3DC, Home Assistant, Go, Python]
|
||||
sources: []
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
provenance: general
|
||||
summary: Kern-Integrationsbibliothek für Home-Assistant-E3DC-Systeme; stellt die E3DC-Kommunikationsprotokolle und den Home-Assistant-Integrationscode bereit.
|
||||
---
|
||||
# ha-core
|
||||
|
||||
**Typ:** Project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
ha-core scheint eine Kernkomponente für die Integrationierung von E3DC-Systemen in Home Assistant zu sein. Basierend auf der Verzeichnisstruktur im übergeordneten Repository ist dies wahrscheinlich ein Go- oder Python-Projekt, das grundlegende Funktionen für die Überwachung und Steuerung von E3DC-Energiespeichersystemen im Home-Assistant-Ökosystem bietet.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Kernintegrationsbibliothek für E3DC-Systeme
|
||||
- **Status:** Aktiv (aus Präsenz im Quellbaum abgeleitet)
|
||||
- **Sprache/Technik:** Go und/oder Python
|
||||
- **Verantwortlich:** Torben
|
||||
- **Repository:** Lokales Verzeichnis (ha-core/)
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** [[Home Assistant]] Ökosystem
|
||||
- **Hängt ab von:** [[E3DC]] Systemen
|
||||
- **Verwandt mit:** [[hacs-e3dc]], [[hacs-integration-blueprint]]
|
||||
- **Verwendet:** [[Go]], [[Python]]
|
||||
|
||||
## Details
|
||||
|
||||
### Komponenten
|
||||
|
||||
Basierend auf der Repository-Struktur wahrscheinlich enthalten:
|
||||
- E3DC-Kommunikationsprotokolle
|
||||
- Datenmodelle für E3DC-Systeme
|
||||
- Home Assistant Integrationscode
|
||||
- Konfigurationsverwaltung
|
||||
|
||||
### Abhängigkeiten
|
||||
|
||||
- E3DC Hardware-/Softwareschnittellen
|
||||
- Home Assistant Integrations-Frameworks
|
||||
|
||||
## Historie
|
||||
|
||||
- [2026-07-25] - Entity-Seite erstellt als Teil des Initial-Wiki-Scaffolds
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[E3DC]]
|
||||
- [[Home Assistant]]
|
||||
- [[hacs-e3dc]]
|
||||
- [[hacs-integration-blueprint]]
|
||||
- [[Go]]
|
||||
- [[Python]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, Go, ha-core]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Home Assistant Custom Component zur Überwachung von E3DC-Energiesystemen.
|
||||
---
|
||||
# hacs-e3dc
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
hacs-e3dc ist eine Home Assistant Custom Component (HACS), die eine Integration für E3DC-Energiespeichersysteme bereitstellt. Sie ermöglicht die Überwachung des Batterieladestands, der Solarstromerzeugung und des Netzverbrauchs und unterstützt die Automatisierung von Energierouting und Optimierung.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, ha-core]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Home-Assistant-Automatisierungs-Blueprints für das E3DC-Energiemanagement.
|
||||
---
|
||||
# hacs-integration-blueprint
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
hacs-integration-blueprint stellt Home Assistant Integrations-Blueprints bereit - vorgefertigte Automatisierungsvorlagen für E3DC-Energiesysteme, einschließlich Multi-Sensor-Setup, Batterieoptimierung und Grid-Synchronisierungsautomatisierungen.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,56 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, skills, claude-code]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Umsetzung der Wiki-Skills für Claude Code von kfchou
|
||||
---
|
||||
# wiki-skills
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das kfchou/wiki-skills-Projekt wird in den Copilot Skill Restructure Instructions als eine Vorgängerimplementierung im LLM-wiki-Ökosystem erwähnt[^s-copilot-skill-restructure-instructions]. Es zeigt ein funktionierendes Beispiel von sechs eigenständigen Claude-Code-Skills: `wiki-init`, `wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-update` und `wiki-audit`, von denen jede ihre eigene Datei ist und nur beim Aufruf geladen wird[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
Dies wird als das nächste 1:1-Strukturanalog zu dem beschrieben, was die Chemenu-Umstrukturierung anstrebt - es zeigt, dass das Muster von diskreten, aufrufbaren Skills gut für ein allgemeines IT-Wiki funktioniert, anstatt für ein persönliches Journal[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Claude Code Wiki-Skills Implementierung
|
||||
- **Status:** Extern, als Vorlage referenziert
|
||||
- **Verantwortlich:** kfchou
|
||||
- **Repository:** https://github.com/kfchou/wiki-skills (abgeleitet)
|
||||
- **Skills:** wiki-init, wiki-ingest, wiki-query, wiki-lint, wiki-update, wiki-audit
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Vorlage für:** [[Chemenu]] Skill-Umstrukturierung
|
||||
- **Ähnlich wie:** [[wiki-skills-vanillaflava]], [[llm-wiki-skills]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Die kfchou/wiki-skills Implementierung zeigt, dass das Muster von sechs eigenständigen Skills (eine für jeden Workflow) effektiv für ein allgemeines Wiki funktioniert. Jede Skill-Datei ist in sich geschlossen und wird nur bei Ausführung des entsprechenden Befehls geladen, was Vorteile bei der Kontextisolation bietet[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Chemenu]]
|
||||
- [[wiki-skills-vanillaflava]]
|
||||
- [[llm-wiki-skills]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go, gdeploy]
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
provenance: general
|
||||
summary: Go-basiertes EDL-Werkzeug zur Firmware-Programmierung eingebetteter Geräte.
|
||||
---
|
||||
# plugnburn-edl
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
plugnburn-edl ist ein Go-Sprachen-Tool für Embedded Device Line (EDL) Programmierung, das Firmware-Updates und Konfiguration von eingebetteten Geräten ermöglicht. Es ist Teil von Torbens Deployment- und Device-Management-Toolchain.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** TODO
|
||||
- **Status:** TODO
|
||||
- **Version:** TODO
|
||||
- **Sprache/Technik:** TODO
|
||||
- **Verantwortlich:** TODO
|
||||
- **Repository:** TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwandt mit:** TODO
|
||||
|
||||
## Details
|
||||
|
||||
TODO
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-02 - Seite erstellt via wikitool
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
@@ -0,0 +1,57 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, skills, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Referenzimplementierung plattformübergreifender LLM-Wiki-Skills
|
||||
---
|
||||
# wiki-skills-vanillaflava
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das vanillaflava/wiki-skills-vanillaflava-Projekt wird in den Copilot Skill Restructure Instructions als die Referenzimplementierung für **plattformübergreifende Verteilung** erwähnt[^s-copilot-skill-restructure-instructions]. Es zeigt sechs Wiki-Skills, die gleichzeitig gegen Claude Code, Gemini CLI, Codex CLI und GitHub Copilot getestet werden[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
Dieses Projekt ist besonders bemerkenswert für seinen plattformübergreifenden Ansatz, der ein gemeinsames Verzeichnis (`.agents/skills/`) verwendet, das in das native Skill-Verzeichnis jedes Tools verlinkt ist, was sicherstellt, dass alle vier Tools mit einer einzigen Quelle der Wahrheit synchronisiert bleiben[^s-copilot-skill-restructure-instructions]. Es bietet auch ein Installer-Muster, das die Chemenu-Umstrukturierung als Modell nutzen kann[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Plattformübergreifende LLM-Wiki-Skill-Verteilung
|
||||
- **Status:** Extern, als Referenzimplementierung referenziert
|
||||
- **Verantwortlich:** vanillaflava
|
||||
- **Repository:** https://github.com/vanillaflava/wiki-skills-vanillaflava (abgeleitet)
|
||||
- **Zieltools:** Claude Code, Gemini CLI, Codex CLI, GitHub Copilot
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Referenzimplementierung für:** [[Chemenu]] plattformübergreifende Ausrichtung
|
||||
- **Ähnlich wie:** [[wiki-skills]], [[llm-wiki-skills]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Das vanillaflava/wiki-skills-vanillaflava-Projekt wird als das kanonische Installationsziel hervorgehoben, das in tool-spezifische Verzeichnisse verlinkt wird[^s-copilot-skill-restructure-instructions]. Dieser Ansatz vermeidet die Verwaltung von vier Kopien derselben Skills und stellt Konsistenz über alle Ziel-LLM-Tools hinweg sicher.
|
||||
|
||||
Das Installer-Muster des Projekts dient als Modell für die Chemenu-Umstrukturierung und zeigt, wie ein kleines Skript das gemeinsame Verzeichnis einmal erstellen und in den nativen Skill-Pfad jedes Tools verlinken kann[^s-copilot-skill-restructure-instructions].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Chemenu]]
|
||||
- [[wiki-skills]]
|
||||
- [[llm-wiki-skills]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: project
|
||||
tags: [wiki, skills, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
provenance: sourced
|
||||
summary: Plattformübergreifende LLM-Wiki-Skills von yugasun
|
||||
---
|
||||
# llm-wiki-skills
|
||||
|
||||
**Typ:** project
|
||||
|
||||
## Beschreibung
|
||||
|
||||
Das yugasun/llm-wiki-skills-Projekt wird in den Copilot Skill Restructure Instructions als ein weiteres plattformübergreifendes Repository erwähnt, das explizit Claude Code, GitHub Copilot und Codex CLI anstrebt[^s-copilot-skill-restructure-instructions]. Es dient als Vorlage, die zeigt, dass das plattformübergreifende Skill-Verteilungsmuster praktikabel ist und aktiv von mehreren Implementierungen im LLM-wiki-Ökosystem genutzt wird[^s-copilot-skill-restructure-instructions]. Das eigentliche Repository befindet sich unter https://github.com/yugasun/llm-wiki-skills.
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Plattformübergreifende LLM-Wiki-Skills
|
||||
- **Status:** Extern, als Vorlage referenziert
|
||||
- **Verantwortlich:** yugasun
|
||||
- **Repository:** https://github.com/yugasun/llm-wiki-skills (abgeleitet)
|
||||
- **Zieltools:** Claude Code, GitHub Copilot, Codex CLI
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Vorlage für:** [[Chemenu]] plattformübergreifende Ausrichtung
|
||||
- **Ähnlich wie:** [[wiki-skills]], [[wiki-skills-vanillaflava]]
|
||||
- **Erwähnt in:** [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
## Details
|
||||
|
||||
Das yugasun/llm-wiki-skills-Projekt wird neben vanillaflava/wiki-skills-vanillaflava zitiert als Beweis dafür, dass der plattformübergreifende Ansatz für LLM-Wiki-Skills an Fahrt im Ökosystem gewinnt[^s-copilot-skill-restructure-instructions]. Dies validiert die architektonische Entscheidung, mehrere LLM-Tools mit einem einzigen gemeinsamen Skill-Satz anzusprechen.
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-04 - Seite erstellt während der Aufnahme der Copilot Skill Restructure Instructions
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Chemenu]]
|
||||
- [[wiki-skills]]
|
||||
- [[wiki-skills-vanillaflava]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
type: types/entity.md
|
||||
entity_type: system
|
||||
tags: [schema, configuration, wiki, operating-system]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Naming Convention Conflict, CLAUDE.md, Denylist over Allowlist, ENVIRONMENT.md]
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis, Source - LLM Wiki v2, Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31, Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: sourced
|
||||
summary: 'Kontrollebene des LLM-Wikis: Invarianten, Dateibenennung, Routing, Gates, seit 1.1.0 Personalization und seit 1.8.0 der Environment-Abschnitt; erreicht Claude Code nur ueber den Import in CLAUDE.md'
|
||||
---
|
||||
# AGENTS.md
|
||||
|
||||
**Typ:** system
|
||||
|
||||
## Beschreibung
|
||||
|
||||
AGENTS.md ist das Schema und Betriebssystem für die LLM Wiki. Es definiert die vollständige Methodik, wie die LLM die Wiki pflegt, Quellen verarbeitet, Anfragen beantwortet, Linting durchführt, Seiten erstellt und Konsistenz über alle Operationen hinweg aufrechterhält. Das Dokument etabliert den Grundsatz „Niemals ableiten. Immer kompilieren." und erzwingt eine strenge Trennung zwischen mechanischen Operationen (von wikitool gehandhabt) und semantischen Operationen (von der LLM gehandhabt).
|
||||
|
||||
Die Codex-Analyse identifizierte AGENTS.md als Bereitstellung einer deterministisch erzwungenen Grundlage, die vielen öffentlichen LLM-Wiki-Skills voraus ist. Sie kodifiziert Workflows (INGEST, QUERY, LINT, CREATE, UPDATE), Qualitätsstandards, Namenskonventionen, Seitenformate, Cross-Reference-Regeln und die drei-schichtige Architektur (Rohquellen, von LLM verwaltete Wiki, Schema).
|
||||
|
||||
## Kerndaten
|
||||
|
||||
- **Zweck:** Kontrollebene für die Wiki: Invarianten, Dateibenennnung, Routing, Gates
|
||||
- **Status:** Aktiv, unter aktiver Entwicklung
|
||||
- **Version:** Umstrukturiert 2026-08-22 - siehe `CHANGES.md`
|
||||
- **Sprache/Technik:** Markdown, YAML-Frontmatter
|
||||
- **Standort:** Repo-Wurzel: `/AGENTS.md`
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Implementiert von:** [[wikitool]]
|
||||
- **Definiert:** [[LLM Wiki Pattern]], [[Three-Layer Architecture]], [[Workflow Orchestration]]
|
||||
- **Verwendet von:** Alle LLM-Operationen in dieser Wiki
|
||||
- **hat:** [[Naming Convention Conflict]]
|
||||
- **Analysiert in:** [[Source - LLM Improvements Codex Analysis]], [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- **verwandt mit:** [[CLAUDE.md]]
|
||||
- **begründet:** [[Denylist over Allowlist]]
|
||||
- **beschreibt:** [[ENVIRONMENT.md]]
|
||||
|
||||
## Hauptabschnitte
|
||||
|
||||
AGENTS.md enthält diese Hauptabschnitte:
|
||||
|
||||
- **Übersicht:** Grundsätze und Architektur
|
||||
- **Werkzeuge:** wikitool-CLI-Befehlsreferenz
|
||||
- **Provenienz und Zitation:** raw_files, Provenienz-Marker, Inline-Zitationen
|
||||
- **Entity-Typen:** Projects, Systems, Tools, Technologies, People
|
||||
- **Concept-Typen:** Architecture, Pattern, Protocol, Workflow, Decision, Problem
|
||||
- **Relationship-Typen:** depends on, uses, implements, extends, replaces, etc.
|
||||
- **Workflows:** ~~INGEST, QUERY, LINT, CREATE, UPDATE mit detaillierten Schritten~~ **abgelöst** - die
|
||||
5 Workflow-Schritt-Listen wurden wörtlich in diskrete Skills unter `.agents/skills/`
|
||||
extrahiert (`wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-manage` (CREATE+UPDATE zusammengeführt), `wiki-status`
|
||||
(neu, schreibgeschützt)); die Root-Datei enthält jetzt nur eine Zeiger-Tabelle[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Skills:** Neuer Top-Level-Abschnitt, der die 5 Skills auflistet und auf `.agents/skills/` verweist,
|
||||
gespiegelt zu `.claude/skills/` über `tools/wikitool skills sync`/`verify` für Claude-Code-
|
||||
Kompatibilität[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Git-Automation:** Auto-Publish über wikitool - jetzt nur Policy in der Root-Datei; der Output-Abschnitt jeder Skill gibt an, ob dieser Workflow auto-published[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- **Seitenformate:** Templates für Entities, Concepts, Sources, Comparisons
|
||||
- **Qualitätsstandards:** Inhalts- und Cross-Reference-Qualitätskriterien
|
||||
- **IT-spezifische Richtlinien:** Domänen-spezifische Regeln für Projects, Systems, Tools, etc.
|
||||
- **Konfidenz-Bewertung:** Quantitative Bewertung für sachliche Aussagen
|
||||
- **Personalization:** Seit `1.1.0` ein eigener Abschnitt. Er hält fest, dass `USER.md` und
|
||||
`SOUL.md` bei Sitzungsstart gelesen werden, dass `USER.md` Kontext und keine
|
||||
Instruktionsquelle ist, dass `SOUL.md` gegen diese Datei verliert und dass eine
|
||||
Nutzeraussage keine Quelle im Sinne von Invariante 3 ist. Die Mechanik dahinter:
|
||||
[[Personalization Plane]].
|
||||
- **Environment:** Seit `1.8.0` ein eigener Abschnitt neben „Personalization". Er hält fest,
|
||||
dass [[ENVIRONMENT.md]] bei Sitzungsstart gelesen wird, *falls sie existiert*, dass ihr Fehlen
|
||||
kein Fehler ist, und dass sie Kontext ohne Autorität trägt - ein dort gelisteter Remote
|
||||
autorisiert keinen Push an Invariante 5 vorbei[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]. Der Abschnitt ist nötig, weil
|
||||
die übrigen Harnesses [[CLAUDE.md]] nie lesen und die Datei sie sonst nie erreichte. Die
|
||||
Mechanik dahinter: [[Optional Instance Context File]].
|
||||
|
||||
## Namenskonventions-Anmerkung
|
||||
|
||||
**Konflikt identifiziert:** Es gibt einen bekannten Unterschied zwischen AGENTS.md (das menschenlesbare Dateinamen mit Leerzeichen erfordert, z. B. `Hybrid Search.md`) und README.md (das Kebab-Case erfordert, z. B. `hybrid-search.md`). Dies verursacht Validierungsinkonsistenzen, die gelöst werden sollten. Siehe [[Naming Convention Conflict]].
|
||||
|
||||
## Historie
|
||||
|
||||
- 2026-08-31 - Abschnitt „Environment" und eine vierte Zeile in der File-naming-Tabelle
|
||||
(`ENVIRONMENT.md`, die einzige optionale Zeile darin), mit Stack-Version `1.8.0`[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]
|
||||
- 2026-08-31 - Die Obergrenze des Iteration Budget Gate im Abschnitt „Gates" von 30 auf 60 gezogen, gemeinsam mit `instructions/gates.md`, `tools/CONTRACT.md`, `README.md`, der `work plan`-Vorlage und der Einheitengröße in `migrate-corpus.md`. Der Loop-Breaker blieb bei 3[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]
|
||||
- 2026-08-30 - Abschnitt „Personalization" und drei neue Zeilen in der File-naming-Tabelle
|
||||
(`CLAUDE.md`, `USER.md`, `SOUL.md`). Im selben Zug stellte sich heraus, dass diese
|
||||
Datei [[Claude Code]] nie erreicht hatte, weil dieses Harness ausschließlich [[CLAUDE.md]]
|
||||
lädt
|
||||
|
||||
- 2026-08-04 - Umstrukturiert: Die 5 Workflow-Abschnitte wurden in `.agents/skills/`-Skills extrahiert (`wiki-ingest`, `wiki-query`, `wiki-lint`, `wiki-manage`, `wiki-status`), Datei von 745 auf ~573 Zeilen reduziert, neue „## Skills"-Sektion und Git-Automation-Policy-only-Umschreiben[^s-conversation-agents-md-skill-restructuring-session-2026-08-04].
|
||||
- 2026-08-03 - Seite während der Aufnahme der Codex-Analyse erstellt
|
||||
- 2026-08-02 - Namenskonventionen auf menschenlesbare Titel mit Leerzeichen aktualisiert
|
||||
- 2026-07-26 - Mit Git-Automation- und Tooling-Abschnitten aktualisiert
|
||||
- 2026-07-25 - Initiales IT-fokussiertes Schema erstellt
|
||||
|
||||
## Analyseergebnisse
|
||||
|
||||
Die Sonnet-Analyse kam zu dem Ergebnis, dass AGENTS.md in drei Schlüsselbereichen konzeptionell bereits vor den meisten öffentlichen LLM-Wiki-Implementierungen ist:
|
||||
- **Provenienz und Zitation:** Die raw_files:, provenance:, [^s-llm-wiki-v2]-Marker und provenance.md-Rückwärtsindex bieten ungewöhnlich reife Coverage[^s-llm-improvements-sonnet-analysis]
|
||||
- **Deterministisches CLI:** wikitool handhabt mechanische Operationen präzise, anstatt an Ad-hoc-LLM-Scripts zu delegieren[^s-llm-improvements-sonnet-analysis]
|
||||
- **Konfidenz-Bewertung:** Die Verfallsformel und das Bewertungssystem existieren und funktionieren effektiv[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
Die Sonnet-Analyse identifizierte jedoch Lücken, wo AGENTS.md verbessert werden könnte:
|
||||
- Einen Abschnitt „Content Quality & Style" mit Seitenlängen-Schwellwerten und Style-Guide-Regeln hinzufügen[^s-llm-improvements-sonnet-analysis]
|
||||
- Session-Orientierung als obligatorischen ersten Schritt für alle Workflows einbauen[^s-llm-improvements-sonnet-analysis]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Three-Layer Architecture]]
|
||||
- [[Naming Convention Conflict]]
|
||||
- [[Content Quality Control]]
|
||||
- [[Session Orientation]]
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Source - LLM Improvements Codex Analysis]][^s-llm-improvements-codex-analysis]
|
||||
- [[Source - LLM Improvements Sonnet Analysis]]
|
||||
- [[Source - LLM Wiki v2]]
|
||||
- [[Source - Copilot Skill Restructure Instructions]]
|
||||
- [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
- [[Source - LLM Improvements Production Agent Gaps 2026]]
|
||||
- [[CLAUDE.md]]
|
||||
- [[Denylist over Allowlist]]
|
||||
- [[Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]]
|
||||
- [[ENVIRONMENT.md]]
|
||||
- [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-conversation-agents-md-skill-restructuring-session-2026-08-04]: [[Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]]
|
||||
[^s-conversation-environment-md-as-an-optional-third-session-level-file-session-2026-08-31]: [[Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]]
|
||||
[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
|
||||
[^s-llm-wiki-v2]: [[Source - LLM Wiki v2]]
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user