GP-142 GP-143 GP-144: Harden training plan guardrails

[deancochran]

Summary

• GP-142: add core training-plan creation readiness results with blocking/warning severities and preference consistency guardrails, then consume them from mobile save readiness without UI layout changes.
• GP-143: make backend planning preview status explicit and gate preview/save usage through the mapped availability contract.
• GP-144: add shared core projection-window budgets and apply them to Plan tab and Training Preferences projection aggregation before expensive timeline work.

Verification

• pnpm --filter @repo/core check-types
• pnpm --filter mobile check-types
• pnpm --filter @repo/core test -- trainingPlanCreationValidation trainingPlanProjectionBudgets — passes; current Vitest selection runs the core suite.
• pnpm --filter mobile test -- training-plan-creation
• pnpm --filter @repo/core lint — completed with existing warnings outside this change.
• pnpm --filter mobile lint — completed with existing warnings outside this change.
• Pre-push hook passed: biome, typecheck, test, knip.

Plane

• Plane items: GP-142, GP-143, GP-144
• Parent audit: GP-141
• Target branch: dev

Notes

• No UI/UX layout changes are included.
• No API analytics range validation was changed; GP-44 remains the coordinating item for API date-range guardrails.
• Maestro video is not applicable: this change affects background/core validation and projection orchestration only, with no mobile runtime UI behavior changes.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2e3049ed23

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve builder-authored data before backend saves

When this makes the backend commit route available, the create/edit builder starts saving through createFromCreationConfig/updateFromCreationConfig, but the mapped backend input only carries the minimal goal/config data and not state.details or state.structure.sessions. The backend commit then persists the generated expandedPlan, so a user who typed a plan name/description or manually arranged sessions/activity plans can save a different generated plan instead of the one they built; keep the legacy payload route for manual-builder saves or include those builder fields in the backend contract before enabling these commit operations.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Use the requested schedule bounds for coverage

When a caller supplies scheduledWindowStart/scheduledWindowEnd that are narrower than the resolved projection guardrail, this predicate treats every date in the larger projection window as covered by fetched calendar data. aggregateScheduledLoadByDate still filters events to the actual requested window, so baseline scheduled_tss is replaced by 0 for dates outside the fetched range; compare against the requested schedule bounds here and use the projection window only to clamp which dates are emitted.

Useful? React with 👍 / 👎.