v0.13.8

Changed

• The oam floor moves from 0.15.2 to 0.18.0, so the postgres-mcp launcher
  no longer runs the server on an older oam. This server is verified on one
  oam release at a time, and the floor keeps the launcher off anything older
  than that release. 0.18.0 is verified on the published
  aarch64-pc-windows-msvc binary, checksum matched against the release
  SHA256SUMS, through the launcher with OAM_BIN pointing at it and a local
  PostgreSQL 18.3: a full MCP handshake listing all 23 tools (the same 23 as on
  Node), a pg_readonly query answering byte-for-byte as it does on Node (same
  rows, same dataTypeName values), and the server process confirmed as that
  binary (oam run .../dist/index.js as the launcher's child). The sandbox the
  README documents was re-measured on it: with POSTGRES_MCP_SANDBOX=1 POSTGRES_MCP_RUNTIME=oam the launcher spawns oam --permission --allow-net=localhost:5432 --allow-env=... run, the same query answers as it
  does on Node, and under the same flags a connect to port 5433 and a file read
  are refused with ERR_ACCESS_DENIED. If the launcher finds only an oam from
  0.15.2 to 0.17.x, it now falls back to Node under the default
  POSTGRES_MCP_RUNTIME=auto, and exits with an error under
  POSTGRES_MCP_RUNTIME=oam or POSTGRES_MCP_SANDBOX=1 -- it says so on
  stderr, naming the version it found and the floor (measured with oam 0.17.0:
  is oam 0.17.0, older than 0.18.0; using Node instead.). On Node every tool
  answers the same; what is lost is the sandbox, which needs a fresh oam at the
  floor and refuses to start without one. A host that launches the command with
  oam run on 0.15.2 to 0.17.x now hands off to a newer oam or to Node instead
  of serving in-process. A client that runs oam run /path/to/postgres-mcp/dist/index.js directly bypasses the launcher and keeps
  the oam it names. Run oam self-update, or set POSTGRES_MCP_RUNTIME=node to
  make the choice explicit.

Fixed

• release.sh waits up to 600 s, not 300, for npm to serve a new version before
  the MCP Registry step, and polls npm up to 120 times 5 s apart in its final
  check, not five times. scripts/post-publish-smoke.sh tries its npm install
  of the new version up to 60 times, 10 s apart, instead of once. On 2026-09-29
  the @yawlabs/fetch-mcp 0.8.2 release spent 295 s of its 300 s gate waiting for
  npm to serve the new version, and npx needed 313 s, 24 of its 30 attempts,
  to install @yawlabs/lemonsqueezy-mcp 1.0.1. Release tooling only; the server
  itself is unchanged.
• release.sh runs every mcp-publisher call to the MCP Registry, each login and
  each publish attempt, under coreutils timeout (MCP_PUBLISH_TIMEOUT_S,
  default 90 s) where one (or Homebrew's gtimeout) is on PATH -- without one
  the call runs unbounded, and a warning says so -- because mcp-publisher waits
  for the registry's answer with no limit of its own and a registry that never
  answered would have hung the release. A publish attempt that gets no answer is
  retried on the same 30, 60 and 90 s clock as the registry's own 429-504: one
  the limit stopped, which used to hang the step, and one whose connection
  failed or dropped (the client's error sending request or
  error reading response), which used to fail it at once. A login the limit
  stopped says the registry did not answer; one that failed any other way says
  how to read mcp-publisher's output (a 401 is the registry refusing the token
  exchange; a 429, a 5xx or a connection error is the registry or the network)
  instead of naming token scopes, which never fail a login: the registry reads
  the org role at login and refuses only at publish. A publish refused with a
  403 says what the io.github.YawLabs namespace takes: a YawLabs org Owner whose
  token can read org roles. Release tooling only; the server itself is
  unchanged.