My calendar tracked my meetings. Nothing tracked the other 6 hours. So I built something that does.

Hal Hunt — Tue, 28 Apr 2026 14:00:00 +0000

I have been writing software for 25 years and managing engineering teams for 6. I know how to build things. What I could never figure out was how to remember everything I built, reviewed, commented on, or responded to on any given day.

My calendar tracked meetings fine. Everything else just disappeared.

PR reviews. Jira comments. Ad hoc asks from leadership. One-off conversations that turned into two hours of unplanned architecture work. Performance review prep. By Friday I could barely reconstruct Tuesday. I eventually started keeping a running Google Doc of everything I touched each day. It was exactly as tedious as it sounds, and I stopped maintaining it within a week every single time I tried.

I looked for a tool that solved this. I could not find one I was willing to actually use. Everything fell into one of four buckets:

Time trackers that required manual start/stop timers
Task managers that needed you to log work before you did it
Meeting tools that only cared about your calendar
Desktop "monitoring" agents that tracked everything you did on your machine

That last category was a hard no. I'm not installing surveillance software on my PC to remember what I worked on.

So I built something myself. This post is about what I built, the technical decisions I made, and what I learned.

What It Does

Worktrace connects to the tools you already use, observes activity metadata, and builds a chronological daily work log for you to review.

The key word is metadata. It never reads document bodies, PR diffs, calendar descriptions, or source code. It reads things like: event titles, timestamps, file names, issue status transitions, PR state changes. The signals you already generate just by doing your job.

At the end of the day (or whenever you want), you open the app, see what it surfaced, confirm what counts, edit anything that's wrong, and move on. The whole review takes a couple of minutes.

No timers. No manual entry. No agents on your machine.

The 8 Integrations

The supported providers right now:

Provider	What Gets Captured
Google Calendar	Event titles, start/end times, organizer, recurring status
Microsoft Calendar	Event titles, start/end times, organizer (via Graph API)
Google Drive	File name, last modified time, file type
Microsoft OneDrive	File name, last modified time (via Graph API)
GitHub	PRs opened/merged/closed/reviewed, commits, issues
Jira	Issues, worklogs, status transitions, comments
Azure DevOps	Work items, PRs, commits
Bitbucket Cloud	PRs, commits, issues

Everything is read-only. Nothing is ever written back.

Architecture: Clean, Intentionally Boring

The stack is .NET 10 with an ASP.NET Minimal APIs backend and an Angular 21 frontend. The architecture follows Clean Architecture strictly, enforced structurally:

Domain
  |
Application
  |
Infrastructure
  |
API
  |
Frontend

Dependencies only point inward. No exceptions.

The Domain layer (Hyprsoft.Worktrace.Domain) has zero framework dependencies. It compiles if ASP.NET, EF Core, and Azure do not exist. I treat this as a test: if a decision makes the Domain aware of the outside world, the decision is wrong.

The Application layer uses CQRS via MediatR. Commands and queries are thin orchestrators. The interesting business logic lives in the Domain. Infrastructure is EF Core over SQL Server.

Each integration is its own project. Hyprsoft.Worktrace.Integrations.GitHub, Hyprsoft.Worktrace.Integrations.Jira, and so on. They all implement the same interface:

public interface IIntegrationWorker
{
    IntegrationProvider Provider { get; }
    Task AuthenticateAsync(UserContext user, CancellationToken ct = default);
    Task<IEnumerable<ActivityEvent>> FetchActivityAsync(
        UserContext user,
        DateTimeOffset since,
        CancellationToken ct = default);
}

The Core API never calls a third-party API. The workers do. This keeps the API clean and keeps failure contained per integration. If GitHub is down, only GitHub stops working.

The Part I Found Most Interesting: The Inference Engine

Raw activity events are not useful on their own. On a normal day you might have 40 or 50 of them across all your tools. What you actually want is a meaningful, grouped summary.

The inference engine takes those raw events and produces WorkEntry suggestions. This is where most of the interesting logic lives.

Why No LLMs?

I want every suggestion to be traceable to specific evidence. I want users to understand why they got a suggestion. I want the system to be predictable. LLMs don't always produce perfect for all three of these use cases all the time.

The engine is deterministic and rules-based. Every confidence score is explained, not opaque.

The Pipeline

ActivityEvents
   |
   v
Context Extraction (per provider)
   |
   v
Sort by OccurredAt
   |
   v
Phase 1: Attach new events to existing calendar-based entries
   |
   v
Phase 2: Calendar events -> one WorkEntry each
   |
   v
Phase 3: Cluster remaining non-calendar events
   |
   v
Confidence Scoring
   |
   v
WorkEntry Suggestions

Context Extraction

Before grouping, every event goes through a provider-specific IActivityContextExtractor. This normalizes events into a provider-agnostic ActivityContext:

public sealed record ActivityContext
{
    public string? ProjectIdentifier { get; init; }
    public IReadOnlyList<string> SecondaryIdentifiers { get; init; } = [];
    public string CleanedTitle { get; init; } = string.Empty;
    public IReadOnlyDictionary<string, string> CorrelationHints { get; init; }
}

ProjectIdentifier is the primary grouping key (repo name, Jira project key)
SecondaryIdentifiers are exact correlation keys (Jira issue key like WT-43, PR number)
CleanedTitle strips provider prefixes for fuzzy matching
CorrelationHints carries pattern learning signals

Similarity Scoring

The engine uses a multi-tier similarity system to decide if two events are related:

1. Exact secondary identifier match (e.g., "WT-43" in both)  -> 1.0
2. Exact project identifier match (same repo name)            -> 0.8
3. FuzzySharp TokenSetRatio >= 60 on CleanedTitle             -> score/100
4. Same organization in correlation hints                     -> 0.3
5. No match                                                   -> 0.0

Minimum threshold is 0.6. Anything below that is not considered related.

I use FuzzySharp (a .NET port of RapidFuzz) for the fuzzy title matching. TokenSetRatio handles word order differences and extra words well, which matters when you're comparing "Sprint Planning - Platform Team" against "WT-43: Platform sprint items."

Calendar Events as Anchors

Calendar events are the primary time anchors. Each calendar event becomes its own WorkEntry. Non-calendar events that occurred during a meeting's time window and have sufficient similarity get attached to that entry.

The engine does a transitive grouping pass for this. If PullRequestReviewed didn't directly match the calendar event's context, but it matches another already-attached event (say, because they both reference WT-43), it gets pulled in transitively. This handles the case where a meeting is called "Sprint Planning" but all the work items discussed are WT-43, WT-44, etc.

Non-Calendar Clustering

Events that don't attach to any calendar entry get clustered in three steps:

Group by project. Events with the same ProjectIdentifier go in the same bucket.
Time-proximity clustering. Within a project group, events are ordered by time. If the gap between consecutive events exceeds 60 minutes, a new cluster starts.
Cross-cluster merging. Clusters are merged if they share secondary identifiers or have fuzzy title similarity and are within 60 minutes of each other. I use Union-Find for transitive merging here.

Confidence Scoring

Confidence is evidence-based, not probabilistic. The score is built from factors:

Factor	Score Impact
Base	+0.5
Calendar provider as primary event	+0.3
Multiple events from different providers	+0.2
Multiple events from same provider	+0.1 per event (max 3)
Explicit duration on primary event	+0.1
Pattern-based adjustment	-0.2 to +0.2

Scores map to High (>0.85), Medium (0.60-0.85), or Low (<0.60). The numeric score never surfaces in the UI. Users see the level, not the number.

Learning from Feedback

When a user accepts, rejects, edits, or splits an entry, the engine records it against UserInferencePattern entities keyed by a multi-granularity pattern signature.

Pattern keys are extracted at several levels:

Provider + title: gcalendar:title:standup
Provider + event type: github:eventtype:pullrequestreviewed
Provider + project: github:owner/repo
Pattern hints from context: jira:issuetype:bug
Cross-provider: cross:github+jira

Over time, accept/reject rates shift confidence scores up or down, and duration edit history influences the engine's duration estimates. The adjustment is clamped to ±0.2 confidence and ±30-60 minutes on duration.

No model training. No retraining loop. Just incrementing counters and doing math.

Privacy by Architecture

The metadata-only constraint is not a policy. It's enforced structurally.

Integration mappers only extract metadata fields. The ActivityEvent.Create() factory method validates and normalizes inputs. Title normalization collapses whitespace. URLs are validated as absolute HTTP/HTTPS only. The EventMetadata value object is a controlled key-value store with no free-text content fields.

OAuth tokens are encrypted at rest. They are never exposed to the frontend. Each user has their own tokens per provider. There are no shared credentials.

I understand that for a lot of engineers, especially those at larger companies, connecting any third-party tool to code repositories or project trackers is not a personal decision. IT security teams have to sign off, compliance reviews happen, and "trust me, it only reads metadata" is not going to cut it. That is completely reasonable.

I put together a detailed 21-page privacy and security whitepaper that covers exactly what data is accessed, how OAuth tokens are stored and encrypted, data isolation guarantees, retention policies, and the full threat model. If you need to make the case internally or just want to read the fine print yourself, it is available here.

What I Shipped, What's Left

The current free tier gives you Google Calendar and Google Drive. Standard ($5/mo) unlocks all 8 integrations and 90 days of history. Enterprise ($10/mo) adds unlimited history and org controls but for a limited time all tiers are free.

The weekly digest is one of my favorite features. It runs at 8 AM Monday in your local timezone, emails you the previous week's summary, and links to a time-limited signed PDF report.

What I'm still working on: Stripe integration when required.

What I Actually Learned

A few things that surprised me:

The inference engine is the hardest part, and it's not glamorous. It's a lot of edge case handling. What if the PR was opened before the standup but merged after? What if someone has 12 Jira events in one day across 3 projects? What if a calendar event has no duration? Every case needs a rule, and every rule has a counterexample.

Privacy as a constraint is actually clarifying. When you eliminate all content, you're forced to make the metadata work harder. That constraint shaped a lot of the extractor and similarity design in ways I wouldn't have arrived at otherwise.

No-LLM doesn't mean dumb. The inference is genuinely useful without any language models. Deterministic and explainable is a feature, not a limitation. LLM integration will be integrated as needed.

Building for yourself is a good start, but not the whole story. I use this every day. But I'm also a fairly unusual case: 25 years of tooling opinions, specific integrations, and a very structured workday. I genuinely don't know yet whether the problem is widespread or whether I'm just uniquely disorganized.

One Honest Ask

I built this to solve my own problem, and it solves it well for me. But I am one person with one workflow, one set of tools, and 25 years of habits baked in.

What I genuinely do not know yet is whether the inference engine holds up for people with different rhythms. Someone who lives in Azure DevOps instead of GitHub. A contractor juggling three clients in Jira simultaneously. An EM whose day is 80% calendar and 20% everything else.

If you try it and something feels off, like the grouping is wrong, the confidence is backwards, a whole category of your work is invisible, etc. I want to know. That feedback is not just appreciated, it is the only way this gets better.

There is a feedback form built into the app, or you can find me here in the comments. Either way, I am reading everything.

Try It

If you want to poke around: worktrace.io

For a limited time all tiers are free for early adopters. No credit card required.

Happy to answer questions about the inference engine, the OAuth flows, the clean architecture decisions, or anything else.

DEV Community: Hal Hunt