feat: Publish-Remote Gate und die Anleitung fuer eine private Instanz (2.2.0)

Files changed:
- .gitignore
- AGENTS.md
- CHANGES.md
- VERSION
- instructions/gates.md
- instructions/private-instance.md
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/git_publish.py
- tools/chemenu/config.py
- tools/chemenu/tests/test_git_publish.py

instructions/gates.md

@@ -22,10 +22,11 @@ Read the exit code first - it says which of these applies:
 ## Exit 42: user clearance required
 
 A `wikitool` command that exits **42** is not reporting an error. It is refusing to act until a
-human has *read its output*. Two gates use it today - the Mass-Update Gate (`publish`, on a
-change touching 10 or more counted files) and the rebase-review gate (`sync` and `publish`, on
-a rebase whose incoming commits touch a file this session is also changing) - but the rule is
-about the exit code, not the command:
+human has *read its output*. Three gates use it today - the Mass-Update Gate (`publish`, on a
+change touching 10 or more counted files), the rebase-review gate (`sync` and `publish`, on
+a rebase whose incoming commits touch a file this session is also changing), and the
+Publish-Remote Gate (`publish`, on a push to a target this checkout has not declared) - but the
+rule is about the exit code, not the command:
 
 > **Copy the command's output into your reply - the substance of it, not a description of it -
 > and stop.** Run no further commands in that turn.
@@ -62,6 +63,42 @@ clearance.
 
 Background: [[Mass-Update Gate]] (`kb/concepts/Mass-Update Gate.md`).
 
+### Publish-Remote Gate
+
+The Mass-Update Gate asks whether a change is too large to publish. This one asks the question
+underneath it: **whether this is the right repository to publish to at all.**
+
+A checkout that holds private content usually has two remotes - its own, and the public upstream
+it takes stack updates from. Git does not distinguish them at push time, so one wrong `--remote`
+puts a private corpus on a public repository. That is not cheaply reversible: a force-push moves
+the branch, but the objects stay fetchable by SHA until someone expires the server's reflogs and
+runs `git gc --prune=now` on the bare repo.
+
+`.wikitool-remotes.json` names the push URLs a checkout permits:
+
+```json
+{ "schema": 1, "allowed_push_urls": ["ssh://git@example.net:22/you/your-wiki.git"] }
+```
+
+It pins **URLs, not remote names** - a name-based list would wave through a `publish` whose
+`origin` had been repointed, which is the failure it exists to catch. It reads the remote's
+`pushurl` when one is set, because that is where `git push` actually writes.
+
+The file is per-checkout and gitignored, for the same reason `ENVIRONMENT.md` is: two clones push
+to two different places, so a committed copy would tell a private clone that the public upstream
+is a legitimate target for its own content. **Absent means unrestricted** - a single-remote
+checkout with nothing private in it has nothing to protect, and `doctor` reports which state a
+checkout is in, WARNing only when there is more than one remote and no allowlist. A malformed
+file is an error rather than "no restriction": a corrupted safeguard must not read as a disabled
+one.
+
+**This gate has no `--confirm` token, on purpose.** The other two clear with a token because the
+question they ask ("is this change right?") is one the agent can put to the user and the user can
+answer for that one changeset. This one asks "does this content belong to that repository?", which
+is a standing property of the checkout, not a per-push judgment. The way past it is for the user
+to add the URL to the file. **An agent must never edit `.wikitool-remotes.json` to get past a
+refusal** - that is opening a gate on your own initiative, which AGENTS.md invariant 6 forbids.
+
 ## Iteration Budget Gate and loop-breaker
 
 Every `wikitool` call is counted per session. Calls are refused past **60 in a session**, or

instructions/private-instance.md

@@ -0,0 +1,125 @@
+---
+type: types/instruction.md
+name: private-instance
+description: Set up a private working instance as a clone of a public upstream, so stack updates arrive by merge instead of by copying a tarball over the tree.
+---
+
+# Set up a private instance against a public upstream
+
+The distribution path in [setup-instance.md](setup-instance.md) builds an instance from a
+`dist export` tarball, with no git ancestry in common with the repo it came from. That is the
+right shape for someone who only ever *consumes* the stack.
+
+This is the other shape: a private instance that keeps taking stack changes from a public
+upstream, and whose own content must never travel back. It costs one safeguard to set up and
+saves the whole update procedure afterwards.
+
+**Read this before, not after, the first `publish`.** The gate in step 4 is the thing that makes
+the arrangement safe, and adding it later means the window it closes was open in between.
+
+## Why a clone rather than a tarball
+
+`INSTALL.md`'s "Eine Instanz aktualisieren" is `cp -r` as an upgrade strategy: copy `tools/`,
+`types/`, `instructions/`, `AGENTS.md`, `VERSION` over the existing tree. It has no three-way
+merge, so it cannot notice that the receiving instance changed a file, and it has no conflict
+surface, so nobody learns when upstream and local both touched the same one. It overwrites
+silently.
+
+A clone gets all of that from git. The private `main` deletes the upstream's demo corpus once;
+every later `git merge upstream/main` sees *deleted-in-ours, unmodified-in-theirs* and resolves
+without asking. Stack changes land as real merges, with real conflicts where they conflict.
+
+## Steps
+
+1. **Clone, and name the two remotes for what they are.**
+
+   ```bash
+   git clone <private-repo-url> my-wiki
+   cd my-wiki
+   git remote add upstream <public-repo-url>
+   ```
+
+   `origin` is yours and is the only thing you ever push to. `upstream` is where stack updates
+   come from and is fetch-only.
+
+2. **Make the fetch-only half fetch-only in git, too.**
+
+   ```bash
+   git remote set-url --push upstream no_push
+   ```
+
+   git refuses to push to a URL it cannot resolve. This is a convenience, not the safeguard -
+   step 4 is the safeguard.
+
+3. **Delete the upstream's demo corpus once, on your own `main`.**
+
+   Everything under `kb/` and `raw/` that came with the clone is the upstream's content, not
+   yours. Remove it with `wikitool rm --page` (never `rm -rf`: `rm` de-links each page from the
+   rest of the wiki, and a plain delete leaves dead wikilinks and broken citations behind), then
+   `index rebuild`, `sources rebuild-index`, `lint`.
+
+   This is a one-time cut. Afterwards the upstream corpus is frozen from your side, which is
+   what makes later merges content-free.
+
+4. **Arm the Publish-Remote Gate — before the first `publish`.**
+
+   ```bash
+   cat > .wikitool-remotes.json <<'EOF'
+   { "schema": 1, "allowed_push_urls": ["<your-private-push-url>"] }
+   EOF
+   ```
+
+   Use the URL `git remote get-url --push origin` prints, exactly. `publish` refuses with exit
+   42 for anything else, and there is no flag that opens it - see [gates.md](gates.md).
+
+   The file is gitignored, so it stays with this checkout and never travels to the upstream.
+   `wikitool doctor` reports whether the gate is armed, and WARNs at more than one remote
+   without it.
+
+5. **Take away the write credential, if you can.** A token or deploy key for `origin` only,
+   with no write access to the upstream, is the one control that holds even if everything above
+   is misconfigured. Belt and braces.
+
+6. **Personalize and bootstrap.** `USER.md`, `SOUL.md` and optionally `ENVIRONMENT.md` are
+   yours and unrelated to the upstream's - see the Personalization step of
+   [setup-instance.md](setup-instance.md), then [bootstrap.md](bootstrap.md) for the venv and
+   the skills.
+
+## Taking a stack update
+
+```bash
+git fetch upstream
+git merge upstream/main
+```
+
+Then, as after any stack change: `doctor`, `docs verify`, `instructions verify`, `migrate status`,
+`lint`. A `migrate status` with outstanding links means the update crossed a compatibility
+boundary - follow [migrate-corpus.md](migrate-corpus.md) before doing anything else.
+
+## Where stack development happens
+
+**In the public repo, not here.** That is not a preference; the stack is built that way. The
+development-only half of the instruction layer is pruned from a distribution one-way, with no
+command that reconstructs it, so an instance built this way has no tool-development mode to
+switch into in the first place.
+
+When a tool bug blocks real content work here - and it will - file the issue against the public
+repo (an MCP server or the web UI reaches it from any session; no shared history needed), fix it
+there where the tests, `docs verify` and CI's version gate live, and take the fix back with the
+merge above. Nothing is lost by the detour: the fix has to pass that CI either way.
+
+## Decision points
+
+- **Merge conflict in `kb/` or `raw/`?** Something changed the upstream's corpus after you cut
+  it. Resolve as "keep deleted" - your instance's content is yours, and the upstream's demo
+  corpus has no business in it.
+- **Conflict in `tools/`, `types/` or `instructions/`?** You changed the stack locally, which
+  step "Where stack development happens" says not to do. Take the upstream side and re-file the
+  change as an issue there.
+
+## Scope
+
+Not for a first instance with no upstream - that is [setup-instance.md](setup-instance.md). Not
+for a fresh clone of a repo you already own and develop in - that is
+[bootstrap.md](bootstrap.md). This is specifically the two-remote case, where the cost of a
+mistaken push is disclosure rather than inconvenience.