Problem
The v0.2.0 release exposed a stale supported-version entry in SECURITY.md. PR #7 adds a release checklist, but a small offline check would catch version drift earlier.
Scope
Add the minimum dependency-free verification needed to fail when public release metadata becomes inconsistent. Do not add a release framework or publishing automation.
Acceptance criteria
- verify that
package.json, the root entries in package-lock.json, pyproject.toml, and src/kg_debugger/__init__.py contain the same version
- verify that the current major/minor release line is represented consistently in the README project status and the supported row in
SECURITY.md
- keep issue-form version examples generic rather than coupling them to a concrete release
- integrate the check into an existing verification entry point such as
npm run lint or ./scripts/check.sh
- add focused regression coverage showing that a deliberate mismatch fails closed
- use only the existing Node.js/Python standard libraries and perform no network access
Verification
- run the focused metadata regression
- run
./scripts/check.sh
Problem
The
v0.2.0release exposed a stale supported-version entry inSECURITY.md. PR #7 adds a release checklist, but a small offline check would catch version drift earlier.Scope
Add the minimum dependency-free verification needed to fail when public release metadata becomes inconsistent. Do not add a release framework or publishing automation.
Acceptance criteria
package.json, the root entries inpackage-lock.json,pyproject.toml, andsrc/kg_debugger/__init__.pycontain the same versionSECURITY.mdnpm run lintor./scripts/check.shVerification
./scripts/check.sh