From 66db9a4b57d334cc608fbc6dfa07ddb534dd2cae Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Thu, 13 Aug 2026 09:04:36 +0000 Subject: [PATCH] chore: add missing pr-analysis and logging-standards skills Co-authored-by: jokob-sk <96159884+jokob-sk@users.noreply.github.com> --- .gemini/skills/logging-standards/SKILL.md | 67 +++++++++++++++++++++++ .gemini/skills/pr-analysis/SKILL.md | 52 ++++++++++++++++++ .gemini/skills/skills-index/SKILL.md | 2 + .github/skills/logging-standards/SKILL.md | 67 +++++++++++++++++++++++ .github/skills/pr-analysis/SKILL.md | 53 ++++++++++++++++++ .github/skills/skills-overview/SKILL.md | 2 + 6 files changed, 243 insertions(+) create mode 100644 .gemini/skills/logging-standards/SKILL.md create mode 100644 .gemini/skills/pr-analysis/SKILL.md create mode 100644 .github/skills/logging-standards/SKILL.md create mode 100644 .github/skills/pr-analysis/SKILL.md diff --git a/.gemini/skills/logging-standards/SKILL.md b/.gemini/skills/logging-standards/SKILL.md new file mode 100644 index 00000000..8395586b --- /dev/null +++ b/.gemini/skills/logging-standards/SKILL.md @@ -0,0 +1,67 @@ +--- +name: logging-standards +description: Logging conventions for NetAlertX backend Python code. Use this when adding, modifying, or reviewing log statements. +--- + +# Logging Standards + +## Import + +```python +from logger import mylog +``` + +Never import `logging` directly in application code. Use `mylog` exclusively. + +## Function Signature + +```python +mylog(level, message_or_list) +``` + +`message_or_list` can be a plain string or a list of values — the logger joins them with spaces. + +## Log Levels + +Levels from least to most verbose (higher number = more output): + +| Level | Numeric | When to use | +|-------|---------|-------------| +| `"none"` | 0 | Always printed regardless of user setting. Reserve for startup, fatal errors, and one-time permission checks. | +| `"minimal"` | 1 | Important state transitions visible by default (scan start/end, plugin finish, restart). | +| `"verbose"` | 2 | Informational progress — what the system is doing without clutter (e.g. "No changes to report"). | +| `"debug"` | 3 | Developer-level detail — loop decisions, branch taken, counts. | +| `"trace"` | 4 | Granular per-item tracing — individual device rows, SQL queries, raw values. | + +## Message Format + +Prefix every message with a `[Module]` tag matching the file/function context: + +```python +mylog("debug", [f"[device_handling] Processing MAC: {mac}"]) +mylog("verbose", ["[Scan] Scan complete — devices updated:", count]) +``` + +Use `f-strings` inside a list element, not string concatenation: + +```python +# Correct +mylog("debug", [f"[NIC] parent={parent_mac} nic_online={nic_online}"]) + +# Avoid +mylog("debug", "[NIC] parent=" + parent_mac + " nic_online=" + str(nic_online)) +``` + +## Timestamp + +`mylog` / `file_print` prepend the current local-timezone time automatically via `timeNowTZ`. Do **not** add a timestamp manually inside the message. + +## What NOT to Log + +- Do not log raw user input without sanitization. +- Do not log full SQL query strings at `"none"` or `"minimal"` — use `"trace"` at most. +- Do not use `print()` in server code — use `mylog`. `file_print` is an internal helper; do not call it directly. + +## Log File Location + +Written to `{logPath}/app.log` (`logPath` from `const.py` → `/tmp/logs` at runtime). Do not hardcode this path. diff --git a/.gemini/skills/pr-analysis/SKILL.md b/.gemini/skills/pr-analysis/SKILL.md new file mode 100644 index 00000000..26dd7793 --- /dev/null +++ b/.gemini/skills/pr-analysis/SKILL.md @@ -0,0 +1,52 @@ +--- +name: pr-analysis +description: How to analyze and respond to GitHub PR review comments in NetAlertX. Use this whenever you are addressing PR feedback, review threads, or inline code comments. +--- + +# PR Analysis + +## Before Acting on Any PR Comment + +1. Load `code-standards` skill — all code changes must comply with it before replying. +2. Load `testing-workflow` skill — any test additions or changes must follow it. +3. Load any domain-specific skill relevant to the files being changed (e.g. `database-patterns` for DB writes, `settings` for config). + +## Comment Classification + +For each comment, determine: + +| Type | Action | +|------|--------| +| Request for code change | Make the change, validate it, then reply with the short commit hash | +| Question about code | Reply with a concise answer (no restatement of the question) | +| Suggestion / feedback | Decide if it is actionable. If yes, act and reply. If not, do not reply. | +| General / praise | Do not reply. | + +## Acting on Comments — Step by Step + +1. **Identify all actionable comments** before touching any file. +2. **Load relevant skills** to understand conventions that apply. +3. **Prepare a plan** — list each file and the exact change required. +4. **Make changes one comment at a time** — keep commits focused. +5. **Run targeted tests** after each change (`testing-workflow` skill). +6. **Reply** only after the commit is pushed. Include the short SHA. + +## Reply Guidelines + +- Be concise. Do not summarize or restate the original comment. +- State what was done and (optionally) why. +- Include the short commit hash when relevant. +- Do not thank or compliment the reviewer. + +## What to Check After Every Batch of Changes + +- All MACs are lowercase everywhere (code-standards). +- No mocks or DB helpers are re-defined locally — use `test/db_test_helpers.py` (code-standards). +- No inline imports — all imports at the top of the file (code-standards). +- Tests live under a subdirectory of `test/` matching the source path, not in `test/` root (code-standards). + +## Stacked / Base-Branch Issues + +When a PR targets a non-default branch (e.g. `next_release`): +- Do **not** retarget the branch yourself; note it in a reply so the author can do it from the GitHub UI. +- Check CI failures on the **base branch** first before checking your branch. diff --git a/.gemini/skills/skills-index/SKILL.md b/.gemini/skills/skills-index/SKILL.md index d5272a5d..ea21fd9c 100644 --- a/.gemini/skills/skills-index/SKILL.md +++ b/.gemini/skills/skills-index/SKILL.md @@ -24,6 +24,8 @@ Skills with the same purpose exist in both, sometimes under different names and | Project navigation | `project-navigation` | `project-navigation` | Copilot version has full path tables and env vars; Gemini version is a brief reference | | Plugin dev | `plugin-development` | `plugin-run-development` | Copilot version is comprehensive (data contract, phases, formats); Gemini version is a brief checklist pointing to `docs/PLUGINS_DEV.md` | | Devcontainer | `devcontainer-management` | `devcontainer-services` + `devcontainer-setup` + `devcontainer-configs` | Gemini combines into one (uses `docker exec`); Copilot splits into 3 focused skills | +| PR review | `pr-analysis` | `pr-analysis` | How to classify and respond to PR comments; pre-flight skill loading checklist | +| Logging | `logging-standards` | `logging-standards` | `mylog` levels, message format, what not to log | --- diff --git a/.github/skills/logging-standards/SKILL.md b/.github/skills/logging-standards/SKILL.md new file mode 100644 index 00000000..8cbc834c --- /dev/null +++ b/.github/skills/logging-standards/SKILL.md @@ -0,0 +1,67 @@ +--- +name: netalertx-logging-standards +description: Logging conventions for NetAlertX backend Python code. Use this when adding, modifying, or reviewing log statements. +--- + +# Logging Standards + +## Import + +```python +from logger import mylog +``` + +Never import `logging` directly in application code. Use `mylog` exclusively. + +## Function Signature + +```python +mylog(level, message_or_list) +``` + +`message_or_list` can be a plain string or a list of values — the logger joins them with spaces. + +## Log Levels + +Levels from least to most verbose (higher number = more output): + +| Level | Numeric | When to use | +|-------|---------|-------------| +| `"none"` | 0 | Always printed regardless of user setting. Reserve for startup, fatal errors, and one-time permission checks. | +| `"minimal"` | 1 | Important state transitions visible by default (scan start/end, plugin finish, restart). | +| `"verbose"` | 2 | Informational progress — what the system is doing without clutter (e.g. "No changes to report"). | +| `"debug"` | 3 | Developer-level detail — loop decisions, branch taken, counts. | +| `"trace"` | 4 | Granular per-item tracing — individual device rows, SQL queries, raw values. | + +## Message Format + +Prefix every message with a `[Module]` tag matching the file/function context: + +```python +mylog("debug", [f"[device_handling] Processing MAC: {mac}"]) +mylog("verbose", ["[Scan] Scan complete — devices updated:", count]) +``` + +Use `f-strings` inside a list element, not string concatenation: + +```python +# Correct +mylog("debug", [f"[NIC] parent={parent_mac} nic_online={nic_online}"]) + +# Avoid +mylog("debug", "[NIC] parent=" + parent_mac + " nic_online=" + str(nic_online)) +``` + +## Timestamp + +`mylog` / `file_print` prepend the current local-timezone time automatically via `timeNowTZ`. Do **not** add a timestamp manually inside the message. + +## What NOT to Log + +- Do not log raw user input without sanitization. +- Do not log full SQL query strings at `"none"` or `"minimal"` — use `"trace"` at most. +- Do not use `print()` in server code — use `mylog`. `file_print` is an internal helper; do not call it directly. + +## Log File Location + +Written to `{logPath}/app.log` (`logPath` from `const.py` → `/tmp/logs` at runtime). Do not hardcode this path. diff --git a/.github/skills/pr-analysis/SKILL.md b/.github/skills/pr-analysis/SKILL.md new file mode 100644 index 00000000..bea79ca5 --- /dev/null +++ b/.github/skills/pr-analysis/SKILL.md @@ -0,0 +1,53 @@ +--- +name: netalertx-pr-analysis +description: How to analyze and respond to GitHub PR review comments in NetAlertX. Use this whenever you are addressing PR feedback, review threads, or inline code comments. +--- + +# PR Analysis + +## Before Acting on Any PR Comment + +1. Load `code-standards` skill — all code changes must comply with it before replying. +2. Load `testing-workflow` skill — any test additions or changes must follow it. +3. Load any domain-specific skill relevant to the files being changed (e.g. `database-patterns` for DB writes, `settings-management` for config). + +## Comment Classification + +For each comment, determine: + +| Type | Action | +|------|--------| +| Request for code change | Make the change, validate it, then reply with the short commit hash | +| Question about code | Reply with a concise answer (no restatement of the question) | +| Suggestion / feedback | Decide if it is actionable. If yes, act and reply. If not, do not reply. | +| General / praise | Do not reply. | + +## Acting on Comments — Step by Step + +1. **Identify all actionable comments** before touching any file. +2. **Load relevant skills** to understand conventions that apply. +3. **Prepare a plan** — list each file and the exact change required. +4. **Make changes one comment at a time** — keep commits focused. +5. **Run targeted tests** after each change (`testing-workflow` skill). +6. **Reply** only after the commit is pushed via `report_progress`. Include the short SHA. + +## Reply Guidelines + +- Be concise. Do not summarize or restate the original comment. +- State what was done and (optionally) why. +- Include the short commit hash when relevant. +- Do not thank or compliment the reviewer. + +## What to Check After Every Batch of Changes + +- All MACs are lowercase everywhere (code-standards). +- No mocks or DB helpers are re-defined locally — use `test/db_test_helpers.py` (code-standards). +- No inline imports — all imports at the top of the file (code-standards). +- Tests live under a subdirectory of `test/` matching the source path, not in `test/` root (code-standards). +- Secret scan (`runtime-tools-secret_scanning`) before committing. + +## Stacked / Base-Branch Issues + +When a PR targets a non-default branch (e.g. `next_release`): +- Do **not** retarget the branch yourself; note it in a reply so the author can do it from the GitHub UI. +- Check CI failures on the **base branch** first before checking your branch. diff --git a/.github/skills/skills-overview/SKILL.md b/.github/skills/skills-overview/SKILL.md index f526459e..e02b5f96 100644 --- a/.github/skills/skills-overview/SKILL.md +++ b/.github/skills/skills-overview/SKILL.md @@ -24,6 +24,8 @@ Skills with the same purpose exist in both, sometimes under different names and | Project navigation | `project-navigation` | `project-navigation` | Copilot version has full path tables and env vars; Gemini version is a brief reference | | Plugin dev | `plugin-run-development` | `plugin-development` | Copilot version is comprehensive (data contract, phases, formats); Gemini version is a brief checklist pointing to `docs/PLUGINS_DEV.md` | | Devcontainer | `devcontainer-services` + `devcontainer-setup` + `devcontainer-configs` | `devcontainer-management` | Copilot splits into 3 focused skills; Gemini combines into one (uses `docker exec`) | +| PR review | `pr-analysis` | `pr-analysis` | How to classify and respond to PR comments; pre-flight skill loading checklist | +| Logging | `logging-standards` | `logging-standards` | `mylog` levels, message format, what not to log | ---