Feature/sem review

[antiartificial]

Adds a few new features:

sem review and sem log work with historical state whereas sem graph and sem impact work with current state. Signature change detection (new capability, powers the [signature changed] / [body only] labels in review and changelog).

• sem log full history of any function (entity), following it through renames and moves across commits
• sem changelog auto-categorized release notes from a commit range with a suggested semver bump
• sem review groups changes by impact (API surface, internal, config) with dependency counts and a risk assessment

Other items in this PR:

• This includes a slight fix to the version string handling, previously this was hardcoded and could become stale, now reflects what's in the Cargo.toml.
• Test coverage for all three new modules (19 new tests)
• README updated with documentation for the new commands

Example usage/output

sem review --from HEAD~2 --to HEAD # last two commits

  ┌─ Internal Changes ──────────────────────────────────
  │  ∆ function   getSupportedMimeType      [modified]
  │  ∆ variable   types                     [modified]
  └───────────────────────────────────────────────────────

  Summary: 2 internal
  Risk: low (internal/config changes only, no public API impact)

Example usages:
sem log --entity authenticateUser # finds all references to entity (ex. a function)
sem log --entity login --file src/auth.ts # constrains search to specific file

Example output:

>sem log --entity getSupportedMimeType                                                                                                              (base)

  prism-web/src/lib/audio.ts :: function :: getSupportedMimeType

  349f65f  2026-02-18  Aaron Barton  [modified]       Fix Brave misdetected as Safari: prefer webm over mp4 MIME type
  45b819f  2026-02-06  antiartifici  [added]          Add Prism: voice-driven Socratic interview simulator

Example usages:
sem changelog --from v1.2.0 --to HEAD # ex changes spanning a tag range (or commits)
sem changelog --from v1.0.0 --to v2.0.0 --format markdown

Example output:

sem changelog --from HEAD~1 --to HEAD                                                                                                              (base)

## Unreleased — 2026-03-08

### Internal
  · `getSupportedMimeType` — function modified in prism-web/src/lib/audio.ts
  · `types` — variable modified in prism-web/src/lib/audio.ts

Suggested version bump: PATCH (no new public API, no breaking changes)

[rs545837]

Thanks I will take a look at this asap.

[rs545837]

Replied on the discussion with more context on how this relates to inspect and the broader roadmap. The sem log and sem changelog modules look good and fill real gaps in the CLI. sem review overlaps significantly with inspect which does entity-level triage with graph-based risk scoring and LLM integration.

Going to review the code in detail. Main things I want to check: how the signature detection interacts with sem-core's existing structural_hash (which already distinguishes cosmetic vs structural changes), and whether the log module's git history walking could live in sem-core as a library function so inspect and weave can use it too.

[Palanikannan1437]

Great feature set — review, changelog, and log are solid additions. Left some inline comments. The two I'd want addressed before merge are the signature breaking classification (return type changes + language-aware param handling) and the entity name collision in log history tracking. The rest are suggestions for follow-ups.

Also we could discuss more on what should stay here vs in inspect as @rs545837 mentioned above

[Palanikannan1437]

I think ReturnTypeChanged should be in here too — changing a return type will break every caller that depends on the old type. Right now it silently gets classified as non-breaking, which means changelog/semver will miss real breakage.

[Palanikannan1437]

Nice API — the lazy callback with early-stop is a good design for entity log. One thing to consider for later: the callback receives CommitInfo with sha as a String, but callers like build_entity_log immediately re-resolve that SHA back into trees via resolve_tree. Passing richer data (or at least the Oid + parent) would avoid that round-trip.

[antiartificial]

I'll have more time to digest and reflect this evening, thank you for your eyes and input.

[Palanikannan1437]

Hey @antiartificial did you get some time to check them out?

[antiartificial]

I've had some guests from out of town. Catching up!

[antiartificial]

Replied on the discussion with more context on how this relates to inspect and the broader roadmap. The sem log and sem changelog modules look good and fill real gaps in the CLI. sem review overlaps significantly with inspect which does entity-level triage with graph-based risk scoring and LLM integration.

Going to review the code in detail. Main things I want to check: how the signature detection interacts with sem-core's existing structural_hash (which already distinguishes cosmetic vs structural changes), and whether the log module's git history walking could live in sem-core as a library function so inspect and weave can use it too.

Thank you, the idea with sem review was to offer an offline first no LLM, would you be interested in merging the logic here, keeping sem review as the offline baseline?

the structural_hash and analyze_signature_change operate independently, I feel they compliment one another but don't coordinate. build_entity_log already uses both for formatting only plus signature analysis for the detail.

structural_hash ast level answers "did anything meaningful change, or was it just formatting or comments?" acts as a fast pre-filter.
analyze_signature_change function signature only (params and return type) answers "how exactly did the signature change? is it breaking"

sem review uses structural_change to label things "cosmetic" but doesn't run signature analysis so a review will show a parameter removal as just "modified" and it won't say "parameter removed (breaking). The changelog and log commands do run signature analysis. if inspect wants breaking code change detection in its triage:

1. call the analyze_signature_change function directly
2. use the changeling/log output which includes signature details

structural_hash is the "did anything real change" gate and signature analysis is the "what exactly changed in the API contract"

As far as some of the feedback: targeted single-entity parsing instead of computing a full semantic diff for all changed files in a commit parse only the tracked file and compare only the tracked entity and shared "analyzed change" structure when calling build_review and reclassifying everything into changelog categories and using an intermedia structure. I'm happy to tackle these in this effort if you don't mind it, or happy to do a follow up PR for each.

[rs545837]

Hey @antiartificial, sorry for the slow reply!

Took another look and the signature classification and entity disambiguation are both handled nicely, good work on those.

Here's what I'd like to do: let's merge sem log and sem changelog from this PR, but leave out sem review for now since it overlaps with inspect and I want to think through the right boundary there.

Could you split out the sem review parts so we can merge the rest? Once that's done this is good to go.

[antiartificial]

@rs545837 no problem, we are all busy, certainly I can proceed with sem log and changelog sans review.

[rs545837]

Awesome sounds great.

[inspect-review]

inspect review

Triage: 175 entities analyzed | 0 critical, 0 high, 68 medium, 107 low
Verdict: standard_review

Findings (1)

1. [low] analyze_signature_change misclassifies return-type additions/removals as BodyOnly: when before_params == after_params and before_ret != after_ret, it only returns ReturnTypeChanged if both are Some. If one side is None (return type added/removed), it falls through to SignatureChangeKind::BodyOnly, which is incorrect.
   Evidence (crates/sem-core/src/parser/signature.rs):

if before_params == after_params {
    if before_ret != after_ret {
        if let (Some(br), Some(ar)) = (before_ret, after_ret) {
            return SignatureChangeKind::ReturnTypeChanged { before: br, after: ar };
        }
    }
    return SignatureChangeKind::BodyOnly;
}

---

Reviewed by inspect | Entity-level triage found 0 high-risk changes