@gonrocca/zero-pi 0.1.45 → 0.1.47

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gonrocca/zero-pi",
-  "version": "0.1.45",
+  "version": "0.1.47",
   "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": [

package/prompts/phases/explore.md

@@ -14,6 +14,16 @@ Investigate the codebase and the feature request read-only. Do not modify any
 files. Map the relevant modules, the existing patterns and conventions, the
 integration points, and the constraints. Identify the risks and the unknowns.
 
+**Size exploration to the request.** Match breadth to what the change actually
+needs. A localized change — copy/text, one component, a config value, a single
+endpoint — needs only the files that render or define it plus their immediate
+wiring; do not map the full permission/billing model or unrelated subsystems
+unless the request touches them. A cross-cutting or architectural change earns
+full breadth. Stop once you can name the exact files to change and their
+constraints — reading past that point burns tokens without improving the plan.
+As a rough gauge, a localized change rarely needs more than ~20 tool calls; if
+you blow past that on a small request, you are over-exploring.
+
 Produce a concise findings report the **plan** phase can build on: what exists,
 what is relevant to the request, and what to watch out for.
 

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.