This looks like a bot PR if i'm honest - and i'm sure the output is - thought he PR might be cold outreach ... so let's try with a few questions first.

I don't see how a random, hidden, non-standard directory, which doesn't render as part of the docs would help users with onboarding.
Instead of discussions - the correct route should be an issue (or the discord server).

There's essentially no details in this. While it's great that it "might" be able to update automatically - it seems pretty much AI generated - and you can see that from afar.

So far - i'm not impressed - as it got some things wrong.
i can ask copilot to get a very similar overview if i'd care about it - we'd still need to make sure it ain't bullshit or wrong.

There's a couple of questions that come to mind before even trying to look at what you're trying to add...

• Will the output change between runs if nothing changed (AI is a random generator after all) - or will just the actually changed methods/classes/relationships change? (so if ClassA wasn't touched, nothing touching ClassA will be modified?)
• what ways are there to "impact" the outcome? (if i want a specific class/file/method excluded as it doesn't make sense - or want it described in a different way)?
• what are dependencies for the free Github Action? is there something proprietary inside, or will it run even if the startup fails?

Hey, thanks for the fast response@xmatthias and thank you for the feedback and the questions!

On your questions:

Will the output change between runs if nothing changed (AI is a random generator after all) - or will just the actually changed methods/classes/relationships change? (so if ClassA wasn't touched, nothing touching ClassA will be modified?)
We will be updating only components in which changes occur, the way the generation works is via Static Analysis and LLMs. The static analysis part associates components with their references, and only if change in those components occur we would update them (this is WiP).

what ways are there to "impact" the outcome? (if i want a specific class/file/method excluded as it doesn't make sense - or want it described in a different way)?
This we haven't thought much about, however we are thinking of introducing custom rules i.e. at the moment test/example folders are ignored. So this can definetly be something that we can look into.

what are dependencies for the free Github Action? is there something proprietary inside, or will it run even if the startup fails?
For now it calls our own endpoint as it was the easiest and fastest way to set it up and get going, however we plan it to be self-containing docker (so that we don't have to host a server)

The .codeboarding directory is just something that we chose as this is the name that we are currently running with. As said in the PR I'd usually do a discussion before PR, but aren't enabled for this repository.

I'll be quite honest - freqtrade is a small project, with an even smaller maintainer range - so we'll not be playing the "test bunnies" for a potential startup.
Unfortunately, we need to be very cautious with our time - which is better spent working on actual features and personally helping users, rather than debugging some random LLM output (which is intended to teach new contribtors - but if it's wrong, it'll cause more work, rather than simplify the process).

Are there any bigger / popular repositories that are already using this successfully?

After having a small look around to see how other projects respond (e.g.matplotlib/matplotlib#30135,psf/requests#6958) - i'm going to close this for similar reason than theirs.

This seems to be some combination of SEO (many backlings to your repo), market research (would people be open for it) combined with abusing open source maintainer's free time to test your product.

The approach taken in this PR is not something I'd accept into this project.
There's 0 clarity how or when or if these files would refresh - and i assume that's all part of your closed source stack.

Also the text is mostly useless and will waste people's time trying to learn the codebase.

(example - especially the second part):

Contains shared utility functions, constants, and helper methods that are common across multiple exchange implementations. This module promotes code reuse and consistency in handling common exchange-related tasks.

This seems good at first - but has 0 clarity which realm these helpers go in. Instead of explaining that a common module promotes code reuse (that's what the name says) - describing the content (provides exchange retry methods, ...) is 100% more helpful to users.

Similar (completely pointless) sentences are throughout some random parts i reviewed - so while it may provide some overview - the explanations need a TON of work.

Feel free to re-submit / open as idea once it's an open source project we can control fully (as in - it's an open source github action or mkdocs plugin, running in our repository, where we get some control over the quality of the output).

For the future (not least because you got the same feedback elsewhere) - you shouldn't open random PR's just because discussions are closed - the proper replacement for a discussion is an issue, not a Pull Request.