bd7c2f2cee
* test(sync): pin three-client convergence after a merged op loses LWW Follow-up to #8874 (the retracted-then-adjudicated composition finding): after a disjoint-merged op loses whole-op LWW to a newer overlapping edit from a third client, the remote-win holders transiently keep the merged delta's other field while the local-win holder never applied it. Convergence depends ENTIRELY on _createLocalWinUpdateOp emitting a FULL-SNAPSHOT reconciling op with a dominating clock. This spec pins that closure property end-to-end (merge -> overlapping newer edit -> whole-op LWW on both holders -> snapshot propagation): if local-win ops ever become partial deltas - the same direction the merge path moved for analogous reasons - the three clients diverge permanently and this test goes red. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * test(sync): reframe 3-client convergence as a focused composition test Addresses maintainer review on #8933: - Drops the '(e2e)/all-clients' framing. It is a composition test of ConflictResolutionService's emitted ops applied via a local LWW helper, not a transport e2e; the comment now states the scope and that cross-client propagation is modelled (justified by the dominating-clock assertion), not executed. Client B contributes only an input op. - Adds the two assertions that make the convergence claim real: the local-win op reconstructs C's COMPLETE reviewable entity from a bare base (full-snapshot closure), and its clock is GREATER_THAN both inputs (opC and the merged op), so it propagates as a plain non-conflicting remote op. - Updates the local resolveCapturing helper to the #8900 mixed-source-batch API (appendMixedSourceBatchSkipDuplicates); the rebase onto current master surfaced that the prior appendWithVectorClockUpdate mock no longer matches the service. SPAP-39 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(sync): scope 3-client claim to shared-field reconciliation; prove receiver-only-field divergence Addresses maintainer review on #8933. The three-client composition test previously claimed full-snapshot closure (stateA === stateC / identical entities). johannesjo gave a verified counterexample: applying C's full local-win snapshot to A cannot clear a field C never had (SuperSync JSON-serializes ops so absent fields don't travel as clears; lwwUpdateMetaReducer applies via a shallow updateOne), so A keeps it and the clients diverge — with a dominating clock, permanently. - Narrow the active composition test to the property that actually holds: present-field reconstruction + a dominating clock + shared-field reconciliation. It no longer asserts byte-identical whole-state equality. - Replace the pending() aspiration with an ENABLED test asserting today's ACTUAL behavior: run the real resolution service to get C's local-win op, JSON round-trip its payload, apply it through the PRODUCTION lwwUpdateMetaReducer, and assert A retains the receiver-only dueDay while C lacks it (divergence). Flip the dueDay assertions when the runtime reconciles receiver-only fields. The underlying runtime data-integrity bug is tracked in SPAP-43. SPAP-39 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(sync): migrate disjoint-merge spec to production op-apply seam; pin convergence Rebasing #8933 onto current master surfaced that upstream #8980/#8990 reshaped the LWW op payload (adapter `{ task: { changes } }` -> nested `{ actionPayload, entityChanges, lwwUpdateMode }`) and #9007/SPAP-43 made `_createLocalWinUpdateOp` stamp `lwwUpdateMode: 'replace'`, applied via setOne. Per johannesjo's #8933 review: - Content-model applyOp: also read the nested `actionPayload` shape so the no-receiver-only-field test reconstructs the op's carried fields correctly. (This limb only asserts WHICH fields the op transports; no clearing in play.) - Receiver-only test: build the action via the real `convertOpToAction` instead of hand-rolling it. The hand-built action spread `lwwUpdateMode` at the top level, so it never reached `action.meta` and silently took the updateOne (shallow-merge) branch — masking production. Through the real seam the 'replace' op applies via setOne: A's absorbed receiver-only `dueDay` and B's `notes` are CLEARED and the clients CONVERGE. Flipped the assertions and reframed the test from "diverge" to "converge" — the SPAP-43 replace/setOne work closed the gap the test previously (incorrectly) documented as open. Verified end-to-end: 28/28 in-file green on current master. SPAP-39 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * test(sync): fix stale op-log-store mock; reconcile flipped convergence comments Round-4 review fixes for #8933 after rebase onto current master: - resolveCapturing helper's createSpyObj was a third, un-maintained copy of the OperationLogStoreService mock and had rotted: renamed appendWithVectorClockUpdate -> appendWithVectorClockOverwrite (#9080) and added the missing getOpById (#9086). This was the CI-red blocker (TypeError: opLogStore.getOpById is not a function). - Flip the two describe-level headers that still carried pre-flip divergence framing. Master now stamps lwwUpdateMode: 'replace' on local-win ops and the reducer applies replace-mode via setOne, so test 2 asserts the receiver-only field IS cleared and the clients converge -- the headers said the opposite. - Add a receiver-version scope note: the disjoint merge is enabled in production (unfrozen by #9095), but only replace-mode-aware receivers converge; older clients apply the snapshot via updateOne and still diverge. 29/29 SUCCESS in conflict-resolution.disjoint-merge.spec.ts. SPAP-39 * chore(sync): scrub private tracker keys from disjoint-merge spec The spec ships to the public upstream PR and the maintainer is GitHub-only, so replace internal tracker keys with neutral descriptive wording: - top-level describe + file header: drop the key, keep "disjoint-field merge" - (a3)/(a4)/(a5) section comments: "disjoint-merge fix:" instead of the key - 3-client test comments: "the replace/setOne behavior/work" without the key No behavioural change; 29/29 SUCCESS. SPAP-39 --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|---|---|---|
| .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.