Building a Practical Hypertrophy Workout Tracker with CalDAV, Tasks.org and a Minimal Backend

Table of Contents

1. Key Highlights
2. Introduction
3. Why tracking wins for hypertrophy (and why many trackers fail)
4. Design principles: functional core, imperative shell
5. Domain model and progression logic
6. A UI without building a UI: CalDAV, Nextcloud, and Tasks.org
7. The workout-data microlanguage: how to write entries that are machine-readable and forgiving
8. From notes to structured microcycles: parsing and sanitization
9. Running the backend: where orchestration happens
10. Example flow: one mesocycle from baseline to second microcycle
11. Tracking subjective feedback and auto-adjustments
12. Data ownership and analytics: why keeping raw notes matters
13. Implementation notes and existing code
14. Trade-offs and limitations
15. Who benefits most from this approach
16. Next steps and practical extensions
17. Building safe progression rules: practical heuristics
18. Real-world example: handling an unexpected injury
19. FAQ

Key Highlights

• A practical architecture for hypertrophy-focused workout tracking: functional core for progression logic, CalDAV/Tasks.org for user interface, and a lightweight backend orchestrated by cron on a Nextcloud server.
• A forgiving microlanguage for encoding set-level prescriptions and actuals inside calendar/task notes, enabling offline mobile entry and automated parsing for progression algorithms.
• Design choices prioritize minimal UI work, data ownership, and extensibility: keep all raw data, calculate prescriptions from actuals, and store structured workout trees (mesocycles → microcycles → workouts → exercises → sets).

Introduction

Tracking workouts is the single most effective habit for consistent progress in hypertrophy training. When done right, a log of weights, sets and reps turns subjective memory into objective signals. Those signals make it possible to detect plateaus, adjust load, and design mesocycles that prioritize incremental adaptation. Yet most people use ad-hoc methods: paper notebooks, spreadsheets, or commercial apps that either lock data behind paywalls or demand constant context switching.

This article documents a pragmatic alternative: a fitness tracking system built around small, resilient components you already control. It replaces heavy frontend work with a simple functional core that computes progressions, leverages CalDAV (Nextcloud) and the Tasks.org mobile app for the user-facing side, and parses lightweight, human-friendly annotations as structured data. The result keeps your data local, lets you write workout notes on your phone without fighting a UI, and automates the prescriptions for the following microcycle.

The following sections walk through why those decisions matter, how the domain model is shaped around hypertrophy principles, the microlanguage that makes mobile entry reliable, and how a minimal backend ties everything together. Practical examples demonstrate how a mesocycle unfolds in this setup. Links to code and implementation notes appear where they help clarify the design.

Why tracking wins for hypertrophy (and why many trackers fail)

Hypertrophy training rewards progressive overload, consistency, and measured recovery. A reliable log provides three things: an accurate record of what actually happened, a way to compare sessions, and a deterministic rule set for deciding the next step. That makes planning possible without guesswork.

Common tracking approaches and their weaknesses:

• Paper notebook: simple, reliable, portable. Prone to missing context, hard to aggregate, and easy to lose.
• Spreadsheets: structured and analyzable. Require discipline to update and are awkward to use on a phone under time pressure.
• Note-taking apps: flexible and portable, but end up full of abbreviations and inconsistent formats that make automated parsing brittle.
• Dedicated apps: polished and mobile-friendly, but may lock data, charge steep fees, or disappear when unmaintained.

The right solution hits three targets: low friction for entry during the workout, structured data for analysis and progression logic, and control over raw data. That suggests an approach that is both pragmatic and modular: accept a minimal, familiar UI (a task manager), design a forgiving micro-syntax for entries, and isolate progression and analytics in a functional core.

Design principles: functional core, imperative shell

The foremost architectural decision is to separate pure domain logic from side-effecting infrastructure. The functional core contains the domain model and pure functions that answer questions like “Given this history of microcycles, what should the next microcycle look like?” The imperative shell handles interactions with external systems—reading/writing CalDAV tasks, scheduling cron jobs, and writing back notes.

This pattern delivers several advantages:

• Testability: progression functions are deterministic and easy to unit test.
• Portability: the same core can power a CLI, web UI, mobile wrapper or an integration with calendar tools.
• Minimal UI work: the shell can reuse existing clients (Tasks.org) so the developer avoids building and maintaining a custom mobile interface.

The domain model encodes how mesocycles, microcycles, workouts, exercises and sets relate. It captures both prescriptions (planned weights, sets, reps) and actuals (what the athlete performed). Keeping the domain model compact, explicit and purely functional allows the system to evolve algorithmically without being tied to a UI choice.

Real-world analogy: think of the core as a fitness-specific rules engine (like a financial bookkeeper) and the shell as the set of connectors that bring in the raw receipts (the workout notes) and post back the next month's invoices (the next microcycle plan).

Domain model and progression logic

Hypertrophy goals shape the structure of training cycles. The model here uses common coaching terms but remains flexible:

• Mesocycle: a macro training block, typically eight weeks.
• Microcycle: usually a week, containing several workouts.
• Workout: a session that contains multiple exercises.
• Exercise: includes name, target muscles, number of sets, and per-set prescriptions.
• Set: targets weight and reps; actuals are recorded after the set.

Assumptions baked into the model:

• Progress is evaluated microcycle-to-microcycle.
• The first microcycle serves as a baseline: prescriptions are empty and actuals supply the starting point.
• A progression function consumes the vector of completed microcycles (with actuals) and returns a new microcycle fully populated with prescribed weights and potentially adjusted set counts.
• Optional subjective feedback (soreness duration, joint pain, pump rating) is stored with exercises to influence decisions later.

A minimal progression rule produces useful behavior: if prescribed reps were achieved (or exceeded) across the relevant sets, increase the planned weight for the next microcycle by a small increment (e.g., 2.5%). If reps fall short consistently, reduce by a small amount or flag the exercise for autoregression. When progress stalls for several microcycles, suggest adding or removing a set based on workload feedback. These simple heuristics give predictable adaptations without overfitting to noisy single-session variance.

Example progression algorithm (pseudo steps):

1. For each exercise, compute volume and intensity across the microcycle.
2. Determine whether the athlete met prescribed reps for majority of sets.
3. If majority success and RPE/subjective feedback is within acceptable range, increase weight by preset increment for the next microcycle.
4. If failure with low fatigue but missed reps, decrease weight modestly.
5. If failure due to high fatigue or reported joint pain, reduce volume or substitute an accessory movement.
6. Persist the prescribed values into the next microcycle structure.

Testing and transparency matter. Preserve all actuals and the rules that led to a prescription. When an athlete reviews past cycles they must see both the raw entries and the derived prescriptions with the exact rule applied, enabling trust and better long-term planning.

A UI without building a UI: CalDAV, Nextcloud, and Tasks.org

Building a polished mobile interface is time-consuming. The pragmatic approach uses systems you already trust: run a Nextcloud instance, use CalDAV to manage a dedicated "Workouts" task list, and let the Tasks.org mobile app serve as the data-entry surface.

How that maps to the model:

• Each microcycle becomes a set of tasks scheduled within a week.
• Top-level tasks represent workouts with dates.
• Subtasks represent exercises in each workout.
• Sub-subtasks represent individual sets for each exercise.

Why Tasks.org works:

• It exposes a familiar task tree and note fields where set-level details can be typed quickly on a phone.
• Sync through CalDAV keeps tasks consistent across devices.
• It avoids building and maintaining a custom app while providing an interface that supports nested tasks and per-task notes.

Operational flow:

1. A cron job checks whether there are outstanding workout tasks for the current microcycle.
2. If none are present, the backend populates the calendar with tasks for the first or next microcycle.
3. During workouts, the athlete enters set-level notes using a microlanguage (examples below).
4. The backend parses notes, converts them into structured actuals, runs progression logic, and writes next-week prescriptions back into tasks.

This approach trades some UX polish for speed of implementation, data portability and minimal maintenance. For many lifters who prefer quick note entry over fussy mobile UIs, it is preferable.

The workout-data microlanguage: how to write entries that are machine-readable and forgiving

Entering structured data via a mobile keyboard requires a syntax that balances strictness (to enable parsing) with forgiveness (to tolerate typos and shorthand). The microlanguage uses a small vocabulary: explicit markers for prescription or actual entries, and numbers for weight and reps.

Core grammar concepts:

• Allow both explicit markers and implicit defaults: “p 100 8” or “prescribed 100 8” for prescriptions; “a 95 8” or just “95 8” for actuals.
• Use short aliases: “p” and “a” reduce typing friction.
• Keep the token order fixed: weight then reps. Mobile users expect “100 x 8” or “100 8”, so support both.

Formalized grammar (conceptual):

• entry := prescription | actual
• prescription := ("p" | "prescribed") ws weight ws reps
• actual := ("a" | "actual") ws weight ws reps | weight ws reps
• weight := number
• reps := number

Practical examples:

• “100 8” — simple actual: 100 kg for 8 reps.
• “a 95 7” — explicit actual.
• “p 105 8” — a planned or prescribed target.
• Notes can combine entries for multiple sets if the app supports newlines: "95 8\n100 7\na 102 5" or use separate set subtasks for clarity.

Forgiveness strategies:

• Case-insensitive parsing for tokens.
• Allow extra whitespace or common separators like “x”, “×”, commas.
• Preserve raw notes so manual correction is possible.

Parsing can be implemented with a small grammar tool like instaparse (used by the project) or a hand-rolled tokenizer that tolerates common smartphone artifacts (missing spaces, doubled characters). The key is to convert free-form notes into a reliable vector of set-level tuples: [{weight:100, reps:8, type:actual}, ...].

From notes to structured microcycles: parsing and sanitization

Parsing is where usability and robustness collide. Raw mobile input is noisy: auto-caps, missing spaces, and inconsistent separators are common. The design handles these challenges using three layers:

1. Preprocessing: normalize Unicode (e.g., replace “×” with “x”), collapse multiple spaces, lowercase tokens, and strip extraneous punctuation.
2. Tokenization: split by whitespace and common separators, then attempt to match token sequences to grammar patterns such as [weight, reps], [a, weight, reps], [p, weight, reps].
3. Sanitization and fallback: when parsing fails for a line, flag that set for manual review while still including other successfully parsed data. Keep raw text in the data store so corrections remain possible.

Example: A user types “95×8” (no spaces). Preprocessing replaces the multiplication symbol with "x" and inserts a space: “95 x 8”. Tokenization recognizes the pattern as weight-reps and converts it.

Edge cases:

• Units: platform may combine units like “100kg 8”. The parser should strip known unit suffixes like “kg” or “lbs”.
• Decimal weights: allow decimals for users who increment in small fractions (e.g., “100.5 8”).
• Missing reps/weight: if only one number is present, infer whether it’s weight or reps based on context (position in a set-level subtask or default to weight) but flag the entry.

Keeping raw data ensures that false positives do not produce silent errors. When a parser fails to parse an entry, the system should surface that line in an audit log alongside the parsed results.

Running the backend: where orchestration happens

With Nextcloud and CalDAV handling the UI, the backend job is limited and predictable: fetch tasks, parse notes into data structures, run the progression engine, and write updated prescriptions back.

Deployment pattern:

• Host a small service on the same machine as the Nextcloud instance or a trusted backend host.
• Schedule a cron job (e.g., Sunday night) to:
  • Pull current workout tasks from the "Workouts" CalDAV list.
  • If no incomplete tasks exist for the current microcycle, populate tasks from the current plan or from the core planner when available.
  • Parse notes for completed tasks into actuals and aggregate microcycle data.
  • Run the progression function to compute next microcycle prescriptions.
  • Write the new prescriptions back into the notes or create tasks for the next microcycle.

Security and reliability:

• Use the existing Nextcloud authentication and CalDAV tokens, avoid storing passwords in plain text.
• Keep the backend idempotent: able to run multiple times without duplicating tasks.
• Log changes and decisions: store the reason for each prescription adjustment alongside the data for auditability.

Example orchestration sequence:

1. Cron triggers backend.
2. Backend queries CalDAV: finds four workouts in the "Workouts" list, each with nested subtasks.
3. Backend parses set-level notes; three workouts have complete actuals, one has some missing sets.
4. Backend computes next microcycle prescriptions and writes them to a "planned" set of tasks scheduled for the upcoming week.
5. Any ambiguous or unparsable entries are posted to a designated “Review” note in Nextcloud for manual inspection.

The orchestration is intentionally lightweight. The functional core encapsulates the smart bits. The backend simply moves data between storage and the core.

Example flow: one mesocycle from baseline to second microcycle

A concrete example clarifies the entire pipeline.

Setup:

• Baseline microcycle contains four workouts per week.
• Each workout contains 5 exercises; each exercise contains 3 sets.
• The first microcycle is populated with exercises but no prescriptions—athlete performs sets and writes actuals in Tasks.org set subtasks.

Week 1:

• Athlete completes workouts and enters lines like "80 10" for sets.
• Cron job picks up entries; parser converts notes to structured actuals.
• Core aggregates per-exercise outcomes: e.g., exercise A had 3 sets at 80kg × (10, 9, 10).
• Core applies a progression rule: if average reps >= target (since no target exists, use a baseline RPE or a default success threshold), set a conservative prescription for next microcycle, e.g., +2.5% weight.

Week 2 (prescribed by the system):

• Tasks.org now shows the next microcycle with prescribed weights in notes: "p 82.5 10" or similar.
• Athlete uses prescriptions as targets, performs sets, and records actuals.
• Backend compares actuals vs prescriptions to adapt week 3: if prescriptions were consistently met, another incremental increase is scheduled. If not met with low fatigue, the system reduces the increment or repeats the weight.

This approach guarantees that training is individualized: prescriptions are not fixed numbers picked beforehand; they are derived from the user's starting state.

Tracking subjective feedback and auto-adjustments

Objective load numbers matter, but so do subjective recovery and pain markers. The design includes optional feedback fields at exercise level:

• Soreness duration: how long muscle soreness lasted after the workout.
• Joint pain: boolean or rating to flag problematic movements.
• Perceived difficulty: a simple scale (1–10).
• Pump or muscle activation rating.

Integrating this data into progression:

• If soreness persists beyond a threshold, reduce volume or prescribe lighter assistance work.
• If joint pain is reported, flag the exercise and suggest an alternative movement or regression.
• If perceived difficulty exceeds a threshold while performance is declining, lower intensity or add deload weeks.

Example: an athlete reports strong joint pain after heavy benching for two consecutive microcycles. The system flags bench as "problematic" and proposes replacing it with close-grip bench or floor press, and reduces the load by 5–10% until pain subsides.

Subjective data makes the progression rules safer and more adaptive. It prevents the system from blindly escalating load based solely on reps.

Data ownership and analytics: why keeping raw notes matters

Many apps obfuscate or lock raw workout data. This design explicitly keeps every piece of raw information intact:

• Raw notes from Tasks.org are stored as-is alongside parsed structured data.
• Every prescription and progression decision is logged with the rule that caused it.
• Historical microcycles become a dataset for analysis: detect trends in volume, intensity, frequency, and fatigue markers.

Analytics possibilities:

• Plot weekly total volume per muscle group to visualize progress.
• Detect early signs of overreach by correlating volume increases with soreness and performance drops.
• Build simple predictive models to suggest deload timing based on volume spikes and subjective fatigue.

Real-world example: analyzing six months of logged data could reveal that progress stalls whenever weekly volume increases by more than 15% without a commensurate rise in recovery metrics. With that insight, rules can be refined to cap week-over-week increases.

Keeping the raw data ensures reproducible analysis. If the parser misinterprets an entry, you can always go back to the original text and correct it.

Implementation notes and existing code

The project’s author pursued several prototype implementations before settling on the current architecture. Public repositories show the evolution and components:

• https://github.com/Schroedingberg/romance-progression
• https://github.com/Schroedingberg/progressive
• https://github.com/Schroedingberg/barbiff
• https://github.com/Schroedingberg/muscleapi

Key implementation decisions:

• Use Clojure for the functional core due to its emphasis on immutable data and expressive sequence operations.
• Use instaparse or a small parser combinator for the microlanguage parsing to reduce brittle ad-hoc parsing code.
• Implement a lightweight CalDAV client module to interact with Nextcloud; reusing existing libraries where possible but keeping an eye on developer ergonomics.

These repositories contain early proof-of-concept code, parser grammar examples, and sample progression implementations. They can serve as a starting point for anyone wanting to implement a similar approach.

Trade-offs and limitations

No system is perfect. The chosen design accepts several trade-offs:

• UX trade-off: Tasks.org is functional but lacks the polish of a dedicated mobile app. Some users prefer a tailored interface and real-time feedback during workouts.
• Parsing complexity: While the microlanguage is forgiving, it still requires disciplined entry for reliable automation. Unparsable lines create manual review work.
• Sync lag: CalDAV sync behavior and cron timing introduce delays between entering actuals and getting updated prescriptions.
• Platform dependency: This setup assumes either a hosted Nextcloud or a willingness to run a server. For users who want a fully cloud-hosted, managed solution, this adds friction.

These limitations are acceptable for users who prioritize data ownership, flexibility and the ability to iterate algorithmically on progression rules.

Who benefits most from this approach

This architecture fits several user profiles:

• Lifters who value simple mobile note entry over complex app workflows.
• People running a Nextcloud instance who want everything under their control.
• Coaches or hobbyist developers who want a testable domain core to iterate progression rules.
• Users who plan long-term experiments with training algorithms and need raw data for analysis.

It is less suitable for:

• Users who want a zero-setup, polished commercial app experience with full-time customer support.
• People who cannot host a small backend or don't want to manage a Nextcloud instance.

For many hobbyist lifters and small coaching groups, the balance of control, low development overhead and structured data will be attractive.

Next steps and practical extensions

After a working baseline, the architecture lends itself to features that improve safety, personalization and analytics:

• Autoregulated progression: incorporate rep ranges and RPE to make daily adjustments.
• Movement substitutions: recommend alternatives when an exercise is flagged for pain.
• Volume autoregulation: automatically adjust weekly sets based on recovery trends.
• Cross-device client: a simple web dashboard to visualize microcycle history and to edit ambiguous parser results.
• Community templates: share mesocycle templates that users can import into their Nextcloud instance (e.g., hypertrophy-focused push/pull/legs templates).

Each extension adheres to the core principle: keep the domain logic pure and the UI thin, so new behaviors are expressed as transformations of structured workout data rather than a tangle of client-side routines.

Building safe progression rules: practical heuristics

A set of pragmatic heuristics increases safety while preserving steady progression:

• Small increments: prefer 1–2.5% load increases per microcycle on compound lifts.
• Microcycle averaging: base decisions on patterns from the last 2–3 microcycles, not single workouts.
• Redundancy for failure: if an athlete fails a prescribed weight twice in a row, reduce weight or repeat last successful load instead of forcing more reductions abruptly.
• Volume cap: limit week-over-week volume increases (e.g., 5–15%) to reduce overreach risk.
• Deload scheduling: introduce a planned deload every 4–8 weeks or when subjective fatigue metrics cross thresholds.
• Accessory scaling: progressive overload on accessory lifts can be slightly faster, but watch for technique breakdown.

These heuristics map cleanly to functions in the core and produce predictable behavior that users can trust.

Real-world example: handling an unexpected injury

Consider a bench press that produces shoulder pain mid-mesocycle. The athlete flags joint pain in the exercise note.

System response:

1. Mark bench as "injured" in the exercise metadata.
2. Replace heavy benching with a lower-risk variant (floor press or neutral grip dumbbell press) for 1–2 microcycles.
3. Reduce load and volume for the affected movement and increase accessory work for scapular strength and rotator cuff support.
4. Monitor subjective pain entries each workout; only reintroduce barbell benching when pain is consistently absent for multiple sessions.

This demonstrates how combining subjective feedback and structured prescriptions results in safer adaptations than purely numeric rules.

FAQ

Q: Why use CalDAV and Tasks.org instead of a dedicated workout app? A: CalDAV and Tasks.org provide a simple, portable UI and let you keep all data within your infrastructure. Building a full mobile app requires substantial maintenance; the chosen path achieves low friction for entry while enabling automated parsing and progression logic.

Q: What happens if my notes are parsed incorrectly? A: Raw notes are always preserved. The parser should flag ambiguous lines and surface them in an audit for manual correction. Over time the parser can be refined to handle new edge cases.

Q: How do I start if I don’t run Nextcloud? A: The architecture hinges on a sync-capable task/calendar store. You can adapt the system to other CalDAV-compatible hosts or use a lightweight server to expose an endpoint that your phone can edit (for example, via a web form or a different task client).

Q: Can I use this with imperial units (lbs) instead of kilograms? A: Yes. The parser and core can handle both units; normalize units during preprocessing and keep the stored values in a consistent base. Support for both units is a matter of parser rules and UI preferences.

Q: How customizable is the progression logic? A: Very. The functional core separates rules from data. You can implement simple linear percentage increases, more sophisticated autoregulation (RPE-based), or entirely different strategies. Unit tests validate behavior before deployment.

Q: Are there privacy risks running this on my Nextcloud instance? A: Running your own Nextcloud gives you control over where data resides. Standard security measures—strong passwords, TLS, and limited service exposure—apply. The backend should follow secure credential storage and minimal permissions.

Q: How do I handle split routines and non-weekly microcycles? A: The data model supports flexible microcycle length and variable workout counts per microcycle. Scheduling logic in the shell maps microcycle dates to CalDAV tasks; set your preferred microcycle length, and the backend will schedule tasks accordingly.

Q: What about syncing latency—what if I update notes mid-week and the cron job ran earlier? A: Schedule the cron job at a time that matches your workflow (e.g., run nightly). If immediate feedback is needed, trigger the backend manually or add a webhook that the phone can call after workout completion.

Q: Where can I find the code? A: Prototype repositories include:

• https://github.com/Schroedingberg/romance-progression
• https://github.com/Schroedingberg/progressive
• https://github.com/Schroedingberg/barbiff
• https://github.com/Schroedingberg/muscleapi

Q: Who should consider a commercial app instead? A: Those who prioritize a single, polished mobile experience with integrated social features, coaching support, or whose priority is zero-setup simplicity will likely prefer a commercial solution. This architecture targets users who prefer control, experimentability and low-maintenance ownership.

Q: How do I validate that the progression rules are working? A: Keep test datasets with known inputs and expected outputs; write unit tests for the core. Monitor real training data for expected trends: progressive increases in load and volume, improvements in reps, and consistent deload intervals.

Q: Can coaches use this to manage multiple athletes? A: Yes. The core can be extended to support multiple athlete profiles, each with their own task lists or CalDAV calendars. The backend can iterate through athlete configs and perform orchestration per profile.

Q: Will the parser handle supersets or circuits where multiple exercises are logged together? A: Supersets complicate the mapping between set subtasks and exercise contexts. Best practice is to use separate subtasks per exercise-set even within supersets. If users prefer combined notes, the parser needs context-aware rules that split multi-exercise lines; this is feasible but requires more complex grammar.

Q: Is there support for auto-generating warm-up sets and load calculators (e.g., 1RM-based percentages)? A: Warm-up generation and 1RM-based prescriptions are natural extensions. The core can compute projected 1RM from recent data and generate warm-up sets as part of the microcycle creation step.

Q: How do I incorporate tempo, rest periods, and other qualitative set parameters? A: Extend the microlanguage with optional tokens for tempo (“t 3-1-1”), rest (“r 90s”), or add structured fields in exercise notes. Keep the language minimal and consistent to avoid complexity during parsing.

Q: What about community-sourced mesocycle templates? A: Templates can be exported as microcycle definitions (JSON or EDN) and shared. Users import them into Nextcloud and the backend populates tasks. Templates become a library of starting points that the system adapts to personal baselines.

Q: How does this approach handle long-term periodization? A: Periodization is modeled as mesocycles composed of microcycles. The core can implement macros: alter intensity, volume and exercise selection on a mesocycle granularity and schedule deloads. Each mesocycle is generated from the previous one using explicit rules, preserving historical continuity.

Q: Can the system handle cardio or conditioning sessions? A: Yes. Treat conditioning as an exercise category with different progression rules (e.g., time/distance rather than weight/reps). The microlanguage can be extended to represent time-based entries: "20:00" for 20 minutes or "5k 25:00" for time.

Q: What happens if I change the exercise list mid-mesocycle? A: Keep changes idempotent: when the backend detects structural changes mid-cycle, it should treat the new exercises as additions with empty histories and preserve completed work for removed exercises. Manual review may be needed for significant reconfiguration.

Q: Is there a plan for a web dashboard to visualize and audit entries? A: A lightweight dashboard is a logical enhancement. It can be built on the same core API to display recent microcycles, flags, parser warnings and subjective feedback. The core separates data and presentation, making such an interface straightforward to add.

Q: How steep is the technical barrier to get started? A: Basic setup requires running a small backend script and a Nextcloud instance. The repositories include prototypes to help bootstrap the system. Familiarity with hosting, cron jobs and CalDAV configuration is helpful but not strictly necessary if you use a hosted CalDAV provider.

Q: Can I run the whole stack locally without a server? A: Yes. You can run a lightweight CalDAV server locally or adapt the system to use local files for input and output as a development-mode substitute. The core functions remain the same.

Q: How does the system avoid encouraging reckless loading? A: Conservative default increments, multi-week confirmation before aggressive increases, and the inclusion of subjective recovery data keep progression safe. The system defaults to small, gradual steps rather than aggressive jumps.

Q: Are there privacy controls for shared workouts or coaching? A: If shared with a coach, limit CalDAV sharing permissions to a dedicated list that contains only the relevant workouts. Use Nextcloud’s share controls to grant and revoke access. Shared data should be kept minimal and exclude unnecessary personal files.

Q: What should I do if I want to contribute? A: Clone the repositories, run unit tests for the core, and submit pull requests for parser improvements, additional progression strategies, or integrations with other clients. Contributions that expand parsing robustness or analytics capabilities are particularly valuable.