pitroom 0.6.4 → 0.6.6

package/docs/backends.md

@@ -87,7 +87,7 @@ Recorded v2 streams live in `test/fixtures/opencode/{events,failures}/v2-*`; the
 - **Login shells.** Codex runs commands through `zsh -lc`; macOS's `path_helper` and `~/.zprofile` reorder `PATH`, which hides the git-guard shim. The second guard layer (git's own env config: a `reference-transaction` hook and `pushInsteadOf`) holds regardless, for every worker.
 - **Stream**: `item.completed` items of type `error` are warnings (deprecated settings, skills budget), not failures; failures are top-level `error` / `turn.failed`, whose message is a JSON API error. The JSON stream does not name the model, so it is read from the session's rollout file. Cost is not reported.
 - **"Not supported when using Codex with a ChatGPT account"** comes back both for models the account cannot use and for models the installed Codex CLI is too old to know (seen with `gpt-6.1-sol` on 0.146, working on 0.159). It is `model-unavailable`, so the chain moves on, and the message suggests updating Codex.
-- **Node**: `codex` is a Node script (`#!/usr/bin/env node`); Pitroom runs such CLIs on its own Node 18+, since agents' shells often have an older Node first on `PATH`.
+- **Node**: `codex` is a Node script (`#!/usr/bin/env node`); Pitroom runs such CLIs on its own Node 22.13+, since agents' shells often have an older Node first on `PATH`.
 
 ## Claude Code notes
 

package/hooks/session-start.mjs

@@ -19,11 +19,12 @@ try {
   process.exit(0); // broken install: stay silent rather than break the session
 }
 const body = skill.replace(/^---\n[\s\S]*?\n---\n/, '').trim();
-// Fallback when `pitroom` is not on PATH: the installed launcher (it picks a Node 18+),
+// Fallback when `pitroom` is not on PATH: the installed launcher (it picks a Node 22.13+),
 // else this Node if it is new enough, else plain `node`.
 const cli = path.join(root, 'dist', 'pitroom.mjs');
 const launcher = path.join(os.homedir(), '.local', 'bin', 'pitroom');
-const nodeOk = Number(process.versions.node.split('.')[0]) >= 18;
+const [major, minor] = process.versions.node.split('.').map(Number);
+const nodeOk = major > 22 || (major === 22 && minor >= 13);
 const fallback = fs.existsSync(launcher) ? `"${launcher}"` : `"${nodeOk ? process.execPath : 'node'}" "${cli}"`;
 const command = fs.existsSync(cli) || fs.existsSync(launcher) ? `\`pitroom\`, or if that is not on PATH: \`${fallback}\`` : '`pitroom`';
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pitroom",
-  "version": "0.6.4",
+  "version": "0.6.6",
   "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 or Claude Code workers, with receipts that prove the savings.",
   "type": "module",
   "author": "TahaAtas",
@@ -26,16 +26,18 @@
     "README.md",
     "CHANGELOG.md",
     "PRIVACY.md",
+    "THIRD_PARTY_NOTICES.md",
     "LICENSE"
   ],
   "engines": {
-    "node": ">=18"
+    "node": ">=22.13"
   },
   "scripts": {
     "build": "node scripts/build.mjs",
-    "typecheck": "tsc --noEmit",
+    "typecheck": "tsc --noEmit && tsc -p ui/tsconfig.json",
     "test": "npm run build && node --test test/*.test.mjs",
-    "prepublishOnly": "npm run typecheck && npm test"
+    "prepublishOnly": "npm run typecheck && npm test",
+    "bump": "node scripts/bump-version.mjs"
   },
   "keywords": [
     "agent",
@@ -55,8 +57,22 @@
   ],
   "license": "MIT",
   "devDependencies": {
+    "@base-ui/react": "^1.8.0",
+    "@pierre/diffs": "^1.5.1",
+    "@tailwindcss/cli": "^4.3.3",
     "@types/node": "^22.10.0",
+    "@types/react": "^19.3.0",
+    "@types/react-dom": "^19.3.0",
+    "class-variance-authority": "^0.7.1",
+    "clsx": "^2.1.1",
     "esbuild": "^0.25.0",
+    "lucide-react": "^1.49.0",
+    "motion": "^13.5.0",
+    "react": "^19.3.0",
+    "react-dom": "^19.3.0",
+    "tailwind-merge": "^3.7.0",
+    "tailwindcss": "^4.3.3",
+    "tw-animate-css": "^1.4.0",
     "typescript": "^5.7.0"
   }
 }

package/skills/pitroom-crew/SKILL.md

@@ -17,7 +17,7 @@ Don't use it when the failures are related (fixing one might fix the others: inv
 
 ## 1. Split
 
-Parts must be **independent**: no part needs another's result, and no two parts edit the same file. Two to five parts is the sweet spot; at most `maxParallel` workers (default 4) run at a time, the rest queue. Keep dependent or judgment-heavy parts for yourself.
+Parts must be **independent**: no part needs another's result, and no two parts edit the same file. Start as many workers as there are independent parts: up to 20 run at a time by default (`maxParallel`, 30 at most), the rest queue. Keep dependent or judgment-heavy parts for yourself.
 
 ## 2. Write focused briefs
 
@@ -53,10 +53,11 @@ Read-only by default. For changes add `-i` (each worker edits its own isolated c
 ## 4. Watch
 
 Follow the group live without polling:
+- `pitroom watch -g NAME --brief`: one card line when a worker starts and one when it ends, then a total; the user can read it, so prefer it in a host that shows monitor output (Claude Code's Monitor tool).
 - `pitroom watch -g NAME --json`: one JSON line per change (`queued`, `started`, `progress`, `fallback`, `done`/`failed`, then `all-done`). Run it through your host's background or monitor facility so each line reaches you as it happens; it exits by itself when the group is done.
 - No such facility: `pitroom wait -g NAME --timeout 540`, and call it again while it exits with 75.
 - `pitroom status -g NAME`: one table snapshot.
-- Tell the user they can see the same table live with `pitroom watch -g NAME` in a terminal.
+- Tell the user how to see it live: `pitroom dash --detach` prints the address of a read-only page on 127.0.0.1 with every run (open it in a browser or the app's browser pane), or `pitroom watch -g NAME` in a terminal.
 
 While workers run, do the parts you kept for yourself.
 
@@ -76,5 +77,5 @@ pitroom show <run>                  # the full report of the ones you need
 ## When things go wrong
 
 - A worker failed or timed out: retry that part once with a sharper brief, or do it yourself.
-- Rate limits: the fallback chain handles single failures; if many fail, lower `maxParallel` (config or `PITROOM_MAX_PARALLEL`).
+- Rate limits: the fallback chain handles single failures; if many fail at once, lower `maxParallel` (config or `PITROOM_MAX_PARALLEL`) or spread the parts over more than one worker.
 - Stop everything: `pitroom stop -g NAME` (running and queued).

package/skills/pitroom-writing-plans/SKILL.md

@@ -50,7 +50,7 @@ Every task names the worker tier that implements it, on its own line right under
 - **standard**: several files with integration concerns, or an implementer working from prose.
 - **capable**: design judgment or broad understanding of the codebase.
 
-Turn count beats token price: the cheapest models take 2-3× the turns on multi-step work. When unsure between two tiers, take the higher.
+Turn count beats token price: the cheapest models take 2-3× the turns on multi-step work. The user prefers the free tier, so start with `cheap` for everything a cheap worker can plausibly do and raise only the tasks that need more; a failed cheap task costs one retry on a higher tier. When you are truly unsure between two tiers for a task that is costly to redo, take the higher.
 
 ## Bite-Sized Task Granularity
 

package/skills/using-pitroom/SKILL.md

@@ -55,7 +55,9 @@ Once you or the user pick a skill, follow it: its checklists and gates are how i
 
 Call `pitroom` (on PATH after `pitroom install`; otherwise the command in your session context). `pitroom doctor` diagnoses setup problems. Workers and models come from the user's config (`worker`, `fallback`, `models`, `tiers`); pick others only when the user or a plan says so (`--tier capable`, `-W codex`).
 
-Workers can take minutes. Start long work with `--bg` and keep working; follow it with `pitroom watch --json` through your host's background or monitor facility, or call `pitroom wait --timeout 540` again while it exits 75. Never poll with `sleep`.
+Model and effort: tiers already name the workers. Before you pick anything else, run `pitroom models`: it lists what each worker offers (Codex, Claude Code, OpenCode), the effort levels each model accepts, what the user says it costs (`costs` in the config) and what it used so far. Take the cheapest model that fits the task, never a dearer one by habit: start on the `cheap` tier (OpenCode's free model) and move up only when the task needs it or a cheaper worker already failed. Set `--effort` from the task: `low` for lookups and mechanical edits, `medium` for ordinary changes, `high` for reviews and non-obvious bugs, `xhigh` or above only when the user asks or a lower level failed. More effort costs more tokens and time.
+
+Workers can take minutes. Start long work with `--bg` and keep working; follow it with `pitroom watch --brief` (one card line per start and end) through your host's background or monitor facility, or call `pitroom wait --timeout 540` again while it exits 75. Never poll with `sleep`.
 
 ## When you do use it
 
@@ -63,6 +65,8 @@ Workers can take minutes. Start long work with `--bg` and keep working; follow i
 - Worker output is draft work and a worker's report is a claim: verify what you rely on (`pitroom-verification`).
 - You apply patches and commit; workers never commit or push. Push, merge and pull requests happen only after the user asks.
 - Keep the decisions: delegate the reading and typing, not the architecture.
+- Background workers: run `pitroom dash --detach` once and give the user the address it prints: a live page of every run for the apps (Claude Code, Codex) that show neither Pitroom's cards nor its status line.
+- Say what you delegated: one line per worker run naming the worker and model (the run report has both) and what it cost or saved. Not every host shows Pitroom's cards or status line, and the user should always know which model touched their code. `pitroom savings --models` lists them all.
 - You set a worker's permissions when you create it, from the task and from how much autonomy the user gave you in this session (for example auto mode): read-only by default, `-i` (an isolated copy) for changes, `-w` (edits in place) when the user wants that, `--web` only when the task needs the web. A worker never widens its own permissions.
 - Pitroom keeps a fixed floor that no flag lifts: no git history changes, no `sudo`, no publishing, no secrets, no killing processes. Everything above that floor is your call.
 - Deletions are your decision, made as the user's agent. `pitroom apply` refuses a patch that deletes files unless you pass `--allow-delete`. If removing files is what the user asked for or an obvious part of it, apply with the flag and tell them which files went; if the worker deleted something the user did not ask for, ask first, or discard the run.