Repository navigation
work-items: work-item status as a field with labels as fallback #7577
Description
Parent
Refs #7555. Source: PLAN Phase 10, topic poteto-review. Thread: Work-item status (fields versus
labels).
Depends on
- config-cascade: settings resolution and convention home #7571 Settings resolution and convention home (role-label remap setting)
- pr-pipeline: probe token broker grants #7601 broker-mint probe (closed: lane tokens hold
issues: write, enough for field writes) - Child work-items: probe org issue field for work status #7600 (Q563 status-field probe, closed with its result) is this thread's gating probe.
Outcome
A work item's status lives in one single-valued field when the tracker offers one (the org field
Work status here), with labels as the fallback, detected by the tracker adapter; lanes trigger on
the field change.
Decisions
- Status set
needs-triage,needs-reporter-info,needs-owner-decision,needs-spec,
agent-ready; Issue Type field, never a type label (D76, Q505). Origin: ours, owner-decided. - A single-valued attribute (status) is a field when the tracker offers fields (native first, else a
created org field); labels where a label fits better (multi-valued tags) and as the fallback
(user-owned repos, no field access); the adapter detects field availability; prefer the field
trigger when both work (Q563). - Setting: role labels remap for status and pair labels, names per D76, D94 (repo).
- Q563 probe result (owner sitting, GUIDE 123): GitHub reserves the name
status, so the field is
Work status(single-select, visibility all, the five options above); writes through the
issue-field-values API succeeded; the Issue events API keeps no value history, so the lane
triggers on Actionsissues: field_addedwithchanges.issue_field_value.from, checked live on
the first trigger run. - Migration (B5, owner): one cut-over, scoped to the open
agent-readyissues in this repository,
count first, dry run, recount; dual-write only if a label reader cannot move in the slice; move
work-resolve-issue.yml's trigger in the same slice. - Rejected: Projects v2 Status (per project, no Actions trigger); Issue Types and
state_reason(do
not model status).
Key interfaces
From the design's contracts, "Pipeline and verdict": "Statuses: needs-triage,
needs-reporter-info, needs-owner-decision, needs-spec, agent-ready; Issue Type field, never a
type label. Status is a field when the tracker offers one (adapter detects), labels as fallback."
"Tracker adapter": "Contract and conformance tests in the work-items tracker contract;
schema_version covers versions."
Variation verdicts: "Work-item status storage: abstract now; tracker adapter; field where offered,
labels as fallback (Q563)."
Slices, filed when this phase starts: status-field-adapter, status-migration.
Done when
- The tracker test suite and the conformance suite pass for
githubandlocal-markdownwith
field detection. - After migration,
gh issue list --label agent-ready --state open --json number --jq length
returns 0, and the migration comment lists the same issues with field valueagent-ready. - The first
field_addedtrigger run logs a non-emptychanges.issue_field_value.fromand
concludessuccess.
Out of scope
- Creating or changing org-level issue fields (owner stop).
- Status writes from decompose and
track addbefore this thread lands.
Activity
github-actions commentedon Oct 16, 2026
Proposed work class: work-class: structural
Basis: automated intake triage; the lanes App applied this class.
Size: Large
Complexity: High
Uncertainty: Knowable
Flags: none
Blocked by: none
Understood: move work-item status into the single-select
Work statusissue field when the tracker offers one, keep labels as the fallback, detect which applies in the tracker adapter, and move lane triggers to the field change. The decisions, migration plan and done-when items are already specific, so I see no open intent question. The issue names two slices (status-field-adapter, status-migration), so it needs splitting. #7571 is listed as a dependency but I couldn't find it among the open issues I was given, so I recorded no blocker. The last done-when item (the first livefield_addedrun) can only be checked after the trigger moves. I found no likely duplicates.Automated triage, applied by the lanes App.
kyle-sexton commentedon Oct 24, 2026
Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.
To hold this issue again, add
needs-human(orstatus: needs-decision) and say why in a comment.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).
melodic-automation-lanes commentedon Oct 24, 2026
The latest triage verdict holds nothing: the issue is at
status: ready.kyle-sexton commentedon Oct 26, 2026
Released for re-triage under the owner's 2026-10-24 rule: an issue stops for a person only for an intent or vision question, a security call, a host or attended run, or spend outside prepaid credit. The hold label came off and intake triage runs again now; it re-applies a hold, with a numbered question, when one of those applies.
To hold this issue again, add
needs-human(orstatus: needs-decision) and say why in a comment.