@gonrocca/zero-pi 0.1.1 → 0.1.2

package/README.md

@@ -33,13 +33,24 @@ A spec-driven development pipeline driven through four phases, in order:
 4. **veredicto** — review the build adversarially and record a verdict
    (`pasa`, `corregir`, or `replantear`).
 
-Run it with the `/forge` prompt. The orchestrator drives phase order and
-enforces a hard build/veredicto iteration cap. Each phase has its own prompt
+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.
 
+`/forge models` (no feature request) opens an in-session editor for the
+per-phase models — it reads `~/.pi/zero.json`, lets you reassign any phase, and
+writes the choice back.
+
 Per-phase model assignments are read from `~/.pi/zero.json`, which the `zero`
 CLI writes when it installs this layer.
 
+**Run memory** — every SDD run reads from and writes to Cortex (the memory MCP
+server). Before exploring, the orchestrator recalls prior `zero-run/*` traces
+for the feature; when the run ends it saves a run-trace — the final verdict, the
+correction rounds, and the gotchas — under `topic_key: zero-run/<slug>`. The
+next run on related work starts from what the last one learned. With `--no-mcp`
+the loop degrades silently.
+
 ### Skill auto-learning (`skills/`)
 
 `skill-loop.md` gives the agent a closed learning loop so solutions are reused

package/package.json

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

@@ -1,8 +1,31 @@
 ---
-description: Run an automatic spec-driven development pipeline for a feature request
+description: Run the SDD pipeline for a feature — or `/forge models` to set the per-phase models
 ---
 
-Run the zero SDD pipeline for the feature request in the arguments.
+The argument decides the mode.
+
+## `/forge models` — configure the SDD models
+
+When the argument is exactly `models`, do **not** run the pipeline. Configure
+the per-phase models instead:
+
+1. Read `~/.pi/zero.json`. Show the user the current `models` mapping — the
+   model assigned to each phase: `explore`, `plan`, `build`, `veredicto`.
+2. Ask which phases they want to change and to what. Offer the models the
+   active provider exposes — run `pi --list-models` if you need the list.
+   Guidance: a cheap, fast model suits `explore`; a strong model suits `plan`
+   and the adversarial `veredicto`; `build` sits in between.
+3. Write the chosen models back into `~/.pi/zero.json`, replacing only the
+   `models` block and preserving every other key (`version`, `installedAt`).
+   Validate each model name against `pi --list-models` before writing.
+4. Confirm the new mapping back to the user.
+
+This changes the models for every later `/forge` run — the orchestrator reads
+`~/.pi/zero.json` at the start of each run.
+
+## `/forge <feature request>` — run the SDD pipeline
+
+For any other argument, run the zero SDD pipeline for that feature request.
 
 Follow the zero SDD orchestrator instructions: drive the run through the
 explore → plan → build → veredicto phases, honour the build/veredicto iteration
@@ -17,4 +40,4 @@ In interactive mode, pause after each phase with a summary and ask before
 continuing. Never report success unless the veredicto phase returned a `pasa`
 verdict; if the cap is reached first, report that the result is not verified.
 
-Feature request: $ARGUMENTS
+Argument: $ARGUMENTS

package/prompts/orchestrator.md

@@ -60,3 +60,32 @@ Cache the mode for the run.
 While a phase runs, keep the user informed of progress — never run silently for
 a long stretch. The user must always be able to tell which phase and round the
 run is in.
+
+## Run memory
+
+zero runs improve each other. The pipeline reads from and writes to Cortex —
+the persistent memory MCP server zero installs — so every run learns from the
+runs before it. You, the orchestrator, own both ends of the loop.
+
+**Recall — before the explore phase.** Search Cortex for the feature: prior
+`zero-run/*` traces and related discoveries, bug fixes, and patterns. Pass what
+you find into the explore sub-agent's brief — past runs flag what already broke
+in this code and which plans were sent back.
+
+**Persist — after the final verdict.** When the run ends — a `pasa` verdict, or
+the iteration cap reached — save one run-trace memory with `memoria_save`:
+
+- `type`: `session_summary`
+- `topic_key`: `zero-run/<feature-slug>` — stable, so re-running a feature
+  updates its trace rather than duplicating it
+- `title`: `zero run — <feature>`
+- `what`: what was built, the final verdict, and the build/veredicto round count
+- `why`: the feature request
+- `where_at`: the files the run touched
+- `learned`: the gotchas — what each `corregir` round fixed and, on any
+  `replantear`, why the plan was wrong. Future runs read this first.
+
+Use the project name Cortex derives from the working directory.
+
+If Cortex is unavailable — installed with `--no-mcp`, or the server is down —
+skip recall and persist silently. The memory loop must never block a run.

package/prompts/phases/explore.md

@@ -10,3 +10,7 @@ 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.
+
+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

@@ -11,3 +11,6 @@ independently verifiable tasks.
 Do not write implementation code in this phase — only the plan. Keep each task
 scoped tightly enough that the build phase can implement and check it on its
 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.

package/prompts/phases/veredicto.md

@@ -15,3 +15,7 @@ Record exactly one verdict:
 - `replantear` — the plan itself is wrong; the plan phase must re-run.
 
 Never return `pasa` unless the evidence supports it.
+
+State the verdict's reasoning concretely — the specific defects for `corregir`,
+the specific plan flaw for `replantear`. The orchestrator persists that
+reasoning to the run's memory trace, so future runs depend on it being precise.