Repository navigation
feat(pr-pipeline): stop gating any step on work class (owner Q85) #9668
Description
Problem
Owner decision Q85 (2026-10-24, Backlog HITL session): work class gates nothing. The owner: "I don't think work class needs to be a gate right now. We can always come back in and change our minds."
Work class still blocks or routes work in several places, for example:
- intake:
apply-verdict.mjs:180-181adds a hold reason when no class is proposed, which sends the issue tostatus: needs-decision(the escalation needs-human pile also writesnone, atapply-verdict.mjs:123, but its cause is the escalation, not this gate), andapply-verdict.mjs:82holdswork-class: structural. - admission:
admit.mjs:285againstadmission-rules.json:5classes. resolve-config/predicate.mjs(work-classes, admissionclasses), pr-merge / babysit (babysit_merge*.py,babysit_risk.py,babysit_verify_evidence.py),pr-verify.yml,pr-run-activity-read.yml,report-outcome.mjs,label-unblocked.mjs,triage-sweep.mjs, and the work-items tracker frontier and rule-admit.
Fix
- No step refuses, holds, escalates or routes an issue or pull request by its work class or by a missing one.
- Existing labels may stay on issues; nothing reads them for a decision.
- Size, uncertainty, trust and review gates are out of scope here (owner question Q88 covers Size).
Done when
-
git grep -n -i -E "work-class|workClass|work_class|lane_class" -- .github plugins/source-control/skills/babysit-prs/scripts plugins/work-itemsshows no read that refuses, holds, escalates or routes on a class (docs describing the removal are fine). - The intake, admission, pr-merge and resolve-config test suites pass, with a case per former gate showing a class-less and a structural issue or PR passing it.
Activity
kyle-sexton commentedon Oct 24, 2026
Decision recorded. Owner, Backlog HITL session, 2026-10-24. Q85: "Should work class stop being a gate?" Answer: "the work class: nothing. There's no filtering or further processing with PRs, reviews, and blocks ... I don't think work class needs to be a gate right now. We can always come back in and change our minds." Also answered in the same session: Q83, a status-ready Feature with no parent issue is admitted like a Task ("go w/ recomemndations").
github-actions commentedon Oct 24, 2026
Proposed work class: work-class: structural
Basis: automated intake triage; the lanes App applied this class.
Size: Large
Complexity: Medium
Uncertainty: Known
Flags: none
Blocked by: none
#9668 (comment)
The decision settles the open questions: untrusted-provenance stays as a label check everywhere, and no other step gates on work class. The change spans intake, admission, pr-merge, resolve-config and work-items, so it is Large and may need splitting.
Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 24, 2026
Not admitted to the issue lane yet: Size large: the split into sub-issues at intake is pending (owner Q93).
kyle-sexton commentedon Oct 24, 2026
Decision recorded. Owner, poteto session, 2026-10-24. Question: does Q85 also remove pr-merge's work-class checks, the untrusted-provenance one included? Options were: (a) remove the class-above-rung ceiling, the per-class promotion cells and the
class-missingMED score, and keep the untrusted-provenance hold as its own label check that reads no work class; (b) remove everything, untrusted-provenance included; (c) leave pr-merge unchanged. Answer: "yes go w/ recommendations", meaning option (a).Scope for pr-merge (
babysit_merge*.py,babysit_risk.py,babysit_verify_evidence.py): no refusal, hold or MED/HIGH score reads a work class. The untrusted-provenance hold stays as a trust gate.6 remaining items
feat(source-control): key the merge gate's promotion check by rung
kyle-sexton commentedon Oct 26, 2026
Decision recorded. Intake has posted no refinement on this issue. This issue's
- [ ]criteria are already in its body; the owner set the pr-merge scope on 2026-10-24. The open trust-gate point outside pr-merge is decided on the facts below.Sources, quoted verbatim:
Outside pr-merge, decided on the facts (owner, Refinement session, 2026-10-25):
The owner's own answer agrees: Q90 (hub ledger,
.work/backlog-to-zero/interview-checklist.md:162) records "untrusted-provenance stays a label check". It stays as a label check everywhere it runs today. Keeping it tightens nothing and loosens nothing; removing it would loosen a trust gate, which the body puts out of scope and the owner's pr-merge decision keeps ("The untrusted-provenance hold stays as a trust gate"). One rule in both places also keeps a single source of truth for the trust gate.Body criteria as amended by the pr-merge decision (only the amended line; the rest of the body's list stands as written):
babysit_merge*.py,babysit_risk.py,babysit_verify_evidence.py) no refusal, hold or MED/HIGH score reads a work class; the untrusted-provenance hold stays as a label check that reads no work class.melodic-automation-lanes commentedon Oct 26, 2026
Split at intake (owner Q93). This issue is Size Large, so its done-when is split into 2 sub-issues, each holding its task-list lines as written.
Automated split by the lanes App. Admission waits on this issue while a sub-issue is open; work-unblock closes it as completed once every sub-issue is closed by a merge or a listed human.
kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-26 rule: a person is involved only for "1. A change in original intent/vision 2. Something comes up during implementation ... that alters intent/vision or the primary design 3. If there is a HIGH/CRITICAL security issue". None applies here, so the hold label came off and intake triage runs again now.
To hold this issue again, add
needs-human(orstatus: needs-decision) and name which of the three applies.melodic-automation-lanes commentedon Oct 29, 2026
Every sub-issue of this split is closed by a listed human or a merge (#10236, #10237), so the lanes App closes it as completed.
kyle-sexton commentedon Oct 29, 2026
Re-triage: scope.
plugins/work-itemsis out of this issue's scope, as decided on #10237: #10237 (comment)Owner decision Q85 (no work-class gate at admission) governs the automation factory's
.githublanes, which already apply it (admit.mjsgates only onwork-class: untrusted-provenance). Those lanes are what will be generalized into ci-workflows for every repository. The published work-items and autonomy plugins keep their class-based admission for repositories outside the factory. Read this issue's done-when grep overplugins/work-itemsas out of scope.