pitroom 0.6.10 → 0.7.0

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "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 or Claude Code workers, with receipts that prove the savings.",
-  "version": "0.6.10",
+  "version": "0.7.0",
   "author": {
     "name": "TahaAtas"
   },

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "pitroom",
-  "version": "0.6.10",
+  "version": "0.7.0",
   "description": "A free pit crew for your expensive coding agent: delegate research, fixes, tests, reviews and parallel investigations to cheap worker agents running your own models, with verified answers, exact diffs and cost receipts.",
   "author": {
     "name": "TahaAtas"
@@ -19,6 +19,7 @@
     "workflow"
   ],
   "skills": "./skills/",
+  "hooks": "./hooks/codex-hooks.json",
   "interface": {
     "displayName": "Pitroom",
     "shortDescription": "Cheap workers for your agent",

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # Changelog
 
+## 0.7.0
+
+### Codex
+- The Codex plugin registers hooks (`hooks/codex-hooks.json`, named in `.codex-plugin/plugin.json`): Pitroom is introduced at session start, so the agent knows it even when Codex drops skill descriptions because many skills are installed, and a job card follows each `pitroom` command. Codex asks you to trust the plugin's hooks once. The hooks go through `pitroom` on PATH (`pitroom hook-start` is new) and stay silent when it is missing. Checked against Codex 0.159.
+
+### CLI
+- `pitroom init` proposes a starter config from the worker CLIs and OpenCode models you have: a fallback chain from your free models, tiers when more than one CLI is installed. It never picks your model, and writes only with `--yes` (`--force` to replace a file, which is kept as `.bak`).
+- `pitroom doctor` groups its checks (Setup, Worker chain, one section per worker CLI, Skills and agents), ends with one verdict line and a Next list of the commands the findings point to, and warns when the first `node` on PATH is too old. Colour only on a terminal (`NO_COLOR` and `FORCE_COLOR` are honoured); `ls`, `status`, `history` and run reports colour the state too.
+- The `pitroom` command is now a small launcher that finds a Node 22.13+ (`PITROOM_NODE`, nvm, Homebrew, `/usr/local`) when the shell's own `node` is old, instead of crashing with a syntax error; without one it says how to fix it.
+- A timed-out run's report says what to do: raise the limit with `-t` (or `PITROOM_TIMEOUT`) for a long job, or `--continue`.
+
+### One figure for savings
+- The Stats tab (and `pitroom history stats`) takes its saved figures, total, per worker and per day, from the ledger, the same ones the Live tab, `pitroom savings` and the status line add up. They used to be calculated twice and could differ.
+- A run that finished while another process was marking it as crashed no longer loses its usage and savings.
+
+### Dashboard
+- Cards name the model the worker really ran (what the CLI reported), not just `opencode`; terminal cards do too.
+- The close button closes the card (its click used to bubble into the card's open handler and re-open it). The step list scrolls by hand while a worker runs and follows new steps only while you are at the bottom.
+- A `#run-id` link opens that run as the same expandable card the lists use, pinned above the page, and clears the link when closed; `/api/run/:id` carries the card. A page opened in a background tab fetched nothing until shown: fixed.
+- The state icons explain themselves on hover and focus (a clock is a timeout).
+- No `NaN%` for a worker the history has no run for.
+
 ## 0.6.10
 
 ### Verified answers

package/README.md

@@ -270,7 +270,7 @@ pitroom install
 | Path | You get |
 |---|---|
 | Claude Code plugin | The 14 skills, the session-start hook that introduces Pitroom, and a card after each `pitroom` command. |
-| Codex plugin | The 14 skills. Codex has no session-start hook, so Pitroom is not introduced on its own: the skills load when a task matches, or name one. `pitroom` itself comes from npm. |
+| Codex plugin | The 14 skills, a session-start hook that introduces Pitroom (so it is known even when Codex drops skill descriptions because many are installed), and a card after each `pitroom` command. Codex asks you to trust the plugin's hooks once. The hooks call `pitroom`, which comes from npm (`npm i -g pitroom`). |
 | npm + `pitroom install` | The CLI, and the skills linked into `~/.agents/skills` and `~/.claude/skills`. |
 
 Pick one path, not several: `doctor` warns if the skills load twice. The plugins alone do not put `pitroom` on your PATH, so install it from npm too if you want to run it yourself (`watch`, `models`, `savings`, the status line).
@@ -442,7 +442,7 @@ pitroom ls [--running] [-g NAME] · pitroom clean [--days 14] [--yes]
 pitroom savings [--since 7d|30d|all] [--models] [--card file.svg] [--badge]
 pitroom models [worker] [--all] [--json]      models, effort levels, your costs, your usage
 pitroom statusline [--then CMD] · pitroom hook-card
-pitroom doctor [--probe] · pitroom config · pitroom install [--copy] [--force] · pitroom uninstall
+pitroom doctor [--probe] · pitroom config · pitroom init [--model ID] [--fallback A,B] [--yes] [--force] · pitroom install [--copy] [--force] · pitroom uninstall
 ```
 
 Exit codes: `0` ok · `1` worker failed · `2` usage · `3` refused/setup · `4` timeout · `5` read-only violation · `6` verify failed · `75` still running.
@@ -551,7 +551,7 @@ Fallbacks cross backends (e.g. `"fallback": ["codex:#low", "opencode"]`): a work
 
 </details>
 
-Or put defaults in `~/.config/pitroom/config.json` (flags and env still win); `pitroom config` shows every effective value and where it came from. `models` gives each worker a default model for targets that name none (`-W codex`, a `"codex"` fallback); a model in the target or `-m` still wins. `tiers` names workers for `--tier` and for plan tasks' `**Worker:**` lines:
+Or put defaults in `~/.config/pitroom/config.json` (flags and env still win); `pitroom config` shows every effective value and where it came from. `pitroom init` proposes a starter config from the worker CLIs and OpenCode models you have (a fallback chain of your free models, tiers when more than one CLI is installed) and writes it only with `--yes`; it never picks your model for you. `models` gives each worker a default model for targets that name none (`-W codex`, a `"codex"` fallback); a model in the target or `-m` still wins. `tiers` names workers for `--tier` and for plan tasks' `**Worker:**` lines:
 
 ```json
 {

package/bin/pitroom.cjs

@@ -0,0 +1,68 @@
+#!/usr/bin/env node
+'use strict';
+// The `pitroom` command. Plain ES5 so that even an old Node can run it: it finds a Node.js of 22.13 or newer
+// and runs dist/pitroom.mjs with it. Agent apps often run commands in a shell whose first `node` is an old one
+// (an installer's Node 14 in /usr/local/bin, say), where the real CLI would only crash with a syntax error.
+var cp = require('child_process');
+var fs = require('fs');
+var path = require('path');
+
+var MIN = [22, 13];
+var cli = path.join(__dirname, '..', 'dist', 'pitroom.mjs');
+
+function ok(v) {
+  return v[0] > MIN[0] || (v[0] === MIN[0] && v[1] >= MIN[1]);
+}
+function parse(text) {
+  var m = /(\d+)\.(\d+)\.(\d+)/.exec(String(text));
+  return m ? [Number(m[1]), Number(m[2]), Number(m[3])] : null;
+}
+function versionOf(bin) {
+  var r = cp.spawnSync(bin, ['-p', 'process.versions.node'], { encoding: 'utf8', timeout: 5000 });
+  return r.status === 0 ? parse(r.stdout) : null;
+}
+function newer(a, b) {
+  return a[0] - b[0] || a[1] - b[1] || a[2] - b[2];
+}
+
+// PITROOM_TEST_NODE_VERSION only lets the tests pretend this Node is old.
+var current = parse(process.env.PITROOM_TEST_NODE_VERSION || process.versions.node) || [0, 0, 0];
+var node = process.execPath;
+
+if (!ok(current)) {
+  node = null;
+  var candidates = [];
+  if (process.env.PITROOM_NODE) candidates.push(process.env.PITROOM_NODE);
+  // PITROOM_NODE_SEARCH (a path-delimited list) replaces the places searched below; the tests use it.
+  var nvm = path.join(process.env.NVM_DIR || path.join(process.env.HOME || '', '.nvm'), 'versions', 'node');
+  try {
+    candidates = candidates.concat(
+      fs.readdirSync(nvm).filter(function (d) { return /^v\d+\.\d+\.\d+$/.test(d); })
+        .sort(function (a, b) { return newer(parse(b), parse(a)); })
+        .map(function (d) { return path.join(nvm, d, 'bin', 'node'); }),
+    );
+  } catch (e) { /* no nvm */ }
+  candidates.push('/opt/homebrew/bin/node', '/usr/local/bin/node', '/usr/bin/node');
+  if (process.env.PITROOM_NODE_SEARCH !== undefined) candidates = process.env.PITROOM_NODE_SEARCH.split(path.delimiter).filter(Boolean);
+  for (var i = 0; i < candidates.length && !node; i++) {
+    if (!fs.existsSync(candidates[i])) continue;
+    var v = versionOf(candidates[i]);
+    if (v && ok(v)) node = candidates[i];
+  }
+  if (!node) {
+    process.stderr.write(
+      'pitroom needs Node.js ' + MIN.join('.') + ' or newer, but this shell runs Node.js v' + current.join('.') + ' (' + process.execPath + ').\n' +
+      'Install a current one and make it the default, for example:  nvm install 24 && nvm alias default 24\n' +
+      '(or put a newer node first on PATH, or set PITROOM_NODE=/path/to/node)\n',
+    );
+    process.exit(1);
+  }
+}
+
+var r = cp.spawnSync(node, [cli].concat(process.argv.slice(2)), { stdio: 'inherit' });
+if (r.error) {
+  process.stderr.write('pitroom: could not run ' + node + ': ' + r.error.message + '\n');
+  process.exit(1);
+}
+if (r.signal) process.kill(process.pid, r.signal);
+process.exit(r.status === null ? 1 : r.status);