@gonrocca/zero-pi 0.1.5 → 0.1.7

package/README.md

@@ -46,6 +46,16 @@ Run it with the `/forge <feature>` prompt. The orchestrator drives phase order
 and enforces a hard build/veredicto iteration cap. Each phase has its own prompt
 under `prompts/phases/` so it can be delegated to a dedicated sub-agent.
 
+**Review Workload Forecast** — the plan phase keeps tasks reviewable. Every
+planned task carries a `review: ~N changed lines` estimate, and `tasks.md` gains
+a `## Review Workload` section with the per-task estimates and a bold run total.
+Tasks are sized against a fixed budget of **400 changed lines per task** — an
+internal, non-configurable default (borrowed from gentle-ai), so "small task"
+means the same number on every run. A task whose estimate exceeds the budget is
+split into smaller, individually verifiable tasks; one that genuinely cannot be
+split stays whole and is recorded as an over-budget exception with a reason. The
+orchestrator's plan-phase summary reports the run total and any exceptions.
+
 ### Per-phase models (`/zero-models`)
 
 `/zero-models` is a real pi command — a code handler, not an LLM prompt — for

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gonrocca/zero-pi",
-  "version": "0.1.5",
+  "version": "0.1.7",
   "description": "zero-pi — an installable layer for pi (pi.dev): the zero spec-driven development workflow, skill auto-learning, and an animated ZERO startup banner. Adds capability to pi without modifying pi.",
   "type": "module",
   "keywords": [

package/prompts/forge.md

@@ -4,6 +4,17 @@ description: Run an automatic spec-driven development pipeline for a feature req
 
 Run the zero SDD pipeline for the feature request in the arguments.
 
+**Parse the arguments first.** If the arguments start with `--continue`, this is
+a **resume** run, not a fresh one:
+
+- `--continue` with no slug → resume mode: hand control to the orchestrator's
+  `## Resuming a run` section, which scans `.sdd/*/` for an unfinished run.
+- `--continue <slug>` → resume mode targeting `.sdd/<slug>/` directly. If that
+  directory does not exist, report "no such run: <slug>" and stop — do **not**
+  start a fresh run under that slug.
+- Anything else (a feature request, or no arguments) → a fresh run, exactly
+  today's behaviour: the arguments are the feature request.
+
 Follow the zero SDD orchestrator instructions: drive the run through the
 explore → plan → build → veredicto phases, honour the build/veredicto iteration
 cap, and use the execution mode (interactive or automatic) the user chose.

package/prompts/orchestrator.md

@@ -26,6 +26,74 @@ whim. Drive the run through four phases, in order:
 The orchestrator code controls phase order and the round count. The cap is not
 optional and the model does not get to extend it.
 
+## Resuming a run
+
+`/forge --continue` resumes an interrupted run instead of starting fresh. Resume
+is derived purely from the `.sdd/<feature-slug>/` artifacts — `requirements.md`,
+`design.md`, and `tasks.md` with its `[ ]`/`[x]` checklist. There is no separate
+state file; the artifacts are the run's durable state.
+
+**Selecting the run.**
+
+- `--continue <slug>` — skip the scan and target `.sdd/<slug>/` directly. Never
+  disambiguate. (`forge.md` already reports "no such run" and stops if the
+  directory is absent.)
+- `--continue` with no slug — scan `.sdd/*/` and classify every run by its
+  resume-point state (below). "Unfinished" = state `no-plan`, `building`, or
+  `built` (anything except `done`).
+  - Exactly one unfinished run → resume it silently.
+  - More than one → list each unfinished run with its slug and detected resume
+    point, and ask the user which to resume.
+  - Zero → state "nothing to resume" and stop. Do **not** start a fresh run.
+
+**Resume-point algorithm.** For the selected `<slug>`:
+
+1. If `.sdd/<slug>/requirements.md` is missing → state `no-plan`; resume at
+   **explore**, then plan (the run barely started; rebuild the plan artifacts).
+2. Else if `.sdd/<slug>/design.md` or `.sdd/<slug>/tasks.md` is missing → state
+   `no-plan`; resume at **plan** (requirements survived; finish the plan).
+3. Else (all three plan artifacts exist):
+   - If `tasks.md` has at least one `[ ]` task → state `building`; resume at
+     **build**, starting at the first `[ ]` task. Already-`[x]` tasks are done —
+     do not redo them.
+   - Else (every task `[x]`):
+     - Look for best-effort proof of a prior `pasa` verdict, in order: the
+       Cortex `zero-run/<slug>` trace (`memoria_search` for that `topic_key`)
+       reporting a `pasa` final verdict, then a line in `~/.pi/zero-runs.jsonl`
+       with `"feature":"<slug>"` and `"verdict":"pasa"`.
+     - Proof found → state `done`; report the run already completed
+       successfully and do nothing — no re-run, no clobber.
+     - No proof (Cortex unreachable, file absent, `--no-mcp`) → state `built`;
+       resume at **veredicto** and let it confirm the verdict. An all-`[x]`
+       `tasks.md` proves build finished but **never** proves a `pasa` verdict —
+       absence of proof always resolves toward re-verification.
+
+**Sanity-checking artifacts on resume.** A phase may have been killed
+mid-write, leaving a truncated `design.md` or `tasks.md`. When you brief the
+resumed phase's sub-agent, instruct it to sanity-check the artifacts it depends
+on (plan checks `requirements.md`/`design.md` look complete; build checks
+`tasks.md` parses as a checklist) and rebuild an obviously-incomplete one rather
+than trust it.
+
+**Pipeline guarantees on resume.** Resume enters the same loop at a later
+phase — every existing guarantee still holds: phase order proceeds forward from
+the resume phase with no downstream phase skipped; the build/veredicto iteration
+cap still bounds the resumed segment (the spent round count is not recoverable,
+so a resumed `building`/`built` run starts its counter at 1); the veredicto gate
+still stands — `pasa` is reported only on a `pasa` verdict, and the `done`
+short-circuit is the sole exception because it required positive proof of a
+prior `pasa`. Ask for the execution mode (interactive / automatic) at resume
+time exactly as a fresh run does — mode is per-invocation, not persisted — and
+announce the slug, the detected resume phase, and (for `building`) the first
+unchecked task number before entering the pipeline.
+
+**Fresh `/forge` against an existing slug.** At the start of a *fresh* run
+(no `--continue`), if `.sdd/<slug>/` already exists and is non-empty, do **not**
+silently clobber it and do **not** silently resume. Ask the user to choose:
+(a) resume it instead, (b) start over — discarding the existing artifacts, which
+the user must explicitly confirm — or (c) pick a different slug. An empty or
+non-existent `.sdd/<slug>/` proceeds as a fresh run with no prompt.
+
 ## Sub-agent delegation
 
 Each phase runs as its own sub-agent — `zero-explore`, `zero-plan`,
@@ -55,6 +123,11 @@ At the start of a run, ask the user which mode they want:
 
 Cache the mode for the run.
 
+When summarising the plan phase, report the run's total changed-lines forecast
+from the `## Review Workload` section of `tasks.md`, name each over-budget
+exception with its reason, and — when there are no exceptions — state that all
+tasks are within the per-task budget.
+
 ## Visibility
 
 While a phase runs, keep the user informed of progress — never run silently for

package/prompts/phases/build.md

@@ -4,6 +4,15 @@ description: SDD build phase — implement the planned tasks, test-first, and ma
 
 You run the **build** phase of a zero SDD pipeline.
 
+**Locating artifacts.** If you are invoked with a feature slug, operate on
+`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
+no slug and an ambiguous target, ask which run before acting. Read `tasks.md`
+and continue from the first `[ ]` task — already-`[x]` tasks are done, leave
+them untouched. Update each checkbox to `[x]` as its task completes so a later
+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.
+
 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.
 

package/prompts/phases/explore.md

@@ -4,6 +4,12 @@ description: SDD explore phase — investigate the codebase read-only and produc
 
 You run the **explore** phase of a zero SDD pipeline.
 
+**Locating artifacts.** If you are invoked with a feature slug, operate on
+`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
+no slug and an ambiguous target, ask which run before acting. Explore is
+read-only and may run with no `.sdd/<slug>/` directory yet — a brand-new feature
+is normal; do not treat the missing directory as an error.
+
 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.

package/prompts/phases/plan.md

@@ -4,6 +4,15 @@ description: SDD plan phase — turn findings into requirements, design, and an
 
 You run the **plan** phase of a zero SDD pipeline.
 
+**Locating artifacts.** If you are invoked with a feature slug, operate on
+`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
+no slug and an ambiguous target, ask which run before acting. You write
+`requirements.md`, `design.md`, and `tasks.md` into that directory. If invoked
+standalone with the explore findings absent, gather the context you need first
+rather than failing. On a resumed run, sanity-check any `requirements.md` or
+`design.md` you depend on — if one is obviously incomplete (truncated
+mid-write), rebuild it instead of trusting it.
+
 Using the explore findings, write the plan: the requirements (what must be
 true), the design (how it will be built), and an ordered list of small,
 independently verifiable tasks.
@@ -14,3 +23,23 @@ own.
 
 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.
+
+## Review Workload Forecast
+
+Size every task against a fixed budget of **400 changed lines per task** — an
+internal, non-configurable default (borrowed from gentle-ai), so "small task"
+means the same number on every run.
+
+- Attach a `review: ~N changed lines` bullet to every task entry. `N` is always
+  a whole number (added + modified + deleted), prefixed with `~`. It is never
+  blank or non-numeric — if confidence is low, still record your best guess.
+- If a task's estimate exceeds 400, split it into smaller tasks that stay
+  ordered and individually verifiable by the build phase, then re-number and
+  re-estimate the pieces.
+- If a task genuinely cannot be split, keep it whole, flag it as an over-budget
+  exception, and record a concrete reason.
+- Append a `## Review Workload` section to `tasks.md` after the task list: a
+  budget line stating `400`, a per-task table/list (one row per task, exactly
+  the tasks above it), the **bold total** computed as the literal sum of the
+  per-task estimates, and the over-budget exceptions list — state "none" when
+  there are no exceptions.

package/prompts/phases/veredicto.md

@@ -4,6 +4,15 @@ description: SDD veredicto phase — adversarially review the build and record a
 
 You run the **veredicto** phase of a zero SDD pipeline.
 
+**Locating artifacts.** If you are invoked with a feature slug, operate on
+`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
+no slug and an ambiguous target, ask which run before acting. Read the plan
+artifacts and the build result, then record your verdict. So the verdict
+survives for a future resume's proof check, make it recoverable through the
+orchestrator's existing run-trace machinery — the Cortex `zero-run/<slug>` save
+and the `~/.pi/zero-runs.jsonl` append. Do not write a separate verdict file;
+`.sdd/` artifacts stay plan state only.
+
 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.