pitroom 0.26.0 → 0.27.0

package/docs/backends.md

@@ -175,7 +175,11 @@ How a worker is started, and why:
 
 ## Antigravity CLI notes
 
-Status: **beta**. Checked against **agy 1.3.5** on macOS (October 2026): a read run, a follow-up, an isolated edit, shell commands in the sandbox, the deny rules, an unknown model, a used-up quota and a missing sign-in were run against the real CLI, and `test/fixtures/antigravity` holds their recorded output (home paths replaced). Not yet checked on Linux (the sign-in file link) or Windows (`doctor` says to use `-i` there).
+Status: **macOS**; **beta** on Linux and Windows, where it has not been run yet. Checked against **agy 1.3.5** on macOS (October 2026): a read run, a follow-up, an isolated edit, shell commands in the sandbox, the deny rules, an unknown model, a used-up quota and a missing sign-in were run against the real CLI, and `test/fixtures/antigravity` holds their recorded output (home paths replaced). Checked again against **agy 1.4.7** on macOS (2026-10-25) with `scripts/check-worker.mjs`: all eight checks held once edit runs granted writes in their workspace, which agy 1.4 asks for. Not yet checked on Linux (the sign-in file link) or Windows (`doctor` says to use `-i` there).
+
+To check it on another machine: sign in to `agy` there, then, from a checkout of this repository (`npm install && npm run build`), run `node scripts/check-worker.mjs antigravity:<model>`. It makes a new git repository in the temp folder and a Pitroom state folder of its own (your projects, history and savings are left alone) and tries what was tried on macOS: `doctor --probe`, a read, a follow-up, a read of a file outside the project, a shell command, an isolated edit, a commit the git guard must refuse, and an unknown model. It prints PASS, FAIL or SKIP for each and writes a JSON report to the temp folder. A used-up quota and a missing sign-in cannot be brought about on purpose; `pitroom doctor` reports both when they happen.
+
+The primary agent side has its own check: Cursor. `pitroom install --mcp --client cursor`, restart Cursor, then in a project ask its agent to "use pitroom_run to find where X is defined" (a read), "use pitroom_run with mode isolate to add a comment to Y" (then `pitroom_review` and `pitroom_apply`), and "what did pitroom cost today" (`pitroom_info`, topic savings). Each should show up in `pitroom dash`.
 
 Why it is here: Google refuses a Google account sign-in to Gemini CLI (`IneligibleTierError`, "migrate to the Antigravity suite"), so for someone without an AI Studio key, `agy` is the way to use their Google account's models (Gemini, and the Claude and GPT-OSS models Antigravity offers).
 

package/gemini-extension.json

@@ -1,6 +1,6 @@
 {
   "name": "pitroom",
-  "version": "0.26.0",
+  "version": "0.27.0",
   "description": "A free pit crew for your expensive coding agent: hand reading, fixes, tests and reviews to cheap worker agents and get back the answer, the exact diff and a receipt. Fourteen skills adapt a full development workflow. Needs the pitroom command (npm i -g pitroom).",
   "contextFileName": "gemini-context.md"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pitroom",
-  "version": "0.26.0",
+  "version": "0.27.0",
   "mcpName": "io.github.ATASTECH/pitroom",
   "description": "A free pit crew for your expensive coding agent: the superpowers development workflow, run by cheap workers. Delegate research, fixes, tests, reviews and whole plans from Claude Code, Codex or any agent to OpenCode, Codex, Claude Code or Gemini CLI workers, with receipts that prove the savings.",
   "type": "module",

package/skills/pitroom-driven-development/re-review-prompt.md

@@ -11,7 +11,7 @@ It contains, in order:
 1. BRIEF: the task that was requested.
 2. PREVIOUS FINDINGS: the previous review; its Critical and Important findings and spec gaps are under verification.
 3. FIX REPORT: what the implementer says it changed, with the tests it re-ran.
-4. FIX DIFF: only this fix round's changes, with 10 lines of context.
+4. FIX DIFF: only this fix round's changes, with 10 lines of context, each line led by its line number in the file after the change.
 
 Your working directory contains the code after the fix. You are read-only: do not change files, the index, HEAD or branches.
 
@@ -38,4 +38,4 @@ In DETAILS, in this order:
 - FINDING VERDICTS: for each finding, in order, the finding in one line, then ADDRESSED or NOT ADDRESSED with file:line evidence. "Attempted" is not addressed: the specific defect must no longer exist.
 - NEW BREAKAGE: problems the fix introduced, with severity and file:line, or "none".
 - OUT OF SCOPE: issues entirely outside the fix diff, or "none".
-A file:line is the project file's path and its line number after the change (from the diff's hunk headers), never a line of the package file. No preamble and no closing summary.
+A file:line is the project file's path and the line number in front of the line in the FIX DIFF (the file after the change), never a line of the package file. No preamble and no closing summary.

package/skills/pitroom-driven-development/task-reviewer-prompt.md

@@ -10,7 +10,7 @@ One file holds everything; read it once: {{PACKAGE_FILE}}
 It contains, in order:
 1. BRIEF: what was requested (for a plan task: the plan's context, its global constraints and the task).
 2. REPORT: what the implementer claims it built, with its test evidence.
-3. DIFF: the change under review, with 10 lines of context.
+3. DIFF: the change under review, with 10 lines of context, each line led by its line number in the file after the change.
 
 Your working directory contains the code after this change. The diff's context lines are your view of the changed files: open a changed file only when a hunk you must judge is cut off mid-function, and say so. Do not crawl the codebase: look outside the diff only to check a concrete risk you can name (a changed contract, lock order, shared mutable state: then check its call sites), one focused check per named risk, and name both the risk and the check.
 
@@ -43,7 +43,7 @@ If the brief lists several files each with its own change, check that every list
 - Tests verify real behaviour (not mocks) and cover the task's edge cases.
 - Each file has one clear responsibility; the plan's file structure is followed; the change does not create files that are already large or grow existing files much (pre-existing size is not a finding).
 
-Cite file:line for every finding, and for every check you would otherwise answer with a bare "yes". A file:line is the project file's path and its line number after the change (from the diff's hunk headers), never a line of the package file.
+Cite file:line for every finding, and for every check you would otherwise answer with a bare "yes". A file:line is the project file's path and the line number in front of the line in the DIFF (the file after the change), never a line of the package file.
 
 ## Calibration
 

package/skills/pitroom-review/code-reviewer.md

@@ -7,7 +7,7 @@ You are a senior code reviewer. Review completed work against its plan or requir
 ## What to read
 
 One file holds everything; read it once: {{PACKAGE_FILE}}
-It contains WHAT WAS IMPLEMENTED, REQUIREMENTS (the plan's goal, global constraints and tasks when there is a plan), NOTES FROM EXECUTION (rulings and deferred findings, when there are any), then the COMMITS, the FILES CHANGED and the DIFF with 10 lines of context.
+It contains WHAT WAS IMPLEMENTED, REQUIREMENTS (the plan's goal, global constraints and tasks when there is a plan), NOTES FROM EXECUTION (rulings and deferred findings, when there are any), then the COMMITS, the FILES CHANGED and the DIFF with 10 lines of context, each line led by its line number in the file after the change.
 
 The diff is your view of the change. Open other files in your working directory only to check a concrete risk you can name, and say what you checked. You are read-only: do not change files, the index, HEAD or branches, and do not check out other revisions.
 
@@ -35,4 +35,4 @@ SUMMARY: SPEC: PASS|FAIL · QUALITY: APPROVED|NEEDS_FIXES · ISSUES: critical=N
 
 SPEC is FAIL when planned functionality is missing or the implementation departs from the requirements. QUALITY is APPROVED only when the branch is ready to merge as it is.
 
-In DETAILS, in this order: STRENGTHS, CRITICAL, IMPORTANT, MINOR (each issue with file:line, what is wrong, why it matters and how to fix it if not obvious), NOTES TRIAGE (only when the package has notes), RECOMMENDATIONS. No preamble and no closing summary.
+In DETAILS, in this order: STRENGTHS, CRITICAL, IMPORTANT, MINOR (each issue with file:line, what is wrong, why it matters and how to fix it if not obvious), NOTES TRIAGE (only when the package has notes), RECOMMENDATIONS. A file:line is the project file's path and the line number in front of the line in the DIFF (the file after the change), never a line of the package file. No preamble and no closing summary.