Captain's Log

The thing I never had as a developer was a tool that read my own commits back to me in a way I could actually remember. Productivity trackers go in the wrong direction — they measure activity, not work. The work I did this week is already in the Git log. I just couldn't tell you what was in it without scrolling back through the repository.

Captain's Log started from a small list of practical questions I asked myself most Fridays:

• What did I ship today?
• Which repositories took most of my week?
• Was this a small cleanup day or a heavy diff day?
• What should I remember from the actual commits?

Every feature in the app exists to answer one of those four questions accurately. Work Map exists because I want to see commit volume and changed lines across days, weeks, months, and years at a glance. Daily journal entries exist because I want a short, accurate paragraph generated from the actual evidence — not from my self-assessment, which is unreliable, and not from my calendar, which lies about what I worked on.

The constraint I held the design to: this is a tool for the person doing the work, not a tool for the person checking on the work. There is no team dashboard. There is no manager view. There is no productivity score. There is no daily standup export.

The studio's posture is enforced by what the app refuses to look at. Captain's Log reads from the GitHub repositories you explicitly selected, and nothing else. Not your inbox, not your calendar, not your screen time, not your IDE telemetry. Adding any of those would broaden the surveillance surface in a way that contradicts what the product is for.

The same posture shapes the data path. GitHub tokens and optional cloud AI keys live in the iOS Keychain. There is no Captain's Log account. There is no 941 Apps server. The app explains its full data flow in an in-app Privacy and Data screen — not just in a policy document buried two taps deep.

Sign-in is GitHub Device Flow. The app shows you a short code, you tap "Copy & Open GitHub," paste the code into github.com on whichever device is closest, and you're authenticated. No OAuth redirect, no Universal Link interception, no Safari handoff.

The reason is friction at the right edge: signing into a mobile app via OAuth redirect routinely fails for users on flaky networks, browsers with strict referrer policies, or operating systems that intercept the callback. Device Flow trades a few extra taps for a flow that works on every device, every time, and gives the user a clear mental model of what they just authorized. After sign-in, the user picks specific repositories via their GitHub App installation — the app reads only what was explicitly granted.

The AI layer is intentionally hybrid. When Apple Foundation Models are available on the device (iOS 26+ on supported hardware), the daily journal summary runs on-device with zero network round-trip. The commit evidence never leaves the phone.

When Foundation Models aren't available — or when the user prefers a different model — the app supports bring-your-own-key OpenAI and Anthropic providers. The studio runs no proxy. Requests go directly from your iPhone to the provider you attached, with whichever commit evidence you selected as context. No relay, no studio analytics, no shared inference layer.

The product works fully with no AI provider attached. Without a model in the loop, you get the timeline, the Work Map, the diff stats, the changed file lists, and the language and work-type breakdowns. Those alone answer most of the four questions I built the app for. The journal summary is the cherry on top, not the foundation.

That layering matters for what the product means. A tool that needs an external LLM to function would also need a subscription, or an account, or a server. None of those are part of this app's posture. Making AI optional is the same decision as making the server optional — both are about the user owning the data and the control surface.

The shipping feature set, kept deliberately small:

• GitHub Device Flow sign-in. No Captain's Log account.
• Repository selection through your GitHub App installation. The app reads only what you explicitly granted.
• Daily, weekly, monthly, and yearly work views. Same commits, different time scales.
• Work Map for commit volume and changed lines, time-scaled to match the view.
• Diff stats, changed files, language breakdowns, and work-type classification (feature / fix / refactor / docs / chore).
• Daily journal summaries backed by commit evidence.
• Apple on-device summaries via Foundation Models when available.
• Optional bring-your-own-key OpenAI and Anthropic support.
• In-app Privacy & Data screen explaining the entire data flow.

Native SwiftUI for iOS and iPadOS. Universal bundle ID (com.blakecrosley.captainslog). iCloud capability for cross-device state. Background indexing of older Git history that batches incrementally, so the app stays usable while indexing continues. The Mac, Apple Watch, and Apple TV companion targets exist and are platform-gated; native marketing for those releases follows their signing and TestFlight paths separately.

Building Captain's Log clarified one of the studio's core decisions: the right AI architecture for a personal tool is on-device first, BYOK second, never proxied through a studio service. Anything else trades user ownership for a roadmap.

It also clarified what to refuse. The pull to add "team features" or a manager dashboard is constant in the developer-tools category — it's where the money usually is. The product is more honest because it refused that pull. Captain's Log will not become a productivity-monitoring SaaS, because making it one would betray what it was built for.

If you want the studio's product overview, it lives at 941apps.com/captains-log. The app is in active development; the studio is closing the remaining App Store Connect blockers before public TestFlight.