// Add a new monitoring command to the vscode-sfdx-hardis VS Code extension. Use when the user asks to add, register, or wire up a monitoring command (sf hardis:org:monitor:* or sf hardis:org:diagnose:* shown in the Org Monitoring menu and Monitoring Config Workbench).
| name | monitoring |
| description | Add a new monitoring command to the vscode-sfdx-hardis VS Code extension. Use when the user asks to add, register, or wire up a monitoring command (sf hardis:org:monitor:* or sf hardis:org:diagnose:* shown in the Org Monitoring menu and Monitoring Config Workbench). |
| compatibility | Designed for Claude Code (or similar products) |
| metadata | {"author":"cloudity","version":"1.0"} |
Add a new monitoring command to the extension so it shows up in the Org Monitoring tree menu, the Org Monitoring home LWC (manual-run cards), and the Monitoring Config Workbench (frequency + per-channel notification thresholds).
The canonical list of monitoring commands and notification types lives in the sfdx-hardis CLI plugin (external to this repo), exposed via sf hardis:config:monitoring-defaults --json. Both the Monitoring Config Workbench and the Org Monitoring home LWC fetch that catalog dynamically (fetchMonitoringCatalog() in src/utils/monitoringConfigUtils.ts) and render their content from monitoringCommands[], notificationConfig[], and categories[] — no hardcoding of the command list in this repo.
Catalog caching:
cacheExpiration: 1000 * 60 * 60 * 24 * 7).clearMonitoringCatalogCache() and re-fetches, so users can pull in new CLI commands without restarting VS Code.What this repo still needs to do per new monitoring command:
What this repo does not need to do per new monitoring command:
orgMonitoring.js / orgMonitoring.html for the manual-run card — the card is generated automatically from the CLI catalog entry's title, description, command, and category.runCommandLabel key that already exists in all 9 locales.If the command does not appear in the Org Monitoring home or the Config Workbench, the CLI catalog is the place to look — not this repo.
The CLI payload (sf hardis:config:monitoring-defaults --json) is split into two parallel arrays — they are surfaced differently and must not be mixed up:
{
"monitoringCommands": [{ "key": "...", "command": "sf hardis:...", "frequency": "daily", "category": "orgActivity", "notificationTypes": ["APEX_ERROR", "FLOW_ERROR"] }, ...],
"notificationConfig": [
{ "key": "APEX_ERROR", "category": "orgActivity",
"notifications": { "messaging": "warning", "email": "error", "api": "log" },
"availableThresholds": ["error", "warning", "success", "off"] } // severities this type can emit, last is always "off"
],
"categories": [{ "key": "orgActivity", "title": "Org Activity", "order": 1 }, ...],
"options": { "frequencies": [...], "frequencyDays": [...], "thresholds": [...], "channels": [...] }
}
notificationConfig[].availableThresholds is the per-type allow-list driving the threshold dropdowns in the Workbench. Always use it as the option source for messaging / email / api selectors, not the global options.thresholds. When a saved user override under notificationConfig: in .sfdx-hardis.yml falls outside this list, the row renders a warning icon — the override is preserved but it behaves as off at runtime. If availableThresholds is missing from a payload (older CLI), monitoringConfig.js falls back to options.thresholds.
| List | Carries | Org Monitoring home (Run cards) | Monitoring Config Workbench |
|---|---|---|---|
monitoringCommands[] | command, frequency, notificationTypes[] (cross-refs) | Shown — user can launch it. Frequency is metadata only here. | Shown — frequency editable. No threshold editors on the command row itself. Each command expands into sub-rows for the notification types it emits. |
notificationConfig[] | notifications.{messaging,email,api} thresholds | Hidden — no command, not runnable. | Sub-rows beneath a command (when referenced via notificationTypes) OR a final Standalone notifications section (when referenced by no command). |
Rules:
orgMonitoring.js's categorySections iterates catalog.monitoringCommands directly and requires entry.command to be truthy — there's nothing else to filter.monitoringConfig.js (rowsByCategory()) iterates catalog.monitoringCommands per category and attaches child rows by looking up each key in notificationConfig[]. Any notificationConfig entry never referenced by notificationTypes becomes a standalone row..sfdx-hardis.yml:
monitoringCommands: — frequency, frequencyDay, frequencyDayOfMonth, custom commands, optional override notificationTypes:.notificationConfig: — notifications.{messaging,email,api} thresholds and email recipients, keyed by notification-type key.monitoringCommands: anymore. The save path enforces this; cleanForSave() in monitoringConfig.js outputs the two arrays separately.notificationConfig[] with a category reference. Either reference it from a command via notificationTypes (it will appear as a sub-row under that command) or leave it unreferenced (it will appear in the Standalone notifications section).Confirm the CLI side first. Before editing anything here, verify the command is published in sf hardis:config:monitoring-defaults --json output (under monitoringCommands[].key / monitoringCommands[].command). For a new notification type, verify it lives under notificationConfig[]. If it's not there yet, the Workbench will not pick it up — flag this to the user and stop, unless they explicitly want only the tree-menu entry.
Register the command in the Org Monitoring tree menu. Edit src/hardis-commands-provider.ts, in the org-monitoring topic block (around lines 611-770 — look for id: "org-monitoring"). Add a new entry following the existing pattern:
{
id: "hardis:org:monitor:<name>", // or hardis:org:diagnose:<name>
label: t("<labelKey>"),
tooltip: t("<tooltipKey>"),
command: "sf hardis:org:monitor:<name>", // or sf hardis:org:diagnose:<name>
helpUrl: DOCSITE_URL + "/hardis/org/monitor/<name>/",
},
Notes:
id and command must match the CLI command exactly (use sf, never legacy sfdx).requiresProject: true only if the command needs a local SFDX project (e.g. test, lint, deploy-related). Pure org-side diagnostics usually omit it.helpUrl follows https://sfdx-hardis.cloudity.com/hardis/<topic>/<verb>/<name>/. Verify the doc page exists before committing.Add i18n keys to all 9 locale files (src/i18n/en.json, fr.json, es.json, de.json, it.json, nl.json, ja.json, pl.json, pt-BR.json) for the tree entry only:
<labelKey> — short, action-oriented label shown in the tree (e.g. "Detect Suspicious Audit Trail Activities")<tooltipKey> — one-sentence explanation of what the command doesKeep keys in alphabetical order, flat JSON, camelCase. Use existing audit-trail / health-check entries as a reference for tone in each language. Follow the language-specific style rules in CLAUDE.md (formal "vous" in French, formal "Sie" in German, informal "tu" in Italian, etc.). Reuse upstream sfdx-hardis terminology where it exists. No card-specific keys are needed — the Org Monitoring LWC reads its card title and description directly from the CLI catalog.
(Recommended) Add icon mappings. Both the Org Monitoring home LWC and the Monitoring Config Workbench have a COMMAND_ICONS map at the top of their JS file. Add an entry keyed by the CLI catalog entries[].key (UPPER_SNAKE_CASE) to both:
src/webviews/lwc-ui/modules/s/orgMonitoring/orgMonitoring.js (top of file)src/webviews/lwc-ui/modules/s/monitoringConfig/monitoringConfig.js (top of file)<CATALOG_KEY>: { icon: "utility:<sldsIconName>", colorClass: "<existing-class>" },
Pick an SLDS utility icon (https://www.lightningdesignsystem.com/icons/) and reuse one of the existing colorClass values for category coherence. If you omit this, both surfaces fall back to DEFAULT_ICON (gear) — functional but visually generic. The two maps should stay in sync; if you're adding many commands at once, factor them into a shared module rather than copying entries.
(Optional) Add a tree-view icon mapping. Edit src/utils/themeUtils.ts in getAllCommandIcons() and add an entry keyed by the command id:
"hardis:org:monitor:<name>": { vscode: "<vscode-codicon>", hardis: "<file>.svg" },
Skip if no matching SVG exists in the icon set — the tree falls back to a default.
Update CHANGELOG.md under ## Unreleased, applying the merge rule:
Unreleased bullet already covers monitoring additions, extend or refine that bullet rather than adding a new one.- Add monitoring command **Health Check** to audit security policies of your org).Verify by running yarn lint and yarn dev (or yarn build). Then launch the Extension Development Host (F5) and:
sf hardis:config:monitoring-defaults --json in a terminal to inspect what the CLI is publishing.The Monitoring Config Workbench and Org Monitoring home pages render in both dark and light VS Code themes. Any custom CSS that hardcodes a color, font, or font-weight will break one of the two.
Lookup order before writing any CSS:
resources/global-theme.css — already loaded by every webview (see src/webviews/lwc-ui-panel.ts:894). It ships .header-section, .header-content, .header-text, .header-title, .header-subtitle, .header-icon-container.{green,teal,gray,blue,purple,orange,yellow}, and .command-icon-container.{backup,audit,tests,limits,updates,security,legacy,users,licenses,apex,connected-apps,metadata-access,unused-metadata,...} — all pre-themed via .slds-scope[data-theme="light"|"dark"]. Reuse, don't redefine.slds-badge, slds-badge_lightest, slds-badge_inverse, slds-text-color_*, slds-text-heading_*, slds-box, etc. Reference: https://www.lightningdesignsystem.com/.var(--slds-g-color-palette-purple-40)) from resources/global-theme-variables.css, or VS Code tokens (var(--vscode-foreground), var(--vscode-editor-background), var(--vscode-descriptionForeground), inherit, currentColor).Hard rules:
#hex, rgb(), color: white, background: linear-gradient(<literal-color>, ...), font-family, font-weight: <number>. They do not theme.global-theme.css — your local rule wins on specificity tie-breaking and silently shadows the themed version.<span class="slds-badge slds-badge_lightest">, never a custom-coloured pill.orgMonitoring.js / orgMonitoring.html or monitoringConfig.js beyond COMMAND_ICONS. The list of commands, their titles, descriptions, categories, default frequency, default thresholds, channels, and severity ordering all come from the CLI catalog. Adding a per-command runXxx() method or <lightning-button> will be ignored at best, or shadow the catalog entry at worst.CONFIGURABLE_FIELDS / SECTIONS in src/utils/pipeline/sfdxHardisConfigHelper.ts — that file is for Pipeline Settings, not monitoring..sfdx-hardis.yml from this repo. The Workbench owns the monitoringCommands: array under the user's workspace config — it persists automatically when the user edits values.NotificationThreshold, channel, or frequency in monitoringConfigUtils.ts. Those types mirror the CLI contract; changing them here without a matching CLI change will desync the Workbench.clearMonitoringCatalogCache() then re-fetch).monitoringConfigUtils.ts types, and both LWCs. Treat as a feature design task, not a routine command addition — invoke the design skill first.NOTIFICATION_THRESHOLD_ORDER in src/utils/monitoringConfigUtils.ts (and mirror in the CLI if needed). This affects how the Workbench sorts threshold dropdowns.clearMonitoringCatalogCache() and re-fetches from the CLI. If it still doesn't appear, ask the user to run sf hardis:config:monitoring-defaults --json and inspect the output. If the command is missing from entries[], the CLI plugin needs updating.cacheExpiration (both occurrences) in fetchMonitoringCatalog() in src/utils/monitoringConfigUtils.ts. Current value: 7 days.| File | Required? | Why |
|---|---|---|
src/hardis-commands-provider.ts (org-monitoring topic) | Required | Tree menu entry |
src/i18n/*.json (all 9 locales) | Required | Tree entry label + tooltip translations |
src/webviews/lwc-ui/modules/s/orgMonitoring/orgMonitoring.js (COMMAND_ICONS) | Recommended | Per-command icon on the Org Monitoring home cards |
src/webviews/lwc-ui/modules/s/monitoringConfig/monitoringConfig.js (COMMAND_ICONS) | Recommended | Per-command icon in the Config Workbench rows |
src/utils/themeUtils.ts (getAllCommandIcons) | Optional | Tree view icon |
CHANGELOG.md (## Unreleased, merged) | Recommended | User-visible release note |
| sfdx-hardis CLI plugin (external) | Required for LWCs | Catalog source of truth — provides key, title, description, command, category |
orgMonitoring.js / orgMonitoring.html (card markup) | DO NOT EDIT | Cards are generated from the CLI catalog — no per-command HTML or JS handler |
Implement features, bug fixes, or refactors in the vscode-sfdx-hardis VS Code extension. Use when the user asks to write code, fix a bug, add a feature, or make changes to the codebase.
Fix duplicate code issues reported by jscpd in the vscode-sfdx-hardis extension. Use when the user asks to fix, resolve, or address jscpd duplications, copy-paste detector findings, or MegaLinter COPYPASTE_JSCPD errors. Either factorizes the duplicates into shared helpers, or, when factorization would hurt clarity, adds jscpd ignore markers to silence them.
Fix security vulnerabilities reported by Trivy and OSV-Scanner in the vscode-sfdx-hardis extension. Use when the user asks to fix, triage, or address Trivy / OSV-Scanner / MegaLinter REPOSITORY_TRIVY / REPOSITORY_OSV_SCANNER findings. Tries upgrading the affected dependency first, then a yarn resolution override, and only ignores the finding if the vulnerability is genuinely non-exploitable in this extension's context.
Analyze code, architecture, data flow, or behavior in the vscode-sfdx-hardis VS Code extension. Use when the user asks to understand, trace, audit, or investigate how something works in this codebase.
Design new features, architectural changes, or refactors for the vscode-sfdx-hardis VS Code extension. Use when the user asks to plan, architect, or propose how to build something new or restructure existing code.
Write or update documentation, tooltips, translations, and help text for the vscode-sfdx-hardis VS Code extension. Use when the user asks to document, describe, explain for users, or update README/translations.