@pmelab/gtd 60.1.0 → 62.0.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gtd",
-  "version": "60.1.0",
+  "version": "62.0.0",
   "description": "Drive the gtd loop inside Claude Code: agent turns run as subagents, gtd decides every beat",
   "author": {
     "name": "Philipp Melab"

package/README.md

@@ -636,6 +636,22 @@ included, as one gzipped ES module after a plain-text
 `gtdpin <format> gtd <version>` line. A workflow using a package with a native
 addon cannot be pinned.
 
+Every process commits its pin: its first beat after it starts is a pin beat
+writing `gtd bundle`'s output to `.gtd/process.gtdpin`, and its last, once the
+flow has ended, an unpin beat removing it — the commit that closes the process.
+Both are ordinary `script` beats a driver runs unattended; see
+[Pin and unpin beats](https://github.com/pmelab/gtd/blob/main/docs/driver.md#pin-and-unpin-beats).
+Histories with pin commits are history format 2, which an older gtd refuses.
+
+While a process is pinned, the `gtd` on your `PATH` hands every command over to
+the pin, so editing the workflow or upgrading gtd mid-process changes nothing;
+gtd notes on stderr when the live config differs from the pinned one. `ui`,
+`lsp`, `guide`, `bundle`, `help`, `version` and the `history` commands always
+run live, and `gtd --live <command>` runs the live engine for any other, at the
+risk of misreading the process. A pin in a format your gtd does not know is
+refused: upgrade gtd. See
+[Pinned processes](https://github.com/pmelab/gtd/blob/main/docs/cli.md#pinned-processes).
+
 ## License
 
 MIT