Repository navigation
Conversation
|
![devin-ai-integration[bot]](https://cdn.statically.io/img/avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| `GET /repos/{owner}/{repo}/pulls?state=closed&sort=updated&direction=desc&per_page=50`, keeping | ||
| those with a `merged_at` in the last 96 hours whose base is the default branch, at most 25, newest | ||
| first. For each, read its title and body, and its changed files | ||
| (`GET /repos/{owner}/{repo}/pulls/{number}/files?per_page=100`; filenames first, patches only when | ||
| you verify a candidate). |
There was a problem hiding this comment.
🟡 Recent merges hidden by closed pull requests
When 50 closed pull requests have newer updates, resolved-check never reads a qualifying merge on the next page. After 96 hours, its fixed issues leave the daily search permanently.
Learn more
The daily task lists closed pull requests by their last update time. That order includes old merges and unmerged closed requests, so the first 50 records need not contain every merge from the last 96 hours. Only the first page is requested; an omitted merge can age out before the next run ever sees it.
Example: Fifty old pull requests receive comments on Tuesday. A pull request merged on Monday now appears on page two; Tuesday's run ignores it, and later runs cannot recover it after its merge falls outside 96 hours.
Recommended fix: Paginate /pulls until updated_at falls before the 96-hour cutoff, and select eligible merges by merged_at before applying the 25-pull-request work cap.
Was this helpful? React with 👍 or 👎 to provide feedback.
| 3. the issue's title names a file, function, option, command, error or feature that the pull | ||
| request's changed files define, change or delete. | ||
|
|
||
| Keep at most 15 issues, strongest first; say in your summary how many you left out. |
There was a problem hiding this comment.
🟡 Repeated candidates starve fixed issues
When 15 stronger candidates stay open, resolved-check selects them on every daily run and never inspects candidate 16. Once its merge ages past 96 hours, that fixed issue remains open.
Learn more
Daily mode sorts possible issue/merge pairs by signal strength, then examines at most 15. A candidate left open remains eligible at the same rank on every subsequent run. No cursor or exclusion lets the next issue through, and each merge is eligible for only 96 hours.
Example: Fifteen issues mentioned by a merged pull request need more evidence and remain open. A sixteenth issue fixed by another merged pull request appears below them; the task rechecks the first fifteen every day until the second merge ages out.
Recommended fix: Track previously examined candidate/merge pairs or rotate the daily selection so lower-ranked candidates get inspected within the 96-hour window. Keep rechecking candidates if new evidence appears.
Was this helpful? React with 👍 or 👎 to provide feedback.
| - Then two or three short bold-labelled lines: **What changed** (the pull request or commit, and | ||
| `path:line` at `HEAD`), **Why this resolves it** (one or two sentences from the code), and |
There was a problem hiding this comment.
🟡 Deleted components cannot satisfy closure evidence
When a merged change deletes the affected file, resolved-check still requires a path:line at HEAD. No such line exists, blocking a valid obsolete close or forcing an invalid citation.
Learn more
The obsolete verdict includes issues about deleted files, commands, and components. The close comment requires both the merged change and a current path:line citation. For an entirely deleted file, a current line does not exist, even though the merged diff proves why the issue no longer applies.
Example: A merged pull request deletes src/old-command.ts. An open issue concerns only that command. The task can establish obsolescence but cannot cite a line in the deleted file at HEAD.
Recommended fix: Permit a link to the deleting pull request's diff or deleted path for obsolescence, and require path:line at HEAD only when relevant current code exists.
Was this helpful? React with 👍 or 👎 to provide feedback.
| first. For each, read its title and body, and its changed files | ||
| (`GET /repos/{owner}/{repo}/pulls/{number}/files?per_page=100`; filenames first, patches only when | ||
| you verify a candidate). |
There was a problem hiding this comment.
🔍 Large merges hide filename-based candidates
When a merge changes over 100 files, resolved-check matches issue titles against only the first files page. Issues naming later files remain undiscovered until backdate.
Was this helpful? React with 👍 or 👎 to provide feedback.
| tools: | ||
| - repository.list_files | ||
| - repository.read_file | ||
| - repository.exec |
There was a problem hiding this comment.
🟨 Issue checker gains unrestricted network access
The scheduled task adds repository.exec without an explicit request for unrestricted network access. The Gardener tool policy forbids this addition without that request and disclosure.
Was this helpful? React with 👍 or 👎 to provide feedback.
commit: |
Upgrades Gardener to 0.1.22 and adds
resolved-check, a task that closes open issues merged work already resolved: fixed without aFixes #N, or made obsolete by changing or removing what the issue is about.resolved-checkbackdate #<from>-#<to>): checks open issues in that range, at most 15 per run, against everything merged since each was opened, and ends its summary with the next range to run. This works through the existing backlog.HEAD, or that what the issue describes no longer exists and which change removed it. It comments with that evidence (the pull request,path:line, why) and closes. A fixed issue closes as completed, an obsolete one as not planned. Anything unproven, partial or uncertain stays open and is listed in the run summary. There are no labels.on the roadmap,wip,blockedorgardener-fixlabels, tracking/RFC issues, issues opened after the pull request merged (triage covers those), and any issue this task has already commented on (<!-- gardener-resolved:… -->). A maintainer reopening one of its closes is final.claude-opus-5-5, 1 hour, at most 10 closes and 20 operations per run,runs: 15/dayso a backdate can proceed in batches. Effects are onlyissue.comment.createandissue.close.Gardener 0.1.22
issue.closetakes an optionalreason(completedornot_planned), sent to GitHub asstate_reason; without it, closes are unchanged. Gardener change: Close issues as completed or not planned scuffi/gardener#69. The shared runtime is already deployed at 0.1.22, and still accepts this repository's current pin until this merges.Validated end to end on a demo repository with 12 seeded issues, 4 merged pull requests and a direct commit. The daily run closed the indirect fix found by mention, the one found by file overlap, the triaged issue whose cited lines had moved (all as completed) and the removed function (as not planned). It left open, each for the right reason: a partial fix, a "still happens" report, a maintainer keeping one open, an issue reopened after an earlier close, an unrelated change to the same file, a roadmap label, and an issue with an open pull request. A backdate closed the issue fixed by a direct commit, and on the older backlog closed nothing, including issues about code that never existed.
Regenerated with
@scuffi/gardener@0.1.22.