stack: MCP submit-Tool mit Upload Review Gate und Quarantäne-Schreibpfad (schliesst #32)

Files changed:
- .gitignore
- AGENTS.md
- CHANGES.md
- INSTALL-MCP.md
- README.md
- VERSION
- docs/why-gates-are-code.md
- instructions/gates.md
- instructions/ingest-queue.md
- instructions/mcp-read-server.md
- instructions/wiki-ingest/SKILL.md
- raw/CONTRACT.md
- tools/CONTRACT.md
- tools/chemenu/cli.py
- tools/chemenu/commands/docs_verify.py
- tools/chemenu/commands/doctor.py
- tools/chemenu/commands/upload_cmd.py
- tools/chemenu/config.py
- tools/chemenu/mcp/server.py
- tools/chemenu/tests/test_doctor.py
- tools/chemenu/tests/test_mcp_server.py
- tools/chemenu/tests/test_upload.py
- tools/chemenu/tests/test_upload_cmd.py
- tools/chemenu/upload.py

docs/why-gates-are-code.md

@@ -1,11 +1,11 @@
 # Why gates are code
 
-Chemenu has three hard limits - the Mass-Update Gate, the Publish-Remote Gate, and the
-Iteration Budget Gate - and all three live inside `tools/wikitool`, not in a paragraph of
-instructions an agent reads and follows. The rules themselves, and what to do when one trips,
-are in [AGENTS.md § Gates](../AGENTS.md#gates) and [instructions/gates.md](../instructions/gates.md).
-This page is only about the design choice underneath them: why code, and why these three
-mechanisms in particular.
+Chemenu has four hard limits - the Mass-Update Gate, the Publish-Remote Gate, the Upload Review
+Gate, and the Iteration Budget Gate - and all four live inside `tools/wikitool`, not in a
+paragraph of instructions an agent reads and follows. The rules themselves, and what to do when
+one trips, are in [AGENTS.md § Gates](../AGENTS.md#gates) and
+[instructions/gates.md](../instructions/gates.md). This page is only about the design choice
+underneath them: why code, and why these four mechanisms in particular.
 
 ## A suggestion an agent can talk itself past
 
@@ -21,9 +21,9 @@ conversation at all. It runs before the command dispatches, regardless of how co
 case for skipping it seemed a moment earlier. The difference isn't that code is smarter than a
 well-written instruction - it's that code doesn't get talked into anything.
 
-## Why three different mechanisms, not one
+## Why four different mechanisms, not one
 
-The three gates ask three different questions, and each one's shape follows from what kind of
+The four gates ask four different questions, and each one's shape follows from what kind of
 question it is.
 
 The Mass-Update Gate asks *is this change too large to publish unreviewed* - a judgment that
@@ -37,7 +37,16 @@ agent clear it once and then treat the answer as settled, which is exactly backw
 question whose answer shouldn't move at all mid-session. The only way past it is the user
 editing `.wikitool-remotes.json` directly, outside the gate's own flow.
 
-The Iteration Budget Gate asks a third kind of question - not "is this instance correct" but
+The Upload Review Gate asks the Mass-Update Gate's own question - *is this change right?* - at
+the opposite end of its size range: one file from a stranger instead of a changeset from the
+session's own work. That similarity is exactly why it reuses the same shape (a `--confirm` token
+digesting the thing being approved) rather than inventing a fourth one: the two gates differ in
+*who* produced the change and *how much* of it there is, not in what kind of question either one
+is answering, so nothing about the mechanism needed to change - only the boundary it sits behind
+did, since the submission lives in a quarantine the ordinary pipeline never reads at all rather
+than in the working tree `publish` is about to commit.
+
+The Iteration Budget Gate asks a fourth kind of question - not "is this instance correct" but
 "has this session stopped making progress." That's read from the shape of the call history
 itself (call count, repeated identical calls), not from anything about the content of any one
 call.