rinafcode · RUKAYAT-CODER · Jul 29, 2026 · Jul 29, 2026
diff --git a/docs/API_VERSIONING_POLICY.md b/docs/API_VERSIONING_POLICY.md
@@ -1,15 +1,14 @@
 # API Versioning Policy
-
+<!-- 
 ## Overview
 
 This project uses URL-based API versioning to protect clients from breaking changes.
 
 - Stable API paths continue to be served at `/api/v1/*`
 - Legacy paths under `/api/*` remain supported through a compatibility layer
-- Older `/api/*` requests are rewritten to `/api/v1/*` and receive deprecation headers
+- Older `/api/*` requests are rewritten to `/api/v1/*` and receive deprecation headers -->
 
 ## Versioning strategy
-
 - New API routes are published under `/api/v1/`
 - Future versions should be added under `/api/v2/`, `/api/v3/`, etc.
 - Path-based versioning is the primary version selection mechanism

diff --git a/docs/BUTTON_VARIANTS.md b/docs/BUTTON_VARIANTS.md
@@ -11,6 +11,13 @@ import { Button, ButtonGroup } from '@/components';
 import type { ButtonProps } from '@/components';
 ```
 
+## Overview
+
+This project uses URL-based API versioning to protect clients from breaking changes.
+
+- Stable API paths continue to be served at `/api/v1/*`
+- Legacy paths under `/api/*` remain supported through a compatibility layer
+- Older `/api/*` requests are rewritten to `/api/v1/*` and receive deprecation headers
 ## Button
 
 ### Variants

diff --git a/docs/DISCORD_OAUTH_INTEGRATION.md b/docs/DISCORD_OAUTH_INTEGRATION.md
@@ -8,6 +8,14 @@ The Discord OAuth integration allows users to authenticate using their Discord a
 
 ## Features
 
+## Overview
+
+This project uses URL-based API versioning to protect clients from breaking changes.
+
+- Stable API paths continue to be served at `/api/v1/*`
+- Legacy paths under `/api/*` remain supported through a compatibility layer
+- Older `/api/*` requests are rewritten to `/api/v1/*` and receive deprecation headers
+
 - **OAuth2 Flow**: Implements the standard Discord OAuth2 authorization code flow
 - **Security**: Uses state parameter to prevent CSRF attacks
 - **Email Verification**: Requires Discord accounts to have verified emails

diff --git a/docs/NOTIFICATION_PERSISTENT_VOLUMES.md b/docs/NOTIFICATION_PERSISTENT_VOLUMES.md
@@ -1,8 +1,8 @@
 # Notification Persistent Volumes
-
+<!-- 
 The production notification system stores durable notification data on a Kubernetes
 PersistentVolumeClaim so pod restarts do not discard queued or cached notification
-state.
+state. -->
 
 ## Kubernetes Resources
 

diff --git a/docs/RUNBOOKS.md b/docs/RUNBOOKS.md
@@ -12,6 +12,10 @@ Each section follows the same structure:
 5. **Escalation** – who to page if the steps above don't resolve it within SLA.
 
 ---
+<!-- 
+The production notification system stores durable notification data on a Kubernetes
+PersistentVolumeClaim so pod restarts do not discard queued or cached notification
+state. -->
 
 ## Table of Contents
 

diff --git a/docs/TIP_CANARY_RELEASE.md b/docs/TIP_CANARY_RELEASE.md
@@ -4,7 +4,10 @@ Summary
 
 - **Purpose:** Enable percentage-based canary rollout for the Tip Receiving feature.
 - **Mechanism:** Server-side feature flag evaluated per-request with deterministic user bucketing.
-
+<!-- 
+The production notification system stores durable notification data on a Kubernetes
+PersistentVolumeClaim so pod restarts do not discard queued or cached notification
+state. -->
 Configuration
 
 - Set the rollout percentage via environment variable `TIP_RECEIVING_CANARY_PERCENT` (0-100).

diff --git a/docs/USER_SETTINGS_CAPABILITIES.md b/docs/USER_SETTINGS_CAPABILITIES.md
@@ -7,7 +7,10 @@ This document describes the implementation of Capabilities for User Settings as
 ## Virtual Background Feature (v3)
 
 ### Overview
-
+<!-- 
+The production notification system stores durable notification data on a Kubernetes
+PersistentVolumeClaim so pod restarts do not discard queued or cached notification
+state. -->
 The virtual background feature allows users to replace their actual background during video calls with various effects:
 
 - **Blur**: Applies a blur effect to the background

diff --git a/docs/ZOOM_PERFORMANCE_MONITORING.md b/docs/ZOOM_PERFORMANCE_MONITORING.md
@@ -1,7 +1,10 @@
 # Zoom Integration Performance Monitoring
 
 This document details the Zoom Integration Performance Monitoring feature implemented in the TeachLink platform.
-
+<!-- 
+The production notification system stores durable notification data on a Kubernetes
+PersistentVolumeClaim so pod restarts do not discard queued or cached notification
+state. -->
 ## Overview
 
 The Zoom Integration Performance Monitoring tracks real-time performance metrics of the Zoom Web Client SDK and REST API. This system allows administrators to proactively identify connection degradation, API outages, and SDK load issues that affect live online classes.

diff --git a/docs/profile-performance.md b/docs/profile-performance.md
@@ -1,9 +1,16 @@
 # Profile Page Performance
-
-The profile route keeps its static shell server-rendered and limits client JavaScript to the tab interaction layer.
+<!-- 
+The profile route keeps its static shell server-rendered and limits client JavaScript to the tab interaction layer. -->
 
 ## Implementation
 
+## Overview
+
+This project uses URL-based API versioning to protect clients from breaking changes.
+
+- Stable API paths continue to be served at `/api/v1/*`
+- Legacy paths under `/api/*` remain supported through a compatibility layer
+- Older `/api/*` requests are rewritten to `/api/v1/*` and receive deprecation headers
 - `src/app/profile/page.tsx` is a server component that renders the page shell and profile header.
 - `src/app/profile/components/ProfileTabs.tsx` owns the small client-side tab state.
 - The default profile panel renders first, while settings and achievements are split into lazy-loaded tab panels.