v1.18.1

Three fixes, two of them to the GitHub Action.

• VS Code in a browser no longer opens a broken tab on every in-app click (#59). In code-server, GitHub Codespaces and vscode.dev, clicking the sidebar's Overview / Specs / Changes, a change card or a spec link also opened a new browser tab at a 404 address, on top of the navigation that did happen inside the panel. VS Code forwards every link click in a webview to the workbench to open, even one the page already handled; desktop VS Code silently refuses those addresses, which is why the bug never showed there. In-app links now stay in the panel, external links still open as before, and the spec page's table of contents scrolls smoothly instead of jumping. Thanks to @Philogag for reporting
• The generated HTML snapshot survives content that looks like markup (#54). An artifact containing </script> ended the page's data early, so the viewer never started and the rest of the data showed up as page text; an artifact containing <!-- followed by <script> stopped the viewer from starting too. Both built without an error. The embedded data and the page title are now escaped, and the build fails, naming the part, if the page it assembled would not read back as written. This affects the GitHub Action's output and the live demo. Thanks to @pierreboissinot (Pierre Boissinot) for reporting and proposing the fix
• The GitHub Action treats its inputs as text, never as shell commands (#56). repo-path, output-path and title were pasted into the action's shell scripts, so a title such as My "draft" specs broke the build's arguments, and a workflow passing in an outside value (a PR title, a branch name) could have that value run as a command. They are now passed as data, and an output-path containing a newline is refused. Behaviour change: a value that relied on the shell expanding it, such as output-path: $HOME/x.html, now arrives literally; ${{ }} expressions in your own workflow are unaffected. Users of spekhq/spek@v1 receive this with this release