@rasensio/aidlc-content 1.49.0 → 1.50.0

package/package.json

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

package/skills/04-roadmap.md

@@ -197,7 +197,7 @@ When the user asks for a worktree ("create a new worktree for roadmap `<file>`")
    ```
    For Codex, swap `claude` for `codex`. If the user names a session manager, give them the worktree path to point it at.
 
-When the instance completes, the `roadmap-done` lifecycle action moves the item to `done/` on its own — do not do it by hand, and do not remove that action to do it manually.
+When the instance completes, the `roadmap-done` lifecycle action moves every item whose `promoted_to` names it to `done/` on its own, and says how many it moved — do not do it by hand, and do not remove that action to do it manually.
 
 ## Drop
 

package/skills/40-implementation.md

@@ -42,16 +42,17 @@ Then the source files that task touches. See **The context rule** (`.aidlc/resou
 
 1. **Load context.** Read `.aidlc/context/style-guide.md` and `.aidlc/context/architecture.md` if they exist. Match the project's established patterns. If the project has a knowledge graph (`.aidlc/knowledge/` exists), also run `aidlc knowledge context --scope phase --phase implementation` and query it (`aidlc knowledge query <term>`) before re-exploring code it already describes — as an index into the source, never a substitute for reading it. Open the file before calling anything the graph names; an entry can outlive the symbol it describes.
 2. **Load guidance.** Read the always-read guidance layers from `.aidlc/guidance/index.yaml` — see **The always-read rule** (`.aidlc/resources/rules/always-read.md`) for which layers those are and when to reach for the full `lessons.md`. Apply their rules during implementation.
-3. **Execute the task breakdown.** When the instance has a `tasks.md` (produced in Design for full/quick-feature scope), read it and execute tasks in order: complete a task, then mark its checkbox `[x]` as part of the same work unit — never batch checkbox updates for later. A task that should not be done is deferred in place (`- [>] T<n>: <title> (deferred YYYY-MM-DD: <reason>)`) with a dated reason, never skipped silently or deleted; the implementation→testing gate blocks on open tasks. For bugfix scope, create the optional `tasks.md` at implementation start when the fix spans more than one commit-sized unit. For Micro scope, reference the task description and acceptance criteria directly — no task file.
-4. **Write code.** Follow the design interfaces. Match existing code style (naming, formatting, error handling patterns).
-5. **Handle sensitive operations.** Before executing any of the following, describe the action and wait for explicit user confirmation (unattended, `AIDLC_UNATTENDED=1`: each is a hard stop except reverting this session's own changes, per `.aidlc/resources/rules/unattended.md`):
+3. **Check that the planning artifacts agree.** Before the first task, run `aidlc cross-check <instance>` and show the user the list. It reads `requirements.md`, `design.md` and `tasks.md` side by side and prints one line per gap — a criterion no task cites, a task citing no criterion, a criterion design never mentions — each naming both artifacts and the ID. It is a report: it writes nothing and never blocks, and acting on a gap is the user's call. A gap in `tasks.md` is fixed in place, since its phase is still open here; a gap in a completed `requirements.md` or `design.md` is fixed through an amendment (**Amending a Completed Phase**, in the requirements skill), never by editing it silently. Unattended (`AIDLC_UNATTENDED=1`): record the list in `code-complete.md` and carry on.
+4. **Execute the task breakdown.** When the instance has a `tasks.md` (produced in Design for full/quick-feature scope), read it and execute tasks in order: complete a task, then mark its checkbox `[x]` as part of the same work unit — never batch checkbox updates for later. A task that should not be done is deferred in place (`- [>] T<n>: <title> (deferred YYYY-MM-DD: <reason>)`) with a dated reason, never skipped silently or deleted; the implementation→testing gate blocks on open tasks. For bugfix scope, create the optional `tasks.md` at implementation start when the fix spans more than one commit-sized unit. For Micro scope, reference the task description and acceptance criteria directly — no task file.
+5. **Write code.** Follow the design interfaces. Match existing code style (naming, formatting, error handling patterns).
+6. **Handle sensitive operations.** Before executing any of the following, describe the action and wait for explicit user confirmation (unattended, `AIDLC_UNATTENDED=1`: each is a hard stop except reverting this session's own changes, per `.aidlc/resources/rules/unattended.md`):
    - File deletions or destructive operations
    - Infrastructure changes (provisioning, configuration)
    - Permission or access control modifications
    - Credential or secret handling
-6. **Commit incrementally.** Produce working code at each step; avoid large uncommittable diffs.
-7. **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.
-8. **Update state.** As implementation artifacts are produced, mark them in `phase-implementation.yaml`.
+7. **Commit incrementally.** Produce working code at each step; avoid large uncommittable diffs.
+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`.
 
 ## Exit Criteria
 

package/skills/84-autopilot.md

@@ -35,7 +35,8 @@ The CLI does the work. This skill starts it and says how to watch and stop it. D
 
 - Takes items in `aidlc roadmap next` order. Builds at most two at once, and never more than the count asked for.
 - Parks an item (moves it to `hold/` with a reason) when its agent stops short, when CI fails twice, or when it passes the cost cap.
-- Halts the merge queue when a merge or release step fails, and never retries it. A half-done release is for a person — `aidlc autopilot status` shows the error.
+- 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.
 - Ends when the asked-for items are each released or parked, or, with `--all`, when nothing is ready and nothing is in flight.
 
 ## Exit Criteria