b64f398975
* docs(agents): require reviews to ask if a feature earns its place * build: add output folder to gitignore because of playwright writing there * fix(sync): recover from migration-path hydration failures via op-log replay A throw on the snapshot migration path (metadata-validation failure, migration transform failure) previously escalated into attemptRecovery(), which refuses while a snapshot exists on disk — bricking the app to an empty store with the HYDRATION_FAILED snack on every boot, even though the op-log could rebuild the state (#9140). The same applied when a feature reducer threw on the snapshot loadAllData dispatch of non-fatally-validated migrated state (the residual class #9124's non-fatal design created). - Catch migrateSnapshotWithBackup throws: when the op-log has replayable rows, discard the unmigratable snapshot for the boot and fall into the existing replay-from-scratch path (#7892 fallback); a successful replay persists a fresh CURRENT_SCHEMA_VERSION snapshot, breaking the re-migrate loop. Empty op-log and IndexedDBOpenError keep the existing terminal handling. - Guard the snapshot loadAllData dispatch with a collector-scoped meta-reducer (mirrors the bulk-replay failure collector): a reducer throw is reported instead of erroring the NgRx state observable (which would silently drop all later dispatches), and the hydrator falls back to the same op-log replay. Pure pass-through outside hydration. - Extract _replayTailOps/_replayAllOpsFromScratch so both fallback call sites reuse the pre-dispatch replay path (replay-from-0 must never run on top of committed snapshot state — double-apply hazard). * fix(sync): harden #9140 fallback against data loss found in multi-review Multi-agent review of the previous commit surfaced three verified defects in the fallback design; all are fixed here with discriminating tests: - Never persist the fallback replay (and suppress the convergence save): for a synced client the surviving op-log is only a compaction-window tail and cursor-based sync never re-sends pruned ops, so caching the partial replay would silently overwrite the intact on-disk snapshot — the last complete local copy. Recovery now re-runs each boot (visible via a new HYDRATION_FALLBACK_RECOVERY snack) until a fixed build migrates the intact snapshot. - Reject the fallback when the store already holds meaningful data: hydrateStore() re-enters on a LIVE store via PluginAPI.reInitData(), and replay-from-0 on top would double-apply non-idempotent reducers. - Rethrow instead of booting silently empty when rows exist but every one is reducer-rejected (the lastSeq>0 gate is only a pre-filter). Also from review: corrected the guard/hydrator comments — a reducer throw never propagates through dispatch(); rxjs diverts it to an async unhandled-error report and silently tears down the state subscription (store freezes). Proven by a new real-store integration spec that also pins the guarded path end-to-end through META_REDUCERS. Registry spec now pins the guard before Phase 3; registry header documents Phase 2.5. Dropped the dead vectorClockService injection to stay under the 1200-line service cap (now exactly 1200 — the near-duplicate _replayTailOps/_replayAllOpsFromScratch pair is the follow-up to win back headroom). * fix(sync): block compaction during hydration fallback; add recovery hint Closes the two follow-ups from the #9140 review round: - Compaction (incl. emergency) now skips while the session booted via the hydration fallback: the live state may be partial (rebuilt from the surviving op tail) while the intact-but-unhydratable snapshot is still on disk — compacting would overwrite that last complete local copy AND prune the ops the next boot's recovery replays. Tracked via a session-scoped flag on HydrationStateService, set/cleared at the end of every hydrateStore() run so a later clean re-hydration (plugin reInit after a sync import) re-enables pruning. - The terminal HYDRATION_FAILED snack now tells users how to actually recover (sync / backup import) instead of only suggesting a reload (#9140 fix 2 minimum). * test(sync): e2e-reproduce the #9140 brick; require e2e repro for sync changes Adds the reproducible end-to-end artifact for this fix: a Playwright spec that seeds a real schemaVersion-1 state_cache snapshot whose v1->v2 migration transform throws, then boots twice. Verified both ways: it FAILS against the pre-fix hydrator (boot bricks, task list never appears) and passes with the fix (tasks restored via op-log replay, fallback path pinned via console log, snapshot preserved at v1 on disk). lastAppliedOpSeq is seeded past all real ops so only the fallback's replay-from-0 can restore the tasks - the assertions discriminate the recovery path, not just task visibility. Found along the way: in the web e2e env the 'will not be persisted' boot snack replaces the recovery snack (SnackService debounces opens), so snack UX is asserted at the unit level instead; Electron/PWA sessions do not show the persistence warning. AGENTS.md: new sync-correctness rule - any sync-system change must START from a reproducible failure (failing test or scripted E2E against real data shapes, not a mocked seam); hardening without an observed end-to-end failure is how the sync layer accumulates overly defensive complexity. |
||
|---|---|---|
| .agents/skills/commit-messages | ||
| .air | ||
| .codex | ||
| .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.