feat: Add GraphQL schema for results service

[hoegertn]

Add new GraphQL types and operations:

• RankingEntry type for league group rankings
• CalendarDate type for upcoming matchdays
• getLeagueGroupRanking query
• getUpcomingMatchdays query
• getAllMatchdaysInSeason query
• importMatchdayFromRBT mutation

Summary by CodeRabbit

• New Features

  • Team league rankings with standings and performance stats
  • Calendar view for upcoming matchdays and schedule planning
  • Browse complete matchday listings for an entire season
  • Import matchday data from external sources

• Documentation

  • Updated API/docs pages describing new ranking, calendar and import endpoints and types

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[amazon-inspector-frankfurt]

⏳ I'm reviewing this pull request for security vulnerabilities and code quality issues. I'll provide an update when I'm done

[coderabbitai]

Walkthrough

The GraphQL schema adds two public types (RankingEntry, CalendarDate), three new read queries (getLeagueGroupRanking, getUpcomingMatchdays, getAllMatchdaysInSeason) and one mutation (importMatchdayFromRBT); docs and generated HTML pages were added/updated and auth directives (@aws_cognito_user_pools) applied to operations.

Changes

Cohort / File(s)	Summary
GraphQL schema schema.graphql	Added new types RankingEntry and CalendarDate. Added queries getLeagueGroupRanking(groupId: ID!, includeNonCompetitive: Boolean), getUpcomingMatchdays(associationId: ID!, seasonId: ID!), getAllMatchdaysInSeason(seasonId: ID!) and mutation importMatchdayFromRBT(groupId: ID!, data: String!). All operations annotated with @aws_cognito_user_pools.
Generated docs — types docs/types/RankingEntry.html, docs/types/CalendarDate.html	New TypeDoc-generated HTML pages documenting RankingEntry and CalendarDate shapes and properties.
Generated docs — args/pages docs/types/QueryGetLeagueGroupRankingArgs.html, docs/types/QueryGetUpcomingMatchdaysArgs.html, docs/types/QueryGetAllMatchdaysInSeasonArgs.html, docs/types/MutationImportMatchdayFromRbtArgs.html	New/updated generated HTML documenting argument type aliases for the new queries/mutation (properties: groupId, includeNonCompetitive, associationId, seasonId, data).
Static site assets (search/navigation) docs/assets/navigation.js, docs/assets/search.js	Replaced base64-encoded payloads assigned to window.navigationData and window.searchData (content change only; logic unchanged).

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant GraphQLAPI as "GraphQL API"
  participant Service as "Matchday/Ranking Resolver"

  Note over Client,GraphQLAPI `#D6EAF8`: Read queries
  Client->>GraphQLAPI: getLeagueGroupRanking(groupId, includeNonCompetitive)
  GraphQLAPI->>Service: resolve getLeagueGroupRanking
  Service-->>GraphQLAPI: RankingEntry[] 
  GraphQLAPI-->>Client: RankingEntry[] 

  Note over Client,GraphQLAPI `#F9E79F`: Upcoming matchdays
  Client->>GraphQLAPI: getUpcomingMatchdays(associationId, seasonId)
  GraphQLAPI->>Service: resolve getUpcomingMatchdays
  Service-->>GraphQLAPI: CalendarDate[] 
  GraphQLAPI-->>Client: CalendarDate[] 

  Note over Client,GraphQLAPI `#F5B7B1`: Mutation (auth required)
  Client->>GraphQLAPI: importMatchdayFromRBT(groupId, data)
  GraphQLAPI->>Service: resolve importMatchdayFromRBT
  alt success
    Service-->>GraphQLAPI: MatchDay
    GraphQLAPI-->>Client: MatchDay
  else failure
    Service-->>GraphQLAPI: Error
    GraphQLAPI-->>Client: Error
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Pay attention to schema nullability and field types mapping to existing Team and MatchDay types.
• Verify @aws_cognito_user_pools directives placed correctly and intended for all operations.
• Confirm generated docs match schema signatures and that static asset payload updates are expected.

Suggested reviewers

• hoegerma

Poem

🐰 A hop, a schema, new fields in view,

Rankings and dates now join the crew.
Queries fetch matchdays, a mutation imports cheer,
Docs bloom like carrots — fresh and clear.
— your rabbit reviewer, nibbling code with glee 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description lists the new types and operations added but lacks key template sections such as what kind of change it is, current behavior, new behavior explanation, and breaking change assessment.	Complete the description using the template: specify change type (feature), explain current/new behavior, clarify if breaking changes exist, and add any other relevant information.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding GraphQL schema for a results service, which aligns with the introduced types, queries, and mutations.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch claude/add-schema-01Sm97K1s7rRy7J48qrwT65R

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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

[amazon-inspector-frankfurt]

✅ I finished the code review, and didn't find any security or code quality issues.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

schema.graphql (1)

654-655: Consider authorization scope and structured input for importMatchdayFromRBT.

The new mutation accepts a raw data: String! parameter instead of a structured input type. While this may be intentional for flexible RBT format handling, it reduces API documentation and schema clarity compared to other mutations.

Additionally, the mutation only requires @aws_cognito_user_pools without group-based restrictions (unlike admin operations on lines 574–575). Consider whether importing matchday data should be restricted to admins or group leaders with explicit authorization checks.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c3cef67 and 73ef537.

📒 Files selected for processing (1)

• schema.graphql (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🔇 Additional comments (2)

schema.graphql (2)

225-239: LGTM!

The new RankingEntry and CalendarDate types are well-designed with clear field semantics and proper references to existing types. Both include appropriate authentication directives.

---

587-594: Clarify intent of getAllMatchdaysInSeason vs existing getListOfMatchdaysInSeason.

Line 594 introduces getAllMatchdaysInSeason(seasonId: ID!): [MatchDay!]!, but line 557 already has getListOfMatchdaysInSeason(seasonId: ID!): [MatchDay] that appears to serve the same purpose. Both accept the same parameter and return matchday collections for a season.

Differences:

• Naming: getAll* vs getList*
• Return type: non-nullable items/list vs nullable (less strict)

Are both intended, or should one be deprecated to avoid API confusion?

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

docs/assets/navigation.js (1)

1-1: Consider excluding generated documentation from the repository.

All documentation files in this PR (navigation.js, TypeDoc HTML pages) appear to be build artifacts. Committing generated files can lead to repository bloat, merge conflicts, and documentation drift from the source schema.

Recommended approach:

1. Add docs/ to .gitignore
2. Generate documentation as part of your CI/CD pipeline or publish workflow
3. Host the generated docs separately (e.g., GitHub Pages, documentation site)

If you must commit generated docs:

• Ensure they're regenerated on every schema change
• Consider a separate docs branch to keep main branch history clean

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 73ef537 and 1b598a6.

⛔ Files ignored due to path filters (1)

• src/generated/graphql.model.generated.ts is excluded by !**/generated/**

📒 Files selected for processing (8)

• docs/assets/navigation.js (1 hunks)
• docs/assets/search.js (1 hunks)
• docs/types/CalendarDate.html (1 hunks)
• docs/types/MutationImportMatchdayFromRbtArgs.html (1 hunks)
• docs/types/QueryGetAllMatchdaysInSeasonArgs.html (1 hunks)
• docs/types/QueryGetLeagueGroupRankingArgs.html (1 hunks)
• docs/types/QueryGetUpcomingMatchdaysArgs.html (1 hunks)
• docs/types/RankingEntry.html (1 hunks)

✅ Files skipped from review due to trivial changes (3)

• docs/types/QueryGetAllMatchdaysInSeasonArgs.html
• docs/assets/search.js
• docs/types/CalendarDate.html

🔇 Additional comments (4)

docs/types/RankingEntry.html (1)

1-9: Documentation structure looks good.

The RankingEntry type documentation is well-formed with appropriate fields for representing league standings. All numeric statistics use the Int scalar type as expected.

docs/types/MutationImportMatchdayFromRbtArgs.html (1)

1-3: Mutation arguments documented correctly.

The importMatchdayFromRBT mutation arguments are properly documented with required groupId and data parameters.

docs/types/QueryGetLeagueGroupRankingArgs.html (1)

1-3: Query arguments well-designed.

The getLeagueGroupRanking query has a good parameter structure with required groupId and an optional includeNonCompetitive filter, providing flexibility for different use cases.

docs/types/QueryGetUpcomingMatchdaysArgs.html (1)

1-3: Query arguments documented correctly.

The getUpcomingMatchdays query appropriately requires both associationId and seasonId to scope the results.

Note: The actual GraphQL schema file (schema.graphql) does not appear to be included in this PR. Please ensure the source schema has been reviewed and that these generated docs accurately reflect the intended API changes.