> ## 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. # Global Settings > Understand the project sources, structure, and conventions used to build and maintain Clubedge documentation Every project documented in the Clubedge documentation portal has its own technical structure and sources of truth. The documentation should reflect the project as it actually exists rather than assuming every project uses the same stack or repository layout. ## Properties ### README.md The project's root `README.md` is the first reference when documenting a project. It should explain what the project does, how to get started, the main development workflow, and where developers can find deeper technical documentation. Example: ```text theme={null} README.md ``` ### package.json Node.js projects normally use `package.json` as the source of truth for scripts, dependencies, package metadata, and package-manager configuration. Use it when documenting installation, development, testing, building, linting, and other project commands. Examples: ```json Node.js application theme={null} { "scripts": { "dev": "nest start --watch", "test": "jest", "build": "nest build" } } ``` ```text Monorepo theme={null} package.json packages/ apps/ ``` ### OpenAPI Backend projects may expose an OpenAPI specification that defines their HTTP API. When available, use the project's OpenAPI specification as the source of truth for endpoints, authentication, parameters, request bodies, responses, and schemas. Common locations include: ```text YAML theme={null} openapi/v1/openapi.yaml ``` ```text JSON theme={null} openapi/v1/openapi.json ``` ```text Directory theme={null} openapi/v1/ ``` ### Environment configuration Projects may provide example environment files or configuration documentation for required runtime variables. Never document real secrets or credentials. Use placeholders and reference the project's environment configuration when needed. Examples: ```text theme={null} .env.example ``` ```text theme={null} .env.local.example ``` ```text theme={null} config/ ``` ### Monorepo Some Clubedge projects are organized as monorepos containing multiple applications, packages, SDKs, or shared tooling. Documentation should clearly identify whether a command applies to the repository root, a specific application, or a specific package. Examples: ```text pnpm theme={null} pnpm-workspace.yaml ``` ```text Turborepo theme={null} turbo.json ``` ```text Common structure theme={null} apps/ packages/ ``` ### Project documentation Projects may contain additional documentation files for architecture, decisions, workflows, deployment, or technical details. Use the existing project documentation as source material instead of duplicating information that is already maintained by the project. Examples: ```text theme={null} docs/ architecture/ ADRs/ ``` ### Navigation Documentation navigation should reflect what developers need to find, not simply mirror the project's filesystem. Product documentation can be grouped by product while shared documentation remains available independently. Example: ```text theme={null} Guides Getting started Introduction Quickstart Development Products Feature Flags Overview Getting started Admin workflow SDKs Node.js Browser React Next.js NestJS Direct HTTP ``` ### Product Each product gets its own documentation area inside the shared Clubedge documentation portal. Product pages should contain information specific to that product, including its concepts, setup, workflows, APIs, SDKs, and integrations. Example: ```text theme={null} Products/Feature Flags/ ``` ### Guides Guides contain documentation that applies to the documentation workflow or to multiple projects rather than to one product. Examples: ```text theme={null} Guides/Getting started/Introduction ``` ```text theme={null} Guides/Getting started/Quickstart ``` ```text theme={null} Guides/Getting started/Development ``` ### SDK documentation Products that expose SDKs should document each supported runtime or framework separately when the integration differs. Example: ```text theme={null} Node.js Browser React Next.js NestJS Direct HTTP ``` ### API API documentation should be included when a project exposes a backend API. Prefer using the project's OpenAPI specification to generate or maintain API reference documentation so the documented contract stays aligned with the implementation. **OpenAPI file path** A path to the OpenAPI specification maintained by the project. Example: `openapi/v1/openapi.yaml` **OpenAPI URL** A URL pointing to a published OpenAPI specification when the project exposes one. Example: `https://api.example.com/openapi/v1/openapi.json` ### Repository Documentation should link technical information back to the project repository when developers need to inspect the implementation. The repository is especially useful for verifying current scripts, dependencies, configuration, source structure, and implementation details. Example: ```text theme={null} GitHub repository → README.md → package.json → source → tests ``` ### Source of truth Technical documentation should always be based on the current project implementation and its maintained configuration. Use the appropriate source depending on what you are documenting. ```text Project overview theme={null} README.md ``` ```text Node.js commands and dependencies theme={null} package.json ``` ```text API contract theme={null} openapi/v1/openapi.yaml ``` ```text Runtime configuration theme={null} .env.example ``` ```text Monorepo structure theme={null} pnpm-workspace.yaml apps/ packages/ ``` ### Versions When a project has multiple supported versions, document version-specific behavior clearly. Examples: ```text theme={null} Products/Feature Flags/v1/ ``` ```text theme={null} API /openapi/v1/ /openapi/v2/ ``` ### Branding Product documentation should use the product's established terminology, naming, and visual identity while remaining part of the shared Clubedge documentation portal. The shared portal should not force every product to have identical technical content. ### Feedback Documentation should make it easy for developers to report incorrect, outdated, or missing technical information. Feedback should be actionable and tied to the relevant product, page, API contract, SDK, or repository when possible. ### Mode toggle Documentation should remain readable in both light and dark themes. Code examples, diagrams, screenshots, and other visual content should be checked in both modes when they are used. ### Background image Product documentation may use product-specific visual assets when they improve understanding, but technical content should remain clear without relying on decorative backgrounds or visual effects.