cso start crashes with UNSAFE_PATH on repos containing untracked nested git repositories; history-inputs fails on routine repos due to a 1 MiB log cap #3255

Environment

• gstack 1.91.121.0 (revision=1.91.121.0 (d258bcffb0cb)), CSO helper ABI 3
• Windows 11 x64 (repro is OS-agnostic; see below)
• Bun 1.4.3, Node 22.23.3

Bug 1 — UNSAFE_PATH: Expected a contained relative path (crash, blocks all audits)

Symptom

gstack-cso start --repo PATH fails before creating a run, for every --repo path form:

{"ok":false,"error":{"code":"UNSAFE_PATH","message":"Expected a contained relative path"}}

doctor passes on the same repo; only start fails.

Root cause

When the audited repository contains an untracked nested git repository (a directory holding its own .git that is not a registered submodule), git ls-files --cached --others --exclude-standard -z emits that directory as a single entry with a trailing slash (e.g. shadcn-ui/).

paths() in lib/cso/snapshot.ts:520 feeds the value to relativePath() without stripping the slash:

// lib/cso/snapshot.ts:520
seen.add(relativePath(value)); // throws on "shadcn-ui/"

relativePath() (lib/cso/contracts.ts:418) rejects any path whose split('/') yields an empty segment, so dir/ throws. The sibling collector at snapshot.ts:547 already strips the slash and does not crash:

// lib/cso/snapshot.ts:547
ignoredDirectories.add(relativePath(value.replace(/\/$/, '')));

Repro (OS-agnostic)

1. git init outer && cd outer && echo hi > README.md && git add . && git commit -m init
2. mkdir inner && cd inner && git init && echo x > f.txt
3. gstack-cso start --repo . → the exact error above.

Fails identically on any OS; it is triggered by repo content, not by path arguments or Windows.

Suggested fix

Strip the trailing slash in paths() before relativePath(value), mirroring line 547:

seen.add(relativePath(value.replace(/\/$/, '')));

Workaround (repo-local, reversible)

Add each nested repository to .git/info/exclude (e.g. shadcn-ui/, solid-glass/). start then succeeds.

Bug 2 — history-inputs not assessed: bounded git log truncated at 1 MiB

Symptom

Every coverage domain reports history-inputs: not_assessed with gap: Could not read bounded Git metadata: log exceeded the output limit (request rejected).

Root cause

The history capture at lib/cso/snapshot.ts:879-896 runs a full-patch log:

git log --max-count=100 --format=... --unified=3 -p <range> --

but passes no maxBytes to the git() helper. In lib/cso/process.ts:598 the effective cap is min(opts.maxBytes ?? MAX_OUTPUT, ...) = MAX_OUTPUT = 1 MiB (lib/cso/contracts.ts:5). Full patches for 100 commits on a routine Next.js app measure 2.4 MiB (git log --max-count=100 -p on the repro repo), so the read is truncated and history capture fails on ordinary repositories. The 16 MiB RAW_OUTPUT_LIMIT (process.ts:562) is unreachable here because maxBytes is omitted.

Suggested fix

Either pass an explicit larger maxBytes (raw mode allows up to RAW_OUTPUT_LIMIT) to the history git() call, or make history capture tolerate truncation (e.g. capture commit metadata without -p when the patch output exceeds the cap).

Notes

• Both issues observed on a real repo (Renhuai-123/ziwei-doushu clone); Bug 1 reproduces in a 3-file sandbox through the compiled launcher.
• With the Bug 1 workaround in place, start completes: run captures 125 source entries, snapshot coverage passes; only history-inputs remains blocked by Bug 2.