@williamthorsen/release-kit 12.0.0 → 13.1.0

package/docs/work-types.md

@@ -1,56 +1,55 @@
 # Work types and tiers
 
-The taxonomy against which release-kit parses commits: its tiers, the breaking-change policy, section markers, customization, and the maintainer scripts that keep release-kit's copy level with its upstream.
-
-release-kit bundles a copy of the codeassembly canonical taxonomy in `packages/release-kit/src/work-types.json`, kept level by the [maintainer scripts](#maintaining-the-bundled-taxonomy). The taxonomy is split into three tiers that drive section rendering and audience classification.
-
-| Tier     | Key         | Header                    | Aliases       | `!` policy   |
-| -------- | ----------- | ------------------------- | ------------- | ------------ |
-| public   | `feat`      | 🎉 Features               | `feature`     | optional     |
-| public   | `drop`      | 🪦 Removed                |               | **required** |
-| public   | `deprecate` | 🗑️ Deprecated             |               | forbidden    |
-| public   | `fix`       | 🐛 Bug fixes              | `bugfix`      | optional     |
-| public   | `sec`       | 🔒 Security               | `security`    | optional     |
-| public   | `perf`      | ⚡ Performance            | `performance` | optional     |
-| internal | `internal`  | 🏗️ Internal features      | `utility`     | forbidden    |
-| internal | `refactor`  | ♻️ Refactoring            |               | forbidden    |
-| internal | `tests`     | 🧪 Tests                  | `test`        | forbidden    |
-| process  | `tooling`   | ⚙️ Tooling                |               | forbidden    |
-| process  | `ci`        | 👷 CI                     |               | forbidden    |
-| process  | `deps`      | 📦 Dependencies           | `dep`         | forbidden    |
-| process  | `ai`        | 🤖 Agentic support        |               | forbidden    |
-| process  | `docs`      | 📚 Documentation          | `doc`         | forbidden    |
-| process  | `fmt`       | (excluded from changelog) |               | forbidden    |
+The taxonomy against which release-kit parses commits: its tiers, the breaking-change policy, section markers, and customization.
+
+release-kit reads the taxonomy from `CANONICAL_TAXONOMY` in [`@williamthorsen/change-grammar`](https://github.com/williamthorsen/node-monorepo-tools/tree/main/packages/change-grammar#readme), which also parses commit subjects. The taxonomy is split into three tiers that determine section rendering and audience classification.
+
+| Tier     | Key         | Header                    | Aliases       | `!` policy |
+| -------- | ----------- | ------------------------- | ------------- | ---------- |
+| public   | `feat`      | 🎉 Features               | `feature`     | optional   |
+| public   | `drop`      | 🪦 Removed                |               | optional   |
+| public   | `deprecate` | 🗑️ Deprecated             |               | forbidden  |
+| public   | `fix`       | 🐛 Bug fixes              | `bugfix`      | optional   |
+| public   | `sec`       | 🔒 Security               | `security`    | optional   |
+| public   | `perf`      | ⚡ Performance            | `performance` | optional   |
+| internal | `internal`  | 🏗️ Internal features      | `utility`     | forbidden  |
+| internal | `refactor`  | ♻️ Refactoring            |               | forbidden  |
+| internal | `tests`     | 🧪 Tests                  | `test`        | forbidden  |
+| process  | `tooling`   | ⚙️ Tooling                |               | forbidden  |
+| process  | `ci`        | 👷 CI                     |               | forbidden  |
+| process  | `deps`      | 📦 Dependencies           | `dep`         | forbidden  |
+| process  | `ai`        | 🤖 Agentic support        |               | forbidden  |
+| process  | `docs`      | 📚 Documentation          | `doc`         | forbidden  |
+| process  | `fmt`       | (excluded from changelog) |               | forbidden  |
 
 ## Tier semantics
 
-- **`public`** — visible to all audiences. `public`-tier sections appear in both public release notes and dev changelogs.
-- **`internal`** — dev-only. `internal`-tier sections appear in dev changelogs but not in public-facing release notes.
-- **`process`** — dev-only. Same audience treatment as `internal`.
+- **`public`**: Visible to all audiences. `public`-tier sections appear in both public release notes and dev changelogs.
+- **`internal`**: Dev-only. `internal`-tier sections appear in dev changelogs but not in public-facing release notes.
+- **`process`**: Dev-only. Same audience treatment as `internal`.
 
-Section render order is **tier order (`public` → `internal` → `process`), then row order within tier**. It comes from the declaration order of `work-types.json`: `CANONICAL_SECTION_ORDER` in `buildChangelogEntries.ts` indexes each header by its row, and `transformReleases` sorts a release's sections by that index whatever order the commits arrived in.
+Section render order is **tier order (`public` → `internal` → `process`), then row order within tier**. It comes from the declaration order of `CANONICAL_TAXONOMY`: `CANONICAL_SECTION_ORDER` in `buildChangelogEntries.ts` indexes each header by its row, and `transformReleases` sorts a release's sections by that index whatever order the commits arrived in.
 
 ## Subject forms
 
-`classifyChangelogCommit` resolves a commit's type through `parseCommitMessage`, so a subject reaches its section under any form that parser accepts: `type:`, `scope|type:`, and the conventional-commit `type(scope):`. The type is matched case-insensitively, so `Feat:` and `FEAT:` resolve like `feat:`. The ticket-ID prefix is still required, and an alias resolves before the section is chosen. A commit whose [change-record block](changelogs.md#change-record-blocks) records entries takes its sections from the entries' types instead of from its subject.
+`classifyChangelogCommit` resolves a commit's type through `parseCommitMessage`, so a subject maps to its section under any form that the parser accepts: `type:`, `scope|type:`, and the conventional-commit `type(scope):`, each followed by a space and a title. A subject combining both scope forms, such as `web|feat(api):`, does not parse. The type is matched case-insensitively: `Feat:` and `FEAT:` resolve like `feat:`. The ticket-ID prefix is still required, and an alias resolves before the section is chosen. A commit whose [change-record block](changelogs.md#change-record-blocks) records entries takes its sections from the entries' types instead of from its subject.
 
 ## `utility` alias
 
-`utility:` is a backward-compat alias for `internal:`. Both forms parse to the same canonical type, route to the same `🏗️ Internal features` section, and are subject to the same `!` policy.
+`utility:` is a backward-compat alias for `internal:`. Both forms parse to the same canonical type, appear under the same `🏗️ Internal features` section, and are subject to the same `!` policy.
 
 ## `!` (breaking change) policy
 
-Each work-type carries a `breakingPolicy` value:
+Each work-type has a `breakingPolicy` value:
 
-- `optional` (`feat`, `fix`, `sec`, `perf`): `!` is allowed; both `type:` and `type!:` parse cleanly. Any of these can break consumers, and the marker records when one does: A fix can break consumers who relied on the defective behavior, and a performance change can break a contract to achieve its gain.
+- `optional` (`feat`, `drop`, `fix`, `sec`, `perf`): `!` is allowed; both `type:` and `type!:` parse cleanly. Any of these can break consumers, and the marker records when one does: A removal breaks consumers only when the removed surface was published, a fix can break consumers who relied on the defective behavior, and a performance change can break a contract to achieve its gain.
 - `forbidden` (`deprecate` and every `internal`- and `process`-tier type): `!` is a policy violation. Deprecating a surface keeps it working, and removing it is a `drop`. Internal- and process-tier work does not face consumers; a change that breaks consumers faces them and therefore takes a public-tier type.
-- `required` (`drop`): Bare `drop:` is a policy violation; only `drop!:` is accepted. Removing a public surface always breaks consumers, and the `!` form makes that explicit.
 
 ### Policy enforcement
 
 `parseCommitMessage` enforces the `!` policy at release time and treats a violation as a warning. Commits already in the log cannot be rewritten, so a policy-violating commit is parsed using its canonical type with `breaking: false` (the `!` is dropped from the parse) and an `onPolicyViolation` callback fires. `readReleaseHistory` collects these warnings while it builds the items of the unreleased window, and the release report lists them. A single legacy `internal!` in a year-old log does not block releases.
 
-A `BREAKING CHANGE:` body footer on a `forbidden`-policy type triggers the same warning path as the prefix `!` does: A type that cannot be breaking is parsed as non-breaking whichever surface carries the signal. The warning is all that a footer triggers; it raises no bump (see [`🚨 **Breaking:**` bullet marker](#-breaking-bullet-marker)).
+A `BREAKING CHANGE:` body footer on a `forbidden`-policy type triggers the same warning path as the prefix `!` does: A type that cannot be breaking is parsed as non-breaking whichever surface has the signal. The warning is all that a footer triggers; it doesn't raise a bump (see [`🚨 **Breaking:**` bullet marker](#-breaking-bullet-marker)).
 
 The release-prepare orchestrators (`releasePrepare`, `releasePrepareMono`, `releasePrepareProject`) apply `DEFAULT_BREAKING_POLICIES` automatically. Violations in the titles and change-record entries of each workspace's or project's unreleased window are collected onto the corresponding result's `policyViolations` field, on a skipped result as on a released one, and rendered under the section in the prepare report:
 
@@ -58,7 +57,7 @@ The release-prepare orchestrators (`releasePrepare`, `releasePrepareMono`, `rele
 arrays
   Found 1 commits since arrays-v1.0.0
   🟠 1 policy violation:
-      · def5678 'internal!: refactor cache' — type 'internal' at prefix surface
+      · def5678 'internal!: refactor cache': type 'internal' at prefix surface
   Bumping versions (patch)...
   📦 1.0.0 → 1.0.1 (patch)
 ```
@@ -67,7 +66,7 @@ To customize, set `breakingPolicies` in `release-kit.config.ts`. The map replace
 
 ## `🚨 **Breaking:**` bullet marker
 
-Items whose commit subject carries the `!` prefix (e.g. `feat!`, `drop!`, `feat(api)!`) on a type whose policy permits it are rendered with a `🚨 **Breaking:** ` prefix on the bullet:
+Items whose commit subject has the `!` prefix (e.g. `feat!`, `drop!`, `feat(api)!`) on a type whose policy permits it are rendered with a `🚨 **Breaking:** ` prefix on the bullet:
 
 ```markdown
 - 🚨 **Breaking:** Drop legacy /v1 endpoint
@@ -75,17 +74,17 @@ Items whose commit subject carries the `!` prefix (e.g. `feat!`, `drop!`, `feat(
 
 The marker agrees with the version bump:
 
-- A `forbidden`-policy type carrying `!`, such as `refactor!`, gets no marker, just as its `!` raises no bump; the prepare report lists it as a policy violation. An [editorial override](editorial-overrides.md) that sets `breaking: true` restores the marker for one entry.
+- A `forbidden`-policy type with `!`, such as `refactor!`, doesn't get a marker, just as its `!` doesn't raise a bump; the prepare report lists it as a policy violation. An [editorial override](editorial-overrides.md) that sets `breaking: true` restores the marker for one entry.
 - The configured `breakingPolicies` map, `{}` included, decides which types permit the marker.
-- A commit whose type the parser cannot resolve reaches no changelog at all, so no marker question arises.
+- A commit whose type the parser cannot resolve doesn't appear in any changelog, so the question of a marker doesn't arise.
 
-A `BREAKING CHANGE:` body footer on its own does **not** retroactively mark a changelog item as breaking, even on a type whose policy permits `!`; the changelog signal is tied to the commit prefix. This avoids surprise breaking-marker appearances for older commits written under earlier conventions. The bump follows the items, so a footer raises no major bump either: A consumer that marks breaking changes with the footer alone gets the bump of the commit's type.
+A `BREAKING CHANGE:` body footer on its own does **not** retroactively mark a changelog item as breaking, even on a type whose policy permits `!`; the changelog signal is tied to the commit prefix. This avoids surprise breaking-marker appearances for older commits written under earlier conventions. Because the bump follows the items, a footer doesn't raise a major bump either: A consumer that marks breaking changes with the footer alone gets the bump of the commit's type.
 
-The emoji and label of this marker are sourced from the `markers.breaking` entry in `work-types.json` (see [Section markers](#section-markers)) so consumers that render their own breaking-changes section draw from the same SSOT.
+The emoji and label of this marker come from the `markers.breaking` entry of `CANONICAL_TAXONOMY` (see [Section markers](#section-markers)), which is also the source for consumers that render their own breaking-changes section.
 
 ## Section markers
 
-Alongside `tiers` and `types`, `work-types.json` exposes a top-level `markers` object for cross-cutting section markers — visual indicators that aren't tied to a specific work type. Today the canonical entry is `breaking`; additional keys (e.g., security advisories, migration notices) can be added without a schema change.
+Alongside `tiers` and `types`, `CANONICAL_TAXONOMY` declares a top-level `markers` object for cross-cutting section markers: visual indicators that aren't tied to a specific work type. Today its only entry is `breaking`.
 
 ```jsonc
 {
@@ -95,29 +94,14 @@ Alongside `tiers` and `types`, `work-types.json` exposes a top-level `markers` o
 }
 ```
 
-Entries store plain text only — the SSOT is format-agnostic, so consumers apply their own emphasis (Markdown bold, ANSI escape, HTML `<strong>`) when constructing the rendered form. release-kit's own renderer constructs the per-bullet prefix as `${emoji} **${label}:** ` from this entry.
+Entries store plain text only, so that the taxonomy stays format-agnostic: Consumers apply their own emphasis (Markdown bold, ANSI escape, HTML `<strong>`) when constructing the rendered form. release-kit's own renderer constructs the per-bullet prefix as `${emoji} **${label}:** ` from this entry.
 
 ## `fmt`
 
-`fmt:` commits are recognized by `parseCommitMessage`, but `fmt` carries `excludedFromChangelog: true`, which `DEFAULT_WORK_TYPES` carries onto its `WorkTypeConfig`. `classifyChangelogCommit` excludes a commit whose type sets the flag, so a `fmt:` commit never appears in `CHANGELOG.md`, `changelog.json`, or release notes. It yields no item, so it raises no bump, and the release report does not list it as unparseable. The label and emoji are present in `work-types.json` for schema parity with the codeassembly upstream but never render.
+`fmt:` commits are recognized by `parseCommitMessage`, but `fmt` sets `excludedFromChangelog: true`, which `DEFAULT_WORK_TYPES` copies onto its `WorkTypeConfig`. `classifyChangelogCommit` excludes a commit whose type sets the flag, so a `fmt:` commit never appears in `CHANGELOG.md`, `changelog.json`, or release notes. Because it doesn't yield an item, it doesn't raise a bump, and the release report does not list it as unparseable. The taxonomy declares a label and emoji for `fmt` like any other type, but they never render.
 
 ## Custom work types
 
-Work types from a config are merged with these defaults by key: a consumer entry overrides or extends, it does not replace the full set. `classifyChangelogCommit` reads the merged record, so an added type reaches the changelog under the `header` it declares, and an entry setting `excludedFromChangelog: true` keeps its commits out of the changelog and the bump. Release-notes sections are rendered in the declaration order of the merged work-types record, with any unknown titles trailing the known ones.
+Work types from a config are merged with these defaults by key: A consumer entry overrides or extends, it does not replace the full set. `classifyChangelogCommit` reads the merged record, so an added type appears in the changelog under the `header` that it declares, and an entry setting `excludedFromChangelog: true` keeps its commits out of the changelog and the bump. Release-notes sections are rendered in the declaration order of the merged work-types record, with any unknown titles trailing the known ones.
 
-The default `devOnlySections` (excluded from public release notes but still written to `CHANGELOG.md`) are derived from the `internal` and `process` tiers (excluding `fmt`). Override via `changelogJson.devOnlySections`; matching is decorator-tolerant, so a bare-name override like `['Internal features']` keeps working against the emoji-prefixed default titles.
-
-## Maintaining the bundled taxonomy
-
-`src/workTypesData.ts` mirrors `src/work-types.json` for runtime use. Two maintainer scripts of the release-kit package compare that JSON with its codeassembly upstream and update it. They exist only in a checkout of this repository and are not part of the published `release-kit` CLI.
-
-- `nmr work-types:check` compares the content of `src/work-types.json` with the upstream, ignoring the local `$schema` hint.
-- `nmr work-types:sync` overwrites `src/work-types.json` with the upstream when their content differs.
-
-Both run from `packages/release-kit`, or from anywhere in the repository as `nmr -F @williamthorsen/release-kit work-types:check` and `nmr -F @williamthorsen/release-kit work-types:sync`. After `sync` writes the file, update `src/workTypesData.ts` to match; `workTypesData.unit.test.ts` fails until the two agree.
-
-`check` exits 0 on a match, 1 on drift, 2 when the upstream fetch fails, and 3 when either file is not valid JSON or the upstream fails the shape check. When the upstream URL returns 404, `check` exits 0 with a warning.
-
-### Authenticated fetches
-
-The upstream codeassembly repo is public, so `check` and `sync` need no token. When `GITHUB_TOKEN` is set in the environment, both scripts send it as `Authorization: Bearer <token>`.
+The default `devOnlySections` (excluded from public release notes but still written to `CHANGELOG.md`) are derived from the `internal` and `process` tiers (excluding `fmt`). Override via `changelogJson.devOnlySections`; matching is decorator-tolerant: A bare-name override like `['Internal features']` keeps working against the emoji-prefixed default titles.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@williamthorsen/release-kit",
-  "version": "12.0.0",
+  "version": "13.1.0",
   "description": "Version-bumping and changelog-generation toolkit for release workflows",
   "keywords": [
     "changelog",
@@ -50,7 +50,8 @@
     "schemas/**"
   ],
   "dependencies": {
-    "@williamthorsen/nmr-core": "0.13.0",
+    "@williamthorsen/change-grammar": "0.1.0",
+    "@williamthorsen/nmr-core": "0.13.1",
     "@williamthorsen/toolbelt.errors": "0.8.1",
     "json-stringify-pretty-compact": "4.0.0",
     "semver": "7.8.5",
@@ -62,8 +63,10 @@
     "@williamthorsen/toolbelt.filesystem": "0.9.1",
     "@williamthorsen/toolbelt.testing": "0.6.1",
     "@williamthorsen/toolbelt.vitest": "0.10.1",
+    "actionlint": "2.0.6",
+    "esbuild": "0.28.2",
     "readyup": "0.38.0",
-    "smol-toml": "1.8.0",
+    "smol-toml": "1.9.0",
     "vitest": "4.1.11"
   },
   "engines": {
@@ -75,8 +78,6 @@
   },
   "scripts": {
     "build:post": "rdy compile",
-    "build:pre": "rdy verify",
-    "work-types:check": "node scripts/check-work-types.ts",
-    "work-types:sync": "node scripts/sync-work-types.ts"
+    "build:pre": "rdy verify"
   }
 }

package/presets/labels/common.yaml

@@ -1,37 +1,17 @@
 # Common label definitions for GitHub repositories.
 # Compatible with EndBug/label-sync format.
+# Work-type labels are built from change-grammar's taxonomy in src/sync-labels/typeLabels.ts.
 
 # Main categories
-- name: ai
-  color: a2eeef
-  description: Guidance on working in this repo, such as its AGENTS.md or a repo-local skill, or its agent config
 - name: breaking
   color: b60205
   description: Breaking API change or removal of functionality
 - name: bug
   color: d73a4a
   description: "Something isn't working"
-- name: deprecation
-  color: fbca04
-  description: Marks functionality for future removal
-- name: documentation
-  color: a2eeef
-  description: Documentation for human readers, such as a README, a guide, or a code comment
-- name: feature
-  color: '0075ca'
-  description: Added or improved external functionality
-- name: fix
-  color: d73a4a
-  description: Fixes a bug
 - name: operational
   color: '000000'
   description: Actions outside the codebase
-- name: performance
-  color: '0075ca'
-  description: Improves performance without changing behavior
-- name: security
-  color: b60205
-  description: Security vulnerability or hardening
 - name: spike
   color: '000000'
   description: Investigation
@@ -47,26 +27,6 @@
   color: fbca04
   description: Further information is needed
 
-# Refactoring
-- name: ci
-  color: edc287
-  description: CI/CD tooling & configuration
-- name: dependencies
-  color: edc287
-  description: Change to dependencies
-- name: internal
-  color: 1d76db
-  description: Internal change without external impact
-- name: refactoring
-  color: edc287
-  description: Improvement to code without change in functionality
-- name: tests
-  color: edc287
-  description: Tests
-- name: tooling
-  color: edc287
-  description: Development tools
-
 # Priority
 - name: 'priority:critical'
   color: b60205

package/dist/esm/resolveReleaseNotesConfig.d.ts

@@ -1,26 +0,0 @@
-import type { OutputStyle } from '@williamthorsen/nmr-core';
-import type { ReleaseNotesConfig } from './types.js';
-export interface ResolvedReleaseNotesConfig {
-    releaseNotes: ReleaseNotesConfig;
-    changelogJsonOutputPath: string;
-    /** Section titles in priority order, derived from the merged workTypes record. */
-    sectionOrder: string[];
-}
-export interface ResolveReleaseNotesConfigOptions {
-    /** Config file to read, relative to the working directory. Defaults to `CONFIG_FILE_PATH`. */
-    configPath?: string;
-}
-/**
- * Loads and validates the release-kit config, resolving the release-notes settings it carries.
- *
- * An unusable config reports to stderr and calls `process.exit(1)`, whether the file failed to load or failed
- * validation, and whether it was named by the caller or the default one. Both callers are CLI commands whose
- * whole behavior depends on the resolved config, so neither could proceed on derived defaults without silently
- * dropping a configured `releaseNotes.shouldInjectIntoReadme`, `changelogJson.outputPath`, or `workTypes`.
- * An absent default config is a supported state and resolves to the defaults.
- */
-export declare function resolveReleaseNotesConfig(stderrStyle: OutputStyle, options?: ResolveReleaseNotesConfigOptions): Promise<ResolvedReleaseNotesConfig>;
-/** Extract section headers in declaration order from a merged workTypes record. */
-export declare function deriveSectionOrder(workTypes: Record<string, {
-    header: string;
-}>): string[];

package/dist/esm/resolveReleaseNotesConfig.js

@@ -1,29 +0,0 @@
-import { DEFAULT_CHANGELOG_JSON_CONFIG, DEFAULT_RELEASE_NOTES_CONFIG } from "./defaults.js";
-import { resolveWorkTypes } from "./loadConfig.js";
-import { loadValidatedConfig, reportConfigProblem, reportConfigWarnings } from "./loadValidatedConfig.js";
-export async function resolveReleaseNotesConfig(stderrStyle, options = {}) {
-    const result = await loadValidatedConfig(options.configPath);
-    if (result.status === 'invalid') {
-        reportConfigProblem(result.problem, stderrStyle);
-        process.exit(1);
-    }
-    if (result.status === 'missing') {
-        return {
-            releaseNotes: { ...DEFAULT_RELEASE_NOTES_CONFIG },
-            changelogJsonOutputPath: DEFAULT_CHANGELOG_JSON_CONFIG.outputPath,
-            sectionOrder: deriveSectionOrder(resolveWorkTypes()),
-        };
-    }
-    reportConfigWarnings(result.warnings, stderrStyle);
-    const { config } = result;
-    return {
-        releaseNotes: {
-            shouldInjectIntoReadme: config.releaseNotes?.shouldInjectIntoReadme ?? DEFAULT_RELEASE_NOTES_CONFIG.shouldInjectIntoReadme,
-        },
-        changelogJsonOutputPath: config.changelogJson?.outputPath ?? DEFAULT_CHANGELOG_JSON_CONFIG.outputPath,
-        sectionOrder: deriveSectionOrder(resolveWorkTypes(config.workTypes)),
-    };
-}
-export function deriveSectionOrder(workTypes) {
-    return Object.values(workTypes).map((entry) => entry.header);
-}

package/dist/esm/workTypesData.d.ts

@@ -1,50 +0,0 @@
-/**
- * Canonical work-types data: the runtime mirror of `work-types.json`.
- *
- * `work-types.json` is release-kit's copy of the codeassembly canonical. This `.ts` mirror exists for
- * runtime consumption: The compiler baseline does not enable JSON module imports, and a TS constant keeps
- * `breakingPolicy` typed as its three-value union.
- *
- * `nmr work-types:sync` updates only the JSON, so copy its change here by hand. A drift test
- * (`workTypesData.unit.test.ts`) asserts that this constant deep-equals the parsed contents of
- * `work-types.json`.
- */
-/** Schema for a single entry. */
-export interface WorkTypeEntry {
-    tier: string;
-    key: string;
-    aliases: string[];
-    emoji: string;
-    label: string;
-    description: string;
-    breakingPolicy: 'forbidden' | 'optional' | 'required';
-    excludedFromChangelog?: boolean;
-}
-/**
- * Schema for an orthogonal section marker (e.g., breaking-changes indicator).
- *
- * Stored as plain text — consumers add formatting (bold, prefix punctuation) when
- * constructing the rendered form. Keeps the SSOT format-agnostic across Markdown,
- * HTML, terminal, and plain-text consumers.
- */
-export interface MarkerEntry {
-    emoji: string;
-    label: string;
-}
-/** Schema for the full data. */
-export interface WorkTypesData {
-    /** Semantic version of the data shape, as declared by the upstream canonical. */
-    version: string;
-    tiers: string[];
-    types: WorkTypeEntry[];
-    /**
-     * Cross-cutting section markers keyed by marker name. The `breaking` marker is
-     * canonical and required; additional keys are permitted for forward-compatibility.
-     */
-    markers: {
-        [key: string]: MarkerEntry;
-        breaking: MarkerEntry;
-    };
-}
-/** Canonical work-types data, kept in lockstep with `work-types.json`. */
-export declare const WORK_TYPES_DATA: WorkTypesData;

package/dist/esm/workTypesData.js

@@ -1,145 +0,0 @@
-export const WORK_TYPES_DATA = {
-    version: '1.1.0',
-    tiers: ['public', 'internal', 'process'],
-    types: [
-        {
-            tier: 'public',
-            key: 'feat',
-            aliases: ['feature'],
-            emoji: '🎉',
-            label: 'Features',
-            description: 'A change that gives consumers a new capability or extends an existing one.',
-            breakingPolicy: 'optional',
-        },
-        {
-            tier: 'public',
-            key: 'drop',
-            aliases: [],
-            emoji: '🪦',
-            label: 'Removed',
-            description: 'A change that removes a capability or surface on which consumers depend.',
-            breakingPolicy: 'required',
-        },
-        {
-            tier: 'public',
-            key: 'deprecate',
-            aliases: [],
-            emoji: '🗑️',
-            label: 'Deprecated',
-            description: 'A change that marks a capability or surface for removal while the capability or surface keeps working.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'public',
-            key: 'fix',
-            aliases: ['bugfix'],
-            emoji: '🐛',
-            label: 'Bug fixes',
-            description: 'A change that corrects behavior that consumers meet and that differs from what was intended.',
-            breakingPolicy: 'optional',
-        },
-        {
-            tier: 'public',
-            key: 'sec',
-            aliases: ['security'],
-            emoji: '🔒',
-            label: 'Security',
-            description: 'A change that closes a vulnerability or hardens a consumer-facing surface against attack.',
-            breakingPolicy: 'optional',
-        },
-        {
-            tier: 'public',
-            key: 'perf',
-            aliases: ['performance'],
-            emoji: '⚡',
-            label: 'Performance',
-            description: 'A change that reduces the time, memory, or other resources that consumer-facing work uses, without changing its result.',
-            breakingPolicy: 'optional',
-        },
-        {
-            tier: 'internal',
-            key: 'internal',
-            aliases: ['utility'],
-            emoji: '🏗️',
-            label: 'Internal features',
-            description: 'A change that adds or extends a capability that consumers do not use directly, such as a helper or an internal module.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'internal',
-            key: 'refactor',
-            aliases: [],
-            emoji: '♻️',
-            label: 'Refactoring',
-            description: 'A change that restructures existing code without changing its behavior.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'internal',
-            key: 'tests',
-            aliases: ['test'],
-            emoji: '🧪',
-            label: 'Tests',
-            description: 'A change confined to tests, test fixtures, or test helpers, including one that unblocks a build or a type check.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'process',
-            key: 'tooling',
-            aliases: [],
-            emoji: '⚙️',
-            label: 'Tooling',
-            description: 'A change to the tools used to develop the project: build, lint, formatting, and release configuration, and development scripts.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'process',
-            key: 'ci',
-            aliases: [],
-            emoji: '👷',
-            label: 'CI',
-            description: 'A change to continuous-integration workflows and their configuration.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'process',
-            key: 'deps',
-            aliases: ['dep'],
-            emoji: '📦',
-            label: 'Dependencies',
-            description: 'A change that adds, removes, or upgrades a dependency, including its lockfile and version-catalog entries.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'process',
-            key: 'ai',
-            aliases: [],
-            emoji: '🤖',
-            label: 'Agentic support',
-            description: "A change to guidance on working in the repository itself, such as its `AGENTS.md` or a repo-local skill, or to the repository's agent configuration.",
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'process',
-            key: 'docs',
-            aliases: ['doc'],
-            emoji: '📚',
-            label: 'Documentation',
-            description: 'A change to documentation for human readers, such as a README, a guide, or a code comment.',
-            breakingPolicy: 'forbidden',
-        },
-        {
-            tier: 'process',
-            key: 'fmt',
-            aliases: [],
-            emoji: '🎨',
-            label: 'Formatting',
-            description: 'A change to formatting alone, such as whitespace or line wrapping, that leaves the content unchanged.',
-            breakingPolicy: 'forbidden',
-            excludedFromChangelog: true,
-        },
-    ],
-    markers: {
-        breaking: { emoji: '🚨', label: 'Breaking' },
-    },
-};

package/schemas/label-map.json

@@ -1,24 +0,0 @@
-{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "title": "label-map",
-  "description": "Maps commit-prefix scopes and types to GitHub label names. Consumed by agent skills, CI tooling, and any script that needs to translate commit conventions into label operations.",
-  "type": "object",
-  "required": ["types", "scopes"],
-  "additionalProperties": false,
-  "properties": {
-    "$schema": {
-      "type": "string",
-      "description": "JSON Schema reference for editor support."
-    },
-    "types": {
-      "type": "object",
-      "description": "Maps commit-type prefix (e.g., `feat`) to GitHub label name (e.g., `feature`).",
-      "additionalProperties": { "type": "string" }
-    },
-    "scopes": {
-      "type": "object",
-      "description": "Maps commit-scope prefix (e.g., `audit`) to GitHub label name (e.g., `scope:audit`).",
-      "additionalProperties": { "type": "string" }
-    }
-  }
-}