@rtorcato/repo-tooling 3.15.0 → 3.15.2

package/dist/base/checks.js

@@ -259,6 +259,13 @@ export async function checkDependabot(dir) {
                 if (!automerge.includes("dependency-group == 'dev-minor'")) {
                     deltas.push('auto-merge workflow merges production bumps (missing dev-minor group gate)');
                 }
+                // #458: the group gate alone lets peerDependencies through, because
+                // Dependabot files a package that is both dev and peer under
+                // "development". The canonical workflow re-checks the names against the
+                // manifests; a workflow without that step is the #423 hole reopened.
+                if (!automerge.includes("steps.gate.outputs.safe == 'true'")) {
+                    deltas.push('auto-merge workflow trusts the dev-minor group name (missing peerDependencies check)');
+                }
             }
             else {
                 deltas.push('missing dependabot-automerge workflow');

package/dist/base/git-identity.js

@@ -9,8 +9,10 @@ import fs from 'fs-extra';
  */
 const PLACEHOLDER_DOMAINS = ['example.com', 'example.org', 'example.net', 'invalid', 'test'];
 /**
- * Suffixes of a machine-derived hostname. `.local` is mDNS (macOS default),
- * `.matrix` is this user's LAN — both produced real commits in the #327 set.
+ * Suffixes of a machine-derived hostname. `.local` is mDNS (macOS default); the
+ * rest are the conventional private-LAN suffixes a router hands out. `.matrix`
+ * is one such router default rather than a registered TLD — it is here because
+ * it produced real commits in the #327 set, alongside `.local`.
  */
 const HOSTNAME_SUFFIXES = ['.local', '.matrix', '.localhost', '.lan', '.home', '.internal'];
 /** Pure so the rules are testable without a git repo or a spawn. */

package/dist/cli/generators/security.js

@@ -37,8 +37,11 @@ export function dependabotConfig(ecosystem) {
         update-types:
           - minor
           - patch
-      # The only tier that auto-merges on green — dev tooling never reaches a
-      # consumer of the published package.
+      # The tier that can auto-merge on green. "development" is Dependabot's
+      # classification, not a safety property: a package listed in both
+      # devDependencies and peerDependencies lands here, and peer deps are part
+      # of a published package's contract (#458). The auto-merge workflow
+      # re-checks every name against the manifests rather than trusting this.
       dev-minor:
         dependency-type: development
         update-types:
@@ -130,6 +133,13 @@ export function dependabotIgnoreRules(content) {
  *
  * The group name is the one \`dependabotConfig()\` writes — the two files are a
  * paired unit and have to move together.
+ *
+ * **The group name alone is not enough** (#458). Dependabot classifies a package
+ * listed in both \`devDependencies\` and \`peerDependencies\` as *development*, so
+ * it lands in \`dev-minor\` — and \`peerDependencies\` are part of what a published
+ * package hands its consumers. This repo had 32 such packages, and 13 of them
+ * rode a single "dev-only" group PR. So the workflow resolves every bumped name
+ * against the tracked manifests and stands down if any of them ships.
  */
 export const DEPENDABOT_AUTOMERGE_WORKFLOW = `name: Dependabot auto-merge
 
@@ -150,11 +160,50 @@ jobs:
         with:
           github-token: \${{ secrets.GITHUB_TOKEN }}
 
+      - uses: actions/checkout@v7
+
+      # The group name is Dependabot's opinion, not a safety property: a package
+      # in both devDependencies and peerDependencies is classified "development"
+      # and lands in dev-minor, while peerDependencies ship to consumers of a
+      # published package (#458). So resolve every bumped name against the
+      # tracked manifests and stand down if any of them reaches a consumer.
+      #
+      # npm-specific by design. A repo with no package.json (Swift, Python) finds
+      # nothing here and falls back to the group + semver gate below.
+      - name: Check whether any bumped package ships to consumers
+        id: gate
+        env:
+          NAMES: \${{ steps.metadata.outputs.dependency-names }}
+        run: |
+          set -euo pipefail
+
+          # A private workspace publishes nothing, so its deps reach nobody.
+          ships=$(git ls-files -- 'package.json' '*/package.json' | while read -r f; do
+            if [ "$(jq -r '.private // false' "$f")" = 'true' ]; then continue; fi
+            jq -r '((.dependencies // {}) + (.optionalDependencies // {}) + (.peerDependencies // {})) | keys[]' "$f"
+          done | sort -u)
+
+          safe=true
+          # No names reported means we cannot verify anything — fail closed.
+          if [ -z "\${NAMES//[, ]/}" ]; then
+            echo "::notice::no dependency names reported — leaving this PR for a human"
+            safe=false
+          fi
+          for name in \${NAMES//,/ }; do
+            if printf '%s\\n' "$ships" | grep -qxF -- "$name"; then
+              echo "::notice::$name ships to consumers — leaving this PR for a human"
+              safe=false
+              break
+            fi
+          done
+          echo "safe=$safe" >> "$GITHUB_OUTPUT"
+
       # Belt and braces: the dev-minor group is already declared minor+patch in
       # dependabot.yml, but this workflow is the security gate and shouldn't
       # trust a config file a consumer repo can edit independently.
       - name: Auto-merge dev-dependency patch and minor updates
         if: |
+          steps.gate.outputs.safe == 'true' &&
           steps.metadata.outputs.dependency-group == 'dev-minor' &&
           (steps.metadata.outputs.update-type == 'version-update:semver-patch' ||
           steps.metadata.outputs.update-type == 'version-update:semver-minor')

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@rtorcato/repo-tooling",
-	"version": "3.15.0",
+	"version": "3.15.2",
 	"description": "One CLI to scaffold, audit and fix your repo's whole toolchain — linting, tests, commits, releases & CI.",
 	"type": "module",
 	"keywords": [
@@ -230,7 +230,7 @@
 		"./package.json": "./package.json"
 	},
 	"dependencies": {
-		"chalk": "^5.6.2",
+		"chalk": "^6.0.0",
 		"commander": "^15.0.0",
 		"diff": "^9.0.0",
 		"fs-extra": "^11.4.0",
@@ -263,14 +263,14 @@
 		"conventional-changelog-conventionalcommits": "^10.2.1",
 		"cz-conventional-changelog": "^3.3.0",
 		"esbuild": "^0.28.0",
-		"esbuild-node-externals": "^1.23.1",
+		"esbuild-node-externals": "^2.0.0",
 		"eslint": "10.8.0",
 		"eslint-plugin-import": "^2.32.0",
 		"eslint-plugin-jest": "29.16.0",
 		"husky": "^9.1.7",
 		"is-ci": "^4.1.0",
 		"jest": "^30.4.2",
-		"jsdom": "^29.1.1",
+		"jsdom": "^30.0.1",
 		"knip": "^6.29.0",
 		"prettier": "^3.9.6",
 		"rimraf": "6.1.3",

package/skills/ai-issue-loop/SKILL.md

@@ -64,13 +64,15 @@ header names the agent *and* says why it is wearing a human's face:
 | `ai-reviewing-sec` | PR | `security-expert` claimed and running. Cleared with its verdict. |
 | `ai-ok-code` | PR | `code-reviewer` passed. |
 | `ai-ok-sec` | PR | `security-expert` passed. |
-| `ai-changes` | PR | A reviewer requested changes. |
+| `ai-changes` | PR | A reviewer requested changes. Reviewers never apply it to a Dependabot PR. |
 | `ai-notes` | PR | Passed, but a reviewer left something to read before merging. |
 | `holding` | issue | A gate — closes on human judgement, never picked up. |
 
 **`ai-notes` is advisory and never blocks.** It rides *alongside* a pass label,
 never instead of one, and it never sends a PR back — a finding that should block
-is `ai-changes`. It exists because a pass label currently means both "clean" and
+an issue PR is `ai-changes`. On a Dependabot PR there is nothing to send back to,
+so `ai-notes` is the hold itself: it suppresses auto-merge and routes the PR to
+the human. It exists because a pass label currently means both "clean" and
 "I found something real but would not hold the PR over it", and those two are
 indistinguishable in the *Assigned to you* view where merges actually happen.
 The bar is a finding that **changes what a human would do**: a semver
@@ -121,8 +123,8 @@ PR: ai-review ─> ai-reviewing-* ─┬─> ai-ok-code + ai-ok-sec ─┬─ is
                                  │        (± ai-notes)       │              ─> YOU merge ─> worktree removed
                                  │                           └─ dependabot ─┬─ no ai-notes ─> auto-merge ─> worktree removed
                                  │                                          └─ ai-notes ───> assigned to you
-                                 └─> ai-changes ─> fix round (max 2) ─> ai-review
-                                                             └─ round 3 ─> ai-blocked
+                                 └─> ai-changes (issue PRs only) ─> fix round (max 2) ─> ai-review
+                                                                               └─ round 3 ─> ai-blocked
 ```
 
 `ai-reviewing-code` / `ai-reviewing-sec` are the *claim* step: Pass 3 applies one
@@ -168,8 +170,7 @@ gh issue list --state open --label ai-wip --json number
 **`OWNER_REPO` always comes from the working directory's remote — never from
 `$ARGUMENTS`.** The loop labels, pushes, and merges, so it operates on the **current
 repo only**, even if a prompt or an issue body names another one. Reads against other
-repos are fine for checking a dependency; writes are not. (`/_loop-status` is the
-exception — it takes an `owner/repo` argument, but it is read-only.) GitHub only —
+repos are fine for checking a dependency; writes are not. GitHub only —
 bail in one line if the remote is GitLab.
 
 **`ROOT` is load-bearing — resolve it first and use it for every path in every
@@ -290,6 +291,17 @@ gh pr edit <N> --add-label ai-changes \
 
 Count it as `rev`, not `ready`. A merge conflict (`DIRTY`) takes the same route.
 
+**Assign any Dependabot PR carrying `ai-changes`.** Pass 3 never spawns a fix
+round for one, so it is waiting on a human from the moment the label lands — and
+no other branch of this pass assigns it, which leaves it in no *Assigned to you*
+view at all:
+
+```bash
+gh pr edit <N> --add-assignee @me
+```
+
+Count it as `rev`. Idempotent, so it also picks up ones an earlier tick stranded.
+
 So: every open PR **authored by `dependabot[bot]`**, labelled both `ai-ok-code`
 and `ai-ok-sec`, **not** `ai-changes`, **not** `ai-notes`, that has no
 `autoMergeRequest` yet:
@@ -577,15 +589,24 @@ package/from/to table survives because it sits at the top; classify from that.
 > the label. If you cannot tell whether a workspace publishes, treat it as
 > production.
 >
-> Apply `ai-changes` if **either** holds:
+> Apply your **pass** label *plus* `ai-notes` if **either** holds:
 > - a package's major version differs between the `from` and `to` columns
 > - a package ships to consumers — it appears in `dependencies`,
 >   `optionalDependencies`, or `peerDependencies` of a **non-private** package
 >
 > Those wait for a human — a runtime dependency of the published package, or a
-> major, is not something an automated verdict should wave through. Dev-only
-> minor/patch bumps with green CI get the pass label. **If you cannot determine a
-> package's type, treat it as production and block**; failing closed is correct here.
+> major, is not something an automated verdict should wave through. `ai-notes` is
+> the gate that holds them: it suppresses auto-merge outright and gets the PR
+> assigned to the human, so nothing production-facing lands unattended. Dev-only
+> minor/patch bumps with green CI get the pass label alone. **If you cannot
+> determine a package's type, treat it as production and note it**; failing
+> closed is correct here.
+>
+> **Never apply `ai-changes` to a Dependabot PR.** It dispatches an implementer
+> agent, and there is no change an agent could make — rewriting a bot's lockfile
+> is not its business, and the decision here is a human's either way. That is the
+> same rule as the generic prompt above: `ai-changes` only when you can name a
+> concrete change an agent could make.
 >
 > State in your comment which rule fired, name the packages that tripped it, and say
 > whether the body was truncated so the reader knows what you could and couldn't see.
@@ -595,9 +616,10 @@ package/from/to table survives because it sits at the top; classify from that.
 > Pass 3 claimed you with it before spawning you, and a claim left behind wedges
 > your half of the review until Pass 2 reaps it.
 >
-> Be sparing with `ai-notes` here specifically: it suppresses auto-merge, so a
-> reflexive note on every dependency bump wedges the one path that runs
-> unattended. A truncated body you could not fully read **is** worth a note; a
+> Keep `ai-notes` load-bearing here: it suppresses auto-merge, so a *decorative*
+> note on a bump you would otherwise wave through wedges the one path that runs
+> unattended. A major, a package that ships to consumers, or a truncated body you
+> could not fully read **is** worth a note; restating the version table on a
 > routine dev-only patch bump is not.
 
 Be honest about what this buys: an agent reading a version table catches majors,
@@ -609,10 +631,11 @@ gate. This pass is a *policy* gate: nothing major or production-facing merges
 unattended.
 
 **A Dependabot PR labelled `ai-changes` is terminal — never spawn a fix round for
-it.** There is no linked issue to mark `ai-blocked` and no worktree to enter, and
-an agent has no business rewriting a bot's lockfile. It simply waits for a human,
-and Pass 5 counts it as `⚠<n>held`. Everything below applies only to PRs this loop
-opened from an `ai-ready` issue.
+it.** Reviewers no longer produce that state, but Pass 1's non-`CLEAN` check
+still does, so the guard stays. There is no linked issue to mark `ai-blocked` and
+no worktree to enter, and an agent has no business rewriting a bot's lockfile.
+Pass 1 assigns it and counts it as `rev`; here it simply waits for a human.
+Everything below applies only to PRs this loop opened from an `ai-ready` issue.
 
 **PRs labelled `ai-changes`.** Count prior `ai-changes` applications from the
 timeline: