@gonrocca/zero-pi 0.1.46 → 0.1.48

package/README.md

@@ -92,6 +92,12 @@ zero-pi keeps its state in `~/.pi/zero.json` (per-phase models + autotune mode)
 and `~/.pi/zero-runs.jsonl` (the run-metrics log); per-project artifacts live
 under `.sdd/`. Set `ZERO_RESUME=off` to disable the conversation-resume note.
 
+## Continuous integration
+
+The `.github/workflows/zero-pi-ci.yml` workflow runs on every push to `main` and
+on every pull request that touches `packages/zero-pi/**`. It enforces `npm test`
+and `npm run pack-check` for the package.
+
 ## 🔗 Relationship to `zero`
 
 zero-pi is the pi layer of the **zero** integrator. The `zero` CLI installs it

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gonrocca/zero-pi",
-  "version": "0.1.46",
+  "version": "0.1.48",
   "description": "zero-pi — an installable layer for pi (pi.dev): the zero spec-driven development workflow (explore → plan → build → veredicto) with per-phase model autotune and token-efficient batched builds. Adds capability to pi without modifying pi.",
   "type": "module",
   "keywords": [
@@ -60,7 +60,8 @@
   ],
   "scripts": {
     "test": "node --test --experimental-strip-types",
-    "prepublishOnly": "node --test --experimental-strip-types"
+    "prepublishOnly": "node --test --experimental-strip-types",
+    "pack-check": "npm pack --dry-run"
   },
   "engines": {
     "node": ">=20.6.0"

package/prompts/phases/veredicto.md

@@ -13,6 +13,17 @@ orchestrator's existing run-trace machinery — the Cortex `zero-run/<slug>` sav
 and the `~/.pi/zero-runs.jsonl` append. Do not write a separate verdict file;
 `.sdd/` artifacts stay plan state only.
 
+**Locating the code — read, do not search.** To check the build against the
+plan, read the `## Code roots` section in `design.md` (or the explore findings)
+for the absolute paths this feature touches, and read the build result for the
+files it changed — go straight to those paths to inspect the changes and run the
+tests. Do **not** run a filesystem-wide `find`/`grep` to rediscover where the
+code lives, and do **not** re-read a file you have already read this review
+unless it changed since; repeated re-reading is the main avoidable token cost on
+the review's model, which is often the most expensive in the pipeline. A single
+targeted search to fill a genuine gap is fine; a full-tree scan is not. This
+bounds cost only — it never lowers the bar for the verdict.
+
 Review the build adversarially, with a fresh perspective. Check it against the
 plan's requirements, run the tests yourself, and look for gaps, regressions,
 and unmet acceptance criteria.