docs: Nachzug zu #119 - Verpflichtungsschicht in Installation, Setup und docs/ (#119)

Files changed:
- AGENTS.md
- CHANGES.md
- INSTALL.md
- README.md
- VERSION
- docs/knowledge-and-commitment.md
- instructions/dev/doc-pull-through.md
- instructions/setup-instance.md
- instructions/upgrade-instance.md
- tools/README.md

CHANGES.md

@@ -59,7 +59,7 @@ concern - readable here, never shipped as something to parse.
 
 ---
 
-## 7.0.0-beta.6 - 2026-09-20 - Skill weekly-review: turning wikitool review's findings into decisions
+## 7.0.0-beta.7 - 2026-09-20 - Doku-Nachzug zu #119: die Verpflichtungsschicht erreicht Installation, Setup und docs/
 
 **Author:** Torben Nehmer
 
@@ -74,6 +74,7 @@ concern - readable here, never shipped as something to parse.
 - wikitool review: the weekly GTD review as a read-time join
 - wikitool new project: Seite und Tracker-Projekt unter einem Namen
 - Skill weekly-review: turning wikitool review's findings into decisions
+- Doku-Nachzug zu #119: die Verpflichtungsschicht erreicht Installation, Setup und docs/
 
 **Low impact**
 - new project: Testabdeckung fuer die required-responsibility-Ablehnung
@@ -222,6 +223,51 @@ zusammen). Die Kommandoflaeche bleibt bei `review`/`new project`; alles Aufgaben
 naechste Aktion anlegen, `follow_up_at` verschieben, einen Someday-Eintrag streichen - bleibt eine
 Handlung im Tracker selbst, weil dafuer kein `wikitool`-Kommando existiert (D31).
 
+### Doku-Nachzug zu #119: die Verpflichtungsschicht erreicht Installation, Setup und docs/
+
+Gitea #119, nach Abschluss von #122-#127: die sechs Umsetzungspakete haben ihre Vertragszeilen
+jeweils mitgebracht (`tools/CONTRACT.md`, `kb/CONTRACT.md`), aber drei Flaechen blieben zurueck,
+die kein Paket fuer sich allein besass - und keine davon faellt bei `docs verify` auf, weil dort
+keine Zeile fehlt, sondern Prosa.
+
+- **`INSTALL.md` § Konfiguration kannte `.wikitool-tasks.json` nicht.** Die Datei stand in
+  `tools/CONTRACT.md`s `doctor`-Zeile und in `review`s Fehlerkontrakt, also dort, wo ein Agent
+  nachschlaegt - nur nicht dort, wo ein Mensch die Form nachschlaegt. Sie steht jetzt neben
+  `.wikitool-telemetry.json` und `.wikitool-remotes.json`, mit vollstaendigem Beispiel, den drei
+  Schwellwerten als Konfiguration statt Schema, und dem fuer Super Productivity getrennten
+  Lese-/Schreibpfad. Die `doctor`-Beschreibung unter § Verifikation nennt den Tracker jetzt mit.
+- **`setup-instance.md` bot den Tracker nie an.** Eine neue Instanz bekam Typ und Collection ueber
+  die generische Template-Adoption (Schritt 5), aber nichts fragte nach der anderen Haelfte des
+  Rueckblicks. Neuer Entscheidungspunkt (Schritt 11, parallel zur Telemetrie): einmal fragen,
+  `.wikitool-tasks.json` anlegen oder nichts tun - kein Tracker ist ein gueltiger Endzustand. Die
+  Form steht nicht hier, sondern in `INSTALL.md` (Invariante 8). Folgenummern 12-16 nachgezogen,
+  Skill-Liste um `weekly-review` ergaenzt.
+- **`upgrade-instance.md` hatte keinen Pfad fuer ein neu ausgeliefertes `.template`.** Genau der
+  Fall, den 7.0.0 erzwingt: Schritt 5 sagte „`new` braucht keine Entscheidung", und die
+  Schritt-6-Tabelle sagt, instanzeigene Dateien koennten dort gar nicht auftauchen - beides
+  richtig und zusammen irrefuehrend, weil ein neues `types/<name>.md.template` fuer einen
+  geforderten Typ sehr wohl eine Handlung braucht. Schritt 5 benennt diese eine Ausnahme jetzt,
+  Schritt 9 traegt die Reparatur neben der TOC-Reparatur: die gewoehnliche Adoption, mit den zwei
+  `cp`-Zeilen, ausdruecklich keine Datenmigration.
+
+Dazu die Begruendung selbst: **`docs/knowledge-and-commitment.md`** ist neu und haelt fest, warum
+Wissen und Verpflichtung zwei Schichten sind (verschiedene Halbwertszeiten), warum nicht
+synchronisiert wird (Muster 4, mit den drei verworfenen Anordnungen), warum der Join zur Lesezeit
+passiert und nichts speichert, warum ein Name die Pflichten eines Identifiers erbt, warum eine
+Seite ihre Aufgabenliste nie zusammenfasst, warum Archivierung ein `state:`-Wert ist, und warum
+keine Instruction je den Provider nennt. Das stand bisher ausschliesslich in Gitea #119 - und ein
+Issue ist genau das, was `dist export` nicht mitliefert: eine ausgelieferte Instanz bekam den
+Mechanismus ohne das Warum. `AGENTS.md` § File naming zaehlt jetzt sechs statt fuenf von dort
+verlinkte `docs/`-Seiten.
+
+`tools/README.md` § Layout fuehrt `review.py` und das Paket `tasks/`; und
+`instructions/dev/doc-pull-through.md` bekommt die zwei Zeilen, deren Fehlen dieser Nachzug ist:
+eine fuer eine instanzeigene Konfigurationsdatei (INSTALL.md § Konfiguration + der
+`setup-instance`-Entscheidungspunkt + `doctor`s Vertragszeile), eine fuer einen neuen geforderten
+Seitentyp oder eine neue Collection (Type-Spec/`COLLECTION.md` + `kb/CONTRACT.md` + **beide**
+Adoptionspfade). Die Zeile zur `docs/`-Begruendung sagt jetzt zusaetzlich, dass eine Entscheidung
+ohne Seite die eigentliche Luecke ist, weil Begruendungen aus einem Issue nie ausgeliefert werden.
+
 ---
 
 ## 6.2.0 - 2026-09-19 - Entity-Subtyp project nach codebase umbenannt