The Unsuccessful Glob: How a Failed Search Reveals an Agent's Assumptions

[glob] **/install/**/* No files found

This two-line message, issued by the AI assistant at index 210 of an opencode coding session, is deceptively simple. On its surface, it is nothing more than a failed file search — a glob pattern that returned zero results. Yet within the context of the broader conversation, this tiny failure is a revealing artifact. It exposes the assistant's mental model of the project's directory structure, the assumptions baked into its search strategy, and the iterative process by which an autonomous coding agent navigates unfamiliar codebases. To understand why this message was written, we must examine the chain of events that led to it, the reasoning that produced it, and the knowledge it both required and generated.

The Context: A Documentation Update Request

The story begins with a user request at message 208. The user asked the assistant to add protobuf-compiler to the installation dependency lists in the project's documentation, noting that this package was now required by the CuZK proving engine. The user specified: "In install documentation/ add (apt) protobuf-compiler to list of deps (also to other distros mentioned there)." This was a straightforward documentation task — a small but necessary update reflecting a new build dependency.

The assistant's first response (message 209) was to search for the relevant files using a glob pattern: [glob] install/supra-install/**/*. This returned "No files found." The assistant had interpreted the user's phrase "install documentation" literally, looking for a directory path containing the word "install" followed by "supra-install" — a guess based on the project's terminology (the project uses a component called "supraseal" for batch sealing). But this guess was wrong.

The Subject Message: A Broader but Still Incorrect Search

Message 210 represents the assistant's second attempt. The glob pattern was widened from install/supra-install/**/* to **/install/**/* — a recursive search for any directory named "install" anywhere in the project tree. The double asterisk at the beginning (**) means "any number of parent directories," so this pattern would match paths like foo/bar/install/baz/qux.md or documentation/install/something.md. But it would not match a file named installation.md because the pattern specifically requires a directory component named install (not installation).

The result was again "No files found."

This is the entirety of the subject message. It is a tool call followed by its output — no commentary, no reasoning text, no plan adjustment. Just the raw result of a failed search. But this apparent simplicity is misleading. The message is dense with meaning when read in context.

The Assumptions Embedded in the Glob Pattern

The glob **/install/**/* encodes several assumptions about the project's documentation structure:

Assumption 1: Documentation files live in directories named "install." The assistant assumed that installation documentation would be organized under a directory with "install" in its name. This is a reasonable heuristic — many projects do structure their docs this way — but it is not universal. In this project, the installation documentation files are named installation.md and reside under documentation/en/ and documentation/zh/, not under any directory called "install."

Assumption 2: The user's phrase "install documentation" referred to a directory path. The user said "In install documentation/ add..." which could be interpreted either as a directory path or as a topical reference ("in the installation documentation section"). The assistant chose the literal interpretation.

Assumption 3: The project follows a conventional documentation layout. Many open-source projects use a docs/ or documentation/ directory with subdirectories for different languages or topics. The assistant's glob assumed a structure where installation-specific content would be in a dedicated subdirectory, rather than being a single file within a broader documentation tree.

None of these assumptions were malicious or unreasonable. They were educated guesses based on common conventions. But they were wrong, and the glob's failure was the mechanism that revealed this.

Input Knowledge Required to Understand This Message

To fully grasp what this message means, a reader needs:

  1. Knowledge of glob syntax. The ** pattern matches any number of directories recursively. The * matches any filename within a directory. The pattern **/install/**/* means "any file inside any directory named 'install' at any depth."
  2. Knowledge of the previous failed attempt. The assistant had just tried install/supra-install/**/* (message 209) and found nothing. Message 210 is a broader reattempt.
  3. Knowledge of the user's request. The user at message 208 asked for protobuf-compiler to be added to installation dependency lists. The assistant is searching for the files that contain those lists.
  4. Knowledge of the project's domain. The term "supra-install" in the first glob is a reference to "supraseal," a batch sealing component in the Filecoin/Curio ecosystem. The assistant was trying to guess the documentation path based on project terminology.
  5. Knowledge of the broader debugging context. Prior to this documentation request, the assistant had been deep in a complex debugging session involving Pre-Compiled Constraint Evaluator (PCE) extraction, constraint system type harmonization, and a WindowPoSt crash. The documentation update was a side task requested after the main fix was completed.

Output Knowledge Created by This Message

Despite returning "No files found," this message creates valuable knowledge:

  1. Negative evidence: The project's installation documentation is not organized under directories named "install." This eliminates a class of hypotheses about the file structure.
  2. A search boundary: The glob searched the entire project tree (since ** starts from the root). The empty result means no directory named "install" exists anywhere in the project. This is a nontrivial fact about the repository layout.
  3. A signal to pivot: The failed search tells the assistant that its current strategy is not working. It must either try different glob patterns, use different search tools (like grep for content), or read the project's directory listing to understand the actual structure.
  4. A demonstration of the assistant's search methodology: The assistant is using iterative glob-based search, starting with specific guesses and broadening when those fail. This reveals a systematic (if imperfect) approach to navigating unfamiliar code.

The Thinking Process Visible in the Message

While the subject message contains no explicit reasoning text, the thinking process can be inferred from the transition between message 209 and message 210:

  1. Initial hypothesis: The assistant guessed that installation docs would be at install/supra-install/. This was based on the user's phrasing and project terminology.
  2. Hypothesis falsified: The first glob returned nothing. The assistant now knows its specific guess was wrong.
  3. Generalization: Rather than trying another specific path, the assistant generalized the search to **/install/**/* — any directory named "install" anywhere. This is a logical next step: if the specific path was wrong, maybe the docs are under a different "install" directory.
  4. The generalization also fails: The broader search also returns nothing. This forces a more fundamental rethinking of the search strategy. What's notable is what the assistant did not do: it did not immediately fall back to listing the project root directory, nor did it try searching for files containing "install" in their name (rather than directory). The assistant remained within the glob paradigm, which has a blind spot for files whose names contain "install" but are not inside an "install" directory.

Resolution and Significance

The story does not end with this failed glob. In subsequent messages (starting at message 211), the assistant tried **/supra-install/**/* (another guess), then read the project root directory listing, discovered the documentation/ directory, explored it, found installation.md, and ultimately made all the required edits across both English and Chinese documentation files. The successful search required switching from glob-based directory matching to reading the actual directory tree — a different navigational strategy entirely.

This message matters because it illustrates a fundamental challenge in autonomous code manipulation: the agent must build a mental model of the file system without direct perception. Each glob, each read, each grep is an experiment that updates that model. The failed globs are not errors — they are data points. They constrain the hypothesis space and guide the next action. In this case, two failed globs were sufficient to rule out the "install directory" hypothesis and prompt a more direct exploration strategy.

The message also reveals something about the relationship between human and AI in this session. The user's instruction was ambiguous ("In install documentation/") — a human developer familiar with the project would have known the exact file path. The assistant had to disambiguate through search. This is a microcosm of the larger challenge in AI-assisted programming: translating human intent into precise actions in an unfamiliar environment.

In the end, the glob **/install/**/* returning "No files found" is not a failure. It is a successful falsification of a hypothesis, a necessary step on the path to the correct answer. The message is a testament to the iterative, experimental nature of autonomous code navigation — and a reminder that even the simplest tool outputs can carry profound meaning when placed in their proper context.