@monte3l/groundwork 1.0.0-rc.4 → 1.0.0-rc.5

package/templates/core/.claude/hooks/inject-decision-gate.mjs

@@ -73,13 +73,13 @@ export function buildContext(branch) {
         : `on \`${branch}\``;
   return [
     "Decision gate (before editing code/tests) -- currently " +
-      `${branchLine}. Settle these first, ideally via the \`starting-work\` skill:`,
-    "  • Branch -- `feat/<slug>` or `fix/<slug>` off `main` (never `main`" +
-      (onMain ? ", and you appear to be on/at `main` now" : "") +
-      ").",
-    "  • PR -- any `src/`/`tests/` change lands via PR, never a direct commit to `main`.",
-    "  • Push -- `origin <branch>`, not `origin main`.",
-    "guard-branch-isolation.mjs will block src/test writes on `main`, so branch first.",
+      `${branchLine}. These decisions come first, ideally via the \`starting-work\` skill:`,
+    "  • Branch -- a `feat/<slug>` or `fix/<slug>` branch off `main`, not `main` itself" +
+      (onMain ? "; HEAD may be on/at `main` now" : "") +
+      ".",
+    "  • PR -- any `src/`/`tests/` change lands via a PR, not a direct commit to `main`.",
+    "  • Push -- the target is `origin <branch>`, not `origin main`.",
+    "guard-branch-isolation.mjs blocks src/test writes while HEAD is on `main`.",
   ].join("\n");
 }
 

package/templates/core/.claude/skills/triaging-ci/SKILL.md

@@ -4,8 +4,8 @@ description: >-
   Diagnose a CI failure via gh CLI: resolve the failing run, fetch logs, map the
   failure to its pipeline step, report root cause plus the exact local repro
   command, and present 3-5 fix options. Use for /triaging-ci, "why did CI fail",
-  "CI is failing", "debug the CI run", or a specific run ID/URL. GitHub stance:
-  gh CLI.
+  "CI is failing", "the build is red", "find the root cause of a failing
+  build", "debug the CI run", or a specific run ID/URL. GitHub stance: gh CLI.
 ---
 
 Diagnose why a GitHub Actions CI run failed by fetching its logs via `gh` and

package/templates/core/.claude/skills/writing-commits/SKILL.md

@@ -104,7 +104,7 @@ Co-Authored-By: <exact model name from your environment> <noreply@anthropic.com>
 
 **Co-Authored-By footer**: include whenever Claude authored or substantially
 assisted the commit. Use the exact model name from the environment (e.g.,
-`Claude Sonnet 5`, `Claude Opus 5`) — never copy a model name from an example
+`Claude Sonnet 5.5`, `Claude Opus 5.5`) — never copy a model name from an example
 or template. The trailer is a provenance marker, not a legal authorship
 claim.
 
@@ -163,7 +163,7 @@ EventEmitter<TEventMap> to the public entry point.
 
 Three new named exports; no existing export changed.
 
-Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
+Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
 ```
 
 ---
@@ -215,7 +215,7 @@ the durable fixes so later modules don't re-hit them.
 
 No src/, test, or exports-map changes; zero semver impact.
 
-Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
+Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
 ```
 
 ---
@@ -244,5 +244,5 @@ output/ holds run archives, not raw output; the old name was misleading.
 
 BREAKING CHANGE: Paths.outputDir removed; use archiveDir instead.
 
-Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
+Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
 ```

package/templates/core/.prettierignore

@@ -1,6 +1,7 @@
 node_modules/
 dist/
 coverage/
+.vitest/
 pnpm-lock.yaml
 CHANGELOG.md
 # A worktree the harness creates (see .gitignore) is a full, independent

package/templates/core/_gitignore

@@ -7,6 +7,7 @@ dist/
 
 # Test / coverage artifacts
 coverage/
+.vitest/
 
 # Editor / OS
 .DS_Store

package/templates/core/bin/check-exports.mjs

@@ -79,9 +79,11 @@ try {
         // This project is ESM-only by design (no CommonJS -- see
         // guard-no-commonjs.mjs); attw's default node16-from-CJS check
         // flags exactly the interop this package intentionally doesn't
-        // support. Ignoring this one rule is attw's own documented
-        // escape hatch for a deliberately ESM-only package, not a
-        // suppression of a real problem.
+        // support. Ignoring this one rule (`--ignore-rules`) is a narrow
+        // suppression of that known interop gap, not of a real problem. attw's
+        // documented ESM-only mechanism is the broader `--profile esm-only`,
+        // which ignores every CJS-mode resolution failure; this keeps the
+        // narrower rule on purpose so other CJS-side problems still surface.
         "--ignore-rules",
         "cjs-resolves-to-esm",
       ],

package/templates/core/bin/lib/harness-rules.mjs

@@ -19,7 +19,8 @@ import { fieldList, fieldText, parseFrontmatter } from "./frontmatter.mjs";
  * Model ids and aliases the rubric accepts: the current ids and aliases, plus
  * ids that were once listed here, kept until Anthropic deprecates them. The
  * ids follow Anthropic's models overview and model-deprecations pages
- * (retrieved 2026-10-01). A legacy id that was never listed here is
+ * (retrieved 2026-10-08): Haiku 5.5 (released 2026-10-07) is current, and
+ * Haiku 4.5 is legacy but still active. A legacy id that was never listed here is
  * deliberately not added, so the rule keeps nudging pins toward current
  * models. Bump alongside a harness-guidance refresh sweep.
  * @public Not imported anywhere else in this project -- exported only for
@@ -36,6 +37,7 @@ export const CURRENT_MODELS = [
   "claude-sonnet-5",
   "claude-sonnet-5-5",
   "claude-fable-5-1",
+  "claude-haiku-5-5",
   "claude-haiku-4-5",
   "claude-haiku-4-5-20251001",
 ];

package/templates/core/tsconfig.base.json

@@ -1,8 +1,8 @@
 {
   "$schema": "https://json.schemastore.org/tsconfig",
   "compilerOptions": {
-    "target": "es2023",
-    "lib": ["es2023"],
+    "target": "es2025",
+    "lib": ["es2025"],
     "types": ["node"],
     "module": "nodenext",
     "moduleResolution": "nodenext",
@@ -12,20 +12,24 @@
     "noFallthroughCasesInSwitch": true,
     "exactOptionalPropertyTypes": true,
     "verbatimModuleSyntax": true,
+    "erasableSyntaxOnly": true,
     "isolatedModules": true,
     "noUncheckedSideEffectImports": true,
     "noPropertyAccessFromIndexSignature": true,
     "noImplicitReturns": true,
     "allowUnreachableCode": false,
     // isolatedDeclarations stays out of the base config deliberately: the
-    // build project sets it individually (see tsconfig.build.json), but the
-    // tooling project (tsconfig.json) sets declaration: false and includes
-    // tests/, which isolatedDeclarations does not tolerate.
+    // per-package build projects set it individually, but a tooling project
+    // that includes tests/ can't tolerate it (a test file re-exporting a
+    // fixture without an explicit return type is normal and fine). Promoting
+    // it here would fail typecheck on every test file rather than catch a
+    // real declaration-emit gap.
     //
     // noUnusedLocals / noUnusedParameters are deliberately NOT set:
     // @typescript-eslint/no-unused-vars already covers both at error level
     // (eslint.config.js) with an `^_`-prefix escape hatch this codebase
-    // relies on; tsc's flags honor no such pattern for locals.
+    // relies on; tsc's flags honor no such pattern for locals, so adding
+    // them would duplicate an existing gate while breaking that convention.
     "declaration": true,
     "declarationMap": true,
     "sourceMap": true,

package/templates/packs/README.md

@@ -16,6 +16,12 @@ templates/packs/<name>/
                     # exactly as templates/core/ does -- emitted the same way
 ```
 
+A pack has no release of its own: it ships inside the CLI tarball, so a change
+to one that is user-visible takes a CLI changeset whose summary starts with
+`pack(<name>):`. The checklist for working on a pack lives in the source
+repository's own `.claude/rules/pack-<name>.md` (m3l-groundwork, not shipped),
+not in the pack, since a pack cannot ship a rule (see below).
+
 ## The wiring contract
 
 **A pack never edits YAML or JavaScript.** It may add files under `files/`.

package/templates/packs/github/files/.github/workflows/claude-pr-review.yml

@@ -87,7 +87,7 @@ jobs:
           fetch-depth: 0
 
       - id: claude
-        uses: anthropics/claude-code-action@ed670b4cf9de2a5a570d130d2f6197b9e543cd64 # v1.0.240
+        uses: anthropics/claude-code-action@6fed3ca145920b639991cb756090506e1bcaf515 # v1.0.245
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           # Swap in CLAUDE_CODE_OAUTH_TOKEN or the Workload Identity

package/templates/packs/github/files/.github/workflows/claude.yml

@@ -70,7 +70,7 @@ jobs:
           fetch-depth: 1
 
       - name: Run Claude Code
-        uses: anthropics/claude-code-action@ed670b4cf9de2a5a570d130d2f6197b9e543cd64 # v1.0.240
+        uses: anthropics/claude-code-action@6fed3ca145920b639991cb756090506e1bcaf515 # v1.0.245
         with:
           # Option 1 (active default): a stored API key. Install the Claude
           # GitHub App (https://github.com/apps/claude) and add

package/templates/packs/github/pack.json

@@ -15,5 +15,5 @@
     "packageScripts": {},
     "verifySteps": []
   },
-  "adoptNotes": "claude.yml only reacts to @claude mentions from a repository owner, member or collaborator (author_association), so an outside commenter on a public repository cannot start a job that holds contents: write and your auth secret; an org member with private membership may surface as CONTRIBUTOR and be skipped. It also commits through the GitHub API (use_commit_signing) so a signed-commits ruleset accepts its work. Both workflows need one thing this pack cannot verify or install: an ANTHROPIC_API_KEY repository secret (the active default), or a CLAUDE_CODE_OAUTH_TOKEN from a Claude subscription, or a Workload Identity Federation setup in the Anthropic Console -- see the comments in .github/workflows/claude.yml for all three. Until one is configured, either workflow runs and fails cleanly (an auth error in the run log, not a crash and not a silent no-op): claude.yml on an @claude mention, claude-pr-review.yml on the next PR open/push. An adopted project that already has its own .github/workflows/claude.yml or claude-pr-review.yml surfaces as an ordinary file conflict -- keep the existing one if it's already configured for that project's own auth choice, since this pack's version would just overwrite a working setup with its own generic defaults. triaging-scan-alerts reads code-scanning alerts, and nothing in the baseline or this pack produces them: turn on GitHub's CodeQL default setup for the repository (Settings > Code security), or install the `publishing` pack, whose scorecard.yml uploads SARIF, otherwise the skill's first call returns \"code scanning is not enabled\" and reports nothing. The other two skills have no such dependency: they install anywhere a .claude/ directory exists and need only `gh` CLI auth (already required by every other gh-CLI-based skill this baseline ships). watching-pr-checks' handoff to /triaging-ci degrades gracefully if the project doesn't have that skill installed -- it still reports the real failure, just without the handoff."
+  "adoptNotes": "claude.yml only reacts to @claude mentions from a repository owner, member or collaborator (author_association), so an outside commenter on a public repository cannot start a job that holds contents: write and your auth secret; an org member with private membership may surface as CONTRIBUTOR and be skipped. It also commits through the GitHub API (use_commit_signing) so a signed-commits ruleset accepts its work. Both workflows need one thing this pack cannot verify or install: an ANTHROPIC_API_KEY repository secret (the active default), or a CLAUDE_CODE_OAUTH_TOKEN from a Claude subscription, or a Workload Identity Federation setup in the Anthropic Console -- see the comments in .github/workflows/claude.yml for all three. Until one is configured, either workflow runs and fails cleanly (an auth error in the run log, not a crash and not a silent no-op): claude.yml on an @claude mention, claude-pr-review.yml on the next PR open/push. An adopted project that already has its own .github/workflows/claude.yml or claude-pr-review.yml surfaces as an ordinary file conflict -- keep the existing one if it's already configured for that project's own auth choice, since this pack's version would just overwrite a working setup with its own generic defaults. triaging-scan-alerts reads code-scanning alerts, and nothing in the baseline or this pack produces them: turn on GitHub's CodeQL default setup for the repository (Settings > Code security), or install the `supply-chain` pack, whose scorecard.yml uploads SARIF, otherwise the skill's first call returns \"code scanning is not enabled\" and reports nothing. The other two skills have no such dependency: they install anywhere a .claude/ directory exists and need only `gh` CLI auth (already required by every other gh-CLI-based skill this baseline ships). watching-pr-checks' handoff to /triaging-ci degrades gracefully if the project doesn't have that skill installed -- it still reports the real failure, just without the handoff."
 }

package/templates/packs/harness-extras/files/.claude/hooks/subagent-statusline.mjs

@@ -5,17 +5,19 @@
  *
  * The command receives one JSON object on stdin per refresh tick: the base
  * hook fields, a `columns` field (usable row width), and a `tasks` array.
- * Each task may carry `id`, `name`, `type`, `status`, `description`, `label`,
- * `startTime`, `model`, `effort`, `contextWindowSize`, `tokenCount`,
- * `tokenSamples`, `cwd` -- `model`/`contextWindowSize` require Claude Code
- * v2.1.205+ and `effort` v2.1.214+. On an older version those fields are
- * simply absent and the row omits them.
+ * Each task may carry `id`, `name`, `type`, `agentType`, `status`,
+ * `description`, `label`, `startTime`, `model`, `effort`, `contextWindowSize`,
+ * `tokenCount`, `tokenSamples`, `cwd` -- `model`/`contextWindowSize` require
+ * Claude Code v2.1.205+, `effort` v2.1.214+ and `agentType` v2.1.293+. On an
+ * older version those fields are simply absent and the row omits them.
  *
  * Output is one JSON line per row to override: `{"id": "<task id>", "content":
  * "<row body>"}`. A task is left with Claude Code's own default rendering
  * (name · description · token count) by omitting it from the output entirely
- * -- this happens whenever `id` or `name` is missing/unusable, rather than
- * guessing at a row.
+ * -- this happens whenever `id` is missing/unusable, or both `name` and
+ * `agentType` are, rather than guessing at a row. `name` is the row's label
+ * when present; `agentType` (the same value hooks receive as `agent_type`)
+ * stands in for a task that has no name.
  *
  * The elapsed-time color thresholds (15/30 minutes) mark a subagent worth a
  * glance and one that has probably stalled.
@@ -46,9 +48,9 @@ export const ELAPSED_WARN_THRESHOLD_SEC = 15 * 60;
 export const ELAPSED_HIGH_THRESHOLD_SEC = 30 * 60;
 
 /**
- * @param {unknown} value a task's `startTime` field. The documented
- *   `subagentStatusLine` payload shape does not pin down whether this is an
- *   epoch-millisecond number or an ISO 8601 string, so both are accepted.
+ * @param {unknown} value a task's `startTime` field. The statusline docs
+ *   document it as a number of milliseconds since the Unix epoch; an ISO 8601
+ *   string is still accepted leniently.
  * @returns {number | null} epoch milliseconds, or null when unparseable.
  */
 export function parseStartTime(value) {
@@ -124,12 +126,25 @@ export function formatEffort(effort) {
  */
 export function formatSubagentRow(task, env) {
   if (typeof task !== "object" || task === null) return null;
-  const { id, name, effort, startTime, tokenCount, contextWindowSize } =
-    /** @type {Record<string, unknown>} */ (task);
+  const {
+    id,
+    name,
+    agentType,
+    effort,
+    startTime,
+    tokenCount,
+    contextWindowSize,
+  } = /** @type {Record<string, unknown>} */ (task);
   if (typeof id !== "string" || id.length === 0) return null;
-  if (typeof name !== "string" || name.length === 0) return null;
+  const label =
+    typeof name === "string" && name.length > 0
+      ? name
+      : typeof agentType === "string" && agentType.length > 0
+        ? agentType
+        : null;
+  if (label === null) return null;
 
-  const segments = [name];
+  const segments = [label];
 
   const effortText = formatEffort(effort);
   if (effortText !== null) segments.push(`${MAGENTA}${effortText}${RESET}`);

package/templates/packs/harness-extras/pack.json

@@ -66,5 +66,5 @@
     "packageScripts": {},
     "verifySteps": []
   },
-  "adoptNotes": "The statusline and compaction hooks install anywhere a .claude/ directory exists, but guard-readonly-bash.mjs imports ../../bin/lib/agent-roster.mjs (the baseline's list of writer spokes) -- copy that file alongside it in an adopted project, or skip that one hook. The PreCompact hook writes tmp/compact-handoff-<session_id>.json under the git worktree the session runs in (from the hook payload's cwd, since CLAUDE_PROJECT_DIR does not follow a session into a linked worktree) -- fresh mode's baseline .gitignore already lists tmp/ unconditionally, but an adopted project's own .gitignore was never touched by adopt mode, so add tmp/ there too before this pack's hooks run, or the handoff artifact can end up committed. The statusline scripts read only the stdin payload, .git/HEAD (via node:fs, never a git subprocess) and process.availableMemory()/os.totalmem(), so they install anywhere a .claude/ directory exists -- no dependency on the baseline's file layout. The one real adopt risk is the two top-level settings keys: a project that already defines statusLine or subagentStatusLine collides, and its existing value must be shown and decided on, never overwritten -- if either is already set, skip that key and the three statusline scripts, and install the rest of this pack (the hooks) normally rather than failing the whole install. A .claude/settings.local.json or the user's own ~/.claude/settings.json statusLine also shadows the project one -- check both before concluding the pack is wired. rate_limits.spend_limit and prompt_cache need Claude Code v2.1.251+, and the per-subagent model/contextWindowSize/effort fields need v2.1.205+/v2.1.214+; each renders only when present, so an older Claude Code degrades to fewer segments rather than breaking. The scripts behave the same on macOS and Linux; the memory segment uses process.availableMemory() (Node 22+), and on macOS with an older Node it is hidden rather than shown from os.freemem(), which undercounts there. Below roughly 40 columns the layout drops segments by priority rather than wrapping. The size-ratchet gate and the type-design-analyzer agent that used to ship here are now the separate `quality` pack."
+  "adoptNotes": "The statusline and compaction hooks install anywhere a .claude/ directory exists, but guard-readonly-bash.mjs imports ../../bin/lib/agent-roster.mjs (the baseline's list of writer spokes) -- copy that file alongside it in an adopted project, or skip that one hook. The PreCompact hook writes tmp/compact-handoff-<session_id>.json under the git worktree the session runs in (from the hook payload's cwd, since CLAUDE_PROJECT_DIR does not follow a session into a linked worktree) -- fresh mode's baseline .gitignore already lists tmp/ unconditionally, but an adopted project's own .gitignore was never touched by adopt mode, so add tmp/ there too before this pack's hooks run, or the handoff artifact can end up committed. The statusline scripts read only the stdin payload, .git/HEAD (via node:fs, never a git subprocess) and process.availableMemory()/os.totalmem(), so they install anywhere a .claude/ directory exists -- no dependency on the baseline's file layout. The one real adopt risk is the two top-level settings keys: a project that already defines statusLine or subagentStatusLine collides, and its existing value must be shown and decided on, never overwritten -- if either is already set, skip that key and the three statusline scripts, and install the rest of this pack (the hooks) normally rather than failing the whole install. A .claude/settings.local.json or the user's own ~/.claude/settings.json statusLine also shadows the project one -- check both before concluding the pack is wired. rate_limits.spend_limit and prompt_cache need Claude Code v2.1.251+, and the per-subagent model/contextWindowSize/effort fields need v2.1.205+/v2.1.214+, and the agentType label a row falls back to when a subagent has no name needs v2.1.293+; each renders only when present, so an older Claude Code degrades to fewer segments rather than breaking. The scripts behave the same on macOS and Linux; the memory segment uses process.availableMemory() (Node 22+), and on macOS with an older Node it is hidden rather than shown from os.freemem(), which undercounts there. Below roughly 40 columns the layout drops segments by priority rather than wrapping. The size-ratchet gate and the type-design-analyzer agent that used to ship here are now the separate `quality` pack."
 }

package/templates/packs/publishing/pack.json

@@ -37,5 +37,5 @@
     "node bin/check-license-headers.mjs --fix",
     "git add -A"
   ],
-  "adoptNotes": "REQUIRED right after install, before the first pnpm verify -- two one-time steps, or pnpm verify fails immediately, not from a real regression but from two setup gaps this pack cannot close itself: (1) `pnpm add -D @changesets/cli` -- the wiring contract only extends package.json's scripts, never its dependencies (see templates/packs/README.md), so the wired `changeset`/`version:packages` scripts reference a binary knip's own unlisted-binaries check correctly flags as missing until this is installed; (2) `git add -A`, then `node bin/check-license-headers.mjs --fix`, then `git add -A` again and commit the result (the gate only checks git-tracked files, so a fresh project with nothing staged passes it vacuously and fails on every file at its first push) -- templates/core has never had a license-header gate before this pack, so every one of its own files (hooks, bin/ scripts, CI workflows, the placeholder src/tests, and the workflows of any other installed pack such as `github` or `supply-chain`) is missing the SPDX header this pack's own license-headers gate now requires, the same one-time cost this repo itself paid when it adopted the same gate (see CLAUDE.md's Definition of Done). In a hand-copied install the CLI does not substitute tokens, so replace every literal `__PROJECT_NAME__` in the copied files (REUSE.toml, the SPDX headers in bin/, the workflows) with the project's real name first. Fresh mode only: a release pipeline encodes decisions (whether the package is actually public, which registry, whether a GitHub App backs the version PR) this pack cannot survey or guess at safely, so it is staged like every other pack (at .groundwork/packs/publishing/) but never auto-installed in adopt mode -- if an adopted project wants it, copy .groundwork/packs/publishing/files/ by hand, dropping the `.staged` suffix from every name (or copy templates/packs/publishing/files/ from this repo directly) and work through the one-time setup below. check-publish-version.mjs is deliberately NOT one of this pack's wired verify steps: with changesets, package.json's version on the release branch is always the one just published between releases, so a version-already-published check running on every ordinary push (via pnpm verify / pre-push) would fail every single time until the next version PR lands -- it is instead invoked directly as a step inside release.yml's pack job, the one place \"is this version about to collide with an already-published one\" is actually the right question to ask. The two remaining verify-group gates (dts-deps, license-headers) install anywhere a bin/verify.mjs-shaped gate runner exists; wire them into the project's real one if it differs. Both check-publish-version.mjs and check-dts-deps.mjs no-op (checked: 0, not a failure) on a package.json with `private: true` (the baseline's own default) or (check-dts-deps.mjs only) with no dist/**/*.d.ts yet -- flip `private` to `false` (and set a real `name`) once the package is actually meant to publish. The pack assumes a public package: `.changeset/config.json` ships `access: public`, npm refuses `restricted` for an unscoped name, and the publish shim always passes `--provenance`, which npm ties to a public source repository -- a private scoped package needs `access: restricted` and provenance removed from bin/lib/npm-publish-args.mjs. `@changesets/changelog-github` (and its `repo` option) is a drop-in swap for `.changeset/config.json`'s plain default changelog generator, once this project's GitHub repository is known, for changelog entries that link back to the originating PR/commit -- see `.changeset/README.md`. One-time setup before release.yml's first real run (distinct from the two pnpm-verify prerequisites above), distilled from this repo's own .claude/rules/releases.md: (1) npm cannot configure a trusted publisher for a package that doesn't exist yet -- publish once by hand with a temporary token first; (2) the trusted publisher is bound to the exact workflow filename `release.yml` -- renaming or moving it breaks publishing until reconfigured on npmjs.com; (3) set the trusted publisher's allowed actions to staged-only (`npm stage publish`, npm's own default and recommendation since 2026-09-03) -- a maintainer runs `npm stage approve <id>` (2FA, never automatable) before a version actually installs; (4) create an `npm-publish` GitHub environment (via `gh api`, not committed as JSON) with a required reviewer, restricted to the release branch, so the `publish` job itself pauses before the git tag/Release/stage-publish exist; (5) if branch protection requires status checks on every PR with no bypass actor, the version-PR job needs a GitHub App installation token (`APP_CLIENT_ID`/`APP_PRIVATE_KEY` repo secrets), not the default GITHUB_TOKEN, or those checks never trigger and the PR can never merge -- if this project has no such rule, `github-token: ${{ secrets.GITHUB_TOKEN }}` is enough and the app-token step can be dropped. release.yml pins `.github/release-tools/` (the npm CLI version) but the baseline's dependabot.yml only covers the github-actions ecosystem, so that pin goes stale unless you add an `npm` entry with `directory: \"/.github/release-tools\"` to the project's own .github/dependabot.yml. Security note, as of 2026-10-01: the npm pinned in the shipped `.github/release-tools/package-lock.json` (12.2.0) bundles undici 6.28.0, ip-address 10.5.0 and brace-expansion 5.0.9, which carry open advisories; every npm release found that day (11.20.0, 11.21.0, 12.2.0) bundles the same versions, and overrides cannot change bundled dependencies. Reading the npm tarballs and lockfile, no reach was found from what the shipped workflow runs (`npm ci --ignore-scripts`, `npm stage publish <tarball>` and `npm stage list`; the tarball is packed earlier by pnpm, not npm, and the shipped workflow configures no proxy; if your runner sets one, for example HTTPS_PROXY on a self-hosted runner behind an egress proxy, the ip-address advisories may apply), and the minimatch callers on those commands (Arborist, and tuf-js under sigstore) take their patterns from your own lockfile and from signed registry metadata, but that is analysis, not a run of the code. Re-check on the day of each release and bump the pinned npm as soon as a release bundling undici >= 6.28.1, ip-address >= 10.7.1 and brace-expansion >= 5.0.12 exists. The secret-scanning and Scorecard workflows that used to ship here are now the separate `supply-chain` pack."
+  "adoptNotes": "REQUIRED right after install, before the first pnpm verify -- two one-time steps, or pnpm verify fails immediately, not from a real regression but from two setup gaps this pack cannot close itself: (1) `pnpm add -D @changesets/cli` -- the wiring contract only extends package.json's scripts, never its dependencies (see templates/packs/README.md), so the wired `changeset`/`version:packages` scripts reference a binary knip's own unlisted-binaries check correctly flags as missing until this is installed; (2) `git add -A`, then `node bin/check-license-headers.mjs --fix`, then `git add -A` again and commit the result (the gate only checks git-tracked files, so a fresh project with nothing staged passes it vacuously and fails on every file at its first push) -- templates/core has never had a license-header gate before this pack, so every one of its own files (hooks, bin/ scripts, CI workflows, the placeholder src/tests, and the workflows of any other installed pack such as `github` or `supply-chain`) is missing the SPDX header this pack's own license-headers gate now requires, the same one-time cost this repo itself paid when it adopted the same gate (see CLAUDE.md's Definition of Done). In a hand-copied install the CLI does not substitute tokens, so replace every literal `__PROJECT_NAME__` in the copied files (REUSE.toml, the SPDX headers in bin/, the workflows) with the project's real name first. Fresh mode only: a release pipeline encodes decisions (whether the package is actually public, which registry, whether a GitHub App backs the version PR) this pack cannot survey or guess at safely, so it is staged like every other pack (at .groundwork/packs/publishing/) but never auto-installed in adopt mode -- if an adopted project wants it, copy .groundwork/packs/publishing/files/ by hand, dropping the `.staged` suffix from every name (or copy templates/packs/publishing/files/ from this repo directly) and work through the one-time setup below. check-publish-version.mjs is deliberately NOT one of this pack's wired verify steps: with changesets, package.json's version on the release branch is always the one just published between releases, so a version-already-published check running on every ordinary push (via pnpm verify / pre-push) would fail every single time until the next version PR lands -- it is instead invoked directly as a step inside release.yml's pack job, the one place \"is this version about to collide with an already-published one\" is actually the right question to ask. The two remaining verify-group gates (dts-deps, license-headers) install anywhere a bin/verify.mjs-shaped gate runner exists; wire them into the project's real one if it differs. Both check-publish-version.mjs and check-dts-deps.mjs no-op (checked: 0, not a failure) on a package.json with `private: true` (the baseline's own default) or (check-dts-deps.mjs only) with no dist/**/*.d.ts yet -- flip `private` to `false` (and set a real `name`) once the package is actually meant to publish. The pack assumes a public package: `.changeset/config.json` ships `access: public`, npm refuses `restricted` for an unscoped name, and the publish shim always passes `--provenance`, which npm ties to a public source repository -- a private scoped package needs `access: restricted` and provenance removed from bin/lib/npm-publish-args.mjs. `@changesets/changelog-github` (and its `repo` option) is a drop-in swap for `.changeset/config.json`'s plain default changelog generator, once this project's GitHub repository is known, for changelog entries that link back to the originating PR/commit -- see `.changeset/README.md`. One-time setup before release.yml's first real run (distinct from the two pnpm-verify prerequisites above), distilled from this repo's own .claude/rules/releases.md: (1) npm cannot configure a trusted publisher for a package that doesn't exist yet -- publish once by hand with a temporary token first; (2) the trusted publisher is bound to the exact workflow filename `release.yml` -- renaming or moving it breaks publishing until reconfigured on npmjs.com; (3) set the trusted publisher's allowed actions to staged-only (`npm stage publish`, npm's own default and recommendation since 2026-09-03) -- a maintainer runs `npm stage approve <id>` (2FA, never automatable) before a version actually installs; (4) create an `npm-publish` GitHub environment (via `gh api`, not committed as JSON) with a required reviewer, restricted to the release branch, so the `publish` job itself pauses before the git tag/Release/stage-publish exist; (5) if branch protection requires status checks on every PR with no bypass actor, the version-PR job needs a GitHub App installation token (`APP_CLIENT_ID`/`APP_PRIVATE_KEY` repo secrets), not the default GITHUB_TOKEN, or those checks never trigger and the PR can never merge -- if this project has no such rule, `github-token: ${{ secrets.GITHUB_TOKEN }}` is enough and the app-token step can be dropped. release.yml pins `.github/release-tools/` (the npm CLI version) but the baseline's dependabot.yml only covers the github-actions ecosystem, so that pin goes stale unless you add an `npm` entry with `directory: \"/.github/release-tools\"` to the project's own .github/dependabot.yml. Security note, as of 2026-10-08: the npm pinned in the shipped `.github/release-tools/package-lock.json` (12.2.0) bundles undici 6.28.0, ip-address 10.5.0, brace-expansion 5.0.9, postcss-selector-parser 7.1.4 and http-cache-semantics 4.2.0, which carry open advisories; every npm release found (11.20.0, 11.21.0, 12.2.0) bundles the same versions, and overrides cannot change bundled dependencies. Reading the npm tarballs and lockfile, no reach was found from what the shipped workflow runs (`npm ci --ignore-scripts`, `npm stage publish <tarball>` and `npm stage list`; the tarball is packed earlier by pnpm, not npm, and the shipped workflow configures no proxy; if your runner sets one, for example HTTPS_PROXY on a self-hosted runner behind an egress proxy, the ip-address advisories may apply), the minimatch callers on those commands (Arborist, and tuf-js under sigstore) take their patterns from your own lockfile and from signed registry metadata, postcss-selector-parser is called only by `npm query` and `npm sbom`, and http-cache-semantics sits behind make-fetch-happen's private (`shared: false`) cache, but that is analysis, not a run of the code. Re-check on the day of each release and bump the pinned npm as soon as a release bundling undici >= 6.28.1, ip-address >= 10.7.1, brace-expansion >= 5.0.12 and postcss-selector-parser >= 7.1.6 exists; fixes are open upstream as npm/cli#10088 and #10089. http-cache-semantics has no fixed release (4.3.0 is outside the advisory's range, but upstream closed the report as not planned), so a bump past 4.2.0 only clears its alert. The secret-scanning and Scorecard workflows that used to ship here are now the separate `supply-chain` pack."
 }

package/templates/packs/quality/files/.claude/agents/type-design-analyzer.md

@@ -3,7 +3,7 @@ name: type-design-analyzer
 description: Read-only type-design reviewer. Rates the type design quality of changed exports on four dimensions (encapsulation, invariant expression, invariant usefulness, invariant enforcement), each scored 1–10, and flags violations of strict-TS / branded-type / make-illegal-states-unrepresentable rules. Use after writing or changing any exported TypeScript types, interfaces, or function signatures. Complements code-reviewer (general structure/SOLID).
 tools: Read, Grep, Glob, Bash
 disallowedTools: Agent
-model: claude-opus-5
+model: claude-opus-5-5
 effort: xhigh
 maxTurns: 40
 color: orange

package/templates/packs/quality/pack.json

@@ -25,5 +25,5 @@
       }
     ]
   },
-  "adoptNotes": "check-file-budget.mjs's ROOTS default assumes a flat src/+tests/ layout and its ceilings are this baseline's defaults -- in an adopted project, re-point ROOTS at the project's real source layout (or drop the gate) before wiring it. check-file-budget.mjs imports ./lib/report.mjs, a baseline file that an adopted project will not have -- copy bin/lib/report.mjs alongside the gate, or treat the gate as not installable. The verify step assumes a bin/verify.mjs-shaped gate runner; if the project has none, install the agent and report the gate as not installable rather than inventing one. The type-design-analyzer agent has no such dependency and installs anywhere a .claude/agents/ directory exists; it is a read-only review spoke (model claude-opus-5 at xhigh effort, more expensive than the baseline's reviewers, which run claude-opus-5-5 at medium effort), and nothing in the baseline's hub-and-spoke instructions dispatches it by name -- ask for it after changing exported types, or add it to the project's own CLAUDE.md review step."
+  "adoptNotes": "check-file-budget.mjs's ROOTS default assumes a flat src/+tests/ layout and its ceilings are this baseline's defaults -- in an adopted project, re-point ROOTS at the project's real source layout (or drop the gate) before wiring it. check-file-budget.mjs imports ./lib/report.mjs, a baseline file that an adopted project will not have -- copy bin/lib/report.mjs alongside the gate, or treat the gate as not installable. The verify step assumes a bin/verify.mjs-shaped gate runner; if the project has none, install the agent and report the gate as not installable rather than inventing one. The type-design-analyzer agent has no such dependency and installs anywhere a .claude/agents/ directory exists; it is a read-only review spoke (model claude-opus-5-5 at xhigh effort, more expensive than the baseline's reviewers, which run claude-opus-5-5 at medium effort), and nothing in the baseline's hub-and-spoke instructions dispatches it by name -- ask for it after changing exported types, or add it to the project's own CLAUDE.md review step."
 }