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

instructions/setup-instance.md

@@ -239,25 +239,44 @@ and ready for its first ingest.
     off, and no file is created. `WIKI_TRACE` still overrides in both directions, should a
     single session need to differ.
 
-    `tools/wikitool doctor` reports the result in step 13 (`telemetry`): on/off, why
+    `tools/wikitool doctor` reports the result in step 14 (`telemetry`): on/off, why
     (installation form, this file, or `WIKI_TRACE`), and the current volume against both caps -
     never a `FAIL`, since both directions are a valid state. More on this:
     [EVALS.md](../EVALS.md) § "Whether it runs at all".
 
-11. **Scope the session budget** (details: [session-setup.md](session-setup.md)):
+11. **Decision point - task tracker.** The instance ships the `project` type and the collection
+    its type-spec's `base_dir:` names (`kb/gtd/` here), so committed initiatives have a page from
+    the start. What they do *not* have until this step is the other half of the weekly review:
+    the tracker that owns the open items, which `tools/wikitool review` joins those pages against
+    over the project name. No tracker configured is a legitimate end state - the pages work
+    alone, `review` simply says so and refuses - so ask rather than assume.
+
+    Ask the user once: is there a task tracker to connect? If yes, create `.wikitool-tasks.json`
+    in the repo root (per checkout, no `.template`, **gitignored once it holds a token** - like
+    `.wikitool-telemetry.json` and `.wikitool-remotes.json`), with the provider's own section and
+    the three thresholds the review reads as configuration rather than schema. The shape, the
+    shipped providers, and what Super Productivity in particular needs are in
+    [INSTALL.md](../INSTALL.md) § Konfiguration; do not restate them here. If no, do nothing - no
+    file is created, and adding one later needs nothing from this procedure.
+
+    `doctor` reports the result in step 14 (`tasks`): absent is `OK`, a malformed file is the one
+    `FAIL` here (a broken opt-in must not read as "no tracker configured"), and a configured
+    provider that is simply not running is never a fault.
+
+12. **Scope the session budget** (details: [session-setup.md](session-setup.md)):
 
    ```bash
    export WIKITOOL_SESSION_ID="wiki-$(date +%s)"
    ```
 
-12. **Build the generated indexes** - `dist export` deliberately does not ship them:
+13. **Build the generated indexes** - `dist export` deliberately does not ship them:
 
     ```bash
     tools/wikitool index rebuild
     tools/wikitool sources rebuild-index
     ```
 
-13. **Verify**, in this order:
+14. **Verify**, in this order:
 
     ```bash
     tools/wikitool doctor
@@ -270,7 +289,7 @@ and ready for its first ingest.
     no `WIKITOOL_SESSION_ID`, say) is not a blocker. A `FAIL` names its own fix command; run it
     and call `doctor` again.
 
-14. **Make the first commit:**
+15. **Make the first commit:**
 
     ```bash
     tools/wikitool publish --message "chore: initial instance setup"
@@ -282,9 +301,9 @@ and ready for its first ingest.
     `--confirm <token>` line that publishes once they approve. Details on the gate:
     [gates.md](gates.md).
 
-15. **Restart the agent session.** Harnesses read the skill directories at startup; only
-    afterwards are `wiki-ingest`, `wiki-query`, `wiki-manage`, `wiki-lint` and `wiki-status`
-    available.
+16. **Restart the agent session.** Harnesses read the skill directories at startup; only
+    afterwards are `wiki-ingest`, `wiki-query`, `wiki-manage`, `wiki-lint`, `wiki-status` and
+    `weekly-review` available.
 
 ## Scope