chore(native): decouple collector version from managed + versioning docs/rules

[lotgon]

What

Per the agreed model — one independent version per product (C++ collector / C# collector / server / agent) — decouple the native collector's reported version from the managed collector.

• Code: remove HSM_COLLECTOR_PRODUCT_VERSION (the pinned copy of the managed 3.4.12). The native collector now reports its own version as the .module/Collector version sensor, via a new HSM_COLLECTOR_VERSION_STRING (MAJOR.MINOR.PATCH, built from the existing version macros). Bump the collector 0.6.0 → 0.6.1 (PATCH — the log-quality fix fix(collector): log quality — relabel runtime registrations, HTTP code, quiet stop-drop #1225 owed one) and sync CMakeLists.txt.
• Rule: rewrite src/native/collector/AGENTS.md — one standalone collector version; add the PATCH clause (a behavior/logic change with no ABI change); drop the "pinned to managed" section.
• Doc: aicontext/features/core/versioning/feature.md — the four independent versions and when to bump each.

Effect

.module/Collector version from a native collector now shows its own version (0.x) instead of the managed 3.4.12. C# collectors still report their own 3.4.x. The two are separate products and may diverge.

Conformance

Safe for PR CI: the corpus golden captures only the collector_version registration (path/description are _ wildcards); the version value is not compared, and 3.4.12 appears nowhere in the corpus.

Nightly watch: the diff-fuzzer does a direct C#-vs-native byte-compare. If it emits the collector-version sensor value, that value now legitimately differs (3.4.x vs 0.x) and should be excluded from the comparison (build-specific, not portable behavior). It is not a PR-CI lane.

🤖 Generated with Claude Code

[github-actions]

PR #1228 Review — docs/versioning-feature

Scope: This PR adds a single documentation file, aicontext/features/core/versioning/feature.md (+43 lines). No code changes, so there is no runtime, security, or performance surface to review. The review focuses on factual accuracy of the documented facts and on consistency with the surrounding docs conventions — which is where a canonical map doc either earns or loses its value.

Verification — every documented fact checks out ✅

I cross-checked each claim against the actual sources. All paths, symbol names, and version numbers are accurate as of this branch:

Doc claim	Verified in source
Agent version → project(HsmAgent VERSION …) / HSM_AGENT_VERSION	src/agent/CMakeLists.txt:21,120 (0.5.26) ✅
Collector library semver → HSM_COLLECTOR_VERSION_{MAJOR,MINOR,PATCH}	src/native/collector/include/hsm_collector/hsm_collector.h:16-20 (0.6.0) ✅
Mirror in CMakeLists.txt project VERSION	src/native/collector/CMakeLists.txt:7 (VERSION 0.6.0) ✅
Feeds find_package(hsm_collector x.y) + hsm_collector_version()	CMakeLists.txt:6-7, header :239 (int32_t hsm_collector_version(void)) ✅
Product version native HSM_COLLECTOR_PRODUCT_VERSION	hsm_collector.h:27 ("3.4.12") ✅
Product version managed .csproj <Version>	src/collector/HSMDataCollector/HSMDataCollector.csproj:9 (3.4.12) — matches native in lockstep ✅
.module/Collector version sensor	src/native/collector/src/hsm_collector.cpp:1378,7036 ✅
Shared API DTO .csproj	src/api/HSMSensorDataObjects/HSMSensorDataObjects.csproj:6 (3.1.12) ✅
Server .csproj	src/server/HSMServer/HSMServer.csproj:8 (3.40.33) ✅
Self-update = "strictly greater" delivery key	src/agent/AGENTS.md:19-20 (semver major→minor→patch compare in src/update_checker.cpp) ✅
Bump-rule pointers (agent / native AGENTS.md, root AGENTS.md "Versioning")	src/agent/AGENTS.md, src/native/collector/AGENTS.md, root AGENTS.md:107 all exist ✅

The "don't conflate the two collector numbers" section (library 0.x ABI vs. product 3.4.x release identity) is correct and is a genuinely useful clarification — these two numbers are easy to mix up.

Minor observations (non-blocking)

1. Not discoverable from the index. aicontext/README.md's "Directory Structure" table lists features/collector|server|storage|site|api|integrations but has no entry for features/core/, and this new doc isn't linked from the README or any parent index. A reader following the documented "Start Here" path won't find it. Consider adding a features/core/ row (or a "Versioning" pointer) to aicontext/README.md. Note this is a pre-existing gap — features/core/ and features/agent/ already sit outside the README table — but this PR is a natural moment to close it.

2. "conformance compares them byte-identically" is slightly stronger than the evidence. The byte-identical native/managed product-version rule is a maintenance instruction in src/native/collector/AGENTS.md:28 ("Keep it byte-identical to the managed collector"). The conformance harness (hsm_collector_tests.cpp) runs a shared .hsmtest corpus against both ports for behavior parity; I didn't find a check that asserts the two version strings are literally byte-equal. If such an assertion exists, a file/line pointer would strengthen the claim; otherwise consider softening to "kept in lockstep by convention" to avoid implying an automated guard that isn't there.

3. Template sections omitted (fine). The doc uses only the header + a couple of sections from features/_TEMPLATE_feature.md (no Invariants / Workflows / Tests). That's appropriate for a cross-cutting map doc rather than a component feature, so no change needed — just noting it's intentional divergence.

Verdict

Accurate, well-scoped, and useful — it consolidates version facts that are otherwise scattered across five build files and three AGENTS.md files, and every fact I checked is correct. The only actionable item is wiring it into the aicontext/README.md index (obs. 1) so it's actually discoverable; the byte-identical phrasing (obs. 2) is a nice-to-tighten. Approve.

[github-actions]

PR #1228 Review — docs/versioning-feature

Mostly a documentation change plus a small, well-scoped native-collector code change: the C++ collector now reports its own version (HSM_COLLECTOR_VERSION_STRING, 0.6.1) as the .module/Collector version sensor instead of a pinned copy of the managed collector's product version (HSM_COLLECTOR_PRODUCT_VERSION = "3.4.12"), and the macro is removed.

Overall this is clean and internally consistent. The HSM_COLLECTOR_VERSION_STRING two-level stringify idiom is correct (STRINGIFY → STRINGIFY_ indirection expands the macro before #), the unit test was updated to assert on the new symbol, and the conformance golden captures only the registration of the sensor (the value is wildcarded), so PR-lane CI is unaffected — as the PR description states. I verified there is no server-side logic that parses or compares .module/Collector version (grep of src/server is empty), so the value change is functionally safe on the server.

A few points below, none blocking.

---

1. Stale comment references the removed macro — src/agent/src/agent_runtime.cpp:237-241

// NOTE: do NOT override ".module/Collector version" with the agent's version — the
// collector is a separate product (HSMDataCollector line, reported via
// HSM_COLLECTOR_PRODUCT_VERSION) from this agent (HSM_AGENT_VERSION). ...

This is the only remaining reference to HSM_COLLECTOR_PRODUCT_VERSION in the tree, and it also still describes the old "HSMDataCollector line" shared-product model that this PR abolishes. It's a comment so it won't break the build, but it now contradicts the new independent-version model documented in feature.md and AGENTS.md. Please update it to say the collector reports its own version (HSM_COLLECTOR_VERSION_STRING) as a distinct product.

2. Removing the public HSM_COLLECTOR_PRODUCT_VERSION macro is source-breaking, shipped as PATCH

HSM_COLLECTOR_PRODUCT_VERSION lived in the public header include/hsm_collector/hsm_collector.h. Any external consumer that referenced it will now fail to compile. The PR bumps only PATCH (0.6.0 → 0.6.1), but per this collector's own semver rule (documented in the same AGENTS.md: MAJOR = breaking) and root AGENTS.md rule #2 ("no breaking changes without major version bump"), removing a previously-exported public symbol is arguably more than a PATCH. This is a judgment call — the symbol is a compile-time macro rather than true ABI, and it was only recently introduced, so real-world impact is probably nil. Worth a conscious decision rather than an implicit one; at minimum consider noting the removal in the header/changelog.

3. feature.md says "four independent versions" but the repo tracks five

The rewrite (commit 2) reframes to "HSM carries four independent version numbers, one per product" and lists: native collector, managed collector, server, agent. But the Shared API DTO package (src/api/HSMSensorDataObjects/HSMSensorDataObjects.csproj) is an independently-versioned artifact — it was listed in the commit-1 draft and is still tracked in root AGENTS.md (line 111). Dropping it makes the "four … one per product" count inaccurate. Either re-add the API DTO version to the table, or soften the framing so the definite count isn't wrong.

4. Reported collector version regresses 3.4.12 → 0.6.1 (awareness, low)

For existing deployments the .module/Collector version sensor value now goes backwards. Confirmed harmless server-side (no ordering/comparison logic keys on it — it's a displayed Version sensor), but operators looking at sensor history/dashboards will see the number drop. This is a documented, intentional design decision, and the PR already flags the follow-on for the nightly diff-fuzzer (direct C#-vs-native byte compare) — please do watch that lane, since it emits the value, not just the registration.

---

Positives

• Macro stringification is correct and the 0.6.1 PATCH bump matches the stated log-quality fix (fix(collector): log quality — relabel runtime registrations, HTTP code, quiet stop-drop #1225).
• Test (hsm_collector_tests.cpp:4098) correctly switched to HSM_COLLECTOR_VERSION_STRING; Contains is a throwing assertion so the check is real.
• Docs (feature.md, AGENTS.md) and code comments are consistent with each other for the new model — the one exception is the agent comment in finding Change the protocol in the project to GRPC #1.

Nice, well-reasoned change. Addressing #1 (stale comment) and #3 (version count) before merge would keep the docs self-consistent.