Skip to content

planned workouts spec#4

Open
angjozee wants to merge 3 commits intomasterfrom
jozee/planned-workouts
Open

planned workouts spec#4
angjozee wants to merge 3 commits intomasterfrom
jozee/planned-workouts

Conversation

@angjozee
Copy link
Copy Markdown

@angjozee angjozee commented Feb 4, 2026

Summary by CodeRabbit

  • New Features
    • Create and manage custom workout templates for various sports
    • Schedule and manage planned workouts with date-based retrieval
    • Configure intensity targets and performance metrics per workout step
    • Update or delete scheduled workouts as needed

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Feb 4, 2026

📝 Walkthrough

Walkthrough

The pull request introduces a comprehensive TypeSpec API specification for managing workout templates and planned workouts, with support for various sport types, intensity targets, and completion conditions. An import statement is added to the main data models file to include the new PlannedWorkouts module in the data model ecosystem.

Changes

Cohort / File(s) Summary
API Specification Integration
data_models/main.tsp
Added import for PlannedWorkouts.tsp module to extend data model module exports.
Workout Management API
data_models/specs/data_models/PlannedWorkouts.tsp
New comprehensive TypeSpec specification defining 8 enums (SportType, CompletionConditionType, IntensityType, TargetType, WeightUnit, SwimStroke, SwimEquipment), 12 core models with validation constraints (@minValue, @maxValue, @pattern), and 5 REST API endpoints (POST /v2/workouts, POST/GET/PATCH/DELETE /v2/plannedWorkouts) with request/response contracts, authentication headers, and error handling.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Poem

🐰 Hop, hop, and stretch so fine!
Workouts planned in structured design.
Templates bloom with sport and grace,
REST endpoints running their race.
TypeSpec hops to validate it all—
A rabbit's feast, from spring to fall! 🏃‍♂️✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'planned workouts spec' accurately and concisely describes the main change—adding a new PlannedWorkouts.tsp specification file with comprehensive API definitions for managing workout templates and planned workouts.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch jozee/planned-workouts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Fix all issues with AI agents
In `@data_models/main.tsp`:
- Line 14: PlannedWorkouts.tsp is using OpenAPI/REST decorators
(`@service/`@server and imports `@typespec/http`, `@typespec/rest`,
`@typespec/openapi3`) but the build only emits JSON Schema; either enable the
OpenAPI emitter in tspconfig.yaml or convert PlannedWorkouts.tsp to the
project's JSON Schema style. To fix: open tspconfig.yaml and add the OpenAPI
emitter configuration (enable `@typespec/openapi3` output) so the `@service/`@server
decorators in PlannedWorkouts.tsp are processed, or refactor the
PlannedWorkouts.tsp file to remove
`@typespec/http/`@typespec/rest/@typespec/openapi3 usage and model the API types
using the same JSON Schema-oriented patterns used by other data model files
(keeping type names and endpoints equivalent). Ensure references to
PlannedWorkouts.tsp, `@service`, `@server`, and tspconfig.yaml are updated
accordingly.
🧹 Nitpick comments (4)
data_models/specs/data_models/PlannedWorkouts.tsp (4)

88-91: Consider renaming if to avoid reserved keyword conflicts.

The if enum value represents the TrainingPeaks Intensity Factor metric. While TypeSpec allows backtick escaping, this may cause code generation issues in languages where if is reserved (TypeScript, Python, Java, etc.).

Consider using intensity_factor instead:

   // TrainingPeaks-style targets
   tss: "tss",
-  `if`: "if",
+  intensity_factor: "if",

315-316: Consider adding format validation for date fields.

created_date and updated_date lack @pattern validation while other date fields in this spec (e.g., planned_date) use @pattern("^\\d{4}-\\d{2}-\\d{2}$"). If these fields follow a specific format (ISO 8601 datetime or YYYY-MM-DD), consider adding validation for consistency.

-  created_date?: string;
-  updated_date?: string;
+  /** ISO 8601 datetime when the planned workout was created */
+  created_date?: utcDateTime;
+
+  /** ISO 8601 datetime when the planned workout was last updated */
+  updated_date?: utcDateTime;

380-391: Add @pattern validation to date query parameters for consistency.

The start_date and end_date query parameters lack the @pattern validation used elsewhere in this spec (e.g., planned_date in request models). The doc comment indicates expected format YYYY-MM-DD.

Suggested fix
   op listPlannedWorkouts(
     ...TerraHeaders,
     `@query` user_id: string,
-    `@query` start_date?: string,
-    `@query` end_date?: string
+    `@query` `@pattern`("^\\d{4}-\\d{2}-\\d{2}$") start_date?: string,
+    `@query` `@pattern`("^\\d{4}-\\d{2}-\\d{2}$") end_date?: string
   ): ListPlannedWorkoutsResponse | {

334-346: Consider adding 401 Unauthorized response for authentication failures.

All endpoints require authentication via TerraHeaders (dev-id, x-api-key), but none define a 401 response for invalid or missing credentials. This would improve API completeness and client error handling.

Example for createWorkoutTemplate
   op createWorkoutTemplate(
     ...TerraHeaders,
     `@body` body: CreateWorkoutTemplateRequest
   ): CreateWorkoutTemplateResponse | {
+    `@statusCode` statusCode: 401;
+    `@body` error: { detail: string };
+  } | {
     `@statusCode` statusCode: 400;
     `@body` error: { detail: string };
   } | {

This pattern should be applied to all endpoints in both namespaces.

Comment thread data_models/main.tsp
import "./specs/data_models/Athlete.tsp";
import "./specs/data_models/Body.tsp";
import "./specs/data_models/Events.tsp";
import "./specs/data_models/PlannedWorkouts.tsp";
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# First, let's check if the file exists and understand the repository structure
echo "=== Repository structure ==="
ls -la data_models/

echo ""
echo "=== Main file content ==="
cat -n data_models/main.tsp

echo ""
echo "=== Checking PlannedWorkouts.tsp for `@service/`@server decorators ==="
if [ -f "data_models/specs/data_models/PlannedWorkouts.tsp" ]; then
  echo "--- PlannedWorkouts.tsp (first 30 lines) ---"
  head -30 "data_models/specs/data_models/PlannedWorkouts.tsp"
else
  echo "PlannedWorkouts.tsp not found"
fi

echo ""
echo "=== Checking decorators in imported files ==="
for f in enums common Samples TerraUser Activity Daily Sleep Nutrition Menstruation Athlete Body Events; do
  file="data_models/specs/data_models/${f}.tsp"
  if [ -f "$file" ]; then
    echo "--- $file ---"
    head -30 "$file" | grep -E "@(service|server|jsonSchema)" || echo "(no service/server/jsonSchema decorators in first 30 lines)"
  else
    echo "--- $file (NOT FOUND) ---"
  fi
done

Repository: tryterra/openapi

Length of output: 3968


🏁 Script executed:

#!/bin/bash
echo "=== tspconfig.yaml content ==="
cat -n tspconfig.yaml

echo ""
echo "=== package.json scripts ==="
cat package.json | grep -A 10 '"scripts"'

echo ""
echo "=== Check src directory structure ==="
ls -la src/ 2>/dev/null || echo "src/ not found"

echo ""
echo "=== Check specs directory structure ==="
find specs -type f -name "*.tsp" | head -20

Repository: tryterra/openapi

Length of output: 365


🏁 Script executed:

#!/bin/bash
echo "=== Current directory ==="
pwd

echo ""
echo "=== tspconfig.yaml content ==="
if [ -f "data_models/tspconfig.yaml" ]; then
  cat -n "data_models/tspconfig.yaml"
elif [ -f "tspconfig.yaml" ]; then
  cat -n tspconfig.yaml
fi

echo ""
echo "=== package.json scripts section ==="
if [ -f "data_models/package.json" ]; then
  cat "data_models/package.json" | jq '.scripts' 2>/dev/null || grep -A 5 '"scripts"' "data_models/package.json"
elif [ -f "package.json" ]; then
  cat package.json | jq '.scripts' 2>/dev/null || grep -A 5 '"scripts"' package.json
fi

echo ""
echo "=== Check if PlannedWorkouts appears in any config files ==="
find . -type f \( -name "*.json" -o -name "*.yaml" -o -name "*.yml" \) -exec grep -l "PlannedWorkouts" {} \; 2>/dev/null

Repository: tryterra/openapi

Length of output: 658


PlannedWorkouts.tsp uses OpenAPI/REST decorators but the build pipeline is not configured to emit OpenAPI output.

PlannedWorkouts.tsp imports @typespec/http, @typespec/rest, and @typespec/openapi3, and applies @service/@server decorators for OpenAPI generation. However, tspconfig.yaml is configured to emit only @typespec/json-schema output, not OpenAPI. The @service/@server decorators in PlannedWorkouts will not be processed or emitted by the build pipeline. Either add the OpenAPI emitter configuration to tspconfig.yaml or refactor PlannedWorkouts.tsp to use the JSON Schema paradigm consistent with other data models.

🤖 Prompt for AI Agents
In `@data_models/main.tsp` at line 14, PlannedWorkouts.tsp is using OpenAPI/REST
decorators (`@service/`@server and imports `@typespec/http`, `@typespec/rest`,
`@typespec/openapi3`) but the build only emits JSON Schema; either enable the
OpenAPI emitter in tspconfig.yaml or convert PlannedWorkouts.tsp to the
project's JSON Schema style. To fix: open tspconfig.yaml and add the OpenAPI
emitter configuration (enable `@typespec/openapi3` output) so the `@service/`@server
decorators in PlannedWorkouts.tsp are processed, or refactor the
PlannedWorkouts.tsp file to remove
`@typespec/http/`@typespec/rest/@typespec/openapi3 usage and model the API types
using the same JSON Schema-oriented patterns used by other data model files
(keeping type names and endpoints equivalent). Ensure references to
PlannedWorkouts.tsp, `@service`, `@server`, and tspconfig.yaml are updated
accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant