pi-loopflows 0.1.1 → 0.1.3

package/CHANGELOG.md

@@ -1,5 +1,16 @@
 # Changelog
 
+## 0.1.3 - 2026-06-22
+
+- Add clear semantic versioning policy and release checklist.
+- Include `VERSIONING.md` in the published package.
+- Add concise versioning guidance to README.
+
+## 0.1.2 - 2026-06-22
+
+- Tighten README positioning around loopflows as LEGO-like subagent workflows.
+- Remove the dedicated Launch Control README section while keeping it listed as a bundled workflow.
+
 ## 0.1.1 - 2026-06-22
 
 - Polish product README and usage guidance for public release.

package/README.md

@@ -2,9 +2,7 @@
 
 Build deterministic AI workflows out of Pi subagents.
 
-A **loopflow** is a reusable process for agent work: steps, gates, feedback loops, stop rules, and evidence artifacts. Instead of asking one agent to “do the whole thing”, you describe how specialist agents should cooperate: one agent gathers context, another plans, another builds, another reviews, and a gate decides whether the work moves forward, loops back for fixes, or stops.
-
-`pi-loopflows` ships with a production-ready **Launch Control** loopflow out of the box, and it is also a flexible constructor for your own workflows.
+Think of **loopflows** as LEGO for subagents. You take small specialist agents, connect them into a process, add gates where decisions matter, and let the workflow move forward, branch, loop back, or stop based on explicit results. Instead of one giant prompt, you get a reusable structure for how agents collaborate: steps, feedback loops, stop rules, and saved evidence.
 
 ## Why loopflows
 
@@ -65,32 +63,6 @@ loopflow_run({
 - `build-review` — small generic build → review → fix loop for scoped implementation tasks.
 - `plan-review` — planning loop that lets a reviewer reject vague or unsafe plans before implementation.
 
-## Built-in: Launch Control
-
-Launch Control is bundled because it is the clearest example of why loopflows exist. It turns a plan into a controlled implementation process:
-
-```text
-context-builder
-  → planner
-  → loop max 3:
-      worker
-      reviewer gate
-        approved -> continue
-        changes_requested -> repeat
-        blocked -> stop
-  → final audit
-```
-
-Use it when drift, skipped validation, PR correctness, or multi-step delivery risk matter.
-
-Example:
-
-```text
-/loopflow launch-control -- Implement the auth migration plan in docs/auth-plan.md
-```
-
-Launch Control is not hard-coded. It is just a `.loopflow.json` file. You can copy it, change the agents, change the prompts, adjust max iterations, add stricter gates, or create a project-specific version in `.pi/loopflows/`.
-
 ## Loopflows as a constructor
 
 Think of loopflows as LEGO for agent processes. A loopflow can use any available Pi subagent role:
@@ -306,6 +278,16 @@ worker → reviewer → worker → reviewer
 
 If you need a feedback loop, a quality gate, a max iteration limit, or saved evidence, use a loopflow.
 
+## Versioning
+
+`pi-loopflows` uses semantic versioning: `MAJOR.MINOR.PATCH`.
+
+- PATCH for docs, bug fixes, prompt polish, validation improvements, and internal refactors with no user-facing behavior change.
+- MINOR for new backward-compatible features, bundled loopflows, commands, options, fields, or adapter backends.
+- MAJOR for breaking changes to loopflow JSON shape, template variables, gate semantics, commands, artifact paths, or adapter behavior.
+
+See [`VERSIONING.md`](VERSIONING.md) for the release checklist.
+
 ## Status
 
 `pi-loopflows` is early, but designed as a real product surface rather than a one-off script. The core model is intentionally small:

package/VERSIONING.md

@@ -0,0 +1,70 @@
+# Versioning
+
+`pi-loopflows` uses semantic versioning: `MAJOR.MINOR.PATCH`.
+
+## PATCH: `0.1.x`
+
+Use a patch release for safe, backward-compatible changes:
+
+- README, docs, examples, wording, metadata;
+- bug fixes that do not change workflow file shape;
+- bundled loopflow prompt improvements that keep the same behavior contract;
+- validation/typecheck/test improvements;
+- internal refactors with no user-facing API changes.
+
+Example: `0.1.2 -> 0.1.3`.
+
+## MINOR: `0.x.0`
+
+Use a minor release for new backward-compatible capability:
+
+- new bundled loopflows;
+- new loopflow fields that old files do not need;
+- new commands/tools/options;
+- new adapter backend support;
+- expanded artifact output that does not break existing consumers;
+- new gate/status helpers that existing loopflows can ignore.
+
+Example: `0.1.3 -> 0.2.0`.
+
+## MAJOR: `x.0.0`
+
+Use a major release for breaking changes:
+
+- changing or removing existing loopflow JSON fields;
+- changing template variable semantics;
+- changing gate status behavior in a way existing loopflows may interpret differently;
+- removing commands, tools, bundled loopflows, or adapter behavior;
+- changing artifact paths or output shape in a way scripts may depend on.
+
+Example: `1.4.2 -> 2.0.0`.
+
+## Release checklist
+
+1. Update `package.json` with `npm version <patch|minor|major> --no-git-tag-version`.
+2. Update `CHANGELOG.md` under the new version.
+3. Run:
+
+   ```bash
+   npm run validate
+   npm run typecheck
+   npm run pack:check
+   ```
+
+4. Commit with a clear release-prep message.
+5. Tag the version: `git tag vX.Y.Z`.
+6. Push `main` and the tag.
+7. Publish to npm:
+
+   ```bash
+   npm publish --access public
+   ```
+
+8. Create a GitHub release for the tag.
+9. Install the published package and validate it:
+
+   ```bash
+   pi remove npm:pi-loopflows || true
+   pi install npm:pi-loopflows@X.Y.Z
+   node ~/.pi/agent/npm/node_modules/pi-loopflows/scripts/validate.mjs
+   ```

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-loopflows",
-  "version": "0.1.1",
+  "version": "0.1.3",
   "description": "Deterministic loop workflows for Pi subagents: steps, gates, feedback loops, and artifacts.",
   "license": "MIT",
   "author": "Nikita Nosov <20nik.nosov21@gmail.com>",
@@ -28,6 +28,7 @@
     "skills",
     "scripts",
     "README.md",
+    "VERSIONING.md",
     "LICENSE",
     "CHANGELOG.md"
   ],