## TL;DR
Make sure the namespace's code is in Doxygen's INPUT and that the reference uses the fully qualified name. Doxygen cannot resolve what it never parsed.

## Error
```text
warning: the name 'mylib::detail' could not be resolved
```

## Steps
1. Check the Doxyfile INPUT paths: the file defining the namespace must be included, and EXCLUDE patterns must not filter it out. Expected: the defining file is inside INPUT and outside EXCLUDE.
2. Verify the namespace is actually documented or at least declared in the parsed code; undocumented anonymous details are invisible to the resolver. Expected: the symbol exists in the parsed sources.
3. Use the fully qualified name in the referencing comment (e.g. `mylib::detail::Helper`), since short names resolve only within scope. Expected: references use complete paths.
4. Re-run `doxygen Doxyfile` and confirm the warning is gone. Expected: zero unresolved-name warnings.

## When to use
- Doxygen warns a name or namespace could not be resolved
- References use short names across namespace boundaries
- INPUT was narrowed and symbols dropped out of the parse

## When not to use
- The warning is about an undocumented parameter (different warning)
- Graphviz dot fails to run (an installation problem)
- The symbol is intentionally internal (document the exclusion instead)

## Tool compatibility
Doxygen 1.9 through 1.12. Name resolution rules are stable across these versions.

### Variant phrasings
### could not be resolved for a class in another namespace
Same fix: fully qualify the name and confirm the class's file is in INPUT.

### warning appears after moving headers
Update INPUT to the new header locations; stale paths silently drop symbols.

## Why it happens
Doxygen resolves references against the symbols it parsed, not against your compiler's view. Anything outside INPUT, excluded, or referenced by a short name from the wrong scope fails resolution.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_PQHUQRKuVHMk1AFFnPOCjg