@codluv/versionguard 0.8.0 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -1,15 +1,15 @@
1
1
  # VersionGuard
2
2
 
3
- Strict version governance for TypeScript and Node.js projects.
3
+ Strict version governance for any project — SemVer and CalVer enforcement, language-agnostic manifest support, git hooks, changelog validation, file sync, and repo-wide version scanning.
4
4
 
5
- VersionGuard keeps `package.json`, changelog entries, git tags, and configured version references in sync so humans and LLM agents stop shipping messy release state.
5
+ VersionGuard keeps your manifest, changelog entries, git tags, and configured version references in sync so humans and LLM agents stop shipping messy release state.
6
6
 
7
7
  ## Why it exists
8
8
 
9
9
  Versioning breaks in the same places over and over:
10
10
 
11
- - versions get hardcoded across docs and source files
12
- - changelog entries are forgotten
11
+ - versions get hardcoded across docs, CI configs, and Dockerfiles
12
+ - changelog entries are forgotten or use wrong section names
13
13
  - tags drift from the package version
14
14
  - SemVer and CalVer rules get bent under pressure
15
15
  - agents take shortcuts and leave the repo in an invalid release state
@@ -18,58 +18,83 @@ VersionGuard turns those into enforceable checks with repair-oriented feedback.
18
18
 
19
19
  ## What it does
20
20
 
21
- - validates SemVer and CalVer formats strictly
22
- - keeps configured files synced from `package.json`
23
- - detects version mismatches in scanned files
24
- - validates Keep a Changelog structure and required release entries
25
- - installs git hooks for `pre-commit`, `pre-push`, and `post-tag`
21
+ - validates SemVer and CalVer formats with configurable rules
22
+ - keeps configured files synced from your manifest (package.json, Cargo.toml, pyproject.toml, etc.)
23
+ - scans the entire repo for stale version literals (`vg validate --scan`)
24
+ - validates Keep a Changelog structure with section enforcement
25
+ - installs cooperative git hooks for `pre-commit`, `pre-push`, and `post-tag`
26
26
  - provides CLI commands for validation, sync, bumps, and tagging
27
27
  - refuses unsafe tagging when hooks are required or the worktree is dirty
28
+ - built-in CKM help system for humans and LLM agents (`vg ckm`)
29
+
30
+ ## Where it runs
31
+
32
+ VersionGuard enforces at three points in the development lifecycle:
33
+
34
+ 1. **Local dev (git hooks):** `pre-commit` and `pre-push` hooks run `vg validate` automatically. This catches version drift, changelog issues, and sync mismatches before code leaves the developer's machine. This is the primary enforcement point.
35
+
36
+ 2. **CI (GitHub Actions):** `vg validate` runs as a build gate in CI. This catches anything the hooks missed (hooks can be skipped with `--no-verify`), validates on every PR, and ensures Dependabot PRs don't break version consistency.
37
+
38
+ 3. **CLI (developer workflow):** `vg check`, `vg fix`, `vg sync`, `vg tag`, `vg doctor` — manual commands that developers and agents use during the release flow.
39
+
40
+ ## Who needs it
41
+
42
+ - **Any project that ships versioned software** and wants to stop version-related drift: stale install commands in docs, missing changelog entries, hardcoded version strings in CI configs or Dockerfiles, tag/manifest mismatches
43
+ - **Teams using AI agents** that modify code — VG is the guardrail that catches when agents skip versioning steps
44
+ - **Polyglot projects** that need consistent version governance across npm, Rust, Python, Dart, PHP, Java, and more
28
45
 
29
46
  ## Install
30
47
 
31
48
  ```bash
32
- npm install -D @codluv/versionguard
33
- npx versionguard init
34
- npx versionguard hooks install
49
+ npm install -D @codluv/versionguard@latest
50
+ vg init
51
+ vg hooks install
35
52
  ```
36
53
 
54
+ > `vg` is a shorthand alias for `versionguard`. Both work identically.
55
+
37
56
  That gives you:
38
57
 
39
58
  - a `.versionguard.yml` config file
40
59
  - managed git hooks
41
- - a repo-local version policy built around `package.json`
60
+ - a repo-local version policy built around your manifest
42
61
 
43
62
  ## Quick start
44
63
 
45
64
  Run a basic version check:
46
65
 
47
66
  ```bash
48
- npx versionguard check
67
+ vg check
49
68
  ```
50
69
 
51
70
  Run full repository validation:
52
71
 
53
72
  ```bash
54
- npx versionguard validate
73
+ vg validate
74
+ ```
75
+
76
+ Scan entire repo for stale version literals:
77
+
78
+ ```bash
79
+ vg validate --scan
55
80
  ```
56
81
 
57
82
  For CI or agent workflows:
58
83
 
59
84
  ```bash
60
- npx versionguard validate --json
85
+ vg validate --json
61
86
  ```
62
87
 
63
- Sync configured files back to the package version:
88
+ Sync configured files back to the manifest version:
64
89
 
65
90
  ```bash
66
- npx versionguard sync
91
+ vg sync
67
92
  ```
68
93
 
69
94
  Repair common issues automatically:
70
95
 
71
96
  ```bash
72
- npx versionguard fix
97
+ vg fix
73
98
  ```
74
99
 
75
100
  ## Example output
@@ -100,18 +125,20 @@ How to fix:
100
125
 
101
126
  ## Configuration
102
127
 
103
- VersionGuard uses a single YAML config file.
128
+ VersionGuard uses a single YAML config file. Both `semver:` and `calver:` blocks are always present — change `type` to switch.
104
129
 
105
130
  Example:
106
131
 
107
132
  ```yaml
108
133
  versioning:
109
134
  type: semver
110
-
111
- # Enable this block when using calver
112
- # calver:
113
- # format: "YYYY.MM.PATCH"
114
- # preventFutureDates: true
135
+ semver:
136
+ allowVPrefix: false
137
+ allowBuildMetadata: true
138
+ requirePrerelease: false
139
+ calver:
140
+ format: "YYYY.MM.PATCH"
141
+ preventFutureDates: true
115
142
 
116
143
  sync:
117
144
  files:
@@ -128,6 +155,18 @@ changelog:
128
155
  file: "CHANGELOG.md"
129
156
  strict: true
130
157
  requireEntry: true
158
+ enforceStructure: false
159
+ sections:
160
+ - Added
161
+ - Changed
162
+ - Deprecated
163
+ - Removed
164
+ - Fixed
165
+ - Security
166
+
167
+ scan:
168
+ enabled: false
169
+ allowlist: []
131
170
 
132
171
  git:
133
172
  hooks:
@@ -147,39 +186,57 @@ ignore:
147
186
 
148
187
  ### SemVer
149
188
 
150
- VersionGuard supports strict semantic version validation with:
189
+ VersionGuard supports strict semantic version validation with configurable rules via the `semver:` block:
151
190
 
152
- - `MAJOR.MINOR.PATCH`
153
- - prerelease metadata such as `1.2.3-alpha.1`
154
- - build metadata such as `1.2.3+build.5`
191
+ - `MAJOR.MINOR.PATCH` with prerelease (`1.2.3-alpha.1`) and build metadata (`1.2.3+build.5`)
192
+ - `allowVPrefix` tolerate `v1.2.3` format (stripped before parsing)
193
+ - `allowBuildMetadata` permit or reject `+build` metadata suffix
194
+ - `requirePrerelease` — require prerelease labels on every version
195
+ - `schemeRules.allowedModifiers` — whitelist prerelease tags (e.g., `alpha`, `beta`, `rc`)
155
196
  - precedence comparison and increment helpers
156
197
 
157
198
  ### CalVer
158
199
 
159
- Supported formats currently include:
200
+ Composable token-based format strings supporting all calver.org tokens:
201
+
202
+ - Year: `YYYY`, `YY`, `0Y`
203
+ - Month: `MM`, `M`, `0M`
204
+ - Week: `WW`, `0W`
205
+ - Day: `DD`, `D`, `0D`
206
+ - Counter: `MICRO`, `PATCH`
207
+
208
+ CalVer validation can reject future-dated versions and enforce modifier allowlists.
209
+
210
+ ### Language-agnostic manifests
211
+
212
+ VersionGuard reads versions from any supported manifest:
160
213
 
161
- - `YYYY.MM.DD`
162
- - `YYYY.MM.PATCH`
163
- - `YY.M.PATCH`
164
- - `YYYY.0M.0D`
214
+ - `package.json` (Node.js), `Cargo.toml` (Rust), `pyproject.toml` (Python)
215
+ - `pubspec.yaml` (Dart/Flutter), `composer.json` (PHP), `pom.xml` (Java/Maven)
216
+ - `VERSION` (plain text), Git tags (Go/Swift), Custom regex patterns
165
217
 
166
- CalVer validation can reject future-dated versions when enabled.
218
+ Set `manifest.source: auto` for automatic detection.
167
219
 
168
220
  ## Commands
169
221
 
170
222
  | Command | Description |
171
223
  | --- | --- |
172
- | `versionguard init` | Create `.versionguard.yml` in the current project |
173
- | `versionguard check` | Validate the current version with actionable feedback |
174
- | `versionguard validate` | Run version, sync, and changelog validation |
175
- | `versionguard doctor` | Report repository readiness in one pass |
176
- | `versionguard fix` | Apply deterministic fixes for common drift |
177
- | `versionguard sync` | Update configured files to match `package.json` |
178
- | `versionguard bump` | Suggest the next version and optionally apply it |
179
- | `versionguard tag [version]` | Create an annotated release tag safely |
180
- | `versionguard hooks install` | Install managed git hooks |
181
- | `versionguard hooks uninstall` | Remove managed git hooks |
182
- | `versionguard hooks status` | Check whether hooks are installed |
224
+ | `vg init` | Create `.versionguard.yml` (interactive wizard or headless) |
225
+ | `vg check` | Validate the current version with actionable feedback |
226
+ | `vg validate` | Run version, sync, changelog, and optional scan validation |
227
+ | `vg validate --scan` | Include repo-wide stale version detection |
228
+ | `vg validate --strict` | Include guard checks for hook bypass detection |
229
+ | `vg doctor` | Report repository readiness in one pass |
230
+ | `vg fix` | Apply deterministic fixes for common drift |
231
+ | `vg fix-changelog` | Fix Changesets-mangled changelogs to Keep a Changelog format |
232
+ | `vg sync` | Update configured files to match manifest version |
233
+ | `vg bump` | Suggest the next version and optionally apply it |
234
+ | `vg tag [version]` | Create an annotated release tag safely |
235
+ | `vg hooks install` | Install managed git hooks |
236
+ | `vg hooks uninstall` | Remove managed git hooks |
237
+ | `vg hooks status` | Check whether hooks are installed |
238
+ | `vg ckm [topic]` | Codebase Knowledge Manifest — auto-generated help |
239
+ | `vg ckm [topic] --json` | Machine-readable CKM for LLM agents |
183
240
 
184
241
  ## Git hook behavior
185
242
 
@@ -196,13 +253,13 @@ When `git.enforceHooks` is enabled, release tagging also expects managed hooks t
196
253
  Use `doctor` when you want a one-pass readiness report before releasing:
197
254
 
198
255
  ```bash
199
- npx versionguard doctor
256
+ vg doctor
200
257
  ```
201
258
 
202
259
  For CI or agent workflows:
203
260
 
204
261
  ```bash
205
- npx versionguard doctor --json
262
+ vg doctor --json
206
263
  ```
207
264
 
208
265
  It reports:
@@ -219,7 +276,7 @@ It reports:
219
276
  Use `validate --json` when you need machine-readable validation output:
220
277
 
221
278
  ```bash
222
- npx versionguard validate --json
279
+ vg validate --json
223
280
  ```
224
281
 
225
282
  The JSON payload includes:
@@ -252,26 +309,26 @@ That keeps release tags from becoming a bypass around normal validation.
252
309
  ### Validate before committing
253
310
 
254
311
  ```bash
255
- npx versionguard validate
312
+ vg validate
256
313
  ```
257
314
 
258
315
  ### Repair drift after a manual version change
259
316
 
260
317
  ```bash
261
318
  npm version patch
262
- npx versionguard fix
319
+ vg fix
263
320
  ```
264
321
 
265
322
  ### Suggest and apply the next version
266
323
 
267
324
  ```bash
268
- npx versionguard bump --apply
325
+ vg bump --apply
269
326
  ```
270
327
 
271
328
  ### Create a release tag safely
272
329
 
273
330
  ```bash
274
- npx versionguard tag 1.2.3 -m "Release 1.2.3"
331
+ vg tag 1.2.3 -m "Release 1.2.3"
275
332
  ```
276
333
 
277
334
  ## Using with Changesets
@@ -281,10 +338,11 @@ VersionGuard and [Changesets](https://github.com/changesets/changesets) are comp
281
338
  | Concern | Changesets | VersionGuard |
282
339
  | --- | --- | --- |
283
340
  | Decide the next version | Yes | No (validates, doesn't choose) |
284
- | Update `package.json` version | Yes | No (reads it as source of truth) |
341
+ | Update manifest version | Yes | No (reads it as source of truth) |
285
342
  | Validate version format | No | Yes (SemVer/CalVer strictness) |
286
343
  | Sync version across files | No | Yes (regex-based sync) |
287
- | Validate changelog structure | No | Yes (Keep a Changelog) |
344
+ | Validate changelog structure | No | Yes (Keep a Changelog + section enforcement) |
345
+ | Scan repo for stale versions | No | Yes |
288
346
  | Git hooks enforcement | No | Yes |
289
347
  | Publish to npm | Yes | No |
290
348
 
@@ -300,7 +358,7 @@ npx changeset
300
358
  npx changeset version
301
359
 
302
360
  # 3. VersionGuard validates the new state
303
- npx versionguard validate
361
+ vg validate
304
362
 
305
363
  # 4. Publish
306
364
  npx changeset publish
@@ -312,7 +370,7 @@ In GitHub Actions, both tools run in sequence. Changesets creates a "Version Pac
312
370
 
313
371
  ```yaml
314
372
  - run: npm run build
315
- - run: npx versionguard validate
373
+ - run: vg validate
316
374
  - uses: changesets/action@v1
317
375
  with:
318
376
  publish: npx changeset publish --access public
@@ -368,6 +426,7 @@ npx vitest run src/__tests__/calver.test.ts -t "increments patch-based versions"
368
426
 
369
427
  - Product vision: `docs/VISION.md`
370
428
  - Verified feature ledger and roadmap: `docs/FEATURES.md`
429
+ - CKM module documentation: `src/ckm/README-CKM.md`
371
430
  - Agent guidance for contributors: `AGENTS.md`
372
431
 
373
432
  ## Forge