feat!: installation only from a release, into an empty folder; upstream merge/verify and private-instance.md removed, dist adopt, shell-neutral instructions (#153)

Files changed:
- .gitea/workflows/ci.yml
- .gitea/workflows/release.yml
- AGENTS.md
- CHANGES.md
- DEVELOPMENT.md
- EVALS.md
- INSTALL.md
- README.md
- VERSION
- docs/ownership-and-templates.md
- instructions/CONTRACT.md
- instructions/bootstrap.md
- instructions/dev/dev-setup.md
- instructions/dev/stack-dev/SKILL.md
- instructions/gates.md
- instructions/ingest-large-tree.md
- instructions/kb-profiles.md
- instructions/mcp-read-server.md
- instructions/migrations/3.0.0-authoring-conventions.md
- instructions/preflight.md
- instructions/private-instance.md
- instructions/session-setup.md
- instructions/setup-instance.md
- instructions/upgrade-instance.md
- tools/CONTRACT.md
- tools/README.md
- tools/chemenu/cli.py
- tools/chemenu/cli_contract.py
- tools/chemenu/commands/dist_cmd.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/git_publish.py
- tools/chemenu/commands/upstream_cmd.py
- tools/chemenu/commands/work_cmd.py
- tools/chemenu/config.py
- tools/chemenu/ownership.py
- tools/chemenu/tests/test_cli.py
- tools/chemenu/tests/test_dist_cmd.py
- tools/chemenu/tests/test_instructions_shell.py
- tools/chemenu/tests/test_preflight.py
- tools/chemenu/tests/test_preflight_pwsh.py
- tools/chemenu/tests/test_run_budget.py
- tools/chemenu/tests/test_upstream_cmd.py
- tools/chemenu/toc.py
- tools/preflight.ps1
- tools/preflight.sh

DEVELOPMENT.md

@@ -13,6 +13,62 @@ Grund steht dort als Kommentar, damit eine spätere Sitzung die vermeintliche L
 `INSTALL.md` oder `EVALS.md`, die `instructions verify` auf genau diesen Punkt prüft - nach
 `instructions/dev/` verlinken.
 
+## Entwicklungsumgebung
+
+Am Stack wird in einem Klon dieses Repos gearbeitet. Ein solcher Klon ist **keine Instanz** und
+wird nie eine. Instanzen entstehen ausschließlich aus Releases, siehe [INSTALL.md](INSTALL.md).
+
+```bash
+git clone https://gitea.nehmer.net/torben/chemenu.git
+cd chemenu
+```
+
+Danach den Agenten `instructions/bootstrap.md` ausführen lassen: Preflight, dann
+`tools/wikitool instructions sync`. Die Agenten-Seite dazu - was hier anders ist als in einer
+Instanz und wie `dist export` als Testwerkzeug läuft - steht in
+[instructions/dev/dev-setup.md](instructions/dev/dev-setup.md).
+
+Was ein Klon mitbringt und eine Instanz nicht:
+
+- **Den Demo-Korpus.** Rund 170 Seiten, die den Stack selbst dokumentieren: Gates, Lint,
+  Versionierung, Suche, das Wiki-Muster. Er ist Testbett und begehbares Beispiel, keine
+  produktive Wissensbasis. Was an ihm geändert werden darf, regelt
+  [instructions/dev/corpus-policy.md](instructions/dev/corpus-policy.md).
+- **Eine Demo-Persona** in `USER.md`/`SOUL.md`. `doctor` meldet beide als ausgefüllt. Sie
+  beschreiben den Demo-Betrieb, nicht dich.
+- **Telemetrie an.** Ohne `.wikitool-release.json` ist der Klon die Messstation, mit der der
+  Stack sich selbst bewertet ([EVALS.md](EVALS.md) § „Whether it runs at all“).
+- **`instructions/dev/`, `commonplace/`, `.gitea/` und diese Datei.** `dist export` liefert
+  davon nichts aus.
+
+`ENVIRONMENT.md` fehlt nach jedem Klon, weil die Datei gitignored ist: Sie beschreibt einen
+Checkout, nicht das Repo. Wer sie anlegt (Vorlage `ENVIRONMENT.md.template`, Schritt 5 in
+`instructions/bootstrap.md`), erspart jeder Stack-Sitzung die Fragen nach Harness, `gitea-mcp`
+und Remote.
+
+### `dist export` als Build- und Testwerkzeug
+
+`tools/wikitool dist export <leeres Verzeichnis>` schreibt genau den Baum, den ein Release
+ausliefert: Maschinerie ohne Wiki-Inhalt, ohne Git-Historie, ohne `instructions/dev/`. Damit
+prüft man vor einem Release, was ausgeliefert würde (`--dry-run` listet es nur). Und man spielt
+den Installationsweg nach, ohne auf ein Release zu warten: Tarball daraus bauen wie
+`.gitea/workflows/release.yml`, dann das Preflight-Skript in einem leeren Verzeichnis mit
+`--archive <tarball>` starten. Der CI-Schritt „The distribution works as a fresh instance“ in
+`.gitea/workflows/ci.yml` macht genau das.
+
+Für eine echte Instanz ist ein solcher Export kein Weg. Ihm fehlen die Release-Herkunft im
+Stamp, und `dist upgrade --latest` vergleicht später gegen einen Stand, den es nie als Release
+gab.
+
+### Ein Release-Feed in einem nicht öffentlichen Repo
+
+Wer den Stack in einem eigenen, nicht öffentlichen Repo betreibt und Instanzen von dort
+aktualisiert, lässt `WIKITOOL_UPDATE_URL` auf dessen Feed zeigen. Dabei gibt es eine Eigenheit:
+Gitea antwortet anonymen Aufrufern für ein unsichtbares Repo mit demselben `404` wie für ein gar
+nicht existierendes. Ein fehlendes Release und ein fehlender Zugriff sehen dann identisch aus –
+„kein Update gefunden“ wäre in dem Fall schlicht falsch. Dagegen hilft ein Gitea-Token mit
+Lesezugriff in `WIKITOOL_UPDATE_TOKEN`. Es geht nur an Downloads auf demselben Host wie der Feed.
+
 ## Der Release-Ablauf
 
 Zwischen zwei Releases führt der Stack **einen** laufenden Versionskandidaten statt einer neuen
@@ -75,8 +131,9 @@ eine Sitzung ihn tatsächlich durchläuft:
    `VERSION` bewegt: Eine suffixbehaftete `VERSION` (ein Kandidat) lässt den Job sauber
    überspringen, bevor er die Releases-API überhaupt anfragt - Betas werden nie veröffentlicht.
    Eine suffixfreie `VERSION` baut die Distribution (`dist export`), erzeugt Tag und Release und
-   lädt Tarball plus Prüfsumme hoch. **CI setzt den Tag, nie eine Sitzung** - das hält
-   Invariante 5 intakt.
+   lädt Tarball und Prüfsumme hoch, dazu die beiden Preflight-Skripte und die Anleitungen
+   `setup-instance.md` und `preflight.md`, auf die der Installationssatz in `INSTALL.md` zeigt.
+   **CI setzt den Tag, nie eine Sitzung** - das hält Invariante 5 intakt.
 
 Die drei Verify-Befehle stehen oben in Schritt 3; was jeder von ihnen prüft, steht in
 [tools/CONTRACT.md](tools/CONTRACT.md) und wird dort von `docs verify` gegen die tatsächliche
@@ -90,8 +147,9 @@ Drift also niemandem auf. Was `pytest` an dieser Stelle vom Entwickler erwartet,
 
 `.gitea/workflows/ci.yml` läuft auf jeden Push/PR gegen `main` (Content-Pfade ausgenommen) und
 führt Testsuite, `docs verify`, `instructions verify` sowie einen vollständigen
-`setup-instance.md`-Replay gegen einen frischen `dist export` aus - derselbe Pfad, den ein neuer
-Nutzer tatsächlich geht. `.gitea/workflows/nightly.yml` ist der Drift-Check gegen die Zeit statt
+`setup-instance.md`-Replay aus: ein lokal gebauter Release-Tarball, das Preflight-Skript mit
+`--archive` in einem leeren Verzeichnis, dann die Schritte der Anleitung - derselbe Pfad, den
+ein neuer Nutzer tatsächlich geht, nur ohne Download. `.gitea/workflows/nightly.yml` ist der Drift-Check gegen die Zeit statt
 gegen einen Commit. `.gitea/workflows/release.yml` ist Schritt 6 oben.
 
 Drei weitere Workflows tragen die Live-Tests der Tracker-Adapter (Super Productivity, CalDAV):