Playwise Training Plan

What does Playwise Training Plan do?

Based on long-term health, build comprehensive physical capacity through integrated training, enhancing the ability to handle life's challenges and participate in different sports. "Hexagonal Warrior" is the long-term direction, allowing for simultaneous improvement in multiple abilities, while also permitting phased focus on developing some abilities while maintaining others; functional training handles the construction and supplementation of general physical capacity. Reasonable weight and body composition are long-term observations, and training supports them.

Who This System Serves

Serves: People who treat training as long-term health and life ability; people who play multiple sports (strength + running + swimming + ball) at once, without competing in any single one; whose goal is to play a bit of everything, avoid injury, and handle life's physical demands; who pursue a wide range of abilities, not single-event performance.

Does not serve—just say it's out of scope:

Type	Characteristic
Competition prep	Marathon, triathlon, rowing, competition—needs taper, sport-specific peak, periodization fluctuations
Specialized athlete	Needs competition prep, taper, sport-specific peak, periodization fluctuations per sport. Run/swim frequency alone is not a criterion: running 4-6x/week or swimming 3-4x/week can still be general training, determined by training history and total volume
Seeking performance breakthrough	Goal is ranking, pace, achieving a performance standard
Needing clinical treatment	Diagnosis, imaging interpretation, rehabilitation prescription

One-liner decision rule: Ask "Would you adjust your training for a specific competition?" If "Yes," they are not within the profile.

Why this line is drawn: The skeleton of this system is "comprehensive ability + no competition prep + long-term health," max 12 weeks, no taper, no sport-specific peak, fatigue-driven reduction rather than periodization fluctuations. Specialization needs would overturn all three pillars—forcing it results in serving neither end well. When encountering such needs, it's out of scope; don't offer a "discount version" of a specialization plan.

By default, the user can complete the assigned training; the Skill is responsible for providing sufficient stimulus, clear dosage, preset progression, and a recoverable combination so that following the plan as intended has a path to improve target abilities. "Adjust based on the situation" cannot replace this specific recommendation, nor can filling in examination conclusions be considered a guarantee of effectiveness.

No choice positions within the plan: The movements, sets/reps, load selection methods, recovery, and rotation in the training plan should be clear. When equivalent movements are retained, fix the rotation order; do not fabricate unknown measured loads, prescribe executable prescriptions based on target RPE and first-set selection method. Before delivery, eliminate any prescription positions that require the executor to make a binary choice.

This is an independently usable training system. For regular scheduling, use the principles, decision rules, and movement assets within the package; delivery files and training plans should not display external authors, textbooks, papers, citation numbers, or original file paths.

Boundary between Skill and Personal Content—three areas each manage their own affairs, no crossing over:

• Skill (this package): Reusable methods, movement library with their default_dose, layout and dosing strategies, validation and rendering scripts, output formats. Does not write any specific person's available time, historical weights, equipment, or dosage preferences; the recommended weights in the library are general defaults, not a prescription for someone.
• Plan file (e.g., plan.json): Facts for this one person, this one cycle—available time, pool length, goals and starting point, phase arrangement, current dosage and reference weights.
• User's history: The user's actual completed weights and reactions (TR). Format demonstration TR 36kg×8 (synthetic example, not real record) is a fake data point constructed for this document; real plans must use the user's valid records and actual dates.

Delivery pipeline is not in this package: Scripts for placing plans into Notion/Feishu/some repository, repo IDs and page IDs, and operation history like "someone's habit of manually editing tables" are all private links belonging to the user, and should not be written into this skill—they tie to one person's account and page structure, and won't work for someone else. This package ends at "draft/export file"; if there is a real need, put it in the user's own tools directory, not in scripts/, not in references/, and not downgraded to an "optional tool" within the package. When making things universal, this layer is deleted in place, not moved elsewhere.

When scheduling encounters conflicts over time, equipment, or load trade-offs, decide based on the user's conditions; do not write personal constraints into the skill as rules, nor use the skill's general defaults to override the user's real data.

Main Process: Plan First, Feedback Triggers Adjustment

Making the plan is the main task of this skill; sports judgment starts only when the user reports a problem.

1. Make the plan first: Based on the starting point and known conditions, write out the dosage, intensity, rest, and normal progression for each week at once.
2. No feedback: Continue on the preset path—do not ask week by week for confirmation of "no discomfort, no residual fatigue, stable"; do not treat default completion as recorded actual completion. Default normal completion is just a scheduling assumption.
3. Receive feedback: Only when there are difficulties completing, discomfort, or changes in conditions, adjust the not-yet-executed parts, preserving history.

Increasing load (adding weight, sets, distance, denser sets, compressing rest, increasing frequency, progressing to next phase) still goes through the increase gate—the gate is a passive interceptor: no problem reported, no interception; problem reported, intercepted. It does not constitute "must report status every week to continue."

Operational Process

1. Determine whether to create new, expand, adapt, modify, or explain; reuse existing goals, conditions, and structures.
2. When creating new or adapting, must read these five: Intake, Training Philosophy, Design Principles, Planning, and Programming; as long as injuries, pain, surgery history, or movement limitations are involved, read Training Under Limitations first before scheduling—not checking only after something goes wrong.
3. Based on training content, read Functional Strength Session or Run/Swim Session Structure; along the four-layer movement library of ability, domain, movement family, and specific entry, select executable assets from Movements & Training Units; and verify movement contribution against Selection & Benefits. A complete functional session specifies: rolling, stretching, correction, activation, in-place movement prep, locomotion skills, specific speed/jumps/medicine ball, strength room power & core, strength complexes, and energy system work (force-velocity profile zones for explosive movements and weightlifting derivative load ranges are in Force-Velocity & Weightlifting Derivatives); place support tasks back into these segments according to Rehabilitation Support & Correction; independent weekend sessions are for low-cost stretching and relaxation. When adapting due to project division, phase, or time constraints, provide specific substitutes and load judgments; do not claim deleted segments as completed. For technical movements, select familiar versions; for those with low technical foundation, based on the assumption of normal completion, produce a clear and controllable prescription; do not fabricate mastered observations. Do not use vague candidate names as prescriptions, nor generate movement teaching or clinical course content.
4. Provide specific dosage, intensity, recovery, execution points, and end conditions, and pre-arrange weekly progression. If normal completion is achieved, advance along the established path; logs, extra tests, or proof per session are not used as progression thresholds. When feedback or condition changes are received, read Change Logic; modify the minimum necessary scope; preserve completed history. When time changes involve multiple sports, follow the Cross-Project Trade-off: first provide recommendations and alternatives, clearly marking the costs; let the user decide the direction, then reschedule; do not cut sports for the user, nor wait for the user to propose cuts. For reduction order, see How to Reduce When Time is Short: swap days → reduce sessions → reduce volume; saving time only allows reducing volume, not increasing density or intensity.
5. Save the plan according to Data Model; check target stimulus, starting point, progression, sport trade-offs, actual time, and hierarchical consistency according to Self-Validation Criteria; then execute scripts/validate_plan.py. Correct errors first; specific pending review items must be handled appropriately, not just written as "passed." Render or export according to Output Specification; when modifying, run scripts/compare_plans.py to retain actual differences and impacts.

Design Constraints

• Max 12 weeks; supported plan lengths are only 12/9/8/6/4/3 weeks; all others (e.g., 10, 11, 13 weeks) are directly rejected—regression is done within blocks, total length unchanged, not extended. 12 weeks=four 3-week phases, 9 weeks=three, 6 weeks=two, 8 weeks=two complete phases + final phase compressed to 2 weeks (compress the final segment, do not extend the front segment), 4 weeks=single phase with a redundancy week or 4×1 maintenance cycle, 3 weeks=single phase.
• 12 weeks adopts four 3-week phases (Phase 1 Volume → Phase 2 Intensity → Phase 3 Strength to Power → Phase 4 Strength Endurance + Consolidation; Phase 4 does not peak, see four-day structure). Periodization units are uniformly called "Phases," not "Periods" or "Blocks"; numbering is "Phases 1-4", text uses "each phase/every phase/between phases". Any mention of "four blocks" in old drafts should be changed accordingly. The entire cycle is used for training; there are no test sessions, test weeks, or pre-test reductions. By default, there are load or focus variations within and between weeks; it is not fixed to three weeks of increase plus one week of deload.

Phase dosage is given fully; do not schedule a weekly four-step ladder: Each phase has one range (e.g., volume session 3x8-10); W1 at the low end, W2 takes one step within the range, W3 maintains; write a definite dosage for each of the three weeks; follow the table for normal completion. Plan first: Fill in the default dosage and phase transitions for the entire 12 weeks (or chosen length) at once; do not leave the values for W2/W3 to be determined by execution results; only after receiving feedback, change the not-yet-executed weeks, do not trace back executed weeks. Dosage can be written fully, but load starting points cannot be fabricated—sets x reps, running minutes, swimming meters must be assigned week by week; if reference weight/pacing cannot be obtained via actual measurement, write "TBD"; do not use general defaults to pretend they are actual measurements; "TBD" can only be used in these two fields—sets & reps, target RPE, rest between sets, how to select weight for the first set, intensity descriptions for running and swimming must all be fully written; they cannot be left as TBD, otherwise someone without historical kg data gets only half a plan. How to use ranges is in Plan Revision. The four-step ladder is bound to block length; once block length changes, it degrades into "add two weeks, reduce one week." Preset prescriptions are not fabricated execution results.

Write ranges according to templates, do not create single values yourself: If the template gives "3x8-10 / 24-30 reps per movement", write it as a range; picking one value from each end ("24 reps" or "30 reps") is creating a single value from a range. Ranges are used to describe the method; execution weeks still need definite values—W1/W2/W3 each get one number (2x8, 3x9, 3x10); you cannot leave both weeks as ranges. Total set count is not a prescription indicator: First define movements x sets/reps; total sets per session = number of movements that day x sets; this is a result after planning, only used for estimating time (including warm-up and core). Setting a column "weekly set count range" to manage movements backwards is using the template in reverse; if you really need to verify, calculate the set count and write it under the table as a check, not as a threshold.

Regression and re-dos are absorbed within the block, not by extending total length: If a week doesn't meet standards, reduce to a maintenance week (see Plan Forms); when the end of a phase determines "re-do", it occupies the next phase's position—total length remains 12 weeks; non-standard lengths like 13 weeks are directly judged invalid.

• Allocate tasks and priorities for functional strength, running, and swimming based on life and sports needs, target abilities, and execution conditions; project configuration changes with goals. Prioritize Sunday for main rest days, maintain training on workdays, alternate intensity within six days. Swimming, running/jumping in warm-ups, and metabolic training at the end of strength sessions are all counted in total load.
• Read Aerobic Volume & Progression for endurance development; separately account for main running segment, net swimming volume, planned equivalent volume, and total session time. For low starting points, use specific weekly paths to build volume; do not cobble together strength, prep, and pool-side rest as aerobic work; for those with a higher baseline, design new stimuli based on specific sport needs.
• Applicable strength clearly uses the Reps in Reserve (RIR) scale to guide weight selection, commonly RPE 7 ~ 3 RIR, RPE 8 ~ 2 RIR, RPE 9 ~ 1 RIR (main movements in strength phase use this range); write anchors in the session plan. RPE is not equivalent to a percentage of 1RM; reference weight is not a fixed completion requirement. DUP uses stable main movements in adjacent training sessions, changing reps and corresponding loads; the declared main anchor is stored in design_context.strength_waves; working groups are marked with wave_role. Changing movements, titles, or phase progression itself cannot prove DUP; not all accessory, power, or prep tasks are required to fluctuate.
• Design actual stimuli and progression for development goals; maintenance goals have corresponding stimulus; explicitly mark paused or unevaluated items. Cannot use arbitrary ability labels to claim coverage, nor assume every ability requires independent training.
• The movement library covers functional strength, running, swimming, and macro support tasks; coverage table is in references/training-library/coverage.json. Each required ability has applicable assets or a clear gap; cannot assume that because a movement exists in the library, it is being developed this cycle. By default, main sessions prioritize high-contribution, progressable, and cost-effective (time, technique, recovery) movements; only include local isolated movements when there is a clear reason; do not add them to main sessions just to fill rows.
• Default completion does not mean automatic mastery of unfamiliar techniques or that existing movement limitations are cleared. Select mastered alternatives; incorporate clearly identified limitations into the layout; stop relevant content and re-evaluate upon abnormal reactions.
• First produce a general layout, then customize: First round is based on a generic prescription for a healthy adult; do not assume injuries, missing equipment, available time; only after the structure is finalized, make substitutions and downgrades. Exception: When registered limitations (or clear suspicion) exist, skip this step—first apply limitations to filter movements and total volume, then schedule sessions based on frequency; if not registered or evaluated, use the most conservative tier, wait for evaluation results before relaxing. If the order is reversed, the first draft is a healthy person's prescription containing contraindicated movements. Mixing two things into one version makes structural issues and individual limitations a mess. When users review frequency by frequency (four-day → three-day → two-day), only lay out one frequency, one session at a time; after confirmation for that round, continue; when the user directly requests the entire schedule or explicitly delegates structure selection, deliver the complete version based on intake at once, without asking session by session; before each session, clarify "which items progress over three weeks, which are fixed for three weeks" so preset progression can be verified.

Structure Templates: Select one by frequency, do not mix or splice

• Four-Day Structure: Intra-week alternation (2 lower body days + 2 pure upper body push days), four-phase progression (Phase 1 Volume → Phase 2 Intensity → Phase 3 Strength to Power → Phase 4 Strength Endurance + Consolidation, no peak), daily positioning.
• Three-Day Structure: Core skeleton (Core two rows / Pair one group / Tri-set three grids), Heavy-Medium-Light intensity gradient, only movements from the example table's categorized pool, two-axis progression (strength axis + template axis); Three-day structure only has Phase 1; subsequent phases are transplants.
• Two-Day Structure: Two main group structures, default no accessory layer (the only exception for complete integration must write full group order / working length / recovery), two complete days of sessions, gap list, and progression correction for "expansion rule invalid".

Multi-Sport Scheduling: First define the skeleton, then calculate intensity budget

• Concurrent Training: Interference threshold, weekly high-intensity session budget (hard cap 4 times, 3 times with registered limitations, script checks), sport mutual exclusion matrix, run 0-7 times gradient and four/three/two-sessions x run weekly calendar combinations, two ratio options (strength-dominant / mixed, no "dominant sport" generated).
• Multi-Sport Scheduling: Skeleton + attachments for non-specialized athletes, two ledgers (intensity/days), three recovery day forms and counting rules, seven scheduling steps, ball sport impact on strength focus, same-day order, double-session rules, calculation examples.

Functional strength is the foundation; sports are its application context—do not distribute "development slots" by sport rotation: First ask the user about their intentions for each sport (enjoyment / supplementing fitness / wanting to improve a specific aspect) + weekly time commitment; if unclear, schedule for maintenance and mark as "unconfirmed" in the draft; do not guess ratios, do not define roles for the user. Strength sessions run throughout the cycle, progressing by their own sets/reps and load; do not yield because it's a run or swim day, nor require runs/swims to stop because strength increased. Control increment via the load line, not by queueing sports: rotation tables like "this week run, next week swim" are wrong readings; if written, revert and reschedule.

Five Independent Load Lines: Strength sets/reps (including load anchors) / running minutes / net swimming / impact contact count / recovery occupation. At most one line significantly rises in the same phase; a second line rising requires a written reason (review level, not error). Maintenance items are not zero-load—a maintenance strength session still occupies recovery resources; "maintaining one item" does not equal "the other two can safely increase." Rise is judged by the prescribed dosage in the schedule, not by how the goal is phrased: Use strength sets x reps, running minutes, net swimming from the first and last week of each phase as volume, average target RPE as intensity, main rest as recovery; any of the following criteria constitute that line is rising: volume increase > 10%, RPE increase 0.2, rest decrease to < 95%. stage_load_lines() produces this comparison table; if more than one line rises in the same phase, report stage_lines:<block> (review), requiring clarification of primary/secondary and why another line is also rising; if the goal says "develop" but the dosage per session hasn't changed, that line is flat.

"Only one line rising" does not equal "the same line can keep rising for consecutive phases": If the same line rises for more than 2 consecutive phases, report stage_lines_streak; there must be at least 3 stable weeks between two adjacent rising points; if separated by only 1-2 weeks of consecutive rise, report ramp_interval (message carries both week numbers and values). The legal way is all three lines flat within a phase, rising only at phase boundaries (example: run 62/75/88/100 minutes weekly, each tier stable for 3 weeks). When all lines are flat within a phase, clarify which line will pick up at the next boundary; otherwise, "nothing has moved" will be read as no progression through the entire cycle. Two forms do not report "intra-phase increase": ① Phase first week 1-2 sets → second week 3 sets, reps and RPE unchanged; that's the Phase 1 entry-level rhythm (_is_phase_intro() marks as prescribed_intro, use second week as comparison baseline), not an autonomous increase. ② When volume day and heavier day have the same reps (Phases 2-4 both have 5 reps for main items), daily fluctuation is handled by target RPE; design_checks recognizes either "different reps" or "clearly higher target RPE"—lacking this, from the phase transition week onward, the example will falsely report "heavier session and volume session do not have clearly lower rep ranges", and blocked_weeks will extend to the final week.

Phase transitions are listed separately; baseline → first week is also listed separately: Comparing only the first and last week of each phase will entirely miss cases like "all three lines flat within a phase, all rises concentrated at the boundary"—stage_load_lines() handoff/handoff_rising reports stage_handoff:<block>; if not explicitly stated in design_context.review_resolutions whether it's a ramp or superposition, actual mode won't produce the table. Comparing only rising points after W1 will miss the jump from baseline to W1 (the largest step in the entire table is often in an unseen place). Baseline → first week is judged by frequency, not percentage: baseline_entry_check() for increased run frequency only checks if a single session is extended (single session max ≤ baseline single session is a pass; increasing frequency itself is not increasing volume); only report if frequency unchanged but weekly volume increase exceeds 10%. Three metrics cannot share one name: Main running segment total (sum of the longest single segment from each session, excluding warm-up and cool-down) / Total running volume (summed by movement type—if warm-up and cool-down are also coded as running-type exercises, they will be included) / Whole session (including brisk walk and cool-down), write in three sentences; the 40% cap, ramp judgment, and transition check all use only this set: "whole week running volume including transitions." When reporting the comparison table, write the column names precisely: if you mark a value summed by type as "main running total," it will differ from the main segment count given by a sport coach by over ten minutes, making it look like both sides are wrong. The minutes in the summary (mini_goal) check the session's main running segment (longest single segment), not the whole session or total running volume including warm-up/cool-down—if the metric is wrong, dozens of sessions will all report "inconsistent," causing a useless round of corrections; this kind of drift requires a full scan by script; manual spot checks will inevitably miss the few where the difference is only 1-2 minutes. The baseline run frequency / single session max / weekly volume must be structured fields in baseline_basis (run_sessions_per_week / run_longest_minutes / run_weekly_minutes / minutes_basis); if only written in observation prose, the next step cannot verify, and cross-metric division will yield fake increases like +55%.

Do not manually write fields that can be calculated: Single session summary (mini_goal) and total session duration are both generated from dosage (session_summary.mini_goal() / duration_model.apply()); if a manual copy exists alongside the dosage, changing one will leave the other stale. A number written in the summary is a claim that can be checked; discrepancy with dosage reports mini_goal does not match single session dosage (review level, with generated value). For the checklist after changing sets/reps (set_sequence / duration / summary / context_hash / phase table), see Data Model; missing one leads to another round of rework. context_hash is not manually filled, and old values are not retained: After changing main item sets/reps or ascending sets, an unrefreshed resolution will cause global_gaps to report stage_handoff:<block>: review_resolutions must record current context_hash…, consequently blocking the output gate. The refresh method is to rerun design_checks.check(plan, library()) (library() imported from validate_plan), then backfill review_id → context_hash entries from requirements into design_context.review_resolutions, then run the full test suite; do not change wording unless the ramp fact itself changes.

Description fields must match the actual dosage in the schedule: Before writing "this phase goes from 8 sets to 12 sets" in progression_condition/purpose, read the actual sets/reps/target_rpe of items in that phase to confirm it is so arranged. Paraphrasing the coach's target numbers into the description while the schedule does not realize them creates a plan that contradicts itself—reviewers will reject it as "claimed but not implemented," and it will mislead your own review. Progression that is not implemented is written only in notes outside the plan, not in the plan description.

Impact contact is a separate row: Set tables and run tables cannot show it. Weekly contact volume = contacts_per_rep × sets × reps × sides accumulated daily; verification is parallel with running minutes, not added, and there is no hard-and-fast rule that "two cannot rise together." Determine if impact is increasing in a phase by calculating from this formula, not by inferring from "changed organizational method"—moving independent plyometric segments into paired groups usually results in flat or decreased volume.

Prescription adjustments and performance improvements are recorded in two columns: Improvement in performance under the same prescription is a training outcome, not a prescription change; only adding sets, increasing distance, raising target intensity, or advancing to the next phase count as prescription changes. Mixing them into one column obscures both the gains from foundational training and any additional loading from sport-specific work.

Individual Sport Prescriptions: Starting points, progression, and upper limits for running and swimming

• Plan Revision: Plan is plan, execution is execution—this package does not prescribe how to train and how to log; it only handles how to modify the plan based on results received: intra-week determination, end-of-phase judgment, regression slots within blocks, modifying only local parts, not rewriting the plan.
• Run Programming: Four starting point prescriptions; I/R frequency follows ball sports; progression (including single longest run tiered by weekly run sessions: 4+ times 30% / 3 times 40% / 2 times 55% / single run not applicable, > 64 km capped at 25%, script checks); running form three rules; intensity descriptions; typical weekly calendar.
• Swim Programming: Confirm starting point by stroke and specific task; two effort levels (no CSS testing); preset single-variable progression and exception adjustments; real pool length and swimming distance; equipment and existing limitations; example dosages are not universal adult prescriptions.

Supporting Judgments: First check limitations and equipment, then decide movement names

• Training Under Limitations: Two types of limitations (long-term/stage-based); seven movement families × three tiers; three phases of healing (staged by tissue and next-morning response, not by calendar); 3/10 pain is only the daily cap; three types of impact branches (explicitly prohibited / allowed but conditions not met / current episode; three branches cannot be merged into one); red flag list; referral conditions.
• Gym Equipment: Equipment list and item-by-item substitutions (upgradeable / downgradeable / true gap—three levels); knee-dominant functional ranking; how to fill eight main positions under four equipment configurations; six methods of progression without weights.
• Exercise Names Chinese-English: Terminology baseline; marking for exercises not in the book; the "Current Chinese Name" column is the exact name in the movement library; write schedules using this name; otherwise, performance columns matching by name will mix up.
• Each row in the comparison table either has a library ID or explicitly writes not_in_library; after modification, run scripts/check_exercise_names.py: It checks row by row: "ID in library?", "table name equals library name?", "has ID but claims current Chinese name?", and provides fillable IDs. Rows with not_in_library are listed separately as "Declared not in library," not counted as errors; header rows are skipped. There are no other states beyond these two: Rows without an ID and not declared not_in_library are not considered "current Chinese names"; the script will report them as errors—locomotive skills not in the library (e.g., cross jumps, lateral crawl), written as current names, essentially create an unsearchable name for the library. Before declaring "simultaneously executed in movement library and this table," first grep -rn 'old_name_1\|old_name_2' SKILL.md references/: Changing table rows is easy; the main text and structural files (two/three/four-day structures, functional-session, gym-equipment, limitations, multi-sport) may contain dozens of instances of the same names; changing only the table while declaring unification will result in the next review revealing that the table is newer than the main text.
• Determining library gaps requires searching by definition: Query simultaneously by id/name, english_name, and movement definition; check canonical and runtime asset sets and synonyms. Only mark not_in_library if zero hits; approximate movement substitutes cannot replace gaps. Report keywords, scope, and findings.
• When adding a new entry, first decide the Chinese name, categorized into "with source" and "suggested translation": Those with a publicly accepted Chinese usage write directly (squat hold / static squat, lateral bear crawl); if no unified translation exists, mark as "descriptive suggested translation, pending visual confirmation" (e.g., medicine ball toe-touch squat). Do not pretend to be an industry standard. Align new names with the library's existing family: The library's crawl is only bear crawl; a lateral variation is called "lateral bear crawl," not "lateral crawl." If it collides with clinical/test terminology, clearly state the difference: "Single-leg crossover hop" in rehabilitation literature is a measurement test for the crossover hop test, different from a warm-up crossover jump; failing to distinguish means one name points to two movements.
• Subtract parsing artifacts from reported line counts before discussing how many real gaps exist: The header row of the comparison table will be treated as a data row ("Current Chinese Name" cell is the header name); merged rows with two IDs side by side will be checked against the same name cell twice—both will be reported as "name does not match library" or "no library ID but claims current Chinese name." The fix is to modify the script to skip the header, split merged rows into one ID per row, not to go back and change exercise names; subtract these two categories before reporting, otherwise half the reported errors are generated by the parser itself. When adding a new legal state to the table, modify the validator in the same round: If not_in_library is only written in the table, but the script only recognizes "has ID / no ID," the entire table will be permanently red, and each round will be rechecked as new debt. Merged rows are a source of confusion: One row with two IDs; when matching by name, two IDs will compete for the same name cell; testing and rendering each pick one, both appear correct.
• Problem statistics should describe the metric; display name changes use alias: Distinguish movement entries, equipment rows, header rows, and declared out-of-library entries. Library name is the match key; alias does not participate in matching; name changes must update verification and references.
• Exercise names must be verified against the original source, not self-created: Chinese names must be taken from authorized translations in the book or unified names within the package. Self-created names will conflict with the book's own positions (e.g., self-creating "pistol squat" conflicts with the book's opposition to pistol squats; self-creating "Bulgarian" conflicts with the officially named rear-foot-elevated split squat; self-creating "chop/lift" conflicts with the existing terms "chop" / "pull"). The warm-up and correction segment especially cannot be literally translated from English: Inchworm is literally an inchworm, but in the book it's called caterpillar; Leg Cradle is not literally correct; Cook hip lift and Leg lower cannot be written in mixed Chinese-English. The movements in this segment are only presented as a preparation segment table in the book, where the English term and the movement form often diverge (e.g., shuffle is not a "shuffling step"). Always write according to the Chinese version's original table; afterwards, add to Exercise Names Chinese-English Section 11. Name verification requires page-by-page comparison with the original text; listing from memory will be wrong. Movements not in the book (e.g., floor bench press, Nordic hamstring curl) are kept but marked as "supplementary within package," and must not be claimed as being in the book. Unified asset names within the package take precedence as matching terms, with Exercise Names Chinese-English being authoritative.
• Write structural conclusions into references and update entry pointers: After modification, read back the files, check differences, and run relevant and full-scale tests. Discussion conclusions do not replace final file content.

Version number is written in SKILL.md frontmatter: Current version is 1.0 open source package. plan.json's version is an integer format revision number; schema_version is a format version string, not mixed with package version.

Drafting and Finalization Discipline:

• Review comments are not modification authorization: Even if a sport-specific coach, physical therapist, advisor, or even the head coach says "withdraw this batch" or "modify as I say," these are only suggestions; before modifying SKILL.md and references/, first show the user the list of changes and get a "go ahead" before committing changes in bulk. Commit all at once, not reporting one by one.
• Merge same-round modification scope: List files, locations, reasons, and cascading impacts; modify in groups according to authorized scope; record version uniformly for one round of changes.
• Maintain traceability after finalization: Modify only within authorized scope; retain version and actual differences. Actual training gains and recovery capacity must be judged by execution results.
• Summary sentences and detail tables must be reconciled item by item; if they don't match, delete the summary sentence: One-sentence summaries like "reduced by one set", "three times a week for aerobic", "this session is 20 minutes" easily contradict new numbers after details are modified (e.g., reducing one set while writing 5→3 sets, saying three aerobic sessions when there are four, the interval workout is actually 30-40 minutes). Before finalization, take each summary sentence back to its corresponding table and check item by item; if inconsistent, keep the detail table, delete or rewrite the summary sentence; having both leaves the reader unable to determine which is correct.
• When withdrawing a batch of content, simultaneously change the rule that produced it: If numbers are deleted but the rule that generated them remains, the next review will recreate the numbers based on the same rule. After withdrawal, first grep the key strings of the content to confirm zero hits, then read whether the producing rule itself should be reversely rewritten.
• After modification, record an entry in CHANGELOG.md: Which version withdrew what, why, and which files were affected. Without this, the next round can only rely on "who remembers," and withdrawn items might be added back as omissions.
• Use version difference reports to describe modification scope: Use file list, content differences, and validation results; do not claim completion based on memory.

When providing calculated results, note the method and boundary of liability: Distinguish source facts, independent calculations, and design choices; maintain consistent thresholds and clear application scope for the same judgment.

If the same quantity yields different results, first align the metrics: Verify input, units, transition time, and rounding methods; list unresolved differences, then determine the adopted value.

Before entering an absolute number into a rule, first run it through a judgment criterion: For any number like "add at most X minutes each time" or "switch mode after exceeding Y minutes," first ask yourself if it works for two people with different starting points—adding 15 minutes to someone with a 60-minute weekly volume is +25%, adding 15 minutes to someone with 300 minutes is +5%; one number cannot govern two magnitudes. If not, downgrade it to "parameter for this example," clearly stating the trigger point is determined by the user's percentage tier; do not make it a general rule. Numbers derived from the package's own allocation logic especially must not be upgraded to rules (e.g., deriving from "at 40% tier with three runs, a single session exceeds 50 minutes" to conclude "120 minutes must require adding a run session" is stacking two layers of self-made logic). Similarly, when percentage caps already control single session length, do not add a fixed minute cap—redundant thresholds will eventually conflict.

Time budget and feasibility conclusions must be based on the same metric: Before saying "it fits in X minutes," fixed blocks (prep + power + core), ascending/warm-up sets, working groups and rest intervals, and movement transitions must all be calculated at once; giving a number without ascending sets, then adding "plus 6 more minutes for ascents," already creates internal conflict. Before comparing which of two options saves more time, first align the workload: If set counts or durations differ, the difference comes from the workload itself, not from the structure (comparing 7 sets to 9 sets and concluding "reducing mode is more time-consuming," or comparing 6 sets to 9 sets and concluding "keeping all four types doesn't fit" are both such cases). The correct way is a comparison table of "budget ↔ achievable set counts," allowing both options to be compared for coverage and thickness under the same budget. Total session duration is calculated from dosage, not written as a constant: scripts/duration_model.py is the sole implementation (single movement = sets × work time per set + (sets-1) × rest between sets; work time per set prioritizes: if RPE ≥ 7, count × 5 seconds; otherwise, use the whole-set work seconds from the asset table (if notes already state "about 9 sec/repetition" or "hold 10 sec each, 6 reps total," use directly, no need to overwrite with per-rep estimation), then the duration field, technical count × 4 seconds; per_side doubles it); apply() writes back to the items→modules→session three layers; the check that "prescribed volume exceeds allocated time" must call the same function. Distance calculation varies by movement speed, not using one shared constant: Locomotion/lateral walking and kicking locomotion 0.8 m/s, loaded carry 1.0 m/s, acceleration runs ~3 m/s (10m strides ~3 seconds). Using 1.3 m/s for everything will calculate a 20m locomotion as 15 seconds and a stride as 8 seconds, both wrong. When two sets of work time estimates coexist, and one calculates "over 90 minutes per session" while the other calculates "all within 90 minutes," the conclusion itself is wrong, not the data. Hand-writing a single constant for all 24 sessions hides real fluctuations. When two implementations differ by only 0.5-1.5 minutes per session, do not immediately attribute it to "movement transition" or "item-by-item rounding"—these two categories cannot produce differences of this magnitude; open the other script and diff the work time per set item by item; the difference almost always lies at that layer (stopwatch whole set vs. per-rep estimation), then determine which is correct after locating the specific movement; do not pick one explanation over the other and treat it as a conclusion. Overtime is not compensated by compressing prep sets for symptomatic areas: Ascending/warm-up sets address safety (i.e., directly performing working sets without adequate preparation); they are not cuttable volume. Calculate adding ascending sets and cutting time separately; if still over time after adding ascents, report the overtime truthfully. When reviewing dosage, count the ascending sets (the RPE 4 ones) for each movement item by item—if a main item has zero ascending sets for the entire cycle, there is no safety belt...

[truncated for translation]