ci: collapse the whole review comment behind one summary line - #2957
Conversation
|
@ES-Alexander this implements what we were talking about before. |
Automated PR Review — round 1Note 📝 MINOR SUGGESTIONS — 4 open: 3 minor and 1 nit. This changes the instruction document the automated reviewer follows, so that every review comment it publishes is wrapped in one collapsible block. Until someone opens it, a reader sees a single line carrying the round number and the verdict word. Because the platform will not draw its coloured callout inside a collapsible block, the verdict is now written twice — once on that visible line, and once as ordinary quoted text at the top of the hidden body. Nothing about how a review is investigated, or what it must contain, changes. Note on this comment: the diff redefines the output format of the run that produced it. Per the rule in the checked-out guidelines, a format that exists only in the diff has no authority over this run, so this review was written against the base contract and still uses the top-level alert and the What still needs attention
Change map — what was established before judgingThe PR touches one file, Claims (from the PR body / commit message):
Entry points — no function changed, so the rows are the consumers of the changed document and of the shape it specifies. None is
Searched for every other machine reader of the comment body before judging: Invariants the change relies on:
1. Correctness & Implementation Bugs — 3 findings1.1 — The verdict is duplicated with nothing checking the two copies, and the visible copy can vanish silently —
1.2 — "Nothing changes below it" is contradicted by the same diff — head:122 says "Nothing changes below it: opening the outer block gives the same document as before, with the human summary at the top and every other block still collapsed inside it." Two hunks later the document below the block does change: the 1.3 — The human-decision checkboxes move inside an HTML block, and the PR does not say what that does to them — The Two ways to close it: verify the checkboxes are still clickable on a scratch comment and say so where the alert limitation is already documented (head:172-178), or keep this block outside the outer 11. Nitpicks / Optional — 1 finding11.1 — The stated reason for the literal emoji is doubtful — head:174 says that inside Sections with nothing to report (9)2. Persistence & User Data — ✅ (grepped the diff for Generated by Claude. This is advisory; a human reviewer must still approve. |
92111f5 to
04a0931
Compare
Review follow-up — round 1Done
Deferred
Won't change (with reasoning)
|
|
/review |
Automated PR Review — round 2Note 📝 MINOR SUGGESTIONS — 2 open (1 minor, 1 nit), 3 closed since round 1. This changes the instruction document the automated reviewer follows, so that every review comment it publishes is wrapped in one collapsible block: until someone opens it, a reader sees a single line carrying the round number and the verdict word. Because the platform will not draw its coloured callout inside a collapsible block, the verdict is now written twice — once on that visible line, and once as ordinary quoted text at the top of the hidden body. Since the last round the document's account of its own change was narrowed to what is true, the claim about how the platform treats emoji codes was corrected, the visible verdict was made a placeholder that fails loudly rather than silently, and a line was added saying the maintainer tick-boxes still work inside the block. Nothing about how a review is investigated, or what it must contain, changes. Note on this comment: the diff redefines the output format of the run that produced it, so per the rule in the checked-out guidelines this review was written against the base contract and still uses the top-level alert and the What still needs attention
Since round 1 — 3 closed, 1 partly addressed, 1 new, comparing 92111f5 → 04a0931The range is not usable as an increment. ✅ 1.2 — Addressed. The bullet that claimed "Nothing changes below it" is gone; head:122 now says only that the sections below the block keep their order and their contents and that the title and the verdict move onto the summary line. That is the narrowing the finding asked for, and it is accurate against the rest of the diff (the ✅ 1.3 — Addressed. head:215-217 now states, where the decisions block is specified, that a task list nested in an HTML block publishes with the same markup it carries at top level and stays tickable. That is closure route one of the two the finding named. The author's follow-up declines the second half — hoisting the block back out — on the grounds that a disputed finding blocks nothing on its own and the verdict already reaches the reader unopened; the finding offered either route, so taking one closes it, and the residual cost (the question sits behind a click) is the change itself rather than a defect in it. ✅ 11.1 — Addressed. head:175-176 now says emoji shortcodes do survive inside :large_yellow_circle: 1.1 — Partially addressed. The finding had two halves. The second is closed: the summary-line verdict is now the contract's one square-bracket placeholder (head:342) and head:397 says why — an unsubstituted New this round: 11.2 ( Discussion since round 1. One substantive comment, from Change map — what was established before judgingThe PR touches one file, Claims (from the PR body and the commit message):
Entry points — no function changed, so the rows are the consumers of the changed document and of the comment shape it specifies. None is
Invariants the change relies on:
1. Correctness & Implementation Bugs — 1 finding (carried from round 1)1.1 — Nothing machine-checks the summary-line verdict against the body line — The half that landed: head:342 makes the summary-line verdict the contract's one square-bracket placeholder, and head:397 states the reason — it is the only The half still open: head:158-159 requires the verdict to be emitted twice, and head:181-182 names the failure this creates — "a summary line that disagrees with the body line is the one failure this duplication can produce" — without closing it. Nothing in the diff, in either review workflow, or in The publish steps already machine-enforce every other load-bearing line of the body: The author defers this to its own change, arguing that the single alert line is model-authored and unchecked today as well, that the check needs the ledger-to-verdict rule reimplemented in shell with self-check cases, and that this would be a larger diff than the line it guards. That is a fair scope argument, and this stays 11. Nitpicks / Optional — 1 finding11.2 — The stated reason for the two verdict forms claims more platform necessity than there is — head:172-173 opens the explanation with "The two columns differ because each sits in a context the other's syntax does not survive, and both are the platform's rules rather than a preference", and head:175-176 then concedes that emoji shortcodes do survive inside
This file is a specification whose justifications are what the next editor reasons from, which is the only reason it is worth a line at all; the choices the paragraph defends are the right ones either way. Sections with nothing to report (9)2. Persistence & User Data — ✅ (grepped the diff for Generated by Claude. This is advisory; a human reviewer must still approve. |
There was a problem hiding this comment.
Definitely an improvement over the walls of text ❤️
A couple of suggestions:
- The verdict duplication seems unnecessary and potentially error-prone
- I'd recommend keeping the verdict only in the details summary, but we can have it first (e.g.
> 📝 MINOR SUGGESTIONS (Automated PR review - round 3)), and then have the first line inside the details just specify the finding counts, like a subtitle to the verdict
- I'd recommend keeping the verdict only in the details summary, but we can have it first (e.g.
- Not sure if it's possible, but to further reduce the space taken we could use maintainers adding the 😕 reaction to the last automated review comment as a new mechanism to trigger a follow-up automated review
- This would still need user-based permissions gating, like the
/reviewcomment trigger already has
- This would still need user-based permissions gating, like the
04a0931 to
edc5cdc
Compare
Review follow-up — round 3Done
Deferred
Questions for reviewers
|
|
/review |
Automated PR Review — round 3Note 📝 MINOR SUGGESTIONS — 2 open (1 minor, 1 nit), 4 closed (1 this round). This changes the instruction document the automated reviewer follows, so that every review comment it publishes sits inside one collapsible block: until someone opens it, a reader scrolling the pull request sees a single line carrying the round number and the verdict word. Because the platform will not draw its coloured callout inside a collapsible block, the verdict is now written twice — once on that visible line, and once as ordinary quoted text at the top of the hidden body. The only change since the last round is to the document's own explanation of that duplication: it no longer claims the platform forces both differences between the two forms, and the note about the placeholder that must be substituted now gives the reason it actually relies on. Nothing about how a review is investigated, or what it must contain, changes. Note on this comment: the diff redefines the output format of the run that produced it, so per the rule in the checked-out guidelines this review was written against the base contract and still uses the top-level alert and the What still needs attention
Since round 2 — 1 closed, 1 new, 1 unchanged, comparing 04a0931 → edc5cdcThe range is not usable as an increment, again. No ✅ 11.2 — Addressed. Both halves landed, and both sentences the finding quoted are gone from this head (grepping the diff for
1.1 — unchanged, still New this round: 11.3 ( Discussion since round 2. One substantive comment from Change map — what was established before judgingThe PR touches one file, Claims (from the PR body and the commit message):
Entry points — no function changed, so the rows are the consumers of the changed document and of the comment shape it specifies. None is
Invariants the change relies on:
1. Correctness & Implementation Bugs — 1 finding (carried from round 1)1.1 — Nothing machine-checks the summary-line verdict against the body line — The half that landed: head:343 makes the summary-line verdict the contract's one square-bracket placeholder, and head:398 states the reason — an unsubstituted The half still open: head:158-159 requires the verdict to be emitted twice, and head:182-183 names the failure this creates — "a summary line that disagrees with the body line is the one failure this duplication can produce" — without closing it. Nothing in this head, in the three review workflows, or in The publish steps already machine-enforce every other load-bearing line of the body: The author defers this to its own change, arguing that the single alert line is model-authored and unchecked today as well, that the check needs the ledger-to-verdict rule reimplemented in shell with self-check cases, and that this would be a larger diff than the line it guards. That is a fair scope argument, and this stays 11. Nitpicks / Optional — 1 finding11.3 — The two-audiences paragraph still promises the scrolling reader what the new outer block hides — head:115-117 is untouched by this diff (the first hunk starts at line 118, so those lines are identical in base and head) and still reads: "A maintainer scrolling the PR needs the verdict, what is still open, and what only they can decide. A coding agent picking the review up needs every file path, line number and traced call. Round 1's 1.2 was the same species — a sentence left standing that the same diff had made untrue — and it was accepted and fixed by narrowing the wording. The same edit closes this one: a clause on head:116-117 saying the scrolling reader gets the verdict, and that what is open and what they must decide are one click behind it, or the same trade stated in the new bullet at head:121. To be clear about what this is not: the design decision is settled. Round 2 closed 1.3 on the grounds that the decisions block sitting behind a click is the change itself rather than a defect in it, and nothing here reopens that. What is stale is only the document's account of it, which matters because this file is a specification whose justifications are what the next editor reasons from. Sections with nothing to report (9)2. Persistence & User Data — ✅ (grepped the diff for Generated by Claude. This is advisory; a human reviewer must still approve. |
Makes sense.
I prefer if we deal with that in a separated PR. The goal of this one is just to reduce the wall of text indeed. |
edc5cdc to
9b4aa51
Compare
Review follow-up — round 4Done
Deferred
|
|
/review |
Automated PR Review — round 4Note 📝 MINOR SUGGESTIONS — 2 open (2 nits), 6 closed (2 this round). This changes the instruction document the automated reviewer follows, so that every review comment it publishes sits inside one collapsible block: until someone opens it, a reader scrolling the pull request sees a single line carrying the verdict word and the round number. Since the last round the verdict is no longer written twice — it now exists only on that visible line, and the hidden body opens with the finding counts instead — and the two sentences that still described the old arrangement have been narrowed to match. Nothing about how a review is investigated, or what it must contain, changes. Note on this comment: the diff redefines the output format of the run that produced it, so per the rule in the checked-out guidelines this review was written against the base contract and still uses the top-level alert and the What still needs attention
Since round 3 — 2 closed, 2 new, comparing edc5cdc → 9b4aa51The range is not usable as an increment, for the third round running. No ⚪ 1.1 — No longer applicable. The finding asserted that the verdict was written twice — once on the
Two things this closure is not. It is not the author's deferral argument being accepted — that argument was recorded last round and could never have closed the finding. And it is not a statement that the verdict is now machine-checked: it is still model-authored and unverified against the ledger the same publish step already parses. That was true before this PR as well, it is not what 1.1 asserted, and with one copy left there is nothing for a cross-check to compare, so no residue is carried forward. The author's follow-up asks for no ✅ 11.3 — Addressed. The finding asked for two things and both landed. First, the two-audiences sentence: head:115-116 now reads "A maintainer scrolling the PR needs the verdict, with what is still open and what only they can decide one click behind it", which is the clause the finding named. Second, the human-summary bullet that still listed the verdict among the body's contents: head:123 now reads "It holds the counts, the open findings, and the decisions only a human can make". Grepping the head text for the old wording — New this round: 11.4 and 11.5, both Discussion since round 3. Two substantive comments, both from
Change map — what was established before judgingThe PR touches one file, Claims (from the PR body and the commit message):
Entry points — no function changed, so the rows are the consumers of the changed document and of the comment shape it specifies. None is
Invariants the change relies on:
11. Nitpicks / Optional — 2 findings11.4 — The "every head:126 is untouched by this diff and still reads: "Every This is not an argument for putting the counts back on that line. That trade was asked for by a reviewer and accepted by the author, and it is a better fit for a line read while scrolling than a count would be. What is stale is only the general rule that the same file states two paragraphs earlier, which matters because this document is a specification and its rules are what the next editor applies to a block the examples do not cover. The fix is one clause, the same shape as the two already accepted on this branch: scope head:126 to the nested blocks, or add to it that the outer block carries the verdict in place of a count. 11.5 — One line of the rewrapped short-circuit paragraph runs past the file's wrap — head:402 — "the counts line, the footer and the ledger, and both skip everything else. The ledger they emit is the one" — is 106 characters. Every other prose line in the document sits at or under 101: grepping the base file for paragraph lines longer than that (excluding bullets, table rows and headings, which are single-line by convention) returns none, and the other six lines of this same paragraph are within it. The paragraph had to be rewrapped because its opening changed from "the verdict alert" to "the outer block with the verdict on its summary line, the counts line", so this is a leftover of that rewrap rather than a new sentence. Rewrap head:401-407 so the whole paragraph keeps to the file's width. Sections with nothing to report (10)1. Correctness & Implementation Bugs — ✅ (the one finding this section carried, 1.1, is closed above as no longer applicable; re-checked the contract against its machine readers — Generated by Claude. This is advisory; a human reviewer must still approve. |
9b4aa51 to
41249dc
Compare
Review follow-up — round 5Done
|
|
/review |
Automated PR Review — round 5Tip ✅ READY TO MERGE — 0 open, 8 closed (2 this round). This changes the instruction document the automated reviewer follows, so that every review comment it publishes sits inside one collapsible block: until someone opens it, a reader scrolling the pull request sees a single line carrying the verdict word and the round number. The counts, the findings and every detail block stay where they were, one click behind that line. Since the last round the two remaining wording defects were fixed — the rule about what each collapsed line must say now names the outer block as the exception, and the one over-long paragraph line was rewrapped. Nothing about how a review is investigated, or what it must contain, changes. Note on this comment: the diff redefines the output format of the run that produced it, so per the rule in the checked-out guidelines this review was written against the base contract and still uses the top-level alert and the What still needs attentionNothing is open. Both findings carried into this round are addressed, and this round's pass over the whole diff raised none. Since round 4 — 2 closed, 0 new, comparing 9b4aa51 → 41249dcThe range is not usable as an increment, for the fourth round running. No ✅ 11.4 — Addressed. The finding asked that head:126's general rule be scoped to the nested blocks, or that it state the outer block carries the verdict in place of a count. head:126 now reads: "Every nested ` states`) returns nothing, and no other rule in the file now describes a summary line the diff's own example breaks.
Two short-circuits. Both still emit the marker, the outer block with the verdict on its summary line, at head:401), where the reported line was 106. Measured with grep '^+.\{N,\}' on pr.diff under a UTF-8 locale, no line of head:401-407 reaches 101, and no added prose line anywhere in the diff reaches 102.grep -n '^[^-|# ].\{101,\}' on the checked-out file), and four more — base:134, :137, :219, :237 — are unwrapped single-line paragraphs well past that. The reported line at 106 was above all of them either way, so the finding was real and the rewrap answers it; only the stated ceiling was off by two.pr.diff, not over the increment — the contract's three machine readers re-checked against review-marker.sh:19-27, review-ledger.sh:19-31 and the marker-prefix filters at claude-pr-review.yml:165-167 and claude-pr-review-continue.yml:210-212/:265-266; the base file re-grepped for every sentence still describing the pre-wrapper shape; and the sibling claude-pr-demo.yml checked as a possible second consumer (it is not — it reads .github/claude-review/demo-video-guidelines.md and writes demo/comment.md). Nothing new surfaced.rafaellehmkuhl, plus a bare /review treated as noise. Summarised rather than quoted, since it is written as an HTML block. |
| Function | Reached from | Frequency |
|---|---|---|
| the guidelines document itself | agent step of claude-pr-review.yml:90 (PR opened / ready_for_review) and claude-pr-review-continue.yml:326 (/review comment), both reading it from the base ref |
per user action |
| the published comment shape (contract, head:335-410) | written by the agent, published by claude-pr-review.yml:153-172 and claude-pr-review-continue.yml:406-440 |
per user action (once per review round) |
review-marker.sh:apply |
publish step of both review workflows (claude-pr-review.yml:156, claude-pr-review-continue.yml:409) |
per review round |
review-ledger.sh:extract |
publish step of both workflows (claude-pr-review.yml:160, claude-pr-review-continue.yml:416), plus claude-pr-review-continue.yml:230 reading the previous round back |
per review round |
bot-comment filter, claude-pr-review-continue.yml:265-266 |
gathering new-comments.json on every /review |
per user action |
marker parse in claude-pr-review-current.yml:40-44 |
pull_request_target opened/synchronize/reopened |
per push |
Invariants the change relies on:
- The marker is line 1 of the published body. Violable only by the model; head:339 keeps it there and
review-marker.sh:21-26repairs it either way, prepending rather than replacing when line 1 is not a bot marker (:23, self-check:59-61), so a<details>on line 1 would survive the repair. Load-bearing twice over under the new shape:claude-pr-review-continue.yml:265-266filters the bot's own comments out ofnew-comments.jsonby that prefix, so a marker moved inside the wrapper would re-deliver every past review as untrusted discussion, and:210-212picks the previous review by the same prefix. head:395 states the requirement explicitly. Covered. - The ledger block is the last
^<!-- claude-pr-review-ledgerline. Violators are the review's own prose (the casereview-ledger.sh:9-12documents) and now the trailing</details>; head:388-390 places the ledger after it. Covered. - Blank line after every
</summary>and before the closing</details>(head:125) now has to hold at two nesting levels. The template shows both for the outer block (head:341-343, head:387-388). The nested examples in the same template omit the blank line before their closing tag, but that predates this PR and is unchanged by it. - The summary-line verdict placeholder is always substituted. head:341 writes it in square brackets and head:396 gives the reason — an unsubstituted
<…>inside the<summary>element is parsed as a tag and dropped, while[…]publishes visibly. Covered by convention, not by machine; with the verdict written in exactly one place there is no disagreement case behind it, only a missing-substitution one that fails loudly. - Every collapsed line says what is behind it. head:126 now scopes that rule to the nested blocks and names the outer block's verdict as the exception, so the diff's own example no longer breaks a rule the same file states. This was 11.4 and is covered as of this head.
Sections with nothing to report (11)
1. Correctness & Implementation Bugs — ✅ (re-checked the contract against its three machine readers — review-marker.sh:19-27 on line 1, where a missing marker is prepended so the <details> on line 2 survives; review-ledger.sh:19-31, which takes the last ledger block and so still finds it after head:388's </details>; and the marker-prefix filters at claude-pr-review.yml:165-167 and claude-pr-review-continue.yml:210-212/:265-266 — the new outer block sits inside all of them)
2. Persistence & User Data — ✅ (grepped the diff for cockpit-, useBlueOsStorage and settings-management: the change adds, reshapes and removes no persisted key, so there is no footprint to inventory)
3. AGENTS.md Adherence — ✅ (checked all five hunks against the stated purpose; the only edits since round 4 are one clause on head:126 and the rewrap of head:401-407, both asked for last round, with no other line moved — pr.diff and incremental.diff carry identical hunks. No dependency, JSDoc, rename, import reorder or unrelated content change, and nothing added without a consumer, since both agent steps at claude-pr-review.yml:90 and claude-pr-review-continue.yml:326 read the shape this file defines)
4. Security — ✅ (scanned pr.diff for zero-width, bidi and directional-override code points — none; the complete non-ASCII inventory is the em dash, the ellipsis, the four verdict emoji that are the point of the change and the U+FE0F variation selector giving ⚠ its emoji presentation. No text addressed to the reviewer in the diff. The PR does redefine this reviewer's own output contract, which I reviewed under the checked-out base version and did not adopt, as recorded above the findings table. The one new comment is the author's own status report, treated as a claim and checked line by line against the diff)
5. Performance — ✅ (no runtime code; the document is read once per review run at claude-pr-review.yml:90 and claude-pr-review-continue.yml:326, and the net effect on the agent is ~19 lines of prose)
6. UI / UX — ✅ (no Vue component, dialog, Vuetify overlay control or user-facing string in the diff; the only rendered surface is the review comment itself, whose last open question — the summary line carrying no count — closed with 11.4, and the checkbox-interactivity statement that answered 1.3 still stands at head:214-216)
7. Code Quality & Style — ✅ (the complexity report for this head — base ce3a8d4, head 41249dc — measured 0 changed files and 0 functions and is not truncated, consistent with a markdown-only diff, so nothing is triggered and no complexity finding arises; no lint surface is touched, yarn lint covering only the JS/TS globs and .github/scripts having its own ESLint run at ci.yml:144, neither of which reaches markdown; re-measured the prose wrap after the rewrap — the longest line of head:401-407 is 100, against 103 elsewhere in the file)
8. Commit Hygiene — ✅ (one commit 41249dc, one file, +55/−36, subject ci: collapse the whole review comment behind one summary line; round 4's two nits were folded in by amending — authored 20:09:58, committed 22:48:09 — rather than left as an "address review" commit, which is what AGENTS.md asks; no wip/fixup!/self-correcting commit, and no #N or closing keyword in the message, with the github/markup#1753 and #2960 references kept in the PR body and comments where they belong; git log on this file uses ci: for mechanism edits and docs: for rule-content edits, and this is a mechanism edit)
9. Tests — ✅ (ci.yml:120-132 runs five .github/scripts self-checks; none reads this document, none was removed or weakened, and review-ledger.sh's own cases at :56-70 — including the fenced-example case the guidelines' template creates — still describe the layout head:388-392 produces)
10. Documentation — ✅ (re-grepped the base file for alert, never collapsed, top of the comment, "first <details>" and Automated PR Review: base:121, :144, :146, :150, :156, :325, :327 and :382 are the only occurrences and every one falls inside a rewritten hunk, with head:126 — the last survivor — fixed this round; also checked the sibling claude-pr-demo.yml, which reads its own demo-video-guidelines.md and writes demo/comment.md, so the shape change does not reach it)
11. Nitpicks / Optional — ✅ (both nits carried in, 11.4 and 11.5, are closed above; re-read the two amended passages at head:126 and head:401-407 for an inconsistency introduced by the fixes themselves and found none)
Generated by Claude. This is advisory; a human reviewer must still approve.
A review runs to several screens, and a PR that goes ten rounds with it is a conversation nobody can scroll. Everything now sits inside one outer <details> whose summary carries the verdict and the round it belongs to, so each round costs one line until someone opens it; the sections inside keep their order and their contents, and only the title and the verdict move. The verdict leads that line, because it is what a reader scrolling past is after, and it is written there and nowhere else: the body opens with the finding counts instead, as a subtitle to it, so there is no second copy that can end up disagreeing with the first. It could not have stayed a coloured callout in either place — GitHub does not render an alert nested inside another element, so the wrapping would have published it as a plain blockquote with a literal [!WARNING] line in it. <summary> is an HTML block that processes no markdown, hence the HTML tags in the table's one form column; the literal emoji there is readability, since shortcodes do survive in a <summary>. The marker and the ledger stay outside the block. Neither renders, and the ledger has to stay the last thing in the body for the extractor that reads it back.
41249dc to
134fd6d
Compare
2 participants
The automated review comment runs to several screens, and a PR that goes several rounds with it turns into a conversation nobody can scroll. This puts the whole comment inside one outer
<details>whose summary carries the verdict and the round it belongs to, so each round costs one line in the timeline until someone opens it. The sections below keep their order and their contents: opening the block gives the document we have today, human summary at the top and every section still collapsed inside it. Only the title and the verdict move onto the summary line.The verdict leads that line and is written nowhere else. The body opens with the finding counts instead, as a subtitle to it, so nothing has to be kept in step: a maintainer scrolling past gets the one thing they are scrolling for, and the counts are there for whoever opens the block.
Two platform constraints shaped the rest of the diff, both verified rather than assumed:
> [!WARNING]inside a<details>publishes as a plain blockquote with a literal[!WARNING]line in it, so the coloured callout could not survive the wrapping wherever the verdict ended up. On the summary line it needs no callout: the emoji and the bold text carry what the colour used to.<summary>processes no markdown. Rendering**bold**,_em_, backtick code and a link inside a<summary>through the GFM API returns all four verbatim, which is why the verdict table's one column is HTML tags. Emoji shortcodes are the exception — they are substituted after the markup is rendered, so:warning:does resolve there — but a literal emoji needs no substitution in either context, so that is what the column uses.The marker and the ledger stay outside the block. Neither is rendered either way, and the ledger has to remain the last thing in the body for
review-ledger.sh, which takes the last matching block.Only the guidelines file changes — the three workflows delegate the output contract to it and never parse the rendered structure.
Test plan
POST /markdown(mode: gfm): the summary line comes back as📝 <strong>MINOR SUGGESTIONS</strong> (Automated PR Review — round 3), and the counts blockquote, the table and the nested<details>inside the wrapper all render normally.[the verdict, …]publishes visibly at the head of the line, while<the verdict, …>is parsed as a tag and dropped, leaving the round in parentheses with nothing in front of it — which is the reason the contract writes that one placeholder in square brackets.<details>come back with the samecontains-task-list/task-list-itemmarkup they get at top level, so the human-decision checkboxes stay tickable once the block moves inside the wrapper.review-ledger.shextracts the ledger from that body unchanged, with the wrapper's</details>between the footer and the ledger..github/scriptsself-checks pass,review-marker.shincluded; line 1 is untouched by this change.