@erclx/canon 4.47.0 → 4.48.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -25,15 +25,15 @@ A declined finding fails on a third axis, which is where its reason ends up. A w
|
|
|
25
25
|
- Push before replying, so the comment never runs ahead of the code it describes
|
|
26
26
|
- Map every finding to what changed, or to a one-line reason when it is a question or a conscious accept
|
|
27
27
|
- Carry the fact behind a declined finding into the posted reply rather than into the message that answered the dispatch, since both sessions end and the thread is what the next reader opens
|
|
28
|
-
-
|
|
29
|
-
- Say what the run actually did on a rebase-only pass, since a reply mapping findings and a
|
|
28
|
+
- Append the closing confirmation to the reply only when the findings are addressed and every check passes
|
|
29
|
+
- Say what the run actually did on a rebase-only pass, since a reply mapping findings and a closing confirmation claiming they were addressed are both false on a pull request carrying none
|
|
30
30
|
- Scan the reply for banned characters and internal phase labels before posting, since the comment leaves for the remote unchecked
|
|
31
31
|
|
|
32
32
|
## Must not
|
|
33
33
|
|
|
34
|
-
- Merge, or read the closing
|
|
34
|
+
- Merge, or read the closing confirmation as an approval. The author cannot approve their own pull request.
|
|
35
35
|
- Write a review. This skill consumes findings and does not produce them.
|
|
36
|
-
-
|
|
36
|
+
- Append the closing confirmation while a check is failing
|
|
37
37
|
- Reimplement the follow-up push or the doc refresh. Both have owners, and a second copy here drifts from them.
|
|
38
38
|
- Edit silently. A finding answered without a reply leaves the reviewer re-deriving the change from the diff.
|
|
39
39
|
- Answer a finding in the channel alone. A reply that changes what the review concluded is the one the thread has to carry.
|
|
@@ -153,34 +153,57 @@ matches it.
|
|
|
153
153
|
Before posting, run the scan in
|
|
154
154
|
`${CLAUDE_SKILL_DIR}/../../standards/publish.md`
|
|
155
155
|
against the reply. The hook skips `.canon/tmp/`, so this scan is the
|
|
156
|
-
only gate on the published reply. Post it to the PR
|
|
156
|
+
only gate on the published reply. Post it to the PR and capture the posted
|
|
157
|
+
comment's id, since Step 7 edits this exact comment rather than trusting
|
|
158
|
+
whichever one `gh` considers last:
|
|
157
159
|
|
|
158
160
|
```bash
|
|
159
|
-
gh pr comment <number> --body-file .canon/tmp/address-review/reply-<number>.md
|
|
161
|
+
comment_url=$(gh pr comment <number> --body-file .canon/tmp/address-review/reply-<number>.md)
|
|
162
|
+
echo "${comment_url##*issuecomment-}" > .canon/tmp/address-review/reply-<number>.id
|
|
160
163
|
```
|
|
161
164
|
|
|
162
165
|
## Step 7: confirm resolution
|
|
163
166
|
|
|
164
167
|
After the follow-up push, watch CI on the PR. Poll
|
|
165
168
|
`canon pr checks <number> --json` until the record's `state` leaves `pending`,
|
|
166
|
-
then read it. When every finding is addressed and the state is `passing`,
|
|
167
|
-
|
|
169
|
+
then read it. When every finding is addressed and the state is `passing`, append
|
|
170
|
+
the closing confirmation to the reply file Step 6 already posted, so the thread
|
|
171
|
+
carries one terminal state rather than a second comment under no heading:
|
|
168
172
|
|
|
169
173
|
```bash
|
|
170
|
-
|
|
174
|
+
printf '\n✅ All review findings addressed, CI green.\n' >> .canon/tmp/address-review/reply-<number>.md
|
|
171
175
|
```
|
|
172
176
|
|
|
173
|
-
A rebase-only run addressed no finding, so it
|
|
174
|
-
|
|
177
|
+
A rebase-only run addressed no finding, so it appends its own confirmation
|
|
178
|
+
instead of that one. Claiming findings were addressed on a pull request that
|
|
175
179
|
carries none is false on a surface nothing else checks:
|
|
176
180
|
|
|
177
181
|
```bash
|
|
178
|
-
|
|
182
|
+
printf '\n✅ Rebased onto origin/main, CI green. No review findings were open.\n' >> .canon/tmp/address-review/reply-<number>.md
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
Re-run the `${CLAUDE_SKILL_DIR}/../../standards/publish.md` scan against the
|
|
186
|
+
updated file, since the appended line is new content the Step 6 scan never saw.
|
|
187
|
+
Then edit the exact comment Step 6 posted, read back from the id it saved,
|
|
188
|
+
rather than posting a second comment:
|
|
189
|
+
|
|
190
|
+
```bash
|
|
191
|
+
gh api -X PATCH "repos/{owner}/{repo}/issues/comments/$(cat .canon/tmp/address-review/reply-<number>.id)" \
|
|
192
|
+
-F body=@.canon/tmp/address-review/reply-<number>.md
|
|
179
193
|
```
|
|
180
194
|
|
|
181
|
-
|
|
182
|
-
|
|
183
|
-
|
|
195
|
+
`--edit-last` was the first shape and it targets the wrong object here.
|
|
196
|
+
It edits the last comment posted by the authenticated user, not the last
|
|
197
|
+
comment this run posted, and every session here authenticates as the one
|
|
198
|
+
account the operator also comments from. A comment the operator leaves on
|
|
199
|
+
their own pull request during the minutes Step 7 spends waiting on CI becomes
|
|
200
|
+
that last comment, so `--edit-last` would overwrite it with the reply and the
|
|
201
|
+
confirmation, silently. Targeting the id Step 6 captured closes that whether
|
|
202
|
+
or not anyone commented in between.
|
|
203
|
+
|
|
204
|
+
If any check fails, skip the edit. Report the failing check so it can be fixed
|
|
205
|
+
first. This is a resolution signal, not a formal approval, since the PR author
|
|
206
|
+
cannot approve their own PR.
|
|
184
207
|
|
|
185
208
|
## Step 8: output
|
|
186
209
|
|