Compare commits
12 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 41f5dfe1cd | |||
| 23307c3c5f | |||
| cfe925a76c | |||
| 23e34a940c | |||
| c8c238523a | |||
| 3f99d6715f | |||
| 807094deae | |||
| 8b711f4860 | |||
| a35c94e2d9 | |||
| 9e2f9bf98d | |||
| 7e15035001 | |||
| b137359b90 |
+6
-1
@@ -1,11 +1,16 @@
|
||||
{
|
||||
"schema": 1,
|
||||
"kb_version": "3.0.0",
|
||||
"kb_version": "4.0.0",
|
||||
"applied": [
|
||||
{
|
||||
"migration": "3.0.0-authoring-conventions",
|
||||
"at": "2026-09-02",
|
||||
"pages": 0
|
||||
},
|
||||
{
|
||||
"migration": "4.0.0-link-taxonomy",
|
||||
"at": "2026-09-02",
|
||||
"pages": 153
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
+198
@@ -20,6 +20,204 @@ their date-only headings.
|
||||
|
||||
---
|
||||
|
||||
## 4.1.2 - 2026-09-03 - Issue-Abschluss ist ein Body-Rewrite, nicht nur ein Kommentar
|
||||
|
||||
**Author:** Torben Nehmer
|
||||
|
||||
Aufgefallen beim Schließen von #44: der Abschlussbericht stand als Kommentar da, der Body
|
||||
darunter weiterhin als offene Arbeit — Abschnitt „Zu entscheiden" über eine längst getroffene
|
||||
Entscheidung, ungehakte Checkliste, Präsens über einen Defekt, den es nicht mehr gab.
|
||||
|
||||
Die Regel gab es dafür schon: Schritt 2 von `instructions/dev/issue-tracking.md` sagt, der Body
|
||||
ist die aktuelle Wahrheit und wird umgeschrieben, wenn sich der Stand ändert. Nur ließ die
|
||||
Formulierung offen, *wann* — und Schritt 7 („Close with what actually happened") war vollständig
|
||||
erfüllbar, ohne den Body anzufassen. Ein Abschlussbericht im Kommentar fühlt sich beim Schreiben
|
||||
vollständig an; dass der Body dabei zurückbleibt, merkt erst der nächste Leser.
|
||||
|
||||
**Schritt 2 ist deshalb schärfer geworden: der Body ist das Plan-File dieses Stacks.** Dasselbe,
|
||||
was das Plan-Dokument eines Harness ist, und genauso gepflegt — fortlaufend, sobald etwas darin
|
||||
nicht mehr stimmt, nicht am Ende. Der Maßstab ist der Abbruch, nicht der Meilenstein: eine
|
||||
Session kann jederzeit enden, und was der Body in diesem Moment sagt, ist die vollständige
|
||||
Übergabe. Eine frische Session muss zu **jedem** Zeitpunkt allein aus dem Body weiterarbeiten
|
||||
können, ohne Kommentare rückwärts zu lesen und ohne einen Menschen, der es neu erklärt. Entschieden
|
||||
ersetzt die Frage, erledigt hakt das Kriterium ab, verworfen steht mit Begründung dort, wo das
|
||||
Kriterium stand.
|
||||
|
||||
Schritt 7 ist damit kein Sonderakt mehr, sondern die letzte dieser Aktualisierungen: erst Body
|
||||
auf den Endstand, dann schließen, dann die Changelog-Zeile aus Schritt 3. Wer Schritt 2 befolgt
|
||||
hat, ist fast fertig; wer nicht, zahlt die ganze Schuld im schlechtesten Moment — der
|
||||
geschlossene Body ist die Fassung, die danach alle lesen und niemand mehr aufsucht. #44 steht
|
||||
als Beispiel drin.
|
||||
|
||||
Schritt 3 zieht die Konsequenz: **ein Kommentar pro Session-Umfang, nicht pro Edit.** Ein
|
||||
fortlaufend gepflegter Body mit einem Changelog-Kommentar je Änderung wäre Lärm; triviale Pflege
|
||||
braucht gar keinen. Der `stack-dev`-Skill sagt es beim Aufgreifen mit, weil dort die Entscheidung
|
||||
fällt, ob eine Session den Body überhaupt anfasst.
|
||||
|
||||
**Und die ehrliche Antwort auf die Frage nach dem Tooling: es gibt keins, und es soll keins
|
||||
geben.** `wikitool` kennt diesen Tracker nicht. Es wird an Instanzen ausgeliefert, die unter
|
||||
dieser URL keine Issues haben, während `instructions/dev/` von `dist export` gepruned wird —
|
||||
ein Gitea-Client im ausgelieferten Tool wäre eine Dev-Abhängigkeit, die jede Instanz mitträgt,
|
||||
um ein Board zu prüfen, das keine von ihnen hat. Der Tracker ist ausschließlich über
|
||||
`gitea-mcp` erreichbar, also in einer Session, durch einen Agenten.
|
||||
|
||||
Kein `docs verify` fängt also einen geschlossenen Issue, dessen Body offen klingt, einen Body,
|
||||
der seinen eigenen Kommentaren widerspricht, oder ein fehlendes Pflichtlabel. Das steht jetzt
|
||||
als eigener Abschnitt „What no tool checks" in der Instruktion — nicht als Bedauern, sondern als
|
||||
Begründung dafür, warum die Reihenfolge in Schritt 7 ausgeschrieben ist statt aus Schritt 2
|
||||
erschlossen zu werden.
|
||||
|
||||
---
|
||||
|
||||
## 4.1.1 - 2026-09-03 - Testisolation: kb_dir repointet config.ROOT, lint löst Kollektionen gegen den übergebenen Baum auf
|
||||
|
||||
**Author:** Torben Nehmer
|
||||
|
||||
Issue #44, gefunden beim Bau der Migrations-Gate-Tests für 4.1.0: die `kb_dir`-Fixture baute
|
||||
ihren Baum unter `tmp_path`, ließ `config.ROOT` aber auf dem echten Checkout stehen. Jeder
|
||||
Codepfad, der eine Datei über `config.ROOT`/`config.KB_DIR` auflöst statt über das übergebene
|
||||
Verzeichnis, traf damit das echte Repository.
|
||||
|
||||
**Der laute Fall** war ein Test, der `kb_state.write_kb_state()` rief und dabei das
|
||||
`.wikitool-kb.json` des Repos überschrieb — Applied-Ledger leer statt zwei Einträgen. In
|
||||
`git status` sofort sichtbar und reversibel; bei einer gitignorierten Datei wäre es das nicht
|
||||
gewesen.
|
||||
|
||||
**Der stillere Fall** ist der teurere. `lint`s Kollektions-Lookup löste eine Seite gegen
|
||||
`config.KB_DIR` auf. Für eine Seite unter `tmp_path/kb/` warf das `ValueError`, die Funktion
|
||||
antwortete „keine Kollektion", und die Label-Autorisierung übersprang die Kante wortlos.
|
||||
`unauthorised_labels` war damit faktisch ungetestet — jeder Test, der das Finding hätte
|
||||
auslösen können, bekam eine leere Liste und behauptete nichts. Ein grüner Lauf, der wie eine
|
||||
Zusicherung aussah.
|
||||
|
||||
**Der Fix ist der Codepfad, nicht die Fixture.** `run_lint()` bekommt ein Verzeichnis
|
||||
übergeben und löst jetzt auch intern dagegen auf; `authorised_labels()` bekommt denselben Baum
|
||||
gereicht, statt auf `config.KB_DIR` zurückzufallen. Der Regressionstest lintet einen Baum, von
|
||||
dem `ROOT` bewusst wegzeigt — genau der Fall, den die alte Auflösung verschluckte. Eine Funktion,
|
||||
die ein Verzeichnis entgegennimmt, löst dagegen auf: keine Fixture kann diese Form von außen
|
||||
reparieren.
|
||||
|
||||
**Beide Korpus-Fixturen repointen jetzt.** `kb_dir` tut, was `raw_dir` längst tat — `ROOT` auf
|
||||
das eigene `tmp_path`, plus `use_shipped_type_specs()`. Der Suite-Lauf kippte dadurch keinen
|
||||
einzigen Test. Die lokale `rooted_kb`-Umgehung aus 4.1.0 entfällt damit; die Auswahl zwischen
|
||||
zwei fast gleichen Fixturen war Wissen, das nirgends stand.
|
||||
|
||||
**Und ein Wächter für die ganze Klasse.** `repository_tree_guard` (session-scoped, autouse)
|
||||
vergleicht `git status --porcelain` vor und nach dem Lauf und lässt die Suite scheitern, wenn
|
||||
sich im Checkout etwas bewegt hat — zwei `git status`-Aufrufe pro Lauf, deshalb per Default an.
|
||||
Er vergleicht vorher gegen nachher statt einen sauberen Baum zu verlangen, sagt also nichts über
|
||||
die unveröffentlichte Arbeit des Entwicklers. Den Verursacher benennt er nicht;
|
||||
`CHEMENU_TREE_GUARD=each` prüft nach jedem Test und tut es. Ohne git oder außerhalb eines
|
||||
Repositorys sind beide still.
|
||||
|
||||
Was der Wächter nicht sieht: eine Prüfung, die unter Test nichts tut, schreibt keine Datei.
|
||||
Dagegen hilft nur ein Test, der das Finding tatsächlich auslöst — der neue tut das.
|
||||
|
||||
`instructions/dev/testing-conventions.md` hat dafür einen eigenen Abschnitt („Which tree a test
|
||||
writes into"), einen Schritt in der Checkliste und die Regel für neue Fixturen.
|
||||
|
||||
---
|
||||
|
||||
## 4.1.0 - 2026-09-03 - Link-Taxonomie: Lint-Findings hart ab kb_version 4.0.0, outbound: an das Type-Spec gebunden, part-of/composition als Inversenpaar
|
||||
|
||||
**Author:** Torben Nehmer
|
||||
|
||||
Der Rest von Issue #40, nachdem die Korpus-Migration durch ist: die beiden aufgeschobenen
|
||||
Lint-Findings werden hart, und die drei Befunde aus dem Abschlusskommentar des Migrationslaufs
|
||||
werden aufgelöst.
|
||||
|
||||
**`unlabelled_edges` und `unauthorised_labels` sind harte Fehler — aber an `kb_version`
|
||||
gebunden, nicht an ein Datum.** Der Weg, den `legacy_citation_markers` genommen hat, war ein
|
||||
Umlegen in einer späteren Version: eine Instanz, die die Zitat-Migration noch schuldete, lebte
|
||||
danach mit rotem Lint. Das Ledger kann die Frage inzwischen beantworten, also tut es das.
|
||||
Unterhalb `kb_version` 4.0.0 bleiben beide beratend — genau das Fenster, in dem
|
||||
`instructions/migrations/4.0.0-link-taxonomy.md` der Instanz sagt, sie solle den halb
|
||||
konvertierten Korpus Einheit für Einheit publizieren; ein Check, der dabei fehlschlägt, würde
|
||||
den Korpus verweigern, dessen Fortschritt er misst. Ab 4.0.0 ist eine kahle Titelangabe in
|
||||
`related:` keine Seite mehr, die auf ihre Umstellung wartet, sondern eine Kante, deren Autor
|
||||
nicht gesagt hat, was sie behauptet. `hard_error_keys()` liefert die jeweils geltende Menge,
|
||||
`HARD_ERROR_KEYS` bleibt die vollständige.
|
||||
|
||||
**`outbound:` ist an das Type-Spec gebunden.** `kb/sources/` und `kb/comparisons/`
|
||||
autorisierten Label, die dort strukturell nicht schreibbar waren: keiner der beiden Type-Specs
|
||||
führte ein `related:`. Folgenlos war das nicht — die einzige Comparison-Seite des Korpus trug
|
||||
`- **compares-with:** [[amd-pstate]]` als *handgeschriebene Prosa*, ohne Marker-Region, ohne
|
||||
Frontmatter, für `lint` unsichtbar. Also ein Identifier zurück im Fließtext, gut vier Stunden
|
||||
nachdem 4.0.0 genau das beendet hatte. Eine leere Autorisierung liest sich als Lizenz.
|
||||
|
||||
Aufgelöst nach dem, was die beiden Contracts jeweils selbst sagen: `comparison` bekommt ein
|
||||
`related:` (die `compares-with`-Kante gegen jedes Subjekt ist die eine Aussage, für die die
|
||||
Seite existiert), `kb/sources/` verliert seinen `outbound:`-Block ersatzlos (dessen Contract
|
||||
sagt ausdrücklich, seine Verknüpfungen seien der mechanische Provenance-Pfad und keine
|
||||
Autorenkanten). Neu prüft `docs verify` die Kombination: ein `outbound:`-Block auf einer
|
||||
Collection, in die kein Typ mit `related:` schreibt, ist ein Befund und nennt beide Richtungen
|
||||
der Reparatur.
|
||||
|
||||
**`composition` / `part-of` ist das dritte Inversenpaar**, neben `depends-on` / `required-by`
|
||||
und `runs-on` / `hosts`. Aus der Messung, nicht vom Schreibtisch: der u3-Lauf hatte entschieden,
|
||||
die Gegenseite eines `composition` bekomme `see-also`, weil `part-of` ein Spiegel wäre. Ist es
|
||||
nicht — der Satz des Elternteils zählt seine Teile auf, der des Kindes benennt das Ganze, zu
|
||||
dem es gehört, und ein Leser, der auf dem Kind landet, braucht den zweiten. Übrig blieben 16
|
||||
`see-also`-Kanten für eine Beziehung, für die der Katalog ein Wort hat; sie sind auf `part-of`
|
||||
umgestellt. Ein Inversenpaar macht die Gegenkante weiterhin **nicht** zur Pflicht — Richtung
|
||||
wird verfasst, nicht gespiegelt —, es legt nur fest, welches Label sie trägt, wenn jemand sie
|
||||
schreibt.
|
||||
|
||||
**Stack- und Korpusänderung laufen hier in einem Zug**, entgegen der sonstigen Trennung. Der
|
||||
neue `docs verify`-Check würde eine bestehende 4.0.x-Instanz beim bloßen Kopieren der neuen
|
||||
Maschinerie fehlschlagen lassen, weil deren `kb/sources/COLLECTION.md` den `outbound:`-Block
|
||||
noch trägt — nach [instructions/dev/version-parts.md](instructions/dev/version-parts.md)
|
||||
Schritt 1 ein Grenzübertritt. Statt dafür eine `5.0.0` zu lösen, ist die Ursache mitbeseitigt:
|
||||
die Collection-Contracts dieser Instanz sind angepasst, und `dist export` leitet die
|
||||
`COLLECTION.md.template` daraus ab, also liefert jede neue Distribution die korrigierte Form
|
||||
aus. Für eine bereits bestehende 4.0.x-Instanz bleibt eine Handbewegung übrig, und sie wird
|
||||
hier benannt statt versteckt: die zwei `outbound:`-Zeilen aus `kb/sources/COLLECTION.md`
|
||||
löschen. Das neue `related:` im `comparison`-Type-Spec erreicht sie ohnehin nicht — die vier
|
||||
Page-Type-Specs gehören seit 4.0.0 der Instanz und werden nur als `.template` ausgeliefert.
|
||||
|
||||
Offen aus #40 bleibt nichts mehr; Befund 2 des Migrationslaufs (dem Katalog fehlt ein Register
|
||||
für Urheberschaft) ist als eigenes Issue erfasst.
|
||||
|
||||
---
|
||||
|
||||
## 4.0.1 - 2026-09-02 - Issue-Board: vier Pflicht-Label-Familien und Body-als-Wahrheit
|
||||
|
||||
**Author:** Torben Nehmer
|
||||
|
||||
Das Issue-Schema aus 1.2.1 hatte zwei Pflichtachsen und einen ausdrücklich begründeten Verzicht
|
||||
auf eine dritte: eine Taxonomie mit mehr Achsen brauche eigene Pflege, und das Board habe einen
|
||||
einzigen Betreuer. Diese Begründung ist entfallen, weil die Pflege inzwischen maschinell
|
||||
passiert - Body-Rewrites und Kommentare laufen über eine LLM-Sitzung, Menschen fassen in der
|
||||
Regel nur Labels an. Damit sind vier Achsen bezahlbar (Issue #41).
|
||||
|
||||
**Pflicht auf jedem offenen Issue sind jetzt vier Label:** `area/` (`kb`, `distribution`,
|
||||
`corpus`, `workflow`, `process` - kein `area/tools`, Tooling wird nach der bedienten Domäne
|
||||
einsortiert, nicht nach Codeort), `kind/` (`decision`, `build`, `defect`), `prio/`
|
||||
(`blocking`, `planned`, `waiting` - reine Umbenennung von `1`/`2`/`3`) und `size/` (`S`, `M`,
|
||||
`L`; `XS` entfällt). Dazu zwei optionale Flags: `status/blocked` für Abhängigkeit von einem
|
||||
anderen offenen Issue, `status/unconfirmed` für einen ungeprüften Verdacht, unter dem `size`
|
||||
und `prio` vorläufig sind. Ein `unconfirmed`-Issue endet in der Triage entweder ohne Flag und
|
||||
mit verbindlichen Werten oder geschlossen mit Begründung - die Prozessentsprechung zu
|
||||
Invariante 3.
|
||||
|
||||
**Der Issue-Body ist ab jetzt aktuelle Wahrheit, nicht Ursprungstext.** Die Umsetzung eines
|
||||
Issues zieht sich über mehrere, zeitlich getrennte Sitzungen, und der Body ist das einzige, was
|
||||
sie verbindet: eine Sitzung muss aus ihm allein rekonstruieren können, was entschieden und was
|
||||
offen ist. Er wird deshalb umgeschrieben statt ergänzt. Jeder Rewrite bekommt einen Kommentar,
|
||||
der ausschließlich benennt, was sich geändert hat - keine Vollkopie des alten Stands, weil ein
|
||||
Mensch zwei Fließtexte nicht diffen kann und eine Kopie pro Revision damit keine Historie ist,
|
||||
sondern nur eine weitere Kopie.
|
||||
|
||||
Geändert: [instructions/dev/issue-tracking.md](instructions/dev/issue-tracking.md) (Schritte 2,
|
||||
3, 5 neu; Schritt 4 um `area/` und `kind/` erweitert; der Entscheidungspunkt „Two labels feel
|
||||
too coarse?" entfällt) und die Beschreibungszeile in `instructions/dev/stack-dev/SKILL.md`. Für
|
||||
eine ausgelieferte Instanz ändert sich nichts: `dist export` schließt `instructions/dev/`
|
||||
vollständig aus, weshalb dies ein PATCH ist und kein MINOR - dieselbe Begründung wie bei
|
||||
`1.2.1`. Noch offen aus #41: `kb/concepts/Issue Label Scheme.md` beschreibt weiterhin das
|
||||
zweiachsige Schema und braucht eine eigene `wiki-manage`-Sitzung.
|
||||
|
||||
---
|
||||
|
||||
## 4.0.0 - 2026-09-02 - Prosa ist kein Identifier: Link-Taxonomie als Enum, generierte Regionen mit Markern
|
||||
|
||||
**Author:** Torben Nehmer
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
type: types/instruction.md
|
||||
name: issue-tracking
|
||||
description: Where open work on this stack is tracked, and what the prio/ and size/ labels on a Gitea issue mean.
|
||||
description: Where open work on this stack is tracked, what the four mandatory area/kind/prio/size labels and the two status flags on a Gitea issue mean, and how to keep an issue body current across sessions.
|
||||
---
|
||||
# Track open work as Gitea issues, not as prose in the repo
|
||||
|
||||
@@ -26,8 +26,14 @@ issues at that URL, which is exactly why `dist export` excludes
|
||||
the repo.
|
||||
- A session's findings outgrow the change it was making - a gap in the tooling,
|
||||
an assumption nobody has checked, a decision that needs the user.
|
||||
- Picking an issue up: before doing anything else, read the body as the current
|
||||
spec, and re-label it if the ground has moved since.
|
||||
- **While working on one:** the body is updated as the state moves, not at the
|
||||
end (step 2). A session that is interrupted leaves the body as its handover.
|
||||
- Prioritising: deciding what to pick up next, or re-labelling after the ground
|
||||
moved.
|
||||
- Closing one: the body is rewritten to its final state first, and only then
|
||||
closed (step 7).
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -36,38 +42,159 @@ issues at that URL, which is exactly why `dist export` excludes
|
||||
specific files or commands involved. An issue that only makes sense to
|
||||
whoever wrote it is a note, and notes were the problem.
|
||||
|
||||
2. **Give it exactly two labels: one `prio/`, one `size/`.** Both, always -
|
||||
a priority without a cost is half a decision. Neither is a promise about
|
||||
*when*; together they answer "what should I pick up in the time I have".
|
||||
2. **The body is the working state, not a historical first post - keep it
|
||||
current as you go.** It is this stack's plan file: the same thing a harness's
|
||||
own plan document is, and it is maintained the same way. Not written once,
|
||||
not brought up to date at the end, but **updated whenever something in it
|
||||
stops being true** - a decision made, a criterion met, an approach ruled out,
|
||||
a new constraint found.
|
||||
|
||||
| Priority | Means |
|
||||
The test is an abort, not a milestone. A session can end at any moment - an
|
||||
interrupt, a context limit, a crash, a human walking away - and whatever the
|
||||
body says at that instant is the entire handover. So the standard is: **at
|
||||
every point, a fresh session must be able to open the body and pick the work
|
||||
up from there**, without a human re-explaining it and without reading back
|
||||
through the comments. If the body would mislead someone who read it right
|
||||
now, it is already out of date, whether or not the work is finished.
|
||||
|
||||
That means updating *during* the work, not only at its end:
|
||||
|
||||
- a decision gets made → the decision and its reasoning replace the question
|
||||
- an acceptance criterion is done → tick it, in the same session that did it
|
||||
- something turns out differently than the issue assumed → the assumption is
|
||||
corrected where it stands, not contradicted three paragraphs later
|
||||
- work is deferred or dropped → say so, with the reason, where the criterion is
|
||||
|
||||
**Rewrite, never append.** Do not add to a text that has become wrong: an
|
||||
additively grown log forces every later reader to reconstruct the current
|
||||
state by filtering the whole history, which is the exact cost the body exists
|
||||
to remove. Comments carry the history (step 3); the body carries the state.
|
||||
|
||||
Body rewrites and comments are an LLM session's job. A human normally
|
||||
touches only labels and metadata directly.
|
||||
|
||||
3. **Comment a changelog, never a copy.** A body rewrite gets one short comment
|
||||
naming only what changed against the previous state - what is new, what is
|
||||
gone, what was corrected. Do not snapshot the old body into a comment: a full
|
||||
copy per revision forces a human to diff two prose texts, which is not a
|
||||
readable history, only another copy.
|
||||
|
||||
One comment per *session's worth* of change, not per edit. Step 2 asks the
|
||||
body to be kept current continuously, and a comment for every tick would bury
|
||||
the board in noise; the changelog line summarises what that session moved.
|
||||
Trivial upkeep - a typo, a tightened sentence - needs no comment at all.
|
||||
|
||||
```
|
||||
**Changelog:** Decision 2 tightened - `kind/` may now change over an
|
||||
issue's life. Old acceptance criterion 3 dropped (covered by #42).
|
||||
```
|
||||
|
||||
4. **Give it all four mandatory labels: one `area/`, one `kind/`, one `prio/`,
|
||||
one `size/`.** All four, always. Machine maintenance by an LLM session is
|
||||
what makes four axes affordable - the original objection to a third and
|
||||
fourth axis was the upkeep cost for a single human maintainer, and that
|
||||
objection no longer holds.
|
||||
|
||||
| `area/` | Means |
|
||||
|---|---|
|
||||
| `prio/1` | Blocks or damages work in progress. Next. |
|
||||
| `prio/2` | Accrues interest. Planned. |
|
||||
| `prio/3` | Worth doing, waiting on a trigger. |
|
||||
| `area/kb` | The `kb/` schema, contract, confidence machinery, lint - the knowledge base as a system. |
|
||||
| `area/distribution` | Shipping, upgrading and versioning an instance. |
|
||||
| `area/corpus` | The content and scope of `kb/` in this instance, and the demo/testbed question. |
|
||||
| `area/workflow` | Git, merging, branching, publish, PRs. |
|
||||
| `area/process` | The development process itself, rather than the stack as an artefact. |
|
||||
|
||||
`prio/3` is not a graveyard. It means the issue's value is real but gated on
|
||||
something outside it - a decision, another issue, a second instance
|
||||
There is deliberately no `area/tools`: tooling is filed under the domain it
|
||||
serves, not under where its code sits. The axis follows the stage split in
|
||||
[AGENTS.md](../../AGENTS.md).
|
||||
|
||||
| `kind/` | Means |
|
||||
|---|---|
|
||||
| `kind/decision` | Waiting on an operator decision. |
|
||||
| `kind/build` | Specified; waiting only on implementation time. |
|
||||
| `kind/defect` | A finding: documentation and reality, or two documents, contradict each other. |
|
||||
|
||||
`kind/` is expected to change over an issue's life - `decision` becomes
|
||||
`build` once the decision is made. That is session memory working, not a
|
||||
labelling failure.
|
||||
|
||||
| `prio/` | Means |
|
||||
|---|---|
|
||||
| `prio/blocking` | Blocks or damages work in progress. Next. |
|
||||
| `prio/planned` | Accrues interest. Planned. |
|
||||
| `prio/waiting` | Worth doing, waiting on a trigger. |
|
||||
|
||||
`prio/waiting` is not a graveyard. It means the issue's value is real but
|
||||
gated on something outside it - a decision, another issue, a second instance
|
||||
existing. Name that trigger in the issue, or the label is a polite no.
|
||||
|
||||
| Size | Means |
|
||||
| `size/` | Means |
|
||||
|---|---|
|
||||
| `size/XS` | Minutes. Often just a decision or an observation to record. |
|
||||
| `size/S` | One session, one publish, a clear cut. |
|
||||
| `size/M` | Several files; a contract or instruction change; its own test effort. |
|
||||
| `size/L` | Several sessions, or open design questions before the first commit. |
|
||||
|
||||
Size is effort, not importance. A `prio/1 size/XS` is the best thing on the
|
||||
board; a `prio/3 size/L` is a thing to talk about before anyone starts.
|
||||
Size is effort, not importance. A `prio/blocking size/S` is the best thing
|
||||
on the board; a `prio/waiting size/L` is a thing to talk about before anyone
|
||||
starts.
|
||||
|
||||
3. **Re-label when the ground moves, and say why in a comment.** A trigger that
|
||||
fired turns `prio/3` into `prio/2`. A design question that got answered can
|
||||
drop a size. Silent re-labelling is how a board stops meaning anything.
|
||||
5. **Add a `status/` flag only when it applies.** Both are optional, because
|
||||
each describes a temporary condition rather than a property every issue has.
|
||||
|
||||
4. **Close with what actually happened**, not with a commit hash alone: which
|
||||
proposals were implemented, which were deliberately left out and why, and
|
||||
what was verified. The issue is the only place that record survives - a
|
||||
changelog entry says what changed, not what was decided against.
|
||||
| `status/` | Means |
|
||||
|---|---|
|
||||
| `status/blocked` | Waiting on another, still-open issue - not workable on its own, whatever its `prio/` says. Name the blocking issue in the body. |
|
||||
| `status/unconfirmed` | A reported suspicion, not yet checked against actual behaviour. Applies to any `kind/`, not just `kind/defect`. |
|
||||
|
||||
While `status/unconfirmed` is set, `size/` and `prio/` are provisional. Triage
|
||||
ends it one of two ways: the flag comes off and `size`/`prio` are set for
|
||||
real, or the issue is closed with the reason. An unverified suspicion does not
|
||||
stay open indefinitely - the process-level analogue of AGENTS.md invariant 3.
|
||||
|
||||
6. **Re-label when the ground moves, and say why in a comment.** A trigger that
|
||||
fired turns `prio/waiting` into `prio/planned`. A design question that got
|
||||
answered can drop a size and move `kind/decision` to `kind/build`. Silent
|
||||
re-labelling is how a board stops meaning anything.
|
||||
|
||||
7. **Closing is the last body update, not a comment.** If step 2 was followed
|
||||
the body is already nearly there, and closing only settles what the final
|
||||
run established. If it was not, closing is where the whole debt comes due -
|
||||
and it comes due at the worst moment, because a closed body is the version
|
||||
everyone reads afterwards and nobody revisits.
|
||||
|
||||
Either way the body reaches its final state *before* the issue closes:
|
||||
proposals that were decided read as decided, a "to decide" section has become
|
||||
the decision with its reasoning, acceptance criteria are ticked or struck with
|
||||
a reason, and what was verified is named. Then close, with the one-line
|
||||
changelog comment step 3 asks for.
|
||||
|
||||
Record what actually happened, not a commit hash alone: which proposals were
|
||||
implemented, which were deliberately left out and why, and what was verified.
|
||||
The issue is the only place that record survives - a changelog entry says
|
||||
what changed, not what was decided against.
|
||||
|
||||
**A closing report in a comment does not satisfy this.** It reads as
|
||||
complete to whoever writes it and leaves a body still phrased as open work:
|
||||
unticked boxes, an undecided decision section, present tense about a defect
|
||||
that no longer exists. #44 closed exactly that way, with a thorough comment
|
||||
above a body that still asked for a decision that had already been made and
|
||||
shipped. Nothing mechanical catches it (see below), which is why it is a step
|
||||
rather than a habit.
|
||||
|
||||
## What no tool checks
|
||||
|
||||
`wikitool` does not know this tracker exists, and should not learn. It ships to
|
||||
instances that have no issues at that URL, while this file and the workflow it
|
||||
describes are pruned by `dist export` - a Gitea client inside the shipped tool
|
||||
would be a dev-only dependency carried by every instance, to check a board none
|
||||
of them have. The tracker is reachable only through the `gitea-mcp` server, in a
|
||||
session, by an agent.
|
||||
|
||||
So there is no `docs verify` for the board. Nothing reports a closed issue whose
|
||||
body still reads as open, a body that contradicts its own comments, or an issue
|
||||
missing one of the four mandatory labels. Every one of those is caught by a
|
||||
session following this file, or not at all - which is the argument for the
|
||||
sequence in step 7 being explicit about the order (body first, then close),
|
||||
rather than leaving it to be inferred from step 2.
|
||||
|
||||
## Decision points
|
||||
|
||||
@@ -75,8 +202,14 @@ issues at that URL, which is exactly why `dist export` excludes
|
||||
what shipped. A finished change needs both: the entry, and the issue closed
|
||||
with the reasoning.
|
||||
- **Issue or `kb/` page?** An issue is about *this stack* and is ephemeral - it
|
||||
closes. A `kb/` page is compiled knowledge that stays true. Never put wiki
|
||||
content findings in an issue, and never file a work item as a page.
|
||||
- **Two labels feel too coarse?** They are meant to. A third axis - kind, area,
|
||||
status - is the point at which a taxonomy starts needing maintenance of its
|
||||
own, and this board has one maintainer.
|
||||
closes, and it records a wish. A `kb/` page is verified knowledge that stays
|
||||
true. Never put wiki content findings in an issue, and never file a work item
|
||||
as a page.
|
||||
- **Rewrite the body, or add a comment?** Rewrite whenever a reader of the body
|
||||
alone would otherwise be misled - a changed decision, a dropped criterion, a
|
||||
new constraint. A comment carries the changelog line for that rewrite, and
|
||||
nothing else that a future session needs in order to act. Closing an issue is
|
||||
always a rewrite - see step 7.
|
||||
- **An old issue carries only `prio/` and `size/`?** Complete it to all four
|
||||
when you touch it, rather than in a sweep. The board reaches the new scheme
|
||||
issue by issue, as each is picked up.
|
||||
|
||||
@@ -43,8 +43,11 @@ stack development happens in the origin repo instead (see AGENTS.md's routing li
|
||||
engineering, memory and deploy-time learning; consult before a design decision in those
|
||||
areas.
|
||||
[issue-tracking.md](../issue-tracking.md) - open work lives in Gitea issues, one per work
|
||||
package, labelled `prio/1..3` and `size/XS..L`. There is no `TODO.md`. Read it before
|
||||
filing something for later, or before deciding what to pick up next.
|
||||
package, labelled `area/`, `kind/`, `prio/` and `size/`. There is no `TODO.md`. **The body
|
||||
of the issue you are working on is this session's plan file:** keep it current as the state
|
||||
moves, not at the end, so an interrupted session leaves a body the next one can resume from.
|
||||
Read it before filing something for later, before editing or closing an issue, or before
|
||||
deciding what to pick up next.
|
||||
[testing-conventions.md](../testing-conventions.md) - the suite runs against a deliberately
|
||||
empty machine; what the autouse fixture already neutralizes, and what a test still has to
|
||||
establish itself. Read it before adding or changing a test.
|
||||
|
||||
@@ -40,6 +40,48 @@ resolved paths and `conventions`' parsed `kb/CONVENTIONS.md`. A test that *rewri
|
||||
conventions file mid-test calls `conventions.reset_cache()` itself - the fixture answers for the
|
||||
boundary between tests, not for one inside a test.
|
||||
|
||||
## Which tree a test writes into
|
||||
|
||||
The environment is one half of the isolation; `config.ROOT` is the other. With `CHEMENU_ROOT`
|
||||
cleared, `ROOT` falls back to the checkout pytest is running from - deliberately, because most
|
||||
tests want the shipped `types/`. It also means that any code path resolving a file through
|
||||
`config.ROOT` or `config.KB_DIR` reaches **the real repository**, no matter which tree the
|
||||
fixture built.
|
||||
|
||||
Both corpus fixtures therefore repoint it: `raw_dir` and `kb_dir` each set
|
||||
`config.ROOT` to their `tmp_path` and re-declare the shipped `types/` through
|
||||
`use_shipped_type_specs()`. `config`'s module `__getattr__` resolves the derived paths on
|
||||
access, so repointing `ROOT` carries `KB_DIR`, `RAW_DIR` and the rest with it. A new fixture
|
||||
that builds a tree does the same thing - that is the rule here, not a per-test judgment.
|
||||
|
||||
`kb_dir` did not, until Gitea #44. Two things came of that. A test calling
|
||||
`kb_state.write_kb_state()` overwrote the real `.wikitool-kb.json`, which `git status` made
|
||||
visible within the minute. Quieter and worse: `lint`'s collection lookup resolved a page
|
||||
against `config.KB_DIR`, so every fixture page read back as "no collection" and the
|
||||
`unauthorised_labels` check skipped every edge in silence - the finding had no working test at
|
||||
all, and its green run read like an assurance.
|
||||
|
||||
Two guards came out of it, both in `conftest.py`:
|
||||
|
||||
| Guard | Default | Cost |
|
||||
|---|---|---|
|
||||
| `repository_tree_guard` (session) | on | two `git status --porcelain` calls per run |
|
||||
| `per_test_tree_guard` | off, `CHEMENU_TREE_GUARD=each` turns it on | one `git status` per test |
|
||||
|
||||
The session guard compares the working tree before against after and fails the run if anything
|
||||
moved, so it says nothing about uncommitted work a developer already had. It cannot name the
|
||||
test that did it; `CHEMENU_TREE_GUARD=each` can, and is the way to bisect once it fires. Where
|
||||
git is unavailable or the checkout is not a repository, both are silently inert.
|
||||
|
||||
Neither guard sees the second, quieter half: a check that silently *does nothing* under test
|
||||
writes no file. That one is only caught by a test that asserts the finding actually fires -
|
||||
which is why `test_unauthorised_label_is_judged_in_a_tree_that_is_not_the_configured_kb`
|
||||
lints a tree `ROOT` deliberately points away from.
|
||||
|
||||
**A function that takes a directory resolves against that directory.** `run_lint(kb_dir)`
|
||||
reading `config.KB_DIR` for one of its own lookups was the defect behind the quiet half, and
|
||||
no fixture can fix that shape from the outside.
|
||||
|
||||
## When to run
|
||||
|
||||
Whenever you add or change a test under `tools/chemenu/tests/`.
|
||||
@@ -80,7 +122,12 @@ Whenever you add or change a test under `tools/chemenu/tests/`.
|
||||
`conftest.py` in the same change. A variable the tool reads and the fixture does not clear
|
||||
is the exact hole this whole file is about, reopened.
|
||||
|
||||
5. **Verify against an empty machine before publishing**, not only in your own shell:
|
||||
5. **Writing a fixture that builds a tree?** Repoint `config.ROOT` at it and call
|
||||
`use_shipped_type_specs(monkeypatch)`, as `raw_dir` and `kb_dir` do - see
|
||||
[Which tree a test writes into](#which-tree-a-test-writes-into). A fixture that returns a
|
||||
path without repointing hands the code under test the real repository.
|
||||
|
||||
6. **Verify against an empty machine before publishing**, not only in your own shell:
|
||||
|
||||
```bash
|
||||
cd tools && env -i PATH="$PATH" HOME="$(mktemp -d)" \
|
||||
@@ -92,7 +139,7 @@ Whenever you add or change a test under `tools/chemenu/tests/`.
|
||||
`.venv/bin/python -m pytest -q`. A difference between the two is a leak, and the leaking
|
||||
variable belongs in step 4's list.
|
||||
|
||||
6. **Check the coverage report when adding tests to close a gap**, rather than guessing which
|
||||
7. **Check the coverage report when adding tests to close a gap**, rather than guessing which
|
||||
lines were uncovered:
|
||||
|
||||
```bash
|
||||
|
||||
@@ -40,9 +40,18 @@ edge merely to mirror the first one.** The inbound view is rendered from the gra
|
||||
`index rebuild` and `search`, so a reader landing on the target sees what points at it whether
|
||||
or not anyone wrote a second edge.
|
||||
|
||||
That is why most labels below have no inverse. Only two pairs do, because in each the reverse
|
||||
That is why most labels below have no inverse. Only three pairs do, because in each the reverse
|
||||
direction is a genuine primary statement someone would write on its own: `depends-on` /
|
||||
`required-by` and `runs-on` / `hosts`.
|
||||
`required-by`, `runs-on` / `hosts`, and `composition` / `part-of`.
|
||||
|
||||
The third was added after the 4.0.0 migration, from measurement rather than from the desk. A
|
||||
parent-child structure - a tier list and its tiers, a spectrum and its levels - produces the
|
||||
question on nearly every page: the parent writes `composition`, and the child then reaches for
|
||||
either `part-of` or `see-also`. The migration run answered `see-also`, on the reading that
|
||||
`part-of` would be a mirror, and left sixteen edges saying "these two are related" about a
|
||||
relationship the catalogue already had a word for. It is not a mirror: the parent's sentence
|
||||
lists its parts, the child's names the whole it belongs to, and a reader landing on the child
|
||||
needs the second one.
|
||||
|
||||
## When to run
|
||||
|
||||
@@ -129,6 +138,13 @@ Inference and comparison between ideas.
|
||||
| `composition` | is composed of the target |
|
||||
| `part-of` | is a component of the target |
|
||||
|
||||
`composition` / `part-of` is the third **inverse pair**, alongside `depends-on` / `required-by`
|
||||
and `runs-on` / `hosts` in the operational register. Being a pair does not make the second edge
|
||||
obligatory - direction is still authored - it settles *which label* the second edge takes when
|
||||
someone does write it. The child of a `composition` writes `part-of`, not `see-also`: what it
|
||||
is a component of is a primary statement about the child, and `see-also` says strictly less
|
||||
about the same fact.
|
||||
|
||||
`grounds` / `rests-on` is a genuine pair and both directions are primary statements; they are
|
||||
listed separately rather than as inverses because either page may legitimately carry only its
|
||||
own side.
|
||||
|
||||
@@ -36,8 +36,9 @@ you know the run is finished.
|
||||
**Nothing breaks while it is outstanding.** Unlabelled edges and undelimited regions are read,
|
||||
not rejected: `links.py` treats a bare title as an edge whose label is not declared yet, and
|
||||
`provenance.split_cite_block` falls back to the pre-marker layout. That is deliberate - a corpus
|
||||
has to stay readable while it is being converted - and it is why the two lint findings are
|
||||
advisory until step 6 promotes them.
|
||||
has to stay readable while it is being converted - and it is why the two lint findings stay
|
||||
advisory for as long as `kb_version` is below 4.0.0, which is exactly as long as this document
|
||||
is outstanding.
|
||||
|
||||
## Steps
|
||||
|
||||
@@ -102,7 +103,7 @@ advisory until step 6 promotes them.
|
||||
is otherwise silent: the region becomes ordinary prose and the next write appends a second
|
||||
one beside it.
|
||||
|
||||
6. **Record it, then tighten the checks:**
|
||||
6. **Record it. The checks tighten themselves:**
|
||||
|
||||
```bash
|
||||
tools/wikitool lint # unlabelled_edges and unauthorised_labels must be 0
|
||||
@@ -110,8 +111,14 @@ advisory until step 6 promotes them.
|
||||
```
|
||||
|
||||
Only once `lint` reports zero of both is the run finished. The two findings are advisory
|
||||
during the window and become hard errors afterwards - the same path
|
||||
`legacy_citation_markers` took after the citation migration.
|
||||
while `kb_version` is below 4.0.0 and hard from the moment `migrate done` records it -
|
||||
nothing to flip by hand, and no window in which a half-converted corpus is refused by the
|
||||
check that is measuring its progress.
|
||||
|
||||
Do not record the migration to silence the findings. The promotion is what makes the run
|
||||
stick: after it, a bare title in `related:` is a hard error rather than a page still
|
||||
waiting, so a corpus recorded early fails its next lint instead of quietly keeping the old
|
||||
shape.
|
||||
|
||||
## How to tell a migrated page from an unmigrated one
|
||||
|
||||
|
||||
@@ -3,8 +3,10 @@ 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."
|
||||
summary: "Vergleich zweier AMD-CPU-Power-Management-Treiber: CPPC-basiertes amd-pstate gegen\xFCber ACPI-basiertem acpi-cpufreq."
|
||||
related:
|
||||
- compares-with: amd-pstate
|
||||
- compares-with: acpi-cpufreq
|
||||
---
|
||||
# Comparison: amd-pstate vs acpi-cpufreq
|
||||
|
||||
@@ -131,13 +133,9 @@ ls /sys/devices/system/cpu/cpu0/cpufreq/cppc_*
|
||||
|
||||
**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.
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **compares:** [[amd-pstate]]
|
||||
- **compares:** [[acpi-cpufreq]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[amd-pstate]]
|
||||
- [[acpi-cpufreq]]
|
||||
|
||||
- **compares-with:** [[amd-pstate]]
|
||||
- **compares-with:** [[acpi-cpufreq]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- exemplifies: Structural Enforcement over Documented Rule
|
||||
- contrasts: Green Suite Blind Spot
|
||||
- exemplifies: wikitool
|
||||
- exemplifies: Gitea Actions
|
||||
sources: [Source - Conversation - Hardening the Test Suite Against Silent Environment Dependencies Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -101,26 +105,21 @@ wird sie erst auf einer fremden Maschine - und wenn niemand die Suite je woander
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Structural Enforcement over Documented Rule]]
|
||||
- **contrasts:** [[Green Suite Blind Spot]]
|
||||
- **exemplifies:** [[wikitool]]
|
||||
- **exemplifies:** [[Gitea Actions]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ concept_type: workflow
|
||||
tags: [cramming, heuristic, pages, creation]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Content Quality Control, Iteration and Cost Limits]
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Iteration and Cost Limits
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -46,21 +48,20 @@ Die Anti-Cramming-Heuristik ist eine Entscheidungsregel, die hilft zu bestimmen,
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- exemplifies: Implementation Spectrum
|
||||
- enables: Multi-Agent Collaboration
|
||||
- part-of: Privacy and Governance
|
||||
- enables: Quality and Self-Correction
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
- enables: Supersession
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +44,14 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **enables:** [[Multi-Agent Collaboration]]
|
||||
- **part-of:** [[Privacy and Governance]]
|
||||
- **enables:** [[Quality and Self-Correction]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
- **enables:** [[Supersession]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
+12
-1
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
related:
|
||||
- part-of: Hybrid Search
|
||||
- see-also: LLM Wiki Pattern
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +41,11 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Hybrid Search]]
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Privacy and Governance, Implementation Spectrum, Mass-Update Gate]
|
||||
related:
|
||||
- part-of: Privacy and Governance
|
||||
- exemplifies: Implementation Spectrum
|
||||
- see-also: Mass-Update Gate
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -41,9 +44,12 @@ TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **ergaenzt:** [[Mass-Update Gate]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Mass-Update Gate]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Privacy and Governance]]
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ concept_type: workflow
|
||||
tags: [pre-commit, hooks, automation, quality-control]
|
||||
created: 2026-08-03
|
||||
modified: 2026-09-01
|
||||
related: [wikitool, Gitea Actions]
|
||||
related:
|
||||
- invokes: wikitool
|
||||
- operates-on: Gitea Actions
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - Conversation - Nightly Drift-Check Workflow and doctor's Bootstrap Gap Session 2026-08-31]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -82,24 +84,23 @@ Bootstrap-Anspruch an eine Instanz statt an einen bloßen Checkout).
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **invokes:** [[wikitool]]
|
||||
- **operates-on:** [[Gitea Actions]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
+11
-5
@@ -4,7 +4,10 @@ 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]
|
||||
related:
|
||||
- see-also: Linux Kernel
|
||||
- mechanism: amd-pstate
|
||||
- see-also: Kernel PM Governors
|
||||
sources: [Source - AMD Powermanagement CPU]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -75,7 +78,10 @@ CPPC bietet mehrere Schlüsselmöglichkeiten:
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[amd-pstate]]
|
||||
- [[acpi-cpufreq]]
|
||||
- [[Kernel PM Governors]]
|
||||
- [[Linux Kernel]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Linux Kernel]]
|
||||
- **mechanism:** [[amd-pstate]]
|
||||
- **see-also:** [[Kernel PM Governors]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ concept_type: workflow
|
||||
tags: [audit, checkpoint, rhythm, quality]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Semantic Lint Automation, Content Quality Control]
|
||||
related:
|
||||
- see-also: Semantic Lint Automation
|
||||
- part-of: Content Quality Control
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -64,3 +66,10 @@ Das Checkpoint Audit definiert einen regelmäßigen Rhythmus für Qualitätssich
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Semantic Lint Automation]]
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ 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]
|
||||
related:
|
||||
- mechanism: Claude Code
|
||||
- contradicts: Diff-Reviewable Agent Edits
|
||||
sources: [Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -96,15 +98,17 @@ ist hier also die eingebaute Voreinstellung, keine getroffene Wahl.
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[Claude Code]]
|
||||
- **contradicts:** [[Diff-Reviewable Agent Edits]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,12 @@ 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]
|
||||
related:
|
||||
- exemplifies: wikitool
|
||||
- enables: Self-Healing
|
||||
- contrasts: Detect-Repair Asymmetry
|
||||
- see-also: Green Suite Blind Spot
|
||||
- contrasts: 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
|
||||
@@ -93,29 +98,24 @@ Seite, die kein Befehl mehr reparieren kann, ist eine Sackgasse.
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[wikitool]]
|
||||
- **enables:** [[Self-Healing]]
|
||||
- **contrasts:** [[Detect-Repair Asymmetry]]
|
||||
- **see-also:** [[Green Suite Blind Spot]]
|
||||
- **contrasts:** [[Write-Once Frontmatter Fields]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ concept_type: pattern
|
||||
tags: [confidence, scoring, reliability, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memory Lifecycle, LLM Wiki Pattern]
|
||||
related:
|
||||
- part-of: Memory Lifecycle
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -128,3 +130,10 @@ Aussage: „Das CI-System verwendet BuildKit auf Port 1234." (als Tatsache angeg
|
||||
- [[Event-Driven Automation]] (für automatisierte Konfidenz-Updates)
|
||||
- [[Contradiction Resolution]] (für Konfliktbehandlung)
|
||||
- [[Self-Healing]] (für automatisierte Konfidenz-Reparatur)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- part-of: Memory Lifecycle
|
||||
- composition: Working Memory
|
||||
- composition: Episodic Memory
|
||||
- composition: Semantic Memory
|
||||
- composition: Procedural Memory
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -189,12 +195,6 @@ Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -203,3 +203,14 @@ Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
- [[Confidence Scoring]] (für ebenenspezifische Konfidenz)
|
||||
- [[Event-Driven Automation]] (für Förderungstrigger)
|
||||
- [[Knowledge Graph]] (für ebenenübergreifende Beziehungen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Working Memory]]
|
||||
- **composition:** [[Episodic Memory]]
|
||||
- **composition:** [[Semantic Memory]]
|
||||
- **composition:** [[Procedural Memory]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: [quality, lint, thresholds, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Semantic Lint Automation, Stub Threshold, Split Threshold]
|
||||
related:
|
||||
- composition: Semantic Lint Automation
|
||||
- composition: Stub Threshold
|
||||
- composition: Split Threshold
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -45,9 +48,6 @@ Content Quality Control bezieht sich auf die Menge der Regeln, Schwellwerte und
|
||||
|
||||
## 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
|
||||
@@ -57,3 +57,11 @@ Content Quality Control bezieht sich auf die Menge der Regeln, Schwellwerte und
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **composition:** [[Semantic Lint Automation]]
|
||||
- **composition:** [[Stub Threshold]]
|
||||
- **composition:** [[Split Threshold]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: architecture
|
||||
tags: [context, isolation, efficiency]
|
||||
created: 2026-08-04
|
||||
modified: 2026-08-29
|
||||
related: []
|
||||
related:
|
||||
- see-also: Token Economics
|
||||
- see-also: Scale Ceiling
|
||||
- see-also: Workflow Extraction
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -50,9 +53,6 @@ Context Isolation ist weniger wirksam, wenn:
|
||||
## Verwandte Konzepte
|
||||
|
||||
- [[Cross-platform Agent Skills]]
|
||||
- [[Token Economics]]
|
||||
- [[Scale Ceiling]]
|
||||
- [[Workflow Extraction]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
@@ -61,3 +61,11 @@ Context Isolation ist weniger wirksam, wenn:
|
||||
## Fußnoten
|
||||
|
||||
[^s-copilot-skill-restructure-instructions]: [[Source - Copilot Skill Restructure Instructions]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Token Economics]]
|
||||
- **see-also:** [[Scale Ceiling]]
|
||||
- **see-also:** [[Workflow Extraction]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- rests-on: Confidence Scoring
|
||||
- see-also: Event-Driven Automation
|
||||
- see-also: Multi-Agent Collaboration
|
||||
- part-of: Quality and Self-Correction
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
- enables: Supersession
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +44,14 @@ TODO
|
||||
## Verwandte Konzepte
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[Confidence Scoring]]
|
||||
- **see-also:** [[Event-Driven Automation]]
|
||||
- **see-also:** [[Multi-Agent Collaboration]]
|
||||
- **part-of:** [[Quality and Self-Correction]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
- **enables:** [[Supersession]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ concept_type: architecture
|
||||
tags: [skills, agents, cross-platform]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
related:
|
||||
- rests-on: Context Isolation
|
||||
- rests-on: Token Economics
|
||||
- see-also: Scale Ceiling
|
||||
- see-also: Workflow Extraction
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -66,13 +70,6 @@ Dieses Muster vermeiden, wenn:
|
||||
- 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]]
|
||||
@@ -82,3 +79,12 @@ Dieses Muster vermeiden, wenn:
|
||||
|
||||
[^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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[Context Isolation]]
|
||||
- **rests-on:** [[Token Economics]]
|
||||
- **see-also:** [[Scale Ceiling]]
|
||||
- **see-also:** [[Workflow Extraction]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ 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]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- part-of: Memory Lifecycle
|
||||
- rests-on: Event-Driven Automation
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
@@ -138,9 +141,6 @@ Mit [[Event-Driven Automation]] integrieren:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -148,3 +148,11 @@ Mit [[Event-Driven Automation]] integrieren:
|
||||
|
||||
- [[Implementation Spectrum]] (Crystallization als erweiterte Funktion)
|
||||
- [[Quality and Self-Correction]] (Sicherung der Qualität kristallisierten Inhalts)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Event-Driven Automation]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: decision
|
||||
tags: []
|
||||
created: 2026-09-01
|
||||
modified: 2026-09-01
|
||||
related: [Chemenu]
|
||||
related:
|
||||
- operates-on: Chemenu
|
||||
sources: ['Source - Public Release, Corpus Purge and History Squash Session 2026-09-01', Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -63,11 +64,13 @@ sonst unverändertem Inhalt) vorzuziehen - wenn ein unterstütztes Löschkommand
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **gilt fuer:** [[Chemenu]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
|
||||
- [[Chemenu]]
|
||||
- [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **operates-on:** [[Chemenu]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ 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]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
- grounds: Write-Once Frontmatter Fields
|
||||
- see-also: 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
|
||||
@@ -83,21 +86,20 @@ Angenommen (2026-08-31) mit Stack-Version `1.4.0`, Commit
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **grounds:** [[Write-Once Frontmatter Fields]]
|
||||
- **see-also:** [[Green Suite Blind Spot]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- exemplifies: wikitool
|
||||
- rests-on: Lint Workflow
|
||||
- contrasts: Self-Healing
|
||||
- see-also: Issue Label Scheme
|
||||
- contrasts: Write-Once Frontmatter Fields
|
||||
- contrasts: 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
|
||||
@@ -102,34 +108,27 @@ auftritt.
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[wikitool]]
|
||||
- **rests-on:** [[Lint Workflow]]
|
||||
- **contrasts:** [[Self-Healing]]
|
||||
- **see-also:** [[Issue Label Scheme]]
|
||||
- **contrasts:** [[Write-Once Frontmatter Fields]]
|
||||
- **contrasts:** [[Command Round-Trip Integrity]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ 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]
|
||||
related:
|
||||
- see-also: Claude Code Auto Mode
|
||||
- operates-on: Claude Code
|
||||
- derived-from: Write-Once Frontmatter Fields
|
||||
sources: [Source - Conversation - Auto Mode and Tool Choice Session 2026-08-31]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -75,17 +78,18 @@ Angenommen (2026-08-31), auf Anweisung des Nutzers, für Sitzungen an diesem Rep
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Claude Code Auto Mode]]
|
||||
- **operates-on:** [[Claude Code]]
|
||||
- **derived-from:** [[Write-Once Frontmatter Fields]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: decision
|
||||
tags: []
|
||||
created: 2026-09-01
|
||||
modified: 2026-09-01
|
||||
related: [Chemenu]
|
||||
related:
|
||||
- operates-on: Chemenu
|
||||
sources: ['Source - Public Release, Corpus Purge and History Squash Session 2026-09-01']
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -56,16 +57,14 @@ Distributions-/Build-Werkzeug ohnehin pflegt.
|
||||
separate, maschinell nachvollziehbare Grenze existiert - dort wäre die Lizenz-Zuordnung selbst
|
||||
wieder eine unabhängige, drift-anfällige Liste.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Chemenu]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **gilt fuer:** [[Chemenu]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
|
||||
- [[Chemenu]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **operates-on:** [[Chemenu]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Knowledge Graph, Source - LLM Wiki v2]
|
||||
related:
|
||||
- exemplifies: Implementation Spectrum
|
||||
- enables: Knowledge Graph
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -37,4 +40,10 @@ TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **enables:** [[Knowledge Graph]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -37,4 +38,8 @@ TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: [automation, hooks, events, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memory Lifecycle, Hooks]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- enables: Memory Lifecycle
|
||||
- rests-on: Hooks
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -169,9 +172,6 @@ Mit **Stufe 2 (Basis)** beginnen und Ereignisse nach Bedarf hinzufügen:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -183,3 +183,11 @@ Mit **Stufe 2 (Basis)** beginnen und Ereignisse nach Bedarf hinzufügen:
|
||||
- [[Forgetting]] (angewandt durch Automatisierung)
|
||||
- [[Hybrid Search]] (verwendet in Query-Automatisierung)
|
||||
- [[Contradiction Resolution]] (ausgelöst durch Automatisierung)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **enables:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Hooks]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Privacy and Governance]
|
||||
related:
|
||||
- exemplifies: Implementation Spectrum
|
||||
- part-of: Privacy and Governance
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -37,4 +39,9 @@ TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **part-of:** [[Privacy and Governance]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: [memory, retention, decay, ebbinghaus]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memory Lifecycle, Confidence Scoring, Consolidation Tiers]
|
||||
related:
|
||||
- part-of: Memory Lifecycle
|
||||
- see-also: Confidence Scoring
|
||||
- rests-on: Consolidation Tiers
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -149,9 +152,6 @@ Fakten mit niedrigerer Priorität:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -159,3 +159,11 @@ Fakten mit niedrigerer Priorität:
|
||||
|
||||
- [[Event-Driven Automation]] (für automatisiertes Verstärkungstracking)
|
||||
- [[Quality and Self-Correction]] (für verwandte Qualitätsmechanismen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **see-also:** [[Confidence Scoring]]
|
||||
- **rests-on:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, Knowledge Graph, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
related:
|
||||
- part-of: Hybrid Search
|
||||
- rests-on: Knowledge Graph
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -37,4 +41,11 @@ TODO
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Hybrid Search]]
|
||||
- **rests-on:** [[Knowledge Graph]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,12 @@ 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]
|
||||
related:
|
||||
- see-also: Command Round-Trip Integrity
|
||||
- exemplifies: wikitool
|
||||
- see-also: Denylist over Allowlist
|
||||
- see-also: Ambient Environment Dependency
|
||||
- rests-on: 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
|
||||
@@ -110,30 +115,26 @@ widersprechen: jede für sich ist getestet, das Zusammenspiel hat nie jemand auf
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Command Round-Trip Integrity]]
|
||||
- **exemplifies:** [[wikitool]]
|
||||
- **see-also:** [[Denylist over Allowlist]]
|
||||
- **see-also:** [[Ambient Environment Dependency]]
|
||||
- **rests-on:** [[Lint Workflow]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
+10
-3
@@ -4,7 +4,9 @@ concept_type: workflow
|
||||
tags: [automation, events, triggers, workflow]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Event-Driven Automation, LLM Wiki Pattern]
|
||||
related:
|
||||
- grounds: Event-Driven Automation
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
@@ -129,8 +131,6 @@ Hooks sollten **robust** sein:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -140,3 +140,10 @@ Hooks sollten **robust** sein:
|
||||
- [[Consolidation Tiers]] (hochgestuft durch Hooks)
|
||||
- [[Forgetting]] (angewandt durch Hooks)
|
||||
- [[Confidence Scoring]] (aktualisiert durch Hooks)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **grounds:** [[Event-Driven Automation]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: BM25
|
||||
- composition: Vector Search
|
||||
- composition: Reciprocal Rank Fusion
|
||||
- rests-on: Knowledge Graph
|
||||
- see-also: Graph Traversal
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -115,15 +121,20 @@ Abfrage: "Wie funktioniert das Auth-System?"
|
||||
|
||||
## 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)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[BM25]]
|
||||
- **composition:** [[Vector Search]]
|
||||
- **composition:** [[Reciprocal Rank Fusion]]
|
||||
- **rests-on:** [[Knowledge Graph]]
|
||||
- **see-also:** [[Graph Traversal]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -41,7 +41,7 @@
|
||||
| [[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 |
|
||||
| [[Issue Label Scheme]] | decision | Pflicht-Labelschema fuer das Gitea-Board: seit 2026-09-02 vier Achsen (area/kind/prio/size) plus zwei optionale status/-Flags, dazu der Issue-Body als aktuelle Wahrheit; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf | 2026-09-02 |
|
||||
| [[Iteration and Cost Limits]] | workflow | Im Code durchgesetzte Obergrenze von 60 wikitool-Aufrufen je Session, Loop-Breaker bei 3 identischen Wiederholungen, Slot-Erstattung, ein gemessenes Kalibrierungsband, und Retrieval sowie der MCP-Leseserver bleiben ausgenommen | 2026-09-02 |
|
||||
| [[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 (Drop-in-Ersatz) und Inhaltsmigration sind seit 2.5.0 getrennte, unabhaengig geprueft Fragen | 2026-09-02 |
|
||||
|
||||
@@ -4,7 +4,14 @@ 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]
|
||||
related:
|
||||
- rests-on: LLM Wiki Pattern
|
||||
- composition: Memory Lifecycle
|
||||
- composition: Knowledge Graph
|
||||
- composition: Event-Driven Automation
|
||||
- composition: Multi-Agent Collaboration
|
||||
- composition: Privacy and Governance
|
||||
- composition: Crystallization
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -224,16 +231,21 @@ Level 0 → Level 1 → Level 2 → Level 3 → Level 4 → Level 5 → Level 6
|
||||
|
||||
## 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)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[LLM Wiki Pattern]]
|
||||
- **composition:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Knowledge Graph]]
|
||||
- **composition:** [[Event-Driven Automation]]
|
||||
- **composition:** [[Multi-Agent Collaboration]]
|
||||
- **composition:** [[Privacy and Governance]]
|
||||
- **composition:** [[Crystallization]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Split Threshold
|
||||
- operationalized-from: pascalandy schema
|
||||
- see-also: Iteration and Cost Limits
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -56,21 +60,24 @@ Index Scaling definiert Regeln und Schwellenwerte für den Zeitpunkt und die Art
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Split Threshold]]
|
||||
- **operationalized-from:** [[pascalandy schema]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -3,13 +3,17 @@ 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]
|
||||
modified: 2026-09-02
|
||||
related:
|
||||
- operates-on: Chemenu
|
||||
- mechanism: Gitea MCP Server
|
||||
- see-also: KB Stack Versioning
|
||||
- see-also: Detect-Repair Asymmetry
|
||||
sources: [Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
confidence_base: 0.85
|
||||
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'
|
||||
summary: 'Pflicht-Labelschema fuer das Gitea-Board: seit 2026-09-02 vier Achsen (area/kind/prio/size) plus zwei optionale status/-Flags, dazu der Issue-Body als aktuelle Wahrheit; die Regel liegt in instructions/dev/, weil sie keine ausgelieferte Instanz erreichen darf'
|
||||
---
|
||||
# Issue Label Scheme
|
||||
|
||||
@@ -18,36 +22,78 @@ summary: 'Zweiachsiges Pflicht-Labelschema fuer das Gitea-Board: prio/1..3 und s
|
||||
## 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].
|
||||
Gitea-Issues zu führen und jedes offene Issue mit vier Pflicht-Labels zu versehen: einem
|
||||
Bereich `area/`, einer Art `kind/`, einer Priorität `prio/` und einer Größe `size/`. Dazu
|
||||
kommen zwei optionale `status/`-Flags. Getroffen wurde die Entscheidung in dieser Form am
|
||||
2026-09-02[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02]; sie ersetzt das
|
||||
zweiachsige Schema vom 2026-08-31 (siehe [Historie](#historie)).
|
||||
|
||||
| Priorität | Bedeutung |
|
||||
| `area/` | 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. |
|
||||
| `area/kb` | `kb/`-Schema, Contract, Confidence, Lint - die Wissensbasis als System. |
|
||||
| `area/distribution` | Auslieferung, Upgrade und Versionierung einer Instanz. |
|
||||
| `area/corpus` | Inhalt und Umfang von `kb/` in dieser Instanz, samt Demo-/Testbett-Frage. |
|
||||
| `area/workflow` | Git, Merge, Branching, Publish, PRs. |
|
||||
| `area/process` | Der Entwicklungsprozess selbst, nicht der Stack als Artefakt. |
|
||||
|
||||
| Größe | Bedeutung |
|
||||
| `kind/` | Bedeutung |
|
||||
|---|---|
|
||||
| `kind/decision` | Wartet auf eine Betreiberentscheidung. |
|
||||
| `kind/build` | Spezifiziert, wartet nur noch auf Umsetzungszeit. |
|
||||
| `kind/defect` | Befund: Doku und Realität, oder zwei Dokus, widersprechen sich. |
|
||||
|
||||
| `prio/` | Bedeutung |
|
||||
|---|---|
|
||||
| `prio/blocking` | Blockiert oder beschädigt laufende Arbeit. Als Nächstes. |
|
||||
| `prio/planned` | Sammelt Zinsen. Eingeplant. |
|
||||
| `prio/waiting` | Lohnend, wartet auf einen benannten Auslöser. |
|
||||
|
||||
| `size/` | 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].
|
||||
| `status/` (optional) | Bedeutung |
|
||||
|---|---|
|
||||
| `status/blocked` | Wartet auf ein anderes, noch offenes Issue - unabhängig vom `prio`-Wert nicht eigenständig bearbeitbar. |
|
||||
| `status/unconfirmed` | Gemeldeter Verdacht, noch nicht gegen tatsächliches Verhalten geprüft; `size` und `prio` sind solange vorläufig. |
|
||||
|
||||
Sechzehn Labels stehen in Gitea; `prio/1`, `prio/2`, `prio/3` und `size/XS` existieren nicht
|
||||
mehr[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
|
||||
## 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.
|
||||
- **Vier Achsen sind Pflicht, weil ihre Pflege maschinell läuft.** Der ursprüngliche Einwand
|
||||
gegen eine dritte Achse war der Aufwand für einen einzelnen menschlichen Betreuer. Da
|
||||
Body-Rewrites und Labelpflege über eine LLM-Sitzung laufen und ein Mensch in der Regel nur
|
||||
Metadaten anfasst, trägt dieser Einwand
|
||||
nicht mehr[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
- **Der Issue-Body ist die aktuelle Wahrheit, nicht der Ursprungstext.** Die Umsetzung eines
|
||||
Issues zieht sich über mehrere, zeitlich getrennte Sitzungen, und der Body ist das einzige,
|
||||
was sie verbindet: eine Sitzung muss allein aus ihm rekonstruieren können, was entschieden
|
||||
und was offen ist. Er wird deshalb umgeschrieben statt
|
||||
ergänzt[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
- **Ein Kommentar ist ein Changelog, keine Kopie.** Ein Volltext-Snapshot des alten Bodys pro
|
||||
Revision zwingt einen Menschen zum Diffen zweier Fließtexte und ist damit keine lesbare
|
||||
Historie, sondern nur eine weitere
|
||||
Kopie[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
- **`area/` folgt der Systemgrenze, nicht dem Codeort.** Die Werte folgen der Stufenteilung aus
|
||||
`AGENTS.md`. Ein `area/tools` gibt es bewusst nicht - Tooling wird nach der Domäne
|
||||
einsortiert, die es
|
||||
bedient[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
- **`kind/` darf sich im Lauf eines Issues ändern.** Der Wechsel von `decision` zu `build`,
|
||||
sobald entschieden ist, ist erwünschtes Session-Memory-Verhalten und kein
|
||||
Makel[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
- **Eine Priorität ohne Kosten ist eine halbe Entscheidung.** Größe ist Aufwand und nicht
|
||||
Wichtigkeit, deshalb ist `prio/blocking size/S` das Beste, was auf einem Board stehen kann,
|
||||
und `prio/waiting size/L` etwas, worüber gesprochen wird, bevor jemand anfängt.
|
||||
- **`prio/waiting` 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].
|
||||
- **Kein unbelegter Verdacht bleibt offen liegen.** Die Triage eines `status/unconfirmed`
|
||||
endet entweder mit entferntem Flag und verbindlichen `size`/`prio`-Werten oder mit einem
|
||||
geschlossenen Issue samt Begründung - die Prozessentsprechung zu Invariante 3 des
|
||||
Stacks[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
- **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
|
||||
@@ -59,6 +105,28 @@ angewandt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-0
|
||||
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.
|
||||
|
||||
## Historie
|
||||
|
||||
Das ursprüngliche Schema vom 2026-08-31 hatte ~~genau zwei Pflicht-Labels, `prio/1..3` und
|
||||
`size/XS..L`, und verzichtete ausdrücklich auf eine dritte Achse: Art, Bereich oder Status
|
||||
wurden verworfen als der Punkt, ab dem eine Taxonomie eigene Pflege braucht, und das Board
|
||||
habe einen einzigen Betreuer.~~ 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].
|
||||
|
||||
Was sich am 2026-09-02 geändert hat:
|
||||
|
||||
| Achse | Vorher | Jetzt |
|
||||
|---|---|---|
|
||||
| `prio/` | `1`, `2`, `3` | `blocking`, `planned`, `waiting` - reine Umbenennung, Bedeutung unverändert |
|
||||
| `size/` | `XS`, `S`, `M`, `L` | `S`, `M`, `L` - `XS` entfällt, die übrigen unverändert |
|
||||
| `area/` | - | fünf Werte, neu |
|
||||
| `kind/` | - | drei Werte, neu |
|
||||
| `status/` | - | zwei optionale Flags, neu |
|
||||
|
||||
Der Verzicht auf die dritte Achse fiel damit weg, nicht weil die Begründung falsch war,
|
||||
sondern weil ihre Voraussetzung entfallen ist: gepflegt wird das Board nicht mehr von Hand.
|
||||
|
||||
## Wo die Regel liegt
|
||||
|
||||
Die Platzierung war die tragende Entscheidung, nicht das Schema selbst. `README.md` und
|
||||
@@ -76,51 +144,53 @@ Instanz ändert sich nichts. Das CI-Versions-Gate verlangte den Bump trotzdem, w
|
||||
auf `instructions/` passt und `instructions/dev/` darunter liegt[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]. Siehe
|
||||
[[KB Stack Versioning]].
|
||||
|
||||
Für die Erweiterung auf vier Achsen galt dieselbe Rechnung noch einmal: sie ging als `4.0.1`
|
||||
und damit ebenfalls als PATCH
|
||||
hinaus[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02].
|
||||
|
||||
## 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
|
||||
- [[Chemenu]] - das Repository, dessen Board nach dem Schema geführt wird; sechzehn Labels
|
||||
stehen dort, verteilt auf vier Pflicht- und eine optionale Familie
|
||||
- [[Gitea MCP Server]] - der Weg, auf dem Issues und Labels gelesen und geschrieben werden
|
||||
- [[Detect-Repair Asymmetry]] - Issue #14 ist der Fall, den dieses Concept beschreibt, und
|
||||
trägt `prio/2 size/S`
|
||||
trug in der ersten Triage `prio/2 size/S`, nach der Umbenennung also `prio/planned size/S`
|
||||
|
||||
## Wann zu verwenden
|
||||
|
||||
- Auf einem Board mit einem einzigen Betreuer, das eine erkennbare Reihenfolge braucht, aber
|
||||
keinen Prozess.
|
||||
- Auf einem Board mit einem einzigen menschlichen Betreuer, dessen Labelpflege maschinell
|
||||
läuft. Erst das macht mehr als zwei Achsen bezahlbar.
|
||||
- Sobald offene Arbeit sonst in Prosa-Dateien wandert, die niemand als Board liest und die
|
||||
gegen den Tracker driften.
|
||||
- Sobald die Bearbeitung eines Issues sich über mehrere, zeitlich getrennte Sitzungen zieht -
|
||||
dann trägt die Body-als-Wahrheit-Konvention den Kontext, den sonst ein Mensch jedes Mal neu
|
||||
erzählen müsste.
|
||||
|
||||
## 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 dort, wo Labels von Hand gepflegt werden. Dann ist die ursprüngliche Zweiachsigkeit
|
||||
die tragfähigere Wahl, und die Begründung von 2026-08-31 gilt unverändert.
|
||||
- Nicht als Ersatz für die Abnahmekriterien im Issue-Text. Die Labels ordnen ein Issue ein; ob
|
||||
es fertig ist, sagen sie nicht.
|
||||
- Nicht mit umgeschriebenen Bodys dort, wo mehrere Menschen denselben Thread lesen und den
|
||||
Verlauf brauchen. Die Konvention tauscht Historie gegen Aktualität und setzt voraus, dass
|
||||
der Changelog-Kommentar als Historie genügt.
|
||||
- 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]]
|
||||
<!-- wikitool:links -->
|
||||
|
||||
## 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]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
- **mechanism:** [[Gitea MCP Server]]
|
||||
- **see-also:** [[KB Stack Versioning]]
|
||||
- **see-also:** [[Detect-Repair Asymmetry]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
<!-- wikitool:footnotes -->
|
||||
## Fußnoten
|
||||
|
||||
[^s-gitea-issue-41-issue-management-and-label-scheme-2026-09-02]: [[Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]]
|
||||
[^s-conversation-issue-triage-labels-and-todo-retirement-session-2026-08-31]: [[Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31]]
|
||||
<!-- /wikitool:footnotes -->
|
||||
|
||||
@@ -4,7 +4,13 @@ concept_type: workflow
|
||||
tags: [gate, safety, iteration-budget, loop-breaker]
|
||||
created: 2026-08-07
|
||||
modified: 2026-09-02
|
||||
related: [Mass-Update Gate, Anti-Cramming Heuristic, Index Scaling, wikitool, Structural Enforcement over Documented Rule, MCP-Leseserver]
|
||||
related:
|
||||
- compares-with: Mass-Update Gate
|
||||
- see-also: Anti-Cramming Heuristic
|
||||
- see-also: Index Scaling
|
||||
- mechanism: wikitool
|
||||
- exemplifies: Structural Enforcement over Documented Rule
|
||||
- see-also: MCP-Leseserver
|
||||
sources: [Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - MCP Read Server Implementation Session 2026-09-02]
|
||||
confidence: 0.88
|
||||
confidence_base: 0.88
|
||||
@@ -54,32 +60,12 @@ Eine hart in Code durchgesetzte Obergrenze für die Anzahl der Tool-Aufrufe, die
|
||||
den Serverprozess gehört (Rate Limiting), nicht in dieses Gate - beide zu vermischen würde es
|
||||
zu einem Rate Limiter verwässern.[^s-mcp-read-server-implementation-session-2026-09-02]
|
||||
|
||||
## 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]]
|
||||
- **nimmt aus:** [[MCP-Leseserver]]
|
||||
|
||||
## 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]]
|
||||
- [[MCP-Leseserver]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
@@ -87,3 +73,14 @@ Eine hart in Code durchgesetzte Obergrenze für die Anzahl der Tool-Aufrufe, die
|
||||
[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
|
||||
[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **compares-with:** [[Mass-Update Gate]]
|
||||
- **see-also:** [[Anti-Cramming Heuristic]]
|
||||
- **see-also:** [[Index Scaling]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **exemplifies:** [[Structural Enforcement over Documented Rule]]
|
||||
- **see-also:** [[MCP-Leseserver]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ concept_type: workflow
|
||||
tags: [migration, versioning, corpus-diff, workflow]
|
||||
created: 2026-08-30
|
||||
modified: 2026-08-31
|
||||
related: [wikitool]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
- rests-on: KB Stack Versioning
|
||||
- see-also: Mass-Update Gate
|
||||
- see-also: Iteration and Cost Limits
|
||||
sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -116,12 +120,15 @@ verweigert[^s-conversation-versioning-ci-cd-and-content-migration-session-2026-0
|
||||
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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **rests-on:** [[KB Stack Versioning]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: decision
|
||||
tags: [versioning, semver, release, stack]
|
||||
created: 2026-08-30
|
||||
modified: 2026-09-02
|
||||
related: [wikitool, Issue Label Scheme]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
- see-also: Issue Label Scheme
|
||||
- see-also: CI Integration
|
||||
sources: [Source - Conversation - Versioning CI-CD and Content Migration Session 2026-08-30, Source - Conversation - Issue Triage Labels and TODO Retirement Session 2026-08-31, Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -103,20 +106,10 @@ kann.
|
||||
- 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]]
|
||||
- [[Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]]
|
||||
|
||||
@@ -124,3 +117,11 @@ kann.
|
||||
|
||||
[^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-version-part-nomenclature-and-breaking-change-gate-session-2026-09-02]: [[Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **see-also:** [[Issue Label Scheme]]
|
||||
- **see-also:** [[CI Integration]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: [knowledge-management, growth, learning]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, Memex, Tolkien Gateway]
|
||||
related:
|
||||
- part-of: LLM Wiki Pattern
|
||||
- see-also: Memex
|
||||
- see-also: Tolkien Gateway
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -118,7 +121,12 @@ Mit LLM Wiki Pattern:
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Memex]]
|
||||
- [[Tolkien Gateway]]
|
||||
- [[Three-Layer Architecture]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memex]]
|
||||
- **see-also:** [[Tolkien Gateway]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,12 @@ 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]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Memory Lifecycle
|
||||
- see-also: Entity Extraction
|
||||
- composition: Typed Relationships
|
||||
- see-also: Graph Traversal
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -130,11 +135,6 @@ Basierend auf [[Agent Memory]] und [[iii Engine]]:
|
||||
|
||||
## 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
|
||||
@@ -142,3 +142,13 @@ Basierend auf [[Agent Memory]] und [[iii Engine]]:
|
||||
- [[Hybrid Search]] (nutzt Graph-Traversal als einen Stream)
|
||||
- [[Event-Driven Automation]] (für automatische Graph-Updates)
|
||||
- [[Supersession]] (als Graph-Beziehung verfolgt)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **see-also:** [[Entity Extraction]]
|
||||
- **composition:** [[Typed Relationships]]
|
||||
- **see-also:** [[Graph Traversal]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- rests-on: Three-Layer Architecture
|
||||
- see-also: Knowledge Compounding
|
||||
- contrasts: RAG
|
||||
- see-also: Vannevar Bush
|
||||
- composition: Memory Lifecycle
|
||||
- see-also: Memex
|
||||
sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -201,11 +207,6 @@ Periodische Gesundheitsprüfung zu:
|
||||
|
||||
## 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
|
||||
@@ -230,10 +231,15 @@ Periodische Gesundheitsprüfung zu:
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Three-Layer Architecture]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[RAG]]
|
||||
- [[Memex]]
|
||||
- [[Vannevar Bush]]
|
||||
- [[Obsidian]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **rests-on:** [[Three-Layer Architecture]]
|
||||
- **see-also:** [[Knowledge Compounding]]
|
||||
- **contrasts:** [[RAG]]
|
||||
- **see-also:** [[Vannevar Bush]]
|
||||
- **composition:** [[Memory Lifecycle]]
|
||||
- **see-also:** [[Memex]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- see-also: Event-Driven Automation
|
||||
- part-of: Quality and Self-Correction
|
||||
- grounds: Detect-Repair Asymmetry
|
||||
- grounds: Green Suite Blind Spot
|
||||
sources: [Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -48,21 +52,22 @@ Läuft nach Zeitplan (täglich/wöchentlich) ab und kann durch Memory-Write-Erei
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Event-Driven Automation]]
|
||||
- **part-of:** [[Quality and Self-Correction]]
|
||||
- **grounds:** [[Detect-Repair Asymmetry]]
|
||||
- **grounds:** [[Green Suite Blind Spot]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,12 @@ concept_type: architecture
|
||||
tags: [mcp, library-boundary, search, server]
|
||||
created: 2026-09-02
|
||||
modified: 2026-09-02
|
||||
related: [wikitool, Publish-Remote Gate, Mass-Update Gate, Iteration and Cost Limits, Chemenu]
|
||||
related:
|
||||
- operates-on: wikitool
|
||||
- see-also: Publish-Remote Gate
|
||||
- see-also: Mass-Update Gate
|
||||
- see-also: Iteration and Cost Limits
|
||||
- see-also: Chemenu
|
||||
sources: [Source - MCP Read Server Implementation Session 2026-09-02]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -79,30 +84,22 @@ vertrauen, dass sie übereinstimmen.
|
||||
- Als Ersatz für den Iteration Budget Gate oder das Traefik-Rate-Limiting - beide bleiben
|
||||
notwendig und leben an anderer Stelle.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Publish-Remote Gate]]
|
||||
- [[Mass-Update Gate]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **implementiert:** [[wikitool]]
|
||||
- **verwandt mit:** [[Publish-Remote Gate]]
|
||||
- **verwandt mit:** [[Mass-Update Gate]]
|
||||
- **ausgenommen von:** [[Iteration and Cost Limits]]
|
||||
- **Teil von:** [[Chemenu]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[wikitool]]
|
||||
- [[Publish-Remote Gate]]
|
||||
- [[Mass-Update Gate]]
|
||||
- [[Iteration and Cost Limits]]
|
||||
- [[Chemenu]]
|
||||
- [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **operates-on:** [[wikitool]]
|
||||
- **see-also:** [[Publish-Remote Gate]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
- **see-also:** [[Chemenu]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,14 @@ 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, Publish-Remote Gate, MCP-Leseserver]
|
||||
related:
|
||||
- enables: Content Quality Control
|
||||
- mechanism: wikitool
|
||||
- see-also: Iteration and Cost Limits
|
||||
- exemplifies: Structural Enforcement over Documented Rule
|
||||
- contrasts: Bulk Operations
|
||||
- see-also: Publish-Remote Gate
|
||||
- see-also: MCP-Leseserver
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Improvements Production Agent Gaps 2026, Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31, Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31, Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.88
|
||||
confidence_base: 0.88
|
||||
@@ -68,28 +75,15 @@ Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausier
|
||||
|
||||
## 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]]
|
||||
- **verwandtes Gate:** [[Publish-Remote Gate]]
|
||||
- **verwandt mit:** [[MCP-Leseserver]]
|
||||
|
||||
## 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]]
|
||||
- [[Publish-Remote Gate]]
|
||||
- [[MCP-Leseserver]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
@@ -97,3 +91,15 @@ Das Mass-Update Gate ist ein Sicherheitsmechanismus, der die Ausführung pausier
|
||||
[^s-conversation-gate-counting-and-measured-calibration-session-2026-08-31]: [[Source - Conversation - Gate Counting and Measured Calibration Session 2026-08-31]]
|
||||
[^s-llm-improvements-codex-analysis]: [[Source - LLM Improvements Codex Analysis]]
|
||||
[^s-conversation-comma-bug-budget-refund-and-lint-report-path-session-2026-08-31]: [[Source - Conversation - Comma Bug Budget Refund and Lint Report Path Session 2026-08-31]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **enables:** [[Content Quality Control]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
- **exemplifies:** [[Structural Enforcement over Documented Rule]]
|
||||
- **contrasts:** [[Bulk Operations]]
|
||||
- **see-also:** [[Publish-Remote Gate]]
|
||||
- **see-also:** [[MCP-Leseserver]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- part-of: LLM Wiki Pattern
|
||||
- see-also: Confidence Scoring
|
||||
- composition: Supersession
|
||||
- see-also: Consolidation Tiers
|
||||
- see-also: Forgetting
|
||||
- enables: Knowledge Compounding
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -109,12 +115,6 @@ Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
## 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
|
||||
@@ -122,3 +122,14 @@ Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
- [[Event-Driven Automation]] (Trigger für Lebenszyklus-Management)
|
||||
- [[Quality Scoring]] (komplementäre Qualitätsmetriken)
|
||||
- [[Knowledge Graph]] (Struktur zur Verfolgung von Beziehungen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Confidence Scoring]]
|
||||
- **composition:** [[Supersession]]
|
||||
- **see-also:** [[Consolidation Tiers]]
|
||||
- **see-also:** [[Forgetting]]
|
||||
- **enables:** [[Knowledge Compounding]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Multi-Agent Collaboration, Source - LLM Wiki v2]
|
||||
related:
|
||||
- exemplifies: Implementation Spectrum
|
||||
- part-of: Multi-Agent Collaboration
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +41,11 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **part-of:** [[Multi-Agent Collaboration]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
+12
-4
@@ -4,7 +4,10 @@ concept_type: protocol
|
||||
tags: [industrial, automation, communication, serial]
|
||||
created: 2026-07-25
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, ha-core, Home Assistant]
|
||||
related:
|
||||
- see-also: E3DC
|
||||
- see-also: ha-core
|
||||
- see-also: Home Assistant
|
||||
sources: []
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -243,7 +246,6 @@ func main() {
|
||||
- [[MQTT]] - Alternatives Protokoll für IoT/Industrie
|
||||
- [[OPC UA]] - Modernes Industrieprotokoll mit Sicherheit
|
||||
- Industrial-Automation-Konzept
|
||||
- [[E3DC]] - Verwendet Modbus zur Kommunikation
|
||||
|
||||
## Historie
|
||||
|
||||
@@ -257,5 +259,11 @@ func main() {
|
||||
|
||||
- [Modbus Organization](https://modbus.org/)
|
||||
- [Modbus Specifications](https://modbus.org/specifications/)
|
||||
- [[E3DC]] - Verwendet Modbus TCP
|
||||
- [[ha-core]] - Kann Modbus verwenden
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[E3DC]]
|
||||
- **see-also:** [[ha-core]]
|
||||
- **see-also:** [[Home Assistant]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,12 @@ 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]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Memory Lifecycle
|
||||
- composition: Mesh Sync
|
||||
- composition: Shared vs Private
|
||||
- composition: Work Coordination
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.85
|
||||
confidence_base: 0.85
|
||||
@@ -116,10 +121,6 @@ Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -127,3 +128,13 @@ Basierend auf [[Agent Memory]]-Erfahrung:
|
||||
|
||||
- [[Privacy and Governance]] (für Zugriffskontrolle)
|
||||
- [[Quality and Self-Correction]] (zur Aufrechterhaltung der Qualität in kollaborativen Einstellungen)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Mesh Sync]]
|
||||
- **composition:** [[Shared vs Private]]
|
||||
- **composition:** [[Work Coordination]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: problem
|
||||
tags: [bug, drifts, kebab-case, human-readable]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [AGENTS.md]
|
||||
related:
|
||||
- operates-on: AGENTS.md
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -45,19 +46,21 @@ Naming Convention Conflict ist ein spezifischer Drift/Bug, bei dem README.md und
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **operates-on:** [[AGENTS.md]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: architecture
|
||||
tags: [interoperability, export, validate, okf-profile]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [awesome-llm-wiki]
|
||||
related:
|
||||
- see-also: awesome-llm-wiki
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -45,19 +46,21 @@ OKF (Open Knowledge Framework) Compatibility ist das Konzept, einen Export-/Vali
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[awesome-llm-wiki]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [ENVIRONMENT.md, Personalization Plane, wikitool, Chemenu]
|
||||
related:
|
||||
- mechanism: ENVIRONMENT.md
|
||||
- contrasts: Personalization Plane
|
||||
- mechanism: wikitool
|
||||
- operates-on: Chemenu
|
||||
sources: [Source - Conversation - ENVIRONMENT.md as an Optional Third Session-Level File Session 2026-08-31]
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -92,25 +96,23 @@ in das Repo aller anderen.
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[ENVIRONMENT.md]]
|
||||
- **contrasts:** [[Personalization Plane]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-31
|
||||
modified: 2026-08-31
|
||||
related: [wikitool, Chemenu, Optional Instance Context File]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
- operates-on: Chemenu
|
||||
- see-also: 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
|
||||
@@ -85,23 +88,24 @@ sondern in den Health-Check.
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[KB Migration]] - Abgrenzung: dort Korpus-Form, hier Instanz-Zustand
|
||||
- [[Optional Instance Context File]] - dasselbe Muster ohne Pflicht: dort meldet der
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
- **see-also:** [[Optional Instance Context File]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Filter on Ingest
|
||||
- see-also: Audit Trail
|
||||
- see-also: Bulk Operations
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -132,10 +136,6 @@ Basierend auf [[Agent Memory]] und Produktionserfahrung:
|
||||
|
||||
## 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
|
||||
@@ -143,3 +143,12 @@ Basierend auf [[Agent Memory]] und Produktionserfahrung:
|
||||
- [[Privacy and Governance]] (diese Seite)
|
||||
- [[Multi-Agent Collaboration]] (für Multi-Agent-Sicherheit)
|
||||
- [[Quality and Self-Correction]] (für Qualitätsaspekte)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Filter on Ingest]]
|
||||
- **see-also:** [[Audit Trail]]
|
||||
- **see-also:** [[Bulk Operations]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +39,9 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: []
|
||||
created: 2026-09-01
|
||||
modified: 2026-09-02
|
||||
related: [Mass-Update Gate, Chemenu, MCP-Leseserver]
|
||||
related:
|
||||
- see-also: Mass-Update Gate
|
||||
- operates-on: Chemenu
|
||||
- see-also: MCP-Leseserver
|
||||
sources: [Source - Publish-Remote Gate and Issue Triage Session 2026-09-01, Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01, Source - MCP Read Server Implementation Session 2026-09-02]
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -91,26 +94,22 @@ getestetes Skript und zwei Architekturvorschläge (das Verfahren als `wikitool`-
|
||||
oder den Demo-Korpus grundsätzlich von dem Branch fernhalten, von dem private Instanzen ihre
|
||||
Maschinerie ziehen) stehen in Gitea-Issue #30.
|
||||
|
||||
## Verwandte Concepts
|
||||
|
||||
- [[Mass-Update Gate]]
|
||||
- [[MCP-Leseserver]]
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **gilt fuer:** [[Chemenu]]
|
||||
- **verwandtes Gate:** [[Mass-Update Gate]]
|
||||
- **verwandt mit:** [[MCP-Leseserver]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]]
|
||||
- [[Chemenu]]
|
||||
- [[Mass-Update Gate]]
|
||||
- [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
|
||||
- [[MCP-Leseserver]]
|
||||
|
||||
## Fußnoten
|
||||
|
||||
[^s-private-instance-merge-correction-and-issue-30-session-2026-09-01]: [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
|
||||
[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
- **operates-on:** [[Chemenu]]
|
||||
- **see-also:** [[MCP-Leseserver]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Confidence Scoring, Implementation Spectrum, Memory Lifecycle, Source - LLM Wiki v2]
|
||||
related:
|
||||
- see-also: Confidence Scoring
|
||||
- exemplifies: Implementation Spectrum
|
||||
- see-also: Memory Lifecycle
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +42,12 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Confidence Scoring]]
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- see-also: Memory Lifecycle
|
||||
- rests-on: Event-Driven Automation
|
||||
- rests-on: Confidence Scoring
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -111,10 +115,6 @@ Basierend auf [[Agent Memory]] und [[Event-Driven Automation]]:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -125,3 +125,11 @@ Basierend auf [[Agent Memory]] und [[Event-Driven Automation]]:
|
||||
- [[Self-Healing]] (der automatische Reparaturmechanismus)
|
||||
- [[Contradiction Resolution]] (der Entscheidungsprozess)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Event-Driven Automation]]
|
||||
- **rests-on:** [[Confidence Scoring]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
+12
-4
@@ -4,7 +4,10 @@ concept_type: architecture
|
||||
tags: [ai, retrieval, generation, knowledge-management]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [LLM Wiki Pattern, NotebookLM, ChatGPT]
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- see-also: NotebookLM
|
||||
- see-also: ChatGPT
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -107,7 +110,12 @@ Das [[LLM Wiki Pattern]] kann als eine Verbesserung zu RAG angesehen werden, die
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[NotebookLM]]
|
||||
- [[ChatGPT]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[NotebookLM]]
|
||||
- **see-also:** [[ChatGPT]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
related:
|
||||
- part-of: Hybrid Search
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +41,11 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Hybrid Search]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
+11
-7
@@ -4,7 +4,9 @@ concept_type: protocol
|
||||
tags: [storage, ssd, performance, optimization, linux]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Disk Encryption, LVM, Arch Linux]
|
||||
related:
|
||||
- see-also: LVM
|
||||
- see-also: Arch Linux
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -175,16 +177,18 @@ lsblk -o NAME,FSTYPE,DISC-GRAN,DISC-MAX
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Verwendet mit:** [[Disk Encryption]] (dm-crypt/LUKS)
|
||||
- **Ergänzt:** [[LVM]] (Logical Volume Manager)
|
||||
- **Läuft auf:** [[Arch Linux]] und anderen Distributionen
|
||||
(dm-crypt/LUKS)
|
||||
- **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)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LVM]]
|
||||
- **see-also:** [[Arch Linux]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: architecture
|
||||
tags: [scale, limitations]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
related:
|
||||
- see-also: Token Economics
|
||||
- see-also: Cross-platform Agent Skills
|
||||
- see-also: Context Isolation
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -46,12 +49,14 @@ Scale Ceiling ist kein Problem wenn:
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Token Economics]]
|
||||
- **see-also:** [[Cross-platform Agent Skills]]
|
||||
- **see-also:** [[Context Isolation]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- see-also: Confidence Scoring
|
||||
- part-of: Quality and Self-Correction
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
- see-also: Supersession
|
||||
- see-also: Detect-Repair Asymmetry
|
||||
- see-also: Command Round-Trip Integrity
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -41,11 +47,15 @@ TODO
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **abgegrenzt gegen:** [[Detect-Repair Asymmetry]]
|
||||
- **folgt aus:** [[Command Round-Trip Integrity]]
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Detect-Repair Asymmetry]]
|
||||
- [[Command Round-Trip Integrity]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Confidence Scoring]]
|
||||
- **part-of:** [[Quality and Self-Correction]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
- **see-also:** [[Supersession]]
|
||||
- **see-also:** [[Detect-Repair Asymmetry]]
|
||||
- **see-also:** [[Command Round-Trip Integrity]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: workflow
|
||||
tags: [heuristics, stale-claims, change-density, weak-linking]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [wikitool]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -55,20 +56,22 @@ Semantic Lint Automation bezieht sich auf Maschinen-Heuristiken, die potenzielle
|
||||
|
||||
- [[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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +39,9 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: workflow
|
||||
tags: [preflight, context, query, update]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [wikitool]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis, Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -55,15 +56,18 @@ Session Orientation ist eine obligatorische Preflight-Prüfung, die einen Kontex
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Multi-Agent Collaboration]
|
||||
related:
|
||||
- part-of: Multi-Agent Collaboration
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +39,9 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Multi-Agent Collaboration]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: workflow
|
||||
tags: [page-management, refactoring, link-correction, frontmatter]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [wikitool]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -46,20 +47,22 @@ Split Merge Reclassify bezieht sich auf dedizierte Befehle für strukturelle Sei
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: [split, threshold, lines, pages]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [Content Quality Control, Stub Threshold, Index Scaling]
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Stub Threshold
|
||||
- see-also: Index Scaling
|
||||
sources: [Source - LLM Improvements Sonnet Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -53,9 +56,6 @@ Split Threshold definiert die maximale Größe, die eine Wiki-Seite erreichen so
|
||||
|
||||
## 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
|
||||
@@ -65,3 +65,11 @@ Split Threshold definiert die maximale Größe, die eine Wiki-Seite erreichen so
|
||||
## Fußnoten
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Stub Threshold]]
|
||||
- **see-also:** [[Index Scaling]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- see-also: Ambient Environment Dependency
|
||||
- mechanism: wikitool
|
||||
- see-also: Iteration and Cost Limits
|
||||
- see-also: 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
|
||||
@@ -92,26 +96,23 @@ Dokumentation erklärt die Regel und ihre Ausnahmen; sie trägt aber nicht die D
|
||||
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Ambient Environment Dependency]]
|
||||
- **mechanism:** [[wikitool]]
|
||||
- **see-also:** [[Iteration and Cost Limits]]
|
||||
- **see-also:** [[Mass-Update Gate]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ 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]
|
||||
related:
|
||||
- part-of: Content Quality Control
|
||||
- see-also: Split Threshold
|
||||
- see-also: Semantic Lint Automation
|
||||
sources: [Source - LLM Improvements Sonnet Analysis, Source - LLM Wiki v2]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -64,12 +67,6 @@ It provides comprehensive information about the topic. It clearly exceeds the st
|
||||
- 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]]
|
||||
@@ -79,3 +76,11 @@ It provides comprehensive information about the topic. It clearly exceeds the st
|
||||
|
||||
[^s-llm-improvements-sonnet-analysis]: [[Source - LLM Improvements Sonnet Analysis]]
|
||||
[^s-llm-wiki-v2]: [[Source - LLM Wiki v2]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Content Quality Control]]
|
||||
- **see-also:** [[Split Threshold]]
|
||||
- **see-also:** [[Semantic Lint Automation]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- part-of: Memory Lifecycle
|
||||
- rests-on: Confidence Scoring
|
||||
- see-also: Knowledge Graph
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -122,11 +126,7 @@ Wenn Aussage B Aussage A ersetzt:
|
||||
|
||||
## 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
|
||||
|
||||
@@ -134,3 +134,12 @@ Wenn Aussage B Aussage A ersetzt:
|
||||
- [[Forgetting]] (komplementärer Mechanismus)
|
||||
- [[Self-Healing]] (für automatisierte Supersession-Erkennung)
|
||||
- [[Audit Trail]] (zum Nachverfolgen von Supersession-Historie)
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Memory Lifecycle]]
|
||||
- **rests-on:** [[Confidence Scoring]]
|
||||
- **see-also:** [[Knowledge Graph]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ 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]
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- contrasts: RAG
|
||||
- composition: Memory Lifecycle
|
||||
- composition: Knowledge Graph
|
||||
sources: [Source - LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -256,11 +260,15 @@ Die Three-Layer Architecture bleibt gültig und ausreichend für viele Anwendung
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[LLM Wiki Pattern]]
|
||||
- AGENTS.md
|
||||
- [[RAG]]
|
||||
- [[Knowledge Compounding]]
|
||||
- [[Memory Lifecycle]]
|
||||
- [[Knowledge Graph]]
|
||||
- [[Implementation Spectrum]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **contrasts:** [[RAG]]
|
||||
- **composition:** [[Memory Lifecycle]]
|
||||
- **composition:** [[Knowledge Graph]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: architecture
|
||||
tags: [tokens, cost, efficiency]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
related:
|
||||
- see-also: Cross-platform Agent Skills
|
||||
- see-also: Scale Ceiling
|
||||
- see-also: Context Isolation
|
||||
sources: [Source - Copilot Skill Restructure Instructions, Source - Conversation - AGENTS.md Skill Restructuring Session 2026-08-04]
|
||||
confidence: 0.60
|
||||
confidence_base: 0.60
|
||||
@@ -50,12 +53,6 @@ Token Economics ist weniger entscheidend, wenn:
|
||||
- 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]]
|
||||
@@ -65,3 +62,11 @@ Token Economics ist weniger entscheidend, wenn:
|
||||
|
||||
[^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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Cross-platform Agent Skills]]
|
||||
- **see-also:** [[Scale Ceiling]]
|
||||
- **see-also:** [[Context Isolation]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Knowledge Graph, Source - LLM Wiki v2]
|
||||
related:
|
||||
- exemplifies: Implementation Spectrum
|
||||
- part-of: Knowledge Graph
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +41,11 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **part-of:** [[Knowledge Graph]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,11 @@ concept_type: workflow
|
||||
tags: [linux, administration, security, users, groups]
|
||||
created: 2026-07-31
|
||||
modified: 2026-08-29
|
||||
related: [Arch Linux, AUR, Aura, makepkg]
|
||||
related:
|
||||
- see-also: Arch Linux
|
||||
- see-also: AUR
|
||||
- see-also: Aura
|
||||
- see-also: makepkg
|
||||
sources: [Source - Arch Linux Cheat Sheet]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -323,17 +327,17 @@ 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/
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Arch Linux]]
|
||||
- **see-also:** [[AUR]]
|
||||
- **see-also:** [[Aura]]
|
||||
- **see-also:** [[makepkg]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Hybrid Search, LLM Wiki Pattern, Source - LLM Wiki v2]
|
||||
related:
|
||||
- part-of: Hybrid Search
|
||||
- exemplifies: LLM Wiki Pattern
|
||||
- evidenced-by: Source - LLM Wiki v2
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +41,11 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Hybrid Search]]
|
||||
- **exemplifies:** [[LLM Wiki Pattern]]
|
||||
- **evidenced-by:** [[Source - LLM Wiki v2]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ concept_type: pattern
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Implementation Spectrum, Multi-Agent Collaboration]
|
||||
related:
|
||||
- exemplifies: Implementation Spectrum
|
||||
- part-of: Multi-Agent Collaboration
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +40,10 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[Implementation Spectrum]]
|
||||
- **part-of:** [[Multi-Agent Collaboration]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ concept_type: workflow
|
||||
tags: [workflow, extraction, refactoring]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-01
|
||||
related: []
|
||||
related:
|
||||
- see-also: Cross-platform Agent Skills
|
||||
- see-also: Context Isolation
|
||||
- see-also: Token Economics
|
||||
sources: [Source - Copilot Skill Restructure Instructions]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -47,12 +50,14 @@ Workflow-Extraktion vermeiden, wenn:
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[Cross-platform Agent Skills]]
|
||||
- **see-also:** [[Context Isolation]]
|
||||
- **see-also:** [[Token Economics]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: workflow
|
||||
tags: [automation, end-to-end, ingest, lint, update]
|
||||
created: 2026-08-03
|
||||
modified: 2026-08-29
|
||||
related: [wikitool]
|
||||
related:
|
||||
- mechanism: wikitool
|
||||
sources: [Source - LLM Improvements Codex Analysis]
|
||||
confidence: 0.80
|
||||
confidence_base: 0.80
|
||||
@@ -46,20 +47,22 @@ Workflow-Orchestrierung ist das Konzept der Bereitstellung einzelner, orchestrie
|
||||
## 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **mechanism:** [[wikitool]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ concept_type: architecture
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Consolidation Tiers]
|
||||
related:
|
||||
- part-of: Consolidation Tiers
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -38,3 +39,9 @@ TODO
|
||||
## Verwandte Concepts
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **part-of:** [[Consolidation Tiers]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,12 @@ 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]
|
||||
related:
|
||||
- exemplifies: wikitool
|
||||
- see-also: Denylist over Allowlist
|
||||
- see-also: Detect-Repair Asymmetry
|
||||
- see-also: Diff-Reviewable Agent Edits
|
||||
- see-also: 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
|
||||
@@ -95,30 +100,24 @@ breit[^s-conversation-write-once-frontmatter-fields-and-touch-set-session-2026-0
|
||||
- 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]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **exemplifies:** [[wikitool]]
|
||||
- **see-also:** [[Denylist over Allowlist]]
|
||||
- **see-also:** [[Detect-Repair Asymmetry]]
|
||||
- **see-also:** [[Diff-Reviewable Agent Edits]]
|
||||
- **see-also:** [[Command Round-Trip Integrity]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ 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]
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- see-also: Three-Layer Architecture
|
||||
- see-also: Knowledge Compounding
|
||||
sources: [Source - LLM Wiki v2, Source - LLM Wiki Pattern]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -34,17 +37,12 @@ Seine ursprüngliche Einsicht - "stop re-deriving, start compiling" - bildet die
|
||||
|
||||
## 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]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **see-also:** [[Three-Layer Architecture]]
|
||||
- **see-also:** [[Knowledge Compounding]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ entity_type: person
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC]
|
||||
related:
|
||||
- owns: E3DC
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -43,3 +44,9 @@ TODO
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **owns:** [[E3DC]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ entity_type: person
|
||||
tags: [developer, ai, memory, open-source]
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [iii Engine, LLM Wiki Pattern]
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- owns: Agent Memory
|
||||
- see-also: Andrej Karpathy
|
||||
sources: [Source - LLM Wiki v2]
|
||||
confidence: 0.95
|
||||
confidence_base: 0.95
|
||||
@@ -33,17 +36,12 @@ Seine Arbeit an agentmemory und das zugehörige [LLM Wiki v2](https://gist.githu
|
||||
|
||||
## 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]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **owns:** [[Agent Memory]]
|
||||
- **see-also:** [[Andrej Karpathy]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,9 @@ entity_type: person
|
||||
tags: [history, computer-science, knowledge-management, '1945']
|
||||
created: 2026-07-26
|
||||
modified: 2026-08-29
|
||||
related: [Memex, LLM Wiki Pattern]
|
||||
related:
|
||||
- see-also: LLM Wiki Pattern
|
||||
- owns: Memex
|
||||
sources: [Source - LLM Wiki Pattern]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
@@ -30,9 +32,6 @@ Vannevar Bush (1890-1974) war ein amerikanischer Ingenieur, Erfinder und Wissens
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Erfand:** [[Memex]]
|
||||
- **Inspiration für:** [[LLM Wiki Pattern]] (geistiger Vorläufer)
|
||||
|
||||
## Beiträge
|
||||
|
||||
### Memex-Konzept (1945)
|
||||
@@ -69,6 +68,9 @@ Laut dem Artikel [[LLM Wiki Pattern]] war Bushs Memex-Vision:
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[Memex]]
|
||||
- [[LLM Wiki Pattern]]
|
||||
- [[Knowledge Compounding]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **see-also:** [[LLM Wiki Pattern]]
|
||||
- **owns:** [[Memex]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
related:
|
||||
- uses: Go
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -43,3 +44,9 @@ TODO
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **uses:** [[Go]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,8 +4,17 @@ entity_type: project
|
||||
tags: [wiki, llm, knowledge-base]
|
||||
created: 2026-08-04
|
||||
modified: 2026-09-02
|
||||
related: [Personalization Plane, Issue Label Scheme, Optional Instance Context File, Delete Rather Than Anonymize, Dual Licensing by File Plan, Publish-Remote Gate, MCP-Leseserver]
|
||||
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, 'Source - Public Release, Corpus Purge and History Squash Session 2026-09-01', Source - Publish-Remote Gate and Issue Triage Session 2026-09-01, Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01, Source - MCP Read Server Implementation Session 2026-09-02, Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]
|
||||
related:
|
||||
- implements: Personalization Plane
|
||||
- implements: Issue Label Scheme
|
||||
- implements: Optional Instance Context File
|
||||
- implements: Delete Rather Than Anonymize
|
||||
- implements: Dual Licensing by File Plan
|
||||
- implements: Publish-Remote Gate
|
||||
- implements: MCP-Leseserver
|
||||
- uses: wikitool
|
||||
- composition: AGENTS.md
|
||||
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, 'Source - Public Release, Corpus Purge and History Squash Session 2026-09-01', Source - Publish-Remote Gate and Issue Triage Session 2026-09-01, Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01, Source - MCP Read Server Implementation Session 2026-09-02, Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02, Source - Gitea Issue 41 - Issue Management and Label Scheme 2026-09-02]
|
||||
confidence: 0.90
|
||||
confidence_base: 0.90
|
||||
provenance: mixed
|
||||
@@ -53,18 +62,6 @@ Das Repository hat bereits ein deterministisches CLI, `tools/wikitool` (Python,
|
||||
|
||||
## 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]]
|
||||
- **wendet an:** [[Delete Rather Than Anonymize]]
|
||||
- **wendet an:** [[Dual Licensing by File Plan]]
|
||||
- **setzt um:** [[Publish-Remote Gate]]
|
||||
- **enthaelt:** [[MCP-Leseserver]]
|
||||
|
||||
## Details
|
||||
|
||||
Die Repository-Struktur umfasst:
|
||||
@@ -212,23 +209,14 @@ Repositorys selbst und keine Aussagen aus einer Rohdatenquelle; der Änderungsda
|
||||
|
||||
- [[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]]
|
||||
- [[Source - Public Release, Corpus Purge and History Squash Session 2026-09-01]]
|
||||
- [[Delete Rather Than Anonymize]]
|
||||
- [[Dual Licensing by File Plan]]
|
||||
- [[Source - Publish-Remote Gate and Issue Triage Session 2026-09-01]]
|
||||
- [[Publish-Remote Gate]]
|
||||
- [[Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01]]
|
||||
- [[MCP-Leseserver]]
|
||||
- [[Source - Version Part Nomenclature and Breaking Change Gate Session 2026-09-02]]
|
||||
|
||||
## Fußnoten
|
||||
@@ -242,3 +230,17 @@ Repositorys selbst und keine Aussagen aus einer Rohdatenquelle; der Änderungsda
|
||||
[^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]]
|
||||
[^s-mcp-read-server-implementation-session-2026-09-02]: [[Source - MCP Read Server Implementation Session 2026-09-02]]
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **implements:** [[Personalization Plane]]
|
||||
- **implements:** [[Issue Label Scheme]]
|
||||
- **implements:** [[Optional Instance Context File]]
|
||||
- **implements:** [[Delete Rather Than Anonymize]]
|
||||
- **implements:** [[Dual Licensing by File Plan]]
|
||||
- **implements:** [[Publish-Remote Gate]]
|
||||
- **implements:** [[MCP-Leseserver]]
|
||||
- **uses:** [[wikitool]]
|
||||
- **composition:** [[AGENTS.md]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
related:
|
||||
- uses: Go
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -43,3 +44,9 @@ TODO
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **uses:** [[Go]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,8 @@ entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [Go]
|
||||
related:
|
||||
- uses: Go
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -43,3 +44,9 @@ TODO
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **uses:** [[Go]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,13 @@ 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]
|
||||
related:
|
||||
- required-by: hacs-e3dc
|
||||
- required-by: hacs-integration-blueprint
|
||||
- depends-on: E3DC
|
||||
- part-of: Home Assistant
|
||||
- uses: Go
|
||||
- uses: Python
|
||||
sources: []
|
||||
confidence: 0.70
|
||||
confidence_base: 0.70
|
||||
@@ -29,11 +35,6 @@ ha-core scheint eine Kernkomponente für die Integrationierung von E3DC-Systemen
|
||||
|
||||
## Beziehungen
|
||||
|
||||
- **Teil von:** [[Home Assistant]] Ökosystem
|
||||
- **Hängt ab von:** [[E3DC]] Systemen
|
||||
- **Verwandt mit:** [[hacs-e3dc]], [[hacs-integration-blueprint]]
|
||||
- **Verwendet:** [[Go]], [[Python]]
|
||||
|
||||
## Details
|
||||
|
||||
### Komponenten
|
||||
@@ -55,9 +56,13 @@ Basierend auf der Repository-Struktur wahrscheinlich enthalten:
|
||||
|
||||
## Siehe auch
|
||||
|
||||
- [[E3DC]]
|
||||
- [[Home Assistant]]
|
||||
- [[hacs-e3dc]]
|
||||
- [[hacs-integration-blueprint]]
|
||||
- [[Go]]
|
||||
- [[Python]]
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **required-by:** [[hacs-e3dc]]
|
||||
- **required-by:** [[hacs-integration-blueprint]]
|
||||
- **depends-on:** [[E3DC]]
|
||||
- **part-of:** [[Home Assistant]]
|
||||
- **uses:** [[Go]]
|
||||
- **uses:** [[Python]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
@@ -4,7 +4,10 @@ entity_type: project
|
||||
tags: []
|
||||
created: 2026-08-02
|
||||
modified: 2026-08-29
|
||||
related: [E3DC, Go, ha-core]
|
||||
related:
|
||||
- depends-on: E3DC
|
||||
- uses: Go
|
||||
- depends-on: ha-core
|
||||
sources: []
|
||||
confidence: 0.50
|
||||
confidence_base: 0.50
|
||||
@@ -43,3 +46,11 @@ TODO
|
||||
## Siehe auch
|
||||
|
||||
- TODO
|
||||
|
||||
<!-- wikitool:links -->
|
||||
## Beziehungen
|
||||
|
||||
- **depends-on:** [[E3DC]]
|
||||
- **uses:** [[Go]]
|
||||
- **depends-on:** [[ha-core]]
|
||||
<!-- /wikitool:links -->
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user