@groeponline/pi-missions 0.3.15 → 0.4.0

package/CHANGELOG.md

@@ -7,6 +7,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.4.0] - 2026-09-12
+
+### Fixed
+- peer-range check honors pinned * range; integration non-goals (#26)
+## [0.3.16] - 2026-09-11
+
+### Documentation
+- add durable mission lifecycle visual (#24)
 ## [0.3.15] - 2026-09-11
 
 ### Documentation

package/README.md

@@ -45,6 +45,12 @@ Agent sessions are temporary. Real implementation work is not. Pi Missions store
 
 Use it when a job is too large for one prompt, one context window or one uninterrupted coding session.
 
+<p align="center">
+  <img src="https://raw.githubusercontent.com/GroepOnline/pi-missions/main/docs/images/mission-lifecycle.svg" alt="Pi Missions durable lifecycle: create or load, advance features, persist state and resume later" width="100%">
+</p>
+
+The important bit is not the queue UI. It is that the active pointer, transition history and completion evidence survive the session that created them.
+
 ## Where it fits
 
 Pi Missions owns **durable work state**. Wishcraft captures lightweight ideas; Missions turns serious work into a resumable track; Agent Orchestrator executes parallel or isolated work when that becomes useful.
@@ -55,24 +61,11 @@ Pi Missions owns **durable work state**. Wishcraft captures lightweight ideas; M
 - **pi-missions**: durable plan, queue, evidence and recovery state.
 - [`pi-agent-orchestrator`](https://github.com/GroepOnline/pi-agent-orchestrator): agents, worktrees, swarms, schedules and execution handoffs.
 
-GitHub, Slack and webhook integration classes remain lightweight scaffolding; production-readiness is tracked in [#13](https://github.com/GroepOnline/pi-missions/issues/13).
-
-## Execution loop
-
-```mermaid
-flowchart LR
-    A[Create or load mission] --> B[Pending feature]
-    B -->|/mission next| C[Active feature]
-    C -->|evidence accepted| D[Done]
-    C -->|cannot proceed| E[Blocked]
-    D -->|more ready work| B
-    D -->|all features complete| F[Mission complete]
-    E -->|another feature is ready| B
-    C --> G[history.jsonl]
-    D --> H[evidence/Fxxx.md]
-```
+Explicit non-goal: pi-missions ships no GitHub, Slack or webhook integrations — there are no such integration classes in this package, no network calls to those providers, and no webhook listeners. Mission state stays local (SQLite/JSONL under `MISSIONS_ROOT`). If provider integrations are ever proposed, production-readiness gates are tracked in [#13](https://github.com/GroepOnline/pi-missions/issues/13).
+
+## Runtime contract
 
-The agent is expected to work only on the active feature. Completion is explicit: `/mission done` or `mission_feature_done` records evidence before the queue advances.
+The agent works only on the active feature. Completion is explicit: `/mission done` or `mission_feature_done` records evidence before the queue advances. A blocked feature records its reason instead of being silently skipped.
 
 ## What persists
 
@@ -169,7 +162,7 @@ src/
 └── cli/         # pi-missions CLI
 ```
 
-GitHub, Slack and webhook integration classes are still lightweight scaffolding. They are not advertised as production integrations.
+Explicit non-goal: GitHub, Slack and webhook integrations are out of scope for this package (no integration classes, no provider network calls, no webhook listeners). They are not advertised as features; any future proposal must meet the gates tracked in [#13](https://github.com/GroepOnline/pi-missions/issues/13).
 
 ## Requirements
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@groeponline/pi-missions",
-  "version": "0.3.15",
+  "version": "0.4.0",
   "description": "Persistent mission orchestration for Pi: durable plans, task queues, evidence trails, SQLite state, resumable execution, and handoffs across agent sessions.",
   "type": "module",
   "private": false,