mirrors/z3
3
0
Fork 0
mirror of https://github.com/Z3Prover/z3 synced 2025-10-21 14:50:32 +00:00
Code Activity

improve improvers

Browse source
This commit is contained in:
Don Syme 2025-09-17 11:03:23 +01:00
parent 5b70f75d89
commit db8206d265
9 changed files with 34 additions and 52 deletions
Download patch file Download diff file Expand all files Collapse all files

4
.github/workflows/ask.lock.yml generated vendored
View file

@ -2,7 +2,7 @@
# To update this file, edit the corresponding .md file and run:
# gh aw compile
#
# Effective stop-time: 2025-09-19 01:41:09
# Effective stop-time: 2025-09-19 10:02:59
name: "Question Answering Researcher"
on:
@ -1066,7 +1066,7 @@ jobs:
WORKFLOW_NAME="Question Answering Researcher"
# Check stop-time limit
STOP_TIME="2025-09-19 01:41:09"
STOP_TIME="2025-09-19 10:02:59"
echo "Checking stop-time limit: $STOP_TIME"
# Convert stop time to epoch seconds

4
.github/workflows/ci-doctor.lock.yml generated vendored
View file

@ -2,7 +2,7 @@
# To update this file, edit the corresponding .md file and run:
# gh aw compile
#
# Effective stop-time: 2025-09-19 01:41:09
# Effective stop-time: 2025-09-19 10:02:59
name: "CI Failure Doctor"
"on":
@ -547,7 +547,7 @@ jobs:
WORKFLOW_NAME="CI Failure Doctor"
# Check stop-time limit
STOP_TIME="2025-09-19 01:41:09"
STOP_TIME="2025-09-19 10:02:59"
echo "Checking stop-time limit: $STOP_TIME"
# Convert stop time to epoch seconds

15
.github/workflows/daily-backlog-burner.lock.yml generated vendored
View file

@ -2,7 +2,7 @@
# To update this file, edit the corresponding .md file and run:
# gh aw compile
#
# Effective stop-time: 2025-09-19 01:41:09
# Effective stop-time: 2025-09-19 10:02:59
name: "Daily Backlog Burner"
"on":
@ -527,7 +527,7 @@ jobs:
WORKFLOW_NAME="Daily Backlog Burner"
# Check stop-time limit
STOP_TIME="2025-09-19 01:41:09"
STOP_TIME="2025-09-19 10:02:59"
echo "Checking stop-time limit: $STOP_TIME"
# Convert stop time to epoch seconds
@ -564,7 +564,7 @@ jobs:
1. Backlog research (if not done before).
1a. Check carefully if an open issue with title "${{ github.workflow }} - Research, Roadmap and Plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1a. Check carefully if an open issue with label "daily-backlog-burner-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1b. Do some deep research into the backlog in this repo.
- Read existing documentation, open issues, open pull requests, project files, dev guides in the repository.
@ -577,7 +577,7 @@ jobs:
- Identify any patterns or common themes among the issues, such as recurring bugs, feature requests, or areas of improvement.
- Look for any issues that may be duplicates or closely related to each other, and consider whether they can be consolidated or linked together.
1c. Use this research to create an issue with title "${{ github.workflow }} - Research, Roadmap and Plan". This issue should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
1c. Use this research to create an issue with title "${{ github.workflow }} - Research, Roadmap and Plan" and label "daily-backlog-burner-plan". This issue should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
2. Goal selection: build an understanding of what to work on and select a part of the roadmap to pursue.
@ -611,11 +611,10 @@ jobs:
4c. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
4d. Add a very brief comment to the issue from step 1a if it exists, saying you have worked on the particular goal and linking to the pull request you created.
5. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
5. If you didn't succeed, create an issue with title starting with "${{ github.workflow }}", summarizing similar information to above.
6. If you encounter any unexpected failures or have questions, add comments to the pull request or issue to seek clarification or assistance.
6. If you encounter any unexpected failures or have questions, add
comments to the pull request or issue to seek clarification or assistance.
> NOTE: Never make direct pushes to the default (main) branch. Always create a pull request. The default (main) branch is protected and you will not be able to push to it.

11
.github/workflows/daily-backlog-burner.md vendored
View file

@ -44,7 +44,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
1. Backlog research (if not done before).
1a. Check carefully if an open issue with title "${{ github.workflow }} - Research, Roadmap and Plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1a. Check carefully if an open issue with label "daily-backlog-burner-plan" exists using `search_issues`. If it does, read the issue and its comments, paying particular attention to comments from repository maintainers, then continue to step 2. If the issue doesn't exist, follow the steps below to create it:
1b. Do some deep research into the backlog in this repo.
- Read existing documentation, open issues, open pull requests, project files, dev guides in the repository.
@ -57,7 +57,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
- Identify any patterns or common themes among the issues, such as recurring bugs, feature requests, or areas of improvement.
- Look for any issues that may be duplicates or closely related to each other, and consider whether they can be consolidated or linked together.
1c. Use this research to create an issue with title "${{ github.workflow }} - Research, Roadmap and Plan". This issue should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
1c. Use this research to create an issue with title "${{ github.workflow }} - Research, Roadmap and Plan" and label "daily-backlog-burner-plan". This issue should be a comprehensive plan for dealing with the backlog in this repo, and summarize your findings from the backlog research, including any patterns or themes you identified, and your recommendations for addressing the backlog. Then exit this entire workflow.
2. Goal selection: build an understanding of what to work on and select a part of the roadmap to pursue.
@ -91,11 +91,10 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
4c. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
4d. Add a very brief comment to the issue from step 1a if it exists, saying you have worked on the particular goal and linking to the pull request you created.
5. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
5. If you didn't succeed, create an issue with title starting with "${{ github.workflow }}", summarizing similar information to above.
6. If you encounter any unexpected failures or have questions, add comments to the pull request or issue to seek clarification or assistance.
6. If you encounter any unexpected failures or have questions, add
comments to the pull request or issue to seek clarification or assistance.
@include agentics/shared/no-push-to-main.md

16
.github/workflows/daily-perf-improver.lock.yml generated vendored
View file

@ -2,7 +2,7 @@
# To update this file, edit the corresponding .md file and run:
# gh aw compile
#
# Effective stop-time: 2025-09-19 01:41:09
# Effective stop-time: 2025-09-19 10:02:59
name: "Daily Perf Improver"
"on":
@ -541,7 +541,7 @@ jobs:
WORKFLOW_NAME="Daily Perf Improver"
# Check stop-time limit
STOP_TIME="2025-09-19 01:41:09"
STOP_TIME="2025-09-19 10:02:59"
echo "Checking stop-time limit: $STOP_TIME"
# Convert stop time to epoch seconds
@ -612,13 +612,13 @@ jobs:
2a. Check if `.github/actions/daily-perf-improver/build-steps/action.yml` exists in this repo. Note this path is relative to the current directory (the root of the repo). If this file exists then continue to step 3. Otherwise continue to step 2b.
2b. Check if an open pull request with title "${{ github.workflow }}: Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2b. Check if an open pull request with title "${{ github.workflow }} - Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2c. Have a careful think about the CI commands needed to build the project and set up the environment for individual performance development work, assuming one set of build assumptions and one architecture (the one running). Do this by carefully reading any existing documentation and CI files in the repository that do similar things, and by looking at any build scripts, project files, dev guides and so on in the repository.
2d. Create the file `.github/actions/daily-perf-improver/build-steps/action.yml` as a GitHub Action containing these steps, ensuring that the action.yml file is valid and carefully cross-checking with other CI files and devcontainer configurations in the repo to ensure accuracy and correctness. Each step should append its output to a file called `build-steps.log` in the root of the repository. Ensure that the action.yml file is valid and correctly formatted.
2e. Make a pull request for the addition of this file, with title "${{ github.workflow }}: Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project. Exit the entire workflow.
2e. Make a pull request for the addition of this file, with title "${{ github.workflow }} - Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project. Exit the entire workflow.
2f. Try to run through the steps you worked out manually one by one. If the a step needs updating, then update the branch you created in step 2e. Continue through all the steps. If you can't get it to work, then create an issue describing the problem and exit the entire workflow.
@ -689,13 +689,7 @@ jobs:
5d. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
5e. Add a very brief comment to the issue from step 1a if it exists, saying you have worked on the particular performance goal and linking to the pull request you created. Assess the work that you've done and write notes about what you would have needed to do to make things go more smoothly, and include these notes in the comment. Leave notes about the fastest ways to run builds, tests, benchmarks and so on, including the ways to avoid any problems you encountered.
6. If you didn't succeed in improving performance, create an issue with title starting with "${{ github.workflow }}", summarizing similar information to above.
7. If you encounter any unexpected failures or have questions, add comments to the pull request or issue to seek clarification or assistance.
8. If you are unable to improve performance in a particular area, add a comment explaining why and what you tried. If you have any relevant links or resources, include those as well.
6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
> NOTE: Never make direct pushes to the default (main) branch. Always create a pull request. The default (main) branch is protected and you will not be able to push to it.

12
.github/workflows/daily-perf-improver.md vendored
View file

@ -94,13 +94,13 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
2a. Check if `.github/actions/daily-perf-improver/build-steps/action.yml` exists in this repo. Note this path is relative to the current directory (the root of the repo). If this file exists then continue to step 3. Otherwise continue to step 2b.
2b. Check if an open pull request with title "${{ github.workflow }}: Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2b. Check if an open pull request with title "${{ github.workflow }} - Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2c. Have a careful think about the CI commands needed to build the project and set up the environment for individual performance development work, assuming one set of build assumptions and one architecture (the one running). Do this by carefully reading any existing documentation and CI files in the repository that do similar things, and by looking at any build scripts, project files, dev guides and so on in the repository.
2d. Create the file `.github/actions/daily-perf-improver/build-steps/action.yml` as a GitHub Action containing these steps, ensuring that the action.yml file is valid and carefully cross-checking with other CI files and devcontainer configurations in the repo to ensure accuracy and correctness. Each step should append its output to a file called `build-steps.log` in the root of the repository. Ensure that the action.yml file is valid and correctly formatted.
2e. Make a pull request for the addition of this file, with title "${{ github.workflow }}: Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project. Exit the entire workflow.
2e. Make a pull request for the addition of this file, with title "${{ github.workflow }} - Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project. Exit the entire workflow.
2f. Try to run through the steps you worked out manually one by one. If the a step needs updating, then update the branch you created in step 2e. Continue through all the steps. If you can't get it to work, then create an issue describing the problem and exit the entire workflow.
@ -171,13 +171,7 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
5d. After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
5e. Add a very brief comment to the issue from step 1a if it exists, saying you have worked on the particular performance goal and linking to the pull request you created. Assess the work that you've done and write notes about what you would have needed to do to make things go more smoothly, and include these notes in the comment. Leave notes about the fastest ways to run builds, tests, benchmarks and so on, including the ways to avoid any problems you encountered.
6. If you didn't succeed in improving performance, create an issue with title starting with "${{ github.workflow }}", summarizing similar information to above.
7. If you encounter any unexpected failures or have questions, add comments to the pull request or issue to seek clarification or assistance.
8. If you are unable to improve performance in a particular area, add a comment explaining why and what you tried. If you have any relevant links or resources, include those as well.
6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
@include agentics/shared/no-push-to-main.md

12
.github/workflows/daily-test-improver.lock.yml generated vendored
View file

@ -2,7 +2,7 @@
# To update this file, edit the corresponding .md file and run:
# gh aw compile
#
# Effective stop-time: 2025-09-19 01:41:09
# Effective stop-time: 2025-09-19 10:02:59
name: "Daily Test Coverage Improver"
"on":
@ -541,7 +541,7 @@ jobs:
WORKFLOW_NAME="Daily Test Coverage Improver"
# Check stop-time limit
STOP_TIME="2025-09-19 01:41:09"
STOP_TIME="2025-09-19 10:02:59"
echo "Checking stop-time limit: $STOP_TIME"
# Convert stop time to epoch seconds
@ -598,13 +598,13 @@ jobs:
2a. Check if `.github/actions/daily-test-improver/coverage-steps/action.yml` exists in this repo. Note this path is relative to the current directory (the root of the repo). If it exists then continue to step 3. Otherwise continue to step 2b.
2b. Check if an open pull request with title "${{ github.workflow }}: Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2b. Check if an open pull request with title "${{ github.workflow }} - Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2c. Have a careful think about the CI commands needed to build the repository, run tests, produce a combined coverage report and upload it as an artifact. Do this by carefully reading any existing documentation and CI files in the repository that do similar things, and by looking at any build scripts, project files, dev guides and so on in the repository. If multiple projects are present, perform build and coverage testing on as many as possible, and where possible merge the coverage reports into one combined report. Work out the steps you worked out, in order, as a series of YAML steps suitable for inclusion in a GitHub Action.
2d. Create the file `.github/actions/daily-test-improver/coverage-steps/action.yml` containing these steps, ensuring that the action.yml file is valid. Leave comments in the file to explain what the steps are doing, where the coverage report will be generated, and any other relevant information. Ensure that the steps include uploading the coverage report(s) as an artifact called "coverage". Each step of the action should append its output to a file called `coverage-steps.log` in the root of the repository. Ensure that the action.yml file is valid and correctly formatted.
2e. Before running any of the steps, make a pull request for the addition of the `action.yml` file, with title "${{ github.workflow }}: Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project.
2e. Before running any of the steps, make a pull request for the addition of the `action.yml` file, with title "${{ github.workflow }} - Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project.
2f. Try to run through the steps you worked out manually one by one. If the a step needs updating, then update the branch you created in step 2e. Continue through all the steps. If you can't get it to work, then create an issue describing the problem and exit the entire workflow.
@ -658,11 +658,9 @@ jobs:
- After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
4i. Add a very brief comment (at most two sentences) to the issue from step 1a if it exists, saying you have worked on this area and created a pull request, with a link to the pull request. Assess the work that you've done and write notes about what you would have needed to do to make things go more smoothly, and include these notes in the comment. Leave notes about the fastest ways to run tests, how to get coverage reports, and so on.
5. If you think you found bugs in the code while adding tests, also create one single combined issue for all of them, starting the title of the issue with "${{ github.workflow }}". Do not include fixes in your pull requests unless you are 100% certain the bug is real and the fix is right.
6. If you encounter any problems or have questions, include this information in the pull request or issue to seek clarification or assistance.
6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
> NOTE: Never make direct pushes to the default (main) branch. Always create a pull request. The default (main) branch is protected and you will not be able to push to it.

8
.github/workflows/daily-test-improver.md vendored
View file

@ -87,13 +87,13 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
2a. Check if `.github/actions/daily-test-improver/coverage-steps/action.yml` exists in this repo. Note this path is relative to the current directory (the root of the repo). If it exists then continue to step 3. Otherwise continue to step 2b.
2b. Check if an open pull request with title "${{ github.workflow }}: Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2b. Check if an open pull request with title "${{ github.workflow }} - Updates to complete configuration" exists in this repo. If it does, add a comment to the pull request saying configuration needs to be completed, then exit the workflow. Otherwise continue to step 2c.
2c. Have a careful think about the CI commands needed to build the repository, run tests, produce a combined coverage report and upload it as an artifact. Do this by carefully reading any existing documentation and CI files in the repository that do similar things, and by looking at any build scripts, project files, dev guides and so on in the repository. If multiple projects are present, perform build and coverage testing on as many as possible, and where possible merge the coverage reports into one combined report. Work out the steps you worked out, in order, as a series of YAML steps suitable for inclusion in a GitHub Action.
2d. Create the file `.github/actions/daily-test-improver/coverage-steps/action.yml` containing these steps, ensuring that the action.yml file is valid. Leave comments in the file to explain what the steps are doing, where the coverage report will be generated, and any other relevant information. Ensure that the steps include uploading the coverage report(s) as an artifact called "coverage". Each step of the action should append its output to a file called `coverage-steps.log` in the root of the repository. Ensure that the action.yml file is valid and correctly formatted.
2e. Before running any of the steps, make a pull request for the addition of the `action.yml` file, with title "${{ github.workflow }}: Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project.
2e. Before running any of the steps, make a pull request for the addition of the `action.yml` file, with title "${{ github.workflow }} - Updates to complete configuration". Encourage the maintainer to review the files carefully to ensure they are appropriate for the project.
2f. Try to run through the steps you worked out manually one by one. If the a step needs updating, then update the branch you created in step 2e. Continue through all the steps. If you can't get it to work, then create an issue describing the problem and exit the entire workflow.
@ -147,11 +147,9 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
- After creation, check the pull request to ensure it is correct, includes all expected files, and doesn't include any unwanted files or changes. Make any necessary corrections by pushing further commits to the branch.
4i. Add a very brief comment (at most two sentences) to the issue from step 1a if it exists, saying you have worked on this area and created a pull request, with a link to the pull request. Assess the work that you've done and write notes about what you would have needed to do to make things go more smoothly, and include these notes in the comment. Leave notes about the fastest ways to run tests, how to get coverage reports, and so on.
5. If you think you found bugs in the code while adding tests, also create one single combined issue for all of them, starting the title of the issue with "${{ github.workflow }}". Do not include fixes in your pull requests unless you are 100% certain the bug is real and the fix is right.
6. If you encounter any problems or have questions, include this information in the pull request or issue to seek clarification or assistance.
6. At the end of your work, add a very, very brief comment (at most two-sentences) to the issue from step 1a, saying you have worked on the particular goal, linking to any pull request you created, and indicating whether you made any progress or not.
@include agentics/shared/no-push-to-main.md

4
.github/workflows/pr-fix.lock.yml generated vendored
View file

@ -2,7 +2,7 @@
# To update this file, edit the corresponding .md file and run:
# gh aw compile
#
# Effective stop-time: 2025-09-19 01:41:09
# Effective stop-time: 2025-09-19 10:02:59
name: "PR Fix"
on:
@ -1071,7 +1071,7 @@ jobs:
WORKFLOW_NAME="PR Fix"
# Check stop-time limit
STOP_TIME="2025-09-19 01:41:09"
STOP_TIME="2025-09-19 10:02:59"
echo "Checking stop-time limit: $STOP_TIME"
# Convert stop time to epoch seconds