release: v1.3.1

.claude/skills/pr-description.md

@@ -0,0 +1,58 @@
+---
+name: pr-description
+description: Generate a PR description following the project's GitHub PR template. Analyzes the current branch's changes against the base branch to produce a complete, filled-out PR description.
+user_invocable: true
+---
+
+# PR Description Generator
+
+Generate a pull request description based on the project's PR template at `.github/pull_request_template.md`.
+
+## Steps
+
+1. **Determine the base branch**: Prefer the PR's actual `baseRefName` (via `gh pr view <PR> --json baseRefName`) when a PR exists. Otherwise default by intent — feature PRs target `preview`, release PRs target `master`. If still ambiguous, ask the user.
+
+2. **Analyze changes**: Run the following to understand what changed:
+   - `git log <base>...HEAD --oneline` to see all commits on this branch
+   - `git diff <base>...HEAD --stat` to see which files changed
+   - `git diff <base>...HEAD` to read the actual diff (use `--no-color`)
+   - If the diff is very large, focus on the most important files first
+
+3. **Fill out the PR template** with the following sections:
+
+   ### Description
+
+   Write a clear, concise summary of what the PR does and why. Focus on the "what" and "why", not line-by-line changes. Mention any important implementation decisions.
+
+   ### Type of Change
+
+   Check the appropriate box(es) based on the changes:
+   - Bug fix (non-breaking change which fixes an issue)
+   - Feature (non-breaking change which adds functionality)
+   - Improvement (non-breaking change that improves existing functionality)
+   - Code refactoring
+   - Performance improvements
+   - Documentation update
+
+   ### Screenshots and Media
+
+   Leave this section for the user to fill in, preserving the existing placeholder comment from `.github/pull_request_template.md` verbatim rather than introducing different text.
+
+   ### Test Scenarios
+
+   Based on the code changes, suggest specific test scenarios that should be verified. Be concrete (e.g., "Navigate to project settings and verify the new toggle works") rather than generic.
+
+   ### References
+   - If commit messages or branch name reference a work item identifier (e.g., `WEB-1234`), include it
+   - If the user provides a linked issue, include it
+   - If Sentry issue links or IDs (e.g., `SENTRY-ABC123`, Sentry URLs) were mentioned earlier in the conversation, include them as references
+
+4. **Output format**: Print the filled-out markdown template so the user can copy it directly. Do NOT wrap it in a code fence — output the raw markdown.
+
+## Guidelines
+
+- Keep the description concise but informative
+- Use bullet points for multiple changes
+- Focus on user-facing impact, not implementation details
+- If the branch has a Plane work item ID in its name (e.g., `WEB-1234`), reference it
+- Don't fabricate test scenarios that aren't relevant to the actual changes

.claude/skills/release-notes.md

@@ -0,0 +1,147 @@
+---
+name: release-notes
+description: "Generate release notes for a Plane release PR in `makeplane/plane` (semver, e.g. `release: vX.Y.Z`). Reads PR commits, filters out noise, categorizes by conventional-commit type, optionally enriches via Plane MCP, and writes the result as the PR description."
+user_invocable: true
+---
+
+# Release Notes Generator
+
+Generate structured release notes from a Plane release PR by parsing its commit list, then update the PR description.
+
+## Versioning
+
+Plane community uses **semver** (`vX.Y.Z`, major.minor.patch) for releases.
+
+- PR title format: `release: vX.Y.Z`
+- Source branch: `canary`
+- Target branch: `master`
+
+## When to Use
+
+- User links/mentions a Plane release PR (e.g. `release: v1.3.0`) and asks for release notes
+- User asks to "create release notes" / "update PR description" for a release PR in `makeplane/plane`
+- The branch is named `canary` or `release/x.y.z` and the base is `master`
+
+## Steps
+
+### 1. Fetch commits
+
+```bash
+gh pr view <PR_NUM> --json title,body,baseRefName,headRefName,commits \
+  --jq '.commits[] | .messageHeadline + "\n---BODY---\n" + .messageBody + "\n===END==="'
+```
+
+For a quick scan first:
+
+```bash
+gh pr view <PR_NUM> --json commits \
+  --jq '.commits[] | {oid: .oid[0:10], message: .messageHeadline}'
+```
+
+### 2. Filter out noise
+
+**Always exclude** these commits — mechanical, not user-facing:
+
+| Pattern                                      | Reason         |
+| -------------------------------------------- | -------------- |
+| `fix: merge conflicts`                       | Merge artifact |
+| `Merge branch '...' of github.com:...`       | Merge artifact |
+| `Revert "..."` (when immediately re-applied) | Internal churn |
+
+### 3. Parse work item IDs
+
+Most meaningful commits begin with a Plane work item identifier in brackets:
+
+- `[WEB-XXXX]` — web/frontend product items
+- `[SILO-XXXX]` — Silo (integrations: Slack, GitHub, GitLab, Jira/Linear)
+- `[MOBILE-XXXX]`, `[API-XXXX]`, etc.
+
+Always preserve these IDs in the release notes — they let readers click through to the source ticket.
+
+### 4. (Optional) Enrich via Plane MCP
+
+For larger features where the commit headline is terse, fetch the work item:
+
+```text
+mcp__plane__retrieve_work_item_by_identifier(project_identifier="WEB", issue_identifier=6874)
+```
+
+Use the returned `name` and `description_stripped` to flesh out the bullet. Skip this for routine fixes — commit body is usually enough. Don't enrich every item (slow + work item descriptions are often empty).
+
+### 5. Categorize by conventional-commit type
+
+| Commit prefix                    | Section             |
+| -------------------------------- | ------------------- |
+| `feat:`, `feat(scope):`          | ✨ New Features     |
+| `fix:`, `fix(scope):`            | 🐛 Bug Fixes        |
+| `refactor:`                      | 🔧 Refactor & Chore |
+| `chore:`, `chore(scope):`        | 🔧 Refactor & Chore |
+| `chore(deps):`, dependabot bumps | 📦 Dependencies     |
+
+### 6. Format
+
+```markdown
+# Release vX.Y.Z
+
+## ✨ New Features
+
+- **<Short title>** — [WEB-XXXX] (#PR_NUM)
+  Optional 1–2 sentence elaboration drawn from commit body.
+
+## 🐛 Bug Fixes
+
+- **<Short title>** — [WEB-XXXX] (#PR_NUM)
+
+## 🔧 Refactor & Chore
+
+- **<Short title>** — [WEB-XXXX] (#PR_NUM)
+
+## 📦 Dependencies
+
+- Bump `<package>` X.Y.Z → A.B.C (#PR_NUM)
+```
+
+Rules:
+
+- Lead with a bold human-readable title (rewrite the commit subject if cryptic)
+- Always include the work item ID in brackets and the merge PR number in parens
+- Add a sub-line elaboration only when the commit body has substance worth surfacing (acceptance criteria, scope notes, gotchas like "behind feature flag", "requires migration", "requires Vercel setting")
+- Drop empty sections
+
+### 7. Update the PR description
+
+```bash
+gh pr edit <PR_NUM> --body "$(cat <<'EOF'
+<release notes markdown>
+EOF
+)"
+```
+
+Always use a HEREDOC with single-quoted `'EOF'` so backticks/dollars in the notes are preserved.
+
+## Quick Reference: end-to-end
+
+```bash
+PR=2498
+gh pr view $PR --json commits --jq '.commits[] | .messageHeadline + "\n---\n" + .messageBody + "\n==="' > /tmp/commits.txt
+# read /tmp/commits.txt, filter, categorize, draft notes
+gh pr edit $PR --body "$(cat <<'EOF'
+... release notes ...
+EOF
+)"
+```
+
+## Common Mistakes
+
+- **Including `fix: merge conflicts`** — merge artifact, no functional content
+- **Dropping the work item ID** — readers rely on `[WEB-XXXX]` to navigate to the ticket
+- **Over-enriching with MCP lookups** — work item descriptions are often empty; commit body is usually richer
+- **Missing the merge PR number** — always include `(#NNNN)` from the commit subject so reviewers can audit the source PR
+- **Using `--body` without HEREDOC** — backticks/dollar signs get shell-interpreted and corrupt the notes
+- **Editing the title** — release PR titles are version markers; only edit the body
+
+## Plane-Specific Conventions
+
+- Release PRs go from `canary` → `master`
+- PR title format: `release: vX.Y.Z` semver (major.minor.patch)
+- Commits coming from feature branches always carry a work item ID; commits without one are usually infra/chores

.github/workflows/codeql.yml

@@ -16,6 +16,9 @@ jobs:
       contents: read
       security-events: write
 
+    env:
+      CODEQL_ACTION_FILE_COVERAGE_ON_PRS: "false"
+
     strategy:
       fail-fast: false
       matrix:

CODEOWNERS

@@ -1 +1,8 @@
-eslint.config.mjs   @lifeiscontent
+.oxlintrc.json   @sriramveeraghanta @lifeiscontent
+.oxfmtrc.json   @sriramveeraghanta @lifeiscontent
+apps/api/           @dheeru0198 @pablohashescobar
+apps/web/           @sriramveeraghanta
+apps/space/         @sriramveeraghanta
+apps/admin/         @sriramveeraghanta
+apps/live/          @Palanikannan1437
+deployments/        @mguptahub

README.md

@@ -10,7 +10,7 @@
 <p align="center">
     <a href="https://plane.so/"><b>Website</b></a> •
     <a href="https://forum.plane.so"><b>Forum</b></a> •
-    <a href="https://twitter.com/planepowers"><b>Twitter</b></a> •
+    <a href="https://x.com/planepowers"><b>X</b></a> •
     <a href="https://docs.plane.so/"><b>Documentation</b></a>
 </p>
 

apps/admin/app/(all)/(dashboard)/general/form.tsx

@@ -16,8 +16,6 @@ import { Input, ToggleSwitch } from "@plane/ui";
 import { ControllerInput } from "@/components/common/controller-input";
 // hooks
 import { useInstance } from "@/hooks/store";
-// components
-import { IntercomConfig } from "./intercom";
 
 export interface IGeneralConfigurationForm {
   instance: IInstance;
@@ -27,14 +25,13 @@ export interface IGeneralConfigurationForm {
 export const GeneralConfigurationForm = observer(function GeneralConfigurationForm(props: IGeneralConfigurationForm) {
   const { instance, instanceAdmins } = props;
   // hooks
-  const { instanceConfigurations, updateInstanceInfo, updateInstanceConfigurations } = useInstance();
+  const { updateInstanceInfo } = useInstance();
 
   // form data
   const {
     handleSubmit,
     control,
     formState: { errors, isSubmitting },
-    watch,
   } = useForm<Partial<IInstance>>({
     defaultValues: {
       instance_name: instance?.instance_name,
@@ -45,17 +42,6 @@ export const GeneralConfigurationForm = observer(function GeneralConfigurationFo
   const onSubmit = async (formData: Partial<IInstance>) => {
     const payload: Partial<IInstance> = { ...formData };
 
-    // update the intercom configuration
-    const isIntercomEnabled =
-      instanceConfigurations?.find((config) => config.key === "IS_INTERCOM_ENABLED")?.value === "1";
-    if (!payload.is_telemetry_enabled && isIntercomEnabled) {
-      try {
-        await updateInstanceConfigurations({ IS_INTERCOM_ENABLED: "0" });
-      } catch (error) {
-        console.error(error);
-      }
-    }
-
     await updateInstanceInfo(payload)
       .then(() =>
         setToast({
@@ -112,8 +98,7 @@ export const GeneralConfigurationForm = observer(function GeneralConfigurationFo
       </div>
 
       <div className="space-y-6">
-        <div className="border-b border-subtle pb-1.5 text-16 font-medium text-primary">Chat + telemetry</div>
-        <IntercomConfig isTelemetryEnabled={watch("is_telemetry_enabled") ?? false} />
+        <div className="border-b border-subtle pb-1.5 text-16 font-medium text-primary">Telemetry</div>
         <div className="flex items-center gap-14">
           <div className="flex grow items-center gap-4">
             <div className="shrink-0">

apps/admin/package.json

@@ -1,6 +1,6 @@
 {
   "name": "admin",
-  "version": "1.3.0",
+  "version": "1.3.1",
   "private": true,
   "description": "Admin UI for Plane",
   "license": "AGPL-3.0",

apps/api/package.json

@@ -1,6 +1,6 @@
 {
   "name": "plane-api",
-  "version": "1.3.0",
+  "version": "1.3.1",
   "private": true,
   "description": "API server powering Plane's backend",
   "license": "AGPL-3.0"