converters: Testkorpus und Harness ziehen nach torben/chemenu-testfiles, Workflow Converters mit Pfad-Trigger, Release-Gate (#232); 10.1.0-beta.2

Files changed:
- .gitattributes
- .gitea/workflows/converters.yml
- .gitea/workflows/release.yml
- .gitignore
- CHANGES.md
- VERSION
- docs/dev/development.md
- instructions/dev/dev-setup.md
- instructions/dev/publish-and-ci.md
- instructions/dev/testing-conventions.md
- testfiles/README.md
- testfiles/mail/github-outlook.msg
- testfiles/mail/github-roundcube.eml
- testfiles/mail/gog-outlook.msg
- testfiles/mail/gog-roundcube.eml
- testfiles/mail/gog-roundcube.eml.expect
- testfiles/mail/tldr-outlook.msg
- testfiles/mail/tldr-roundcube.eml
- testfiles/office/excel-artificial.xlsx
- testfiles/office/excel-business.xlsx
- testfiles/office/excel-business.xlsx.expect
- testfiles/office/excel-science.xlsx
- testfiles/office/pptx-baseline.pptx
- testfiles/office/pptx-master.pptx
- testfiles/office/pptx-objects.pptx
- testfiles/office/word-complex.docx
- testfiles/office/word-simple.docx
- testfiles/pdf/einstein-dissertation.pdf
- testfiles/pdf/ifg.pdf
- testfiles/pdf/nist-ai-rmf.pdf
- testfiles/pdf/nist-ssdf-genai.pdf
- testfiles/zip/archive.zip
- tools/chemenu/tests/test_raw_derive_testfiles.py

Co-Authored-By: Claude Code <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SnAJ7Z3CpVD3PRbN73QtU2

instructions/dev/dev-setup.md

@@ -40,6 +40,7 @@ development material under `instructions/dev/` and `commonplace/`, and no
    | `USER.md`/`SOUL.md` describe a demo operator and persona | Written by the operator during setup |
    | `tools/wikitool dist upgrade` refuses: there is no stamp to compare against. The checkout follows `main` with `tools/wikitool sync` | Updated with `dist upgrade --latest` |
    | `instructions/dev/`, `docs/dev/`, `commonplace/` and `.gitea/` are present | Never shipped |
+   | `testfiles/` may hold the private test corpus (step 6) | Never present |
 
 5. **Use `dist export` as a build and test tool.** It writes exactly the tree a release ships, so
    it is how a change to the shipped surface is looked at before it is released:
@@ -56,6 +57,23 @@ development material under `instructions/dev/` and `commonplace/`, and no
    `.gitea/workflows/ci.yml` is that replay and the reference for it. Keep scratch trees outside
    this checkout.
 
+6. **Clone the private test corpus, if you have access.** The real documents the converters are
+   tested against, and the harness that runs them, are a repository of their own and not part of
+   this one:
+
+   ```bash
+   git clone ssh://git@gitea.nehmer.net:10101/torben/chemenu-testfiles.git testfiles
+   cd tools && .venv/bin/python -m pytest -c pytest.ini ../testfiles/harness
+   ```
+
+   The clone sits in `testfiles/`, which `.gitignore` excludes; it is deliberately not a
+   submodule. Without access nothing breaks: `pytest` in `tools/` needs none of it, and a
+   session that changes a converter leaves the real-document run to the `converters` workflow
+   ([publish-and-ci.md](publish-and-ci.md) step 3). What is missing without the clone is the
+   local run of that harness, nothing else. The corpus holds files that may not be public, so
+   nothing from it is copied into this repository, an issue or a bug report without its README
+   saying the file could be public.
+
 ## Decision points
 
 - **Asked to set up an instance from this checkout** (`dist export` into the user's folder, or a

instructions/dev/publish-and-ci.md

@@ -7,7 +7,8 @@ description: How a stack change is published and how its CI run is waited for -
 
 The local checks cover what they cover on this machine; CI covers the same checks plus a full
 `setup-instance.md` replay against a fresh `dist export` (`.gitea/workflows/ci.yml`). A green run
-on the published commit is therefore the end of the checked stretch of a work package, not a
+on the published commit - and, for a converter change, a green `Converters` run (step 3) - is
+therefore the end of the checked stretch of a work package, not a
 formality after it - which is why waiting for it belongs to the phase that wrote the code
 (`stack-build`), and a red run sends the work back there rather than into the closing phase.
 
@@ -54,6 +55,17 @@ formality after it - which is why waiting for it belongs to the phase that wrote
    - Keep the polling out of the main context where the harness allows it - a background
      command or a fork - so a long wait does not fill the session with run listings.
 
+   **Converter changes have a second run.** When the published commit touches the converter
+   surface - `tools/chemenu/filters/`, `tools/chemenu/commands/raw/derive.py` or `accept.py`,
+   `tools/chemenu/tests/test_raw_derive*.py`, `tools/chemenu/tests/binary_formats.py`,
+   `tools/requirements.txt` or `.gitea/workflows/converters.yml` - the `Converters` workflow
+   (`converters.yml`) starts by itself beside CI and derives the real documents of the private
+   test corpus. It takes longer than CI (allow **10 minutes**); wait for it the same way, with
+   the same give-up time, and count a red run like a red CI run (step 4). Start it by hand
+   (`actions_run_write`, `dispatch_workflow` on `main`) when only the private repository changed
+   or when the commit reaches the converters only indirectly. A release without suffix runs the
+   same steps as the first job of `release.yml`, which the release waits for.
+
 4. **A red run is not waited past.** Read the failing job's log, fix the cause, and go back to
    step 1: this is still build work, whichever skill published. The phase that published ends
    only on a green run, and the issue stays open until there is one.

instructions/dev/testing-conventions.md

@@ -187,7 +187,15 @@ Whenever you add or change a test under `tools/chemenu/tests/`.
 
 ## Scope
 
-Applies to `tools/chemenu/tests/` only. It says nothing about what to test - the test/review
+Applies to `tools/chemenu/tests/` only. Tests against **real documents** are not among them:
+they live in the private repository `chemenu-testfiles` (`harness/`, with the corpus beside it),
+cloned into the gitignored `testfiles/` ([dev-setup.md](dev-setup.md) step 6) and run with this
+checkout's `tools/.venv` by the `converters` workflow. A new file for the corpus is a case for
+that harness, not a fixture here; the synthetic filter tests (`test_raw_derive.py`,
+`test_raw_derive_binary.py`) stay and are what the suite relies on. The harness borrows this
+suite's `conftest.py`, so a change to a fixture there reaches it too.
+
+This file says nothing about what to test - the test/review
 expectations for a stack change are the local checks in [publish-and-ci.md](publish-and-ci.md)
 (`docs verify`, `instructions verify`, pytest), run from `stack-build`. CI runs the suite once,
 unhardened, because the fixture makes a second hardened run redundant; see the note on the Tests