v0.4.0 — status updates stop eating the analysis

The release that stops the tool from destroying its own data.

The bug worth upgrading for

jobs.notes served two incompatible purposes: the reasoning behind a score, written by save_job_analysis, and follow-up notes, written by set_application_status. Recording "applied on the 17th" silently destroyed the analysis.

The failure was selective in the worst possible way — the jobs you kept touching were the jobs you cared about, so the highest-scoring records in a store were exactly the ones whose reasoning was gone. It also contradicted the product's own guarantee: resume_versions is append-only, enforced by the database.

Schema v5 splits them. notes is the analysis and set_application_status never names it in its UPDATE. status_notes is a timeline the status tool only ever appends one dated line to. Structurally impossible to repeat, rather than a rule someone has to remember.

Existing databases upgrade on open. No action needed.

New: delete_job

The first destructive, id-targeted tool in the surface. A record that should not exist — mistyped, duplicated, test data — had no exit, and withdrawn is a real event worth keeping, not a synonym for "this is garbage".

It deletes the job and its captured description, but keeps tailored resume versions and only unlinks them (job_id set to NULL). A resume you actually sent outlives the posting it was aimed at.

Lookup is by id or url only, never custom_title — that field is not unique, and deleting by an ambiguous key is how the wrong record gets destroyed. There is no undo, so the result names the job and every version it unlinked.

Schema upgrades that actually run

_ensure_schema decided on table presence, so a database created by an earlier release took the fast path forever and would never see a statement added later. Every schema addition since the SQLite rewrite had been silently skipping existing installs.

_apply_pending_upgrades closes it: an _UPGRADES registry keyed by target version, applied under BEGIN IMMEDIATE with user_version re-read under the write lock, additive and idempotent. Its first passenger is an index on resume_versions(created_at DESC) — every resume read path orders by it, and all four were doing SCAN + USE TEMP B-TREE, sorting a table holding full resume text to return one row.

"This tool never raises" was false

connect() translated only its own setup phase; a statement failing inside the yielded block stayed a raw sqlite3.Error. Every tool caught ValueError alone, so a full disk or a corrupt page escaped as a traceback instead of an error envelope. Seven tools now catch sqlite3.Error too.

Install

/plugin marketplace add satovarb16/runway
/plugin install runway@satovarb

Already on the plugin? /plugin marketplace update satovarb, then /plugin update runway@satovarb, then /reload-plugins.

Or manually, in a .mcp.json where you run Claude Code:

{
  "mcpServers": {
    "runway": {
      "command": "uvx",
      "args": ["--from", "runway-mcp==0.4.0", "runway-mcp"]
    }
  }
}

Note on names. This tag's tree still says runwayMCP throughout. The project was renamed to Runway after v0.4.0 shipped: the repository, the plugin, and the MCP server are now runway, while the PyPI distribution stays runway-mcp and the database stays at ~/.config/runway-mcp/runway.db. The commands above are the ones that work today. No server code changed in the rename.

Unlike v0.3.1, this pin resolves from PyPI rather than a git ref — no git and no source build required.

v0.3.1 — a tag whose tree matches what master says

Important

This release is kept as it was written in September 2026. Two things below are now out of date.

The names changed. The project was renamed to Runway after this release: the repository, the plugin, and the MCP server are all runway now. The install commands in this document no longer work as written — /plugin install runway-mcp@satovarb will not resolve. The current commands are /plugin marketplace add satovarb16/runway and /plugin install runway@satovarb. The PyPI distribution is still runway-mcp.

PyPI is no longer blocked. The note further down says plain uvx runway-mcp pulls 0.1.2; it now pulls 0.4.0, and releases have published to PyPI since v0.3.1. The git-ref pin below is no longer the only working path.

For an install that works today, see the latest release.

---

A packaging-only release. No server code changed since v0.3.0 — server.py, tools/, and every tool contract are byte-identical. If the plugin is already running for you, nothing about its behavior changes.

Why this exists

The v0.3.0 tag pointed at a commit three behind master. Its tree carried an outdated README and a plugin pin of runway-mcp==0.3.0 — a version that does not exist on PyPI, which still serves 0.1.2. So anyone browsing or installing from that tag got stale docs and a pin that fails outright.

The tag could not simply be moved: uvx resolves a git ref once and caches the commit it found, so a moved tag leaves everyone who already installed it building the old commit forever. Hence a new version.

v0.3.1 is the first tag whose tree actually carries the working git pin.

Install

/plugin marketplace add satovarb16/runwayMCP
/plugin install runway-mcp@satovarb

Or manually, in a .mcp.json where you run Claude Code:

{
  "mcpServers": {
    "runway-mcp": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/satovarb16/runwayMCP@v0.3.1", "runway-mcp"]
    }
  }
}

Already on the plugin? /plugin marketplace update satovarb then /plugin update runway-mcp@satovarb, and /reload-plugins.

The git URL is deliberate. Plain uvx runway-mcp pulls 0.1.2 from PyPI — a much older server from before the SQLite rewrite, with a tool set that no longer matches the README. PyPI publishing is blocked pending account recovery.

Release-process fixes

• The version checklist said "four places". There are six. It omitted manifest.json's --from pin, the README's manual-install snippet, and the test asserting the version. The README omission was the dangerous one — nothing checked the snippet every manual installer copy-pastes.
• The version guard no longer hardcodes a version. test_version_is_0_3_0_everywhere had the number baked into its own name, so every release had to edit the test meant to be guarding it. It now reads the version from pyproject.toml and asserts the other five sites agree.
• The publish job is gated on a repository variable instead of failing on every tag with invalid-publisher. This is the first Release run in this repo's history to come back green.

Full changelog: v0.3.0...v0.3.1