tasks.md, from #89's review: the note on the release's pattern is dated

specs/001-biopax-from-graph/tasks.md

@@ -334,7 +334,7 @@ description: 'Tasks for spec 001: BioPAX Level 3 from the graph, as the release
   - **The species:** `-s` takes a list of species ids, each written to its own file; the Jenkinsfile passes the 15 of release 98's published zip (human and the 14 it infers to), read from those files' own `xml:base`. Whether to add _M. tuberculosis_ is issue #84; if so, it is one more id there.
   - **The command:** the stray quote at the end of the `docker run` line, which would have stopped the shell, is gone; the jar is the image's entry point and `-o ./output` lands in the mounted folder (the image's working directory is the container root the Jenkinsfile mounts under).
   - **The release's check** is the DownloadDirectory step's (release-download-directory's Jenkinsfile): every `.owl` in `biopax.zip` must hold `xml:base="http://www.reactome.org/biopax/{release}`. CI's fixture job now runs the same grep on its output; it passes for 98 and fails for 97.
-  - **From #85's review:** a species named with `-s` that has no events now ends the run with exit 1, since the release's check counts files and would not miss one (shown with a species added to the private fixture graph for the run and removed after); CI's second run of the fixture job uses the list form, which its byte comparison holds to the one-by-one run; the Jenkinsfile's credentials reach the shell as `"$user"` and `"$pass"`, quoted, rather than through Groovy (#87, from #86's review, with differences.md's account of what a list with a bad id writes). Noted, not changed: the release's own pattern has no `/` after the release number, so release 9 would match 98's files; the list of 15 is kept in step with what each release publishes by hand.
+  - **From #85's review:** a species named with `-s` that has no events now ends the run with exit 1, since the release's check counts files and would not miss one (shown with a species added to the private fixture graph for the run and removed after); CI's second run of the fixture job uses the list form, which its byte comparison holds to the one-by-one run; the Jenkinsfile's credentials reach the shell as `"$user"` and `"$pass"`, quoted, rather than through Groovy (#87, from #86's review, with differences.md's account of what a list with a bad id writes). Noted then: the release's pattern had no `/` after the release number, so release 9 would match 98's files (the exporter's own check, below, has it); the list of 15 is kept in step with what each release publishes by hand.
   - **The check is the exporter's now (#89):** release-download-directory, whose Jenkinsfile held the `xml:base` check, is on its way to being archived as its files move to their own repositories and the graph. The exporter's Jenkinsfile now checks its own output before the zip is published: one `.owl` for each species named, each with `xml:base="http://www.reactome.org/biopax/{release}/`, the release number ended by its slash so release 9 cannot pass 98's files. CI's mirror has the slash too. Simulated on the fixture's files: it passes for the right release and fails for another, or for one species too many.
   - **Run as written**, as far as this host allows: the image built from this branch, the command's own shape (`--network=host`, the mount, `-o ./output`, `-s` with two species the fixture graph holds) against the private fixture graph, then the Jenkinsfile's `zip -r` and the release's check on the unzipped files: two files, both with the release's base. The release server's own run, with its credentials and graph, is the release's; its time is T024.
 - [ ] T024 [US4] The full run's time recorded against today's step's, which the release's owners provide; the switch's timing agreed with them.