> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.clubedge.live/llms.txt
> Use this file to discover all available pages before exploring further.

# Navigation

> The navigation structure defines how Clubedge documentation is organized and how users move between project documentation, guides, and products.

The navigation menu is the list of links that helps users move through the Clubedge documentation portal.

The navigation structure should reflect the actual organization of the projects being documented. Clubedge documentation can contain multiple products, project-specific guides, SDK documentation, API references, and shared documentation resources.

You will update the navigation configuration when you add a new documentation page, product, project, or documentation section. Pages do not show up automatically unless they are included in the navigation configuration.

## Navigation syntax

The Clubedge documentation navigation is organized according to the structure of the documentation portal. Top-level sections can represent shared documentation areas or products, while nested groups organize the documentation belonging to each product or project.

For example, a product can contain its own overview, getting started documentation, workflows, and SDK documentation.

<CodeGroup>
  ```json Product Navigation theme={null}
  "navigation": {
    "tabs": [
      {
        "tab": "Products",
        "groups": [
          {
            "group": "Feature Flags",
            "pages": [
              "products/feature-flags/overview",
              "products/feature-flags/getting-started",
              "products/feature-flags/admin-workflow"
            ]
          }
        ]
      }
    ]
  }
  ```

  ```json Product With Nested SDK Navigation theme={null}
  "navigation": {
    "tabs": [
      {
        "tab": "Products",
        "groups": [
          {
            "group": "Feature Flags",
            "pages": [
              "products/feature-flags/overview",
              "products/feature-flags/getting-started",
              "products/feature-flags/admin-workflow",
              {
                "group": "SDKs",
                "pages": [
                  "products/feature-flags/sdks/node",
                  "products/feature-flags/sdks/browser",
                  "products/feature-flags/sdks/react",
                  "products/feature-flags/sdks/nextjs",
                  "products/feature-flags/sdks/nestjs",
                  "products/feature-flags/sdks/http"
                ]
              }
            ]
          }
        ]
      }
    ]
  }
  ```
</CodeGroup>

## Folders

Documentation files should be organized according to the project or product they describe.

For example, a Feature Flags product can have the following structure:

```text theme={null}
products/
└── feature-flags/
    ├── overview.mdx
    ├── getting-started/
    │   ├── introduction.mdx
    │   ├── quickstart.mdx
    │   └── development.mdx
    ├── admin-workflow.mdx
    └── sdks/
        ├── node.mdx
        ├── browser.mdx
        ├── react.mdx
        ├── nextjs.mdx
        ├── nestjs.mdx
        └── http.mdx
```

The same principle applies to other Clubedge products and projects. The documentation structure should follow the actual project structure rather than assuming that every project has the same files or technologies.

A project may be a Node.js application, a frontend application, a backend service, a monorepo, an SDK, or another type of project. Its documentation should reflect the files, tooling, architecture, and interfaces that actually exist in that project.

<Warning>
  Do not create documentation paths or sections for files, technologies, APIs, SDKs, or configuration that do not exist in the project. Navigation should describe the real project and should be updated as the project evolves.
</Warning>

## Project documentation

Project documentation can reference the project's existing source documentation and configuration files when those resources are relevant.

Common project-level resources may include:

* A root `README.md` describing the project, its purpose, setup, architecture, and usage.
* A `package.json` for Node.js projects containing dependencies, scripts, package metadata, and tooling configuration.
* Other package or dependency manifests when the project uses a different ecosystem.
* An OpenAPI specification when the project exposes an HTTP API.
* SDK documentation when the project provides an SDK or client library.
* Configuration files that define important development, build, test, deployment, or runtime behavior.
* Monorepo workspace configuration when the project contains multiple packages or applications.

These resources should be documented only when they are present and relevant to the project.

## OpenAPI documentation

Projects that expose an HTTP API may provide an OpenAPI specification. When available, it can be connected to the documentation navigation so that API endpoints can be explored directly.

For example, an OpenAPI specification may be available at a project path such as:

```text theme={null}
openapi/v1/openapi.json
```

or another project-specific location.

<CodeGroup>
  ```json OpenAPI File theme={null}
  "navigation": {
    "tabs": [
      {
        "tab": "Products",
        "groups": [
          {
            "group": "Feature Flags",
            "pages": ["products/feature-flags/overview"]
          }
        ]
      },
      {
        "tab": "API Reference",
        "openapi": "/openapi/v1/openapi.json"
      }
    ]
  }
  ```

  ```json OpenAPI URL theme={null}
  "navigation": {
    "tabs": [
      {
        "tab": "API Reference",
        "openapi": "https://example.com/openapi/v1/openapi.json"
      }
    ]
  }
  ```

  ```json OpenAPI Multiple Specifications theme={null}
  "navigation": {
    "tabs": [
      {
        "tab": "API Reference",
        "openapi": [
          "/openapi/v1/openapi.json",
          "/openapi/v2/openapi.json"
        ]
      }
    ]
  }
  ```
</CodeGroup>

The exact OpenAPI path depends on the project. Do not assume that every Clubedge project exposes an OpenAPI specification.

## Monorepo projects

Monorepo projects can contain multiple applications, packages, SDKs, and shared libraries. Their documentation should preserve the same boundaries used by the repository.

For example:

```text theme={null}
apps/
├── api/
├── web/
└── worker/

packages/
├── sdk/
├── ui/
└── config/
```

The navigation can expose documentation for these areas separately when they have meaningful documentation of their own.

```json Monorepo Navigation theme={null}
"navigation": {
  "tabs": [
    {
      "tab": "Products",
      "groups": [
        {
          "group": "Workspace",
          "pages": [
            "products/workspace/overview",
            "products/workspace/getting-started"
          ]
        }
      ]
    },
    {
      "tab": "Development",
      "groups": [
        {
          "group": "Applications",
          "pages": [
            "development/apps/api",
            "development/apps/web",
            "development/apps/worker"
          ]
        },
        {
          "group": "Packages",
          "pages": [
            "development/packages/sdk",
            "development/packages/ui",
            "development/packages/config"
          ]
        }
      ]
    }
  ]
}
```

## Hidden pages

MDX files that are not included in the navigation configuration will not show up in the sidebar but can still be accessible through direct links and search, depending on the documentation site's configuration.

Hidden pages can be useful for supporting documentation, migration notes, internal references, or pages that should remain accessible without being part of the main navigation.

A page should not be hidden simply because it has not yet been added to the navigation. If it is part of the intended documentation experience, add it to the appropriate navigation section.