{"owner":"nicolargo","repo":"glances","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["CLAUDE.md"],"skills":{"CLAUDE.md":"# CLAUDE.md — Glances Maintainer Context\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n\n```md\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n## Additionnal context\n\n### Tech stack\n\n| Layer | Technology |\n| --- | --- |\n| Backend | Python, psutil, FastAPI (REST API), curses (TUI) |\n| Frontend | Vue.js, Bootstrap 5, SCSS |\n| Export plugins | InfluxDB, MongoDB, MQTT, DuckDB, and others |\n| Infrastructure | GitHub Actions, Helm/Kubernetes, Snap (snapcraft) |\n| LLM abstraction | LiteLLM (multi-provider) |\n| GPU/NPU monitoring | pynvml, sysfs/debugfs |\n\n### Code principles\n\n#### Exception handling for Snap confinement\n\nWrap the `open()` call inside `try/except`, not just the `read()`. Snap's strict\nconfinement blocks host file access at the open stage, not the read stage.\n\n### Security\n\nGlances runs unauthenticated by default — this is intentional and documented.\nMost users deploy on private networks for personal use. See global CLAUDE.md\nfor the general OSS security philosophy (4 rules).\n\n#### Sensitive endpoints\n\n- `/api/4/config` and `/api/4/args` — never expose credentials in plain text\n  (InfluxDB passwords, MongoDB tokens, MQTT passphrases, SSL key paths, etc.)\n  for unauthenticated access. Use the conditional `as_dict_secure()` method,\n  applied when `self.args.password` is `False`.\n- CORS: `allow_origins=[\"*\"]` + `allow_credentials=True` is invalid per the\n  CORS spec and reflected by Starlette. Default: `allow_credentials=False`.\n- DNS rebinding: `TrustedHostMiddleware` via `webui_allowed_hosts` (optional).\n  The MCP endpoint is already protected via `mcp_allowed_hosts` +\n  `TransportSecuritySettings` in `glances/outputs/glances_mcp.py`.\n\n### Contribution management\n\n#### Before merging a PR\n\n- [ ] The code is actively used (no dead code)\n- [ ] Existing tests pass\n- [ ] New behaviour is covered by tests\n- [ ] New configuration keys are documented\n- [ ] Breaking changes are identified and documented\n- [ ] The PR targets the correct branch\n- [ ] Code should be formated and linted (make lint && make format)\n\n#### Glances-specific output formats\n\n| Deliverable | Format |\n| --- | --- |\n| Changelog entry | `.rst` file following the `NEWS.rst` format |\n| Helm Chart | `.tgz` archive or structured directory |\n\n### UI / TUI\n\n#### Web UI\n\nStack: Vue.js + Bootstrap 5 + SCSS.\n\nDesign principles:\n\n- Strict typographic consistency across all plugins (size, weight, opacity,\n  letter-spacing).\n- Pixel-perfect sparkline alignment (CSS grid, fixed row heights).\n- Footer = vertical alert list (up to 10 entries), not a single horizontal row.\n- No gauges — prefer sparklines with an inline current value.\n\n#### TUI (curses)\n\n- 256-colour system with automatic fallback for limited terminals.\n- Lightweight hierarchical separators for information density.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n"},"files":{"CLAUDE.md":"# CLAUDE.md — Glances Maintainer Context\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n\n```md\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n## Additionnal context\n\n### Tech stack\n\n| Layer | Technology |\n| --- | --- |\n| Backend | Python, psutil, FastAPI (REST API), curses (TUI) |\n| Frontend | Vue.js, Bootstrap 5, SCSS |\n| Export plugins | InfluxDB, MongoDB, MQTT, DuckDB, and others |\n| Infrastructure | GitHub Actions, Helm/Kubernetes, Snap (snapcraft) |\n| LLM abstraction | LiteLLM (multi-provider) |\n| GPU/NPU monitoring | pynvml, sysfs/debugfs |\n\n### Code principles\n\n#### Exception handling for Snap confinement\n\nWrap the `open()` call inside `try/except`, not just the `read()`. Snap's strict\nconfinement blocks host file access at the open stage, not the read stage.\n\n### Security\n\nGlances runs unauthenticated by default — this is intentional and documented.\nMost users deploy on private networks for personal use. See global CLAUDE.md\nfor the general OSS security philosophy (4 rules).\n\n#### Sensitive endpoints\n\n- `/api/4/config` and `/api/4/args` — never expose credentials in plain text\n  (InfluxDB passwords, MongoDB tokens, MQTT passphrases, SSL key paths, etc.)\n  for unauthenticated access. Use the conditional `as_dict_secure()` method,\n  applied when `self.args.password` is `False`.\n- CORS: `allow_origins=[\"*\"]` + `allow_credentials=True` is invalid per the\n  CORS spec and reflected by Starlette. Default: `allow_credentials=False`.\n- DNS rebinding: `TrustedHostMiddleware` via `webui_allowed_hosts` (optional).\n  The MCP endpoint is already protected via `mcp_allowed_hosts` +\n  `TransportSecuritySettings` in `glances/outputs/glances_mcp.py`.\n\n### Contribution management\n\n#### Before merging a PR\n\n- [ ] The code is actively used (no dead code)\n- [ ] Existing tests pass\n- [ ] New behaviour is covered by tests\n- [ ] New configuration keys are documented\n- [ ] Breaking changes are identified and documented\n- [ ] The PR targets the correct branch\n- [ ] Code should be formated and linted (make lint && make format)\n\n#### Glances-specific output formats\n\n| Deliverable | Format |\n| --- | --- |\n| Changelog entry | `.rst` file following the `NEWS.rst` format |\n| Helm Chart | `.tgz` archive or structured directory |\n\n### UI / TUI\n\n#### Web UI\n\nStack: Vue.js + Bootstrap 5 + SCSS.\n\nDesign principles:\n\n- Strict typographic consistency across all plugins (size, weight, opacity,\n  letter-spacing).\n- Pixel-perfect sparkline alignment (CSS grid, fixed row heights).\n- Footer = vertical alert list (up to 10 entries), not a single horizontal row.\n- No gauges — prefer sparklines with an inline current value.\n\n#### TUI (curses)\n\n- 256-colour system with automatic fallback for limited terminals.\n- Lightweight hierarchical separators for information density.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n"},"items":[{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md — Glances Maintainer Context\n\nBehavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.\n\n## 1. Think Before Coding\n\n**Don't assume. Don't hide confusion. Surface tradeoffs.**\n\nBefore implementing:\n\n- State your assumptions explicitly. If uncertain, ask.\n- If multiple interpretations exist, present them - don't pick silently.\n- If a simpler approach exists, say so. Push back when warranted.\n- If something is unclear, stop. Name what's confusing. Ask.\n\n## 2. Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes, simplify.\n\n## 3. Surgical Changes\n\n**Touch only what you must. Clean up only your own mess.**\n\nWhen editing existing code:\n\n- Don't \"improve\" adjacent code, comments, or formatting.\n- Don't refactor things that aren't broken.\n- Match existing style, even if you'd do it differently.\n- If you notice unrelated dead code, mention it - don't delete it.\n\nWhen your changes create orphans:\n\n- Remove imports/variables/functions that YOUR changes made unused.\n- Don't remove pre-existing dead code unless asked.\n\nThe test: Every changed line should trace directly to the user's request.\n\n## 4. Goal-Driven Execution\n\n**Define success criteria. Loop until verified.**\n\nTransform tasks into verifiable goals:\n\n- \"Add validation\" → \"Write tests for invalid inputs, then make them pass\"\n- \"Fix the bug\" → \"Write a test that reproduces it, then make it pass\"\n- \"Refactor X\" → \"Ensure tests pass before and after\"\n\nFor multi-step tasks, state a brief plan:\n\n```md\n1. [Step] → verify: [check]\n2. [Step] → verify: [check]\n3. [Step] → verify: [check]\n```\n\nStrong success criteria let you loop independently. Weak criteria (\"make it work\") require constant clarification.\n\n## Additionnal context\n\n### Tech stack\n\n| Layer | Technology |\n| --- | --- |\n| Backend | Python, psutil, FastAPI (REST API), curses (TUI) |\n| Frontend | Vue.js, Bootstrap 5, SCSS |\n| Export plugins | InfluxDB, MongoDB, MQTT, DuckDB, and others |\n| Infrastructure | GitHub Actions, Helm/Kubernetes, Snap (snapcraft) |\n| LLM abstraction | LiteLLM (multi-provider) |\n| GPU/NPU monitoring | pynvml, sysfs/debugfs |\n\n### Code principles\n\n#### Exception handling for Snap confinement\n\nWrap the `open()` call inside `try/except`, not just the `read()`. Snap's strict\nconfinement blocks host file access at the open stage, not the read stage.\n\n### Security\n\nGlances runs unauthenticated by default — this is intentional and documented.\nMost users deploy on private networks for personal use. See global CLAUDE.md\nfor the general OSS security philosophy (4 rules).\n\n#### Sensitive endpoints\n\n- `/api/4/config` and `/api/4/args` — never expose credentials in plain text\n  (InfluxDB passwords, MongoDB tokens, MQTT passphrases, SSL key paths, etc.)\n  for unauthenticated access. Use the conditional `as_dict_secure()` method,\n  applied when `self.args.password` is `False`.\n- CORS: `allow_origins=[\"*\"]` + `allow_credentials=True` is invalid per the\n  CORS spec and reflected by Starlette. Default: `allow_credentials=False`.\n- DNS rebinding: `TrustedHostMiddleware` via `webui_allowed_hosts` (optional).\n  The MCP endpoint is already protected via `mcp_allowed_hosts` +\n  `TransportSecuritySettings` in `glances/outputs/glances_mcp.py`.\n\n### Contribution management\n\n#### Before merging a PR\n\n- [ ] The code is actively used (no dead code)\n- [ ] Existing tests pass\n- [ ] New behaviour is covered by tests\n- [ ] New configuration keys are documented\n- [ ] Breaking changes are identified and documented\n- [ ] The PR targets the correct branch\n- [ ] Code should be formated and linted (make lint && make format)\n\n#### Glances-specific output formats\n\n| Deliverable | Format |\n| --- | --- |\n| Changelog entry | `.rst` file following the `NEWS.rst` format |\n| Helm Chart | `.tgz` archive or structured directory |\n\n### UI / TUI\n\n#### Web UI\n\nStack: Vue.js + Bootstrap 5 + SCSS.\n\nDesign principles:\n\n- Strict typographic consistency across all plugins (size, weight, opacity,\n  letter-spacing).\n- Pixel-perfect sparkline alignment (CSS grid, fixed row heights).\n- Footer = vertical alert list (up to 10 entries), not a single horizontal row.\n- No gauges — prefer sparklines with an inline current value.\n\n#### TUI (curses)\n\n- 256-colour system with automatic fallback for limited terminals.\n- Lightweight hierarchical separators for information density.\n\n---\n\n**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.\n","category":"root","tokens":1232}]}