610ca64894
* fix(sync): harden file-based .bak recovery and split gap detection Post-merge review of the SPAP-8/9/10/11 series found five defects in the file-based sync adapter; all fixed here with regression tests proven red/green against the previous code. Design cross-checked by a 7-reviewer multi-agent pass; its findings are folded in. - Split gap detection suppressed a syncVersion reset when the remote clock was EQUAL OR GREATER_THAN the last-seen clock — the exact bug the SPAP-9 review follow-up removed from the single-file path. A dominating client's snapshot reset (which compacts ops this client never saw) was treated as cosmetic, skipping snapshot hydration and silently diverging. Now EQUAL only, matching the single-file path. - .bak recovery staged the CORRUPT primary's rev, which setLastServerSeq then promoted to _lastSeenRevs: every later poll's SPAP-10 pre-check read "unchanged" and skipped the re-download while the upload path (no .bak recovery) kept failing on the corrupt primary — sync wedged until another client rewrote the file. A recovery download now never stages/promotes the rev (each poll re-recovers and re-seeds the heal cache), and every site that rewrites _lastSeenRevs drops any stale staged rev via the shared _commitLastSeenRev. - Snapshot uploads (force-upload / "Use Local" / E2EE re-encryption) left the pre-snapshot .bak behind. After a password rotation the stale old-key .bak was silently "recovered" by a still-old-key client (suppressing its wrong-password prompt) and heal-uploaded back over the new-key primary, reverting the rotation. Snapshot uploads now write the same payload to .bak FIRST, then the primary (_forceUploadWithBakFirst; deliberately FATAL — aborting pre-primary leaves the remote consistent for a retry). Applies to sync-data.json.bak and sync-ops.json.bak; sync-state.json.bak is deliberately exempt: its adoption is ref-validated (EQUAL clock vs snapshotRef), so a stale copy is inert, and it must keep serving the compaction crash window it exists for. - Recovery additionally refuses a PLAINTEXT .bak when encryption is expected: decoding trusts the file's own prefix flags, so a plaintext .bak decodes even under a wrong/rotated key — the same wrong-password-suppression class via mode (rather than key) mismatch. - The split migration wrote the v3 tombstone BEFORE neutralizing the legacy .bak (best-effort): a crash between the writes left a live v2 .bak that an OFF client's recovery would resurrect over the tombstone, forking the folder. Neutralize-first, fatal. Residual: a step-3 failure after the migration's ops-file commit leaves a live v2 file until the next snapshot upload (documented at the call site). - sync-ops.json — the hot file, rewritten on every op-bearing sync — had no backup at all, so a torn write wedged split sync until a manual force-upload. It now gets the same backup-before-overwrite + recovery + heal treatment as the single-file format. deleteAllData deletes the split files BEFORE the tombstone and treats source-of-truth deletion failures as errors (success:false) — it previously left every split file behind and reported success. The three backup/recover pairs are collapsed into shared _writeBakFile / _readBakFile helpers (the EQUAL||GREATER_THAN divergence above is exactly the copy-drift failure mode this prevents); .bak file names move into FILE_BASED_SYNC_CONSTANTS as remote-format surface. * fix(sync): show the exact pending-op count in the conflict dialog Compaction can fold still-unsynced ops into the snapshot baseline clock, so the dialog's vector-clock delta could report "0 changes" right next to "N local changes pending" — and the false 0 skipped the secondary USE_REMOTE overwrite confirmation. The dialog now prefers the EXACT pending-op count carried on LocalDataConflictError (new optional ConflictData.localUnsyncedOpsCount): it is precisely "what USE_REMOTE would discard", so both the displayed count and the >= 20-difference confirmation threshold work from a truthful figure; the clock delta remains the fallback when no measured count is supplied. Display/confirmation-only — no clock or op-log semantics touched. Also asserts the explicit-null lastSyncedVectorClock contract at the fresh-client conflict throw sites (test gap from SPAP-7). * chore(lint): enforce tx-handle-only access in op-log transactions The SQLite op-log adapter serializes every entry point through a per-connection FIFO queue; awaiting an adapter method inside a .transaction() callback enqueues behind the transaction's own slot and silently deadlocks all op-log persistence. The port contract documents the precondition and #8849 promised a lint rule — this adds it (no-adapter-in-tx, scoped to src/app/op-log) with RuleTester specs. Matching is rename-proof: it flags access on the SAME receiver the transaction was opened on (plain identifiers and any `this.<field>`), so it does not depend on the field being named `_adapter`; known heuristic gaps (extracted callbacks, aliasing, method indirection) are documented. Also corrects the port doc: IndexedDB serializes only overlapping-scope transactions; SQLite provides the stronger whole-connection exclusion. |
||
|---|---|---|
| .air | ||
| .devcontainer | ||
| .github | ||
| .husky | ||
| .signpath/policies/super-productivity | ||
| .vscode | ||
| android | ||
| build | ||
| docs | ||
| e2e | ||
| electron | ||
| eslint-local-rules | ||
| fastlane | ||
| ios | ||
| nginx | ||
| packages | ||
| scripts | ||
| snap/hooks | ||
| src | ||
| tools | ||
| .browserslistrc | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.example | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .gitpod.yml | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.json | ||
| .stylelintrc.mjs | ||
| AGENTS.md | ||
| angular.json | ||
| ARCHITECTURE-DECISIONS.md | ||
| capacitor.config.ts | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| docker-compose.e2e.fast.yaml | ||
| docker-compose.e2e.yaml | ||
| docker-compose.supersync.yaml | ||
| docker-compose.yaml | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| Dockerfile.e2e.dev | ||
| Dockerfile.e2e.dev.fast | ||
| electron-builder.yaml | ||
| eslint.config.js | ||
| funding.json | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE | ||
| ngsw-config.json | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| SECURITY.md | ||
| tsconfig.base.json | ||
| tsconfig.json | ||
| webdav.yaml | ||
An advanced todo list app with timeboxing & time tracking capabilities that supports importing tasks from your calendar, Jira, GitHub and others
🌐 Open Web App or 💻 Download
💻 Downloads & Install
For all current downloads, package links, and platform-specific notes:
check the wiki
✔️ Features
- Keep organized and focused! Plan and categorize your tasks using sub-tasks, projects and tags and color code them as needed.
- Use timeboxing and track your time. Create time sheets and work summaries in a breeze to easily export them to your company's time tracking system.
- Helps you to establish healthy & productive habits:
- A break reminder reminds you when it's time to step away.
- The anti-procrastination feature helps you gain perspective when you really need to.
- Need some extra focus? A Pomodoro timer is also always at hand.
- Collect personal metrics to see, which of your work routines need adjustments.
- Integrate with Jira, Trello, GitHub, GitLab, Gitea, OpenProject, Linear, ClickUp and Azure DevOps. Auto import tasks assigned to you, plan the details locally, automatically create work logs, and get notified immediately, when something changes.
- Basic CalDAV integration.
- Back up and synchronize your data across multiple devices with Dropbox and WebDAV support
- Attach context information to tasks and projects. Create notes, attach files or create project-level bookmarks for links, files, and even commands.
- Super Productivity respects your privacy and does NOT collect any data and there are no user accounts or registration. You decide where you store your data!
- It's free and open source and always will be.
And much more!
Note
The web version has some limitations: See the Web App vs Desktop comparison for more details.
📖 Documentation and Guides
Getting Started
- Getting started guide (article)
- Video walkthrough (YouTube)
- Eat the frog prioritizing scheme
Starting Point in Wiki:
First steps •
Reference •
How-To
Productivity Tips:
Keyboard Shortcuts •
Short Syntax
Need Help?
Visit the discussions page
See the bottom of the README for more information on the documentation.
Advanced Topics
Here are some other topics covered in the official wiki:
Development:
Run dev server •
Package the app •
Build for Android •
Run with Docker
Data Management:
User Data •
Issue Providers •
Sync Providers
Customization:
Plugins •
Themes
APIs:
Sync Server •
Plugins •
REST
Community
The development of Super Productivity is driven by a wonderful community of users and contributors. Thank you all so much for your support!
👀 Check out our awesome curated list of community-created resources about Super Productivity
♥️ Contributing
If you want to get involved, please check out the CONTRIBUTING.md
There are several ways to help.
-
Spread the word: More users mean more people testing and contributing to the app which in turn means better stability and possibly more and better features. You can vote for Super Productivity on Slant, Product Hunt, Softpedia or on AlternativeTo, you can tweet about it, share it on LinkedIn, reddit or any of your favorite social media platforms. Every little bit helps!
-
Provide a Pull Request: Here is a list of the most popular community requests and here some info on how to run the development build (wiki). Please make sure that you're following the commit message format and to also include the issue number in your commit message, if you're fixing a particular issue (e.g.:
feat: add nice feature #31). -
Answer questions: You know the answer to another user's problem? Share your knowledge!
-
Provide your opinion: Some community suggestions are controversial. Your input might be helpful and if it is just an up- or down-vote.
-
Provide a more refined UI spec for existing feature requests
-
Make a feature or improvement request: Something can be done better? Something essential missing? Let us know!
-
Translations, Icons, etc.: You don't have to be a programmer to help; learn how to contribute translations!
-
Create custom plugins or custom themes
Special Thanks to our Sponsors!!!
Recently support for Super Productivity has been growing! A big thank you to all our sponsors!
(If you are, intend to or have been a sponsor and want to be shown here, please let me know!)
Code Signing
Windows binaries are signed. Free code signing is provided by SignPath.io, certificate by SignPath Foundation.
Documentation: Manual versus Automated
There are two wikis: the official one hosted in by GitHub and the autonomously generated variant using DeepWiki.com. The manually curated version is a more stable and approachable resource designed to help you understand the app from a more human-focused perspective whereas DeepWiki is optimized for explaining the code itself with little regard for context beyond that.
Official Wiki
It is preferable to maintain local documentation rather than rely on an external service. It also preferable that the documentation is updated in tandem with the code changes as demonstrated in this commit.
Changes to files within ./docs/wiki are linted in CI before being automatically
sync'd to the repository's official Wiki hosted by GitHub.
Migrating to Docusaurus is a long-term goal once the content and structure of the wiki has matured and the remaining "legacy docs" have either been reworked or removed. There are some automations in development to help reduce the difference between the published docs and the state of the code while retaining a human-in-the-loop.
DeepWiki.com
If you have very specific questions about how the code works or why a bug might be producing
a particular message it might be useful to
. It can help "cite your sources" when discussing functionality and code that you don't fully
understand as part of feature requests or bug reports.
This automated reference does come with some significant drawbacks:
- Intent: Describes what code does, not why decisions or tradeoffs were made.
- Staleness: Will *always* lag behind the code.
- Code-Focused: Does not provide guides or conceptual explanations.
- Cost: Potential future cost and higher resource usage than static docs.