Skip to content

feat(work-items): read issue status from the Work status field with label fallback #13483

Closed

Description

@kyle-sexton

Refs #7577

Slice 2 of 5 of #7577: label to Work status field cutover.

Outcome

Status readers can read the Work status field, and they do so without changing any answer while labels are still written. During dual-write every status change lands on the labels first and reaches the field afterwards, so the field is never fresher than the labels. The rule:

  1. While an issue carries any status label, the labels decide, exactly as before.
  2. The field may only add a hold (a human-floor state) that the labels lack. It never removes a label-held state and never makes an issue ready.
  3. The field decides alone only when the issue carries no status label.

When slice 5 (#13486) retires the labels, rule 3 makes the field decide with no further reader edit. issueStatus() in .github/actions/resolve-config/issue-status.mjs gains its first production callers.

Change

  • Shared reader .github/actions/resolve-config/read-status.mjs applying the rule. Used by check-wip-cap, check-born-triaged, intake-reenter (comment path), triage-sweep.mjs, label-unblocked.mjs and apply-verdict.mjs's wip check.
  • plugins/work-items/tools/work-item-tracker: the autonomous frontier reads status through the same rule, using the existing status-storage detection.
  • Left on labels: apply-patch.mjs's pre-commit hold recheck, and intake-reenter's label-removal paths.

Done when

  • Each reader's existing label-only cases give the same answers through a reader whose field equals the labels' collapsed state. One case shows the field adding a hold the labels lack, and one shows the field deciding for an issue with no status label.
  • The tracker conformance suite passes for local-markdown with field detection, and for github where a sandbox repository is configured (work-items: work-item status as a field with labels as fallback #7577 done-when 1).
  • A live recount of open issues reads 0 drifted and 0 unset. Check: the newest daily full sweep (gh run list -R melodic-software/claude-code-plugins --workflow work-unblock.yml --event schedule --json databaseId,createdAt, taking the run created at 04:47Z) logs swept N: wrote 0, unchanged N, failed 0 (gh run view <id> -R melodic-software/claude-code-plugins --log | grep 'swept '). A write means a drifted or unset field.
  • bash scripts/check-affected.sh --tests passes.

The earlier "field wins" rule was a lane draft, not an owner decision. It was replaced because field-first reads changed lane gate answers (for example, a needs-human added by a person could be missed until the field caught up).

Activity

  1. added
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Nov 5, 2026
  2. github-actions commented on Nov 5, 2026

    @github-actions
    Contributor

    Proposed work class: work-class: scoped
    Basis: automated intake triage; the lanes App applied this class.

    Size: Medium
    Complexity: Medium
    Uncertainty: Known
    Flags: none
    Blocked by: #13482

    Understood: this is slice 2 of #7577. Status readers under .github, the work-item tracker frontier and hold reads, and the babysit-prs verify-cap park would read the Work status field first and fall back to labels. The done-when items are clear: field-wins and field-unset tests per reader, the conformance suite, and check-affected.

    The body says "Depends on slice 1" without a number. I took slice 1 to be #13482 (mirror status-label writers into the field), which is still open. Please correct this if slice 1 is a different issue.

    Automated triage, applied by the lanes App.

  3. added
    priority: mediumReal value, no hard deadline; normal backlog flow.
    and removed
    needs-triageNot yet classified. Floor until a type and one priority tier are set.
    on Nov 5, 2026
  4. added
    status: readyTriaged, unblocked, and fully specified; eligible to pick up.
    work-class: scopedA briefed fix or small feature; blast radius bounded by the brief, tests exist.
    on Nov 5, 2026
  5. melodic-automation-lanes commented on Nov 5, 2026

    @melodic-automation-lanes
    Contributor

    Not admitted to the issue lane yet: blocker #13482 is not closed by a listed human or a merge.

  6. self-assigned this
    on Nov 5, 2026
  7. kyle-sexton commented on Nov 5, 2026

    @kyle-sexton
    MemberAuthor
    No description provided.
  8. added
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    on Nov 5, 2026
  9. github-actions commented on Nov 5, 2026

    @github-actions
    Contributor
    No description provided.
  10. github-actions commented on Nov 5, 2026

    @github-actions
    Contributor

    already-leased: another session holds a live lease on #13483, so run https://github.com/melodic-software/claude-code-plugins/actions/runs/42006384798 ran no model.

  11. kyle-sexton commented on Nov 5, 2026

    @kyle-sexton
    MemberAuthor

    Done-when 3 (live recount before merge): met. At 11:48Z, every open issue's Work status field was read against the state its labels collapse to: open issues 121: match 121, field unset 0, drift 0. That is after #13493's label-event mirror and the first hourly sweep, and after #13494 made the sweep incremental. The PR is #13496, which links this issue with Refs:. What remains is the github conformance binding, which needs a throwaway sandbox repository.

    Posted by host-run Lane 3. This was generated by AI.

  12. melodic-automation-lanes commented on Nov 5, 2026

    @melodic-automation-lanes
    Contributor

    The work-resolve-issue run that agent-ready started ended over 3 hours ago with no report and no pull request. work-unblock removed and added agent-ready back to start a fresh run on main's workflow files. If this run ends the same way, it re-fires the issue again, waiting longer each time.

  13. added
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    and removed
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    on Nov 5, 2026
  14. github-actions commented on Nov 5, 2026

    @github-actions
    Contributor
    No description provided.
  15. github-actions commented on Nov 5, 2026

    @github-actions
    Contributor

    already-leased: another session holds a live lease on #13483, so run https://github.com/melodic-software/claude-code-plugins/actions/runs/42039278809 ran no model.

  16. removed
    agent-readyFully specified and briefed; eligible for autonomous pickup from the frontier.
    on Nov 5, 2026
  17. kyle-sexton commented on Nov 6, 2026

    @kyle-sexton
    MemberAuthor
    No description provided.
  18. kyle-sexton commented on Nov 6, 2026

    @kyle-sexton
    MemberAuthor
    No description provided.
  19. kyle-sexton commented on Nov 6, 2026

    @kyle-sexton
    MemberAuthor

    Close audit (lane 2, hub H69), on main d9098daa3d. Every done-when line is met; closing as completed.

    • Reader cases. The shared reader .github/actions/resolve-config/read-status.mjs and its callers landed with feat(work-items): read issue status from the Work status field with label fallback #13496 (merge 45c8db8b52). All six named readers import it: check-wip-cap, check-born-triaged, intake-reenter/reenter.mjs, triage-sweep.mjs, label-unblocked.mjs and apply-verdict.mjs.
      • read-status.test.mjs:27 covers the field adding a hold the labels lack ("the labels decide and the field only adds a hold they lack").
      • read-status.test.mjs:35 covers the field deciding for an issue with no status label ("with no status label, the field decides alone").
      • node --test on main passes 0 failed in each suite: read-status 9, check-wip-cap 57, check-born-triaged 27, reenter 86, triage-sweep 51, label-unblocked 324, apply-verdict 263.
    • Conformance. run-conformance.sh --binding local-markdown: "Conformance (local-markdown): 131 cases, 0 failed", including the status-storage field-or-labels detection cases (run-conformance.sh:219-224). The github half applies "where a sandbox repository is configured", and none is: bindings/github.sh:17 requires WIT_CONFORMANCE_GITHUB_REPO, which is unset on this host and set by no workflow. That half is left to whoever configures a sandbox; it is not run against a shared repository, since the binding closes every open issue in its target.
    • Live recount, 0 drifted and 0 unset. The newest daily full sweep, scheduled work-unblock run 42164881498 (created 2026-11-06T04:50:43Z), logs swept 56: wrote 0, unchanged 56, failed 0 (113 calls).
    • Tests. feat(work-items): read issue status from the Work status field with label fallback #13496 merged with ci-status SUCCESS, and its select-tests, test-bash (0 to 2), test-python, test-node and check-tests lanes all succeeded. bash scripts/check-affected.sh --tests on main exits 0 ("8 passed, 9 skipped over 0 changed files"). On main alone that compares nothing, so the PR's run is the evidence for this line.

    Next in the chain: #13484 (field-triggered lane run, a workflow edit for Automation Lanes) is unblocked by this close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

priority: mediumReal value, no hard deadline; normal backlog flow.work-class: scopedA briefed fix or small feature; blast radius bounded by the brief, tests exist.

Fields

Work status

ready

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions