Daybreak

Context

Most planning tools ask people to maintain the system before the system becomes useful. Daybreak began with a different premise: the product should compute a credible starting point from what it already knows, bring the plan to the user, and make review lighter than planning from scratch.

The harder design problem appeared when I added an AI agent. A conversational interface is useful only if it can change the same real product state as the UI—and trustworthy only if it cannot silently bypass the UI’s constraints. I treated that tension as the core product architecture rather than a layer of chat added at the end.

Product Principles

Computed over asked. Daybreak derives a starting plan from projects, tasks, routines, due work, carry-over, and fixed Calendar constraints. The user reviews and corrects instead of rebuilding the day manually.

Honest over optimized. A useful plan can be visibly incomplete. Work that does not fit stays on deck instead of spilling past midnight or being hidden behind a false sense of completion.

Editable over autonomous. Generated blocks are ordinary product objects. People can move, remove, defer, or complete them directly, and manual edits remain authoritative.

One product, two interfaces. A feature is not complete when only the visual UI can use it. The agent needs a typed path to the same operation—or an explicit, documented reason it should not have one.

The Shared Operation Model

1. Ask or act

   A person uses a SwiftUI control or describes an adjustment in natural language.

2. Resolve intent

   The agent may propose only a registered typed operation; it does not write directly to the store.

3. Validate

   Identity, ownership, chronology, ambiguity, and safety rules are checked before mutation.

4. Apply once

   The shared handler performs an idempotent local change or refuses it without inventing success.

5. Return a receipt

   Applied, skipped, and failed results remain visible and auditable in the product.

6. Sync privately

   SwiftData and private CloudKit carry the resulting product state between Mac and iPhone.

The agent extends the product's tooling; it does not receive a second, more powerful version of the product.

The current registry contains 42 typed operations. Twenty-seven are available to the conversational agent; fifteen are intentionally excluded where confirmation, privacy, provider-owned data, or destructive behavior still needs a stronger product policy. A separate inventory covers 38 user-facing mutations: 30 map to agent operations and eight carry explicit exclusions.

Those exclusions are part of the design. For example, an agent may complete an eligible task, but destructive deletion stays outside conversational access. It may work around imported meetings, but never rewrite a source-owned Calendar event. A traffic workflow can use a provider result, but the model cannot invent a travel estimate.

Planning Around Reality

Calendar events enter Daybreak as pinned constraints with their provenance intact. Daybreak-owned work can move around them; source meetings cannot. An absent event is treated as evidence only inside the exact Calendar window and account scope that was scanned.

The same preference for evidence shapes daily planning:

• Unattended imports may relax a due date, but never make work more urgent.
• Working ahead fills genuinely open capacity; it does not displace due or carried work.
• Work that cannot fit before the local day boundary stays unscheduled and visible.
• Completing a blocker restores a dependent task’s prior state instead of inventing progress.

Designing Through Dogfooding

I use Daybreak to run my actual days, then trace moments of confusion back through interaction, state, and implementation. One live late-start session surfaced twelve prioritized issues: the plan did not acknowledge a delayed start clearly enough, carry-over counts could feel unstable, and cross-device state could undermine trust even when the underlying merge was technically valid.

That session changed the direction of the product. Evening preparation now does more of the heavy lifting, morning review is intended to stay lightweight and phone-friendly, late-start recovery is a first-class state, and sync correctness is treated as a user experience rather than background infrastructure.

Outcome And Limits

Daybreak runs as a signed Mac app and on a physical iPhone, with private CloudKit sync, typed task and plan operations, unattended workflows, native agent chat, and receipt-backed changes.

The most valuable outcome is the product rule the system made concrete: AI should extend a designer’s tools without removing human taste, ownership, or the ability to correct the result. Reliability here is not only model quality. It is how clearly the interface represents uncertainty, who owns each piece of state, and what happened after the user asked for a change.

This remains a personal product in active dogfooding. Multi-Mac distributed claiming and some external-write policies are documented follow-ups, and I would validate the planning model with more users before treating my own workflow as universal.