### Install Node.js with Volta

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Use Volta to install the Node.js version specified in the project's package.json. Volta automatically manages toolchains, ensuring the correct Node.js version is used when working within the project directory.

```bash
volta install node
```

--------------------------------

### Install Node.js with NVM

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Use NVM (Node Version Manager) to install and activate the Node.js version specified in the project's .nvmrc file. This ensures you are using the correct Node.js environment for development.

```bash
nvm install
nvm use
```

--------------------------------

### Run All Development Servers

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Start the development servers for both the frontend and backend applications simultaneously. Ensure all necessary environment secrets are configured before executing this command.

```bash
pnpm dev
```

--------------------------------

### Run Frontend Development Server

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Start only the frontend development server. This is useful when you want to focus solely on frontend development or when the backend is hosted separately.

```bash
pnpm dev --filter=frontend
```

--------------------------------

### Run Backend Development Server

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Start only the backend development server. This command is useful for working on API logic or when the frontend is being developed independently.

```bash
pnpm dev --filter=backend
```

--------------------------------

### Check Git Version

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Verify if Git is installed on your system by running this command in your terminal. A version number should be displayed if Git is correctly set up.

```bash
git --version
```

--------------------------------

### Enable Corepack for PNPM

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Enable Corepack, a tool that helps manage package manager binaries like PNPM. This command ensures that the correct version of PNPM is used for installing project dependencies.

```bash
corepack enable
```

--------------------------------

### Clone Repository via HTTP

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Clone the uabc-web project repository using the HTTP protocol. This command downloads all project files to your local machine, creating a new directory named 'uabc-web'.

```bash
git clone https://github.com/UoaWDCC/uabc-web.git
```

--------------------------------

### Clone Repository via SSH

Source: https://github.com/uoawdcc/uabc-web/wiki/Onboarding

Clone the uabc-web project repository using the SSH protocol. This method requires SSH keys to be properly configured on your system and GitHub account for authentication.

```bash
git clone git@github.com:UoaWDCC/uabc-web.git
```

--------------------------------

### Install and Use Node.js with nvm

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

These commands are used to install the correct Node.js version specified in the project's configuration and then switch to use that version. This ensures that all developers are working with the same Node.js environment, preventing compatibility issues.

```bash
nvm install
nvm use
```

--------------------------------

### Start All Applications in Development Mode with pnpm

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This command initiates all applications within the monorepo in development mode. It typically starts both the frontend and backend servers concurrently, allowing for integrated local development and testing of the entire system.

```bash
pnpm dev
```

--------------------------------

### Examples of Semantic Commit Messages

Source: https://github.com/uoawdcc/uabc-web/wiki/Contributing-Guidelines

This provides concrete examples of how to format semantic commit messages using the approved types. Each example demonstrates the `type: subject` format, illustrating common use cases for different commit categories.

```text
chore: add Oyster build script
docs: explain hat wobble
feat: add beta sequence
fix: remove broken confirmation message
refactor: share logic between 4d3d3d3 and flarhgunnstow
style: convert tabs to spaces
test: ensure Tayne retains clothing
```

--------------------------------

### Enable Corepack and Install Project Dependencies with pnpm

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This sequence of commands first enables Corepack, a tool that helps manage package managers like pnpm, ensuring it's available. Subsequently, it installs all project dependencies using pnpm, preparing the monorepo for development by fetching all required packages.

```bash
corepack enable
pnpm install
```

--------------------------------

### Yamada-UI Basic Component Styling Example

Source: https://github.com/uoawdcc/uabc-web/wiki/Yamada-UI

Demonstrates fundamental usage of Yamada-UI's `Center` and `Box` components, showcasing how to apply common styling props like `w`, `bg`, `p`, `rounded`, `color`, `h`, and `bgGradient` for layout and visual presentation.

```tsx
<Center w="calc(lg / 2)" bg="primary" p="md" rounded="md" color="white">
  Calc
</Center>

<Box w="full" h="xs" bgGradient="linear(to-r, purple.500, blue.400)" />
```

--------------------------------

### Turborepo Monorepo Management Commands

Source: https://github.com/uoawdcc/uabc-web/wiki/Turborepo-Architecture

Provides essential `pnpm` commands for managing the UABC Web monorepo, including dependency installation, running development servers, building projects, and executing tests, with options to filter operations by specific workspaces.

```bash
# Install dependencies
pnpm install

# Development
pnpm dev                          # Run all apps in development mode
pnpm dev --filter frontend       # Run only frontend
pnpm dev --filter backend        # Run only backend

# Building
pnpm build                        # Build all packages and apps
pnpm build --filter frontend     # Build frontend only
pnpm build --filter backend      # Build backend only

# Testing
pnpm test                         # Run all tests
pnpm test --filter frontend      # Test frontend only
pnpm test --filter backend       # Test backend only

# Other useful filter commands
pnpm lint --filter frontend      # Lint frontend only
pnpm check-types --filter backend  # Check types backend only
```

--------------------------------

### Run Specific Applications in Development Mode with pnpm

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

These commands allow developers to start only a specific application (either the frontend or the backend) within the monorepo in development mode. This is particularly useful for focused development, debugging, or when only one part of the system needs to be active.

```bash
# Run only the frontend
pnpm dev --filter=frontend

# Run only the backend
pnpm dev --filter=backend
```

--------------------------------

### Using Layout Primitives for Structured UI in Yamada-UI

Source: https://github.com/uoawdcc/uabc-web/wiki/Yamada-UI

This example illustrates the best practice of using Yamada-UI's layout primitives like HStack for arranging components. It contrasts avoiding inline styles and manual margins with the preferred method of using HStack and its "gap" prop for consistent spacing and improved readability.

```tsx
<div style={{ display: 'flex', flexDirection: 'row' }}>
  <Box>Item 1</Box>
  <Box style={{ marginLeft: '16px' }}>Item 2</Box>
</div>
```

```tsx
<HStack gap="md">
  <Box>Item 1</Box>
  <Box>Item 2</Box>
</HStack>
```

--------------------------------

### Using Semantic Tokens for Styling in Yamada-UI

Source: https://github.com/uoawdcc/uabc-web/wiki/Yamada-UI

This example demonstrates the recommended approach for styling components in Yamada-UI using semantic tokens instead of hardcoded pixel values. It shows how "md" and "lg" tokens provide consistency, theme adaptability, and maintainability for padding and font sizes.

```tsx
<Box padding="20px" />
<Text fontSize="18px">Hello</Text>
```

```tsx
<Box padding="md" />
<Text fontSize="lg">Hello</Text>
```

--------------------------------

### Google OAuth Authorized JavaScript Origins Configuration

Source: https://github.com/uoawdcc/uabc-web/wiki/Backend-Architecture

This snippet provides the authorized JavaScript origins required for Google OAuth setup. These URLs specify the domains from which your application can request authentication.

```Text
http://localhost:3000
https://your-website.fly.dev
```

--------------------------------

### Using CSS Value Functions in Yamada-UI Style Props

Source: https://github.com/uoawdcc/uabc-web/wiki/Yamada-UI

This section provides examples of how Yamada-UI's CSS Value Functions can be used directly within style props for dynamic calculations, comparisons, and color manipulations. These functions allow for responsive and theme-consistent styles without leaving component code.

```tsx
w="calc(lg / 2)"
```

```tsx
bg="mix(red.500, blue.500)"
```

```tsx
bg="tint(purple.500, 50%)"
```

```tsx
bgGradient="linear(to-r, purple.500, blue.400)"
```

--------------------------------

### Setting Up Environment Variables

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This bash script outlines the process for initializing environment variable files across a monorepo structure. It instructs users to copy `.env.example` templates to `.env` files in the root, frontend, and backend directories, which is crucial for configuring application settings securely.

```bash
# Root directory
cp .env.example .env

# Frontend
cp apps/frontend/.env.example apps/frontend/.env

# Backend
cp apps/backend/.env.example apps/backend/.env
```

--------------------------------

### Biome CLI Commands for Formatting and Linting

Source: https://github.com/uoawdcc/uabc-web/wiki/Styling-and-Convention

Demonstrates common Biome CLI commands for checking code formatting, linting, and performing both checks simultaneously across the project. These commands are typically run via pnpm.

```bash
pnpm biome format .
pnpm biome lint .
pnpm biome check .
```

--------------------------------

### Git Branching Workflow for uabc-web

Source: https://github.com/uoawdcc/uabc-web/wiki/Contributing-Guidelines

This snippet provides the command-line interface (CLI) steps to create a new feature branch from the `master` branch. It ensures the local `master` is up-to-date before creating the new branch, following the project's branch naming convention.

```bash
git checkout master
git pull
git checkout -b <branch name>
```

--------------------------------

### Running a Specific Test File with Vitest

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This command allows developers to execute a single test file or a set of tests matching a specific pattern using Vitest. It's useful for focused development and debugging, enabling quick iteration on individual components without running the entire test suite.

```bash
# src/app/example-double-admin-count/route.ts can be any file path that points to a test.
# Or you can replace the file path with a pattern (like a file name)
pnpm test src/app/example-double-admin-count/route.test.ts
```

--------------------------------

### Git Workflow for Creating a New Feature Branch

Source: https://github.com/uoawdcc/uabc-web/blob/master/CONTRIBUTING.md

This snippet demonstrates the standard Git workflow for initiating work on a new feature or bug fix. It ensures the local master branch is up-to-date before creating a new branch, which should be named using the associated issue number for clarity and tracking.

```bash
git checkout master
git pull
# You need to replace <issue number> with the issue number you are working on
git checkout -b <issue number>-<branch-name>
```

--------------------------------

### Running All Project Tests with Vitest

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This command executes all automated tests configured within the project using Vitest as the test runner. It's a quick way to verify the overall health and functionality of the codebase, ensuring that recent changes haven't introduced regressions.

```bash
pnpm test
```

--------------------------------

### Defining Internal Workspace Dependencies

Source: https://github.com/uoawdcc/uabc-web/wiki/Turborepo-Architecture

Illustrates the `package.json` syntax for declaring dependencies on other packages within the same monorepo workspace, using the `workspace:*` protocol to ensure consistent versioning and linking.

```json
{
  "dependencies": {
    "@repo/ui": "workspace:*",
    "@repo/theme": "workspace:*"
  }
}
```

--------------------------------

### Documenting TypeScript Functions with JSDoc

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This snippet demonstrates the recommended JSDoc syntax for documenting TypeScript functions. It shows how to describe the function's purpose, parameters, and return value, enhancing code readability and maintainability for other developers.

```typescript
/**
 * Adds two numbers together
 *
 * @param a The first number
 * @param b The second number
 * @returns The sum of the two numbers
 */
export const add = (a: number, b: number): number => a + b
```

--------------------------------

### Applying Style Props for Direct Component Styling in Yamada-UI

Source: https://github.com/uoawdcc/uabc-web/wiki/Yamada-UI

This snippet demonstrates how Yamada-UI's style props enable direct, theme-aware styling on components. It shows how shorthand props like "w", "p", "bg", and "color" can be used with theme tokens to efficiently apply width, padding, background, and text color.

```tsx
<Box w="full" p="md" bg="warning" color="white">
  This is Box
</Box>
```

--------------------------------

### Manually Run Biome Checks for Code Quality

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

These commands allow developers to manually run Biome for checking code formatting, linting, or both. This ensures code consistency and adherence to project standards before committing, helping to maintain a clean and high-quality codebase.

```bash
pnpm biome format .
pnpm biome lint .
pnpm biome check .
```

--------------------------------

### Prefer HStack/VStack for Layout in Yamada-UI

Source: https://github.com/uoawdcc/uabc-web/wiki/Yamada-UI

Illustrates the recommended practice of using `HStack` or `VStack` for horizontal and vertical layouts in Yamada-UI, respectively, instead of the more generic `Flex` component. This approach improves code clarity and maintainability by expressing layout intent more explicitly.

```tsx
<Flex direction="row" gap="md">
  <Box>Item 1</Box>
  <Box>Item 2</Box>
</Flex>
```

```tsx
<HStack gap="md">
  <Box>Item 1</Box>
  <Box>Item 2</Box>
</HStack>
```

--------------------------------

### Turborepo Task Pipeline Configuration

Source: https://github.com/uoawdcc/uabc-web/wiki/Turborepo-Architecture

Defines the task pipeline, global dependencies, and output caching for a Turborepo monorepo. It specifies build, lint, and dev tasks with their respective configurations, including dependencies and cache settings.

```JSON
{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": ["**/.env.*local"],
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**"]
    },
    "lint": {},
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}
```

--------------------------------

### PNPM Workspace Structure Definition

Source: https://github.com/uoawdcc/uabc-web/wiki/Turborepo-Architecture

Configures the PNPM workspace, specifying the directories where packages are located within the monorepo. This allows PNPM to manage dependencies and link packages across the workspace.

```YAML
packages:
  - 'apps/*'
  - 'packages/*'
```

--------------------------------

### Resolve PNPM Dependency Issues

Source: https://github.com/uoawdcc/uabc-web/wiki/Turborepo-Architecture

Provides a command-line solution to clean and reinstall dependencies in a PNPM workspace. This is useful for resolving corrupted node_modules or dependency conflicts.

```Bash
# Clean install
pnpm clean
pnpm install
```

--------------------------------

### UABC Web Monorepo Directory Structure

Source: https://github.com/uoawdcc/uabc-web/wiki/Turborepo-Architecture

Defines the hierarchical organization of the UABC Web monorepo, distinguishing between application directories ('apps') and shared utility packages ('packages').

```text
uabc-web/
├── apps/                 # Application code
│   ├── backend/         # Payload CMS
│   └── frontend/        # Next.js frontend
├── packages/            # Shared packages
│   ├── tailwind-config/ # Shared Tailwind configuration
│   ├── test-config/     # Testing utilities and setup
│   ├── theme/           # Shared theme configuration
│   ├── typescript-config/ # Shared TypeScript configs
│   └── ui/              # Shared UI components
```

--------------------------------

### Updating Yamada UI Theme Type Definitions

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This command utilizes the Yamada CLI to update type definitions for Yamada UI theme tokens, ensuring proper TypeScript completions for custom theme properties. It processes theme tokens from `./src/theme` to generate necessary theme files, improving developer experience with accurate type hints.

```bash
pnpm theme
```

--------------------------------

### Generating PayloadCMS Types

Source: https://github.com/uoawdcc/uabc-web/blob/master/README.md

This command triggers Payload's built-in code generation feature to create TypeScript type definitions for the project's data structures. Running this ensures that the application has accurate type completions and strong typing for content managed by PayloadCMS.

```bash
pnpm generate:types
```

--------------------------------

### APIDOC: GameSessionSchedule Collection Schema

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

Defines the schema for the 'GameSessionSchedule' collection, which serves as a template for individual game sessions. It includes fields for session times, capacities, and a reference to the related 'Semester' document.

```APIDOC
Collection: GameSessionSchedule
  Description: Acts as a template for gameSession, with fields deriving data for gameSession.
  Notes:
    - startTime, endTime: Represent full timestamps, but only hours and minutes are extracted (e.g., 12:00).
    - bookingStart, bookingEnd: Not recorded here as they depend on the related Semester; default close time is a day before the session starts.
  Fields:
    id:
      Type: string
      Description: The document ID
      Example: ""
    startTime:
      Type: timestamp
      Description: Time when the game session actually is
      Example: 01 January 1970 at 12:00:00
    endTime:
      Type: timestamp
      Description: Time when the game session actually ends
      Example: 01 January 1970 at 12:00:00
    capacity:
      Type: number
      Description: Maximum capacity of members.
      Example: 10
    casualCapacity:
      Type: number
      Description: Maximum capacity of casuals.
      Example: 5
    semester:
      Type: string
      Description: The document ID of the session's related Semester
      Example: ""
```

--------------------------------

### Payload CMS `User` Collection Schema

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

The `User` collection manages core user data. Some fields are optional and are intended for additional information collected during post-signup onboarding processes.

```APIDOC
User:
  id: string (The document ID)
  firstName: string (First name of the user) [John]
  lastName: string (Last name of the user) [Doe]
  gender?: string (Gender of the user) [Non Binary]
  phoneNumber?: string (Phone number of the user) [021 2345 6789]
  playLevel?: PlayLevel (The play level of the user) [beginner]
  gender?: Gender (The gender of the user)
  dietaryRequirements?: string (Dietary requirements of the user) [Vegan]
  studentId?: string (The student ID of the user) [1234565677]
  studentUpi?: string (The student UPI of the user) [abc123]
  university?: string (The university of the user) [UoA]
  role: member|casual|admin (Internal system role of the user) [member]
  remainingSessions: number (Remaining court booking sessions) [12]
  email: string (The email of the user) [johndoe@gmail.com]
  image?: string (An optional profile image) [https://image.com]
```

--------------------------------

### Event Collection API Documentation

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

This collection is used by club administrators to display and manage events on the website, providing details such as title, descriptions, and associated images or links.

```APIDOC
Event:
  id: string (The document ID)
  title: string (The name of the event, e.g., UABC Welcome Party)
  longDescription: richText (The long description of the event)
  shortDescription: text (The short description of the event, e.g., A cool event)
  eventImage: Media (The image preview of the event)
  button1: Link (The 1st button link of the event)
  button2: Link (The 2nd button link of the event)
```

--------------------------------

### Valid Semantic Commit Message Types

Source: https://github.com/uoawdcc/uabc-web/wiki/Contributing-Guidelines

This lists the predefined commit types that must be used when writing semantic commit messages for the uabc-web project. These types are enforced by commit lints to maintain a consistent commit history.

```text
[build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test]
```

--------------------------------

### APIDOC: Semester Collection Schema

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

Defines the schema for the 'Semester' collection, which manages semester-specific data for game sessions. It includes fields for semester duration, break periods, and booking open times, with specific notes on timestamp interpretation.

```APIDOC
Collection: Semester
  Description: Manages semester data for game sessions.
  Notes:
    - bookingOpenTime: Only hours and minutes are extracted (e.g., 12:00).
    - startDate, endDate, breakStart, breakEnd: Only dates are considered, time is assumed to be 00:00.
    - weekday: Will have an enum (tech debt).
  Fields:
    id:
      Type: string
      Description: The document ID
      Example: ""
    name:
      Type: string
      Description: The semester's name
      Example: Semester 2 2024
    startDate:
      Type: timestamp
      Description: The start date of the semester
      Example: 06 September 2025 at 00:00:00
    endDate:
      Type: timestamp
      Description: The end date of the semester
      Example: 06 September 2025 at 00:00:00
    breakStart:
      Type: timestamp
      Description: The start date of semester break
      Example: 06 September 2025 at 00:00:00
    breakEnd:
      Type: timestamp
      Description: The end date of semester break
      Example: 06 September 2025 at 00:00:00
    bookingOpenDay:
      Type: weekday
      Description: When the bookings open
      Example: Wednesday
    bookingOpenTime:
      Type: timestamp
      Description: What time the booking open on open day
      Example: 01 January 1970 at 12:00:00
```

--------------------------------

### GameSession Collection API Documentation

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

The `GameSession` collection stores copies of data from `GameSessionSchedule`, acting as a child with relevant booking information. Most fields are derived from `gameSessionSchedule`, though some can be edited. `startTime` and `endTime` represent the actual session times.

```APIDOC
GameSession:
  id: string (The document ID)
  gameSessionSchedule?: GameSessionSchedule (Document ID)
  semester: Semester (The Semester document)
  startTime: timestamp (Game session start time, e.g., 06 September 2024 at 00:00:00)
  endTime: timestamp (Game session end time, e.g., 06 September 2024 at 00:00:00)
  capacity: number (Max capacity of members, e.g., 60)
  casualCapacity: number (Max capacity of casuals, e.g., 5)
```

--------------------------------

### Booking Collection API Documentation

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

The `Booking` collection links `user` and `gameSession` collections, indicating a user's reservation for a specific session. The number of bookings for a `gameSession` should limit available slots.

```APIDOC
Booking:
  id: string (The document ID)
  user: User (The User document ID associated to this booking)
  gameSession: GameSession (The document of the game session)
  playLevel: PlayLevel (The player's skill level, e.g., PlayLevel.beginner)
```

--------------------------------

### Google OAuth Authorized Redirect URIs Configuration

Source: https://github.com/uoawdcc/uabc-web/wiki/Backend-Architecture

This snippet provides the authorized redirect URIs for Google OAuth. After successful authentication, Google will redirect users back to one of these specified URLs.

```Text
http://localhost:3000/api/auth/google/callback
https://your-website.fly.dev/api/auth/google/callback/
```

--------------------------------

### Generate JWT Secret using Node.js Crypto

Source: https://github.com/uoawdcc/uabc-web/wiki/Backend-Architecture

This Node.js command generates a cryptographically secure random hexadecimal string suitable for use as a JWT secret. This secret is essential for signing and verifying JSON Web Tokens.

```Node.js
node -e "console.log(crypto.randomBytes(64).toString('hex'))"
```

--------------------------------

### Payload CMS `Authentication` Collection Schema

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

The `Authentication` collection is designed to manage user authentication information securely, preventing exposure of sensitive data. It stores details related to user authentication sessions.

```APIDOC
Authentication:
  id: string (The document ID)
  user: User (The user that's related to this auth)
  email: string (The user email that's related to this auth)
  password?: string (The hashed password)
  provider: 'google' (The provider of the authentication used) [google]
  providerAccountId?: string (The google account id)
  refreshToken?: string (The refresh token of the user authentication)
  accessToken: string (The access token of the user authentication)
  expiresAt: number (The expiration time of the access token)
  tokenType?: string (The type of token)
  scope?: string (The scope of the token)
  idToken?: string (The id token of the user authentication)
```

--------------------------------

### Payload CMS `Admin` Collection Schema

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

This section describes the default auto-generated collection data for the `Admin` collection in Payload CMS. Note that several other auto-generated fields like `resetPasswordToken`, `resetPasswordExpiration`, `salt`, `hash`, `loginAttempts`, `lockUntil`, and `password` are not explicitly listed here.

```APIDOC
Admin:
  id: string (The document ID)
  email: string (The email of the admin) [johndoe@gmail.com]
  password?: string (The hashed password of the admin)
```

--------------------------------

### JavaScript Convert Date to Milliseconds in Day

Source: https://github.com/uoawdcc/uabc-web/wiki/MongoDB-Architecture

This JavaScript snippet calculates the total milliseconds from the beginning of the day (00:00:00) up to the current hour and minute of a `Date` object. It's useful for extracting the time-of-day component from a timestamp.

```javascript
const date = new Date();
const totalMiliseconds =
  date.getHours() * 60 * 60 * 1000 + date.getMinutes() * 60 * 1000;
```

=== COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.