@rasensio/aidlc-content 1.62.0 → 1.64.0

package/docs/lifecycle.md

@@ -147,7 +147,9 @@ instance changed the same requirement first, its revision no longer matches the
 completion is not recorded, and nothing is written. That is the whole conflict rule — a requirement is
 never silently overwritten. `aidlc spec fold <instance> --dry-run` runs the same check any time before.
 An instance with no delta completes exactly as before; nothing was back-filled, so the corpus starts
-empty and grows.
+empty and grows. A `## Spec delta` section that holds only prose — "None." and the reason — counts as
+no delta. One with nothing in it, or whose only block headings sit inside a code fence or at the wrong
+level, is still an error, because that is a delta someone meant to write.
 
 **Before code is written**, `aidlc cross-check <instance>` reads `requirements.md`, `design.md` and
 `tasks.md` side by side. `aidlc review` reads one artifact at a time, so a criterion design forgot, or a

package/docs/roadmap.md

@@ -225,6 +225,7 @@ autopilot:
   pause_after: [requirements, design]  # or [] for no pauses
   stop_at: pr                          # or merge, or release
   release: repo-script                 # or merge-only — a preset name, never a command
+  notify: false                        # no desktop notifications; leave it out for them on
 ```
 
 **Upgrading changes nothing on its own.** A config with no `stop_at` and no `pause_after` behaves
@@ -247,6 +248,21 @@ fills only what is missing with the recommended choice.
 **Watching and stopping.** `aidlc autopilot status` shows the active run and each item's step, pull
 request, CI failure count and last error, and for an item waiting on you: the phase, its worktree and
 the `aidlc autopilot approve` command, or the pull request number to merge.
+`aidlc autopilot status --watch` follows the run live: every 2 seconds it redraws one line per item —
+its roadmap title, step, lifecycle phase, tasks done, how long it has been in its step, pull request
+and CI state, and the last thing autopilot said about it, with its age — until the run ends. It only
+reads, and Ctrl-C ends the view, never the run. Off a terminal (piped, or called by an agent) it
+prints the view once and returns.
+
+**Notifications.** A run sends a desktop notification (`osascript` on macOS, `notify-send` on Linux)
+when an item is parked, fails — "release failed" or "queue halted" where that applies — waits for
+your review or your merge, or is merged, released or closed, and when the run finishes. Each is sent
+once, when it happens: a queue halted for hours notifies once, and nothing in the run waits on a
+notification. `notify: false` in the team's `.aidlc/config.yaml` (above) or in this machine's
+`config.json` turns them off; the machine's value wins. The run log likewise keeps the events and
+drops the heartbeat: a line the previous pass already wrote, such as `nothing ready in the backlog`,
+is not written again until it stops and comes back.
+
 `aidlc autopilot stop` (or `/aidlc-autopilot-stop`) ends the
 run at its next step: nothing further is started, merged or released, and agents already running
 finish their item. `aidlc autopilot pause` freezes the run and its agents where they are —

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.62.0",
+  "version": "1.64.0",
   "type": "module",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/skills/84-autopilot.md

@@ -30,7 +30,7 @@ The CLI does the work. This skill starts it and says how to watch and stop it. D
    - *a run is already active* → report its pid and offer `aidlc autopilot stop` first.
    - *the run is paused* → offer `aidlc autopilot resume`.
 
-5. **Report**, in six short lines: what it is doing (how many items), the `stops:` line `run` printed verbatim, the log file, `aidlc autopilot status` to watch, `aidlc autopilot pause` before the machine sleeps (`aidlc autopilot resume` after), and `/aidlc-autopilot-stop` (or `aidlc autopilot stop`) to stop. When the stops line says none are set, say plainly that every item will be merged and released with no review, and name `aidlc autopilot setup` as what changes that.
+5. **Report**, in six short lines: what it is doing (how many items), the `stops:` line `run` printed verbatim, the log file, `aidlc autopilot status --watch` to watch (one line per item, live, until the run ends), `aidlc autopilot pause` before the machine sleeps (`aidlc autopilot resume` after), and `/aidlc-autopilot-stop` (or `aidlc autopilot stop`) to stop. When the stops line says none are set, say plainly that every item will be merged and released with no review, and name `aidlc autopilot setup` as what changes that.
 
 6. **Where it stops for a person.** Two stops, both set in `aidlc autopilot setup` or `aidlc init` and on by default:
    - **After a phase** — the agent stops when a phase in `pause_after` completes (requirements and design by default). The item waits as `awaiting-review`; it is *not* parked. The user reads the artifact in the item's worktree, then `aidlc autopilot approve <instance>` carries it on.
@@ -38,7 +38,7 @@ The CLI does the work. This skill starts it and says how to watch and stop it. D
 
    One run can change both without touching the saved setup: `aidlc autopilot run --items 3 --stop-at merge` or `--pause-after design` (`--pause-after none` for no pauses, `--stop-at release` for the old merge-and-release). The flags apply to the items that run starts; an item already in flight keeps the stops it started with. A config saved before stops existed keeps today's behaviour — no pauses, merge and release — until somebody sets them.
 
-   When the user asks what is waiting for them, run `aidlc autopilot status`: it names the phase, the worktree and the exact approve command for each waiting item.
+   When the user asks what is waiting for them, run `aidlc autopilot status`: it names the phase, the worktree and the exact approve command for each waiting item. When they ask how the items are getting on, run `aidlc autopilot status --watch`: called from here it prints each item's phase, tasks done, time in its step and last event once, and returns.
 
 7. **Pause and resume.** When the user is stepping away or closing the laptop, run `aidlc autopilot pause`; when they are back, `aidlc autopilot resume`. Report what each printed. If pause says a pass is in progress — a merge or a release — run it again a minute later rather than stopping the run.
 
@@ -49,6 +49,7 @@ The CLI does the work. This skill starts it and says how to watch and stop it. D
 - An agent that loses the network exits, and is parked. Sleep cuts the network, so a run on a laptop needs `aidlc autopilot pause` first: it freezes the run and its agents where they are, and `aidlc autopilot resume` carries on.
 - Before each merge, brings the item's branch up to date with main and waits for CI on the new head. A conflict with main goes back to the item's agent, twice at most, then the item is parked. A pull request someone merged by hand is dropped from tracking.
 - Halts the merge queue when a step fails. Running `aidlc autopilot run` again retries a failure that came before the merge; a failed release is for a person — `aidlc autopilot status` shows the error. `aidlc autopilot forget <instance>` stops tracking an item finished by hand.
+- Sends a desktop notification, once each, when an item is parked, fails, waits for the user, or is done, and when the run ends. `notify: false` under `autopilot:` in `.aidlc/config.yaml` turns them off.
 - Ends when the asked-for items are each released or parked, or, with `--all`, when nothing is ready and nothing is in flight. An item waiting for a person keeps its run alive, so the run is still there to carry the item on after an approval or a merge.
 
 ## Exit Criteria