Repository navigation
chore(pr-pipeline): retire issue status labels after the Work status cutover #13486
Description
Refs #7577
Slice 5 of 5 of #7577: label to Work status field cutover.
Outcome
Issue status lives only in the Work status field. Issue status labels are no longer written or read, and the lane starts only on the field trigger. Labels stay for pull requests.
Decisions
- Q1 (owner, 2026-11-06, option (a)): the lanes App starts and restarts work by writing Work status
agent-ready, not by a label.- The azure-iac token broker also admits an
issues.field_addedevent from the lanes App whose new Work status value is theagent-readyoption, with the same repository allowlist. The broker side is merged in azure-iac#115. - Not chosen: (b) keep
agent-readyas a trigger-only label; (c) App-mintedworkflow_dispatchrestarts. - Record: chore(pr-pipeline): retire issue status labels after the Work status cutover #13486 (comment)
- The azure-iac token broker also admits an
- The text freeze is a security control, so it stays at least as strict when its anchor moves to the admission record: chore(pr-pipeline): retire issue status labels after the Work status cutover #13486 (comment)
Done when
-
gh issue list --label agent-ready --state open --json number --jq lengthreturns 0, and the migration comment lists the same issues with field valueagent-ready(work-items: work-item status as a field with labels as fallback #7577 done-when 2). -
work-resolve-issue.ymlno longer triggers onlabeledforagent-ready. It starts on a Work statusagent-readyfield event from a listed human or from the lanes App (Q1, option (a)), and the App's restarts are field writes. - No
.githubor plugin code writes a queue-state issue status label (status: ready,status: confirmed,needs-triage,agent-ready). Hold labels stay as holds on top of the field, and removing a hold label when its hold lifts is out of scope (owner Q13 (a), 2026-11-07).
Blocked by #13485: labels come off only after the migration recount.
Metadata
Metadata
Assignees
Type
Fields
Work status
confirmed
Activity
github-actions commentedon Nov 5, 2026
Proposed work class: none
Size: Medium
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: #13485
I understood this as the last slice of #7577: move issue status fully to the Work status field. That means no queue-state label writes, and the lane starts on the
agent-readyfield event instead of the label.The newest recorded decision is:
#13486 (comment) is not the decision above. The decision comment is by kyle-sexton on this issue.
That decision settles the open scope questions. No duplicates found. The first done-when item, the label count, needs a host run and waits on #13485.
Automated triage. A maintainer reviews it.
melodic-automation-lanes commentedon Nov 5, 2026
Not admitted to the issue lane: its body or a criterion names .github/workflows/work-resolve-issue.yml, which the issue lane cannot push (patch-protected-path); a builder session takes it; it carries host-run. 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 Nov 5, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.kyle-sexton commentedon Nov 6, 2026
Before the status labels retire, the lanes App needs a field path into work-resolve-issue, and that path needs a token broker change first. That change is the owner's security call.
issues: field_addedfor listed human senders only (hub decision H72, option a). The App's Work status writes start nothing.agent-readylabeledevent. melodic-software/azure-iacauthorize.mjs:176-186states the invariant that the caller runs only on that event.authorize.mjswould then have to admit an Appfield_addedevent that sets Work status toagent-ready. Changing that invariant loosens a security control, which is the owner's decision. No lane makes it.Raised by lane 2 while building #13484.
49 remaining items
chore(source-control): changelog fragment for the floor pins
fix(pr-pipeline): move a host-run or attended stop to Work status con…
fix(pr-pipeline): keep the host-run and attended label when the stop …
fix(pr-pipeline): anchor a human-started run on that human's own set
fix(source-control): keep a capped close's rerun from restarting a fi…
kyle-sexton commentedon Nov 7, 2026
Decision recorded.
Owner, 2026-11-07 in the hub session, answering "Q13: does done-when 3 cover hold labels like
status: needs-decisionandstatus: needs-info?" with option (a), verbatim: "go with recommendations".Done-when 3 covers the queue-state status labels only (
status: ready,status: confirmed,needs-triage,agent-ready). Hold labels stay as holds on top of the Work status field, as the merged reader keeps them (.github/actions/resolve-config/read-status.mjs:3,:36-53). Code that removes a hold label when its hold lifts (intake-triagerefine.mjs, intake-reenterreenter.mjs:414) stays, because without it a held issue never releases. Moving holds to the field only is hardening-pass work..githubor plugin code writes a queue-state issue status label (status: ready,status: confirmed,needs-triage,agent-ready); hold-label lifts are out of scope.Posted by the github-support hub session on the owner's answer. This was generated by AI.
github-actions commentedon Nov 7, 2026
The triage sweep dispatched intake triage for this issue (dispatch 1; 2 runs that reach intake, or 6 dispatches, hand it to a maintainer).
kyle-sexton commentedon Nov 7, 2026
Done-when graded on main
1151ade253(2026-11-07 20:3xZ). All three met; closing.Met.
gh issue list --label agent-ready --state open --json number --jq lengthreturns0. The migration record on work-items: work-item status as a field with labels as fallback #7577 (issuecomment-6711985883) says none moved. The one issue at S4 start, fix(skills): keep an unsubstituted ${user_config.medium} out of the view resolver command #13955, had field valueagent-readyand closed through its own lane PR.Met.
.github/workflows/work-resolve-issue.ymlhason: issues: types: [field_added]only.write-status.mjsrestart(clear, then set), used by report-outcome, work-unblock and the babysit capped close (fix(source-control): restart a capped close's issues through the Work status field in field repositories #14017).Met for this repository, which configures the field. A grep of
.githubandpluginson main finds no code path that writesstatus: ready,status: confirmed,needs-triageoragent-readywhile a Work status field is configured. The PRs:What remains, by design:
refine.mjs:799,890andreenter.mjs:414), out of scope per owner Q13 (a) (issuecomment-6712509164).babysit_verify_evidence.py:5468-5515andbabysit_postmerge.py:4038), which runs only whenissue_status/statusis unset. The plugin serves repositories and trackers without this field, and this issue's plan left plugin scope to be decided separately (issuecomment-6690412281).The text freeze keeps its strength. Runs anchor on a hashed lanes-App admission record, or on a listed human's own field set.
readEditsSincestill decides first. poteto's independent security review passed (#13998 issuecomment-6711104275).