pitroom 0.6.4 → 0.6.6

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.4",
+  "version": "0.6.6",
   "author": {
     "name": "TahaAtas"
   },

package/.codex-plugin/plugin.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: 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"

package/CHANGELOG.md

@@ -1,5 +1,53 @@
 # Changelog
 
+## 0.6.6
+
+### Node.js 22.13 or newer
+- Pitroom now needs Node.js 22.13+ (`engines`, the launcher, the CI matrix of 22 and 24, the build target). It is the first release line with a built-in SQLite (`node:sqlite`) that needs no flag, which the run history uses.
+
+### History in SQLite
+- Every finished run is written to `history.db` (built-in `node:sqlite`, FTS5): the task, worker and model, time, tokens, savings, the worker's steps, its answer and the diff, plus the whole record.
+- `pitroom history [TEXT]` searches and filters (`--model`, `--state`, `--group`, `--since`, `--limit`, `--json`); `pitroom history stats` shows runs, success rate, average time and tokens per worker and model; `pitroom history import` takes in older runs (it also runs by itself on first use).
+- After a run the raw event stream is compressed (about a sixth of its size) and the stderr log is kept only for runs that did not succeed. `pitroom clean` now keeps the history: `show`, `show --patch` and a short run id keep working for cleaned runs.
+- The dashboard serves `/api/history` and `/api/stats`.
+
+### A new dashboard
+- `pitroom dash` is now a React app built from [shadcn/ui](https://ui.shadcn.com) components on [Base UI](https://base-ui.com), with [Shadix UI](https://shadix-ui.vercel.app)'s expandable card and [beUI](https://beui.dev)'s agent activity stream, and tabs: **Live** (running and recent runs as cards that grow, with a shared-layout animation, into a panel with the task, the worker's steps, the result, the diff and the details), **History** (full-text search and filters over the SQLite history, a table, a side panel per run) and **Stats** (success rate, time, tokens and savings per worker and model, runs per day). Light and dark themes.
+- It is built once into `dist/ui` (esbuild and the Tailwind CLI, from `ui/`) and served as two static files; the CLI still has no runtime dependencies. The page's Content-Security-Policy allows only its own files and one hashed inline script.
+
+### Seeing Pitroom in the Claude Code and Codex apps
+- `pitroom dash` serves a live, read-only page of every run on `127.0.0.1` (state, worker and model, time, steps, tokens, savings, result; click a run for its report). `--detach` starts it in the background and prints the address (a running one is reused), `--stop` ends it, `--open` opens a browser, and it closes itself after four idle hours. The host must be `localhost`, `127.0.0.1` or `[::1]`, and only GET is answered.
+- `pitroom watch --brief` prints one card line when a run starts, when it falls back and when it ends, then a total: made for Claude Code's Monitor tool and for a Codex command block.
+- Click a card in the dashboard to see what the worker was asked (the task), what it did step by step (files read, searches, commands, edits, with times), its result, the files and diff it changed, and the details (model, tokens, cost, fallbacks, reference check). Runs can be searched and older ones loaded; `#run-id` in the address opens a card.
+- Worker adapters record a step-by-step timeline from the event stream (`ParsedRun.timeline`).
+- Cards name a range review by 9-character hashes instead of 40.
+- The skills tell the agent to start the dashboard and give you its address when workers run in the background.
+
+## 0.6.5
+
+### Models, costs and effort
+- `pitroom models [worker] [--all] [--json]` lists what Codex (from its model cache), Claude Code (aliases) and OpenCode (`opencode models`) offer, the effort levels each model accepts, your costs and what your own runs used (runs, average tokens, reported dollars).
+- Config `costs` (`{"codex:gpt-6-sol": 1, "codex:gpt-6.1-sol": 2}`): your relative cost per model. Pitroom cannot know vendor prices, so it does not guess them; `pitroom doctor` prints the cost of the models in use and notes a cheaper one you priced.
+- `--effort LEVEL` for every worker (`model#level`: Codex effort, Claude Code `--effort`, OpenCode variant). The skills tell the agent to pick the cheapest model and the lowest effort that fits.
+- Fix: a target that names only an effort (`codex:#low`) skipped the configured `models` default and ran the vendor's own default model. It now gets the configured model with that effort. A Codex or Claude Code worker with no pinned model gets a warning.
+
+### More workers, free first
+- Up to 20 workers run at once by default (`maxParallel`), 30 at most; before, the default was 4. The rest queue and the fallback chain absorbs free-tier rate limits.
+- An optional `review` tier in `tiers` names who reviews a run (and needs no same-backend warning). The skills start on the `cheap` tier, OpenCode's free model, and raise a task only when it needs more; plans are written the same way.
+
+### Project files
+- `THIRD_PARTY_NOTICES.md` carries the MIT notice of superpowers, which the workflow skills are adapted from, and ships in the npm package; the README stays clean and links to it.
+- `CODE_OF_CONDUCT.md`, issue forms (bug report, feature request), a pull request template and a contact-link page for security reports.
+- `npm run bump -- patch|minor|major|X.Y.Z` moves the version in `package.json`, `package-lock.json` (which still said 0.1.0) and both plugin manifests together and adds a CHANGELOG heading; a test fails while any file disagrees or the new CHANGELOG heading still has its placeholder text.
+
+### README
+- The workflow and the architecture are SVG diagrams (they render on GitHub and on npm, unlike mermaid). The speed gain is stated with measured numbers: 470 s of worker time in 156 s of wall clock.
+- Install commands per agent as copy-and-paste blocks (Claude Code, Codex, npm), with update and uninstall; diagrams for the workflow and for how a run flows; the free-first setup, `pitroom models`, costs and effort are explained; the hard-coded version line is gone (the badges show the real versions).
+
+### Seeing Pitroom at work
+- The card hook also reaches the agent (`additionalContext`), so the user hears which worker and model ran even where the host shows no hook messages. Runs that finished without a card are announced on the next `pitroom` command.
+- `pitroom savings --models` lists workers and models with runs, tokens, cost and savings.
+
 ## 0.6.4
 
 ### Deleting is the user's call

package/PRIVACY.md

@@ -2,29 +2,45 @@
 
 _Last updated: 2026-09-30_
 
-Pitroom is a command-line tool and a set of agent skills that run on your own computer. This page says what it does with your data.
+Pitroom is a command-line tool and a set of agent skills that run on your own computer. This page says what data is involved, what for, who receives it, how long it is kept and what you can do about it.
 
 ## What the Pitroom authors collect
 
 Nothing. Pitroom has no accounts, no analytics and no telemetry, and its own code makes no network requests. No data is sent to the authors.
 
-## What happens when you delegate work
+## Data categories and purposes
 
-Pitroom starts a worker agent CLI that you installed and signed in to yourself. Whatever you ask a worker to do is handled by that CLI and by the model provider behind it:
+When you delegate work, Pitroom handles these categories of data, only to carry out that work:
 
-- the task text you or your agent write;
-- the files the worker reads in your project;
-- for reviews, the diff under review with 10 lines of context, written to a package file the reviewer reads.
+| Data | Purpose |
+|---|---|
+| The task text you or your agent write | Tell the worker what to do |
+| Files of your project that the worker reads, and its edits | Let the worker do the task; return an exact diff |
+| For reviews, the diff under review with 10 lines of context | Let a second worker review the change |
+| Run records: the task, the worker's answer, diffs, timings | Let your agent and you read results, apply or undo them |
+| Savings ledger: token counts, cost estimates, worker and model names per run (no task text, no code) | Show what delegating saved |
+| Settings you choose (`~/.config/pitroom/config.json`) | Remember your worker, models and tiers |
 
-That data goes to the provider of the worker's model, under that provider's terms and privacy policy, not under this one. Pitroom does not filter the content it hands to a worker: secrets that are committed to a reviewed range are sent as they are. Workers cannot read `.env` files or private key files through Pitroom's permission profiles. To keep code on your machine, point the worker at a local model.
+Project files may contain personal data of yours or of third parties; Pitroom does not look for it, filter it or add to it.
 
-## What Pitroom stores on your computer
+## Recipients
 
-- Run records (the task, the worker's answer, diffs, receipts and the savings ledger) in `~/.local/state/pitroom`, or in the folder named by `PITROOM_HOME`.
-- Optional settings in `~/.config/pitroom/config.json`.
-- Private working copies of your project for isolated runs, inside the state folder. They are removed when you apply or discard a run.
+Pitroom starts a worker agent CLI that you installed and signed in to yourself. The task text, the files it reads and, for reviews, the diff go to that CLI and to the provider of the worker's model, under that provider's terms and privacy policy, not under this one. Pitroom does not filter this content: secrets committed in a reviewed range are sent as they are. The file-reading tools of OpenCode and Claude Code workers refuse `.env` files and private keys, but Codex workers are not restricted that way and a shell command can still read such files, so keep secrets out of the project folder you delegate in. To keep code on your machine, point the worker at a local model. Nobody else receives data from Pitroom.
 
-Nothing is stored in your repository. To delete the records, run `pitroom clean` or remove the state folder.
+## Where data is stored and for how long
+
+- Run records and the savings ledger: `~/.local/state/pitroom`, or the folder named by `PITROOM_HOME`. Pitroom never deletes them by itself: they stay until you remove them.
+- Private working copies of your project for isolated runs: inside the same folder, removed when you apply or discard the run.
+- Settings: `~/.config/pitroom/config.json`, until you delete it.
+
+Nothing is stored in your repository.
+
+## Your controls
+
+- `pitroom clean --yes` removes run records older than 14 days (change it with `--days N`); unapplied isolated patches are kept, and so is the savings ledger.
+- Delete the state folder to remove everything, including the ledger; delete the settings file to reset your settings.
+- `pitroom discard <run>` removes a run's private working copy.
+- You choose which worker CLI and model receive your data (`-W`, `config`), and whether a worker may use the web (`--web`, off by default).
 
 ## Changes and contact