Four small problems from shipping a local‑first task app

Описание и применение

Проблемы локального приложения OpenTodo решены чистыми функциями, детерминированными правилами синхронизации, строгой политикой исходящих запросов и шифрованием метаданных происхождения.

Задача

Shipping a local‑first task manager revealed four subtle issues that required careful design and implementation.

Результат

The four targeted problems were resolved with pure, testable code, deterministic sync rules, strict outbound policies, and end‑to‑end encryption, enabling a stable local‑first experience in OpenTodo 0.9.0.

Рабочий процесс

• 1. Identify problematic behavior in title editing, timer sync, issue import, and origin encryption.
• 2. Design pure functions and deterministic rules to address each issue.
• 3. Implement Go and TypeScript twins, sharing test vectors and fixtures.
• 4. Integrate solutions into OpenTodo’s codebase and run AI‑assisted coding agents.
• 5. Release version 0.9.0 and document changes on the project blog.

Доказательства

The fix is to read only the edit. When editing starts, the current title becomes the base. On commit, the parser finds the common prefix and the common suffix of the base and the draft, treats those spans as if they were quoted, and reads only the text in between.

Источник

Among a user's running entries, the one to keep is the one with the greatest started_at, with ties broken by the greatest id.

Источник

The server never sees task content. The question was which parts of the origin count as content. kind alone looks harmless, but url, title and id name the page, the mail or the issue, and even the combination leaks something.

Источник

Every change above started as a written spec, using the OpenSpec workflow: proposal, design, spec deltas, tasks, then code.

Источник