Plan adjust

Plan adjust

A plan that can't bend gets abandoned. Your job is to bend it without breaking it: change exactly what needs changing, keep every structural guarantee intact, and — the cardinal rule — describe the result from what the file actually says after the write, never from what you intended to write.

Prefer adjusting over rebuilding. Regenerate from scratch (plan-builder) only when the goal or race itself changes; everything else is an adjustment.

When to run

• The athlete asks directly: "move Thursday's tempo to Saturday", "this week is too much", "I was sick all week", "make the plan harder", "swap Wednesday for a bike ride", "I can only run 3 days now".
• weekly-review produced an adjustment suggestion (completion < 60% → reduce frequency; the same weekday repeatedly skipped → move that workout; skips citing fatigue → reduce volume; ≥ 80% completion → leave the plan alone).
• The athlete has missed 3+ consecutive scheduled training days (rest and cross-train-only days count neither way): offer a reconfigure once, and if declined, don't offer again for 7 days.

Inputs

• athlete/plan.json — the canonical plan. No active plan → offer plan-builder instead.
• athlete/profile.md — schedule constraints and declared units.
• athlete/log.json — completion and actuals context (what's driving the adjustment).
• Reference: reference/training-rules.md ("Plan adjustment rules", "The whole-mile rule and other invariants", "Strength programming"), reference/safety.md.

Procedure

1. Dates first

Compute today with date +%F and build the weekday↔date table for this week and next (the COACH.md ritual). Every day you touch is identified by its date and weekday, both read from the table. "Next Monday" computed in your head is how the wrong workout gets moved.

2. Choose the tier

Tier 1 — single-day edit: the request names one day and stays on it. Change a workout's date, distance, duration, type, or details. Apply directly.

Tier 2 — plan-wide adjustment: anything touching multiple days or weeks. Classify it before acting:

Type	Meaning
reschedule	move workouts to different days, content intact
reduce_volume	scale run miles or lift sets/duration down by a stated percent
increase_volume	scale up, within progression limits
swap_workout	replace one session type with another
skip_and_adapt	absorb missed sessions; redistribute what matters, drop what doesn't
reprioritize	shift emphasis between running and lifting
change_frequency	change training days per week, every remaining week
custom	anything else — state your interpretation before applying

3. Tier 1 — single-day edit

1. Locate the day in plan.json by date. If the named day holds only a Rest day, correct the premise instead of silently moving the rest row: "Thursday's actually a rest day — your next session is Friday's tempo. Want me to move that?" If multiple candidates match a fuzzy description, ask one clarifying question.
2. Edit that one day object in python, respecting constraints 8–12 below. Moving a day within its week: the content travels intact; update date and weekday together, and re-sequence the week's days so it stays Mon–Sun ordered.
3. Re-validate the affected week: segment sums and weekly_miles = day sum always; whole-mile totals and the 48 h lower-body/hard-run spacing as the athlete has them set — a deviation they chose is recorded, not reverted.
4. Re-render athlete/PLAN.md from plan.json (projection conventions per templates/PLAN.example.md).
5. Re-read the changed week from the file and confirm from it: "Done — tempo is now Saturday 07-11, Thursday 07-09 is rest."

4. Tier 2 — plan-wide adjustment

1. Read the full future scope: every day from today through meta.end_date. Days in the past and days with status completed or skipped are read-only history — adjustments apply today-forward only, and history is context for the redesign, never a casualty of it.
2. Draft the modification set before touching the file: a one-line summary plus explicit lists of updates (day, field, old → new), deletes, and inserts. Every insert that replaces a day pairs with a delete of what was there. If the request is ambiguous in a way that changes the outcome materially ("reduce volume" — by how much?), ask one question; otherwise state your interpretation in the summary and proceed.
3. Apply in one python pass. Recompute every touched week's weekly_miles and re-title/re-describe any day whose content changed.
4. Re-run the full invariant checklist from the plan-builder skill — arithmetic and structural integrity (segment sums, week sums, weekday↔date agreement, rest-day preferences) always; preference and methodology rules (whole miles, progression limits, 48 h spacing) as the athlete has them set. A failed arithmetic check means fix and re-run — never leave plan.json arithmetically broken, and never present it that way. A preference-rule deviation the athlete chose gets recorded in meta.methodology, not silently reverted.
5. Update meta: days_per_week for frequency changes; user_preferences for new firm constraints or priorities; append a dated one-liner to meta.methodology ("2026-07-06: cut W6–W8 volume 20% — illness recovery").
6. Re-render athlete/PLAN.md.
7. Verify, then narrate: re-read plan.json and describe the next two weeks only from what the file now contains. If you deliberately limited scope (say, only restructured through week 10 of 16), say so explicitly rather than implying the whole plan changed.

5. The adjustment constraints

These thirteen rules are the contract (canonical statement in reference/training-rules.md, "Plan adjustment rules"):

1. Minimize disruption — modify only what the request requires; every untouched day stays byte-identical.
2. Keep the plan's structure — phases, cutback weeks, and taper survive unless they are the target of the request.
3. Reschedules move days intact — type, title, prescription, and strength cue travel with the date.
4. Volume changes scale honestly — cut or grow run miles, or lift sets/duration, by the stated percent, then re-fit sessions to the whole-mile rule and recompute weekly totals.
5. Reprioritizing reorders emphasis, not identity — protect the prioritized modality's key sessions, trim the other's, and record the new priority in meta.user_preferences.
6. skip_and_adapt redistributes, never crams — carry forward the most important missed work (long run first, then quality) without overloading any single day or pushing a week past progression limits; let the rest go.
7. Frequency changes apply to every remaining week — not just the next one.
8. Never schedule heavy lower-body lifting within 48 hours of a hard run (Tempo, Interval, Long, Race) — in either order.
9. Edit days in place for field changes — a moved or resized workout keeps its day-object identity; wholesale replacement is only for discipline changes.
10. Retyping to a run or lift demands complete content — a day becoming a run needs workout, pace_zone, and mileage fields; a day becoming a lift needs duration_min and lift_details with real exercises. A hollow retype is invalid. Retyping in place is only safe toward Rest or Cross-Train.
11. Rest days are clean — no miles, duration_min: null, and stale run/lift fields stripped when a day becomes Rest.
12. No orphaned days — every scheduled non-rest day ends the edit with a prescription and a duration or mileage; every replacing insert pairs with a delete.
13. Summarize clearly — the athlete hears what changed, what didn't, and why, in plain language.

These constraints discipline the coach, not the athlete. If the athlete explicitly asks for something a training guardrail here would block — say, heavy legs the day before their long run — give one concise, specific risk note; if they confirm, make the change their way, record it in meta.user_preferences, and don't re-warn on later edits. (The data-integrity constraints — 9 through 12 — aren't about athlete choices and always hold.)

Rules

• Narrate the file, not your intent. "The plan now shows…" must be literally true of athlete/plan.json at the moment you say it. The single worst failure mode of this skill's ancestors was announcing schedule changes that were never written.
• Completed and skipped days are immutable history. So are their actual blocks.
• plan.json stays canonical; PLAN.md and the dashboard are regenerated projections. Offer to refresh the dashboard after any adjustment.
• All date math, mileage scaling, and sums run in python.
• Destructive requests — archiving or abandoning the plan — get a one-line confirmation first ("Archive your marathon plan? It has 6 weeks left."), then set meta.status: "archived". See reference/safety.md.
• If the athlete reports pain or injury as the reason for adjusting, adjust conservatively and apply the injury rules in reference/safety.md — reduced volume is not a treatment plan.
• Only claim "adjusted" or "moved" after the file write happened this turn.

Output

Show: the one-line summary, a compact diff of changed days (date · was → now), the verified next-two-weeks schedule read back from the file, and the invariant-check result.

Then suggest 2–3 next actions (skip if you just asked a question): regenerate the dashboard (dashboard), sync activities so completions stay current (strava-sync), or a morning daily-checkin to walk the new week.