paicer 0.1.0__tar.gz

paicer-0.1.0/.claude/commands/paicer/create-plan.md

@@ -0,0 +1,53 @@
+# Create or Edit Training Plan
+
+Help the user create a new training plan or modify an existing one.
+
+**Invoke the `plan-authoring` skill** for YAML structure, unit conventions, Garmin patterns, and periodization principles.
+
+## First-Time Setup
+
+No setup file needed — paicer saves config to `~/.paicer/config` automatically on first run.
+
+## Creating a New Plan
+
+Interview the user **one question at a time**. Wait for each answer before asking the next.
+
+1. What are you training for? (race distance, goal date, first time?)
+2. Current fitness? (recent volume, longest recent run/ride, recent races?)
+3. How many days per week, and which days?
+4. What sports? (running only, triathlon, cycling?)
+5. Equipment? (Garmin watch model, power meter, pool access?)
+6. Current easy pace? (Adapt to their sport. Calculate race paces from any race results — don't ask them to do the math.)
+
+If they have a Garmin watch: tell them to run `paicer sync w1` after the plan is ready — it will prompt for credentials on first use. Do NOT ask for credentials directly.
+
+## Plan Length and Start Date
+
+Calculate weeks until race day, then recommend:
+
+- Standard lengths: 8, 10, 12, 16, 20 weeks (pick longest that fits)
+- Minimum: 8 weeks for 5K/10K, 12 for half marathon, 16 for marathon/triathlon
+- `start_date` should be a Monday, counting back from race day
+- More time than needed? Start later, don't pad.
+
+Present: "You have N weeks until race day. I'd recommend an X-week plan starting [date]." Always confirm with the user.
+
+## Building the Plan
+
+1. Read the appropriate reference plan: `examples/reference-metric.yaml` or `examples/reference-imperial.yaml`
+2. Create plan file in `plans/`
+3. Design phase structure (Base -> Build -> Peak -> Taper)
+4. Build week-by-week with progressive volume
+5. Add Garmin structures with YAML comments in user's unit system
+6. Create YAML anchors for reusable sessions (swim, track)
+7. Preview: `paicer render --plan plans/new-plan.yaml` (saves plan path to config, fails loudly if YAML is invalid)
+8. Offer first week sync: `paicer sync w1`
+11. If Garmin set up: suggest `/paicer:review-progress` after first week of training
+
+## Modifying an Existing Plan
+
+1. Read plan path from `~/.paicer/config` (key: `plan`)
+2. Back up: `cp plans/my-plan.yaml plans/my-plan.backup.yaml`
+3. Make edits, preserving sequential numbering and naming conventions
+4. Preview: `paicer render` to confirm the YAML is valid
+5. If Garmin workouts changed, remind user to re-sync affected weeks

paicer-0.1.0/.claude/commands/paicer/review-progress.md

@@ -0,0 +1,58 @@
+# Training Plan Weekly Review
+
+Compare last week's Garmin activities against the plan and discuss adjustments.
+
+**Invoke the `plan-authoring` skill** for unit conventions and pace conversion reference.
+
+## Steps
+
+Read `units` from `~/.paicer/config` (default: `metric`). Present all values in the user's preferred system.
+
+1. Read `plan` path from `~/.paicer/config`, then read the plan YAML using Read tool (do NOT write scripts to parse YAML).
+2. Pull review data:
+   ```
+   uv run python -m paicer.review_data <plan_path>    # most recently completed week
+   uv run python -m paicer.review_data <plan_path> 3  # specific week number
+   ```
+3. Match activities by `activityName` against `W{week_num}: {name}` (prefixed format from Garmin upload). Do NOT match by date — users often shift days.
+4. Analyze using the `intervals` array — NOT overall activity averages. Each interval has `type` (INTERVAL_WARMUP, INTERVAL_ACTIVE, INTERVAL_RECOVERY, INTERVAL_COOLDOWN), `paceSecPerKm`, `averageHR`, `averagePower`, `distance`, `duration`.
+   - **Structured workouts (tempo, intervals):** Compare INTERVAL_ACTIVE entries against targets. Overall average is misleading (includes warmup/cooldown).
+   - **Easy runs:** May only have INTERVAL_ACTIVE or no intervals. Use overall average.
+   - **Elevation context:** Check `elevationGain`/`elevationLoss` on every activity. Hilly runs raise HR at the same effort — don't flag elevated HR without accounting for elevation. Mention gain when it's notable (>5 m/km).
+   - **Running with pace targets:** compare each INTERVAL_ACTIVE pace vs planned, note HR
+   - **Running with HR targets:** compare INTERVAL_ACTIVE HR vs target zone
+   - **Cycling with power targets:** compare INTERVAL_ACTIVE power vs target zone
+   - **Swimming:** completion check (did the session happen?)
+   - **Distance:** actual vs planned
+   - **HR time in zones** (`hrTimeInZones`): Use to verify easy runs stayed in Zone 1–2. If zone 3+ time exceeds ~10% of duration on an easy run, flag it (accounting for elevation). For tempo/interval workouts, zone distribution confirms effort matched intent.
+   - **Aerobic training effect** (`aerobicTrainingEffect`): 1–5 scale. Easy runs should be 2.0–3.0 ("maintaining"). Tempo/intervals 3.0–4.0 ("improving"). Long runs 3.0–4.5. Flag if an easy run scores >3.5 (too hard) or a key session scores <2.5 (too easy). Useful as a weekly load summary — sum or average across sessions to gauge overall training stress.
+   - **Training status** (`trainingStatus`): Included at top level of review data. Report:
+     - **Acute-to-chronic ratio**: optimal 0.8–1.5. Below 0.8 = detraining. Above 1.5 = overreaching risk. If above 1.3, note it as something to watch.
+     - **Load balance feedback**: Garmin's own assessment (e.g., ABOVE_TARGETS, WITHIN_TARGETS). If above targets, discuss whether next week should be lighter.
+     - **VO2max trend**: note if it changed from previous review.
+     - **Training status phrase**: e.g., PRODUCTIVE, MAINTAINING, OVERREACHING. Flag non-productive states.
+5. For unmatched workouts: check for other activities that might be the same workout done under a different name. Ask user to confirm before using.
+6. Flag mismatches: HR too high/low at target pace, missed workouts, distance deviations.
+7. Present findings conversationally. Discuss adjustments.
+8. If pace adjustments agreed, update `targetValueOne`/`targetValueTwo` and descriptions in YAML.
+9. Add review entry:
+   ```yaml
+   reviews:
+     - week: N
+       date: "YYYY-MM-DD"
+       notes: "Summary"
+       adjustments:
+         - "Description of each change"
+   ```
+
+   **Notes content:** stick to training-relevant facts — pace, HR, power, distance, elevation, completion vs plan, perceived effort, weather if it affected execution, illness/injury that affected sessions. Allergies are fine to mention if they affected training. **Skip lifestyle context** like alcohol consumption, social events, work stress, or other personal details that are not training data — even when the user mentions them in chat. The plan log is a training record, not a journal.
+
+10. Run `paicer render` to confirm the YAML is valid after edits.
+
+## Race Week (special handling)
+
+When the upcoming week contains a race, the standard review flow still applies — but **race-week conversations must lead with the HR ceiling rule, not with fueling/kit/course details.** See the "Race Strategy and Execution Priorities" section of the `plan-authoring` skill for the priority order.
+
+The single highest-leverage piece of race-day advice is: *"Stay below the HR ceiling until the release km. Then push."* If that gets buried under gel timing, breakfast composition, and kit selection conversations, the user loses the race in execution even when training is fit. Make it the headline of every race-week message.
+
+If the race workout has a `race_strategy:` field, surface its `one_liner` prominently in every race-week conversation.

paicer-0.1.0/.claude/skills/plan-authoring.md

@@ -0,0 +1,177 @@
+---
+name: plan-authoring
+description: Use when creating, editing, or reviewing training plan YAML - covers structure rules, unit conventions, Garmin patterns, workout types, and periodization principles
+---
+
+# Plan Authoring
+
+Reference for writing correct training plan YAML. Used by `/paicer:create-plan`, `/paicer:review-progress`, and ad-hoc plan edits.
+
+## Unit System
+
+Read `UNITS` from `.env` (default: `metric`). Use for all text fields (`name`, `description`) and YAML comments on Garmin values.
+
+Garmin steps always use metric (meters, sec/km). Add comments in the user's system: `endConditionValue: 6437  # 4 mi`.
+
+**Imperial conventions** — use clean round numbers, not conversions:
+- Runs: 3, 4, 5, 6, 8, 10, 13, 16, 20 miles
+- Bikes: 10, 15, 20, 25, 40 miles
+- Paces: round to nearest :15 (7:30, 7:45, 8:00/mi)
+- Swim: yards for US pools (200, 500, 1000 yds)
+- Track: stays in meters (400m tracks are universal)
+
+## YAML Structure Rules
+
+- Single `start_date` — all dates calculated from it
+- Day numbers = 1-based positions in `training_days`, not weekday names
+- Days must be sequential within a week (1, 2, 3... no gaps except same-day pairs)
+- Non-optional workouts must not exceed `training_days` slots
+- Week/day numbers sequential within their parent
+- `name`: descriptive with distance/workout info (e.g., "Easy 8km", "Tempo 3x8min"). Week prefix added at Garmin sync time.
+
+## Workout Types
+
+| Type | Garmin Sport | Notes |
+|------|-------------|-------|
+| `run` | running (1) | HR zone for easy, pace targets for tempo/intervals |
+| `track` | running (1) | Reusable via YAML anchors |
+| `bike` | cycling (2) | See cycling target rules below |
+| `swim` | swimming (4) | Lap-button cue cards with `description` per step |
+| `multisport` | multi_sport (10) | `garmin.legs`, each with `sport` + `steps` |
+| `race` | — | Race day entry, typically `skip_garmin: true` |
+
+## Flags
+
+- **`optional: true`** — shows as "Optional:" in docs, doesn't count against training_days. If it has a `garmin:` section, uploads to library without scheduling. Doesn't override `skip_garmin`.
+- **`skip_garmin: true`** — no Garmin upload at all.
+
+## Cycling Target Rules
+
+Garmin evaluates power zone targets against 3-second average power. On undulating outdoor terrain, this causes constant out-of-zone alerts regardless of actual effort — and the visual deviation banners obscure the data screens you actually want to see. The Garmin Connect API does not support configuring a longer averaging window.
+
+Power is still the right measurement for hard cycling intervals when a power meter is present. The fix is to keep the structured workout shape but stop letting Garmin enforce target zones on the bike. The user paces by feel + lap-average power on the data screen, and gets clean post-ride power data for analysis.
+
+**Use `heart.rate.zone` for:**
+- All steady-state / endurance cycling (single-interval rides at zone 2–3)
+- Warmup and cooldown steps in steady rides
+- Brick workout bike legs that are steady-state at Z2/Z3
+
+**Use `no.target` with `description` for:**
+- Any step that would otherwise have a `power.zone` target (threshold, VO2, surge intervals, hard brick blocks)
+- Warmup/cooldown of structured power workouts (so the entire workout is banner-free, not just the work intervals)
+
+**Description format (Fenix/Edge display fits ~30–40 chars cleanly):**
+```
+"<duration> @ Z<n> (RPE <n>)"
+```
+Examples: `"5 km @ Z2 (RPE 5)"`, `"6 min @ Z3 (RPE 6)"`, `"1 min @ Z5 (RPE 9)"`.
+
+Don't include explicit watt numbers — FTP changes over time and the zone label remains correct as long as zones are kept current. The user reads the description, glances at lap power, paces accordingly. Recorded power data still supports post-ride analysis; what's lost is real-time zone enforcement (which was never reliable outdoors anyway).
+
+**Why HR works for steady cycling:** HR naturally smooths terrain-induced fluctuations. On a hilly loop, power spikes uphill and drops downhill, but HR stays in zone if effort is consistent. Same logic as running easy runs with HR targets. HR-targeted bike steps don't trigger banner spam because heart rate physiologically lags terrain.
+
+**Roadmap:** for users without a power meter, the right pattern is to use `heart.rate.zone` targets across all bike steps including hard intervals. Plan generation should detect power-meter availability and pick the appropriate target type. Not yet implemented — current plans assume a power meter for the bike.
+
+## Garmin Step Patterns
+
+Read `examples/reference-metric.yaml` (or `reference-imperial.yaml`) for working examples of every pattern. Read `docs/garmin-api.md` for complete API reference.
+
+**Common patterns:**
+- Easy run: single `interval` step + `heart.rate.zone` zone 2
+- Steady bike: single `interval` step + `heart.rate.zone` zone 2–3
+- Bike intervals: `warmup` (HR zone) + `repeat` group (HR recovery + power work) + `cooldown` (HR zone)
+- Tempo: `warmup` + `repeat` group (work + recovery) + `cooldown`
+- Swim: `lap.button` + `description` per step, `rest` steps between sections
+- Multisport: `garmin.legs` array, each leg has `sport` + `steps`
+- Reusable sessions: YAML anchors in `swim_sessions:` / `track_sessions:` blocks
+
+## Periodization Principles
+
+- **Progressive overload:** +5-10% volume/week, recovery week every 3-4 weeks
+- **Polarized intensity:** ~80% easy (RPE 4-5), ~20% hard (RPE 7-9), minimal grey zone
+- **Specificity:** Training mirrors race demands as plan progresses
+- **Taper:** 2-3 weeks before race, -30-50% volume, maintain intensity
+- **Rest sequencing:** Rest day after long/hard sessions. Easy before hard, rest after hard/long.
+- **Phase structure:** Base (aerobic) -> Build (race-specific) -> Peak (sharpening) -> Taper
+
+## Race Strategy and Execution Priorities
+
+**Race outcome is determined more by execution discipline than by training. Race-day decisions are not equal weight.** When advising on race week, lead with the single rule that decides 80% of the outcome: **HR ceiling discipline**.
+
+### Priority order (by impact on finishing time)
+
+1. **HR ceiling discipline** (saves or costs 5–15 min) — set a hard cap below LTHR, hold it religiously until the release km, push only in the final stretch
+2. **Pacing strategy first 5 km** (saves or costs 3–8 min — tied to #1) — let people pass you, ignore corral pressure, run by HR not by feel
+3. **Fueling** (saves or costs 2–5 min in late race) — gel timing aligned with aid stations, tested in training
+4. **Kit / chafe management** (saves or costs 1–3 min from comfort) — singlet, socks, shorts all tested
+5. **Hydration** (saves or costs 1–2 min) — sip at every aid station from km 8+, pour on head if warm
+6. **Carb load** (saves or costs 1–2 min) — single solid carb-load day before race for HM, longer for marathon
+7. **Sleep** (background factor) — bank sleep Wed/Thu; Friday night sleep matters less than people think
+8. **Course strategy details** (saves or costs <1 min in good conditions) — useful color, not the main lever
+
+### HR ceiling rule (the headline)
+
+- **HM:** HR cap ≈ LTHR − 9 to −12 bpm. Hold until km 16 (last 5 km). Then lift cap, push by feel.
+- **Marathon:** HR cap ≈ LTHR − 16 to −20 bpm. Hold until km 32 (last 10 km). Lift cap, but stay below LTHR until last 5 km.
+- **10K:** HR cap ≈ LTHR − 3 to −5 bpm. Hold until km 7, push.
+- **5K:** HR cap doesn't really apply — run by feel.
+
+Race-day HR for the same pace typically runs 5–8 bpm higher than training HR. Plan for this. The training-day "5:00/km at HR 168" becomes race-day "5:00/km at HR 173–176."
+
+**Time-to-failure at intensities near threshold:**
+- At LTHR: ~60 minutes sustainable
+- LTHR + 5 bpm: ~30 minutes
+- LTHR + 10 bpm: ~10 minutes
+
+This is why HM at threshold = bonk-by-km-15. Run 5+ bpm below threshold and time-to-failure extends to 3+ hours.
+
+### `race_strategy` YAML field
+
+For any `race` type workout, include a `race_strategy:` block. Renderers display this prominently for race week:
+
+```yaml
+- day: 6
+  type: "race"
+  name: "RACE: Brooklyn Half Marathon"
+  skip_garmin: true
+  description: "Race description, course notes, etc."
+  race_strategy:
+    hr_cap: 165
+    cap_release_km: 16
+    one_liner: "Stay below HR 165 until km 16. Then push."
+    notes: |
+      Hilly first 5 km (Prospect Park). Don't chase corral pace.
+      Race-day HR runs 5-8 bpm above training HR — recalibrate in moment.
+      Fueling: 2 SiS gels at aid stations after km 5 and km 14.
+```
+
+**Required fields:**
+- `hr_cap` (int): the HR ceiling for the body of the race
+- `cap_release_km` (int): km marker where the ceiling lifts
+- `one_liner` (str): the one rule to remember on race day
+
+**Optional fields:**
+- `notes` (str): course-specific context (hills, weather, fueling reminders)
+- `target_time` (str): for context, not for pacing — e.g., `"1:45"`
+- `target_pace` (str): goal pace if HR cap allows — e.g., `"5:05/km"` (HR governs, not pace)
+
+### What NOT to lead with in race-week conversations
+
+These are real considerations but should never displace the HR ceiling rule:
+- Gel brand/timing minutiae
+- Carb load gram counts
+- Breakfast composition
+- Kit selection
+- Course-guide course-by-course narrative
+
+Cover them, but make the HR rule the headline of every race-week conversation.
+
+## Pace Conversion
+
+Garmin pace values are sec/km. Convert: `5:25/km = 325 sec/km`.
+
+To min/mi: multiply sec/km by 1.60934. Example: 325 sec/km = 523 sec/mi = 8:43/mi.
+
+## Validation
+
+Always run `make test` after changes. It validates YAML syntax, Python, and plan structure (day ranges, training_days counts).

paicer-0.1.0/.env.example

@@ -0,0 +1,18 @@
+# Unit system (metric or imperial). Also sets paper format (a4 or letter).
+UNITS=metric
+
+# Plan file (set after running /paicer:create-plan)
+# PLAN=plans/my-plan.yaml
+
+# Override paper format if your printer doesn't match your unit system.
+# FORMAT=letter
+
+# Pool swim distance tracking:
+#   auto  — watch measures distance via stroke detection (needs good form)
+#   drill — each segment is a drill; you enter distance after each lap button press
+# SWIM_TRACKING=auto
+
+# Workout integration (uncomment if using Garmin)
+# WORKOUT_INTEGRATION=garmin
+# GARMIN_EMAIL=your-email@example.com
+# GARMIN_PASSWORD=your-password-here

paicer-0.1.0/.github/workflows/publish.yml

@@ -0,0 +1,37 @@
+name: Publish to PyPI
+
+on:
+  release:
+    types: [published]
+
+jobs:
+  publish:
+    runs-on: ubuntu-latest
+    environment: pypi
+    permissions:
+      id-token: write
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Verify tag matches pyproject.toml version
+        run: |
+          TAG="${{ github.event.release.tag_name }}"
+          VERSION=$(grep '^version' pyproject.toml | sed 's/version = "\(.*\)"/\1/')
+          if [ "$TAG" != "$VERSION" ]; then
+            echo "Release tag '$TAG' does not match pyproject.toml version '$VERSION'"
+            exit 1
+          fi
+
+      - uses: actions/setup-python@v5
+        with:
+          python-version: "3.12"
+
+      - name: Install build tools
+        run: pip install hatchling build
+
+      - name: Build package
+        run: python -m build
+
+      - name: Publish to PyPI
+        uses: pypa/gh-action-pypi-publish@release/v1

paicer-0.1.0/.gitignore

@@ -0,0 +1,38 @@
+# Python
+__pycache__/
+*.py[cod]
+*$py.class
+*.so
+.Python
+
+# Virtual environments
+.venv/
+venv/
+ENV/
+
+# Generated files
+output/
+
+# User plans (generated by /paicer:create-plan)
+plans/
+
+# Env files
+.env
+
+# Garmin tokens
+.garmin_tokens
+
+# yaks data directory
+.yaks
+
+
+# IDE
+.vscode/
+.idea/
+*.swp
+*.swo
+*~
+
+# OS
+.DS_Store
+Thumbs.db

paicer-0.1.0/.python-version

@@ -0,0 +1 @@
+3.14

paicer-0.1.0/CHANGELOG.md

@@ -0,0 +1,58 @@
+# Changelog
+
+## 2026-03-15
+
+- Add training status to review data (VO2max, load balance, acute-to-chronic ratio)
+- Add HR time in zones and aerobic training effect to review data
+- Add elevation gain/loss to review data and skill
+- Update review skill to interpret all new metrics
+- Fix inaccurate distance totals in tempo workout descriptions
+- Smooth long run progression (12 → 14 → 15 → 17 → 16 → 18 → 19 → 18 → 20 → 19 → 16 → Race)
+- Add strides to W4, W5, W8, W10, W11 (every non-race week now has strides)
+- Add introductory comment to hm-tri-combo.yaml example
+
+## 2026-03-14
+
+- Fix advanced example plan (hm-tri-combo): remove duplicate workouts, correct step ordering
+
+## 2026-03-12
+
+- Fix plan formatting across all example plans (descriptions, date displays, en dashes)
+
+## 2026-03-11
+
+- Extract plan-authoring knowledge into shared skill (used by both create-plan and review-progress)
+- Rename commands to `paicer/create-plan` and `paicer/review-progress`
+- Fix hm-tri phase 1 training day assignments
+
+## 2026-03-10
+
+- Add imperial unit system support (pace in min/mile, paper format switches to letter)
+- Add optional workout support (`skip_garmin: true` for strength/rest days)
+- Add sport labels (emoji in HTML, text in Markdown) and plan validation
+- Add imperial reference example plan
+- Update README
+
+## 2026-03-08
+
+- Add coaching commands: `/paicer:create-plan` and `/paicer:review-progress`
+- Add `review_data.py` for pulling Garmin activity data by plan week
+- Add Garmin API reference docs
+- Add CLAUDE.md project instructions
+- Move plans to `examples/` directory
+
+## 2026-03-04
+
+- Add multisport (brick) workout support for Garmin
+- Add track session support with reusable YAML anchors
+
+## 2026-03-03
+
+- Add cycling and swimming workout types
+- Expand hm-tri-combo plan with full Phase 2 (swim/bike integration)
+
+## 2026-02-22
+
+- Initial release: YAML plan parser, Markdown/HTML renderers, Garmin workout sync
+- Run-only support with tempo, interval, and easy run structures
+- Scope filtering (phase, week, day)

paicer-0.1.0/CLAUDE.md

@@ -0,0 +1,42 @@
+# Paicer
+
+Training plan tool: YAML plan → Garmin workouts + Markdown/HTML documents.
+
+## Architecture
+
+```
+src/
+  render_plan.py        — YAML → Markdown/HTML (entry point)
+  generate_workouts.py  — YAML → Garmin workouts with filtering
+  plan_utils.py         — Date calculation, YAML loading, plan validation, sport maps
+  formatters/           — Base class + MarkdownFormatter + HTMLFormatter
+  integrations/         — Base class + GarminIntegration
+examples/               — Example training plans
+plans/                  — User plans (gitignored, created by /paicer:create-plan)
+output/                 — Generated documents (gitignored)
+docs/                   — Garmin API reference, other docs
+```
+
+## Commands
+
+```bash
+make markdown                  # Generate Markdown
+make html                      # Generate HTML (A4 for metric, letter for imperial)
+make workouts SCOPE=w7         # Sync week 7 to Garmin
+make workouts SCOPE=w7d2       # Sync week 7 day 2
+make workouts SCOPE=p2         # Sync phase 2
+make workouts SCOPE=all        # Sync everything
+make test                      # Validate YAML, Python, and plan structure
+```
+
+Plan path is set in `.env` as `PLAN=plans/your-plan.yaml`.
+
+Set `UNITS=metric` or `UNITS=imperial` in `.env` to control the unit system used when creating or editing plans. Garmin steps always use metric internally. Text fields (`name`, `description`) and YAML comments use the preferred system.
+
+## Plan Authoring
+
+Invoke the `plan-authoring` skill for YAML structure rules, workout types, Garmin patterns, unit conventions, and periodization principles.
+
+Reference plans: `examples/reference-metric.yaml` and `examples/reference-imperial.yaml` demonstrate every pattern in a minimal 2-week plan.
+
+Garmin API: `docs/garmin-api.md` for step types, end conditions, target types, pace conversions.

paicer-0.1.0/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Tome Cvitan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

paicer-0.1.0/Makefile

@@ -0,0 +1,52 @@
+.PHONY: install test workouts markdown html all clean
+
+-include .env
+export
+
+UNITS ?= metric
+FORMAT ?= $(if $(filter imperial,$(UNITS)),letter,a4)
+SCHEDULE ?= 1
+
+define check_plan
+	@if [ -z "$(PLAN)" ]; then \
+		echo "No plan set. Set PLAN in .env or run /paicer:create-plan"; \
+		exit 1; \
+	fi
+	@if [ ! -f "$(PLAN)" ]; then \
+		echo "Plan file not found: $(PLAN)"; \
+		exit 1; \
+	fi
+endef
+
+install:
+	uv sync
+
+test:
+	$(check_plan)
+	@echo "Running tests..."
+	@uv run pytest -v
+	@echo "Validating plan..."
+	@uv run paicer render --plan $(PLAN) > /dev/null
+	@echo "✅ Plan valid"
+
+workouts:
+	$(check_plan)
+	@uv run paicer sync $(SCOPE) --plan $(PLAN) $(if $(filter 0,$(SCHEDULE)),--no-schedule)
+
+markdown:
+	$(check_plan)
+	@mkdir -p output
+	@uv run paicer render --plan $(PLAN) > output/training_plan.md
+	@echo "Created output/training_plan.md"
+
+html:
+	$(check_plan)
+	@mkdir -p output
+	@uv run paicer render --html --format=$(FORMAT) --plan $(PLAN) > output/training_plan.html
+	@echo "Created output/training_plan.html ($(FORMAT))"
+
+all: markdown html
+
+clean:
+	trash output/
+	trash __pycache__

paicer-0.1.0/PKG-INFO

@@ -0,0 +1,56 @@
+Metadata-Version: 2.4
+Name: paicer
+Version: 0.1.0
+Summary: Training plan tool: YAML to Garmin workouts and readable documents
+License-File: LICENSE
+Requires-Python: >=3.12
+Requires-Dist: click>=8.0
+Requires-Dist: garminconnect<0.3.0,>=0.2.40
+Requires-Dist: keyring>=24.0
+Requires-Dist: markdown>=3.10.2
+Requires-Dist: pyyaml>=6.0
+Description-Content-Type: text/markdown
+
+# p**ai**cer
+
+AI-powered training plan manager. Provide your race goals, schedule, and fitness level to create a plan, with structured workouts that can be synced to your Garmin watch. After each training week, run the progress review command to pull your Garmin activity and training status data, compare it against the plan, and adjust targets based on how your body is responding.
+
+**Disclaimer:** This tool is not a substitute for professional coaching or medical advice. Always listen to your body and consult a qualified professional for health or injury concerns.
+
+## Get Started
+
+```bash
+git clone https://github.com/cvitan/paicer && cd paicer
+```
+
+Open the project in Claude Code and run `/paicer:create-plan` to create a YAML-based training plan through a guided conversation. It handles setup, configuration, and walks you through the process.
+
+After each week of training, run `/paicer:review-progress` to review your plan progress and make any tweaks if needed. The review will also be appended to your plan for future reference.
+
+### Plan output options
+- **Markdown**
+- **HTML** — set up to print 1 wk/page
+- **Garmin** — sync scheduled structured workouts
+
+## Commands
+
+```bash
+make markdown               # Generate Markdown
+make html                   # Generate HTML (A4 for metric, letter for imperial)
+make workouts SCOPE=w7      # Sync week 7 to Garmin
+make workouts SCOPE=w7d2    # Sync specific workout
+make workouts SCOPE=p2      # Sync entire phase
+make test                   # Validate plan
+```
+
+## Supported Sports
+
+Running, cycling, swimming (pool and open water), track sessions, and multisport/brick workouts (bike + run with transition tracking). Requires a Garmin watch — multisport needs a compatible model (Fenix, Forerunner 570/970, Enduro).
+
+## Roadmap
+
+1. **Strava activity enrichment**
+2. **Zwift Integrations**
+3. **Additional Formats** - PDF, iCal, JSON, CSV export
+4. **HR-zone fallback for cycling** - generate bike workouts with `heart.rate.zone` targets for users without a power meter (current plans assume one)
+5. **Ad-hoc activity data tool** - extend `src/review_data.py` or add `src/activity_data.py` with `--activity-id`, `--latest N`, `--from-date/--to-date` flags so single-activity / cross-week queries don't require throwaway scripts. Expose `get_activity_typed_splits` as the primary intervals fetch.

paicer-0.1.0/README.md

@@ -0,0 +1,43 @@
+# p**ai**cer
+
+AI-powered training plan manager. Provide your race goals, schedule, and fitness level to create a plan, with structured workouts that can be synced to your Garmin watch. After each training week, run the progress review command to pull your Garmin activity and training status data, compare it against the plan, and adjust targets based on how your body is responding.
+
+**Disclaimer:** This tool is not a substitute for professional coaching or medical advice. Always listen to your body and consult a qualified professional for health or injury concerns.
+
+## Get Started
+
+```bash
+git clone https://github.com/cvitan/paicer && cd paicer
+```
+
+Open the project in Claude Code and run `/paicer:create-plan` to create a YAML-based training plan through a guided conversation. It handles setup, configuration, and walks you through the process.
+
+After each week of training, run `/paicer:review-progress` to review your plan progress and make any tweaks if needed. The review will also be appended to your plan for future reference.
+
+### Plan output options
+- **Markdown**
+- **HTML** — set up to print 1 wk/page
+- **Garmin** — sync scheduled structured workouts
+
+## Commands
+
+```bash
+make markdown               # Generate Markdown
+make html                   # Generate HTML (A4 for metric, letter for imperial)
+make workouts SCOPE=w7      # Sync week 7 to Garmin
+make workouts SCOPE=w7d2    # Sync specific workout
+make workouts SCOPE=p2      # Sync entire phase
+make test                   # Validate plan
+```
+
+## Supported Sports
+
+Running, cycling, swimming (pool and open water), track sessions, and multisport/brick workouts (bike + run with transition tracking). Requires a Garmin watch — multisport needs a compatible model (Fenix, Forerunner 570/970, Enduro).
+
+## Roadmap
+
+1. **Strava activity enrichment**
+2. **Zwift Integrations**
+3. **Additional Formats** - PDF, iCal, JSON, CSV export
+4. **HR-zone fallback for cycling** - generate bike workouts with `heart.rate.zone` targets for users without a power meter (current plans assume one)
+5. **Ad-hoc activity data tool** - extend `src/review_data.py` or add `src/activity_data.py` with `--activity-id`, `--latest N`, `--from-date/--to-date` flags so single-activity / cross-week queries don't require throwaway scripts. Expose `get_activity_typed_splits` as the primary intervals fetch.