chat-arch, the local-first viewer and indexer for Claude transcripts I’ve been building, already unifies sessions from claude.ai, Cowork, and Claude Code CLI into one place. Search, cost analytics, duplicate detection, and a zombie-project view all work today, against your own corpus, in your own browser. But it exposed a problem: the viewer organizes sessions by where they came from (app, project folder, session file), not by what I was actually working on.
Real projects don’t respect those boundaries. ShopForge development lives across standalone chats, Projects, Cowork sessions, and CLI sessions. The “project” in my head isn’t the “Project” in Claude.
Site Survey
Semantic project discovery across all sources. A new view called Site Survey will read the archive and identify the work-streams running through it, regardless of where each session happened.
The design:
- Embed per-session summaries with bge-small, the local model chat-arch already runs in-browser, so nothing leaves the machine.
- Cluster with HDBSCAN, using session date alongside source context (project folder, tool calls, file paths) as metadata features. Whether this is enough to disentangle concurrent projects with shared vocabulary is the open question the fixture is designed to answer.
- Label each cluster with one LLM pass. The real compute budget is upstream: generating a summary for each session before embedding, roughly one call per session. That call can run locally (smaller model, slower) or via API (better summaries, content leaves the machine). Cluster labeling adds negligible cost compared to embedding.
- Treat corrections as first-class. Labels attach to session IDs and survive re-clustering. Conflicts surface for review rather than getting silently overwritten.
- Render a per-project timeline with source icons so the real chronology is visible across tools.
The acceptance test: can I point at the timeline and recognize the work I actually did this year, including the parts that surprise me?
Why the memory layer isn’t enough
Anthropic’s memory handles continuity inside their ecosystem. It does not pull together work that crosses tools or cluster standalone chats into coherent work-streams. If you use more than one Claude surface, your work-streams are invisible to the memory layer.
For me that’s ~300 Cowork sessions, a full Claude Code CLI history, and everything on claude.ai. Without unification, I can’t actually see what I’ve been working on. If you’re on more than one surface, the same gap applies.
Deferred, on purpose
Three capabilities Site Survey unlocks, deferred until the clustering is solid:
- Provenance chains. Trace any decision (an API choice, a product name, an architecture pattern) from first mention to current form. The timeline surfaces when each concept first appeared; what it doesn’t yet do is render the evolution between mentions.
- Midden mining. Systematic review of abandoned or looping sessions, the archaeological refuse heaps where the real signal about how you work hides. A distraction from Site Survey, but a natural follow-up.
- Narrative synthesis. Project stories with characters, conflicts, resolutions. Follow-up post material.
All three get cheaper once Site Survey is solid.
Highest-risk components, built first
Two failure modes rank highest. First, whether per-session summaries capture project identity rather than just session topic. If summaries describe activity, HDBSCAN will cluster by topic, not by project. Second, whether concurrent projects with shared vocabulary can be separated at all. If vocabulary overlap defeats the metadata features, the clusters won’t match real work-streams.
So before building UI, I’ll build a test fixture, starting from zero: at least 60 sessions across at least 4 projects, with at least two project pairs running concurrently and sharing vocabulary. Enough to stress the failure mode the approach most needs to survive. Kill the plan cheap if the plan won’t work.
Site Survey will be the test. If the timeline shows me only what I already remember, the feature isn’t worth shipping.