v0.17.0

Answer cache

• The same read question on the same code gets the earlier answer back at once instead of a new worker run (pitroom ⟲ cached answer · … · no worker ran). The key is the question (whitespace does not count), where it was asked, the attached files' contents, where the worker reads (a clean snapshot or in place) and the project's exact state: HEAD and a tree of every working file, uncommitted and untracked included (made with git's own index, so unchanged files are not re-hashed). Only answers that held up are reused: a finished read run with an answer, every reference verified, nothing written, and no audit still running or disagreeing, for cacheDays (default 7; 0 turns it off; PITROOM_CACHE_DAYS). Follow-ups, web runs, plan tasks, reviews, audits, --audit, --verify, crews and changes are never cached; --fresh asks a worker anyway and its answer is reused from then on. Git-ignored files and the worker/model are not part of the key (documented; --fresh for those). With --bg --json the earlier run comes back already done, marked "cached": true.

MCP server

• Smaller tool definitions. Ten tools instead of eighteen, nothing lost: parallel work is pitroom_run with tasks (was pitroom_crew), every report is pitroom_info with a topic (runs, history, stats, savings, models, cooldown, config (new), doctor; were seven tools), pitroom_show gives a running run's progress (was pitroom_status, and run now defaults to the latest), and pitroom_stop with cooldowns clears the cooldowns. Descriptions are shorter. The definitions sit in the client's context for the whole session: about 1.9k tokens now, 3.3k before. An option that does not go with a topic is an error that names the ones that do.
• Run notifications. A client can subscribe to a run's resource (resources/subscribe on pitroom://run/<id> or its /patch) and is told when the run changes state (for /patch also when it changed more files) or is gone (notifications/resources/updated); every client is told when the newest run changes (notifications/resources/list_changed; runs starting within one check are one notification). Read from the run records every 2 s, only while a client can be told; at most 100 subscriptions per client. An event stream nobody uses (no request, no event for an hour) is closed with its session. Over HTTP a GET with Accept: text/event-stream opens the session's event stream, where these arrive (one stream per session, kept alive with comments); a client without one is told once it opens it. Few clients act on these yet; the tools work the same without them.

Fixes

• pitroom review in a linked git worktree: the review package was written to the worktree's git directory, which lies outside the worktree, and a sandboxed reviewer (OpenCode) was refused reading it, so the review had nothing to review. There it now goes to <worktree>/.pitroom/ (added once to the repository's info/exclude, so git status stays clean) and is removed when the review ends. Found by having Pitroom review its own branches from a worktree.

MCP Registry

• server.json describes Pitroom for the MCP Registry (io.github.ATASTECH/pitroom: the npm package, stdio, pitroom mcp), and package.json has the mcpName the registry checks. npm run bump keeps its version in step, and turns an ## Unreleased CHANGELOG section into the version's entry.

From real-world tests (Codex driving Pitroom over MCP)

• --verify under an MCP client. An app that starts Pitroom often passes a bare PATH, and npm test was "command not found" (exit 127). The verify command now also finds the Node running Pitroom (npm and npx sit next to it) and the usual install places, after your own PATH; a command that still is not found is reported as "could not run (exit 127: command not found)" with what to do, not as a failing test.
• A failed --verify is no longer shown as success. The report says ⚠ done · verify failed instead of ✔ done, an MCP result is an error (isError, as is a read-only violation), and the dashboard shows a warning icon on the card and lists the run under Needs attention.
• Audits check the question, not only the references. The auditor must check every condition the question sets (scope, exclusions, "all", "only", counts), look for missing and extra items in a list and recount a count; AGREE needs all of them. In the tests an answer that listed 8 files outside the asked directory got AGREE from two of three auditors, because its references were valid.
• Skills over MCP. An agent using the MCP tools did not think of Pitroom's skills. The server's instructions now name them and say to use the matching one, pitroom_run points to using-pitroom, and every skill is also a prompt of the same name (its text, with how the CLI commands in it map to the tools), for clients that have no skills.
• pitroom review --range A..B shows the branch's own change, from where it left A, as a pull request does. When A had moved on since (another PR merged), the diff also showed A's newer commits as if the branch undid them.
• An OpenCode model answering "Endpoint is unavailable" (HTTP 400) is treated as rate-limited: it cools down and the next worker runs (this already worked; it now has a test).