Claude support and doc updates - #520
Conversation
Current statusI consider the CLAUDE/USAGE.md files mostly done - maybe I will add the ones on the C frontend to this PR or maybe do that separately, but that is coming soon as well. But the core/common parts are done, in my opinion. I also have a file called I am still working on improving the wiki and sorting out that part. But in the meantime, it would be nice to get some feedback on the generated files: FilesRepo root
common/
solver/
@mondokm , @as3810t may I ask you to take a quick look of the CLAUDE and USING files and the issue doc? I don't need you to go through all of them, just read and leave a review on the ones that you think you know best. Feel free to recommend other reviewers for them, I just didn't want to ping too many people at once. :D |
|
One thing that I noticed on first glance: the build info in the root CLAUDE.md is very xcfa specific, and |
|
/version-bump patch |
|
/version-bump patch |
mondokm
left a comment
There was a problem hiding this comment.
I think we can merge this
|
/version-bump patch |
|
/format |
Release PreviewVersion: 7.3.2 Release Notes: I started working on adding modular summaries per gradle package. As a side effect, I will also probably update some docs and have a list of possible smells/issues I/we can go through. The root CLAUDE.md is unfortunately not optional, as that is the only place claude automatically adds it to context from - but I think that's fine. The per package files are good, because they will only get loaded into context in a lazy manner, only when they are actually needed. But I will try to do most of core/common for sure. I will probably not be able to generate these docs for all subprojects, so in the main CLAUDE.md I added an instruction for claude to ask the developer about also generating missing per-package docs when working with that given package. This also distributes reviewing these generated docs better over time and developers. The generated docs are mainly about the code, rarely about an actual overview of methods or algorithms. However, they include "invariants", e.g., what to do to NOT break existing stuff and recipes, e.g., how to add a new formalism to cegar (some git history was checked for this), which I think is great. They might also be useful for developers, students, etc., not just agents. How these docs were generatedThe CLAUDE.md/USING.md files were produced by a phased, code-grounded workflow rather than written from memory:
Modified subprojects (since v7.3.1): Files to be uploaded:
|
|
Benchexec test report for a selection of benchmarks (correct / incorrect / all):
📦 Download the results - extract the zip and open the |
I started working on adding modular summaries per gradle package. As a side effect, I will also probably update some docs and have a list of possible smells/issues I/we can go through.
The root CLAUDE.md is unfortunately not optional, as that is the only place claude automatically adds it to context from - but I think that's fine.
The per package files are good, because they will only get loaded into context in a lazy manner, only when they are actually needed. But I will try to do most of core/common for sure.
I will probably not be able to generate these docs for all subprojects, so in the main CLAUDE.md I added an instruction for claude to ask the developer about also generating missing per-package docs when working with that given package. This also distributes reviewing these generated docs better over time and developers.
The generated docs are mainly about the code, rarely about an actual overview of methods or algorithms. However, they include "invariants", e.g., what to do to NOT break existing stuff and recipes, e.g., how to add a new formalism to cegar (some git history was checked for this), which I think is great. They might also be useful for developers, students, etc., not just agents.
How these docs were generated
The CLAUDE.md/USING.md files were produced by a phased, code-grounded workflow rather than written from memory: