Repository navigation
fix(harness-ops): name the right plugin in the plugins sync self-update note (split from #6055) #6195
Description
This was generated by AI during attend-queue. Split from #6055 (item 3) on 2026-10-04 (operator direction: "go with the recommendations"). Operator-ratified as C3 bug-fix-shaped.
What
The /harness-ops:plugins sync self-update note names the wrong plugin. It takes .[0] with a filter that matches every id, and the digest carries no field naming harness-ops itself. Run 20261004T030609Z rendered "this run updated architecture (0.21.2 → 0.21.3)" with self_updated true.
Fix
- Emit
self_update {id, scope, old, new}in the digest (the proposal-2 shape in fix(harness-ops): classify concurrent moves and fix the self-update note in plugins sync #6055), so the C4 core does not rework the digest again. - Select this plugin's own row in the render.
- Add a golden where the self row is not first. Today no golden renders the note.
Base: origin/main e3bef12 (harness-ops 3.7.3); the note is at render-report.jq:188. This fixes the wrong name only. A self-move that came back as a noop still prints no note until #6055's core lands.
Sequencing
Conflicts on plugin.json and the CHANGELOG with #6182, #6183, #6184 and #6187. Research: attend-queue slice intake-6055.
Activity
github-actions commentedon Oct 4, 2026
Thanks for the report. As I understand it:
/harness-ops:pluginssync's self-update note picks.[0]from a filter that matches every plugin id and the digest has no field identifying harness-ops itself, so the rendered note names the wrong plugin (seen in run 20261004T030609Z). The proposed fix is to emit an explicitself_update {id, scope, old, new}in the digest and select harness-ops's own row when rendering, plus a golden test where the self row isn't first.This looks well-specified (file/line cited, fix plan given, sequencing conflicts noted), so no missing info from my side. Likely related: #6055 (the parent issue this was split from), #6054, and #6182 (noted conflicts, also harness-ops sync issues).
Automated triage. A maintainer reviews it.
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during work-loop.
Ratify autonomous dispatch of this C3 item?
Classification:
work-class: scoped(C3). Intended dispatch: the work-loop worker lane, through/work-items:work, to a draft PR the lane never merges, after its blocked-by edges clear. Harness-ops items run one at a time. The first-drain gate dispatches a C3 item only on a ratification reply to this marker. A decision comment or an operator-ratified note in the body is context, not dispatch authority. So it is queued here, keeping its labels, until/work-items:attend-queuerecords the reply.Lane: work-loop, instance melo-worker-1, cycle 1.
kyle-sexton commentedon Oct 4, 2026
kyle-sexton commentedon Oct 4, 2026
This was generated by AI during attend-queue.
Operator ratification (2026-10-04): ratified as C3, bug-fix-shaped. This replies to the
kind=ratify-c3marker above. The operator's direction was "go with the recommendations, make them agent ready". The brief is in the earlier attend-queue decision comment or in the issue body; follow any blocked-by edge on this item.kyle-sexton commentedon Oct 4, 2026
Still present in the 3.8.1 release:
render-report.jq:187-189still selects.[0]from the id filter. Reproduced on Windows (Claude Code 2.1.289, runplugins-sync/runs/20261004T171939Z.QD0bBZ). The run updated 53 plugins, harness-ops 3.7.2 → 3.8.1 among them as row 29, and the note named actionlint (0.12.4 → 0.12.5), which is row 1. That run's digest works as the golden fixture where the self row is not first.