refactor(oss): delegate C/C++ auto-detect to CLI extension [IDE-2089]

[acke]

Summary

This PR was originally cut to ship a snyk-ls–side C/C++ auto-detect prompt + per-folder unmanaged toggle. After review, the detection + decision was moved into the CLI's cli-extension-os-flows instead. snyk-ls now only sets one env var; everything else is the extension's responsibility.

Net diff against main: 4 files, +62 / -0.

The intermediate work (detector, prompt, per-folder setting, command, panel toggle, re-arm logic, etc.) was added and then removed in subsequent commits on this branch, so it does not appear in the cumulative file diff. See commit history for the steps.

What snyk-ls actually changes here

• infrastructure/oss/cli_scanner.go — sets SNYK_AUTODETECT_OSS=1 in the env passed to every OSS CLI invocation. The CLI's os-flows extension then decides per input directory whether to also run an unmanaged scan.
• infrastructure/oss/cli_scanner_test.go — new test asserting the env-var contract (TestCLIScanner_prepareScanCommand_SetsAutodetectEnv).
• docs/requirements/architecture.md — ADR describing the new delegation, including the limitation (see below).
• docs/requirements/requirements.md — 3 updated IDE-2089 requirements reflecting the new boundary.

How the auto-detect now works (CLI side, see cli-extension-os-flows#251)

snyk test … (with SNYK_AUTODETECT_OSS=1 from snyk-ls)
   │
   └─► OSWorkflow
         ├─► managed scan (existing path)
         └─► detect.HasCPPArtefacts(inputDir) for each input dir
                  │
                  └─► any C/C++ artefacts?
                          ├─ no  → return managed data
                          └─ yes → invoke legacycli --unmanaged
                                   append its workflow.Data to managed output

The extension keeps the previous --unmanaged flag's semantics for direct CLI users; the env var is the only new switch.

Limitation

A native Go unmanaged.test workflow does not yet exist; the extension currently invokes the legacy TypeScript CLI to perform the unmanaged scan when C/C++ is detected. The legacy CLI's workflow.Data carries its own content type, so for mixed manifest + C/C++ folders the unmanaged and managed results render as two separate sections rather than as one unified report. When the native workflow lands, the extension swap is local — no snyk-ls change needed.

Why this shape

• No IDE prompt and no per-folder toggle. Detection happens unconditionally on every OSS scan; the user never has to opt in. The C/C++ walker is bounded (max 5000 entries, depth 6, skipping node_modules/vendor/cmake-build-*/VCS dirs) and short-circuits on the first hit, so the cost is minimal.
• One source of truth. Detection rules now live with the rest of the OSS routing in cli-extension-os-flows/pkg/unmanaged/detect. Future plugin work (VS Code, Eclipse, Visual Studio) gets the same behaviour automatically since they all invoke the same CLI.
• Backwards-compatible for non-IDE CLI users. The auto-detect is off unless SNYK_AUTODETECT_OSS=1 is set; direct snyk test invocations behave exactly as before.

Depends on / related

• cli-extension-os-flows#251 — adds the detector, OSWorkflow orchestration, and the env-var gate. Must merge before this snyk-ls PR has any user-visible effect.
• snyk-intellij-plugin#834 — closed; the per-folder snyk_oss_unmanaged_enabled setting it forwarded no longer exists.

Jira: IDE-2089

Test plan

• go build ./... clean
• go vet ./... clean
• go test ./internal/types/... ./infrastructure/oss/... ./infrastructure/configuration/... — green
• make test-js — 98/98 pass against regenerated config-page.html fixture
• make build-debug in /cli against this branch — clean (binary built, LS commit pinned)
• Manual end-to-end: requires cli-extension-os-flows#251 merged + CLI dep bumped. Open a folder with both package.json and .cpp files in the IDE and confirm both managed and unmanaged scan results appear.

🤖 Generated with Claude Code

[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.

[snyk-pr-review-bot]

PR Reviewer Guide 🔍

🧪 PR contains tests

🔒 No security concerns identified

⚡ No major issues detected

📚 Repository Context Analyzed This review considered 11 relevant code sections from 6 files (average relevance: 0.75) infrastructure/code/code.go (2 segments, lines 1-163) docs/manual_testing_config_resolution.md (3 segments, lines 860-1102) infrastructure/oss/cli_scanner.go (3 segments, lines 1-219) docs/requirements/architecture.md (lines 1-41) docs/requirements/requirements.md (lines 1-7) infrastructure/filesystem/filesystem.go (lines 1-62)

[bastiandoetsch]

[Suggestion] getCommand (infrastructure/cli/cli.go) treats a non-nil env as the complete subprocess environment and skips loading os.Environ(). Today that's safe because updateArgs→GetEnvFromSystemAndConfiguration always returns a fully OS-populated map. But the new if env == nil { env = gotenv.Env{} } guard codifies a path that, if ever reached, would hand getCommand a map containing only SNYK_AUTODETECT_OSS=1 — stripping PATH and the rest of the OS env from the CLI subprocess. Consider a one-line comment naming that invariant, or setting the var via the existing AppendCliEnvironmentVariables merge path. Non-blocking.

— AI review

[bastiandoetsch]

[Suggestion · non-blocking] SNYK_AUTODETECT_OSS=1 is set unconditionally, but the LS router (shouldUseLegacyScan) sends a default snyk test (no UseOsTest/UseExperimentalRiskScoreInCLI flag) through the legacy CLI path, whereas the architecture doc's diagram routes this var into the os-flows OSWorkflow (the ostest path). Worth confirming whether the legacy CLI also honours the var, or stating explicitly that the feature is gated behind the UseOsTest rollout — and reconciling the mermaid diagram so default-population behaviour is clear. The env var degrades gracefully (ignored if unrecognised), so this is a doc/contract clarification, not a defect.

— AI review

[bastiandoetsch]

Reviewed with the full verification pass (semantic, adversarial, security, code-review). The snyk-ls side is a correct, minimal change — set SNYK_AUTODETECT_OSS=1 at the single command-builder choke point so the env reaches both the legacy and ostest paths, with a meaningful test and a genuinely good architecture decision record. No correctness or security issues. Two non-blocking suggestions left inline/below (env-completeness invariant; confirm the var is honoured on the default legacy route). Approving.

— AI review

[basti-snyk]

Suggestion (non-blocking). The string literal "SNYK_AUTODETECT_OSS" + value "1" is the entire contract between snyk-ls and cli-extension-os-flows, which is the sole arbiter of whether an unmanaged C/C++ scan also runs. That boundary direction is correct (LS only opts in). Two small notes:

• Consider anchoring this literal with a comment pointing at the extension's gate logic, mirroring the existing precedent for the hard-coded workflow ID in ostest_scan.go.
• The if env == nil { env = gotenv.Env{} } guard just above is effectively dead in production — the SDK env path (UpdateEnvironmentAndReturnAdditionalParams → GetEnvFromSystemAndConfiguration) always returns a non-nil map; it only fires under test doubles. Harmless, keep or drop.

Verified the feared interactions are non-issues: setting this unconditionally alongside a user-supplied --unmanaged does not double-scan (--unmanaged forces the legacy path where this var is inert), and forcing env non-nil does not strip os.Environ()/PATH (env was already non-nil before this change).

— AI review

[basti-snyk]

ℹ️ Automated AI review summary — non-blocking.

Reviewed origin/main...HEAD with four reviewers (semantic, adversarial, security, code-review). No Critical or Should-Fix correctness issues. The production change is a single, well-scoped line (SNYK_AUTODETECT_OSS=1 in prepareScanCommand) with a unit test, and the docs.

Verified the two plausible failure modes are non-issues:

• Setting the flag unconditionally while the user also passes --unmanaged does not cause a double unmanaged scan — --unmanaged deterministically forces the legacy scan path, where this env var is never read (only the new ostest/os-flows path honours it).
• Forcing env non-nil does not strip os.Environ()/PATH — the env map was already non-nil in the production SDK flow before this change.

Minor, non-blocking (see inline comment):

• Cross-repo contract is a bare string literal; consider a comment pointing at the extension's gate logic.
• The if env == nil guard is dead in production (test-only).
• Stray unrelated blank line added in Scan (~line 206) — unrelated to IDE-2089; drop to keep the diff surgical.
• Test-pyramid note: only a unit test asserts the map value; no integration/acceptance test confirms the var reaches the spawned CLI subprocess. A future refactor of the env plumbing could silently drop it. Worth an integration assertion if cheap.

Security: no findings introduced.

— AI review