Add exclude glob patterns and subtree pruning to `find`

[abhinavgautam01]

Description

WorkspaceFilesystem.find accepts one inclusion glob plus limit and offset. The walker tests the inclusion glob before yielding an entry, but it descends into every directory regardless of whether that subtree is useful. Searches in workspaces containing directories such as node_modules, .git, or generated build output must scan those trees even when callers do not want any results from them.

Add exclusion patterns to FindOptions:

interface FindOptions {
  limit?: number;
  offset?: number;
  exclude?: string[];
}

Patterns should be matched against paths relative to the requested search directory, like the existing inclusion glob. Exclusion should take precedence over inclusion. When an excluded entry is a directory, the walker should skip both the directory result and its entire subtree before issuing more child queries.

Expected outcome

• Support multiple exclusion glob patterns.
• Match exclusions relative to the search root.
• Prevent excluded files and directories from appearing in results.
• Prune excluded directory subtrees during traversal rather than filtering them afterward.
• Preserve deterministic traversal and apply limit and offset to the remaining matches.
• Pass the option through WorkspaceFilesystem, WorkspaceFilesystemStub and the public find tool.
• Add tests proving both matching behavior and subtree pruning.

[fabriziosalmi]

I have a patch for this on a fork, following the "I already have a patch" path in CONTRIBUTING.md. It is up as fabriziosalmi/computer#1 for a reviewable diff; summary below.

The problem

find tests the inclusion glob before yielding an entry, but it descends into every directory regardless. A search over a workspace that holds node_modules, .git, or generated build output has to walk those trees even when the caller wants nothing from them, and each directory it enters is one more child query against the store.

The change

FindOptions gains an exclude?: string[]. Each pattern is matched against the path relative to the search directory, exactly like the inclusion pattern and using the same glob dialect (*, **, **/, ?). Exclusion takes precedence over inclusion. When an excluded entry is a directory, the walk skips it and never recurses, so the subtree is pruned before any child query is issued rather than filtered out afterward. Empty pattern strings are ignored, so exclude: [""] excludes nothing.

// Every source file, skipping dependency and version control trees.
const src = await workspace.fs.find("/workspace", "**/*.ts", {
  exclude: ["**/node_modules", "**/.git", "**/dist"],
});

The option threads through WorkspaceFilesystem and WorkspaceFilesystemStub unchanged (both already forward FindOptions), and the public find tool exposes it through a new exclude field on its input schema. docs/04_filesystem_interface.md and docs/09_tool_interface.md are updated, and there is a changeset.

I kept the change to the surfaces named in the issue. The sandboxed runtime capability (runtime.exec's ws: filesystem) still takes only (directory, pattern); I can extend it in the same style if you want it in scope.

How to verify

npm test --workspace @cloudflare/dofs -- src/fs/find.test.ts
npm run test:workers --workspace @cloudflare/dofs -- src/fs/find.test.ts
npm run check

Testing strategy

New cases in packages/dofs/src/fs/find.test.ts cover file exclusion, precedence over the inclusion pattern, multiple patterns, relative-root matching (a bare name versus a **/ prefix), empty entries, and the interaction with limit/offset.

The pruning claim is the one worth proving rather than asserting, so one test counts the child-listing queries through a read-through proxy over the database. Listing every subtree issues one such query per directory; excluding a directory drops the queries for it and everything beneath it. A post-traversal filter would leave that count unchanged, so the test fails if pruning regresses to filtering. It passes under both the Node and the Durable-Object-backed test configurations.

Compatibility

Additive and backward compatible. exclude is optional; callers that omit it see no change. No wire or schema change beyond the new optional field.

Happy to open a pull request here if you would like this to go through review.