diff --git a/.claude/skills/branch-name/SKILL.md b/.claude/skills/branch-name/SKILL.md
index a6fc6e55cb61..717933991180 100644
--- a/.claude/skills/branch-name/SKILL.md
+++ b/.claude/skills/branch-name/SKILL.md
@@ -1,12 +1,12 @@
 ---
 name: branch-name
-description: Use when starting a new branch or renaming an existing one — produces a branch name in the format `<type>/<work-item-id>-<short-description>` that's compatible with the create-pr skill's work item ID extraction.
+description: Use when starting a new branch or renaming an existing one — produces a branch name in the format `<type>/<work-item-id>-<short-description>` that's compatible with the create-pull-request skill's work item ID extraction.
 user_invocable: true
 ---
 
 # Branch Naming
 
-Create branch names that follow the convention `<type>/<work-item-id>-<short-description>`, where the work item ID can be cleanly extracted later (e.g., by the create-pr skill).
+Create branch names that follow the convention `<type>/<work-item-id>-<short-description>`, where the work item ID can be cleanly extracted later (e.g., by the create-pull-request skill).
 
 ## Format
 
@@ -51,7 +51,7 @@ Create branch names that follow the convention `<type>/<work-item-id>-<short-des
 ```
 fix/silo-1146-relative-config-urls
 feat/web-1234-app-tile-visibility
-chore/web-2201-bump-eslint
+chore/web-2201-bump-oxlint
 refactor/silo-980-extract-auth-middleware
 docs/web-1500-pr-template-update
 perf/silo-1310-cache-workspace-lookup
diff --git a/.claude/skills/translate/SKILL.md b/.claude/skills/translate/SKILL.md
index ccedf77d655e..6c32d2770e94 100644
--- a/.claude/skills/translate/SKILL.md
+++ b/.claude/skills/translate/SKILL.md
@@ -136,11 +136,11 @@ Also preserve: OAuth, OIDC, SAML, SSO, LDAP, API, REST, GraphQL, URL, URI, ID, U
 
 ## Per-Script Rules
 
-Apply by target-language script, not by locale list. Adding a new Latin-script locale? It follows the Latin-script rules below. Adding a new Cyrillic locale? It follows the Cyrillic section. Scripts not yet shown here (Arabic, Hebrew, Thai, Greek, Hindi/Devanagari, etc.) — see **Adding a locale not documented here**.
+Apply by target-language script, not by locale list. Adding a new Latin-script locale? It follows the Latin-script rules below. Adding a new Cyrillic locale? It follows the Cyrillic section. Scripts not yet shown here (Arabic, Hebrew, Thai, Greek, Hindi/Devanagari, etc.) — see **Adding a locale not documented here**. This includes `ka-ge` (Georgian, Mkhedruli script), which is already in the repo but has no section yet.
 
 ### Latin-script locales
 
-Currently includes fr, es, it, de, pt-BR, pl, cs, sk, ro, tr-TR, vi-VN, id — and any future locale that uses the Latin alphabet (hu, nl, sv, da, nb, fi, hr, bg-using-Latin variants, etc.).
+Currently includes fr, es, it, de, nl, pt-BR, pl, cs, sk, ro, tr-TR, vi-VN, id — and any future locale that uses the Latin alphabet (hu, sv, da, nb, fi, hr, bg-using-Latin variants, etc.). `nl` is not yet in the glossary tables above; follow the Latin-script rules and add its column when you next touch it.
 
 **Translate Plane feature nouns** (Cycle, Cycles, Module, Modules, Epic, Epics, Page, Pages) using the per-locale form from the glossary above. **Keep Latin** for Plane brand marks (Plane, Plane AI, Power K, PQL, Active Cycles, Sticky, Stickies, Intake), plan tier names (Pro, Business, Enterprise), and third-party brands (GitHub, Slack, etc.).
 
@@ -187,7 +187,7 @@ For new terms not on the glossary: prefer the native Korean word where one exist
 
 Register:
 
-- **System and error messages** → 합니다체 (high-formal: 합니다, 됩니다, 입니다). Existing files in this register today: `ko/auth.json`, `ko/error/*.json`.
+- **System and error messages** → 합니다체 (high-formal: 합니다, 됩니다, 입니다). Existing files in this register today: `ko/auth.json`.
 - **Empty states, onboarding microcopy, tooltips** → 해요체 acceptable (softer: 해요, 돼요, 이에요) if the existing file uses it. Existing files in this register today: `ko/empty-state.json`, `ko/tour.json`. Always match the surrounding file rather than introducing a new register mid-namespace.
 - Never casual 반말.
 
@@ -255,19 +255,19 @@ Every `{count, plural, …}` string must contain **every** keyword the target la
 
 Below are the required keywords for locales currently in the repo. When adding a new locale, look up its categories in CLDR and add the row here.
 
-| Locale                                                 | Required keywords                                                                     | Example mapping                                                               |
-| ------------------------------------------------------ | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
-| en, es, de, bg, tr-TR, vi-VN, id, ja, ko, zh-CN, zh-TW | `one, other` (single-form locales may use `other` alone, but **always emit `other`**) | 1 → one; 2+ → other                                                           |
-| fr                                                     | `one, many, other`                                                                    | 0, 1 → one; 1 000 000 → many; else other                                      |
-| it                                                     | `one, many, other`                                                                    | 1 → one; 1 000 000 → many; else other                                         |
-| pt-BR                                                  | `one, many, other`                                                                    | 0, 1 → one; 1 000 000 → many; else other                                      |
-| ro                                                     | `one, few, other`                                                                     | 1 → one; 0, 2–19 → few; 20+ → other                                           |
-| pl                                                     | `one, few, many, other`                                                               | 1 → one; 2–4 (not 12–14) → few; 0, 5–20, many-digit → many; decimals → other  |
-| cs                                                     | `one, few, many, other`                                                               | 1 → one; 2–4 → few; decimals → many; 0, 5+ → other                            |
-| sk                                                     | `one, few, many, other`                                                               | same pattern as cs                                                            |
-| ru                                                     | `one, few, many, other`                                                               | 1, 21, 31… → one; 2–4, 22–24… → few; 0, 5–20, 25–30… → many; decimals → other |
-| ua                                                     | `one, few, many, other`                                                               | same pattern as ru                                                            |
-| ar (when added)                                        | `zero, one, two, few, many, other`                                                    | Six categories — the maximum any language uses                                |
+| Locale                                                            | Required keywords                                                                     | Example mapping                                                               |
+| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
+| en, es, de, nl, bg, ka-ge, tr-TR, vi-VN, id, ja, ko, zh-CN, zh-TW | `one, other` (single-form locales may use `other` alone, but **always emit `other`**) | 1 → one; 2+ → other                                                           |
+| fr                                                                | `one, many, other`                                                                    | 0, 1 → one; 1 000 000 → many; else other                                      |
+| it                                                                | `one, many, other`                                                                    | 1 → one; 1 000 000 → many; else other                                         |
+| pt-BR                                                             | `one, many, other`                                                                    | 0, 1 → one; 1 000 000 → many; else other                                      |
+| ro                                                                | `one, few, other`                                                                     | 1 → one; 0, 2–19 → few; 20+ → other                                           |
+| pl                                                                | `one, few, many, other`                                                               | 1 → one; 2–4 (not 12–14) → few; 0, 5–20, many-digit → many; decimals → other  |
+| cs                                                                | `one, few, many, other`                                                               | 1 → one; 2–4 → few; decimals → many; 0, 5+ → other                            |
+| sk                                                                | `one, few, many, other`                                                               | same pattern as cs                                                            |
+| ru                                                                | `one, few, many, other`                                                               | 1, 21, 31… → one; 2–4, 22–24… → few; 0, 5–20, 25–30… → many; decimals → other |
+| ua                                                                | `one, few, many, other`                                                               | same pattern as ru                                                            |
+| ar (when added)                                                   | `zero, one, two, few, many, other`                                                    | Six categories — the maximum any language uses                                |
 
 > **Note on the consolidated row.** CLDR itself only requires `other` for `tr-TR`, `vi-VN`, `id`, `ja`, `ko`, `zh-CN`, `zh-TW` (single-form locales). Emitting both `one` and `other` with identical content is a **project convention** — it keeps tooling and linters consistent across the codebase. It is not a CLDR requirement, and `Intl.PluralRules` will return only `"other"` for these locales at runtime.
 
@@ -469,7 +469,7 @@ When reviewing a translation — yours or an AI's — score against these catego
 A "namespace" is a top-level JSON file (e.g. `common.json`, `auth.json`, `epic.json`). The set of valid namespace names is a hard-coded const array — adding a JSON file alone is not enough; the runtime will not load it.
 
 1. Add the new namespace name to the `NAMESPACES` array in `packages/i18n/src/constants/namespaces.ts`. Keep alphabetical order with the existing entries.
-2. Create `<namespace>.json` in **every** locale directory under `packages/i18n/src/locales/` — start with `en/<namespace>.json` (the source of truth), then create the file in all 18 target locales. An empty `{}` is fine for the targets at this step; `sync-check` will report missing keys as you add them in step 4.
+2. Create `<namespace>.json` in **every** locale directory under `packages/i18n/src/locales/` — start with `en/<namespace>.json` (the source of truth), then create the file in every target locale (21 today; `ls packages/i18n/src/locales`). An empty `{}` is fine for the targets at this step; `sync-check` will report missing keys as you add them in step 4.
 3. Add at least one key in `en/<namespace>.json` so the namespace has content.
 4. Translate every key from `en/<namespace>.json` into each target locale — apply every rule in this skill.
 5. Run `pnpm --filter @plane/i18n run generate:types` to regenerate the `TTranslationKeys` union so component-level `t()` calls type-check.
diff --git a/.github/ISSUE_TEMPLATE/config.yaml b/.github/ISSUE_TEMPLATE/config.yaml
index 301080b75900..cf159ef8bd81 100644
--- a/.github/ISSUE_TEMPLATE/config.yaml
+++ b/.github/ISSUE_TEMPLATE/config.yaml
@@ -1,6 +1,7 @@
 contact_links:
   - name: Help and support
-    about: Reach out to us on our Forum or GitHub discussions.
+    url: https://forum.plane.so
+    about: Ask questions and get help from the community on our Forum.
   - name: Dedicated support
     url: mailto:support@plane.so
     about: Write to us if you'd like dedicated support using Plane
diff --git a/.github/instructions/bash.instructions.md b/.github/instructions/bash.instructions.md
index b14d3c9eda62..892d25e348c1 100644
--- a/.github/instructions/bash.instructions.md
+++ b/.github/instructions/bash.instructions.md
@@ -10,23 +10,32 @@ This document outlines the standard tools and commands used in this monorepo.
 ## Package Manager
 
 We use **pnpm** for package management.
+
 - **Do not use `npm` or `yarn`.**
 - Lockfile: `pnpm-lock.yaml`
 - Workspace configuration: `pnpm-workspace.yaml`
 
 ### Common Commands
+
 - Install dependencies: `pnpm install`
 - Run a script in a specific package: `pnpm --filter <package_name> run <script>`
-- Run a script in all packages: `pnpm -r run <script>`
+- Run a task across the monorepo through Turbo with the root scripts: `pnpm build`, `pnpm dev`, `pnpm check`, `pnpm fix` (or `pnpm turbo run <task> --filter=<package>`), rather than `pnpm -r run <script>`
+
+### Lint & format
+
+- Lint with OxLint: `pnpm check:lint` / `pnpm fix:lint` (config: `.oxlintrc.json`)
+- Format with oxfmt: `pnpm check:format` / `pnpm fix:format` (config: `.oxfmtrc.json`)
+- `pnpm check` runs format, lint and types; lint-staged runs oxfmt and OxLint on staged files at commit time
 
 ## Monorepo Tooling
 
 We use **Turbo** for build system orchestration.
+
 - Configuration: `turbo.json`
 
 ## Project Structure
 
-- `apps/`: Contains application services (admin, api, live, proxy, space, web).
+- `apps/`: Contains application services (admin, api, live, proxy, space, web). `apps/api` (Django, managed with uv) and `apps/proxy` (Caddy) are excluded from the pnpm workspace.
 - `packages/`: Contains shared packages and libraries.
 - `deployments/`: Deployment configurations.
 
@@ -45,4 +54,6 @@ We use **Turbo** for build system orchestration.
 ## Docker
 
 - Local development uses `docker-compose-local.yml`.
-- Production/Staging uses `docker-compose.yml`.
+- `docker-compose.yml` builds every service from the local Dockerfiles (for testing a full build).
+- Self-hosting configs for releases live in `deployments/` (`cli`, `aio`, `swarm`, `kubernetes`).
+- Backend tests run in `docker-compose-test.yml` (see `apps/api/tests/RUNNING_TESTS.md`).
diff --git a/.github/instructions/typescript.instructions.md b/.github/instructions/typescript.instructions.md
index 4af2f9fdd2f4..77ffe1946fff 100644
--- a/.github/instructions/typescript.instructions.md
+++ b/.github/instructions/typescript.instructions.md
@@ -9,8 +9,8 @@ When writing TypeScript code, prioritize using modern features and best practice
 
 ## Global Themes Across 5.x
 
-1. **Standard decorators are here; legacy decorators are legacy.**
-   New TC39-compliant decorators landed in 5.0 and were extended in 5.2 (metadata). Old `experimentalDecorators`-style behavior is still supported but should be treated as legacy.
+1. **This repo uses legacy decorators.**
+   `@plane/decorators`, `@plane/logger` and `apps/live` enable `experimentalDecorators` (with `emitDecoratorMetadata` and `reflect-metadata`), and the controllers read their routes through `reflect-metadata`. Keep using that style there; do not mix in TC39 standard decorators, which also do not support parameter decorators.
 
 2. **Type system is more precise and less noisy.**
    Major work went into narrowing, control flow analysis, error messages, and new helpers like `NoInfer`, inferred predicates, and better `undefined`/`never`/uninitialized checks.
@@ -19,18 +19,19 @@ When writing TypeScript code, prioritize using modern features and best practice
    Options like `--moduleResolution bundler`, `--module nodenext`/`node18`, `--rewriteRelativeImportExtensions`, `--erasableSyntaxOnly`, and `--verbatimModuleSyntax` are about playing nicely with ESM, Node 18+/22+, direct TypeScript execution, and bundlers.
 
 4. **The standard library keeps tracking modern JS.**
-   Support for new ES features (iterator helpers, `Object.groupBy`/`Map.groupBy`, new Set/ES2024 APIs) shows up as type declarations and sometimes extra checks (regex syntax checking, etc.).
+   Support for new ES features (iterator helpers, `Object.groupBy`/`Map.groupBy`, new Set/ES2024 APIs) shows up as type declarations and sometimes extra checks (regex syntax checking, etc.). Whether you can use them depends on the package's `lib`: the shared presets in `packages/typescript-config` use `es2023` (`base.json`, `node-library.json`, `react-library.json`) and `ES2022` (`react-router.json`, used by the apps).
 
 When generating or refactoring code, prefer these newer idioms, and avoid patterns that conflict with updated checks.
 
 ## Modern Features to Utilize
 
 ### Type System & Inference
+
 - **`const` Type Parameters (5.0)**: Use `const` type parameters for more precise literal inference.
   ```typescript
   declare function names<const T extends string[]>(...names: T): void;
   ```
-- **`@satisfies` Operator (5.0)**: Use `satisfies` to validate types without widening them.
+- **`satisfies` Operator (4.9; JSDoc `@satisfies` in 5.0)**: Use `satisfies` to validate types without widening them.
 - **Inferred Type Predicates (5.5)**: Allow TypeScript to infer type predicates for functions that filter arrays or check types, reducing the need for explicit `is` return types.
 - **`NoInfer` Utility (5.4)**: Use `NoInfer<T>` to block inference for specific type arguments when you want them to be determined by other arguments.
 - **Narrowing**:
@@ -40,7 +41,8 @@ When generating or refactoring code, prefer these newer idioms, and avoid patter
   - **Constant Indexed Access (5.5)**: Use constant indices to narrow object/array properties.
 
 ### Syntax & Control Flow
-- **Decorators (5.0)**: Use standard ECMAScript decorators (Stage 3).
+
+- **Decorators**: Follow the existing `experimentalDecorators` style (see Global Themes); do not introduce standard decorators.
 - **`using` Declarations (5.2)**: Use `using` for explicit resource management (Disposable pattern) instead of manual cleanup.
   ```typescript
   using resource = new Resource();
@@ -49,35 +51,44 @@ When generating or refactoring code, prefer these newer idioms, and avoid patter
 - **`switch` Exhaustiveness**: Rely on TypeScript's exhaustiveness checking in switch statements.
 
 ### Modules & Imports
+
 - **`verbatimModuleSyntax` (5.0)**: Respect this flag by using `import type` explicitly when importing types to ensure they are erased during compilation.
 - **Type-Only Imports with Extensions (5.2)**: You can use `.ts`, `.mts`, `.cts` extensions in `import type` statements.
 - **`resolution-mode` (5.3)**: Use `import type { Type } from "mod" with { "resolution-mode": "import" }` if needed for specific module resolution contexts.
 - **JSDoc `@import` (5.5)**: Use `@import` tags in JSDoc for cleaner type imports in JS files if working in a mixed codebase.
 
 ### Standard Library & Built-ins
+
+Only use these when the package's `lib` includes ES2024/ESNext; with the current `es2023`/`ES2022` presets they do not type-check.
+
 - **Iterator Helpers (5.6)**: Use new iterator methods (map, filter, etc.) if targeting modern environments.
 - **Set Methods (5.5)**: Utilize new `Set` methods like `union`, `intersection`, etc., when available.
 - **`Object.groupBy` / `Map.groupBy` (5.4)**: Use these standard methods for grouping instead of external libraries like Lodash when appropriate.
 - **`Promise.withResolvers` (5.7)**: Use `Promise.withResolvers()` for creating promises with exposed resolve/reject functions.
 
 ### Configuration & Tooling
-- **`--moduleResolution bundler` (5.0)**: Assume this resolution strategy for modern web projects (Vite, Next.js, etc.).
+
+- **`--moduleResolution bundler` (5.0)**: Assume this resolution strategy for modern web projects (Vite, React Router, etc.). The apps use React Router framework mode on Vite; none uses Next.js.
 - **`--erasableSyntaxOnly` (5.8)**: Be aware of this flag; avoid TypeScript-specific syntax that cannot be simply erased (like `enum`s or `namespaces`) if the project aims for maximum compatibility with tools like Node.js's `--strip-types`. Prefer `const` objects or unions over `enum`s if requested.
 
 ## Specific Coding Patterns
 
 ### Arrays & Collections
+
 - Use **Copying Array Methods (5.2)** (`toSorted`, `toSpliced`, `with`) for immutable array operations.
 - **TypedArrays (5.7)**: Be aware that TypedArrays are now generic over `ArrayBufferLike`.
 
 ### Classes
-- **Parameter Decorators (5.0/5.2)**: Use modern standard decorators.
+
+- **Decorators**: Use the legacy `experimentalDecorators` style already used by `@plane/decorators`.
 - **`super` Property Access (5.3)**: Avoid accessing instance fields via `super`.
 
 ### Error Handling
+
 - **Checks for Never-Initialized Variables (5.7)**: Ensure variables are initialized before use to avoid new errors.
 
 ## Deprecations to Avoid
+
 - Avoid `import ... assert` (use `with`).
 - Avoid implicit `any` returns in `undefined`-returning functions (though 5.1 makes this easier, explicit is better).
 - Avoid `enum`s if the project prefers erasable syntax (5.8).
@@ -85,43 +96,52 @@ When generating or refactoring code, prefer these newer idioms, and avoid patter
 ## Version-Specific Highlights
 
 ### TypeScript 5.0
-- **Decorators**: Use standard decorators unless `experimentalDecorators` is explicitly enabled.
+
+- **Decorators**: Standard decorators are available, but this repo enables `experimentalDecorators` where decorators are used; follow that.
 - **`const` Type Parameters**: Use for literal inference.
 - **Enums**: All enums are union enums.
 - **Modules**: `--moduleResolution bundler` and `--verbatimModuleSyntax` are key for modern bundlers.
 
 ### TypeScript 5.1
+
 - **Returns**: `undefined`-returning functions don't need explicit returns.
 - **Getters/Setters**: Can have unrelated types with explicit annotations.
 
 ### TypeScript 5.2
+
 - **Resource Management**: `using` declarations for `Symbol.dispose`.
 - **Decorator Metadata**: Use `context.metadata` for design-time metadata.
 
 ### TypeScript 5.3
+
 - **Import Attributes**: Use `with { type: "json" }`.
 - **Switch(true)**: Narrowing works in `switch(true)`.
 
 ### TypeScript 5.4
+
 - **Closures**: Narrowing preserved in closures if last assignment is before creation.
 - **`NoInfer`**: Block inference for specific arguments.
 - **Grouping**: `Object.groupBy` / `Map.groupBy`.
 
 ### TypeScript 5.5
+
 - **Inferred Predicates**: Functions checking types often don't need explicit `is` return types.
 - **Constant Index Access**: Better narrowing for constant keys.
 - **Regex**: Syntax checking for regex literals.
 
 ### TypeScript 5.6
+
 - **Truthiness Checks**: Errors on always-truthy/falsy conditions (e.g., `if (/regex/)`).
 - **Iterator Helpers**: `.map`, `.filter` on iterators.
 
 ### TypeScript 5.7
+
 - **Uninitialized Variables**: Stricter checks for never-initialized variables.
 - **Relative Imports**: `--rewriteRelativeImportExtensions` for `.ts` imports in output.
 - **ES2024**: Support for `Promise.withResolvers`, `Atomics.waitAsync`.
 
 ### TypeScript 5.8
+
 - **Return Checks**: Granular checks for conditional returns.
 - **Node Modules**: `--module node18` stable; `require()` of ESM allowed in `nodenext`.
 - **Erasable Syntax**: `--erasableSyntaxOnly` forbids enums, namespaces, etc.
diff --git a/AGENTS.md b/AGENTS.md
index c2e687044525..bdd3adeea447 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -2,7 +2,7 @@
 
 ## Commands
 
-- `pnpm dev` - Start all dev servers (web:3000, admin:3001)
+- `pnpm dev` - Start all dev servers (web:3000, admin:3001, space:3002, live:3100); the API runs in Docker via `docker-compose-local.yml` on :8000
 - `pnpm build` - Build all packages and apps
 - `pnpm check` - Run all checks (format, lint, types)
 - `pnpm check:lint` - OxLint across all packages
@@ -18,7 +18,7 @@
 - **Linting**: OxLint with shared `.oxlintrc.json` config
 - **Naming**: camelCase for variables/functions, PascalCase for components/types
 - **Error Handling**: Use try-catch with proper error types, log errors appropriately
-- **State Management**: MobX stores in `packages/shared-state`, reactive patterns
+- **State Management**: MobX stores live in each app's `store/` folder (`apps/web/store`, `apps/space/store`, `apps/admin/store`); stores shared across apps go in `packages/shared-state`
 - **Testing**: All features require unit tests, use existing test framework per package
 - **Components**: Primitives come from the published `@makeplane/propel` npm package (`@makeplane/propel/components/*`, `elements/*`, `icons`); composite/Plane-specific components live in `@plane/blocks` (`packages/blocks`, subpath imports only, e.g. `@plane/blocks/toast`)
 
@@ -48,4 +48,12 @@ Prereq (once): `./setup.sh` — generates `apps/api/.env` from `.env.example`.
 - Subset: `docker compose -f docker-compose-test.yml run --rm --build api-tests pytest -m unit`
 - Teardown: `docker compose -f docker-compose-test.yml down -v`
 
-See `apps/api/tests/RUNNING_TESTS.md` for the full walkthrough and troubleshooting; see `apps/api/tests/TESTING_GUIDE.md` for test conventions and fixtures.
+See `apps/api/tests/RUNNING_TESTS.md` for the full walkthrough and troubleshooting; see `apps/api/plane/tests/TESTING_GUIDE.md` for test conventions and fixtures.
+
+## Translations
+
+Strings live in `packages/i18n/src/locales/<lang>/<namespace>.json`; `en` is the source of truth and every locale must have the same keys. Use the `translate` skill when changing locale files, and run `pnpm --filter=@plane/i18n sync:check` (CI runs it with `--ci`).
+
+## Pull requests
+
+Open PRs against `preview`. New `.py`, `.ts` and `.tsx` files need the `COPYRIGHT.txt` header (checked in CI, see `COPYRIGHT_CHECK.md`).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index deb7cef5e2d3..837d69fc6909 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -4,7 +4,7 @@ Thank you for showing an interest in contributing to Plane! All kinds of contrib
 
 ## Submitting an issue
 
-Before submitting a new issue, please search the [issues](https://github.com/makeplane/plane/issues) tab. Maybe an issue or discussion already exists and might inform you of workarounds. Otherwise, you can give new information.
+Before submitting a new issue, please search the [issues](https://github.com/makeplane/plane/issues) tab. Maybe an issue or a [Forum](https://forum.plane.so) thread already exists and might inform you of workarounds. Otherwise, you can give new information.
 
 While we want to fix all the [issues](https://github.com/makeplane/plane/issues), before fixing a bug we need to be able to reproduce and confirm it. Please provide us with a minimal reproduction scenario using a repository or [Gist](https://gist.github.com/). Having a live, reproducible scenario gives us the information without asking questions back & forth with additional questions like:
 
@@ -17,18 +17,15 @@ You can open a new issue with this [issue form](https://github.com/makeplane/pla
 
 ### Naming conventions for issues
 
-When opening a new issue, please use a clear and concise title that follows this format:
+The issue forms pre-fill a title prefix. Keep it and follow it with a clear, concise description:
 
-- For bugs: `🐛 Bug: [short description]`
-- For features: `🚀 Feature: [short description]`
-- For improvements: `🛠️ Improvement: [short description]`
-- For documentation: `📘 Docs: [short description]`
+- For bugs: `[bug]: [short description]`
+- For features and improvements: `[feature]: [short description]`
 
 **Examples:**
 
-- `🐛 Bug: API token expiry time not saving correctly`
-- `📘 Docs: Clarify RAM requirement for local setup`
-- `🚀 Feature: Allow custom time selection for token expiration`
+- `[bug]: API token expiry time not saving correctly`
+- `[feature]: Allow custom time selection for token expiration`
 
 This helps us triage and manage issues more efficiently.
 
@@ -36,11 +33,10 @@ This helps us triage and manage issues more efficiently.
 
 ### Requirements
 
-- Docker Engine installed and running
-- Node.js version 20+ [LTS version](https://nodejs.org/en/about/previous-releases)
-- Python version 3.12 and [uv](https://docs.astral.sh/uv/) (only needed to run the API outside Docker)
-- Postgres version v14
-- Redis version v6.2.7
+- Docker Engine installed and running. `docker-compose-local.yml` runs the API, its workers and the backing services: Postgres 15, Valkey 7.2 (Redis-compatible), RabbitMQ 3.13 and S3-compatible object storage
+- Node.js 22.22.0 or newer (pinned in `.node-version` and `.mise.toml`)
+- pnpm, activated through Corepack (`corepack enable pnpm`); the version is pinned in `package.json`
+- Python 3.12 and [uv](https://docs.astral.sh/uv/) (only needed to run the API outside Docker)
 - **Memory**: Minimum **12 GB RAM** recommended
   > ⚠️ Running the project on a system with only 8 GB RAM may lead to setup failures or memory crashes (especially during Docker container build/start or dependency install). Use cloud environments like GitHub Codespaces or upgrade local RAM if possible.
 
@@ -64,17 +60,17 @@ chmod +x setup.sh
 ./setup.sh
 ```
 
-`setup.sh` copies each service’s `.env.example` to `.env` (root, `apps/api`, `apps/web`, `apps/admin`, `apps/space`, `apps/live`) and generates a Django `SECRET_KEY` for the API. Review those files if you need custom values; the defaults work with the local Docker Compose stack.
+`setup.sh` copies each service’s `.env.example` to `.env` (root, `apps/api`, `apps/web`, `apps/admin`, `apps/space`, `apps/live`), generates a Django `SECRET_KEY` for the API and object-storage (MinIO) credentials shared by the root and API env files, then enables pnpm through Corepack and runs `pnpm install`. Review those files if you need custom values; the defaults work with the local Docker Compose stack.
 
 #### Environment variables
 
 If these are missing or wrong, the API and supporting services fail to connect on first run. Defaults come from `apps/api/.env.example` and `apps/live/.env.example` (copied by `setup.sh`):
 
-| Variable | Where | Purpose | Local Docker default |
-| -------- | ----- | ------- | -------------------- |
-| `DATABASE_URL` | `apps/api/.env` | Postgres connection for the Django API | `postgresql://plane:plane@plane-db:5432/plane` |
-| `REDIS_URL` | `apps/api/.env`, `apps/live/.env` | Redis/Valkey for cache, sessions, and realtime | API: `redis://plane-redis:6379/` · Live: `redis://localhost:6379/` |
-| `PORT` | `apps/live/.env` | Port the live (collab) server listens on | `3100` |
+| Variable       | Where                             | Purpose                                        | Local Docker default                                               |
+| -------------- | --------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------ |
+| `DATABASE_URL` | `apps/api/.env`                   | Postgres connection for the Django API         | `postgresql://plane:plane@plane-db:5432/plane`                     |
+| `REDIS_URL`    | `apps/api/.env`, `apps/live/.env` | Redis/Valkey for cache, sessions, and realtime | API: `redis://plane-redis:6379/` · Live: `redis://localhost:6379/` |
+| `PORT`         | `apps/live/.env`                  | Port the live (collab) server listens on       | `3100`                                                             |
 
 Related values used to build those URLs (also in `apps/api/.env.example`): `POSTGRES_USER`, `POSTGRES_PASSWORD`, `POSTGRES_HOST`, `POSTGRES_PORT`, `POSTGRES_DB`, `REDIS_HOST`, `REDIS_PORT`.
 
@@ -105,7 +101,7 @@ That’s it! You’re all set to begin coding. Remember to refresh your browser
 
 ## Missing a Feature?
 
-If a feature is missing, you can directly _request_ a new one [here](https://github.com/makeplane/plane/issues/new?assignees=&labels=feature&template=feature_request.yml&title=%F0%9F%9A%80+Feature%3A+). You also can do the same by choosing "🚀 Feature" when raising a [New Issue](https://github.com/makeplane/plane/issues/new/choose) on our GitHub Repository.
+If a feature is missing, you can directly _request_ a new one [here](https://github.com/makeplane/plane/issues/new?template=--feature-request.yaml). You also can do the same by choosing "Feature request" when raising a [New Issue](https://github.com/makeplane/plane/issues/new/choose) on our GitHub Repository.
 If you would like to _implement_ it, an issue with your proposal must be submitted first, to be sure that we can use it. Please consider the guidelines given below.
 
 ## Coding guidelines
@@ -113,7 +109,16 @@ If you would like to _implement_ it, an issue with your proposal must be submitt
 To ensure consistency throughout the source code, please keep these rules in mind as you are working:
 
 - All features or bug fixes must be tested by one or more specs (unit-tests).
-- We lint with [OxLint](https://oxc.rs/docs/guide/usage/linter) using the shared `.oxlintrc.json` and format with [oxfmt](https://oxc.rs/docs/guide/usage/formatter) using `.oxfmtrc.json`.
+- We lint with [OxLint](https://oxc.rs/docs/guide/usage/linter) using the shared `.oxlintrc.json` and format with [oxfmt](https://oxc.rs/docs/guide/usage/formatter) using `.oxfmtrc.json` (see [docs/linting.md](./docs/linting.md)). The backend in `apps/api` is linted with [Ruff](https://docs.astral.sh/ruff/) using `apps/api/ruff.toml`.
+- See [AGENTS.md](./AGENTS.md) for the full command reference, code style, backend dependency (uv), migration and backend test workflows.
+
+## Submitting a pull request
+
+1. Branch off `preview` and open your pull request against `preview`.
+2. Before pushing, run `pnpm check` (format, lint and types). For backend changes, also run `uv run ruff check .` in `apps/api` and the backend tests (`docker compose -f docker-compose-test.yml up --build --abort-on-container-exit --exit-code-from api-tests`, see [apps/api/tests/RUNNING_TESTS.md](./apps/api/tests/RUNNING_TESTS.md)).
+3. If you add a Django migration, generate it with `makemigrations` and commit the updated `apps/api/migrations_lockfile.txt` with it (see [AGENTS.md](./AGENTS.md#migrations)).
+4. New source files need the copyright header from `COPYRIGHT.txt` (see [COPYRIGHT_CHECK.md](./COPYRIGHT_CHECK.md)).
+5. Fill in the pull request template: description, type of change, screenshots for UI changes, and the test scenarios you ran.
 
 ## Ways to contribute
 
@@ -135,19 +140,23 @@ This guide is designed to help contributors understand how to add or update tran
 
 #### File organization
 
-Translations are organized by language in the locales directory. Each language has its own folder containing JSON files for translations. Here's how it looks:
+Translations are organized by language in the locales directory. Each language has its own folder with one JSON file per namespace (the namespaces are listed in `packages/i18n/src/constants/namespaces.ts`). English (`en/`) is the source of truth: every other language mirrors it file for file and key for key. Here's how it looks:
 
 ```
 packages/i18n/src/locales/
     ├── en/
-    │   ├── core.json       # Critical translations
-    │   └── translations.json
+    │   ├── common.json
+    │   ├── work-item.json
+    │   └── ...             # one file per namespace
     ├── fr/
-    │   └── translations.json
+    │   ├── common.json
+    │   └── ...
     └── [language]/
-        └── translations.json
+        └── ...
 ```
 
+A key must be unique across all namespace files of a language.
+
 #### Nested structure
 
 To keep translations organized, we use a nested structure for keys. This makes it easier to manage and locate specific translations. For example:
@@ -165,7 +174,7 @@ To keep translations organized, we use a nested structure for keys. This makes i
 
 ### Translation formatting guide
 
-We use [IntlMessageFormat](https://formatjs.github.io/docs/intl-messageformat/) to handle dynamic content, such as variables and pluralization. Here's how to format your translations:
+We use [i18next](https://www.i18next.com/) with ICU message format ([i18next-icu](https://github.com/i18next/i18next-icu)) to handle dynamic content, such as variables and pluralization. Here's how to format your translations:
 
 #### Examples
 
@@ -188,19 +197,27 @@ We use [IntlMessageFormat](https://formatjs.github.io/docs/intl-messageformat/)
 
 #### Updating existing translations
 
-1. Locate the key in `locales/<language>/translations.json`.
+1. Locate the key in `locales/<language>/<namespace>.json`.
 
 2. Update the value while ensuring the key structure remains intact.
 3. Preserve any existing ICU formats (e.g., variables, pluralization).
 
 #### Adding new translation keys
 
-1. When introducing a new key, ensure it is added to **all** language files, even if translations are not immediately available. Use English as a placeholder if needed.
+1. Add the key to the right namespace file in `locales/en/` first, then to the same file in **all** other languages, even if translations are not immediately available. Use English as a placeholder if needed.
 
 2. Keep the nesting structure consistent across all languages.
 
 3. If the new key requires dynamic content (e.g., variables or pluralization), ensure the ICU format is applied uniformly across all languages.
 
+4. Run the sync check. It reports keys missing from a language, keys duplicated across namespaces, and keys that are both a value and a parent of other keys. CI runs it in `--ci` mode on every pull request that touches `packages/i18n`.
+
+```bash
+pnpm --filter=@plane/i18n sync:check
+```
+
+The TypeScript key types (`packages/i18n/src/types/keys.generated.ts`) are generated from the English files during build and type check. The file is git-ignored; do not edit it by hand.
+
 ### Adding new languages
 
 Adding a new language involves several steps to ensure it integrates seamlessly with the project. Follow these instructions carefully:
@@ -213,7 +230,7 @@ Adding a new language involves several steps to ensure it integrates seamlessly
 export type TLanguage = "en" | "fr" | "your-lang";
 ```
 
-1.  **Add language configuration**
+2.  **Add language configuration**
     Include the new language in the list of supported languages:
 
 ```ts
@@ -224,25 +241,14 @@ export const SUPPORTED_LANGUAGES: ILanguageOption[] = [
 ];
 ```
 
-2.  **Create translation files**
-    1. Create a new folder for your language under locales (e.g., `locales/your-lang/`).
-
-    2. Add a `translations.json` file inside the folder.
+3.  **Create translation files**
+    1. Copy `locales/en/` to a new folder for your language (e.g., `locales/your-lang/`), keeping every namespace file.
 
-    3. Copy the structure from an existing translation file and translate all keys.
+    2. Translate all keys in every file.
 
-3.  **Update import logic**
-    Modify the language import logic to include your new language:
+    3. Run `pnpm --filter=@plane/i18n sync:check` and fix anything it reports.
 
-```ts
-      private importLanguageFile(language: TLanguage): Promise<any> {
-      switch (language) {
-          case "your-lang":
-          return import("../locales/your-lang/translations.json");
-          // ...
-      }
-      }
-```
+No loader change is needed: namespace files are imported dynamically by language code (`packages/i18n/src/core/instance.ts`).
 
 ### Quality checklist
 
diff --git a/COPYRIGHT_CHECK.md b/COPYRIGHT_CHECK.md
index a72b11a2404c..9522fdba4b61 100644
--- a/COPYRIGHT_CHECK.md
+++ b/COPYRIGHT_CHECK.md
@@ -1,9 +1,15 @@
 ## Copyright check
 
-To verify that all tracked Python files contain the correct copyright header for **Plane Software Inc.** for the year **2023**, run this command from the repository root:
+Every tracked Python, TypeScript and TSX file must start with the header in [`COPYRIGHT.txt`](./COPYRIGHT.txt) (`Copyright (c) 2023-present Plane Software, Inc. and contributors`, `SPDX-License-Identifier: AGPL-3.0-only`). The `copyright-check.yml` workflow enforces this on every pull request to `preview`, using [addlicense](https://github.com/google/addlicense) (`go install github.com/google/addlicense@latest`).
+
+Run the same checks as CI from the repository root:
 
 ```bash
-addlicense --check -f COPYRIGHT.txt -ignore "**/migrations/**" $(git ls-files '*.py')
+# Python (migrations are skipped)
+addlicense -check -f COPYRIGHT.txt -ignore "**/migrations/**" $(git ls-files '*.py')
+
+# TypeScript (config and declaration files are skipped)
+addlicense -check -f COPYRIGHT.txt -ignore "**/*.config.ts" -ignore "**/*.d.ts" $(git ls-files '*.ts' '*.tsx')
 ```
 
 #### To Apply Changes
@@ -14,21 +20,20 @@ python files
 addlicense -v -f COPYRIGHT.txt -ignore "**/migrations/**" $(git ls-files '*.py')
 ```
 
-ts and tsx files in a specific app
+ts and tsx files in a specific app or package
 
 ```bash
 addlicense -v -f COPYRIGHT.txt \
   -ignore "**/*.config.ts" \
   -ignore "**/*.d.ts" \
-  $(git ls-files 'packages/*.ts')
+  $(git ls-files 'packages/*.ts' 'packages/*.tsx')
 ```
 
-Note: Please make sure ts command is running on specific folder, running it for the whole mono repo is crashing os processes.
+Note: run the ts command on one folder at a time (for example `'apps/web/*.ts' 'apps/web/*.tsx'`); running it for the whole monorepo crashes OS processes.
 
 #### Other Options
 
-- **`addlicense -check`**: runs in check-only mode and fails if any file is missing or has an incorrect header.
-- **`-c "Plane Software Inc."`**: sets the copyright holder.
-- **`-f LICENSE.txt`**: uses the contents and format defined in `LICENSE.txt` as the header template.
-- **`-y 2023`**: sets the year in the header.
-- **`$(git ls-files '*.py')`**: restricts the check to Python files tracked in git.
+- **`-check`**: runs in check-only mode and fails if any file is missing or has an incorrect header.
+- **`-f COPYRIGHT.txt`**: uses the contents of `COPYRIGHT.txt` as the header template.
+- **`-ignore <glob>`**: skips matching files.
+- **`$(git ls-files '*.py')`**: restricts the run to files tracked in git.
diff --git a/README.md b/README.md
index 74688cd92c4b..cbfc816629b8 100644
--- a/README.md
+++ b/README.md
@@ -42,6 +42,7 @@ Getting started with Plane is simple. Choose the setup that works best for you:
 | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | Docker               | [![Docker](https://img.shields.io/badge/docker-%230db7ed.svg?style=for-the-badge&logo=docker&logoColor=white)](https://developers.plane.so/self-hosting/methods/docker-compose)         |
 | Kubernetes           | [![Kubernetes](https://img.shields.io/badge/kubernetes-%23326ce5.svg?style=for-the-badge&logo=kubernetes&logoColor=white)](https://developers.plane.so/self-hosting/methods/kubernetes) |
+| All-in-one Docker    | [deployments/aio/community](./deployments/aio/community/README.md) · [docs](https://developers.plane.so/self-hosting/methods/docker-aio)                                                |
 
 `Instance admins` can configure instance settings with [God mode](https://developers.plane.so/self-hosting/govern/instance-admin).
 
@@ -129,26 +130,27 @@ Explore Plane's [product documentation](https://docs.plane.so/) and [developer d
 
 ## ❤️ Community
 
-Join the Plane community on [GitHub Discussions](https://github.com/orgs/makeplane/discussions) and our [Forum](https://forum.plane.so). We follow a [Code of conduct](https://github.com/makeplane/plane/blob/master/CODE_OF_CONDUCT.md) in all our community channels.
+Join the Plane community on our [Forum](https://forum.plane.so), and use [GitHub issues](https://github.com/makeplane/plane/issues) for bug reports and feature requests. We follow a [Code of conduct](./CODE_OF_CONDUCT.md) in all our community channels.
 
 Feel free to ask questions, report bugs, participate in discussions, share ideas, request features, or showcase your projects. We’d love to hear from you!
 
 ## 🛡️ Security
 
-If you discover a security vulnerability in Plane, please report it responsibly instead of opening a public issue. We take all legitimate reports seriously and will investigate them promptly. See [Security policy](https://github.com/makeplane/plane/blob/master/SECURITY.md) for more info.
+If you discover a security vulnerability in Plane, please report it responsibly instead of opening a public issue. We take all legitimate reports seriously and will investigate them promptly. See [Security policy](./SECURITY.md) for more info.
 
-To disclose any security issues, please email us at security@plane.so.
+To disclose any security issues, please [report them privately on GitHub](https://github.com/makeplane/plane/security/advisories/new) or email us at security@plane.so.
 
 ## 🤝 Contributing
 
 There are many ways you can contribute to Plane:
 
-- Report [bugs](https://github.com/makeplane/plane/issues/new?assignees=srinivaspendem%2Cpushya22&labels=%F0%9F%90%9Bbug&projects=&template=--bug-report.yaml&title=%5Bbug%5D%3A+) or submit [feature requests](https://github.com/makeplane/plane/issues/new?assignees=srinivaspendem%2Cpushya22&labels=%E2%9C%A8feature&projects=&template=--feature-request.yaml&title=%5Bfeature%5D%3A+).
-- Review the [documentation](https://docs.plane.so/) and submit [pull requests](https://github.com/makeplane/docs) to improve it—whether it's fixing typos or adding new content.
+- Report [bugs](https://github.com/makeplane/plane/issues/new?template=--bug-report.yaml) or submit [feature requests](https://github.com/makeplane/plane/issues/new?template=--feature-request.yaml).
+- Review the [documentation](https://docs.plane.so/) and tell us on the [Forum](https://forum.plane.so) or in a GitHub issue where it is wrong or incomplete.
+- Add or update [translations](./CONTRIBUTING.md#contributing-to-language-support).
 - Talk or write about Plane or any other ecosystem integration and [let us know](https://forum.plane.so)!
 - Show your support by upvoting [popular feature requests](https://github.com/makeplane/plane/issues).
 
-Please read [CONTRIBUTING.md](https://github.com/makeplane/plane/blob/master/CONTRIBUTING.md) for details on the process for submitting pull requests to us.
+Please read [CONTRIBUTING.md](./CONTRIBUTING.md) for details on the process for submitting pull requests to us.
 
 ### Repo activity
 
@@ -162,4 +164,4 @@ Please read [CONTRIBUTING.md](https://github.com/makeplane/plane/blob/master/CON
 
 ## License
 
-This project is licensed under the [GNU Affero General Public License v3.0](https://github.com/makeplane/plane/blob/master/LICENSE.txt).
+This project is licensed under the [GNU Affero General Public License v3.0](./LICENSE.txt).
diff --git a/SECURITY.md b/SECURITY.md
index 0e11bbb5570a..25c01e4bb2ac 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -1,8 +1,10 @@
 # Security policy
+
 This document outlines the security protocols and vulnerability reporting guidelines for the Plane project. Ensuring the security of our systems is a top priority, and while we work diligently to maintain robust protection, vulnerabilities may still occur. We highly value the community’s role in identifying and reporting security concerns to uphold the integrity of our systems and safeguard our users.
 
 ## Reporting a vulnerability
-If you have identified a security vulnerability, submit your findings to [security@plane.so](mailto:security@plane.so). 
+
+If you have identified a security vulnerability, report it privately through [GitHub's private vulnerability reporting](https://github.com/makeplane/plane/security/advisories/new) or submit your findings to [security@plane.so](mailto:security@plane.so). Do not open a public issue or pull request for it.
 Ensure your report includes all relevant information needed for us to reproduce and assess the issue. Include the IP address or URL of the affected system.
 
 To ensure a responsible and effective disclosure process, please adhere to the following:
@@ -13,6 +15,7 @@ To ensure a responsible and effective disclosure process, please adhere to the f
 - Do not engage in physical security attacks, social engineering, distributed denial of service (DDoS) attacks, spam campaigns, or attacks on third-party applications as part of your vulnerability testing.
 
 ## Out of scope
+
 While we appreciate all efforts to assist in improving our security, please note that the following types of vulnerabilities are considered out of scope:
 
 - Vulnerabilities requiring man-in-the-middle (MITM) attacks or physical access to a user’s device.
@@ -26,14 +29,14 @@ While we appreciate all efforts to assist in improving our security, please note
 At Plane, we are committed to maintaining transparent and collaborative communication throughout the vulnerability resolution process. Here's what you can expect from us:
 
 - **Response Time** <br/>
-We will acknowledge receipt of your vulnerability report within three business days and provide an estimated timeline for resolution.
+  We will acknowledge receipt of your vulnerability report within three business days and provide an estimated timeline for resolution.
 - **Legal Protection** <br/>
-We will not initiate legal action against you for reporting vulnerabilities, provided you adhere to the reporting guidelines.
+  We will not initiate legal action against you for reporting vulnerabilities, provided you adhere to the reporting guidelines.
 - **Confidentiality** <br/>
-Your report will be treated with confidentiality. We will not disclose your personal information to third parties without your consent.
+  Your report will be treated with confidentiality. We will not disclose your personal information to third parties without your consent.
 - **Recognition** <br/>
-With your permission, we are happy to publicly acknowledge your contribution to improving our security once the issue is resolved.
+  With your permission, we are happy to publicly acknowledge your contribution to improving our security once the issue is resolved.
 - **Timely Resolution** <br/>
-We are committed to working closely with you throughout the resolution process, providing timely updates as necessary. Our goal is to address all reported vulnerabilities swiftly, and we will actively engage with you to coordinate a responsible disclosure once the issue is fully resolved.
+  We are committed to working closely with you throughout the resolution process, providing timely updates as necessary. Our goal is to address all reported vulnerabilities swiftly, and we will actively engage with you to coordinate a responsible disclosure once the issue is fully resolved.
 
-We appreciate your help in ensuring the security of our platform. Your contributions are crucial to protecting our users and maintaining a secure environment. Thank you for working with us to keep Plane safe.
\ No newline at end of file
+We appreciate your help in ensuring the security of our platform. Your contributions are crucial to protecting our users and maintaining a secure environment. Thank you for working with us to keep Plane safe.
diff --git a/apps/api/docs/django-5.2-migration-plan.md b/apps/api/docs/django-5.2-migration-plan.md
index 0b2527d0efbf..0dbf75086c59 100644
--- a/apps/api/docs/django-5.2-migration-plan.md
+++ b/apps/api/docs/django-5.2-migration-plan.md
@@ -1,6 +1,8 @@
 # Django 4.2 → 5.2 Migration Plan (`apps/api`)
 
-> **Status:** ✅ Executed & verified on branch `chore/django-5.2-upgrade` · **Target:** Django **5.2.15 LTS** from **4.2.30 LTS**
+> **Status:** ✅ Done. Merged in #9325 (Django **5.2.15 LTS** from **4.2.30 LTS**); `pyproject.toml` now pins Django 5.2.17, DRF 3.18.3 and psycopg 3.3.4.
+>
+> **Historical record.** This plan predates the move to uv (#9950). References below to `requirements/*.txt`, `pip install` and "no lockfile" describe the old setup: dependencies now live in `apps/api/pyproject.toml` and `apps/api/uv.lock` (see `AGENTS.md`), and backend tests run with `docker-compose-test.yml` (see `apps/api/tests/RUNNING_TESTS.md`). Line numbers cited below may have moved.
 > **Scope:** `apps/api` (the only Django service in the monorepo) · **Strategy:** single coordinated PR, direct 4.2 → 5.2 jump · **Dependency policy:** opportunistic (latest stable, with evidence-based safe overrides)
 
 ---
diff --git a/apps/api/plane/tests/README.md b/apps/api/plane/tests/README.md
index 3d6936d78540..d2bd8b942017 100644
--- a/apps/api/plane/tests/README.md
+++ b/apps/api/plane/tests/README.md
@@ -6,7 +6,7 @@ This directory contains tests for the Plane application. The tests are organized
 
 Tests are organized into the following categories:
 
-- **Unit tests**: Test individual functions or classes in isolation.
+- **Unit tests** (`unit/`): Test individual functions or classes in isolation. Grouped by area: `bg_tasks`, `db`, `middleware`, `models`, `observability`, `serializers`, `settings`, `utils`, `views`.
 - **Contract tests**: Test interactions between components and verify API contracts are fulfilled.
   - **API tests**: Test the external API endpoints (under `/api/v1/`).
   - **App tests**: Test the web application API endpoints (under `/api/`).
@@ -25,49 +25,51 @@ Plane has two types of API endpoints:
 
 2. **Web App API** (`plane.app`):
    - Available at `/api/` endpoint
-   - Uses session-based authentication (CSRF disabled)
+   - Uses session-based authentication with CSRF checks (`plane/authentication/session.py`)
    - Designed for the web application frontend
-   - Tests use the `session_client` fixture for authentication
+   - Tests use the `session_client` fixture, which calls `force_authenticate` for the test user
    - Test files are in `contract/app/`
 
 ## Running Tests
 
+The easiest way is the isolated Docker stack; see [`apps/api/tests/RUNNING_TESTS.md`](../../tests/RUNNING_TESTS.md). The commands below run pytest directly and need a local env: from `apps/api`, run `uv sync`, then start Postgres, Redis, RabbitMQ and MinIO (for example with `docker-compose-local.yml`).
+
 To run all tests:
 
 ```bash
-python -m pytest
+uv run pytest
 ```
 
 To run specific test categories:
 
 ```bash
 # Run unit tests
-python -m pytest plane/tests/unit/
+uv run pytest plane/tests/unit/
 
 # Run API contract tests
-python -m pytest plane/tests/contract/api/
+uv run pytest plane/tests/contract/api/
 
 # Run App contract tests
-python -m pytest plane/tests/contract/app/
+uv run pytest plane/tests/contract/app/
 
 # Run smoke tests
-python -m pytest plane/tests/smoke/
+uv run pytest plane/tests/smoke/
 ```
 
-For convenience, we also provide a helper script:
+For convenience, we also provide a helper script (`apps/api/run_tests.py`):
 
 ```bash
 # Run all tests
-./run_tests.py
+uv run python run_tests.py
 
 # Run only unit tests
-./run_tests.py -u
+uv run python run_tests.py -u
 
 # Run contract tests with coverage report
-./run_tests.py -c -o
+uv run python run_tests.py -c -o
 
 # Run tests in parallel
-./run_tests.py -p
+uv run python run_tests.py -p
 ```
 
 ## Fixtures
@@ -90,9 +92,7 @@ When writing tests, follow these guidelines:
    - For external API (`/api/v1/`), use `api_key_client`
    - For web app API (`/api/`), use `session_client`
    - For smoke tests with real HTTP, use `plane_server`
-3. Use the correct URL namespace when reverse-resolving URLs:
-   - For external API, use `reverse("api:endpoint_name")`
-   - For web app API, use `reverse("endpoint_name")`
+3. Reverse-resolve URLs by their plain name, e.g. `reverse("sign-in")` or `reverse("api-tokens")`; the URL confs do not use namespaces.
 4. Add the `@pytest.mark.django_db` decorator to tests that interact with the database.
 5. Add the appropriate markers (`@pytest.mark.contract`, etc.) to categorize tests.
 
@@ -101,7 +101,7 @@ When writing tests, follow these guidelines:
 Common fixtures are defined in:
 
 - `conftest.py`: General fixtures for authentication, database access, etc.
-- `conftest_external.py`: Fixtures for external services (Redis, Elasticsearch, Celery)
+- `conftest_external.py`: `mock_redis` and `mock_celery` fixtures for external services. They are imported into `conftest.py`, which is what makes pytest pick them up; import any new fixture you add there the same way.
 - `factories.py`: Test factories for easy model instance creation
 
 ## Best Practices
@@ -114,9 +114,10 @@ When writing tests, follow these guidelines:
    @pytest.mark.unit
    @pytest.mark.contract
    @pytest.mark.smoke
+   @pytest.mark.slow  # slow tests that can be skipped with -m "not slow"
    ```
 3. **Use fixtures instead of setUp/tearDown methods** for cleaner, more reusable test code.
-4. **Mock external dependencies** with the provided fixtures to avoid external service dependencies.
+4. **Mock external dependencies** with the `mock_redis` / `mock_celery` fixtures, or pytest-mock's `mocker` fixture for anything else, to avoid external service dependencies.
 5. **Write focused tests** that verify one specific behavior or edge case.
 6. **Keep test files small and organized** by logical components or endpoints.
 7. **Target 90% code coverage** for models, serializers, and business logic.
@@ -125,19 +126,15 @@ When writing tests, follow these guidelines:
 
 Tests for components that interact with external services should:
 
-1. Use the `mock_redis`, `mock_elasticsearch`, and `mock_celery` fixtures for unit and most contract tests.
-2. For more comprehensive contract tests, use Docker-based test containers (optional).
+1. Use the `mock_redis` and `mock_celery` fixtures for unit and most contract tests, and `mocker.patch(...)` for other services.
+2. For more comprehensive tests, use the Docker test stack in [`RUNNING_TESTS.md`](../../tests/RUNNING_TESTS.md), which runs real Postgres, Redis, RabbitMQ and MinIO.
 
 ## Coverage Reports
 
 Generate a coverage report with:
 
 ```bash
-python -m pytest --cov=plane --cov-report=term --cov-report=html
+uv run pytest --cov=plane --cov-report=term --cov-report=html
 ```
 
 This creates an HTML report in the `htmlcov/` directory.
-
-## Migration from Old Tests
-
-Some tests are still in the old format in the `api/` directory. These need to be migrated to the new contract test structure in the appropriate directories.
diff --git a/apps/api/plane/tests/TESTING_GUIDE.md b/apps/api/plane/tests/TESTING_GUIDE.md
index 98f4a1dba7c8..f07009b0098c 100644
--- a/apps/api/plane/tests/TESTING_GUIDE.md
+++ b/apps/api/plane/tests/TESTING_GUIDE.md
@@ -12,11 +12,12 @@ We divide tests into three categories:
 
 ## Writing Unit Tests
 
-Unit tests should be placed in the appropriate directory under `tests/unit/` depending on what you're testing:
+Unit tests should be placed in the appropriate directory under `plane/tests/unit/` depending on what you're testing:
 
-- `tests/unit/models/` - For model tests
-- `tests/unit/serializers/` - For serializer tests
-- `tests/unit/utils/` - For utility function tests
+- `plane/tests/unit/models/` - For model tests
+- `plane/tests/unit/serializers/` - For serializer tests
+- `plane/tests/unit/utils/` - For utility function tests
+- `plane/tests/unit/views/`, `middleware/`, `bg_tasks/`, `db/`, `settings/`, `observability/` - For views, middleware, background tasks, database helpers, settings and observability
 
 ### Example Unit Test:
 
@@ -29,13 +30,13 @@ class TestMySerializer:
     def test_serializer_valid_data(self):
         # Create input data
         data = {"field1": "value1", "field2": 42}
-        
+
         # Initialize the serializer
         serializer = MySerializer(data=data)
-        
+
         # Validate
         assert serializer.is_valid()
-        
+
         # Check validated data
         assert serializer.validated_data["field1"] == "value1"
         assert serializer.validated_data["field2"] == 42
@@ -43,7 +44,7 @@ class TestMySerializer:
 
 ## Writing Contract Tests
 
-Contract tests should be placed in `tests/contract/api/` or `tests/contract/app/` directories and should test the API endpoints.
+Contract tests should be placed in `plane/tests/contract/api/` (external API, `api_key_client`) or `plane/tests/contract/app/` (web app API, `session_client`) directories and should test the API endpoints.
 
 ### Example Contract Test:
 
@@ -55,13 +56,13 @@ from rest_framework import status
 @pytest.mark.contract
 class TestMyEndpoint:
     @pytest.mark.django_db
-    def test_my_endpoint_get(self, auth_client):
+    def test_my_endpoint_get(self, session_client):
         # Get the URL
         url = reverse("my-endpoint")
-        
+
         # Make request
-        response = auth_client.get(url)
-        
+        response = session_client.get(url)
+
         # Check response
         assert response.status_code == status.HTTP_200_OK
         assert "data" in response.data
@@ -69,34 +70,30 @@ class TestMyEndpoint:
 
 ## Writing Smoke Tests
 
-Smoke tests should be placed in `tests/smoke/` directory and use the `plane_server` fixture to test against a real HTTP server.
+Smoke tests should be placed in `plane/tests/smoke/` directory and use the `plane_server` fixture to test against a real HTTP server.
 
 ### Example Smoke Test:
 
 ```python
 import pytest
 import requests
+from django.urls import reverse
 
 @pytest.mark.smoke
 class TestCriticalFlow:
     @pytest.mark.django_db
     def test_login_flow(self, plane_server, create_user, user_data):
-        # Get login URL
-        url = f"{plane_server.url}/api/auth/signin/"
-        
-        # Test login
+        # Sign-in is a form POST that answers with a redirect, not a token
+        url = f"{plane_server.url}{reverse('sign-in')}"
+
         response = requests.post(
-            url, 
-            json={
-                "email": user_data["email"],
-                "password": user_data["password"]
-            }
+            url,
+            data={"email": user_data["email"], "password": user_data["password"]},
+            allow_redirects=False,
         )
-        
+
         # Verify
-        assert response.status_code == 200
-        data = response.json()
-        assert "access_token" in data
+        assert response.status_code not in range(400, 600)
 ```
 
 ## Useful Fixtures
@@ -106,10 +103,14 @@ Our test setup provides several useful fixtures:
 1. `api_client`: An unauthenticated DRF APIClient
 2. `api_key_client`: API client with API key authentication (for external API tests)
 3. `session_client`: API client with session authentication (for web app API tests)
-4. `create_user`: Creates and returns a test user
-5. `mock_redis`: Mocks Redis interactions
-6. `mock_elasticsearch`: Mocks Elasticsearch interactions
-7. `mock_celery`: Mocks Celery task execution
+4. `create_user`: Creates and returns a test user (credentials in `user_data`)
+5. `api_token`: API token for the test user
+6. `plane_server`: Live Django test server for smoke tests
+7. `workspace`: A workspace owned by the test user
+8. `mock_redis`: Patches `plane.settings.redis.redis_instance` to return a `MagicMock` client
+9. `mock_celery`: Patches Celery's `Task.delay` so tasks are not executed
+
+For other external services, use pytest-mock's `mocker` fixture.
 
 ## Using Factory Boy
 
@@ -130,22 +131,29 @@ users = UserFactory.create_batch(5)
 
 ## Running Tests
 
-Use pytest to run tests:
+The recommended way is the isolated Docker stack described in [`apps/api/tests/RUNNING_TESTS.md`](../../tests/RUNNING_TESTS.md):
+
+```bash
+# From the repo root
+docker compose -f docker-compose-test.yml run --rm --build api-tests pytest -m unit
+```
+
+With a local env (`uv sync` in `apps/api` plus running Postgres, Redis, RabbitMQ and MinIO):
 
 ```bash
 # Run all tests
-python -m pytest
+uv run pytest
 
 # Run only unit tests with coverage
-python -m pytest -m unit --cov=plane
+uv run pytest -m unit --cov=plane
 ```
 
 ## Best Practices
 
 1. **Keep tests small and focused** - Each test should verify one specific behavior.
 2. **Use markers** - Always add appropriate markers (`@pytest.mark.unit`, etc.).
-3. **Mock external dependencies** - Use the provided mock fixtures.
+3. **Mock external dependencies** - Use `mock_redis` / `mock_celery`, or `mocker.patch(...)` from pytest-mock.
 4. **Use factories** - For complex data setup, use factories.
 5. **Don't test the framework** - Focus on testing your business logic, not Django/DRF itself.
 6. **Write readable assertions** - Use plain `assert` statements with clear messaging.
-7. **Focus on coverage** - Aim for ≥90% code coverage for critical components.
\ No newline at end of file
+7. **Focus on coverage** - Aim for ≥90% code coverage for critical components.
diff --git a/apps/api/plane/utils/exporters/README.md b/apps/api/plane/utils/exporters/README.md
index cbecaaa4b9f2..65784622d444 100644
--- a/apps/api/plane/utils/exporters/README.md
+++ b/apps/api/plane/utils/exporters/README.md
@@ -2,6 +2,8 @@
 
 A flexible and extensible data export utility for exporting Django model data in multiple formats (CSV, JSON, XLSX).
 
+> **Note:** the work item export background task (`plane/bgtasks/export_task.py`) uses `plane.utils.porters` (`DataExporter` with `IssueExportSerializer`), not this module. Change `plane.utils.porters` to change what users get from **Export**.
+
 ## 🎯 Overview
 
 The exporters module provides a schema-based approach to exporting data with support for:
@@ -41,9 +43,10 @@ from plane.utils.exporters import Exporter, IssueExportSchema
 
 # Get issues with prefetched relations
 issues = Issue.objects.filter(project_id=project_id).prefetch_related(
-    'assignee_details',
-    'label_details',
-    'issue_module',
+    'assignees',
+    'labels',
+    'issue_module__module',
+    'issue_link',
     # ... other relations
 )
 
@@ -122,7 +125,7 @@ assignees = ListField(label="Assignees")  # Custom preparer can populate this
 
 #### 🗂️ JSONField
 
-Handles complex JSON-serializable objects (dicts, lists of dicts). In CSV/XLSX, they're serialized as JSON strings. In JSON, they remain as objects.
+Handles complex JSON-serializable objects (dicts, lists of dicts). In CSV/XLSX, a dict is serialized as a JSON string, while a list is joined item by item with `str()` (so a list of dicts comes out as Python reprs). In JSON, they remain as objects.
 
 ```python
 metadata = JSONField(source="metadata", label="Metadata")
@@ -155,7 +158,7 @@ class MySchema(ExportSchema):
     assignees = ListField(label="Assignees")
 
     def prepare_assignees(self, obj):
-        return [f"{u.first_name} {u.last_name}" for u in obj.assignee_details]
+        return [f"{u.first_name} {u.last_name}" for u in obj.assignees.all()]
 ```
 
 Preparers take precedence over field definitions.
@@ -205,7 +208,8 @@ exporter = Exporter(
 ```python
 exporter = Exporter(format_type="json", schema_class=MySchema)
 filename, content = exporter.export("data", records)
-# content is a JSON string: '[{"field": "value"}, ...]'
+# content is a JSON string keyed by field label: '[{"Field Label": "value"}, ...]'
+# (a field without a label falls back to its title-cased name, e.g. "state_name" -> "State Name")
 ```
 
 ### 📗 XLSX Format
@@ -215,6 +219,7 @@ filename, content = exporter.export("data", records)
 - JSON objects are serialized as JSON strings
 - File extension: `.xlsx`
 - Returns binary content (bytes)
+- CSV and XLSX cells are passed through `sanitize_csv_row` to block spreadsheet formula injection
 
 ```python
 exporter = Exporter(format_type="xlsx", schema_class=MySchema)
@@ -239,7 +244,7 @@ class MySchema(ExportSchema):
     @classmethod
     def get_context_data(cls, queryset):
         """Pre-fetch all attachments in one query."""
-        attachments_dict = get_attachments_dict(queryset)
+        attachments_dict = get_issue_attachments_dict(queryset)  # from plane.utils.exporters.schemas.issue
         return {"attachments_dict": attachments_dict}
 
 # The Exporter automatically uses get_context_data() when serializing
@@ -366,8 +371,8 @@ Key features:
    @classmethod
    def get_context_data(cls, queryset):
        return {
-           "attachments": get_attachments_dict(queryset),
-           "comments": get_comments_dict(queryset),
+           "attachments_dict": get_issue_attachments_dict(queryset),
+           "last_cycles_dict": get_issue_last_cycles_dict(queryset),
        }
    ```
 
@@ -387,7 +392,7 @@ Key features:
 
    ```python
    def prepare_assignees(self, obj):
-       return [f"{u.first_name} {u.last_name}" for u in obj.assignee_details]
+       return [f"{u.first_name} {u.last_name}" for u in obj.assignees.all()]
    ```
 
 5. **⚡ Pass QuerySets Directly**: Let the Exporter handle serialization:
@@ -488,7 +493,8 @@ assert isinstance(content, str)
 # Test with field filtering
 filename, content = exporter.export("test", queryset, fields=["id", "name"])
 data = json.loads(content)
-assert all(set(item.keys()) == {"id", "name"} for item in data)
+# JSON keys are the field labels, e.g. {"ID", "Name"} for fields labelled "ID" and "Name"
+assert all(set(item.keys()) == {"ID", "Name"} for item in data)
 
 # Test manual serialization
 data = MySchema.serialize_queryset(queryset)
diff --git a/apps/api/plane/utils/openapi/README.md b/apps/api/plane/utils/openapi/README.md
index 9ac82cdd378c..c41613efcb93 100644
--- a/apps/api/plane/utils/openapi/README.md
+++ b/apps/api/plane/utils/openapi/README.md
@@ -12,12 +12,13 @@ plane/utils/openapi/
 ├── responses.py         # Common OpenAPI responses
 ├── examples.py          # Common OpenAPI examples
 ├── decorators.py        # Helper decorators for different endpoint types
-└── hooks.py            # Schema processing hooks (pre/post processing)
+└── hooks.py            # Schema preprocessing hook and summary helper
 ```
 
 ## Usage
 
 ### Import Everything (Recommended for backwards compatibility)
+
 ```python
 from plane.utils.openapi import (
     asset_docs,
@@ -28,6 +29,7 @@ from plane.utils.openapi import (
 ```
 
 ### Import from Specific Modules (Recommended for new code)
+
 ```python
 from plane.utils.openapi.decorators import asset_docs
 from plane.utils.openapi.parameters import ASSET_ID_PARAMETER
@@ -37,66 +39,43 @@ from plane.utils.openapi.responses import UNAUTHORIZED_RESPONSE
 ## Module Contents
 
 ### auth.py
-- `APIKeyAuthenticationExtension` - X-API-Key authentication
-- `APITokenAuthenticationExtension` - Bearer token authentication
+
+- `APIKeyAuthenticationExtension` - X-API-Key authentication (imported in `plane/api/apps.py` so drf-spectacular registers it)
 
 ### parameters.py
+
 - Path parameters: `WORKSPACE_SLUG_PARAMETER`, `PROJECT_ID_PARAMETER`, `ISSUE_ID_PARAMETER`, `ASSET_ID_PARAMETER`
 - Query parameters: `CURSOR_PARAMETER`, `PER_PAGE_PARAMETER`
 
 ### responses.py
+
 - Auth responses: `UNAUTHORIZED_RESPONSE`, `FORBIDDEN_RESPONSE`
 - Resource responses: `NOT_FOUND_RESPONSE`, `VALIDATION_ERROR_RESPONSE`
 - Asset responses: `PRESIGNED_URL_SUCCESS_RESPONSE`, `ASSET_UPDATED_RESPONSE`, etc.
 - Generic asset responses: `GENERIC_ASSET_UPLOAD_SUCCESS_RESPONSE`, `ASSET_DOWNLOAD_SUCCESS_RESPONSE`, etc.
 
 ### examples.py
+
 - `FILE_UPLOAD_EXAMPLE`, `WORKSPACE_EXAMPLE`, `PROJECT_EXAMPLE`, `ISSUE_EXAMPLE`
 
 ### decorators.py
-- `workspace_docs()` - For workspace endpoints
-- `project_docs()` - For project endpoints  
-- `issue_docs()` - For issue/work item endpoints
-- `asset_docs()` - For asset endpoints
+
+One `*_docs()` decorator per resource, each wrapping `extend_schema` with the right tag and shared defaults:
+`user_docs`, `workspace_docs`, `project_docs`, `cycle_docs`, `issue_docs`, `intake_docs`, `asset_docs`, `work_item_docs`, `label_docs`, `issue_link_docs`, `issue_comment_docs`, `issue_activity_docs`, `issue_attachment_docs`, `work_item_relation_docs`, `module_docs`, `module_issue_docs`, `state_docs`, `sticky_docs`, `estimate_docs`, `estimate_point_docs`.
 
 ### hooks.py
-- `preprocess_filter_api_v1_paths()` - Filters API v1 paths
-- `postprocess_assign_tags()` - Assigns tags based on URL patterns
-- `generate_operation_summary()` - Generates operation summaries
-
-## Migration Status
-
-✅ **FULLY COMPLETE** - All components from the legacy `openapi_spec_helpers.py` have been successfully migrated to this modular structure and the old file has been completely removed. All imports have been updated to use the new modular structure.
-
-### What was migrated:
-- ✅ All authentication extensions
-- ✅ All common parameters and responses
-- ✅ All helper decorators 
-- ✅ All schema processing hooks
-- ✅ All examples and reusable components
-- ✅ All asset view decorators converted to use new helpers
-- ✅ All view imports updated to new module paths
-- ✅ Legacy file completely removed
-
-### Files updated:
-- `plane/api/views/asset.py` - All methods use new `@asset_docs` helpers
-- `plane/api/views/project.py` - Import updated
-- `plane/api/views/user.py` - Import updated  
-- `plane/api/views/state.py` - Import updated
-- `plane/api/views/intake.py` - Import updated
-- `plane/api/views/member.py` - Import updated
-- `plane/api/views/module.py` - Import updated
-- `plane/api/views/cycle.py` - Import updated
-- `plane/api/views/issue.py` - Import updated
-- `plane/settings/common.py` - Hook paths updated
-- `plane/api/apps.py` - Auth extension import updated
-
-## Benefits
-
-1. **Better Organization**: Related functionality is grouped together
-2. **Easier Maintenance**: Changes to specific areas only affect relevant files
-3. **Improved Discoverability**: Clear module names make it easy to find what you need
-4. **Backwards Compatibility**: All existing imports continue to work
-5. **Reduced Coupling**: Import only what you need from specific modules
-6. **Consistent Documentation**: All endpoints now use standardized helpers
-7. **Massive Code Reduction**: ~80% reduction in decorator bloat using reusable components 
\ No newline at end of file
+
+- `preprocess_filter_api_v1_paths()` - Keeps only `/api/v1/` paths and drops `PUT` operations and any path containing `server`
+- `generate_operation_summary()` - Generates operation summaries (exported, not wired into the settings)
+
+## Configuration
+
+The schema is only generated when `ENABLE_DRF_SPECTACULAR=1` is set in the API environment. `plane/settings/common.py` then loads `SPECTACULAR_SETTINGS` from `plane/settings/openapi.py` (which registers the preprocessing hook) and `plane/urls.py` serves:
+
+- `/api/schema/` - OpenAPI schema
+- `/api/schema/swagger-ui/` - Swagger UI
+- `/api/schema/redoc/` - ReDoc
+
+## Where it is used
+
+All public API views in `plane/api/views/` import from this module: `asset.py`, `cycle.py`, `estimate.py`, `intake.py`, `invite.py`, `issue.py`, `member.py`, `module.py`, `project.py`, `state.py`, `sticky.py` and `user.py`. The legacy `openapi_spec_helpers.py` file has been removed.
diff --git a/apps/api/tests/RUNNING_TESTS.md b/apps/api/tests/RUNNING_TESTS.md
index f58b3e06412f..0956f4c9e23e 100644
--- a/apps/api/tests/RUNNING_TESTS.md
+++ b/apps/api/tests/RUNNING_TESTS.md
@@ -2,7 +2,7 @@
 
 This guide covers running the Django/pytest suite for `apps/api` inside Docker via `docker-compose-test.yml` at the repo root. The compose file boots an isolated stack — Postgres, Valkey (Redis), RabbitMQ, MinIO — with tmpfs-backed data dirs, so every run begins from a clean slate and a single teardown command removes everything.
 
-For background on the test layout, markers, and fixtures, see [`TESTING_GUIDE.md`](./TESTING_GUIDE.md) and [`README.md`](./README.md).
+For background on the test layout, markers, and fixtures, see [`TESTING_GUIDE.md`](../plane/tests/TESTING_GUIDE.md) and [`README.md`](../plane/tests/README.md).
 
 ## Prerequisites
 
@@ -28,13 +28,13 @@ docker compose -f docker-compose-test.yml up \
   --exit-code-from api-tests
 ```
 
-- `--build` rebuilds the `api-tests` image when `Dockerfile.dev`, `pyproject.toml` or `uv.lock` change.
+- `--build` rebuilds the `api-tests` image when `Dockerfile.dev`, `pyproject.toml` or `uv.lock` change. Dependency changes also work without a rebuild: the entrypoint runs `uv sync --locked --inexact` against the mounted `uv.lock` before every run.
 - `--abort-on-container-exit` stops the dependency services as soon as `api-tests` exits.
 - `--exit-code-from api-tests` propagates pytest's exit code so this works in CI.
 
 ### Filtered runs
 
-Use `docker compose run` to override the default `pytest` command. Anything you pass after the service name is forwarded to pytest.
+Use `docker compose run` to override the default `pytest` command. Anything you pass after the service name replaces that command, so start it with `pytest`.
 
 ```bash
 # Only unit tests (marker defined in pytest.ini)
@@ -46,7 +46,7 @@ docker compose -f docker-compose-test.yml run --rm --build api-tests \
 
 # Single file with verbose output
 docker compose -f docker-compose-test.yml run --rm --build api-tests \
-  pytest plane/tests/unit/models/test_workspace.py -vv
+  pytest plane/tests/unit/models/test_workspace_model.py -vv
 ```
 
 The available markers (`unit`, `contract`, `smoke`, `slow`) are declared in `apps/api/pytest.ini`.
@@ -57,7 +57,7 @@ The available markers (`unit`, `contract`, `smoke`, `slow`) are declared in `app
 docker compose -f docker-compose-test.yml down -v
 ```
 
-`-v` removes the ephemeral volumes and the `test_env` network. Because the data directories are tmpfs, no host state survives a teardown — every run starts clean. Run this between unrelated test sessions to free Docker resources.
+`down` removes the containers and the `test_env` network; `-v` also removes the anonymous volumes the service images create. Because the data directories are tmpfs, no host state survives a teardown — every run starts clean. Run this between unrelated test sessions to free Docker resources.
 
 ## How it works
 
@@ -71,12 +71,12 @@ docker compose -f docker-compose-test.yml down -v
 
 All four dependencies expose health checks; `api-tests` waits for `service_healthy` on each via `depends_on`, so pytest only starts once the stack is ready.
 
-Test-time env overrides live in the compose file itself (`POSTGRES_HOST=test-db`, `REDIS_URL=redis://test-redis:6379/`, `AWS_S3_ENDPOINT_URL=http://test-minio:9000`, `DJANGO_SETTINGS_MODULE=plane.settings.test`). Everything else is inherited from `apps/api/.env`.
+Test-time env overrides live in the compose file itself (`DJANGO_SETTINGS_MODULE=plane.settings.test`, `POSTGRES_HOST=test-db`, `DATABASE_URL` pointing at `test-db`, `REDIS_HOST=test-redis`, `REDIS_URL=redis://test-redis:6379/`, `RABBITMQ_HOST=test-mq`, `AWS_S3_ENDPOINT_URL=http://test-minio:9000`, and a placeholder `EMAIL_HOST=test-smtp.invalid` for the magic-link tests). Everything else is inherited from `apps/api/.env`.
 
 ## Troubleshooting
 
 - **`./apps/api/.env: no such file or directory`** — run `./setup.sh` from the repo root.
 - **Port already in use** — none of the test services publish host ports; if you see this it's coming from a different compose stack. Stop the local stack (`docker compose -f docker-compose-local.yml down`).
-- **Stale image after dependency changes** — rebuild explicitly: `docker compose -f docker-compose-test.yml build --no-cache api-tests`.
+- **Stale image after `Dockerfile.dev` changes** — rebuild explicitly: `docker compose -f docker-compose-test.yml build --no-cache api-tests`.
 - **MinIO bucket missing** — the `test-minio` entrypoint creates the bucket named by `AWS_S3_BUCKET_NAME` (default `uploads`). Change the value in `apps/api/.env` and re-run.
-- **Database state leaking between runs** — confirm you ran `down -v` (not just `down`). The tmpfs mounts are torn down with the container, but the network and any externally created volumes need `-v` to clear.
+- **Database state leaking between runs** — confirm you ran `down -v` (not just `down`). The tmpfs mounts are torn down with the container; `-v` also clears the anonymous volumes the images create.
diff --git a/apps/space/README.md b/apps/space/README.md
index fc22981018cc..f58b1bd10e7e 100644
--- a/apps/space/README.md
+++ b/apps/space/README.md
@@ -8,3 +8,20 @@
 
 <h3 align="center"><b>Plane Space</b></h3>
 <p align="center"><b>Open-source, self-hosted project planning tool</b></p>
+
+Plane Space serves the public view of a Plane instance at `/spaces`: the work items of projects that have been published to the web (`/issues/:anchor`). It is a [React Router](https://reactrouter.com/) app that talks to the Plane API.
+
+## Development
+
+From the repo root, after running `./setup.sh` (which copies `apps/space/.env.example` to `apps/space/.env`) and starting the API (see [CONTRIBUTING.md](../../CONTRIBUTING.md)):
+
+```bash
+pnpm dev                                # all apps; space runs on http://localhost:3002
+pnpm turbo run dev --filter=space       # only space and its workspace dependencies
+```
+
+Other scripts: `pnpm --filter=space build`, `pnpm --filter=space start` (serves the build on port 3002).
+
+## Configuration
+
+`apps/space/.env` sets the URLs of the other services (`VITE_API_BASE_URL`, `VITE_WEB_BASE_URL`, `VITE_ADMIN_BASE_URL`, `VITE_LIVE_BASE_URL`) and the base paths. `VITE_SPACE_BASE_PATH` (default `/spaces`) is used as the router basename.
diff --git a/deployments/aio/community/README.md b/deployments/aio/community/README.md
index 693a66df4b28..19651d40ce6d 100644
--- a/deployments/aio/community/README.md
+++ b/deployments/aio/community/README.md
@@ -6,13 +6,14 @@ The Plane Community All-In-One Docker image packages all Plane services into a s
 
 The AIO image contains the following services:
 
-- **Web App** (Port 3001): Main Plane web interface
-- **Space** (Port 3002): Public project spaces
-- **Admin** (Port 3003): Administrative interface
-- **API Server** (Port 3004): Backend API
-- **Live Server** (Port 3005): Real-time collaboration
-- **Proxy** (Port 80, 443): Caddy reverse proxy
+- **Proxy** (Port 80, 443): Caddy reverse proxy, the only exposed entry point
+- **Web App**: Main Plane web interface, static files served by the proxy at `/`
+- **Admin**: Instance admin (God mode), static files served by the proxy at `/god-mode`
+- **Space** (internal port 3002): Public project spaces at `/spaces`
+- **API Server** (internal port 3004): Backend API at `/api` and `/auth`
+- **Live Server** (internal port 3005): Real-time collaboration at `/live`
 - **Worker & Beat**: Background task processing
+- **Migrator**: Runs database migrations at startup
 
 ## Prerequisites
 
@@ -35,6 +36,8 @@ You must provide these environment variables:
 - `DATABASE_URL`: PostgreSQL connection string
 - `REDIS_URL`: Redis connection string
 - `AMQP_URL`: RabbitMQ connection string
+- `SECRET_KEY`: Django secret key (see [Security & Secrets](#security--secrets))
+- `LIVE_SERVER_SECRET_KEY`: Live server secret (see [Security & Secrets](#security--secrets))
 
 #### Storage Configuration
 
@@ -42,7 +45,7 @@ You must provide these environment variables:
 - `AWS_ACCESS_KEY_ID`: S3 access key
 - `AWS_SECRET_ACCESS_KEY`: S3 secret key
 - `AWS_S3_BUCKET_NAME`: S3 bucket name
-- `AWS_S3_ENDPOINT_URL`: S3 endpoint (optional, defaults to AWS)
+- `AWS_S3_ENDPOINT_URL`: S3 endpoint (optional, defaults to `https://s3.${AWS_REGION}.amazonaws.com`)
 
 ## Quick Start
 
@@ -80,6 +83,8 @@ docker run --name myaio --rm -it \
     -e AWS_S3_BUCKET_NAME=plane-app \
     -e AWS_S3_ENDPOINT_URL=http://${MYIP}:19000 \
     -e FILE_SIZE_LIMIT=10485760 \
+    -e SECRET_KEY=$(openssl rand -hex 32) \
+    -e LIVE_SERVER_SECRET_KEY=$(openssl rand -hex 32) \
     makeplane/plane-aio-community:latest
 ```
 
@@ -89,7 +94,8 @@ docker run --name myaio --rm -it \
 
 #### Network & Protocol
 
-- `SITE_ADDRESS`: Server bind address (default: `:80`)
+- `SITE_ADDRESS`: Server bind address (default: `:80`). Set it to your domain (e.g. `plane.example.com`) to have Caddy serve HTTPS on 443 with an automatic certificate.
+- `APP_PROTOCOL`: `http` or `https` (default: `http`). Used to build `WEB_URL` and `CORS_ALLOWED_ORIGINS` from `DOMAIN_NAME`.
 
 #### Security & Secrets
 
@@ -116,30 +122,33 @@ In v1.4.0 to v1.4.2 a container started without `SECRET_KEY` received a generate
 The following ports are exposed:
 
 - `80`: Main web interface (HTTP)
-- `443`: HTTPS (if SSL configured)
+- `443`: HTTPS (only when `SITE_ADDRESS` is set to a domain)
 
 ## Volume Mounts
 
 ### Recommended Persistent Volumes
 
 ```bash
--v /path/to/logs:/app/logs \
--v /path/to/data:/app/data
+-v /path/to/logs:/app/logs
 ```
 
+The image also declares `/app/data` as a volume, but no service writes to it today. Store `SECRET_KEY` and `LIVE_SERVER_SECRET_KEY` outside the container, and pass the same values every time you recreate it.
+
 ## Building the Image
 
 To build the AIO image yourself:
 
 ```bash
 cd deployments/aio/community
-IMAGE_NAME=myplane-aio ./build.sh --release=v0.27.1 [--platform=linux/amd64]
+IMAGE_NAME=myplane-aio ./build.sh --release=v1.5.0
 ```
 
+`build.sh` does not build the image itself. It prepares `dist/plane.env` and `dist/Caddyfile`, then prints the `docker build ... --build-arg PLANE_VERSION=<release>` command to run next.
+
 Available build options:
 
 - `--release`: Plane version to build (required)
-- `--image-name`: Custom image name (default: `plane-aio-community`)
+- `--image-name`: Custom image name (default: `makeplane/plane-aio-community`, or the `IMAGE_NAME` env var)
 
 ## Troubleshooting
 
@@ -168,6 +177,10 @@ docker exec -it <container-name> supervisorctl status
 
 The container will validate required environment variables on startup and display helpful error messages if any are missing.
 
+### Environment variable precedence
+
+At startup the container writes the variables above into `/app/plane.env` and then exports every line of that file. Variables that the start script does not manage (`CERT_EMAIL`, `CERT_ACME_CA`, `CERT_ACME_DNS`, `DEBUG`, `GUNICORN_WORKERS`, `AUTHENTICATION_RATE_LIMIT`, `MINIO_ENDPOINT_SSL`, `WEBHOOK_ALLOWED_IPS`, `WEBHOOK_ALLOWED_HOSTS`, `API_BASE_URL`) keep the value from `/app/plane.env`, even if you pass them with `-e`. To change them, mount your own copy of the file: `-v /path/to/plane.env:/app/plane.env`.
+
 ## Production Considerations
 
 - Use proper SSL certificates for HTTPS
@@ -179,4 +192,4 @@ The container will validate required environment variables on startup and displa
 
 ## Support
 
-For issues and support, please refer to the official Plane documentation.
+For issues and support, see the [AIO self-hosting docs](https://developers.plane.so/self-hosting/methods/docker-aio), ask on the [Forum](https://forum.plane.so), or open a [GitHub issue](https://github.com/makeplane/plane/issues).
diff --git a/deployments/aio/community/variables.env b/deployments/aio/community/variables.env
index 8de7439d9630..aa28c34aca23 100644
--- a/deployments/aio/community/variables.env
+++ b/deployments/aio/community/variables.env
@@ -33,8 +33,7 @@ AMQP_URL=
 # Secret Key — change this before deploying to production.
 # Generate a secure value with: python3 -c "from django.utils.crypto import get_random_secret_key; print(get_random_secret_key())"
 # or: openssl rand -hex 32
-# The startup script auto-generates and persists a random key on first boot if the
-# placeholder value below is left unchanged.
+# Required: the container exits at startup if this is empty or left at the placeholder.
 SECRET_KEY=change-this-key-on-deployment
 
 # DATA STORE SETTINGS
@@ -65,8 +64,7 @@ AUTHENTICATION_RATE_LIMIT=10/minute
 
 # Live Server Secret Key — change this before deploying to production.
 # Generate a secure value with: openssl rand -hex 32
-# The startup script auto-generates and persists a random key on first boot if the
-# placeholder value below is left unchanged.
+# Required: the container exits at startup if this is empty or left at the placeholder.
 LIVE_SERVER_SECRET_KEY=change-this-key-on-deployment
 
 # Webhook IP allowlist — comma-separated IPs or CIDR ranges allowed as webhook targets
diff --git a/deployments/cli/community/README.md b/deployments/cli/community/README.md
index 3c4841ede5f9..c208866b9d3e 100644
--- a/deployments/cli/community/README.md
+++ b/deployments/cli/community/README.md
@@ -25,7 +25,7 @@ Let's get started!
 #### For Mac
 
   <ol>
-    <li> Download Docker Desktop for Mac from the <a href="https://hub.docker.com/editions/community/docker-ce-desktop-mac/" target="_blank">Docker Hub</a>. </li>
+    <li> Download Docker Desktop for Mac from the <a href="https://docs.docker.com/desktop/setup/install/mac-install/" target="_blank">Docker docs</a>. </li>
     <li> Double-click the downloaded `.dmg` file and drag the Docker app icon to the Applications folder. </li>
     <li>Open Docker Desktop from the Applications folder. You might be asked to provide your system password to install additional software.</li>
   </ol>
@@ -33,7 +33,7 @@ Let's get started!
 #### For Windows:
 
   <ol>
-    <li>Download Docker Desktop for Windows from the <a href="https://hub.docker.com/editions/community/docker-ce-desktop-windows/" target="_blank">Docker Hub</a>.</li>
+    <li>Download Docker Desktop for Windows from the <a href="https://docs.docker.com/desktop/setup/install/windows-install/" target="_blank">Docker docs</a>.</li>
     <li>Run the installer and follow the instructions. You might be asked to enable Hyper-V and "Containers" Windows features.</li>
     <li>Open Docker Desktop. You might be asked to log out and log back in, or restart your machine, for changes to take effect.</li>
   </ol>
@@ -93,7 +93,7 @@ This will prompt you with the below options.
 
 ```bash
 Select an Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -112,7 +112,9 @@ This will create a folder `plane-app` and will download 2 files inside that
 - `docker-compose.yaml`
 - `plane.env`
 
-Again the `options [1-8]` will be popped up, and this time hit `8` to exit.
+The script exits when the install is done. Review `plane-app/plane.env` (see below), then start the services.
+
+The script also accepts the action as an argument, so you can skip the menu: `./setup.sh install|start|stop|restart|upgrade|logs|backup`.
 
 #### Docker Swarm
 
@@ -129,29 +131,37 @@ Select an Action you want to perform:
 Action [3]: 1
 ```
 
-For the 1st time setup, type "1" as action input.
+Run `docker swarm init` on the manager node first if the node is not part of a swarm yet.
 
-This will create a create a folder `plane-app` and will download 2 files inside that
+For the 1st time setup, type "1" as action input. The script asks for a stack name (default `plane`), creates a folder `plane-app`, downloads 2 files inside that
 
-- `docker-compose.yaml`
+- `docker-compose.yml`
 - `plane.env`
 
-Again the `options [1-7]` will be popped up, and this time hit `7` to exit.
+and deploys the stack with `docker stack deploy` right away. Review `plane-app/plane.env` and use `Redeploy Stack` to apply changes.
 
 ---
 
 ### Continue with setup - Environment Settings
 
-Before proceeding, we suggest used to review `.env` file and set the values.
+Before proceeding, we suggest you review the `plane-app/plane.env` file and set the values.
 Below are the most import keys you must refer to. _<span style="color: #fcba03">You can use any text editor to edit this file</span>_.
 
 > `LISTEN_HTTP_PORT` - This is default set to `80`. Make sure the port you choose to use is not preoccupied. (e.g `LISTEN_HTTP_PORT=8080`)
 
-> `WEB_URL` - This is default set to `http://localhost`. Change this to the FQDN you plan to use along with LISTEN_HTTP_PORT (eg. `https://plane.example.com:8080` or `http://[IP-ADDRESS]:8080`)
+> `APP_DOMAIN` - This is default set to `localhost`. Set it to the domain or IP address you will use (eg. `plane.example.com`).
+
+> `WEB_URL` - This is default set to `http://${APP_DOMAIN}`. Change this to the FQDN you plan to use along with LISTEN_HTTP_PORT (eg. `https://plane.example.com:8080` or `http://[IP-ADDRESS]:8080`)
+
+> `CORS_ALLOWED_ORIGINS` - This is default set to `http://${APP_DOMAIN}`. Change this to the FQDN you plan to use along with LISTEN_HTTP_PORT (eg. `https://plane.example.com:8080` or `http://[IP-ADDRESS]:8080`)
+
+> `SECRET_KEY` and `LIVE_SERVER_SECRET_KEY` - Both ship as `change-this-key-on-deployment`. Set each to its own random value (eg. `openssl rand -hex 32`) before the first start.
+
+> HTTPS - The bundled Caddy proxy can issue certificates. Set `SITE_ADDRESS` to your domain (default `:80`, plain HTTP), `CERT_EMAIL` for the ACME account, optionally `CERT_ACME_DNS` for a DNS challenge, and keep `LISTEN_HTTPS_PORT` (default `443`) free.
 
-> `CORS_ALLOWED_ORIGINS` - This is default set to `http://localhost`. Change this to the FQDN you plan to use along with LISTEN_HTTP_PORT (eg. `https://plane.example.com:8080` or `http://[IP-ADDRESS]:8080`)
+> External services - To use your own Postgres, Redis, RabbitMQ or S3 instead of the bundled containers, set `DATABASE_URL`, `REDIS_URL`, `AMQP_URL`, and `USE_MINIO=0` with the `AWS_*` values in `plane.env`.
 
-There are many other settings you can play with, but we suggest you configure `EMAIL SETTINGS` as it will enable you to invite your teammates onto the platform.
+There are many other settings you can play with. We suggest you also set up email (SMTP) so you can invite your teammates onto the platform. SMTP is not set in `plane.env`: configure it in the instance admin at `/god-mode` → Email after you start the services.
 
 #### Client IP and rate limiting behind proxies
 
@@ -171,7 +181,7 @@ Lets again run the `./setup.sh` command. You will again be prompted with the bel
 
 ```bash
 Select a Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -206,7 +216,7 @@ Lets again run the `./setup.sh` command. You will again be prompted with the bel
 
 ```bash
 Select a Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -253,7 +263,7 @@ Lets again run the `./setup.sh` command. You will again be prompted with the bel
 
 ```bash
 Select a Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -299,7 +309,7 @@ Lets again run the `./setup.sh` command. You will again be prompted with the bel
 
 ```bash
 Select a Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -317,7 +327,7 @@ You must expect the below message
 
 ![Alt text](images/upgrade.png)
 
-Once done, choose `8` to exit from prompt.
+The script exits when the upgrade is done.
 
 > It is very important for you to validate the `plane.env` for the new changes.
 
@@ -339,13 +349,9 @@ Lets again run the `./setup.sh` command. You will again be prompted with the bel
 Action [3]: 5
 ```
 
-By choosing this, it will stop the services and then will download the latest `docker-compose.yaml` and `plane.env`.
-
-Once done, choose `7` to exit from prompt.
-
-> It is very important for you to validate the `plane.env` for the new changes.
+By choosing this, it asks for confirmation, downloads the latest `docker-compose.yml` and `plane.env` (your previous `plane.env` is kept as `plane.env.bak`), and redeploys the stack automatically.
 
-Once done with making changes in `plane.env` file, jump on to `Redeploy Stack`
+> It is very important for you to validate the `plane.env` for the new changes. If you change it, run `Redeploy Stack` again.
 
 ---
 
@@ -361,7 +367,7 @@ This time select `6` to view logs.
 
 ```bash
 Select a Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -409,6 +415,7 @@ Select a Service you want to view the logs for:
 Service: 3
 ```
 
+The Docker Swarm sub-menu lists services 1-9 (no Minio or RabbitMQ). The `admin` and `live` services have no menu entry; view them with `docker compose -f plane-app/docker-compose.yaml logs -f admin` (or `live`).
 Select any of the service to view the logs e.g. `3`. Expect something similar to this
 
 ```bash
@@ -436,7 +443,7 @@ api-1  | EMAIL_PORT loaded with value from environment variable.
 api-1  | EMAIL_FROM loaded with value from environment variable.
 api-1  | EMAIL_USE_TLS loaded with value from environment variable.
 api-1  | EMAIL_USE_SSL loaded with value from environment variable.
-api-1  | OPENAI_API_KEY loaded with value from environment variable.
+api-1  | LLM_API_KEY loaded with value from environment variable.
 api-1  | GPT_ENGINE loaded with value from environment variable.
 api-1  | UNSPLASH_ACCESS_KEY loaded with value from environment variable.
 api-1  | Checking bucket...
@@ -465,11 +472,13 @@ Similarly, you can view the logs of other services.
 
 There would a time when you might want to backup your data from docker volumes to external storage like S3 or drives.
 
+The services must be **running**: the backup copies data out of the running `plane-db`, `plane-minio`, `plane-mq` and `plane-redis` containers.
+
 Lets again run the `./setup.sh` command. You will again be prompted with the below options. This time select `7` to Backup the data.
 
 ```bash
 Select a Action you want to perform:
-   1) Install (x86_64)
+   1) Install
    2) Start
    3) Stop
    4) Restart
@@ -481,12 +490,13 @@ Select a Action you want to perform:
 Action [2]: 7
 ```
 
-In response, you can find the backup folder
+In response, you can find the backup folder. It holds `pgdata.tar.gz`, `uploads.tar.gz`, `rabbitmq_data.tar.gz` and `redisdata.tar.gz`.
 
 ```bash
-Backing Up plane-app_pgdata
-Backing Up plane-app_redisdata
-Backing Up plane-app_uploads
+Backing up plane-db data...
+Backing up plane-minio data...
+Backing up plane-mq data...
+Backing up plane-redis data...
 
 Backup completed successfully. Backup files are stored in /....../plane-app/backup/20240502-1120
 ```
@@ -497,7 +507,7 @@ Backup completed successfully. Backup files are stored in /....../plane-app/back
 
 When you want to restore the previously backed-up data, follow the instructions below.
 
-1. Make sure that Plane-CE is installed, started, and then stopped. This ensures that the Docker volumes are created.
+1. Make sure that Plane-CE is installed, started, and then stopped. This ensures that the Docker volumes are created. The restore script needs `jq` installed to check that Plane is stopped.
 
 1. Download the restore script using the command below. We suggest downloading it in the same folder as `setup.sh`.
 
@@ -537,6 +547,10 @@ When you want to restore the previously backed-up data, follow the instructions
    .....Restoring plane-app_uploads
    .....Successfully restored volume plane-app_uploads from uploads.tar.gz
 
+   Found /opt/plane-selfhost/plane-app/backup/20240722-0914/rabbitmq_data.tar.gz
+   .....Restoring plane-app_rabbitmq_data
+   .....Successfully restored volume plane-app_rabbitmq_data from rabbitmq_data.tar.gz
+
 
    Restore completed successfully.
    ```
@@ -566,6 +580,8 @@ When you want to restore the previously backed-up data on Plane Commercial Air-G
    ./restore-airgapped.sh <path to backup folder containing *.tar.gz files>
    ```
 
+   The script asks for the install path of the Air-Gapped edition (default `$HOME/planeairgapped`); that folder must contain its `docker-compose.yml`.
+
 1. After restoration, you are ready to start Plane Commercial (Airgapped) will all your previously saved data.
 
 ---
@@ -583,7 +599,7 @@ Begin with downloading the migration script using below command
 
 ```
 
-curl -fsSL -o migrate.sh https://raw.githubusercontent.com/makeplane/plane/master/deploy/selfhost/migration-0.13-0.14.sh
+curl -fsSL -o migrate.sh https://raw.githubusercontent.com/makeplane/plane/master/deployments/cli/community/migration-0.13-0.14.sh
 
 chmod +x migrate.sh
 
diff --git a/deployments/kubernetes/community/README.md b/deployments/kubernetes/community/README.md
index c1000c7327c3..0d053b8f1309 100644
--- a/deployments/kubernetes/community/README.md
+++ b/deployments/kubernetes/community/README.md
@@ -3,3 +3,13 @@
 Click on the below link to access the helm chart instructions.
 
 [![Artifact Hub](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/makeplane)](https://artifacthub.io/packages/helm/makeplane/plane-ce)
+
+Quick install:
+
+```bash
+helm repo add makeplane https://helm.plane.so/
+helm repo update
+helm install plane makeplane/plane-ce --namespace plane-ce --create-namespace
+```
+
+See the [Kubernetes self-hosting guide](https://developers.plane.so/self-hosting/methods/kubernetes) for the values you need to set (domain, ingress, external services).
diff --git a/docs/linting.md b/docs/linting.md
index a246d5028744..3ad063e5d66f 100644
--- a/docs/linting.md
+++ b/docs/linting.md
@@ -28,7 +28,7 @@ pnpm turbo run check:lint --filter=@plane/blocks
 
 ## VS Code Integration
 
-Install the [OxLint extension](https://marketplace.visualstudio.com/items?itemName=nicolo-ribaudo.vscode-oxlint) for inline errors/warnings as you type.
+Install the [Oxc extension](https://marketplace.visualstudio.com/items?itemName=oxc.oxc-vscode) for inline errors/warnings as you type.
 
 ## What Gets Linted
 
@@ -39,24 +39,28 @@ The config applies to all TypeScript and JavaScript files across:
 
 **Ignored paths:**
 
-- `node_modules/`, `dist/`, `build/`, `.next/`, `.turbo/`
+- `node_modules/`, `dist/`, `build/`, `coverage/`, `storybook-static/`
+- `.cache/`, `.next/`, `.react-router/`, `.storybook/`, `.turbo/`, `.vite/`
 - Config files (`*.config.{js,mjs,cjs,ts}`)
-- Public folders, coverage, storybook-static
+- Public folders
 
 ## Rules Overview
 
 OxLint uses category-based configuration:
 
-| Category        | Level | What It Catches                                    |
-| --------------- | ----- | -------------------------------------------------- |
-| **correctness** | error | Real bugs that will cause runtime errors            |
-| **suspicious**  | warn  | Code patterns that are likely mistakes              |
-| **perf**        | warn  | Performance anti-patterns                           |
+| Category        | Level | What It Catches                          |
+| --------------- | ----- | ---------------------------------------- |
+| **correctness** | warn  | Real bugs that will cause runtime errors |
+| **suspicious**  | warn  | Code patterns that are likely mistakes   |
+| **perf**        | warn  | Performance anti-patterns                |
+
+Every category reports warnings, so the gate is the warning budget: each package's `check:lint` script runs `oxlint --max-warnings=<n> .`, and the job fails if the count goes above `n`. Do not add new warnings; lower `n` when you fix existing ones.
 
 Additional rule overrides:
-- `react/prop-types` off (TypeScript handles prop validation)
+
+- `react/react-in-jsx-scope` and `react/prop-types` off (TypeScript handles prop validation)
 - `no-unused-vars` warns with `_` prefix pattern ignored
-- Several noisy unicorn rules disabled
+- Several noisy unicorn rules disabled (`filename-case`, `no-null`, `prevent-abbreviations`)
 
 ## Backward Compatibility
 
@@ -86,7 +90,16 @@ Lint-staged runs automatically on commit via Husky:
 
 If the commit fails due to lint errors, fix them before committing.
 
+## Formatting
+
+[oxfmt](https://oxc.rs/docs/guide/usage/formatter) formats the repo using [.oxfmtrc.json](../.oxfmtrc.json) (print width 120, Tailwind class sorting). Run `pnpm check:format` to check and `pnpm fix:format` to apply. CI runs `check:format` on every pull request.
+
+## Python (apps/api)
+
+The backend is linted with [Ruff](https://docs.astral.sh/ruff/) using [apps/api/ruff.toml](../apps/api/ruff.toml). Run `uv run ruff check .` from `apps/api`; CI runs the same command on pull requests that touch `apps/api`.
+
 ## Reference Files
 
 - [.oxlintrc.json](../.oxlintrc.json) - OxLint configuration
+- [.oxfmtrc.json](../.oxfmtrc.json) - oxfmt configuration
 - [package.json](../package.json) - Available scripts
diff --git a/packages/codemods/instructions.md b/packages/codemods/instructions.md
index 18212ba0c060..30de791014f5 100644
--- a/packages/codemods/instructions.md
+++ b/packages/codemods/instructions.md
@@ -1,17 +1,31 @@
 # jscodeshift Instructions
 
+This package (`@plane/codemods`) holds the repo's [jscodeshift](https://github.com/facebook/jscodeshift) codemods:
+
+- `function-declaration.ts` - run with `pnpm --filter=@plane/codemods function-declaration`
+- `remove-directives.ts` - run with `pnpm --filter=@plane/codemods remove-directives`
+
+Both scripts run over `apps/*` and `packages/*/src` (see `package.json`). Tests live in `tests/` and run with `pnpm --filter=@plane/codemods test` (vitest).
+
+The rest of this file is a jscodeshift API cheat sheet. In the examples, `j` is the jscodeshift API (`api.jscodeshift` inside a transform) and `root` is the collection returned by `j(source)`.
+
 ## API Reference
 
 ### Core API
 
 #### `jscodeshift`
 
-The main function that returns the jscodeshift instance.
+Parses the source and returns a Collection of its AST, which the traversal and transformation APIs below work on.
 
 - **Parameters**: `source` (String)
 - **Example**:
   ```javascript
-  const j = jscodeshift(sourceCode);
+  export default function transformer(file, api) {
+    const j = api.jscodeshift;
+    const root = j(file.source);
+    // ...
+    return root.toSource();
+  }
   ```
 
 ### Node Traversal APIs
@@ -23,7 +37,7 @@ Finds nodes that match the provided type.
 - **Parameters**: `type` (String or Function)
 - **Example**:
   ```javascript
-  const variableDeclarations = j.find(j.VariableDeclaration);
+  const variableDeclarations = root.find(j.VariableDeclaration);
   ```
 
 #### `findImportDeclarations`
@@ -33,7 +47,7 @@ Finds all ImportDeclarations optionally filtered by name.
 - **Parameters**: `sourcePath` (String)
 - **Example**:
   ```javascript
-  const routerImports = j.findImportDeclarations("react-router-dom");
+  const routerImports = root.findImportDeclarations("react-router-dom");
   ```
 
 #### `closestScope`
@@ -42,7 +56,7 @@ Finds the closest enclosing scope of a node.
 
 - **Example**:
   ```javascript
-  const closestScopes = j.find(j.Identifier).closestScope();
+  const closestScopes = root.find(j.Identifier).closestScope();
   ```
 
 #### `closest`
@@ -52,7 +66,9 @@ Finds the nearest parent node that matches the specified type.
 - **Parameters**: `type` (String or Function)
 - **Example**:
   ```javascript
-  const closestFunction = j.find(j.Identifier).closest(j.FunctionDeclaration);
+  const closestFunction = root
+    .find(j.Identifier)
+    .closest(j.FunctionDeclaration);
   ```
 
 #### `getVariableDeclarators`
@@ -74,7 +90,7 @@ Finds variable declarators by name.
 - **Parameters**: `name` (String)
 - **Example**:
   ```javascript
-  const variableDeclarators = j.findVariableDeclarators("a");
+  const variableDeclarators = root.findVariableDeclarators("a");
   ```
 
 #### `filter`
@@ -96,7 +112,7 @@ Iterates over each node in the collection.
 - **Parameters**: `callback` (Function)
 - **Example**:
   ```javascript
-  j.find(j.VariableDeclaration).forEach((path) => {
+  root.find(j.VariableDeclaration).forEach((path) => {
     console.log(path.node);
   });
   ```
@@ -143,7 +159,7 @@ Returns the number of nodes in the collection.
 
 - **Example**:
   ```javascript
-  const numberOfNodes = j.find(j.VariableDeclaration).size();
+  const numberOfNodes = root.find(j.VariableDeclaration).size();
   ```
 
 #### `length`
@@ -161,7 +177,7 @@ Returns the AST nodes in the collection.
 
 - **Example**:
   ```javascript
-  const nodes = j.find(j.VariableDeclaration).nodes();
+  const nodes = root.find(j.VariableDeclaration).nodes();
   ```
 
 #### `paths`
@@ -170,7 +186,7 @@ Returns the paths of the found nodes.
 
 - **Example**:
   ```javascript
-  const paths = j.find(j.VariableDeclaration).paths();
+  const paths = root.find(j.VariableDeclaration).paths();
   ```
 
 #### `getAST`
@@ -188,7 +204,7 @@ Gets the first node in the collection.
 
 - **Example**:
   ```javascript
-  const firstVariableDeclaration = j.find(j.VariableDeclaration).get();
+  const firstVariableDeclaration = root.find(j.VariableDeclaration).get();
   ```
 
 #### `at`
@@ -198,7 +214,7 @@ Navigates to a specific path in the AST.
 - **Parameters**: `index` (Number)
 - **Example**:
   ```javascript
-  const secondVariableDeclaration = j.find(j.VariableDeclaration).at(1);
+  const secondVariableDeclaration = root.find(j.VariableDeclaration).at(1);
   ```
 
 #### `getTypes`
@@ -214,13 +230,13 @@ Returns the set of node types present in the collection.
 
 Checks if the node in the collection is of a specific type.
 
-- **Parameters**: `type` (String)
+- **Parameters**: `type` (a type from `j`, e.g. `j.VariableDeclarator`)
 - **Example**:
   ```javascript
   const isVariableDeclarator = root
     .find(j.VariableDeclarator)
     .at(0)
-    .isOfType("VariableDeclarator");
+    .isOfType(j.VariableDeclarator);
   ```
 
 ### Node Transformation APIs
@@ -232,9 +248,9 @@ Replaces the current node(s) with a new node.
 - **Parameters**: `newNode` (Node or Function)
 - **Example**:
   ```javascript
-  j.find(j.Identifier).replaceWith((path) =>
-    j.identifier(path.node.name.toUpperCase())
-  );
+  root
+    .find(j.Identifier)
+    .replaceWith((path) => j.identifier(path.node.name.toUpperCase()));
   ```
 
 #### `insertBefore`
@@ -244,9 +260,9 @@ Inserts a node before the current node.
 - **Parameters**: `newNode` (Node)
 - **Example**:
   ```javascript
-  j.find(j.FunctionDeclaration).insertBefore(
-    j.expressionStatement(j.stringLiteral("Inserted before"))
-  );
+  root
+    .find(j.FunctionDeclaration)
+    .insertBefore(j.expressionStatement(j.stringLiteral("Inserted before")));
   ```
 
 #### `insertAfter`
@@ -256,9 +272,9 @@ Inserts a node after the current node.
 - **Parameters**: `newNode` (Node)
 - **Example**:
   ```javascript
-  j.find(j.FunctionDeclaration).insertAfter(
-    j.expressionStatement(j.stringLiteral("Inserted after"))
-  );
+  root
+    .find(j.FunctionDeclaration)
+    .insertAfter(j.expressionStatement(j.stringLiteral("Inserted after")));
   ```
 
 #### `remove`
@@ -267,7 +283,7 @@ Removes the current node(s).
 
 - **Example**:
   ```javascript
-  j.find(j.VariableDeclaration).remove();
+  root.find(j.VariableDeclaration).remove();
   ```
 
 #### `renameTo`
@@ -287,7 +303,7 @@ Converts the transformed AST back to source code.
 - **Parameters**: `options` (Object)
 - **Example**:
   ```javascript
-  const transformedSource = j.toSource({ quote: "single" });
+  const transformedSource = root.toSource({ quote: "single" });
   ```
 
 ## AST Grammar
diff --git a/packages/decorators/README.md b/packages/decorators/README.md
index f607ca2b9c7e..6f7f0f4eea56 100644
--- a/packages/decorators/README.md
+++ b/packages/decorators/README.md
@@ -6,9 +6,9 @@ A lightweight TypeScript decorator library for building Express.js controllers w
 
 - TypeScript-first design
 - Decorators for HTTP methods (GET, POST, PUT, PATCH, DELETE)
-- WebSocket support
+- WebSocket support (with `express-ws`)
 - Middleware support
-- No build step required - works directly with TypeScript files
+- Built with tsdown to `dist/` (`pnpm --filter=@plane/decorators build`)
 
 ## Installation
 
@@ -22,16 +22,18 @@ This package is part of the Plane workspace and can be used by adding it to your
 }
 ```
 
+The decorators use legacy TypeScript decorators and `reflect-metadata`, so the consuming project needs `"experimentalDecorators": true` and `"emitDecoratorMetadata": true` in its `tsconfig.json`.
+
 ## Usage
 
 ### Basic REST Controller
 
 ```typescript
-import { Controller, Get, Post, BaseController } from "@plane/decorators";
-import { Router, Request, Response } from "express";
+import { Controller, Get, Post, registerController } from "@plane/decorators";
+import { Router, type Request, type Response } from "express";
 
 @Controller("/api/users")
-class UserController extends BaseController {
+class UserController {
   @Get("/")
   async getUsers(req: Request, res: Response) {
     return res.json({ users: [] });
@@ -45,19 +47,21 @@ class UserController extends BaseController {
 
 // Register routes
 const router = Router();
-const userController = new UserController();
-userController.registerRoutes(router);
+registerController(router, UserController);
 ```
 
 ### WebSocket Controller
 
 ```typescript
-import { Controller, WebSocket, BaseWebSocketController } from "@plane/decorators";
-import { Request } from "express";
-import { WebSocket as WS } from "ws";
+import express, { Router, type Request } from "express";
+import expressWs from "express-ws";
+import type { WebSocket as WS } from "ws";
+import { Controller, WebSocket, registerController } from "@plane/decorators";
 
 @Controller("/ws/chat")
-class ChatController extends BaseWebSocketController {
+class ChatController {
+  constructor(private readonly chatService: ChatService) {}
+
   @WebSocket("/")
   handleConnection(ws: WS, req: Request) {
     ws.on("message", (message) => {
@@ -66,12 +70,18 @@ class ChatController extends BaseWebSocketController {
   }
 }
 
-// Register WebSocket routes
-const router = require("express-ws")(app).router;
-const chatController = new ChatController();
-chatController.registerWebSocketRoutes(router);
+// express-ws must patch the app before the router is created
+const app = express();
+expressWs(app);
+const router = Router();
+
+// Constructor arguments are passed as the third parameter
+registerController(router, ChatController, [chatService]);
+app.use(router);
 ```
 
+`registerController` detects whether a class has `@WebSocket` methods and registers it as a WebSocket or REST controller. See `apps/live/src/server.ts` for real usage.
+
 ## API Reference
 
 ### Decorators
@@ -85,11 +95,10 @@ chatController.registerWebSocketRoutes(router);
 - `@WebSocket(route: string)` - Method decorator for WebSocket endpoints
 - `@Middleware(middleware: RequestHandler)` - Method decorator for applying middleware
 
-### Classes
+### Functions
 
-- `BaseController` - Base class for REST controllers
-- `BaseWebSocketController` - Base class for WebSocket controllers
+- `registerController(router: Router, Controller, dependencies: unknown[] = [])` - Instantiates the controller with `dependencies` and registers its routes on `router`
 
 ## License
 
-This project is licensed under the [GNU Affero General Public License v3.0](https://github.com/makeplane/plane/blob/master/LICENSE.txt).
+This project is licensed under the [GNU Affero General Public License v3.0](../../LICENSE.txt).
diff --git a/packages/editor/Readme.md b/packages/editor/Readme.md
index 75aad2c95a29..79001f7163f4 100644
--- a/packages/editor/Readme.md
+++ b/packages/editor/Readme.md
@@ -2,62 +2,56 @@
 
 ## Description
 
-The `@plane/editor` package serves as the foundation for our editor system. It provides the base functionality for our other editor packages, but it will not be used directly in any of the projects but only for extending other editors.
+The `@plane/editor` package is Plane's rich text editor, built on [Tiptap](https://tiptap.dev/). It ships ready-to-use React editors that the apps import directly (for example `apps/web` and `apps/space`), plus helpers, constants and types for building on top of them.
 
-## Utilities
+## Entry points
 
-We provide a wide range of utilities for extending the core itself.
-
-1. Merging classes and custom styling
-2. Adding new extensions
-3. Adding custom props
-4. Base menu items, and their commands
-
-This allows for extensive customization and flexibility in the Editors created using our `editor-core` package.
+| Import                 | What it contains                                                                                     |
+| ---------------------- | ---------------------------------------------------------------------------------------------------- |
+| `@plane/editor`        | React editors, helpers, constants, extension lists and types                                         |
+| `@plane/editor/lib`    | Framework-free pieces: core extensions without props, document collaboration events, Yjs utilities   |
+| `@plane/editor/server` | Node entry (used by `apps/live`): everything in `lib` plus HTML/JSON/Yjs document conversion helpers |
+| `@plane/editor/styles` | Editor CSS (also available as `@plane/editor/styles.css`)                                            |
 
 ### Here's a detailed overview of what's exported
 
-1. useEditor - A hook that you can use to extend the Plane editor.
-
-   | Prop                      | Type                                                             | Description                                                                                                                                                             |
-   | ------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-   | `extensions`              | `Extension[]`                                                    | An array of custom extensions you want to add into the editor to extend it's core features                                                                              |
-   | `editorProps`             | `EditorProps`                                                    | Extend the editor props by passing in a custom props object                                                                                                             |
-   | `uploadFile`              | `(file: File) => Promise<string>`                                | A function that handles file upload. It takes a file as input and handles the process of uploading that file.                                                           |
-   | `deleteFile`              | `(assetUrlWithWorkspaceId: string) => Promise<any>`              | A function that handles deleting an image. It takes the asset url from your bucket and handles the process of deleting that image.                                      |
-   | `value`                   | `html string`                                                    | The initial content of the editor.                                                                                                                                      |
-   | `debouncedUpdatesEnabled` | `boolean`                                                        | If set to true, the `onChange` event handler is debounced, meaning it will only be invoked after the specified delay (default 1500ms) once the user has stopped typing. |
-   | `onChange`                | `(json: any, html: string) => void`                              | This function is invoked whenever the content of the editor changes. It is passed the new content in both JSON and HTML formats.                                        |
-   | `setIsSubmitting`         | `(isSubmitting: "submitting" \| "submitted" \| "saved") => void` | This function is called to update the submission status.                                                                                                                |
-   | `setShouldShowAlert`      | `(showAlert: boolean) => void`                                   | This function is used to show or hide an alert in case of content not being "saved".                                                                                    |
-   | `forwardedRef`            | `any`                                                            | Pass this in whenever you want to control the editor's state from an external component                                                                                 |
-
-2. useReadOnlyEditor - A hook that can be used to extend a Read Only instance of the core editor.
-
-   | Prop           | Type          | Description                                                                                |
-   | -------------- | ------------- | ------------------------------------------------------------------------------------------ |
-   | `value`        | `string`      | The initial content of the editor.                                                         |
-   | `forwardedRef` | `any`         | Pass this in whenever you want to control the editor's state from an external component    |
-   | `extensions`   | `Extension[]` | An array of custom extensions you want to add into the editor to extend it's core features |
-   | `editorProps`  | `EditorProps` | Extend the editor props by passing in a custom props object                                |
-
-3. Items and Commands - H1, H2, H3, task list, quote, code block, etc's methods.
-
-4. UI Wrappers
-
-- `EditorContainer` - Wrap your Editor Container with this to apply base classes and styles.
-- `EditorContentWrapper` - Use this to get Editor's Content and base menus.
-
-5. Extending with Custom Styles
+1. Editors - React components with a forwarded ref (`EditorRefApi`) to control the editor from outside:
+   - `RichTextEditorWithRef` (`IRichTextEditorProps`)
+   - `LiteTextEditorWithRef` (`ILiteTextEditorProps`), used for comments
+   - `DocumentEditorWithRef` (`IDocumentEditorProps`)
+   - `CollaborativeDocumentEditorWithRef` (`ICollaborativeDocumentEditorProps`), real-time editing through `apps/live`
+
+2. Common props (`IEditorProps` in `src/types/editor.ts`). The most important ones:
+
+   | Prop                                       | Type                                                                              | Description                                                      |
+   | ------------------------------------------ | --------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
+   | `id`                                       | `string`                                                                          | Unique id of the editor instance                                 |
+   | `initialValue` / `value`                   | `string`                                                                          | Initial and controlled HTML content                              |
+   | `editable`                                 | `boolean`                                                                         | Whether the content can be edited                                |
+   | `onChange`                                 | `(json: object, html: string, options?: { isMigrationUpdate?: boolean }) => void` | Called whenever the content changes, with JSON and HTML          |
+   | `fileHandler`                              | `TFileHandler`                                                                    | Upload, delete, restore and resolve assets (images, attachments) |
+   | `mentionHandler`                           | `TMentionHandler`                                                                 | Search and render `@` mentions                                   |
+   | `disabledExtensions` / `flaggedExtensions` | `TExtensions[]`                                                                   | Turn extensions off, or mark them as behind a feature flag       |
+   | `extensions`                               | `Extensions`                                                                      | Extra Tiptap extensions to add                                   |
+   | `editorProps`                              | `EditorProps`                                                                     | Extra ProseMirror editor props                                   |
+   | `forwardedRef`                             | `React.MutableRefObject<EditorRefApi \| null>`                                    | Ref used to control the editor from an external component        |
+   | `containerClassName` / `editorClassName`   | `string`                                                                          | Extra classes for the container and the editable area            |
+   | `placeholder`                              | `string \| ((isFocused: boolean, value: string) => string)`                       | Placeholder text                                                 |
+
+3. Extension lists - `CORE_EXTENSIONS`, `ADDITIONAL_EXTENSIONS` and the `TrailingNode` extension.
+
+4. Extending with Custom Styles
 
 ```ts
 const customEditorClassNames = getEditorClassNames({
   noBorder,
   borderOnFocus,
-  customClassName,
+  containerClassName,
 });
 ```
 
+The internal `EditorContainer` and `EditorContentWrapper` components (in `src/components/editors`) apply these classes; they are not exported from the package.
+
 ## Core features
 
 - **Content Trimming**: The Editor’s content is now automatically trimmed of empty line breaks from the start and end before submitting it to the backend. This ensures cleaner, more consistent data.
diff --git a/packages/logger/README.md b/packages/logger/README.md
index 4391b898ae3e..a88edb8e0365 100644
--- a/packages/logger/README.md
+++ b/packages/logger/README.md
@@ -2,11 +2,12 @@
 
 This package provides a logger and a request logger utility built using [Winston](https://github.com/winstonjs/winston). It offers customizable log levels using env and supports structured logging for general application logs and HTTP requests.
 
-## Features.
+## Features
 
 - Dynamic log level configuration using env.
 - Pre-configured winston logger for general usage (`logger`).
-- Request logger middleware that logs incoming request
+- Request logger middleware (`loggerMiddleware`, built on express-winston) that logs incoming requests
+- Shared Winston options (`loggerConfig`) if you need to build another logger
 
 ## Usage
 
@@ -14,18 +15,18 @@ This package provides a logger and a request logger utility built using [Winston
 
 Add this package as a dependency in package.json
 
-```typescript
-dependency: {
-    ...
-    @plane/logger":"*",
-    ...
+```json
+{
+  "dependencies": {
+    "@plane/logger": "workspace:*"
+  }
 }
 ```
 
 ### Importing the Logger
 
 ```typescript
-import { logger, requestLogger } from "@plane/logger";
+import { logger, loggerMiddleware } from "@plane/logger";
 ```
 
 ### Usage
@@ -40,13 +41,13 @@ logger.warn("This is a warning");
 logger.error("This is an error");
 ```
 
-### `requestLogger`: Request Logger Middleware
+### `loggerMiddleware`: Request Logger Middleware
 
 Use this as a middleware for incoming requests
 
 ```typescript
 const app = express();
-app.use(requestLogger);
+app.use(loggerMiddleware);
 ```
 
 ## Available Log Levels
@@ -59,10 +60,9 @@ app.use(requestLogger);
 - `debug`
 - `silly`
 
-## Log file
+## Output
 
-- Log files are stored in logs folder of current working directory. Error logs are stored in files with format `error-%DATE%.log` and combined logs are stored with format `combined-%DATE%.log`.
-- Log files have a 7 day rotation period defined.
+- Logs are written as JSON (with a timestamp) to the console (stdout). No log files are written; collect logs from the process or container output.
 
 ## Configuration
 
diff --git a/packages/tailwind-config/AGENTS.md b/packages/tailwind-config/AGENTS.md
index 57e4876ae643..e11190e372a7 100644
--- a/packages/tailwind-config/AGENTS.md
+++ b/packages/tailwind-config/AGENTS.md
@@ -4,6 +4,8 @@
 
 This guide explains the semantic design system philosophy for building consistent, maintainable UIs. The system is built on three core concepts: **Canvas**, **Surface**, and **Layer**.
 
+The tokens behind these classes come from the published `@makeplane/propel` package: `packages/tailwind-config/index.css` imports `@makeplane/propel/styles`, which defines the colors. This package only wires them into Tailwind.
+
 ## Core Concepts
 
 ### 1. Canvas (`bg-canvas`)
@@ -29,14 +31,9 @@ This guide explains the semantic design system philosophy for building consisten
 **Example**:
 
 ```tsx
-// ✅ Correct: Canvas at application root (only place it should be)
-// App.tsx or root layout
-<div className="bg-canvas min-h-screen">
-  {/* All application content goes here */}
-  <Routes>
-    <Route path="/" element={<Page />} />
-  </Routes>
-</div>;
+// ✅ Correct: Canvas is already applied once, to <body>, by @plane/tailwind-config/index.css:
+//   body { @apply font-body bg-canvas text-primary; }
+// Don't add bg-canvas anywhere else (root.tsx, layouts, pages).
 
 // ✅ Correct: Pages use surfaces, not canvas
 function Page() {
@@ -52,7 +49,7 @@ function Page() {
 <div className="bg-canvas p-4 rounded-md">{/* Card content */}</div>;
 ```
 
-### 2. Surface (`bg-surface-1`, `bg-surface-2`, `bg-surface-3`)
+### 2. Surface (`bg-surface-1`, `bg-surface-2`)
 
 **What it is**: Top-level containers that sit directly on the canvas. Surfaces never overlap each other - they are siblings in the layout hierarchy.
 
@@ -67,7 +64,6 @@ function Page() {
 
 - `bg-surface-1`: Primary surface (most common)
 - `bg-surface-2`: Secondary surface (for variation)
-- `bg-surface-3`: Tertiary surface (rare, for special cases)
 
 **Rules**:
 
@@ -152,7 +148,6 @@ function Page() {
 
 - `bg-surface-1` → use `bg-layer-1` for nested elements
 - `bg-surface-2` → use `bg-layer-2` for nested elements
-- `bg-surface-3` → use `bg-layer-3` for nested elements
 
 **Rare Exception - Visual Separation**:
 
@@ -303,14 +298,8 @@ Use `-selected` variants only when there's actual selection logic.
 ### Pattern 1: Application Root Layout
 
 ```tsx
-// ✅ Correct: Application root (only place for canvas)
-// App.tsx or root layout
-<div className="bg-canvas min-h-screen">
-  <Routes>
-    <Route path="/" element={<HomePage />} />
-    <Route path="/dashboard" element={<DashboardPage />} />
-  </Routes>
-</div>;
+// ✅ Correct: Application root - canvas comes from <body> (index.css), so the
+// root layout (app/root.tsx) and route modules add no background of their own
 
 // ✅ Correct: Individual page structure
 function HomePage() {
@@ -449,7 +438,7 @@ AND
 Is it a sibling to other containers (not nested)?
 OR
 Is this a modal/overlay on a different plane (z-index)?
-├─ YES → Use bg-surface-1 (or surface-2/3 for variation)
+├─ YES → Use bg-surface-1 (or surface-2 for variation)
 └─ NO → Continue to Layer decision
 ```
 
@@ -625,7 +614,7 @@ function Page() {
 ### Hierarchy Structure
 
 ```
-Canvas (one per page)
+Canvas (one per application, on <body>)
   └── Surface 1 (top-level container)
       └── Layer 1 (first level of depth)
           └── Layer 2 (second level)