feat(review): audit-trail rework comment -- the ticket tells its own story (Closes #310) #313
No reviewers
Labels
No labels
Agent
Compat/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No milestone
No assignees
2 participants
Notifications
Total time spent: 37 seconds
Due date
igor
37 seconds
No due date set.
Dependencies
No dependencies set
Reference
joshtronic/igor!313
Loading…
Reference in a new issue
No description provided.
Delete branch "agent/310-audit-trail"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What this does
Adds the rework leg of the per-ticket audit trail (#310). The review side already logs model + effort + verdict on every verdict (since #308/#312); the bot`s rework was silent. Now each rework round posts:
So the ticket conversation, read top to bottom, IS the journey:
review (opus@high) → REQUEST_CHANGES→🔧 rework round 1 (opus@high)→review (opus@high) → REQUEST_CHANGES→🔧 rework round 2 (opus@xhigh)→review (opus@high) → APPROVE→ merged. Read a task, see how it went.Notes
PR_REWORK_ROUND/PR_REWORK_EFFORTfrom the #308 ladder — no new state, no new calls.s a PR comment, best-effort (a failed post logs a warning, never blocks the rework).check-syncgreen,bash -n` clean.s a bot PR on a validated repo, so the live effort-laddered reviewer reviews it (opus, efforthighat round 0) — watch the review comment for the(effort: high)` line.Deferred (not blockers — say if you want them)
Closes #310.
🤖 Review —
COMMENT(automated)CI for
c9279382: successSmall, focused, best-effort change: posts one PR comment per rework round recording round number, a model name, effort, and commit count. Scope is tight (~12 lines), CI is green, no CI-config touches, and the post is genuinely non-blocking (
2>/dev/null || log warning). One semantic concern keeps me from a clean APPROVE.Model/effort mismatch in the audit line (
bin/tick.sh, new block). The comment reads "Addressed the review on${AGENT_MODEL_REVIEW}at effort ${PR_REWORK_EFFORT}". It mixes the review model (AGENT_MODEL_REVIEW) with the rework effort (PR_REWORK_EFFORT). For an audit entry whose stated purpose is "which model did the rework and at what effort," attributing it to the reviewer's model looks like a mislabel — a reader would reasonably expect the rework agent's model here, not the reviewer's. If the intent is "addressed the review that was authored by model X," the phrasing is at least ambiguous. Worth a human confirming this is the variable you meant, and tightening the wording either way.Variable scope is unverifiable from the diff.
PR_REWORK_ROUND,PR_REWORK_EFFORT,AGENT_MODEL_REVIEW,PR_REPO,PR_NUMBER, andforgejo_commentare all assumed live at this point. The description says they're cached from the #308 ladder, which is plausible, but I can't confirm from the shown lines. If any are unset, the failure mode is a benign ugly/empty comment (not a block), given the best-effort guard.No tests. Expected for a shell comment-posting side effect;
bash -n/check-syncgreen per the description and CI issuccess. Not a blocker, just noting there's no automated coverage of the message contents.Nothing here is a hard contract violation, but the review-vs-rework variable mix is a real "is this what you meant?" that deserves a human glance before merge.
Independent review by the harness on
claude-opus-4-8(effort: high). The human reviewer is requested once Igor has reviewed; a human still merges.