@rasensio/aidlc-content 1.48.0 → 1.50.0

package/package.json

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

package/skills/04-roadmap.md

@@ -143,7 +143,7 @@ List each status directory, reading **only frontmatter and the containing direct
 
 For a `hold/` item, show whether it is **parked or declined**, with its reason, from the last `history` entry — that entry is in the frontmatter, so this costs nothing extra. An item with no reason recorded is reported as `hold — reason not recorded`, never guessed at: parked and declined are opposite answers, and a wrong one either revives work somebody killed or buries work somebody agreed to.
 
-**`aidlc roadmap next`** is the deterministic answer to "what next?": the `backlog/` item with the lowest `priority` among those whose `depends_on` are all `done`, unranked items last, ties by file name (`--explain` shows the order and what was skipped and why; `--json` for scripts). It is read-only and never promotes — promoting stays a person's decision. `priority` is an ordinary extension field a project declares in `roadmap.item_fields`; a rank, where 1 is first.
+**`aidlc roadmap next`** is the deterministic answer to "what next?": the `backlog/` item with the lowest `priority` among those whose `depends_on` are all `done`, unranked items last, ties by file name (`--explain` shows the order and what was skipped and why; `--json` for scripts). It is read-only and never promotes — promoting stays a person's decision. `priority` is an ordinary extension field a project declares in `roadmap.item_fields`; a rank, where 1 is first. Where it is declared, `--explain` also lists every unranked backlog item, so one sitting last is visible rather than silently last. **`aidlc roadmap rank <item> <n>`** is the one way to change a rank: it puts the item at `n` and renumbers every ranked backlog item 1…k, so ranks stay unique and gap-free.
 
 The frontmatter-only rule holds for browsing, which is a list and must stay cheap enough to run over the whole roadmap. **Triage** below is the one flow allowed into the body, and only as far as the executive summary.
 
@@ -159,6 +159,18 @@ Triage is the one flow that reads into the body, and it reads **the executive su
 
 Read `.aidlc/context/constitution.md` when it exists and apply the constitution rule in `.aidlc/resources/rules/constitution.md`: an item that crosses a prohibition is the clearest `hold/` there is, and naming the prohibition turns "not for us" into a reason the submitter can read.
 
+### Ranking on the way in
+
+When the project declares `priority` in `roadmap.item_fields`, moving an item into `backlog/` includes giving it a rank — otherwise it sorts last, and the order `aidlc roadmap next` and autopilot follow becomes the order nobody chose.
+
+1. Read the current order with `aidlc roadmap next --explain`.
+2. **Propose** a rank with a one-line reason drawn from the executive summaries — this item against its neighbours, not a score.
+3. Show where it lands: `aidlc roadmap rank <item> <n> --dry-run` prints the whole order with the item marked.
+4. Ask once: accept rank `n`, or give another number. One answer settles it.
+5. Run `aidlc roadmap rank <item> <answer>` without `--dry-run`. Never edit `priority:` by hand — the command is what keeps ranks unique and gap-free.
+
+The proposed rank is never written without the person's answer: a rank nobody looked at reads exactly like a decided one. There is no scoring formula; the person decides and the flow only proposes. Projects that do not declare `priority` triage exactly as before, with no rank asked for.
+
 ## Promote
 
 Promotion is where the roadmap meets the lifecycle:
@@ -185,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