also looking at this
fix(ci): land the lock-file repair instead of describing it
#1408
6 files
+193
-15
| @@ -133,7 +133,7 @@ The log is matched against failure signatures before any model is involved. That | ||
| 133 | 133 | |
| 134 | 134 | | Kind | What it means | Repair | |
| 135 | 135 | | --- | --- | --- | |
| 136 | | `lockfile-drift` | The lock file is out of step with its manifest | Regenerated mechanically | | |
| 136 | | `lockfile-drift` | The lock file is out of step with its manifest | Regenerated, committed and pushed | | |
| 137 | 137 | | `flake` | Network, rate limit or runner problem | Worth one retry | |
| 138 | 138 | | `install` | Dependencies could not be resolved | Agent, or reported | |
| 139 | 139 | | `type-error` | The change does not type-check | Agent | |
| @@ -141,6 +141,18 @@ The log is matched against failure signatures before any model is involved. That | ||
| 141 | 141 | | `lint` | Lint or formatting violations | Agent | |
| 142 | 142 | | `unknown` | Nothing recognisable | Reported, with the interesting log lines | |
| 143 | 143 | |
| 144 | ### Re-running after a mechanical fix | |
| 145 | ||
| 146 | The lock-file repair commits to the branch and pushes it, but the pull request | |
| 147 | does not go green by itself. The job pushes with `GITHUB_TOKEN`, which keeps the | |
| 148 | commit attributed to the bot rather than to whoever owns a personal access | |
| 149 | token — and GitHub deliberately does not start a new workflow run for a push | |
| 150 | made with it. | |
| 151 | ||
| 152 | So the fix lands, and the checks need re-running: from the Actions tab, or by | |
| 153 | the next push to the branch. Buddy tells you which of the two happened in the | |
| 154 | comment it leaves. | |
| 155 | ||
| 144 | 156 | With no AI provider configured, classification and the mechanical repairs still work. You lose the agent-driven fixes, not the diagnosis. |
| 145 | 157 | |
| 146 | 158 | ## What it is allowed to do |