Bug - Non-code configuraiton files for scanning/behavior tooling should be hidden

[trevor-vaughan]

Describe the bug

The current system appears to require users to place a complytime.yaml file in their repository. In order to be more polite, a .complytime/ directory should be used to house ComplyTime materials.

Expected behavior

I did not expect (yet another) file to clutter up my repository.

Additional context

Not only do flat files confuse humans (anything visible should be important to the subject of the repository) but they also confuse LLMs that are trying to gain context. Moving the configuration (and other) files to .complytime/ would help reduce confusion.

[jpower432]

Seems like this could overlap with #433 which just advocates for the location of this file to be configurable. complyctl already creates a .complytime folder in the repo for any generated/results files so we could implement #433 and simply change the default location from the current working directory to .complytime.

[marcusburghardt]

I agree the proposal in #433 should solve this. We can set the default directory for complytime.yaml aligned to the default workspace while allowing users to configure other places as their preferences. Once this feature is there it is just a matter of configuration.

By the way, this is not a bug. It is working as it was initially designed. A new feature will only make it more flexible.

[trevor-vaughan]

I noted it as a bug from a user point of view because I don't think it follows existing best practices. Flawed designs happen to all of us.

[jpower432]

Regardless of how we label the current implementation, moving to a .complytime/ directory seems like a solid path forward for better organization. Coding standards like repository organization are highly subjective, some people value discoverability. I guess the fact that the file is not named .complytime.yaml could be considered a bug. Since there's consensus that this will improve the user experience, let’s focus on how to implement the configurable path as discussed in #433.