@gonrocca/zero-pi 0.1.40 → 0.1.42

package/extensions/zero-statusline.ts

@@ -98,7 +98,7 @@ export function composeStatusline(p: StatuslineParts): string {
 
   if (p.branch) parts.push(fg(STEEL, p.branch));
 
-  if (p.brand) parts.push(fg(AMBER, p.brand));
+  if (p.brand) parts.push(fg(VIOLET, p.brand));
 
   return parts.join(SEP);
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gonrocca/zero-pi",
-  "version": "0.1.40",
+  "version": "0.1.42",
   "description": "zero-pi — an installable layer for pi (pi.dev): the zero spec-driven development workflow, per-phase model autotune, and skill auto-learning. Adds capability to pi without modifying pi.",
   "type": "module",
   "keywords": [

package/prompts/orchestrator.md

@@ -103,6 +103,46 @@ and the adversarial veredicto. Delegate each phase to its sub-agent and wait
 for its result. The orchestrator keeps control of phase order and the round
 count — the sub-agents only carry out their own phase.
 
+## Build batching
+
+The **build** phase is not one monolithic sub-agent that implements every
+remaining task in a single growing context — that is what drove a real run to
+463k tokens, 39 minutes, and a dropped connection. Run build as a loop of
+bounded batches, each a fresh `zero-build` sub-agent.
+
+Before delegating build — a fresh build phase, or a `corregir`/`replantear`
+re-run — drive this loop:
+
+1. Read the unchecked (`[ ]`) tasks from `tasks.md` in listed order and their
+   `review: ~N changed lines` estimates from the `## Review Workload` section.
+2. Group the unchecked tasks into ordered batches with this exact, deterministic
+   rule:
+   - Walk the unchecked tasks in order, accumulating into the current batch.
+   - Start a new batch when adding the next task would push the batch's summed
+     estimate over **800 changed lines**, or when the current batch already
+     holds **4 tasks** — whichever comes first.
+   - A single task whose own estimate exceeds 800 is its own batch.
+   - If estimates are missing or unparseable, group by the 4-task cap alone.
+3. Invoke `zero-build` once per batch, in listed order. Each brief is a fresh
+   sub-agent (no carried conversation) and names the batch's task numbers
+   explicitly (for example, "implement tasks 4–6 only, then return"). Emit the
+   build phase-start line for each batch, noting the batch as `lote <i>/<n>`, so
+   the loop stays visible. Wait for each batch to return before starting the
+   next.
+4. Repeat until `tasks.md` has no `[ ]` task left, then run **veredicto** once.
+   Never run veredicto between batches.
+
+**Single-batch features behave exactly like before:** when every unchecked task
+fits one batch, build is invoked exactly once.
+
+**Batches are not rounds.** An entire batched build — however many batches it
+took — is one build phase and counts as one build/veredicto round. Batch count
+never touches the iteration cap. A `corregir` verdict re-runs the whole build
+phase (re-batching whatever tasks its defects reopened) as the next round.
+
+**Resume is unaffected.** Each batch marks its tasks `[x]` as they land, so an
+interrupted batched build resumes from the first `[ ]` task with no new state.
+
 ## Model configuration
 
 The per-phase model assignments live in `~/.pi/zero.json`: `models` maps each

package/prompts/phases/build.md

@@ -13,11 +13,32 @@ resume sees the progress. Sanity-check that `tasks.md` parses as a checklist
 before trusting it. If `tasks.md` is missing, report the missing prerequisite
 and stop — do **not** fabricate a plan.
 
+**Locating the code — read, do not search.** Before editing, read the
+`## Code roots` section in `design.md` (or the explore findings) to get the
+absolute paths of the code this feature touches, and read each task's `files:`
+bullet for the exact files. Go straight to those paths. Do **not** run a
+filesystem-wide `find`/`grep` to discover where the code lives, and do **not**
+re-read a file you already read this run unless you have changed it since —
+re-reading the same large file repeatedly is the main avoidable token cost. If
+the code roots are missing or wrong, run a single targeted search to fix them,
+then proceed — never fall back to scanning the whole tree.
+
 Implement the planned tasks in order, test-first where practical. Keep every
 change within the plan's scope — do not expand it on your own initiative.
 
-Run the test suite and make it pass before reporting the phase complete. Report
-what you changed so the veredicto phase has something concrete to review.
+**Scope to your batch.** When the brief names a batch — a set or contiguous
+range of task numbers — implement exactly those tasks, mark each `[x]`, and
+**return**; do not continue into later unchecked tasks (the orchestrator drives
+the next batch). When the brief names no batch, implement all remaining `[ ]`
+tasks. A task that depends on code an earlier batch already wrote reads the
+current file via its `files:` touch-list and the design's code roots — never
+assume an earlier batch's context is still present.
+
+Make the test suite pass before reporting the phase complete, but **batch the
+verification**: run the suite or boot a smoke-test server at meaningful
+checkpoints — once per task group and once at the end — not after every single
+edit. Report what you changed so the veredicto phase has something concrete to
+review.
 
 **Return contract.** Return a concise result envelope to the orchestrator: your
 phase's outcome (findings, plan, build result, or verdict with its concrete

package/prompts/phases/explore.md

@@ -17,6 +17,15 @@ integration points, and the constraints. Identify the risks and the unknowns.
 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.
 
+**Record the code roots.** The findings must open with a `## Code roots` section
+listing the absolute path of every code directory relevant to this feature (for
+example `E:\proj\api`, `E:\proj\web`) — the actual roots where you found the
+relevant modules, never the `.sdd/` directory. When the spec lives on a
+different drive or path than the code, say so explicitly. The build phase reads
+this section to go straight to the code instead of searching the filesystem, so
+it must be accurate and absolute. If you genuinely cannot locate the code,
+record that the code root is unknown rather than guessing.
+
 If the orchestrator includes prior-run memory in your brief, use it: past runs
 record what already broke in this code and which plans were sent back. Fold the
 relevant points into the findings under a "Prior runs" heading.

package/prompts/phases/plan.md

@@ -54,9 +54,13 @@ Write all four into `.sdd/<slug>/`:
   `### REQ:` name line. Any section may be empty or absent; a block name must be
   unique within and across the delta's sections and not collide with an existing
   store name unless it is the target of MODIFIED/REMOVED.
-- **`design.md`** — how it is built (unchanged from before).
+- **`design.md`** — how it is built. It must carry forward the `## Code roots`
+  section from the explore findings — the absolute paths of the code directories
+  this feature touches — so the build phase never has to search for the code.
 - **`tasks.md`** — the ordered task list, keeping its `## Review Workload`
-  section (see below).
+  section (see below). Every task entry must carry a `files:` bullet naming the
+  absolute (or code-root-relative) paths it creates or edits, marking new files
+  `(new)`, so the build phase edits them directly instead of rediscovering them.
 
 Honour the prior-run lessons carried in the explore findings: when a past run
 was sent back with `replantear`, do not repeat the plan mistake it recorded.

package/themes/zero-sdd.json

@@ -42,7 +42,7 @@
     "mdLink": "cyan",
     "mdLinkUrl": "dimSteel",
     "mdCode": "mint",
-    "mdCodeBlock": "",
+    "mdCodeBlock": "mint",
     "mdCodeBlockBorder": "blue",
     "mdQuote": "steel",
     "mdQuoteBorder": "dimSteel",