Feedback wanted: v0.4.21 bounds hosted SARIF text without hiding originals

[CAOShurong]

VulnFuse v0.4.21 is now public: https://github.com/CAOShurong/vulnfuse/releases/tag/v0.4.21

This release addresses a specific interoperability gap: the general SARIF 2.1 schema accepts rule and result text longer than hosted code-scanning platforms document. VulnFuse now bounds rule names to 255 UTF-16 code units and rule descriptions/result messages to 1,024, without splitting a surrogate pair. Exact over-limit text stays in named vulnfuseOriginal* properties. Plain and baseline-comparison SARIF now share this rule builder, so baseline output also gets the existing nine-tag guard.

What was actually verified:

• A pre-fix CLI artifact with lengths 307/1311/1517/1357 passed both the generic JSON schema and Microsoft SARIF Multitool 5.6.0, demonstrating why generic validation alone was insufficient.
• Node 22/24, Windows CLI, the committed Action, clean package installation, and CodeQL passed in PR and again on main.
• Fresh anonymous downloads of all six v0.4.21 assets matched GitHub's digests and the flat checksum manifest; strict GitHub/Sigstore provenance verification passed.
• The downloaded CLI and extracted Action both produced bounded plain/baseline SARIF from a Trivy-shaped Unicode boundary fixture, retained exact originals, processed real repository Trivy/OpenVEX/CycloneDX fixtures, and rejected malformed input with exit code 1 and no output.

What is not claimed: no synthetic alert was uploaded to a user's Security tab, these bounds do not emulate every evolving GitHub or GitLab ingestion rule, and there is no adoption or time-savings claim.

Useful feedback would be a sanitized real report where:

1. a hosted platform still rejects or skips VulnFuse SARIF;
2. the truncated visible text is not the right prioritization;
3. a consumer fails to retain/read the custom original-text properties; or
4. another documented host limit should be handled at generation time.

Please include the platform/version, the smallest sanitized input, the exact error or skipped-result message, and whether plain or baseline SARIF was used. Security-sensitive reports belong in the private process described in SECURITY.md, not this discussion.