feat(cli): load quickstart catalogs using in-memory repository clone

[sachin9058]

Summary

Depends on #6364

Update the quickstart command to dynamically load rule and profile catalogs from a remote repository using an in-memory git clone.

Previously, the quickstart flow relied on embedded/static catalog data and installed a limited set of rules. This change enables loading catalogs directly from a repository at runtime, improving flexibility and aligning with the direction discussed in #6339.

The clone operation is performed inline using go-git with in-memory storage, avoiding filesystem side effects and keeping the CLI lightweight. If cloning or parsing fails, the existing embedded catalog flow is used as a fallback to preserve backward compatibility.

This addresses part of #6339 by enabling dynamic catalog loading from a repository.

Testing

• Ran:

  make lint-fix
  go test ./...

• Verified CLI behavior by running:
  go run ./cmd/cli quickstart
• Confirmed catalog loading works with a valid repository
• Verified fallback behavior when repository cloning fails (invalid repo URL)
• Ensured no regressions in existing quickstart functionality

[coveralls]

Coverage is 60.021% — sachin9058:feat/quickstart-inmemory-catalog-clean into mindersec:main. No base build found for mindersec:main.

[evankanderson]

Is this building on #6364? Without referencing related PRs, it's a little hard to track whether some PRs should be reviewed before others.

[sachin9058]

@evankanderson Yes this builds on #6364.

#6364 introduces the --catalog-repo flag and wiring for configurable catalog sources, and this PR extends that by actually loading the catalogs from the repository using an in-memory clone.

Happy to rebase or adjust the ordering if you'd prefer these to be reviewed/merged in a specific sequence.

[evankanderson]

@evankanderson Yes this builds on #6364.

#6364 introduces the --catalog-repo flag and wiring for configurable catalog sources, and this PR extends that by actually loading the catalogs from the repository using an in-memory clone.

Happy to rebase or adjust the ordering if you'd prefer these to be reviewed/merged in a specific sequence.

I'm just trying to figure out what the long-term code shape looks like -- if we were to merge these two PRs and then you were to go off and do something entirely different, would it be clear to a future contributor what the next steps were?

I think the plan is:

1. Add --catalog-repo
2. Clone the existing rules from --catalog-repo
3. Find a profile & ruletypes from clone using recursive file enumeration like minder apply -f
4. Add a function to find profiles & rulesets based on README.mds
5. Present a menu from the located README.md contents, and apply the results

Is that about right?

[sachin9058]

@evankanderson Yes this builds on #6364.
#6364 introduces the --catalog-repo flag and wiring for configurable catalog sources, and this PR extends that by actually loading the catalogs from the repository using an in-memory clone.
Happy to rebase or adjust the ordering if you'd prefer these to be reviewed/merged in a specific sequence.

I'm just trying to figure out what the long-term code shape looks like -- if we were to merge these two PRs and then you were to go off and do something entirely different, would it be clear to a future contributor what the next steps were?

I think the plan is:

1. Add `--catalog-repo`

2. Clone the existing rules from `--catalog-repo`

3. Find a profile & ruletypes from clone using recursive file enumeration like `minder apply -f`

4. Add a function to find profiles & rulesets based on `README.md`s

5. Present a menu from the located `README.md` contents, and apply the results

Is that about right?

@evankanderson Yes, that’s very close to what I had in mind.

The idea is to build the quickstart flow around dynamically discovering profiles and rules from a repository, rather than relying on embedded catalogs.

Your outlined steps match the intended direction:

• use --catalog-repo as the source
• clone and enumerate available profiles/rules
• surface options based on README.md metadata
• allow users to select and apply them

One thing I’m thinking about is keeping the catalog discovery and selection logic separate from the CLI interaction, so it can be reused or extended later (e.g., for non-interactive flows).

Happy to adjust the implementation to better align with this structure if you’d prefer a different breakdown.

[evankanderson]

One thing I’m thinking about is keeping the catalog discovery and selection logic separate from the CLI interaction, so it can be reused or extended later (e.g., for non-interactive flows).

We haven't been perfect about this, but in general I'd like to see complex logic isolated from /cmd/...; we've made a good first pass of collecting input/output (formatting, file detection, prompts, grpc setup, etc) in internal/util/cli for command-line and client-focused functionality, with some generally-useful functions living in pkg/ (e.g pkg/fileconvert, pkg/config).

[sachin9058]

We haven't been perfect about this, but in general I'd like to see complex logic isolated from /cmd/...; we've made a good first pass of collecting input/output (formatting, file detection, prompts, grpc setup, etc) in internal/util/cli for command-line and client-focused functionality, with some generally-useful functions living in pkg/ (e.g pkg/fileconvert, pkg/config).

@evankanderson That makes sense — I agree with keeping the more complex catalog loading and discovery logic out of /cmd/....

Right now some of that logic is still living in the command, but I can refactor it so that:

• catalog loading / filesystem traversal lives in a reusable package (likely under internal/ or pkg/)
• the CLI layer only handles prompting, formatting, and orchestration

This should make the flow easier to follow and also reusable for non-interactive use cases later.

Happy to restructure this in this PR if you’d prefer, or follow up with a separate refactor.

[evankanderson]

I think we're iterating in #6364 and will get back to this after that review has settled the underlying file loading (at which point, this might have space to adopt higher-level features).

[github-actions]

This PR needs additional information before we can continue. It is now marked as stale because it has been open for 30 days with no activity. Please provide the necessary details to continue or it will be closed in 30 days.