viafrei 1.5.6 → 1.5.7

package/API.md

@@ -17,7 +17,7 @@ server:** connect any MCP client and call `tools/list`.
 
 | | |
 | --- | --- |
-| Server | `viafrei` 1.5.6 |
+| Server | `viafrei` 1.5.7 |
 | MCP protocol | `2025-06-18` |
 | Streamable HTTP | https://mcp.viafrei.de/mcp |
 | Legacy HTTP+SSE | https://mcp.viafrei.de/sse |

package/CHANGELOG.md

@@ -5,6 +5,36 @@ a Changelog and the versions follow Semantic Versioning.
 
 ## [Unreleased]
 
+## [1.5.7] - 2026-10-02
+
+**Mirrors the server.** The bridge is versioned to match the ViaFrei MCP server it
+relays to. The running server reports 1.5.7 while the registry's latest is 1.5.6, so
+this release moves the package to the server's number and carries whatever had been
+waiting under `[Unreleased]`. Prepared by the `Version sync` workflow: the shipped
+reference was re-captured from the running server, and the probe reported the surface
+**unchanged** — only the version string moved; the capture date is the same day.
+
+### Fixed
+
+- **The generated release lead no longer claims the capture date moved when it did not.**
+  On a day with two releases the snapshot's `capturedAt` stays where it was, and with
+  every platform patch mirrored that is the normal path: 1.5.5 and 1.5.6 both shipped a
+  lead saying "only the version string and the capture date moved" with the date
+  unchanged, and the reviewer wrote the same paragraph about it twice. `recapture()`
+  now reads the date before and after the probe's `--write` and the lead and the
+  pull-request body say what actually moved; both days are pinned by the self-test.
+- **A bot proposal approves its own `pull_request` CI run.** GitHub creates that run for
+  a pull request opened with the workflow token and holds it at `action_required`
+  without executing it (#39–#41). Observed once, on #40: with the run the workflow
+  had dispatched green and that held run unapproved, the merge was refused by the base
+  branch policy, and approving the held run by hand is what made the pull request
+  mergeable — whether the held run blocks or the dispatched run simply does not count
+  toward `main`'s required checks, that observation does not say. The workflow now
+  looks for the run (it is created asynchronously), approves it, and falls back to
+  dispatching CI when it cannot, reporting "no run appeared" and "the approve call
+  was refused" apart, because whether the workflow token may approve at all is not
+  yet measured and the first run's log is the answer.
+
 ## [1.5.6] - 2026-10-02
 
 **Mirrors the server.** The bridge is versioned to match the ViaFrei MCP server it
@@ -1663,6 +1693,7 @@ for it, so the number is free; the bridge will use it when the platform does.
   commits, and a squash makes them unreachable from `main` - which would turn
   the check red on `main` for everybody, for something no contributor did.
 
+[1.5.7]: https://github.com/mavrovde/viafrei-bridge/releases/tag/v1.5.7
 [1.5.6]: https://github.com/mavrovde/viafrei-bridge/releases/tag/v1.5.6
 [1.5.5]: https://github.com/mavrovde/viafrei-bridge/releases/tag/v1.5.5
 [1.5.4]: https://github.com/mavrovde/viafrei-bridge/releases/tag/v1.5.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "viafrei",
-  "version": "1.5.6",
+  "version": "1.5.7",
   "description": "German traffic, rail, parking, charging, fuel, address and weather data in your AI assistant - MCP, no API key. stdio bridge to the hosted ViaFrei MCP server.",
   "keywords": [
     "mcp",