generate-cve-json: warn when a credit line joins several names by comma - #1741

Thanks for picking up #1737, @srijavuppala, and for the clear write-up of why this warns rather than splits. The heuristic is a reasonable start; the main point is where the signal lands, since the operator it is meant for never sees stderr.

flagging a single-line value with two or more name-like comma-separated parts in needs_decision (or normalisation_changes) (tools/cve-tool-vulnogram/generate-cve-json/src/generate_cve_json/cve_json.py:733)

Suggest flagging a single-line value with two or more name-like comma-separated parts in needs_decision (or normalisation_changes) so the operator splits it before the push.

print(
    f"warning: credit line {line!r} looks like {name_like} names "
    ...
    file=sys.stderr,
)

The skills that run the generator act on its --report-json file only: security-issue-sync (apply-and-push.md:268-272) and security-cve-allocate (tracker-updates.md:58) route a non-empty normalisation_changes, missing_required or needs_decision through outcomes/cve-json-fallback.md, and nothing reads stderr. So the operator the issue is about never sees this warning. Record it in the report instead. needs_decision makes the tool exit 2 with no record, which is too strong for a heuristic, so a non-blocking entry fits: write_report keeps to field names, line numbers and kinds, never body text, so the entry would be something like {field: "Reporter credited as", line: N, kind: "joined-credits"}. Then cve-json-fallback.md needs a line telling the skill to show it to the user.

Smaller observations

• tools/cve-tool-vulnogram/generate-cve-json/src/generate_cve_json/cve_json.py — The prek job fails because check-family-plugins regenerates the plugin's vendored copy, plugins/magpie-security-tools/tools/cve-tool-vulnogram/generate-cve-json/src/generate_cve_json/cve_json.py, which the PR did not commit. prek run check-family-plugins --all-files needs no network; run it and commit the regenerated file. On the local uv trouble in the test plan: exclude-newer = "7 days" needs a recent uv, so upgrading uv should stop it re-resolving uv.lock.
• See inline comments on tools/cve-tool-vulnogram/generate-cve-json/src/generate_cve_json/cve_json.py:769, tools/cve-tool-vulnogram/generate-cve-json/src/generate_cve_json/cve_json.py:704.

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The findings
below are observations, not blockers; an Apache Magpie
maintainer — a real person — will take the next look at the
PR. If you think a finding is mis-applied, please reply on
the PR and a maintainer will weigh in.

More on how Apache Magpie handles maintainer review:
Contributing guide.

needs fixes r=that I pointed out

Thanks for this, and for the patience. I've pushed a fixup on top of your commit so this can land now, instead of asking for another round.

• cve_json.py: the check now runs once per field in main(), so parse_credits_from_field stays pure and a line is no longer reported several times.
• cve_json.py: a line that may join names adds a non-blocking joined-credits entry to normalisation_changes, because the skills read --report-json and not stderr. The stderr warning stays for anyone running the tool by hand.
• cve-json-fallback.md: the skill now shows that entry to the user and says it may be a false alarm, since a multi-word company reads like a name.
• Tests now cover Jane Doe, Red Hat, Alice Smith, Trend Micro and Bob Lee, Palo Alto Networks, plus the report entry.

Please pull before pushing again.

This review was drafted by an AI-assisted tool and
confirmed by an Apache Magpie maintainer. The maintainer
approving this PR has read the findings and signed off. If
something feels off, please reply on the PR and a maintainer
will follow up.

More on how Apache Magpie handles maintainer review:
Contributing guide.