[BUG-03] Version drift across 6 files — pyproject=7.2.0, utils.py=8.0.0, README=v8.2, SKILL.md=v8.1

[Wolfvin]

Summary

CodeLens version metadata is fragmented across 6 files with 4 different values: 7.2.0, 8.0.0, 8.1, 8.2. There is no single source of truth, and the release process documented in CONTRIBUTING.md (which instructs maintainers to bump version in utils.py, skill.json, and pyproject.toml) is clearly not being followed.

Evidence

Source	Value	Location
pyproject.toml	7.2.0	L7 version = "7.2.0"
skill.json	7.2.0	(top-level version field)
scripts/utils.py	8.0.0	L393 CODELENS_VERSION = "8.0.0"
README.md	v8.2	L1 # CodeLens v8.2 — AI-Native Code Intelligence
SKILL-QUICK.md	v8.2	L1 # CodeLens v8.2 — Quick Reference
SKILL.md	v8.1	L12 # CodeLens v8.1
CHANGELOG.md	[8.2.0] — Unreleased	L8 (latest released: [8.1.0] — 2026-06-13)

The actual unreleased version per CHANGELOG is 8.2.0, but:

• pyproject.toml / skill.json are stuck at 7.2.0 (two major versions behind).
• utils.py (the runtime CODELENS_VERSION constant used by codelens --version and the MCP server's serverInfo.version) is at 8.0.0.
• SKILL.md is at 8.1 (one minor behind).

Impact

1. MCP clients see wrong version: initialize response's serverInfo.version reads from utils.CODELENS_VERSION = "8.0.0", but the actual feature set (compact format, graph-schema, git-aware, architecture, hybrid-type-resolver) is 8.2.0-level. Clients that gate behavior on version will mis-route.
2. Packaging metadata lies: pip install codelens (if it ever ships to PyPI) would report 7.2.0 while the code is at 8.2.0.
3. CHANGELOG credibility: The [8.2.0] — Unreleased section advertises features that the version constants don't acknowledge.
4. Contributor confusion: New contributors can't tell which file is the source of truth.

Suggested fix

1. Single source of truth: Make scripts/utils.py:CODELENS_VERSION the only authoritative version. Update pyproject.toml and skill.json to read from it (e.g., via a build-time hook in pyproject.toml using dynamic = ["version"] + [tool.setuptools.dynamic] version = {attr = "utils.CODELENS_VERSION"}).
2. Bump to 8.2.0: Since CHANGELOG already has [8.2.0] features, set CODELENS_VERSION = "8.2.0" and release.
3. Strip hardcoded versions from docs: Replace # CodeLens v8.2 in README.md / SKILL-QUICK.md / SKILL.md with a placeholder that's regenerated from CODELENS_VERSION (or just remove the version from the H1 — readers can run codelens --version).
4. CI guard: Add a test that asserts pyproject.toml.version == skill.json.version == utils.CODELENS_VERSION, failing CI on any drift.

Files

• pyproject.toml (L7)
• skill.json
• scripts/utils.py (L393)
• README.md (L1)
• SKILL.md (L12)
• SKILL-QUICK.md (L1)
• CHANGELOG.md (L8)
• tests/test_version_consistency.py (new)

[Wolfvin]

Multi-worker analysis: direct duplicate confirmation

This version drift issue is directly confirmed by 2 worker reports that independently flagged it as a quick fix:

Worker	Source file	Quote
Semgrep	update!/CodeLens_Upgrade_Issues_from_Semgrep.md \u00a79.1 "Quick Fix"	"README claims v8.1, SKILL.md claims v7.2, SKILL-QUICK.md claims v7.2.0 \u2014 pick a single source of truth and sync all files." Listed as Quick Fix that must happen before larger issues.
OpenTaint	update!/CodeLens_vs_OpenTaint_Upgrade_Analysis.md D3	"Establish single source of truth for version at codelens/_version.py (or codelens/constants.py) with __version__ = "8.1.0". All files read from this source: pyproject.toml (dynamic version), skill.json (remove version field, read at build), README.md badge, SKILL.md, mcp_server.py MCP_SERVER_VERSION." Identified as quick win (3 days, no dependency).

Recommendation

Both workers agree on the fix proposed in this issue: single source of truth at codelens/_version.py (or scripts/utils.py:CODELENS_VERSION), with pyproject.toml using dynamic = ["version"] and CI check failing on drift.

OpenTaint D3 also notes the additional wrinkle that pyproject.toml lines 65-67 currently explicitly state "Entry point removed \u2014 codelens is run directly via python3 codelens.py. The scripts/ directory uses sys.path-based imports, not a proper Python package." — so the version-source-of-truth fix may need to wait for or be paired with the package-refactor work (OpenTaint D2 / RepoAudit CL-041 memory refactor).

Marking this issue as ready to implement — both workers consider it P1 quick win (3 days).

Aggregated from update!/ worker analysis reports by multi-worker triage.