Ai Codebase Grounding And Context

The repo uses a custom Result error type and a logging wrapper everywhere. The Droid adds a new module that throws raw exceptions and calls print().

Inspect neighboring code first and follow the project's established patterns (the Result type, the logging wrapper, naming, file layout) so the change reads as native to the codebase. Grounding means matching existing conventions, not importing a generic template.

For a one-line config change, the Droid pulls hundreds of unrelated files into context, diluting the relevant signal.

Retrieve the minimal context that the task needs (the config file, its readers, the validating test) rather than flooding context with the whole repo. Tight, relevant grounding reduces hallucinated edits and keeps the change reviewable.

The Droid needs a helper to parse a config. Instead of using the repo's existing parser, it calls a plausible-sounding helper that does not exist.

Use functions/types that actually exist in the codebase or its declared dependencies; verify a symbol exists before calling it. When a needed helper is absent, implement it explicitly rather than calling an imagined API and hoping it resolves.