pi-baton 0.7.4 → 0.7.5

package/CHANGELOG.md

@@ -6,6 +6,16 @@ This project follows semantic versioning.
 
 ## [Unreleased]
 
+## [0.7.5] - 2026-08-22
+
+### Changed
+
+- Merge the 2026-08-22 managed OSS dependency and maintenance PR batch.
+
+### Added
+
+- Added the builtin `Two-Stage Review Gauntlet` workflow to demonstrate a non-default two-stage review graph.
+
 ### Changed
 
 - Bump package version to `0.7.3` for the next patch release.
@@ -151,4 +161,3 @@ This project follows semantic versioning.
 - Initial Pi package template.
 - Example extension, Agent Skill, prompt, and theme.
 - CI and npm Trusted Publishing workflow.
-

package/README.md

@@ -39,7 +39,7 @@ pi install npm:pi-baton
 Pin a specific version when you want reproducible installs:
 
 ```bash
-pi install npm:pi-baton@0.7.4
+pi install npm:pi-baton@0.7.5
 ```
 
 Install into the current project instead of your user Pi settings:
@@ -77,7 +77,10 @@ Then run:
 /baton:status     show the active run summary
 ```
 
-The builtin `Default Review Loop` workflow (implement → review → fix) works out of the box — no agent setup required.
+Builtin workflows work out of the box — no agent setup required:
+
+- `Default Review Loop` (`implement → review → fix`)
+- `Two-Stage Review Gauntlet` (`draft → technical_review → editorial_review`, with rejects routed through `fix`)
 
 ## Prerequisites
 
@@ -100,6 +103,8 @@ Discovery order: project `.pi/agents/` → user `~/.pi/agent/agents/` → pi-bat
 
 Pick a name and a scaffold from `default-review-loop` is written to `.pi/baton/workflows/` and opened in editor. The scaffold includes `<your-fast-model>` / `<your-strong-model>` placeholders for step-level model overrides.
 
+The shipped `workflows/` directory also includes `two-stage-review-gauntlet.yaml`, a second builtin graph that demonstrates chaining two review gates before completion.
+
 ### Workflow YAML reference
 
 ```yaml
@@ -135,7 +140,7 @@ steps:
 | `extensions/` | Slash-command entrypoints (`/baton:new`, `/baton:start`, `/baton:run`, `/baton:status`) |
 | `lib/` | Workflow parser, run engine, subagent runner, review contract, UI widget |
 | `agents/` | Builtin `worker` and `reviewer` subagent definitions |
-| `workflows/` | Builtin `default-review-loop.yaml` |
+| `workflows/` | Builtin workflows (`default-review-loop.yaml`, `two-stage-review-gauntlet.yaml`) |
 | `assets/` | README / package branding assets |
 | `docs/` | Release and maintainer documentation |
 
@@ -171,4 +176,4 @@ For vulnerability reporting, see [`SECURITY.md`](SECURITY.md).
 
 ## License
 
-MIT
+MIT

package/docs/release.md

@@ -19,9 +19,9 @@ npm version patch
 git push
 ```
 
-On `main`, `.github/workflows/auto-release.yml` checks `package.json` version. If `v<version>` does not exist yet, it creates the tag, creates the GitHub Release, then explicitly dispatches `.github/workflows/publish.yml` for that tag.
+On `main`, `.github/workflows/auto-release.yml` checks `package.json` version. If `v<version>` does not exist yet, it creates the tag, creates the GitHub Release, then explicitly dispatches `.github/workflows/publish.yml` for that tag. Version bumps on `main` do not trigger `publish.yml` directly; auto-release is the single handoff path for those commits.
 
-The `v*.*.*` tag also triggers `.github/workflows/publish.yml`, which runs CI and publishes to npm when tags are pushed manually.
+The `v*.*.*` tag push also triggers `.github/workflows/publish.yml`, which runs CI and publishes to npm when tags are pushed manually.
 Publishing also runs when a GitHub Release is published, and can be run manually from GitHub Actions with `workflow_dispatch`.
 
 The workflow skips `name@version` if that exact package version already exists on npm.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-baton",
-  "version": "0.7.4",
+  "version": "0.7.5",
   "description": "Pi-native workflow baton runner with per-step model switching and isolated step context.",
   "type": "module",
   "engines": {
@@ -58,10 +58,10 @@
     "typebox": "*"
   },
   "devDependencies": {
-    "@earendil-works/pi-ai": "^0.82.1",
-    "@earendil-works/pi-coding-agent": "^0.82.1",
+    "@earendil-works/pi-ai": "^0.84.1",
+    "@earendil-works/pi-coding-agent": "^0.84.1",
     "typebox": "latest",
     "@types/node": "^26.0.1",
-    "typescript": "^6.0.3"
+    "typescript": "^7.0.2"
   }
 }

package/workflows/two-stage-review-gauntlet.yaml

@@ -0,0 +1,75 @@
+name: Two-Stage Review Gauntlet
+iteration_cap: 4
+steps:
+  draft:
+    agent: worker
+    prompt: |
+      You are the draft step in a Pi Baton two-stage review gauntlet.
+
+      Produce a complete first-pass solution for the task brief. Keep the work focused
+      and prepare it for technical and editorial review gates.
+
+      End your response with a fenced JSON block:
+      ```json
+      {"summary":"One paragraph summary of the draft you produced"}
+      ```
+    next: technical_review
+  technical_review:
+    agent: reviewer
+    prompt: |
+      You are the technical review gate in a Pi Baton two-stage review gauntlet.
+
+      Review the draft for correctness, completeness, tests, regressions, and implementation risk.
+      Accept only when the work is technically ready to proceed to editorial review.
+
+      End your response with a fenced JSON block:
+      ```json
+      {"summary":"Short technical review summary","judgment":"accept","acceptanceNote":"Why this is technically ready"}
+      ```
+      or
+      ```json
+      {"summary":"Short technical review summary","judgment":"reject","findings":["Actionable technical issue 1"]}
+      ```
+
+      Rules:
+      - judgment must be "accept" or "reject"
+      - reject requires non-empty findings
+      - accept requires a non-empty acceptanceNote
+    on_accept: editorial_review
+    on_reject: fix
+  editorial_review:
+    agent: reviewer
+    prompt: |
+      You are the editorial review gate in a Pi Baton two-stage review gauntlet.
+
+      Review the technically accepted work for clarity, maintainability, user-facing wording,
+      and handoff quality. Accept only when the final result is ready to deliver.
+
+      End your response with a fenced JSON block:
+      ```json
+      {"summary":"Short editorial review summary","judgment":"accept","acceptanceNote":"Why this is ready to deliver"}
+      ```
+      or
+      ```json
+      {"summary":"Short editorial review summary","judgment":"reject","findings":["Actionable editorial issue 1"]}
+      ```
+
+      Rules:
+      - judgment must be "accept" or "reject"
+      - reject requires non-empty findings
+      - accept requires a non-empty acceptanceNote
+    on_accept: _complete
+    on_reject: fix
+  fix:
+    agent: worker
+    prompt: |
+      You are the fix step in a Pi Baton two-stage review gauntlet.
+
+      Address the latest review findings while preserving good work from earlier steps.
+      After fixing, the work returns through the technical gate before editorial review.
+
+      End your response with a fenced JSON block:
+      ```json
+      {"summary":"One paragraph summary of fixes applied"}
+      ```
+    next: technical_review