Rename risk assessments to risk analyses

[SachaProbo]

Align the org risk-assessment entity across database, API, CLI, console, and n8n under the risk-analyses naming, leaving third-party assessments and SoA control flags unchanged.

https://linear.app/probo/issue/ENG-702/rename-risk-assessments-risk-analyses

---

Summary by cubic

Renames the org “risk assessment” entity to “risk analysis” across the console, CLI, n8n-node, tests, and docs per ENG-702. No behavior changes; console routes redirect, permissions updated, constraint names adjusted, and third-party assessments and SoA control flags stay the same.

Tests +1203 -1203

• Renamed e2e specs and factory helpers to risk_analysis; added CreateRiskAnalysis.
• Replaced risk_assessment_test.go with risk_analysis_test.go; updated RBAC, relations, and tenant tests.

prb (CLI) +409 -298

• Moved command group to risk-analysis; updated GraphQL types, flags, and help text.
• Added node delete subcommand.

App: console +415 -387

• Switched routes, pages, permissions, and Relay ops to risk-analyses; redirect from /risk-assessments to /risk-analyses.
• Updated en-US, fr-FR, and nl-NL locales; refreshed tabs, scenario linking, and loaders.

Package: n8n-node +288 -288

• Renamed resource to riskAnalysis; updated all operations, inputs, and descriptions.

Agents +4 -4

• Updated docs and .cursor examples to use risk_analysis and risk_analyses constraint names.

^{Written for commit 7dfb814. Summary will update on new commits.}

[cubic-dev-ai]

40 issues found and verified against the latest diff

Not reviewed (too large): apps/console/src/_locales/en-US.json (~5,550 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/getAllScopes.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/getAllScopes.operation.ts:27">
P1: Existing n8n workflows using Get Many Scopes retain the serialized `riskAssessmentId` property, but this handler now reads only `riskAnalysisId`, so upgraded workflows send an omitted `$riskAnalysisId: ID!` and fail at GraphQL execution. An n8n migration/alias or an explicitly documented breaking release is needed to preserve or clearly handle those workflows.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createScenario.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createScenario.operation.ts:27">
P2: Existing n8n Create Scenario workflows lose their configured scope after the node upgrade because saved parameters retain `riskAssessmentScopeId`, while this operation now only defines and reads `riskAnalysisScopeId`; the package has no migration or fallback. Preserving the old key as an alias/fallback or adding an n8n node migration would keep existing workflows working, otherwise this should be explicitly released and documented as a breaking change.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/Probo.node.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/Probo.node.ts:218">
P2: Renaming the persisted resource value from `riskAssessment` to `riskAnalysis` with no backward-compatible alias breaks any existing workflow that stored the old value: on execute, getExecuteFunction throws `Unknown resource: riskAssessment`, failing the node. Since the server-side data migration cannot reach n8n workflow JSON, consider registering a `riskAssessment` alias to `riskAnalysis` in the resources map (or otherwise mapping the legacy value) so already-published nodes keep working.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/ScenarioInScopeActions.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/ScenarioInScopeActions.tsx:150">
P2: The translation keys were renamed to riskAnalysisScenarioActions, but the Dutch locale nl-NL.json was not updated and still only has riskAssessmentScenarioActions. Dutch users will see raw key strings like "riskAnalysisScenarioActions.actions.edit" for every label in this component instead of translated text; rename the block in nl-NL.json to match.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/ThreatActions.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/ThreatActions.tsx:77">
P2: The rename updated this component to the riskAnalysisThreatActions translation keys, and en-US/fr-FR were renamed accordingly, but nl-NL.json still only has the old riskAssessmentThreatActions key. Dutch users will see raw keys like "riskAnalysisThreatActions.actions.edit" in the threat dropdown and edit dialog. Add a riskAnalysisThreatActions block to nl-NL.json (both keys are populated in en-US/fr-FR), and remove the stale riskAssessmentThreatActions block.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createScope.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createScope.operation.ts:59">
P2: Renaming the node parameter `riskAssessmentId` -> `riskAnalysisId` (and resource value `riskAssessment` -> `riskAnalysis`) is a breaking change for existing saved n8n workflows: their stored param is `riskAssessmentId`, so `getNodeParameter('riskAnalysisId')` returns undefined and the Create Scope operation throws on execution. Consider a backward-compat fallback that reads the old parameter name when the new one is absent (and maps the old resource value), or a documented migration, so pre-rename workflows keep working.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/update.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/update.operation.ts:26">
P3: The parameter was renamed to riskAnalysis/resource name, but the node's user-facing description strings still say 'risk assessment' (e.g. 'The ID of the risk assessment to update', 'The name of the risk assessment'). Since this PR's purpose is to align all risk-analyses naming, update these descriptions to 'risk analysis' so the node UI is consistent.</violation>

<violation number="2" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/update.operation.ts:27">
P1: Renaming the parameter `name` from `riskAssessmentId` to `riskAnalysisId` breaks backward compatibility with previously saved workflows. n8n stores each node's parameter value in the workflow JSON under the exact `name` key, so any existing node configured for the `update` operation still holds its value under `riskAssessmentId`. After this change `getNodeParameter('riskAnalysisId', ...)` returns the default empty string, so the mutation sends `id: ""` (an empty ID) and the update either fails or silently updates nothing. The resource had already been shipped (CHANGELOG: "Add a `riskAssessment` resource..."), so affected users are real. Since changing only `displayName` is backward-compatible and this PR is purely a naming alignment, consider keeping `name: 'riskAssessmentId'` and only renaming the display label, or retain a backward-compatible fallback that reads the legacy parameter. This applies identically to every renamed update* operation file in this batch.</violation>

<violation number="3" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/update.operation.ts:31">
P2: Changing the `resource` selection value from `riskAssessment` to `riskAnalysis` breaks existing saved workflows that selected this node's risk-assessment operations. The workflow stores the chosen resource as `'riskAssessment'`, which no longer matches any entry in the Resource options list, so the node's operation/field `displayOptions.show.resource` no longer match and the previously configured operation stops resolving. This affects every operation of the resource (create/update/get/delete and child operations), not just these seven update files. If the rename must proceed, it needs a node version bump (n8n node versioning) that keeps resolving nodes that were saved against the old `riskAssessment` resource, since the resource was already shipped in a prior release.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/RiskAnalysesPage.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/RiskAnalysesPage.tsx:131">
P2: Dutch users now see English labels for this page and its create dialog because the renamed `riskAnalysesPage`/`createRiskAnalysisDialog` keys are missing from `nl-NL.json`; adding the corresponding Dutch entries would preserve the existing localized experience.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/RisksTabs.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/RisksTabs.tsx:62">
P2: Dutch users see the English fallback `Risk analyses` in this tab because `nl-NL` still has only `risksTabs.riskAssessments`; adding/renaming that locale entry to `riskAnalyses` keeps the rename localized.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateThreatDialog.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateThreatDialog.tsx:84">
P2: Dutch users now see English labels and validation text in the create-threat dialog because the renamed `createRiskAnalysisThreatDialog` catalog entry is missing from `nl-NL`; adding the renamed key there would preserve the Dutch UI.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateNodeDialog.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateNodeDialog.tsx:84">
P2: This dialog now reads the createRiskAnalysisNodeDialog.* translation keys, but the nl-NL locale was not renamed and still only ships createRiskAssessmentNodeDialog. Dutch users will see raw i18n keys (e.g. "createRiskAnalysisNodeDialog.actions.add") instead of text; rename the key block in nl-NL.json alongside the en-US/fr-FR updates.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateScopeDialog.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateScopeDialog.tsx:79">
P2: The rename updated the translation keys in the source components but left the Dutch locale (apps/console/src/_locales/nl-NL.json) untouched: it still defines only the old createRiskAssessmentScopeDialog/* and riskAssessmentScopeActions/* (and the analogous Boundary/Node/Process/Threat) keys, while en-US.json and fr-FR.json were updated to the new riskAnalysis* namespace. Because the i18n config falls back to en-US, Dutch-speaking users will now see English text for these create/edit dialogs and the delete confirmations, and the old Dutch keys become orphaned. Please apply the same rename to nl-NL.json so the Dutch translations stay wired up.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateBoundaryDialog.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateBoundaryDialog.tsx:83">
P2: The rename to createRiskAnalysisBoundaryDialog was applied in the component and in en-US/fr-FR, but apps/console/src/_locales/nl-NL.json was not updated and still only has the old createRiskAssessmentBoundaryDialog key. Dutch users will now see the English fallback in this dialog instead of their translated strings; add the new key (and drop the stale one) to nl-NL.json to keep the Dutch locale working.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateProcessDialog.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateProcessDialog.tsx:84">
P2: The translation keys were renamed to createRiskAnalysisProcessDialog in en-US and fr-FR, but nl-NL.json still only defines the old createRiskAssessmentProcessDialog key. Dutch users of this dialog will fall back to English (fallbackLng en-US) instead of seeing Dutch translations; rename the nl-NL key (and remove the stale one) to match.</violation>
</file>

<file name="pkg/riskmanagement/service.go">

<violation number="1" location="pkg/riskmanagement/service.go:293">
P2: Invalid scenario link/unlink requests return the legacy `risk_scenario_id` error field even though the renamed API accepts `risk_analysis_scenario_id`, preventing clients from matching the validation error to their input. Renaming this field label in all four scenario-link validators would keep validation responses aligned with the new contract.</violation>
</file>

<file name="pkg/server/api/mcp/v1/specification.yaml">

<violation number="1" location="pkg/server/api/mcp/v1/specification.yaml:14409">
P2: The third-party risk-assessment tools (listThirdPartyRiskAssessments / addThirdPartyRiskAssessment) had only their `title` fields changed to "Risk Analyses" (lines 14409 and 14421), while their tool `name` and `description` still read "risk assessments". This both contradicts the PR's stated goal of leaving third-party assessments unchanged and makes each tool internally inconsistent — MCP clients see a "Risk Analysis" title above a tool still named/discribed as a "Risk Assessment". Recommend reverting these two title changes so third-party tools keep the "Risk Assessments" wording, keeping the rename scoped to the organization risk-analysis entity only.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/BoundaryActions.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/BoundaryActions.tsx:84">
P2: The rename updated the boundary-action translation keys in en-US and fr-FR but missed nl-NL.json, which still only has the old riskAssessmentBoundaryActions key. Dutch users will see the fallback English strings (or raw keys) for all boundary action labels, edit dialog fields, and the delete confirmation because nl-NL is a supported language and fallbackLng is en-US; rename the block in nl-NL.json to riskAnalysisBoundaryActions for consistency with this change.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/NodeActions.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/NodeActions.tsx:84">
P2: The rename here switched to t("riskAnalysisNodeActions.*"), but nl-NL.json still only has the old "riskAssessmentNodeActions" block (line 4859), so Dutch users will fall back to English for every Edit/Delete/Save/node-type label in this component. Rename the block in nl-NL.json (and any other locale that still uses the old key) to match.</violation>
</file>

<file name="pkg/coredata/risk_analysis_scenario.go">

<violation number="1" location="pkg/coredata/risk_analysis_scenario.go:67">
P3: Authorization attribute loading needlessly casts `@resource_ids` to `text[]`; `resourceIDs` is already `[]gid.GID`, which pgx encodes as a text array, so use the uncast `ANY(@resource_ids)` form used by `business_function.go`.

(Based on your team's feedback about []gid.GID array bindings.) .</violation>
</file>

<file name="pkg/cmd/risk-analysis/scenario/create/create.go">

<violation number="1" location="pkg/cmd/risk-analysis/scenario/create/create.go:149">
P3: The CLI now exposes mixed terminology: the renamed command help says `risk analysis`, but its summary and success output still say `risk assessment`; update those user-facing strings so this rename is consistent throughout the command.</violation>
</file>

<file name="pkg/cmd/risk-analysis/scope/list/list.go">

<violation number="1" location="pkg/cmd/risk-analysis/scope/list/list.go:109">
P3: Omitting `--risk-analysis` still reports the old “risk assessment” entity name; use “risk analysis” so the validation error matches the renamed command and flag.</violation>

<violation number="2" location="pkg/cmd/risk-analysis/scope/list/list.go:144">
P3: A missing `--risk-analysis` ID is reported using the old “risk assessment” name; change this message to “risk analysis” to complete the CLI rename.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createThreat.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createThreat.operation.ts:87">
P2: Renaming the resource value ('riskAssessment' -> 'riskAnalysis') and the parameter name ('riskAssessmentScopeId' -> 'riskAnalysisScopeId') is breaking for existing saved workfows: the node stays at version 1, so previously saved nodes still hold resource='riskAssessment' and the old parameter name. On run, getExecuteFunction throws `Unknown resource: riskAssessment` and the renamed getNodeParameter call reads an empty value. Consider introducing a node version bump with a migration (or a compatibility alias that maps the old resource/parameter to the new ones) so existing workflows keep running.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/get.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/get.operation.ts:26">
P3: The renamed parameter's user-facing description still reads 'The ID of the risk assessment' while the displayName above it now says 'Risk Analysis ID'. Update the description text to 'The ID of the risk analysis' so the copy is consistent with the rename.</violation>

<violation number="2" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/get.operation.ts:27">
P2: Renaming the node parameter key from `riskAssessmentId` to `riskAnalysisId` (and the resource value from `riskAssessment` to `riskAnalysis`) is a breaking change for every already-published workflow using these nodes: saved nodes reference the old parameter key, so `this.getNodeParameter('riskAnalysisId', itemIndex)` won't find a value and the operation's resource match stops resolving. If this rename is intended to be user-visible, consider keeping the previous `riskAssessmentId` parameter key as an alias/fallback (e.g. reading either key) or documenting the migration for existing workflows; otherwise existing automations will need manual reconfiguration after upgrade.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/create.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/create.operation.ts:31">
P2: Renaming the `resource` option value from `riskAssessment` to `riskAnalysis` and the node parameter keys (e.g. `riskAssessmentScopeId` → `riskAnalysisScopeId`, `riskAssessmentId` → `riskAnalysisId`) breaks backward compatibility with any n8n workflow saved before this change. `Probo.node.ts` dispatches via `getNodeParameter('resource')` → `getExecuteFunction(resource, operation)`, so existing nodes that stored `resource='riskAssessment'` will no longer resolve to a matching operation, and previously entered values under the old parameter keys will be silently dropped (returning the default/empty). If existing workflows must keep working, consider accepting the legacy resource value alongside the new one and/or retaining the old parameter names as fallbacks; if this is an intentional breaking change, it should be called out in the n8n node changelog so users can re-configure affected nodes.</violation>

<violation number="2" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/create.operation.ts:31">
P3: The rename to 'riskAnalysis' was applied to the resource value and GraphQL mutation, but the user-facing property descriptions in this file still say 'risk assessment' ('The name of the risk assessment', 'The description of the risk assessment'). These strings surface in the n8n UI, so finish the rename there too for consistency.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/linkScenarioRisk.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/linkScenarioRisk.operation.ts:27">
P2: Renaming the node parameter name and resource value breaks previously saved workflows: existing workflow JSON still stores the value under the old key `riskAssessmentScenarioId` (and selects resource `riskAssessment`), so after this change `getNodeParameter('riskAnalysisScenarioId')` returns the empty default and the link mutation fails with a blank scenario ID. If backward compatibility for installed n8n nodes matters, consider keeping the old key as a fallback (e.g. `getNodeParameter('riskAnalysisScenarioId', itemIndex, this.getNodeParameter('riskAssessmentScenarioId', itemIndex) as string)` ) or documenting that users must reconfigure existing nodes.</violation>
</file>

<file name="pkg/coredata/migrations/20260805T144146Z.sql">

<violation number="1" location="pkg/coredata/migrations/20260805T144146Z.sql:50">
P3: The database rename leaves all foreign-key constraint names under the old `risk_assessment` naming, so schema inspection and any tooling that reports constraint names remain inconsistent with the new `risk_analysis` entities. Renaming the affected FK constraints as part of this migration would keep the database naming aligned, as the access-review rename migration does.</violation>
</file>

<file name="pkg/cmd/risk-analysis/process/update/update.go">

<violation number="1" location="pkg/cmd/risk-analysis/process/update/update.go:123">
P3: The update mutation and response struct were renamed to riskAnalysis, but the CLI still prints "Updated risk assessment process %s (%s)" to the user right below — the rename is incomplete in the user-facing output (and the Short help text at line 69). Update the message (and Short) to "risk analysis process" to keep the rename consistent with this command's code.</violation>
</file>

<file name="pkg/cmd/risk-analysis/boundary/update/update.go">

<violation number="1" location="pkg/cmd/risk-analysis/boundary/update/update.go:125">
P3: The rename to risk-analysis is incomplete in this file's user-facing output: the readout after a successful update still prints "Updated risk assessment boundary %s (%s)\n". Since the PR's goal is to align the CLI under the risk-analyses naming, update the printf (and the command Short text) to say "Updated risk analysis boundary" for consistency with the renamed GraphQL fields.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/routes.ts">

<violation number="1" location="apps/console/src/pages/organizations/risks/routes.ts:41">
P2: The route path rename drops the old "/risk-assessments" and "/risk-assessments/:riskAssessmentId" URLs with no redirect, so previously saved bookmarks and externally linked deep links to risk assessment pages will now 404. Consider adding a redirect from the legacy paths to the new ones (301) to preserve existing links; if URL compatibility is intentionally not supported, leave as is.</violation>
</file>

<file name="pkg/cmd/risk-analysis/boundary/create/create.go">

<violation number="1" location="pkg/cmd/risk-analysis/boundary/create/create.go:76">
P3: The rename in this command is incomplete: Short ("Create a new risk assessment boundary") and the success message ("Created risk assessment boundary %s (%s)") still say "risk assessment boundary" while the command path, example, and flags now say "risk-analysis". Update these two user-facing strings to "risk analysis boundary" so help text and output stay consistent with the renamed command.</violation>
</file>

<file name="pkg/cmd/risk-analysis/scenario/list/list.go">

<violation number="1" location="pkg/cmd/risk-analysis/scenario/list/list.go:82">
P3: The help text for this command was not renamed: `Short` still says "List scenarios in a risk assessment scope" while the command path, examples, and flag description in this same file now use "risk-analysis". Since the PR's goal is to align the CLI under the risk-analyses naming, update the Short string to "List scenarios in a risk analysis scope" so user-facing help matches the renamed command.</violation>
</file>

<file name="pkg/cmd/risk-analysis/process/create/create.go">

<violation number="1" location="pkg/cmd/risk-analysis/process/create/create.go:150">
P3: The CLI has been renamed to `risk-analysis` (command path, GraphQL payloads, struct fields, and flag descriptions like "Risk analysis scope ID"), but the user-facing help and output strings in these same commands still say "risk assessment process" (e.g. `Short: "Create a new risk assessment process"`, "Created risk assessment process …", "Delete risk assessment process …", and the view error). This makes the CLI documentation and messages contradict the new naming and the PR's stated goal of renaming this entity across the CLI. Consider updating these strings to "risk analysis process" so help text and command output match the renamed command and flags.</violation>
</file>

<file name="pkg/cmd/risk-analysis/node/list/list.go">

<violation number="1" location="pkg/cmd/risk-analysis/node/list/list.go:82">
P3: The Short help text still says "risk assessment scope" while the Example and flag text on these same lines were renamed to risk-analysis, leaving inconsistent command help for a PR whose sole purpose is the rename. Update Short to "List nodes in a risk analysis scope".</violation>
</file>

<file name="pkg/cmd/risk-analysis/list/list.go">

<violation number="1" location="pkg/cmd/risk-analysis/list/list.go:80">
P3: This rename PR consolidated the command identifiers onto risk-analysis, but the user-facing help text was left on the old term: Short "List risk assessments in an organization", Example comments "List risk assessments ...", "No risk assessments found.", "Showing %d of %d risk assessments", and the --limit flag description "Maximum number of risk assessments to list" all still say "assessments". Update these strings to "risk analyses" so the CLI output and help are consistent with the renamed entity and command.</violation>
</file>

<file name="pkg/cmd/risk-analysis/risk_analysis.go">

<violation number="1" location="pkg/cmd/risk-analysis/risk_analysis.go:41">
P3: The command was renamed to `risk-analysis` and its package/imports now use the risk-analyses naming, but the command's help text still reads "Manage risk assessments". Since the PR's stated goal is to align the org entity under the risk-analyses naming, this user-facing string is now inconsistent with the command name; update the Short text to match (e.g. "Manage risk analyses").</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

9 issues found and verified against the latest diff

Not reviewed (too large): apps/console/src/_locales/en-US.json (~5,550 lines) - if these are generated or fixture files, add them to ignored paths to exclude them from future reviews.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/linkScenarioRisk.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/linkScenarioRisk.operation.ts:27">
P2: Renaming the node parameter name and resource value breaks previously saved workflows: existing workflow JSON still stores the value under the old key `riskAssessmentScenarioId` (and selects resource `riskAssessment`), so after this change `getNodeParameter('riskAnalysisScenarioId')` returns the empty default and the link mutation fails with a blank scenario ID. If backward compatibility for installed n8n nodes matters, consider keeping the old key as a fallback (e.g. `getNodeParameter('riskAnalysisScenarioId', itemIndex, this.getNodeParameter('riskAssessmentScenarioId', itemIndex) as string)` ) or documenting that users must reconfigure existing nodes.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/BoundaryActions.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/BoundaryActions.tsx:84">
P2: The rename updated the boundary-action translation keys in en-US and fr-FR but missed nl-NL.json, which still only has the old riskAssessmentBoundaryActions key. Dutch users will see the fallback English strings (or raw keys) for all boundary action labels, edit dialog fields, and the delete confirmation because nl-NL is a supported language and fallbackLng is en-US; rename the block in nl-NL.json to riskAnalysisBoundaryActions for consistency with this change.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/NodeActions.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/NodeActions.tsx:84">
P2: The rename here switched to t("riskAnalysisNodeActions.*"), but nl-NL.json still only has the old "riskAssessmentNodeActions" block (line 4859), so Dutch users will fall back to English for every Edit/Delete/Save/node-type label in this component. Rename the block in nl-NL.json (and any other locale that still uses the old key) to match.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createThreat.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/createThreat.operation.ts:87">
P2: Renaming the resource value ('riskAssessment' -> 'riskAnalysis') and the parameter name ('riskAssessmentScopeId' -> 'riskAnalysisScopeId') is breaking for existing saved workfows: the node stays at version 1, so previously saved nodes still hold resource='riskAssessment' and the old parameter name. On run, getExecuteFunction throws `Unknown resource: riskAssessment` and the renamed getNodeParameter call reads an empty value. Consider introducing a node version bump with a migration (or a compatibility alias that maps the old resource/parameter to the new ones) so existing workflows keep running.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/get.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/get.operation.ts:27">
P2: Renaming the node parameter key from `riskAssessmentId` to `riskAnalysisId` (and the resource value from `riskAssessment` to `riskAnalysis`) is a breaking change for every already-published workflow using these nodes: saved nodes reference the old parameter key, so `this.getNodeParameter('riskAnalysisId', itemIndex)` won't find a value and the operation's resource match stops resolving. If this rename is intended to be user-visible, consider keeping the previous `riskAssessmentId` parameter key as an alias/fallback (e.g. reading either key) or documenting the migration for existing workflows; otherwise existing automations will need manual reconfiguration after upgrade.</violation>
</file>

<file name="pkg/server/api/mcp/v1/specification.yaml">

<violation number="1" location="pkg/server/api/mcp/v1/specification.yaml:14409">
P2: The third-party risk-assessment tools (listThirdPartyRiskAssessments / addThirdPartyRiskAssessment) had only their `title` fields changed to "Risk Analyses" (lines 14409 and 14421), while their tool `name` and `description` still read "risk assessments". This both contradicts the PR's stated goal of leaving third-party assessments unchanged and makes each tool internally inconsistent — MCP clients see a "Risk Analysis" title above a tool still named/discribed as a "Risk Assessment". Recommend reverting these two title changes so third-party tools keep the "Risk Assessments" wording, keeping the rename scoped to the organization risk-analysis entity only.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/update.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/update.operation.ts:31">
P2: Changing the `resource` selection value from `riskAssessment` to `riskAnalysis` breaks existing saved workflows that selected this node's risk-assessment operations. The workflow stores the chosen resource as `'riskAssessment'`, which no longer matches any entry in the Resource options list, so the node's operation/field `displayOptions.show.resource` no longer match and the previously configured operation stops resolving. This affects every operation of the resource (create/update/get/delete and child operations), not just these seven update files. If the rename must proceed, it needs a node version bump (n8n node versioning) that keeps resolving nodes that were saved against the old `riskAssessment` resource, since the resource was already shipped in a prior release.</violation>
</file>

<file name="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateProcessDialog.tsx">

<violation number="1" location="apps/console/src/pages/organizations/risks/risk-analyses/_components/CreateProcessDialog.tsx:84">
P2: The translation keys were renamed to createRiskAnalysisProcessDialog in en-US and fr-FR, but nl-NL.json still only defines the old createRiskAssessmentProcessDialog key. Dutch users of this dialog will fall back to English (fallbackLng en-US) instead of seeing Dutch translations; rename the nl-NL key (and remove the stale one) to match.</violation>
</file>

<file name="packages/n8n-node/nodes/Probo/actions/riskAnalysis/create.operation.ts">

<violation number="1" location="packages/n8n-node/nodes/Probo/actions/riskAnalysis/create.operation.ts:31">
P2: Renaming the `resource` option value from `riskAssessment` to `riskAnalysis` and the node parameter keys (e.g. `riskAssessmentScopeId` → `riskAnalysisScopeId`, `riskAssessmentId` → `riskAnalysisId`) breaks backward compatibility with any n8n workflow saved before this change. `Probo.node.ts` dispatches via `getNodeParameter('resource')` → `getExecuteFunction(resource, operation)`, so existing nodes that stored `resource='riskAssessment'` will no longer resolve to a matching operation, and previously entered values under the old parameter keys will be silently dropped (returning the default/empty). If existing workflows must keep working, consider accepting the legacy resource value alongside the new one and/or retaining the old parameter names as fallbacks; if this is an intentional breaking change, it should be called out in the n8n node changelog so users can re-configure affected nodes.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[gearnode]

@SachaProbo please wait I merge the e2e refactor before merge this one 🙏

[gearnode]

LGTM