ShockVPN/shockbot
0
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix: stop report_progress loop and reinforce review-mode output discipline

Browse Source
This commit is contained in:
wolfy
2026-06-01 12:44:57 -05:00
parent eb8871d6d2
commit b36abf39d4
2 changed files with 50 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
modes.ts
+19
View File
@@ -64,6 +64,21 @@ state before acting on findings.
Pull every metadata field from the \`checkout_pr\` tool's response — file count, commit count, base/head ref + SHA, the commit list. For \`IncrementalReview\` runs, populate \`Prior shockbot review\` with the prior review's commit_id (short SHA) and \`html_url\` from \`list_pull_request_reviews\`.
After the metadata comment, include a collapsible per-file summary table built from your file inventory. Place it in the \`body\` parameter of the structured submission, after the metadata comment and before any \`### \` issue sections:
\`\`\`
<details>
<summary>Show a summary per file</summary>
| File | Description |
| ---- | ----------- |
| \`path/to/file.ts\` | One-line description of what this file's change does |
</details>
\`\`\`
Cover every non-trivial file you inventoried. If you skipped any (lockfiles, generated files), note "(N files not reviewed)" in the \`<summary>\` tag. Do NOT put this table in the \`changes\` array — \`changes\` is for the high-level bullet list of substantive changes, not the per-file breakdown.
## 2. Cross-cutting issue sections (zero or more)
For each cross-cutting concern, one \`### \` section. Use this exact shape:
@@ -300,6 +315,8 @@ For simple, well-defined tasks, skip the plan phase and go straight to build.`,
2. **checkout**: call \`${t("checkout_pr")}\` — this returns PR metadata and a \`diffPath\`. read the diff TOC end-to-end and treat its file line ranges as your coverage checklist.
**file inventory**: for every non-trivial file in the diff TOC (skip lockfiles, \`*.lock\`, auto-generated migration checksums, formatter/linter configs with no logic changes), read the file — the diff hunk is usually sufficient; read the full file when the hunk alone doesn't make the intent clear. for each file, record a one-line description: *what changed and why*. this inventory becomes the per-file table in the review body, and ensures a concrete understanding of each file before you form review opinions. read in batches to stay efficient — you do not need to read every line, just enough to understand each file's role in the PR.
3. **triage**: orient yourself on the PR — identify *what kind of thing this is* (domain it touches, seams it crosses, external contracts it depends on, user-facing surfaces it changes). pull as much context as you need to render a confident, well-grounded review: read related files, grep for callers of changed symbols, check tests that exercise the touched paths, fetch related GitHub state. **you are the synthesizer** — never delegate understanding to subagents.
if the PR is **genuinely trivial**, skip the fan-out entirely and submit a \`No new issues found.\` review per step 7.
@@ -456,6 +473,8 @@ ${PR_SUMMARY_FORMAT}`,
2. **checkout**: call \`${t("checkout_pr")}\` — this returns PR metadata, \`diffPath\` (full diff), and \`incrementalDiffPath\` (changes since last reviewed version, if available). read the diff TOC first and use its line ranges as your coverage checklist.
**file inventory**: for every non-trivial file in the incremental diff TOC (skip lockfiles, \`*.lock\`, auto-generated migration checksums, formatter/linter configs with no logic changes), read the file or its diff hunk and record a one-line description: *what changed and why*. this inventory becomes the per-file table in the review body.
3. **incremental scope**: if \`incrementalDiffPath\` is present, read it to see what changed since the last review. this is a range-diff that isolates the net changes, filtering out base branch noise. if not present, fall back to reviewing the full PR diff and determine what changed since Pullfrog's most recent review.
4. **prior feedback — read AND retire it**: fetch previous reviews via \`${t("list_pull_request_reviews")}\`, then call \`${t("get_review_comments")}\` on each prior shockbot review. Each thread renders as a section whose first line is a fenced tag \`comment author=<login> id=<fullDatabaseId> review=<reviewId> thread=<graphqlId>\`; section headers carry \`[RESOLVED]\` / \`[OUTDATED]\` when relevant. For every **open, Pullfrog-originated** thread, decide and act: