Merge branch 'main' into daily-test-coverage-improver-html-attribute-extensions

Author: dsyme

.github/workflows/ci-doctor.lock.yml

@@ -17,7 +17,6 @@ permissions:
   statuses: read # needed to read commit statuses
   issues: write # needed to create investigation issues
   pull-requests: write # needed to comment on PRs if failure is related
-  models: read # typically needed for AI workflows
 
 tools:
   github:

.github/workflows/ci-doctor.md

@@ -139,20 +139,13 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
      - Reducing network calls
      - Improving concurrency
      - Using profiling tools to identify bottlenecks
-     - Improving engineering practices
-     - Other techniques to improve performance 
+     - Other techniques to improve performance or performance engineering practices
 
-     If you do benchmarking then make sure you actually take before/after benchmarking performance figures. Provide benchmarking, profiling or other evidence that the thing you're optimizing is important to a significant realistic workload.
+     If you do benchmarking then make sure you plan ahead about how to take before/after benchmarking performance figures. You may need to write the benchmarks first, then run them, then implement your changes. Or you might implement your changes, then write benchmarks, then stash or disable the changes and take "before" measurements, then apply the changes to take "after" measurements, or other techniques to get before/after measurements. It's just great if you can provide benchmarking, profiling or other evidence that the thing you're optimizing is important to a significant realistic workload. Run individual benchmarks and comparing results. Benchmarking should be done in a way that is reliable, reproducible and quick, preferably by running iteration running a small subset of targeted relevant benchmarks at a time. Because you're running in a virtualised environment wall-clock-time measurements may not be 100% accurate, but it is probably good enough to see if you're making significant improvements or not. Even better if you can use cycle-accurate timers or similar.
 
-   4c. Ensure the code still works as expected and that any existing relevant tests pass. 
+   4c. Ensure the code still works as expected and that any existing relevant tests pass. Add new tests if appropriate and make sure they pass too.
 
-   4d. After making the changes, if appropriate measure their impact on performance.
-   
-     - Get actual performance numbers
-     - If you can't successfully measure the performance impact, then continue but make a note of what you tried.
-     - Run individual benchmarks and comparing results.
-     - Benchmarking should be done in a way that is reliable and reproducible, though beware that because you're running in a virtualised environment wall-clock-time measurements may not be 100% accurate.
-     - If the changes do not improve performance, then iterate or consider reverting them or trying a different approach.
+   4d. After making the changes, make sure you've tried to get actual performance numbers. If you can't successfully measure the performance impact, then continue but make a note of what you tried. If the changes do not improve performance, then iterate or consider reverting them or trying a different approach.
 
    4e. Apply any automatic code formatting used in the repo
 

.github/workflows/daily-perf-improver.lock.yml

@@ -132,11 +132,11 @@ Your name is ${{ github.workflow }}. Your job is to act as an agentic coder for
 
    4g. Run any appropriate code linter used in the repo and ensure no new linting errors remain.
 
-   4h. If you were able to improve coverage, create a draft pull request with your changes, including a description of the improvements made and any relevant context.
+   4h. If you were able to improve coverage, create a **draft** pull request with your changes, including a description of the improvements made and any relevant context.
 
     - Use Bash `git add ...`, `git commit ...`, `git push ...` etc. to push the changes to your branch.
 
-    - Use Bash `gh pr create --repo ${{ github.repository }} ...` to create a pull request with the changes.
+    - Use Bash `gh pr create --repo ${{ github.repository }} --draft ...` to create a pull request with the changes.
 
     - Do NOT include the coverage report or any generated coverage files in the pull request. Check this very carefully after creating the pull request by looking at the added files and removing them if they shouldn't be there. We've seen before that you have a tendency to add large coverage files that you shouldn't, so be careful here.
 

.github/workflows/daily-perf-improver.md

@@ -12,7 +12,6 @@ permissions:
   statuses: read # needed to read commit statuses
   issues: read # needed to create investigation issues
   pull-requests: write # needed to comment on PRs if failure is related
-  models: read # typically needed for AI workflows
 
 tools:
   github:

.github/workflows/daily-test-improver.lock.yml

@@ -29,6 +29,7 @@
     <Compile Include="JsonParserProperties.fs" />
     <Compile Include="JsonConversions.fs" />
     <Compile Include="JsonRuntime.fs" />
+    <Compile Include="JsonSchema.fs" />
     <Compile Include="CsvReader.fs" />
     <Compile Include="CsvFile.fs" />
     <Compile Include="HtmlCharRefs.fs" />