@rasensio/aidlc-content 1.48.0 → 1.49.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rasensio/aidlc-content",
-  "version": "1.48.0",
+  "version": "1.49.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: