@rasensio/aidlc-content 1.57.0 → 1.59.0

package/docs/index.yaml

@@ -42,7 +42,7 @@ entries:
     title: The lifecycle
     file: lifecycle.md
     source: packages/cli/src/core
-    commands: [init, start, continue, status, transition, gate, menu, amend, templates, spec, cross-check]
+    commands: [init, start, continue, status, transition, gate, menu, amend, templates, spec, cross-check, revert]
 
   - id: state-and-concurrency
     kind: topic

package/docs/lifecycle.md

@@ -181,6 +181,23 @@ carry `(wave: <n>)` in `tasks.md`; a wave must be a run of consecutive tasks, an
 the task and warns rather than dropping it from gate coverage. The whole loop is one rule file,
 `.aidlc/resources/rules/task-agents.md`, so a session that runs its tasks itself never reads it.
 
+**Undoing a task.** Each commit made for a task ends with a `Task: <instance>/T<n>` git trailer. `aidlc revert <instance> --task T3` reads those trailers on the commits since the branch left `main`, prints
+the commits it would undo — newest first, marking any that also belong to another task as shared — and
+asks first:
+
+```
+Plan: undo T3 of add-export — 2 commits on feat/add-export since main, newest first:
+  4f1c2ab  feat: csv writer handles quotes  [T3, T4]  — shared: also T4
+  9e0d311  feat: csv writer  [T3]
+Tasks reset to open in tasks.md (if done): T3, T4
+```
+
+On a yes it adds one commit that undoes them, leaves `.aidlc/state/` as it was except those checkboxes,
+and abandons cleanly if the undo conflicts with later work. A clash inside `.aidlc/state/` alone — the
+next task's checkbox on the line below — is not such a conflict. `--phase implementation` undoes every task
+commit at once; `--dry-run` only prints the plan; without a terminal it needs `--yes`. It works only
+during implementation and never on `main`.
+
 ## Where the code lives
 
 - `packages/cli/src/core` — templates, scope resolution, and the gate engine.
@@ -197,6 +214,11 @@ the task and warns rather than dropping it from gate coverage. The whole loop is
   leave the corpus untouched.
 - `packages/cli/src/crosscheck` — `aidlc cross-check`, a pure comparison of one instance's three
   planning artifacts. Nothing but its own command imports it, and a test keeps it that way.
+- `packages/cli/src/revert` — `aidlc revert`: reads `Task:` trailers over `main..HEAD`, builds the plan
+  (pure), and applies it as one commit, returning to the recorded `HEAD` on any failure. It reads
+  `git log -z` with NUL between fields because NUL is the one byte a commit message cannot carry; git
+  keeps every other control character, and a body carrying the first separators chosen forged a
+  commit from `main` into the plan.
 - `packages/cli/src/menu` — the interactive picker. It reads no lifecycle state by design, because
   "what should I do next?" belongs to the skill, not the menu.
 - `packages/content/templates` — the five templates, as data.

package/docs/roadmap.md

@@ -108,7 +108,15 @@ also lists every unranked backlog item, so one sitting last is visible rather th
 **Parking from an instance** is `aidlc roadmap park <instance> --reason "<why>"`: it moves the item
 promoted to that instance into `hold/` with a `parked — ` reason. It exists for unattended mode's hard
 stops — see [Skills and platforms](skills-and-platforms.md) — where the agent works in a worktree but
-the item's status lives in the primary checkout.
+the item's status lives in the primary checkout. `aidlc roadmap park --item <item> --reason "<why>"`
+parks an open item by file name or id instead, whatever its `promoted_to` — for an item no instance
+was ever linked to, such as one whose `aidlc start` failed.
+
+**An item keeps its `promoted_to` when it is parked.** Moving it back from `hold/` to `backlog/` by
+hand leaves the link set, and `aidlc start --roadmap-item` refuses an item that is already promoted.
+`aidlc roadmap next` applies the same rule: it leaves such an item out of the order, warns about it,
+and lists it under `skipped` in `--explain` and `--json`, naming the instance. Clear the
+`promoted_to` line to make it ready again.
 
 Keep the raw idea count around a dozen. At the cap, promote or drop before capturing anything new. A
 completed instance queues **at most two** follow-up items and records the rest in its own
@@ -136,7 +144,10 @@ Each item goes through these steps:
 1. **Pick.** `aidlc roadmap next` names the next ready backlog item.
 2. **Build.** `aidlc start … --worktree --roadmap-item <item>` creates the instance in its own
    worktree, then the configured agent runs there with `AIDLC_UNATTENDED=1`. The agent follows the
-   unattended rule and stops at the release boundary, or parks the item on a hard stop.
+   unattended rule and stops at the release boundary, or parks the item on a hard stop. A start that
+   fails parks the item with `parked — could not start: <error>` and autopilot goes straight on to
+   the next ready item; the parked one does not count toward `--items`. Retrying the same item every
+   pass is what held a whole `--all` run on one item for five hours.
 3. **PR and CI.** Autopilot pushes the branch and opens the pull request. Green checks queue it;
    a failure relaunches the agent once with the failing checks, and a second failure parks the item.
 4. **Up to date with main.** Before merging, autopilot merges `origin/main` into the branch in the
@@ -151,8 +162,8 @@ Each item goes through these steps:
    nothing is retried — a half-finished release is for a person.
 
 At most two items build at once, and never more than you asked for. Autopilot never moves anything
-between `inbox/`, `backlog/` and `hold/` except to park what it is building, and never edits a rank or
-a dependency: deciding what is agreed work stays a person's job.
+between `inbox/`, `backlog/` and `hold/` except to park what it is building or could not start, and
+never edits a rank or a dependency: deciding what is agreed work stays a person's job.
 
 **Setup** comes first, once per machine. A plain `aidlc init` ends by asking "Set up autopilot now?"
 (default no); `aidlc init --autopilot` skips that question, and `aidlc autopilot setup` asks the same

package/package.json

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

package/skills/40-implementation.md

@@ -53,7 +53,7 @@ Then the source files that task touches. See **The context rule** (`.aidlc/resou
    - Infrastructure changes (provisioning, configuration)
    - Permission or access control modifications
    - Credential or secret handling
-7. **Commit incrementally.** Produce working code at each step; avoid large uncommittable diffs.
+7. **Commit incrementally, one task per commit where you can.** Produce working code at each step; avoid large uncommittable diffs. End every commit made for a task with a git trailer naming it — `Task: <instance>/T<n>` on its own line in the last paragraph of the message, one line per task when a commit spans two. The trailer is what lets `aidlc revert <instance> --task T<n>` find that task's commits later and undo them in one step, after showing the plan; a commit without it is invisible to the command.
 8. **Update the knowledge graph.** After modifying code, record what changed with `aidlc knowledge add` / `relate` / `update`: new or restructured modules, decisions taken, debt introduced or paid down. Keep the graph in sync with the code you just changed.
 9. **Update state.** As implementation artifacts are produced, mark them in `phase-implementation.yaml`.