Repository navigation
perf(planning): surface digest re-pins at plan time and re-pin several labels in one repin.sh call #8756
Description
No related issue: found while landing #8714.
Problem
plugins/planning/tests/interview-defenses.test.sh pins regions of the interview skill by digest. Only a person can re-pin them, in their own terminal, with repin.sh, and it asks y/N for each pin. On #8714 the pins surfaced only after the work was done. The owner then had to run the script, which held the PR as a draft for an extra round. repin.sh also exits non-zero while any other pin still fails, so a && chain of re-pins stops after the first one.
Fix
/planning:planlists the digest pins a planned change will move, under the plan's Captured assumptions or Constraints, so the owner sees the re-pin step at approval time.repin.shaccepts several labels in one call and asks once per label, so a single command re-pins all of them.
Verification
A plan that edits a pinned interview region names the pin. One repin.sh call re-pins three labels and ends PASS.
Activity
github-actions commentedon Oct 21, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
The decision settles every open question. What remains is a bounded change to
repin.shand its test suite: multi-label form, an exit-3 test for an unmatched label, and an updated usage line and header.Automated triage, applied by the lanes App.
github-actions commentedon Oct 26, 2026
The triage sweep dispatched intake triage for this issue (attempt 1 of 2).
melodic-automation-lanes commentedon Oct 26, 2026
Not admitted to the issue lane: no trusted-human acceptance criteria: a listed human must put the confirmed
- [ ]criteria in the body or post them as their own comment, or, on an issue a listed human filed, intake's newest refinement comment must hold them unedited. Admission takes the issue once each of those is met, when intake triages it again (.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 26, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.melodic-automation-lanes commentedon Oct 26, 2026
Refinement. A read-only run explored this repository, searched its issues and pull requests, and read the allowed docs to draft what follows. On an issue a listed human filed, it counts as the issue's spec once posted, while unedited; it is still model text, so check it.
Intended outcome: /planning:plan lists the digest pins a planned change will move, and repin.sh re-pins several labels in one call and ends PASS.
Related work
Open questions
RECOMMENDED: Drop it: accept several labels and re-pin each without prompting, since the script is already non-interactive. Basis: plugins/planning/tests/repin.sh:24-112 has no prompt; plugins/planning/tests/repin.test.sh:64 runs it with stdin from /dev/null
RECOMMENDED: repin.sh [--test-file f] <label>... <justification>: the last argument is one shared justification, each earlier one is a label; print one old -> new line per label and PASS or FAIL once at the end. Basis: plugins/planning/tests/repin.sh:31-43
RECOMMENDED: Resolve all labels first; if any matches none or several, exit 3 before changing the file. Basis: plugins/planning/tests/repin.sh:76-79
RECOMMENDED: Add a short step in the plan skill that lists the pins a change will move under the plan's Load-bearing assumptions or Risks and Mitigations, naming each pin label and the repin.sh command. Basis: plugins/planning/skills/plan/context/plan-template.md:41,127
RECOMMENDED: Owner decides after reading #10140 and #10087; keep this issue to the planning plugin's plan skill and repin.sh, leaving the pr-pipeline to #10087. Basis: judgment
Sources read
Automated refinement by the lanes App. Answer with a comment whose first line is
**Decision recorded.**.kyle-sexton commentedon Oct 26, 2026
Decision recorded. The owner answered in the Refinement and Issue Triage sessions (2026-10-25), deciding the open items below on the facts:
No owner ledger (
.work/*/interview-checklist.md,.work/gh-monitor-owner-decisions/) names this issue. Read against origin/main ata6ba1c4c18.The body's premise changed on main. #10140 (commit
68d3f2bd81, 2026-10-26) removed the attended-only gate. The suite now says: "Any session, a lane included, may re-pin a digest after that re-read" (plugins/planning/tests/interview-defenses.test.sh:74-75).repin.shhas no prompt or terminal check: it takes one label and one justification (plugins/planning/tests/repin.sh:3-4,:40), rewrites one sha256 literal, prints<label>: <old> -> <new>, and reruns the test (:6-16)./planning:planstill need to list the pins a change will move?Decided: No. That half existed "so the owner sees the re-pin step at approval time". The session that edits the text now re-pins it in the same change, and each failure message prints the
repin.shcommand (interview-defenses.test.sh:107). Nothing waits on the owner, so a plan-time list removes no round.repin.shask once per label?Decided: No. It has no prompt to repeat (
repin.sh:1-23), and fix(planning): let any session re-pin an interview-defenses digest #10140 removed the y/N ask on purpose.Decided:
repin.sh [--test-file <path>] <label>... <justification>. The last argument is one justification, written above each re-pinned call. Every label is resolved before any write. A label that matches no pin, or more than one, exits 3 and leaves the file unchanged, as one label does today (:76-79). The script prints oneold -> newline per label, reruns the test once, and endsPASS(exit 0) orFAIL(exit 1) (:105-112).Acceptance criteria:
repin.shcall with three labels and one justification re-pins all three and endsPASS; a test inplugins/planning/tests/repin.test.shcovers it on a stand-in file, as that suite does for one label.repin.test.shpass unchanged.repin.sh's usage line and header name the multi-label form.