[aviggiano]

Summary

• fixes Workspace handoff staging aborts when an ignored runtime root exists: exclude pathspec misses the directory entry #281
• workspace capture aborted whenever a gitignored runtime root (e.g. node_modules) existed in the worktree
• the :(exclude) pathspecs were the cause, not an incomplete form of it

The failure

Found live in Aave v4 run R44 (aave-v4-v0012-main-issue272-r44-invariant-only, main 77da78a). Node property-specification-a16z failed at 2026-08-06T14:14Z:

Command failed: git add -A -- . :(exclude).ultrafuzz/** :(exclude).smithers/** :(exclude)node_modules/** :(exclude)artifacts/**
The following paths are ignored by one of your .gitignore files:
node_modules
hint: Use -f if you really want to add them.

Why the obvious fix is wrong

My first attempt added :(exclude)node_modules alongside :(exclude)node_modules/**, on the theory that the glob covered the contents but not the directory entry. The test stayed red. So I measured git's actual behaviour instead of reasoning further:

invocation	result
git add -A -- .	OK — ignored paths skipped silently
git add -A -- . :(exclude)<root>/**	FAIL
git add -A -- . :(exclude)<root> :(exclude)<root>/**	FAIL
git add -A -- . :(exclude)<root>	FAIL
git add -A --ignore-errors -- . :(exclude)<root>	FAIL

Any negative pathspec makes git add report an ignored path as an error rather than skipping it. So the exclusions themselves had to go.

The fix

Stage plainly with git add -A -- ., then git reset --quiet <treeish> -- <runtime roots> so those roots contribute nothing to the captured tree without ever being named to add.

Two details that matter:

• Reset to the tree-ish, not rm --cached. If a file under one of those roots is tracked, resetting restores its baseline content; dropping the index entry would record a deletion and silently corrupt the captured tree.
• The target is threaded through, not assumed to be HEAD. captureWorkspaceTree reads HEAD but captureWorkspacePatch reads the caller's baselineTree; resetting to HEAD in the latter would produce a patch against the wrong base.

Impact

The node fails visibly, so it is retryable — less severe than #275's invisible prepare:-wrapper strand. But property-specification-fanin depends on all eight lens nodes, so a lens that fails deterministically in its own worktree blocks the invariant pipeline from reaching fan-in, invariant setup, Recon, findings or report.md.

It reproduces only when that node's agent actually installed dependencies in its worktree, which is why most nodes survive and this went unnoticed until R44.

Validation

• new regression proven red without the source change and green with it; it plants all four runtime roots (node_modules ignored, the others not) plus a real setup change, then asserts the change is captured and no runtime root leaks into the patch
• pnpm --filter @ultrafuzz/runtime test — 278 pass / 0 fail
• typecheck, eslint, prettier, git diff --check — clean

Relationship to #254

Draft PR #254 proposes the same direction ("stage from an explicit Git path list instead of broad add pathspecs") bundled with eight unrelated changes. This is the narrow fix for the observed abort only; #254 can be rebased or closed on top of it.

Greptile Summary

The PR replaces exclusion-based workspace staging with byte-exact enumeration of tracked and non-ignored paths, omitting runtime roots before staging.

• Uses NUL-delimited literal pathspecs to preserve unusual filenames.
• Retries staging when an enumerated path disappears.
• Adds regression coverage for ignored and unreadable roots, tracked deletions, nested repositories, unusual filenames, and baseline preservation.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
packages/runtime/src/workspace-handoff.ts	Reworks workspace staging around byte-exact path enumeration, runtime-root filtering, and bounded retries for disappearing paths.
packages/runtime/test/workspace-handoff.test.ts	Adds focused regression tests covering ignored roots, concurrency, tracked-path semantics, nested repositories, and unusual filenames.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Load baseline tree into temporary index] --> B[Enumerate tracked and non-ignored paths]
  B --> C[Exclude runtime roots and directory entries]
  C --> D{Any paths remain?}
  D -- No --> E[Write captured tree]
  D -- Yes --> F[Stage NUL-delimited literal paths]
  F --> G{Path vanished?}
  G -- Yes, attempts remain --> B
  G -- No --> E
  G -- Other failure --> H[Abort capture]

Loading

_{Reviews (5): Last reviewed commit: "fix(runtime): retry staging when a liste..." | Re-trigger Greptile}

Context used:

• Knowledge Base — Runtime: Run Orchestration Lifecycle

[aviggiano]

Redesigned after adversarial review — 793757d

Two independent reviews. One recommended merge with a P2; the other found a P1 that invalidated the approach, and separately disproved the core.excludesFile follow-up I had started. Both were right, and the second attempt was wrong for a different reason than the first.

What the first commit missed

The old :(exclude) pathspecs did two jobs. :(exclude)artifacts/** kept entries out of the index and kept git add from descending into the directory. 5f946b1 only accounted for the first.

So a bare git add -A -- . avoids the ignored-path error but walks the runtime roots. Measured by review on a 157 MB non-ignored artifacts/ tree:

	wall	.git growth
git add -A -- .	8.62 s	+158 MB unreachable objects
:(exclude)artifacts/**	0.00 s	0

And worse than the cost, it reintroduces the abort:

# unreadable file under a non-ignored runtime root
error: unable to index file 'artifacts/att/x.json'
fatal: adding files failed        exit=128

That matters because the runtime writes artifacts/<attemptId>/ (workflow.tsx:248) and .ultrafuzz/schemas/ (workflow.tsx:371) into the workspace, and a target repo like Aave v4 has no reason to gitignore either. Capture runs once per dependency (workflow.tsx:470) plus twice inside applyWorkspacePatch, so the cost is O(N) per fan-in node.

Why core.excludesFile also failed

It is the lowest-precedence ignore source. A repository .gitignore containing !artifacts/ re-admits the path, and the unreadable-file case still aborted. Verified in a scratch repo rather than assumed.

The design now

Name only the other top-level entries as positive pathspecs. No negative pathspec means no ignored-path error; never naming the roots means never descending into them. The entry list is the union of worktree entries and git ls-tree entries so deleting a tracked top-level path is still captured, and the empty case is skipped because git add -A -- with no pathspec stages everything.

This is what #254 proposed ("stage from an explicit Git path list instead of broad add pathspecs"); both reviewers converged on it independently.

Verified against the cases that broke the earlier attempts

PASS  ignored node_modules does not abort            (the original #281 repro)
PASS  unreadable file under artifacts does not abort (broke commit 1)
PASS  gitignore negation of artifacts still excluded (broke core.excludesFile)
PASS  deleted tracked top-level path captured
PASS  only runtime roots present does not stage them (empty pathspec guard)
PASS  tracked artifacts file restored to baseline

Three are now pinned as regression tests; the unreadable-file one skips as root, which can read a 0000-mode file regardless.

Also fixed from review

• My test comment stated the cause incorrectly — it claimed /** excluded contents but not the directory entry. Disproved: :(exclude)<root>, :!<root> and the /** form all fail identically. Corrected in the test and the source doc comment, because a maintainer trusting it could have "fixed" it by dropping /** and reintroduced Workspace handoff staging aborts when an ignored runtime root exists: exclude pathspec misses the directory entry #281.
• Added the missing tracked-runtime-root test. Swapping the reset for git rm --cached would have passed every other test while silently converting tracked files into spurious deletions in result_tree.
• Replaced a brittle regex assertion with a git ls-tree check on the captured tree.

Review also independently confirmed the risk I was most worried about is a non-issue: the HEAD vs baselineTree reset skew is byte-for-byte unchanged by this PR, with matching tree SHAs on both implementations.

Validation

pnpm --filter @ultrafuzz/runtime test — 282 pass / 0 fail. typecheck, eslint, prettier, git diff --check clean.