|
| 1 | +--- |
| 2 | +version: 2026.08.8 |
| 3 | +previousSourceCommit: 4c0f9aee521e30d8e3d35745e52c26111c09b143 |
| 4 | +targetSourceCommit: 0a3757375c9acc15897a0ef314bdfa9fa21487fb |
| 5 | +repository: Blazity/ai-workflow |
| 6 | +--- |
| 7 | + |
| 8 | +<!-- shareable:start --> |
| 9 | +# AI Workflow — 2026.08.8 |
| 10 | + |
| 11 | +## Highlights |
| 12 | + |
| 13 | +A pull request that goes red no longer waits for a person. When continuous integration fails on a pull request this system opened, a fix run starts by itself, reads the failing job's log, and pushes a repair to the same branch. It stops after a configured number of attempts and says so on the pull request instead of looping. |
| 14 | + |
| 15 | +The phase that runs checks before a pull request opens was also reworked around the platform's 300 second limit per invocation, which is what made long check batches die silently in earlier versions. |
| 16 | + |
| 17 | +## What's new |
| 18 | + |
| 19 | +- Failing checks on a pull request start an automatic fix run. The number of attempts is capped per pull request, and when the cap is reached the run says so on the pull request and on Slack rather than stopping quietly. |
| 20 | + <!-- sources: 321 --> |
| 21 | + |
| 22 | +## Improvements and fixes |
| 23 | + |
| 24 | +### Checks before the pull request |
| 25 | + |
| 26 | +- A long check batch now survives the 300 second limit for a single invocation instead of dying halfway with no explanation. |
| 27 | + <!-- sources: 318 --> |
| 28 | +- When the check step itself throws, the run reports the real cause instead of a generic failure. |
| 29 | + <!-- sources: 316 --> |
| 30 | +- Repair cycles before the pull request opens no longer run unless a workflow asks for them. |
| 31 | + <!-- sources: 320 --> |
| 32 | + |
| 33 | +### What the agent does |
| 34 | + |
| 35 | +- When the agent needs something from you, it quotes what it actually found in the repository instead of asking a generic question about which repository to use. |
| 36 | + <!-- sources: 319 --> |
| 37 | +- Research continues when the model names repositories that are already attached, instead of stopping to ask for them. |
| 38 | + <!-- sources: 315 --> |
| 39 | +- The prompt injection screen fails closed when it evaluates no rules, so an empty rule set can no longer let content through unchecked. |
| 40 | + <!-- sources: 295 --> |
| 41 | + |
| 42 | +### Runs, tickets and the editor |
| 43 | + |
| 44 | +- A ticket left in the AI column is released when its run ends without moving it. |
| 45 | + <!-- sources: 296 --> |
| 46 | +- A cancelled run records when it finished and how long it took. |
| 47 | + <!-- sources: 281 --> |
| 48 | +- On GitLab a review is still published when the platform refuses a self-approval. |
| 49 | + <!-- sources: 284 --> |
| 50 | +- Rolling a workflow back to an earlier version loads that version into the editor canvas. |
| 51 | + <!-- sources: 294 --> |
| 52 | + |
| 53 | +## Do you need to do anything? |
| 54 | + |
| 55 | +Yes, if any of your repositories has pre-PR checks configured. Read this one before you upgrade. |
| 56 | + |
| 57 | +Until now, when those checks failed the platform ran a repair agent over the workspace and tried again, up to three times, before giving up. That repair is now off unless a workflow asks for it. A run whose checks fail reports the failure and stops instead of repairing in place. |
| 58 | + |
| 59 | +The reason this matters more than a default usually does: the repair was invisible. A run that failed its checks and was then repaired looks exactly like a run whose checks passed. So some share of the runs that have been going green for you may have been going green because of the repair, not because the checks were clean. Turning it off does not break those runs, it stops them at the publication gate and shows you a failure that was always there. |
| 60 | + |
| 61 | +We hit this ourselves while rehearsing this release. Five runs on our own fixture repository stopped at the gate. The only change that made the sixth publish was setting the fix cycle count back to 3, with the same ticket, the same repository and the same commit. |
| 62 | + |
| 63 | +So: upgrade, then watch the first runs on each repository that has checks configured. If they now stop at the gate, the checks were already failing and the repair was hiding it. Fix the checks, or set the fix cycle count on the pre-PR checks block in the editor to get the old behaviour back deliberately rather than by default. |
| 64 | + |
| 65 | +## Known limitations |
| 66 | + |
| 67 | +Nothing in the product tells you which check command failed. The ticket comment, the run diagnosis and the run trace all say the checks did not pass, and none of them names the command or shows its output. If your checks start failing after this upgrade, expect to reproduce them yourself to find out why. We know this is the wrong way round and it is the next thing we are fixing. |
| 68 | + |
| 69 | +The message on that failure also reads "The checks could not be started", which is misleading: the checks did start, ran, and failed. |
| 70 | + |
| 71 | +The automatic fix on failing checks only runs in a workflow that contains the "PR checks failed" trigger, which is a manual edit in the editor for workflows that already exist. That fix agent works from the failing job's log, so a failure whose cause is not visible in that log can spend its attempts without repairing anything. |
| 72 | + |
| 73 | +<!-- shareable:end --> |
| 74 | + |
| 75 | +## Exact release scope |
| 76 | + |
| 77 | +- [#281](https://github.com/Blazity/ai-workflow/pull/281) — fix: fix(worker): cancelled run must record completedAt/durationSec (RUN-CANCEL-BOOKKEEPING-001) |
| 78 | +- [#284](https://github.com/Blazity/ai-workflow/pull/284) — fix: fix(worker): degrade GitLab review publication when self-approval is refused |
| 79 | +- [#294](https://github.com/Blazity/ai-workflow/pull/294) — fix: fix(dashboard): load the rolled back version into the editor canvas |
| 80 | +- [#295](https://github.com/Blazity/ai-workflow/pull/295) — fix: fix(worker): fail closed when the injection screen evaluates no rules (AIW-287) |
| 81 | +- [#296](https://github.com/Blazity/ai-workflow/pull/296) — fix: fix(worker): evict ticket stuck in AI column when its run terminates without a move (AIW-289) |
| 82 | +- [#314](https://github.com/Blazity/ai-workflow/pull/314) — internal: docs(release): Artur 2026.08.7 |
| 83 | +- [#315](https://github.com/Blazity/ai-workflow/pull/315) — fix: fix(worker): continue research when expansion names only attached repositories (AIW-284) |
| 84 | +- [#316](https://github.com/Blazity/ai-workflow/pull/316) — fix: fix(worker): carry the real cause when the pre-PR checks step throws |
| 85 | +- [#317](https://github.com/Blazity/ai-workflow/pull/317) — internal: chore(release): gate the Artur sync on green source CI and a recorded rehearsal |
| 86 | +- [#318](https://github.com/Blazity/ai-workflow/pull/318) — fix: fix(worker): run pre-PR checks detached so they survive the invocation ceiling |
| 87 | +- [#319](https://github.com/Blazity/ai-workflow/pull/319) — fix: fix(worker): replace generic repository questions with evidence-based clarifications |
| 88 | +- [#320](https://github.com/Blazity/ai-workflow/pull/320) — fix: fix(worker): stop running pre-PR repair cycles by default |
| 89 | +- [#321](https://github.com/Blazity/ai-workflow/pull/321) — feature: feat(worker): auto-fix a pull request when its CI checks fail |
0 commit comments