sem log, sem review, sem changelog

[antiartificial]

Hello team, I've been hacking on this a bit and wanted to surface this here for interest/input. I'm not sure which direction you're headed, seems there's some overlap with the typescript cli, but there's also divergence, both logs seem useful for different purposes.

TS sem log vs TS sem history vs Rust sem log --entity

┌────────────────────┬──────────────────────────────┬─────────────────────────────────────┬─────────────────────────────────────────┐
│                    │          TS sem log          │           TS sem history            │          Rust sem log --entity          │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ What it tracks     │ All changes across N commits │ One entity across N commits         │ One entity across all commits           │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Granularity        │ Commit-level summary         │ Entity-level timeline               │ Entity-level timeline                   │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Rename following   │ N/A                          │ No                                  │ Yes (--follow)                          │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Move detection     │ N/A                          │ No                                  │ Yes                                     │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Signature analysis │ No                           │ No                                  │ Yes (body vs signature change)          │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Entity resolution  │ N/A                          │ Manual file::name parsing           │ Auto-scan with ambiguity handling       │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Performance        │ Eager (loads N commits)      │ Eager, git show per commit per file │ Lazy callback, stops at entity creation │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ Depth              │ --count (default 5)          │ --depth (default 50)                │ Walks full history (or --from/--to)     │
├────────────────────┼──────────────────────────────┼─────────────────────────────────────┼─────────────────────────────────────────┤
│ DB storage         │ --store flag                 │ No                                  │ No                                      │
└────────────────────┴──────────────────────────────┴─────────────────────────────────────┴─────────────────────────────────────────┘

sem log

Track the full history of any function, class, or entity across your entire git history and follow it through renames and moves.

How has this function changed over time?

sem log --entity authenticateUser

    src/auth/login.ts :: function :: authenticateUser

    a1b2c3d  2024-01-15  alice         [added]              add auth module
    d4e5f6a  2024-02-01  bob           [modified]           update session handling
    e7f8a9b  2024-03-10  carol         [signature changed]  parameters changed
    f0a1b2c  2024-04-05  bob           [renamed]            was: authenticate
    c3d4e5f  2024-05-20  alice         [modified]           formatting only

    5 events — 3 authors — 2024-01-15 to 2024-05-20

Most git tools lose track of an entity when it gets renamed or moved to another file. sem log follows it backward through the history automatically, so you see the full story in one view.

It also distinguishes between a change to the function signature (parameters added, removed, return type changed) and a change to just the body. If someone only reformatted the code, it tells you that too.

If the name is ambiguous, sem tells you and suggests how to narrow it

  sem log --entity login
  error: 'login' is ambiguous. Did you mean one of:
     1. src/auth/login.ts :: function :: login
     2. src/api/routes.ts :: function :: login
     3. test/auth.test.ts :: function :: login
  
   Use --file <path> to disambiguate.

Scope to a specific file
sem log --entity login --file src/auth/login.ts

Limit to a commit range
sem log --entity login --from v1.0.0 --to v2.0.0

JSON output for scripts and AI agents
sem log --entity login --format json

---

sem review

Get a structured review of any set of changes, grouped by what matters: API surface changes that affect callers, internal implementation details, and
config/data changes.

sem review --from main --to HEAD

 ┌─ API Surface Changes ───────────────────────────────
 │  ⊕ function  validateToken          [added]
 │    0 dependents (new)
 │  ∆ function  authenticateUser       [signature changed]
 │    ~12 dependents across 4 files
 │  ⊖ function  legacyAuth             [deleted]
 │    ↳ was called by: loginHandler, refreshToken, adminAuth
 └──────────────────────────────────────────────────────

 ┌─ Internal Changes ──────────────────────────────────
 │  ∆ function  hashPassword           [body only]
 │  ⊕ function  buildSessionKey        [added]
 └──────────────────────────────────────────────────────

 ┌─ Config / Data Changes ─────────────────────────────
 │  ∆ property  production.pool_size   [5 → 20]
 └──────────────────────────────────────────────────────

 Summary: 3 API surface, 2 internal, 1 config
 Risk: high (breaking API change: deleted entity with dependents)

For each API surface change, it tells you how many other entities depend on it and which files they live in. If you delete something that was referenced
elsewhere, it flags exactly who was calling it. The risk assessment is based on the actual dependency graph, not heuristics.

Review staged changes before committing

sem review --staged

Review a specific commit

sem review --commit abc1234

JSON for CI integration

sem review --format json

---

sem changelog

Generate a changelog from a commit range, automatically categorized into breaking changes, additions, modifications, and removals, with a semver bump suggestion.

sem changelog --from v1.2.0 --to HEAD

Unreleased - 2099-06-15

Breaking Changes
  ! authenticateUser signature changed (parameters removed)

Added
  + function validateToken in src/auth/login.ts
  + function buildSessionKey in src/auth/session.ts

Changed
  ~ function hashPassword body modified in src/auth/crypto.ts

Removed
  - function legacyAuth deleted from src/auth/login.ts

Internal
  · 3 more internal changes

Suggested version bump: MAJOR (breaking API change: deleted entity with dependents)

It uses the dependency graph to determine whether a change is API-facing or internal, parses conventional commit messages when available, and suggests a
semver bump based on what actually changed in the code — not just the commit message.

Markdown output for release notes

sem changelog --from v1.0.0 --to v2.0.0 --format markdown --heading "v2.0.0"

Scoped to specific file types

sem changelog --from HEAD~10 --to HEAD --file-exts .ts .go

JSON for automation

sem changelog --format json

[rs545837]

Thanks a lot, I have a few thoughts in my mind will dump here soon.

[rs545837]

sem log: The Rust CLI already has sem blame which gives per-entity attribution, but it doesn't walk history the way your sem log --entity does. Rename following + signature vs body change detection are both things we want. Your implementation looks solid, especially the lazy callback approach that stops at entity creation.

sem review: We actually built this as a separate tool called inspect. It does entity-level triage with ConGra change classification, risk scoring based on the dependency graph (blast radius, dependents, public API surface), and groups changes into logical units using Union-Find. It's designed as a pre-filter for LLMs: cut 100 changed entities down to the 10 that matter, then let an LLM look at those. We benchmarked it against Greptile and CodeRabbit on 141 golden comments across 52 PRs, and it hits 95% recall. The approach here is similar in spirit (grouping by API surface vs internal, counting dependents for risk) but inspect goes further with the graph-based scoring and LLM integration.

sem changelog: This is a natural extension of sem review / sem diff. We haven't built it yet. The semver bump suggestion based on actual code changes (not just commit messages) is a nice touch.

On direction: sem's Rust rewrite is the foundation. sem-core is the library that weave, inspect all depend on for entity extraction, the dependency graph, and structural hashing. The CLI commands (sem diff, sem blame, sem graph, sem impact) are mostly there to make the library useful standalone. sem log and sem changelog fit naturally as CLI commands. sem review overlaps with inspect, but there's room for a lightweight version in sem that doesn't do the full triage pipeline.

Would be happy to work together on getting sem log and sem changelog merged. For the review piece, it might make more sense to point people at inspect for the full experience and keep sem review as a simpler summary.

[antiartificial]

Excellent, I'd be pleased to collaborate on enhancing the project with the features. I've been dogfooding the branch this week. I appreciate the thoughtful input.