fix(triage-security): improve remediation task generation logic in Step 8

plugins/sdlc-workflow/skills/triage-security/SKILL.md

@@ -412,6 +412,17 @@ assuming a fixed set. Common ecosystems include:
 - **npm** — JavaScript/TypeScript packages (e.g., axios, webpack, react)
 - **RPM** — System packages in container images (e.g., openssl, curl, glibc)
 
+The ecosystem classification determines remediation task structure:
+
+| Category | Ecosystems | Remediation tasks per stream |
+|---|---|---|
+| Source dependency | Cargo, npm | 2 — upstream backport + downstream propagation |
+| System package | RPM | 1 — Konflux release repo fix only |
+
+When a new ecosystem is added to a stream's Ecosystem Mappings table, update this
+classification table to define its category. All downstream rules (Case B, checklist,
+guardrails) reference this table rather than listing ecosystems individually.
+
 If the detected ecosystem is not listed in the stream's Ecosystem Mappings table (e.g.,
 Go modules), inform the user and stop automated triage for that ecosystem:
 
@@ -424,7 +435,7 @@ Both the lock file path and check command are configured per ecosystem in each s
 
 ```mermaid
 flowchart TD
-    A["Identify ecosystem\nfrom library + component"] --> B{"Source dependency?\n(Cargo, npm, ...)"}
+    A["Identify ecosystem\nfrom library + component"] --> B{"Source dependency\necosystem?\n(see classification table)"}
     B -->|Yes| C["Lock file inspection\n(git show commit:lock-file)"]
     B -->|No| D{"RPM / system\npackage?"}
     D -->|Yes| E{"RPM lock file\nconfigured?"}
@@ -602,11 +613,11 @@ flowchart TD
     B -->|Yes| SCOPE{"Issue scoped to\na single stream?"}
     B -->|No| D["Case C: Close as\nNot a Bug"]
     SCOPE -->|"Yes (scoped)"| C{"Other streams\nalso affected?"}
-    SCOPE -->|"No (unscoped)"| F["Case A: Create\nremediation tasks\nfor affected streams"]
-    C -->|Yes| E["Case B: Post cross-stream\nimpact comment"]
+    SCOPE -->|"No (unscoped)"| F["Case B: Create\nremediation tasks\nfor affected streams"]
+    C -->|Yes| E["Case A: Post cross-stream\nimpact comment"]
     C -->|No| F
     E --> F
-    F --> G{"Source dependency?\n(Cargo, npm)"}
+    F --> G{"Source dependency\necosystem?\n(see classification table)"}
     G -->|Yes| H["2 tasks: upstream\nbackport + downstream\npropagation"]
     G -->|No| I["1 task: Konflux\nrepo fix"]
     D --> J{"VEX Justification\nconfigured?"}
@@ -634,23 +645,13 @@ If concurrent triages are detected, the protocol offers three options: wait,
 skip, or proceed with a `concurrent-triage-overlap` label. Only continue to
 Case A/B/C after the user chooses.
 
-### Case A: Affected — create remediation tasks
-
-If the issue's stream-scoped versions (or all versions for unscoped issues)
-are affected:
-- Keep the current Vulnerability issue as-is (with corrected Affects Versions
-  from Step 3).
-- Create one remediation Task per affected stream within the issue's scope
-  (see Remediation Task Creation below).
-- Link each Task to the Vulnerability issue.
-
-### Case B: Cross-stream impact — proactive remediation
+### Case A: Cross-stream impact — proactive remediation
 
-**Guard — scoped issues only.** Case B applies exclusively to stream-scoped
+**Guard — scoped issues only.** Case A applies exclusively to stream-scoped
 issues (those whose summary contains a stream suffix like `[myproduct-2.2]`).
 Unscoped issues cover all streams by definition — there are no "other streams
 outside this issue's scope," so the cross-stream impact check is not applicable.
-For unscoped issues, skip Case B entirely and proceed directly to Case A task
+For unscoped issues, skip Case A entirely and proceed directly to Case B task
 creation for all affected streams.
 
 If the issue is **scoped** and the version impact analysis reveals that **other
@@ -669,7 +670,7 @@ streams** (outside this issue's scope) are also affected:
    suffix (reuse the JQL from Step 4).
 
 3. **For each affected stream without its own CVE Jira**, create proactive
-   remediation tasks using the same templates as Case A, but with the
+   remediation tasks using the same templates as Case B, but with the
    preemptive variant (see `remediation-templates.md` — Preemptive Task
    Variant):
    - Labels include `security-preemptive` alongside standard labels
@@ -694,6 +695,22 @@ streams** (outside this issue's scope) are also affected:
 Do **not** create new Vulnerability issues — PSIRT manages per-stream
 Vulnerability tracking. Only create remediation **Tasks**.
 
+### Case B: Affected — create remediation tasks
+
+If the issue's stream-scoped versions (or all versions for unscoped issues)
+are affected:
+- Keep the current Vulnerability issue as-is (with corrected Affects Versions
+  from Step 3).
+- Create remediation tasks for each affected stream within the issue's scope.
+  The number of tasks depends on the ecosystem — see the **ecosystem
+  classification table** in the Ecosystem detection section above. Source
+  dependency ecosystems produce two tasks per stream (upstream backport +
+  downstream propagation, with the downstream subtask blocked by the upstream
+  task). System package ecosystems produce one task per stream (Konflux release
+  repo fix).
+  See Remediation Task Creation below for full templates and API calls.
+- Link each Task to the Vulnerability issue.
+
 ### Case C: No supported versions affected
 
 If the version impact table shows NO for all supported versions (including
@@ -729,9 +746,23 @@ engineer as part of the close recommendation.
 Present the full recommendation (task details, cross-stream notice, or close
 rationale) to the engineer for confirmation before executing any Jira mutations.
 
+**Pre-creation checklist** — verify before presenting the recommendation:
+
+- [ ] **Task count per stream**: matches the ecosystem classification table
+  (source dependency → 2 tasks; system package → 1 task).
+- [ ] **Cross-stream coverage**: for scoped issues, all affected streams outside the
+  issue's scope have either a preemptive task or an existing sibling CVE Jira.
+- [ ] **Link types**: "Depend" for tasks linked to their own CVE Jira, "Related" for
+  preemptive tasks linked to another stream's CVE Jira, "Blocks" for upstream →
+  downstream within a stream.
+- [ ] **Preemptive labels**: tasks for streams without their own CVE Jira carry the
+  `security-preemptive` label.
+- [ ] **Coordination guidance**: each task's Implementation Notes includes the
+  appropriate guidance based on the repository's deployment context.
+
 ## Remediation Task Creation
 
-When triage concludes "needs fix" (Case A above), create Jira Tasks
+When triage concludes "needs fix" (Case B above), create Jira Tasks
 following `task-description-template.md` so that `/implement-task` can parse them
 directly. Only create tasks for streams within the current issue's scope.
 
@@ -749,12 +780,9 @@ Read `remediation-templates.md` for the full task description templates, Jira
 issue creation API calls, digest comment procedures, and linkage procedures.
 The key distinction:
 
-- **Source dependency ecosystems** (Cargo, npm): create **two** tasks —
-  an upstream backport task (fix in the source repo) and a downstream propagation
-  subtask (update the reference in the Konflux release repo). The downstream subtask
-  is blocked by the upstream task.
-- **System package ecosystems** (RPM): create **one** task — the fix happens directly
-  in the Konflux release repo (Dockerfiles, lock files). No upstream step needed.
+- **Source dependency ecosystems**: create **two** tasks per the ecosystem
+  classification table — upstream backport + downstream propagation (blocked).
+- **System package ecosystems**: create **one** task — Konflux release repo fix.
 
 ## Post-Triage Summary
 
@@ -809,15 +837,14 @@ MUST include the Comment Footnote (see above).
 7. **Never create Vulnerability issues.** PSIRT owns Vulnerability issue creation.
    This skill only creates remediation Tasks. Cross-stream impact is reported via
    comment on the current issue.
-8. **One remediation Task per affected stream, plus a downstream propagation
-   subtask** when the ecosystem is a source dependency (Cargo, npm).
-   The upstream task covers the source repo fix; the downstream subtask covers
-   the Konflux release repo update and is blocked by the upstream task. System
-   package ecosystems produce a single task. A single Task spanning multiple
-   streams would be unimplementable by `/implement-task`. For dev-only or
-   build-only dependencies (identified in Step 2.3.5), add the `dev-dependency`
-   label and override priority to Normal — see the dependency scope decision
-   tree in `version-impact-analysis.md`.
+8. **Task count per stream depends on the ecosystem** — see the ecosystem
+   classification table in the Ecosystem detection section. Source dependency
+   ecosystems produce two tasks, system packages produce one. A single Task
+   spanning multiple streams would be unimplementable
+   by `/implement-task`. For dev-only or build-only dependencies (identified
+   in Step 2.3.5), add the `dev-dependency` label and override priority to
+   Normal — see the dependency scope decision tree in
+   `version-impact-analysis.md`.
 9. **Follow `task-description-template.md` for generated tasks.** The remediation
    Task description must be parseable by `/implement-task`. Do not invent custom
    sections or deviate from the template format.