The documentation is not clear on the recursion behaviour of pluto detect-files -d .

I've traced it like so on mac:

sudo dtruss -f -t open pluto detect-files -d .

and found that it seems to recurse 2 directory levels, but if there are yamls one subdirectory level down.

If you start at the top of a repo root and there are no yamls within 1 sub-level due to directory structures like app/base/*.yaml then pluto is not opening any yaml files and silently failing to scan.

Describe the solution you'd like

1. The recursion behaviour should be clearly documented either way
2. Ideally pluto detect-files -d . should recurse all subdirectory levels to find yamls in kubernetes repo trees
3. Optional: control recursion depth with a flag

Describe alternatives you've considered

Shell script recursing all directories and running pluto detect-files -d . at each level.

https://github.com/HariSekhon/DevOps-Bash-tools/blob/master/kubernetes/pluto_detect_kustomize_materialize.sh

Additional Context

I'm trying to find deprecated API objects affecting my Kubernetes cluster upgrade that are inherited from Helm charts embedded in kustomization.yaml which are not currently detectable by Nova because the helm charts are not installed directy, and are not detectable by pluto unless I materialize the kustomization.yaml, as I do with this script:

https://github.com/HariSekhon/DevOps-Bash-tools/blob/master/kubernetes/kustomize_materialize.sh

When I run pluto detect-files -d . on the resultant directory tree full of kustomization.materialized.yaml files, it fails to open and test any yamls unless I run pluto in each directory level.

I've worked around it for now using this script:

https://github.com/HariSekhon/DevOps-Bash-tools/blob/master/kubernetes/pluto_detect_kustomize_materialize.sh

Somewhat related to #431

Pluto version

$ pluto version
Version:5.12.0 Commit:dc11ba13c840de0034510bff4712f651bf5ff45c