Quiet · local-first, unlisted
Koi Cave
A private operator brain that never leaves the machine.
Internal build — dev-signed and un-notarized, so it cannot run on another Mac
Verified 2026-07-20 · 3 sources
- Not distributable to anyone
- codesign shows “Apple Development: BLAKE JIHAD TAYLOR”; spctl -a returns rejected; stapler reports no ticket
- The installed app is current, not stale
- ~/Applications/Koi Cave.app binary stamped Jul 13 2026, built from HEAD 350269a
- Certified with limitations, and the mail path never ran
- MORNING_FOUNDER_BRIEF_CERTIFICATION_REPORT.md; gmail-oauth-config.json holds a clientID and no tokens
The human problem
Every tool that promises to organize your work wants your work on its servers, on a subscription, forever. I wanted the leverage without renting my own context back from someone else.
The thesis
Personal infrastructure beats personal productivity apps. If the thing that knows the most about how I work is owned by a company, that's a dependency, not leverage.
Where it actually stands
- A macOS app: notes, tasks, memory, and automations, running local-first.
- The morning founder brief is certified with limitations — it survived every failure drill I could design, including corrupt caches, malformed events, and a disconnected mail provider.
- It is signed with a development certificate and not notarized, which means Gatekeeper rejects it on any Mac but this one. There is nothing to hand anyone even if I wanted to.
- One known truth bug remains: items waiting on me for more than 72 hours drop out of the brief while it reports no urgent signal. That's the exact failure mode a brief exists to prevent.
- The mail integration has never completed a real sync. The stored config holds a client ID and no tokens, so every brief it has ever produced was built from local state.
Decisions and tradeoffs
Local-first, with no hosted fallback.
The moment there's a sync server, the privacy claim becomes a policy instead of an architecture.
Certified it with the limitations written down instead of fixing them first.
A known, documented failure is safer than an undocumented one. The report says what it doesn't do.
Kept it off every public surface.
It has no users, no URL, and no store presence. Putting it on a product page would be inventory-padding, and this site doesn't do that.
What building it taught me
I certified a feature against every failure I could imagine and never connected the one integration that would have made it real. The drills tested how it behaves when the data is missing, which turns out to be the only state I've ever actually run it in.
What isn't true yet
- No public build, no download, no waitlist. There is nothing to try.
- Never notarized, so it cannot be installed by anyone else even privately.
- The live mail integration has never completed a sync, so the feature has never run against real data.
- It is a case study in how I build, not a product I'm offering.