@open-tomato/rafa 0.31.0 → 0.32.0

package/README.md

@@ -215,8 +215,9 @@ pr:
 
 The keys are: `release.fragments` (path, default `.changes/`), `release.strategy`
 (fold strategy, default `semver-by-level`), `release.settle` (`push` or `pr`,
-default `push`), `release.tag` (`manual` or `settle`, default `manual`).
-`pr.versionCollision` controls what happens when a merge would collide
+default `push`), `release.tag` (`manual` or `settle`, default `manual`),
+`release.publishCommand` (the publish line `rafa release tag` prints and never
+runs, default `npm publish`). `pr.versionCollision` controls what happens when a merge would collide
 (default `report`). Read `context/release.md` for the full design,
 `docs/ci-release-settle.md` for automating settle in CI, and
 `rafa release settle --help` for the settle command.
@@ -469,6 +470,37 @@ status:
   notice: false
 ```
 
+### `claims`
+
+Two settings control how claims work when two devices work on one project.
+Devices claim issues to prevent collisions: no two can plan or start the same
+issue, and stale or lost claims are recovered without losing work.
+
+| Key | Default | What it sets |
+|---|---|---|
+| `claims.staleAfter` | `3d` | how long a `rafa:claimed` claim stands before takeover is allowed: a duration such as `3d`, `1w`, or `disabled` |
+| `claims.ahead` | `off` | whether to reserve one issue ahead on the roadmap: `off` or `allow` |
+
+`claims.staleAfter` takes a duration or the word `disabled`; `0`, a fraction,
+and a quoted value are refused. When `disabled`, nothing is ever stale and
+claims must be released by hand. `claims.ahead` enables claim-ahead as an
+opt-in per run with `--claim-ahead` on `rafa next --roadmap` and `plan create
+--next`.
+
+```yaml
+# Default: claims are made, staleAfter is 3d, no claim ahead
+# (nothing set, or claims: {})
+
+# Set staleness only
+claims:
+  staleAfter: 3d
+
+# Disable staleness and enable claim ahead
+claims:
+  staleAfter: disabled
+  ahead: allow
+```
+
 ### `loop` and the guard
 
 A loop guards itself: every turn, it watches the checkout's branch and HEAD
@@ -577,6 +609,18 @@ from GitHub Issues:
   `waiting on #C (owner review)` until the team reviews and approves. The
   hop record (`.rafa/hop.json`) tracks where home is and what rafa works.
   When `rafa next` finishes, it deletes the record and returns home.
+- **Board relationships: a choice of modes.** A board tracks relationships
+  — which issues block which — in one of two ways. `labels` (the default)
+  uses `spec:blocked` labels and `Blocked by:` lines, carrying no cost
+  when a board is read. `native` uses GitHub's built-in parent and
+  blocked-by links, showing them in GitHub's UI and costing about 8 API
+  points per read of 5,000 per hour. Solo projects and those new to rafa
+  start with `labels`. Chose `native` when the relationships should show
+  in GitHub, or when nothing should clear a blocker by hand. Config it as
+  `board: relationships: native`, then run `rafa init --board` to move
+  from one mode to the other and remove the old marks. Read
+  [docs/specs-and-roadmap.md](docs/specs-and-roadmap.md) under "Board
+  relationships" for the full choice and upgrade path.
 - **Other trackers.** GitHub Issues is what works today. Linear support
   is being ported from the project rafa grew out of, as an optional
   add-on in a later version. For anything else, open or upvote a request