* fix(cso): give snapshot.json its own 16 MiB cap and actionable capacity errors
/cso refused any repository with more than about 3,100 tracked files before
an audit started: the snapshot manifest was pretty-printed and both its
writer and every reader capped it at the shared 1 MiB private-state limit
(#3068, manifest half of #2993).
- snapshot.json is written compactly and capped by SNAPSHOT_MANIFEST_LIMIT
(16 MiB), a constant local to the snapshot module.
- readJson takes a per-artifact cap; readSnapshotManifest is the only
reader of snapshot.json and passes the snapshot cap through recovery and
the private-file size check. MAX_STATE_FILE and MAX_OUTPUT stay 1 MiB.
- The manifest-cap and 64 MiB source-cap errors name the bound cap, the
measured value, what counts toward it, the next step and #2993. A single
file that would cross 64 MiB now hits the same message before it is read.
- Older pretty-printed manifests still load (recheck, inspect).
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* fix(cso): bound per-entry report and evidence lists with omitted counts
Lifting the manifest cap alone moved the failure into the audit: report.json
listed one transformation per transformed entry plus one coverage gap or
exclusion per omitted entry (1.97 MB for 5,000 nested paths), and
sensitive-evidence.json grew per scanner hit (1.68 MB), both under the
1 MiB private-state cap that saveReport and the start stdout share.
- boundedList (state.ts) keeps the leading entries that fit a byte budget,
measured as the pretty-printed JSON they add at their nesting depth, and
ends the list with one summary carrying the omitted count.
- report.json snapshot lists share one 256 KiB budget (gaps 128 KiB,
transformations 96 KiB, exclusions 32 KiB); coverage counts and status are
computed before trimming, so they stay exact.
- sensitive-evidence.json keeps 512 KiB of per-file evidence plus an
omitted-count record.
- Snapshot coverage and publicSnapshotPath no longer scan the whole manifest
per entry.
Test: 5,000 long nested paths, mostly excluded or withheld, 999 files with
scanner hits, driven through start, inspect, submit, finish and recheck.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* fix(cso): admit Git path listings above 1 MiB during snapshot capture
With the manifest cap lifted, the next file-count wall was the shared 1 MiB
process-output cap on Git's path listings: ls-files/ls-tree --name-only
failed at roughly 15-20k files (23,749-file grafana/grafana fails there) and
the comparison-base ls-tree near 8-10k.
runProcess lets raw callers, whose output is never printed or persisted,
opt in to up to 16 MiB; git() forwards an optional cap, and the four
snapshot listings pass SNAPSHOT_MANIFEST_LIMIT. Every other caller keeps
the MAX_OUTPUT clamp.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* docs(cso): explain the capacity refusals and file the follow-ups
docs/troubleshooting.md#cso-capacity covers the snapshot-list cap, the 64 MiB
source cap and the tracked-symlink refusal. TODOS.md records the symlink
design call, the #2993 aggregate cap, the full-manifest inspect output and
repair-bundle transformations.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* chore(release): v1.91.42.0 /cso lifts its file-count ceiling
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
---------
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
