From 3bf10f83784aa65cbf1d0a9dd14caae4bc0e4566 Mon Sep 17 00:00:00 2001 From: jokob-sk Date: Fri, 18 Sep 2026 08:20:31 +1000 Subject: [PATCH] DOCS+BE: skill updates, write_notifications fix #1793 --- .claude/skills/git-workflow/SKILL.md | 20 ++++++++++++++++++++ .gemini/skills/git-workflow/SKILL.md | 20 ++++++++++++++++++++ .github/skills/git-workflow/SKILL.md | 20 ++++++++++++++++++++ server/api_server/api_server_start.py | 14 +++++--------- 4 files changed, 65 insertions(+), 9 deletions(-) create mode 100644 .claude/skills/git-workflow/SKILL.md create mode 100644 .gemini/skills/git-workflow/SKILL.md create mode 100644 .github/skills/git-workflow/SKILL.md diff --git a/.claude/skills/git-workflow/SKILL.md b/.claude/skills/git-workflow/SKILL.md new file mode 100644 index 00000000..505950e1 --- /dev/null +++ b/.claude/skills/git-workflow/SKILL.md @@ -0,0 +1,20 @@ +--- +name: git-workflow +description: Read before running any git command that changes branch state (checkout -b, branch, push) in this repo. The default workflow is commit-and-push directly to next_release, not a feature-branch/PR flow - never create a branch without asking first. +--- + +# Git Workflow + +## Never create a branch without asking first + +Don't run `git checkout -b `, `git branch `, or anything else that creates a new branch, unless the user has explicitly said to. This applies even when a task sounds like it implies a branch-and-PR flow (e.g. "prep a PR") — ask first rather than assuming that's the intended workflow here. + +**Why:** this repo's working tree is not necessarily an isolated checkout. The user may have their own terminal open on the exact same repo (e.g. a NAS/server shell alongside this session's working directory) at the same time. Switching branches changes shared repository state — a `git checkout -b` run from one place silently changes what `git push`/`git status` does from every other place touching the same repo, which has caused real, confusing failures (a `git push` from the user's own terminal failing with "no upstream branch" because this assistant had switched branches without saying so). + +## Default: commit and push directly to `next_release` + +Absent other instructions, work lands on `next_release` directly — commit there, `git push` targets `origin next_release`. Don't invent a feature-branch/PR workflow unless asked for one. + +## Before any git command that changes shared state + +Run `git status` and `git branch --show-current` first, and don't assume the branch you last left the repo on is still checked out — another process/terminal may have changed it. diff --git a/.gemini/skills/git-workflow/SKILL.md b/.gemini/skills/git-workflow/SKILL.md new file mode 100644 index 00000000..505950e1 --- /dev/null +++ b/.gemini/skills/git-workflow/SKILL.md @@ -0,0 +1,20 @@ +--- +name: git-workflow +description: Read before running any git command that changes branch state (checkout -b, branch, push) in this repo. The default workflow is commit-and-push directly to next_release, not a feature-branch/PR flow - never create a branch without asking first. +--- + +# Git Workflow + +## Never create a branch without asking first + +Don't run `git checkout -b `, `git branch `, or anything else that creates a new branch, unless the user has explicitly said to. This applies even when a task sounds like it implies a branch-and-PR flow (e.g. "prep a PR") — ask first rather than assuming that's the intended workflow here. + +**Why:** this repo's working tree is not necessarily an isolated checkout. The user may have their own terminal open on the exact same repo (e.g. a NAS/server shell alongside this session's working directory) at the same time. Switching branches changes shared repository state — a `git checkout -b` run from one place silently changes what `git push`/`git status` does from every other place touching the same repo, which has caused real, confusing failures (a `git push` from the user's own terminal failing with "no upstream branch" because this assistant had switched branches without saying so). + +## Default: commit and push directly to `next_release` + +Absent other instructions, work lands on `next_release` directly — commit there, `git push` targets `origin next_release`. Don't invent a feature-branch/PR workflow unless asked for one. + +## Before any git command that changes shared state + +Run `git status` and `git branch --show-current` first, and don't assume the branch you last left the repo on is still checked out — another process/terminal may have changed it. diff --git a/.github/skills/git-workflow/SKILL.md b/.github/skills/git-workflow/SKILL.md new file mode 100644 index 00000000..f7cb1906 --- /dev/null +++ b/.github/skills/git-workflow/SKILL.md @@ -0,0 +1,20 @@ +--- +name: netalertx-git-workflow +description: Read before running any git command that changes branch state (checkout -b, branch, push) in this repo. The default workflow is commit-and-push directly to next_release, not a feature-branch/PR flow - never create a branch without asking first. +--- + +# Git Workflow + +## Never create a branch without asking first + +Don't run `git checkout -b `, `git branch `, or anything else that creates a new branch, unless the user has explicitly said to. This applies even when a task sounds like it implies a branch-and-PR flow (e.g. "prep a PR") — ask first rather than assuming that's the intended workflow here. + +**Why:** this repo's working tree is not necessarily an isolated checkout. The user may have their own terminal open on the exact same repo (e.g. a NAS/server shell alongside this session's working directory) at the same time. Switching branches changes shared repository state — a `git checkout -b` run from one place silently changes what `git push`/`git status` does from every other place touching the same repo, which has caused real, confusing failures (a `git push` from the user's own terminal failing with "no upstream branch" because this assistant had switched branches without saying so). + +## Default: commit and push directly to `next_release` + +Absent other instructions, work lands on `next_release` directly — commit there, `git push` targets `origin next_release`. Don't invent a feature-branch/PR workflow unless asked for one. + +## Before any git command that changes shared state + +Run `git status` and `git branch --show-current` first, and don't assume the branch you last left the repo on is still checked out — another process/terminal may have changed it. diff --git a/server/api_server/api_server_start.py b/server/api_server/api_server_start.py index d55dfc53..c49f05db 100755 --- a/server/api_server/api_server_start.py +++ b/server/api_server/api_server_start.py @@ -1909,15 +1909,11 @@ def metrics(payload=None): tags=["messaging"], auth_callable=is_authorized ) -def api_write_notification(payload=None): - data = request.json or {} - content = data.get("content") - level = data.get("level", "alert") - - if not content: - return jsonify({"success": False, "message": "ERROR: Missing parameters", "error": "Missing content"}), 400 - - write_notification(content, level) +def api_write_notification(payload: CreateNotificationRequest = None): + # Use the validated payload, not the raw request body - CreateNotificationRequest's + # truncate_content validator runs against payload.content; re-reading request.json + # directly would silently bypass it and store the untruncated original. + write_notification(payload.content, payload.level) return jsonify({"success": True})