feat: encode UFM findings as TOON

[robertolopezlopez]

Description

Encodes native UFM scan results as generic TOON through GAF's UfmPresenter, matching the CLI-1838 contract. Builds on TOON MIME selection and writers from CLI-1825.

Replaces the earlier concise SCA/Secrets projection approach with a pure-Go encoder that preserves FindingData JSON shape, envelope fields, and deterministic key ordering. No external TOON library.

Changes

• Added internal/presenters/toon/encode.go — JSON-to-TOON encoder (tabular/list/inline forms, UTF-8 key sort, no trailing newline).
• Added internal/presenters/toon/envelope.go — builds {"results":[...]} from TestResult.Findings() and renders via the encoder.
• Added internal/presenters/toon/format.go — scalar/tabular quoting helpers aligned with TOON 4.1 rules.
• Wired ufm.toon.tmpl through encodeUFMToon and registered TOON MIME handling in UfmPresenter and the unified output workflow.

Testing

• Unit golden tests for all seven CLI-1838 contract fixture pairs (encode_test.go).
• Presenter integration tests byte-matching contract goldens via RenderTemplate (presenter_ufm_toon_test.go).
• Output-workflow test verifies TOON routing with varied UFM fixtures.

CLI integration

• Draft CLI PR: snyk/cli#7241 — pins cliv2 to c41b258 on this branch (v0.22.2-0.20260908104610-c41b258683da).

Closes CLI-1826.

Checklist

• Tests added and all succeed (make test)
• Regenerated mocks, etc. (make generate)
• Linted (make lint)
• Test your changes work for the CLI
  1. Clone / pull the latest CLI main.
  2. Run go get github.com/snyk/go-application-framework@YOUR_LATEST_GAF_COMMIT in the cliv2 directory.
     • Tip: for local testing, you can uncomment the line near the bottom of the CLI's go.mod to point to your local GAF code.
  3. Run go mod tidy in the cliv2 directory.
  4. Run the CLI tests and do any required manual testing.
  5. Draft CLI integration PR: snyk/cli#7241 (re-pin to post-merge GAF main before merging).
  • Once this PR is merged, repeat these steps, but pointing to the latest GAF commit on main and update your CLI PR.

---

Note

Medium Risk
New CLI-facing serialization for full UFM payloads; mistakes could break consumers or misrepresent findings, though scope is presentation-only and heavily golden-tested.

Overview
Adds a TOON output path for unified findings model (UFM) scan results, alongside existing human, SARIF, and HTML formats.

A new internal/presenters/toon package builds a {"results":[...]} envelope from TestResult (including Findings()), normalizes via JSON round-trip with UseNumber, and supplies template helpers for tabular arrays, quoting (TOON 4.1-style), and key formatting. ufm.toon.tmpl walks that structure recursively; UfmPresenter registers ApplicationTOONMimeType with getToonTemplateFuncMap, and the unified output workflow maps the TOON MIME type to ApplicationTOONTemplatesUfm.

Tests add contract golden fixtures, presenter byte-matching, edge cases (findings errors, non-JSON-safe values, control characters), and a workflow check that the TOON config flag selects the TOON writer.

^{Reviewed by Cursor Bugbot for commit c41b258. Bugbot is set up for automated code reviews on this repo. Configure here.}

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues
✅	Secrets	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[snyk-io]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[PeterSchafer]

question: why don't we dynamically derive the output from findingstype instead of hardcoding certain types? also below for secrets. the templates should be agnostic as much as possible. New products should just work.

[octavian-snyk]

Can we create something generic for UFM findings instead of building separate implementations for each product?

[PeterSchafer]

Issue: this is basically bypassing the template based rendering

[robertolopezlopez]

hi, I have just seen this message now. Yes that is the case - template should own the presentation logic. I changed that yesterday evening

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ No major issues detected

📚 Repository Context Analyzed This review considered 23 relevant code sections from 14 files (average relevance: 0.98) internal/presenters/funcs.go (2 segments, lines 1-258) pkg/local_workflows/connectivity_check_extension/connectivity/formatter.go (lines 1-239) internal/presenters/components.go (lines 1-312) pkg/utils/sarif/sarif.go (lines 1-248) pkg/utils/ufm/json_test_result.go (lines 1-207) pkg/utils/ufm/ufm_workflow_helper.go (lines 1-74) pkg/local_workflows/doctor_workflow/format/template.go (lines 1-107) ... and 7 more file(s)

🤖 Repository instructions applied (from AGENTS.md)

[octavian-snyk]

Looks good as a first iteration.
Changes are isolated to TOON rendering.

⚠️ Associated CLI PR must pass tests before merging. ⚠️