SKILL.md-Sanierung: Checklisten, Kommandolisten, wiki-status-Hard-Rule, wiki-query-Filingpruefung (schliesst #70, #74, #75, #78)

Files changed:
- CHANGES.md
- VERSION
- instructions/CONTRACT.md
- instructions/wiki-ingest/SKILL.md
- instructions/wiki-lint/SKILL.md
- instructions/wiki-manage/SKILL.md
- instructions/wiki-query/SKILL.md
- instructions/wiki-status/SKILL.md

instructions/wiki-query/SKILL.md

@@ -9,9 +9,11 @@ description: Answer a question using the LLM wiki's compiled knowledge - read-on
 
 **Trigger:** User asks a question.
 
+**Before the first `wikitool` call:** [session-setup.md](../session-setup.md).
+
 **Hard rule:** read-only with respect to wiki *content*. Never modify, hand-edit, or scaffold a
-page while answering. Two exceptions, both mechanical: step 5 (filing a valuable answer through
-`wikitool new`, never by hand) and step 6 (one audit entry via `wikitool log append`). If the
+page while answering. Two exceptions, both mechanical: step 6 (filing a valuable answer through
+`wikitool new`, never by hand) and step 7 (one audit entry via `wikitool log append`). If the
 wiki has no confident source, say so - per AGENTS.md's "never file an unsourced answer"
 invariant - rather than synthesizing a plausible-sounding answer from general knowledge.
 
@@ -46,12 +48,22 @@ invariant - rather than synthesizing a plausible-sounding answer from general kn
    Hedge to the page's confidence: below 0.6 write "possibly"/"may"; below 0.4 write
    "uncertain"/"unconfirmed".
 
-5. **File it back, if it earns a page.** Only when the answer required synthesis across several
-   pages, revealed something not already written down, and will be asked again. Then scaffold
-   it - `tools/wikitool new ...` - and follow `wiki-manage`. Never write the page by hand, and
-   never file an answer no source backs.
+5. **Decide what earns a page - before the first `new`.** Name every page you are considering,
+   then hold each one on its own against all three criteria: the answer required synthesis
+   across several pages, it revealed something not yet written down, and it will be asked
+   again. All three, per candidate. A batch is never judged as a batch - one page clearing the
+   bar says nothing about the next one.
 
-6. **Log it.**
+   A candidate that misses any of the three is not scaffolded. Put one line in the answer
+   naming what was considered and why it stays unwritten, and let the user ask for it anyway.
+   That is the whole cost of being wrong here in the cautious direction; the other direction is
+   a page nobody asked for, which reads exactly like a page the wiki needed and is far harder to
+   find again than a sentence in a chat log.
+
+6. **File back what survived.** Scaffold it - `tools/wikitool new ...` - and follow
+   `wiki-manage`. Never write the page by hand, and never file an answer no source backs.
+
+7. **Log it.**
 
    ```bash
    tools/wikitool log append --op query --title "<question>" --body "<outcome>"
@@ -65,12 +77,14 @@ invariant - rather than synthesizing a plausible-sounding answer from general kn
 - **Filed a page?** Query does **not** auto-publish. Run `tools/wikitool publish` only if asked;
   the sequence is in [publish-cycle.md](../publish-cycle.md).
 - **Several answers filed at once?** That can trip the Mass-Update Gate - see
-  [gates.md](../gates.md).
+  [gates.md](../gates.md). The gate is a brake, not the check: it counts files and knows nothing
+  about whether any of them earned a page. Step 5 is what decides that, and a batch small enough
+  to pass the gate has not been cleared by it.
 
 ## wikitool commands used
 
 `search`, `log append`. If filing an answer back: `new`, `xref add`, `sources rebuild-index`,
-`index rebuild`.
+`index rebuild`, and `publish` only if asked.
 
 ## Output