bug: multi-folder --audit-log is a silent no-op

[Ayush7614]

Summary

With --audit-log <path> (or CVE_LITE_AUDIT_LOG), multi-folder scans open the log handle but emit no events — not even scan.started / scan.finished. Override audits in multi-folder hard-wire NULL_AUDIT_LOG. Unlike --sarif / --cdx (which print an unsupported warning), audit-log fails silently.

Expected

Per docs/audit-log.md: every run emits scan.started and scan.finished (and oa.detected when override hygiene runs). Consumers can always pair start/finish.

Actual

src/index.ts creates the audit log, then on the multi-folder path:

const exitCode = await handleMultiFolderScan(...);
auditLogHandle.close();
process.exit(exitCode);

No emit calls. Inside src/scan/multi-folder-scan.ts, override audit uses NULL_AUDIT_LOG, so even OA findings never stream.

--sarif / --cdx in multi-folder explicitly error with a yellow message; --audit-log does not.

Impact

Compliance / change-control pipelines that enable --audit-log on monorepos get an empty (or unchanged) NDJSON file and assume the run was logged. False sense of audit coverage.

Suggested fix

1. Emit at least scan.started / scan.finished around multi-folder scans (with folder count / exit code).
2. Pass the real audit-log handle into per-folder override audits instead of NULL_AUDIT_LOG when --check-overrides is set.
3. Optionally warn (like SARIF/CDX) until full event parity lands — prefer emitting events over warning-only.

Reproduce

cve-lite /path/to/multi-folder-root --offline --check-overrides --audit-log ./audit.ndjson
wc -l ./audit.ndjson
# expected: ≥2 events (started + finished), plus oa.detected when OA findings exist
# actual: 0 new events

[Ayush7614]

@hanu-14 Thanks for looking at these — a quick note for next time:

1. Please comment on the issue and ask before starting implementation (and wait for a clear go-ahead / assignment). That avoids duplicate work and conflicting PRs.
2. If you take an issue, please implement it completely — including the acceptance criteria, valid types so tsc/CI pass, early-exit/lifecycle handling where relevant, and tests. A partial change that claims the issue is fixed creates more review noise than it saves.
3. One issue → one focused PR. Do not batch unrelated issues (e.g. bug: docs teach --json > file but single-folder writes a timestamped file (redirect gets garbage) #877 + bug: multi-folder --report omits report.json and never renders override/maintenance panels #878 + bug: multi-folder --audit-log is a silent no-op #879) into a single PR. Separate PRs keep review and Fixes #… linking honest and avoid closing issues that were never actually fixed.

Your #882 claimed all three of these issues but did not implement #877/#878 and only partially attempted #879 (build failed; see the review on that PR). That PR is closed so these issues stay open for proper, complete fixes.

Happy to review a focused PR when the work for this issue is done end-to-end.

[kocaemre]

I can take this as a focused PR if it is still available.

Planned scope for #879 only:

• Emit multi-folder audit lifecycle events (scan.started / scan.finished) when --audit-log is configured.
• Thread the real audit log handle into multi-folder override-audit flow instead of using the null logger when --check-overrides is enabled.
• Keep the PR limited to audit-log behavior; no bug: docs teach --json > file but single-folder writes a timestamped file (redirect gets garbage) #877/bug: multi-folder --report omits report.json and never renders override/maintenance panels #878 report changes.
• Add/adjust tests for the multi-folder audit-log path and run the relevant TypeScript checks before opening a PR.