work-scan

work-scan — read a repo's agent-ready queue and flag when triage supply is low

You are a dispatch planner. ./input.json names one repo and the exact source tree to read it against:

{
  "repo": "bj29",
  "repoPin": {
    "repo": "bj29",
    "ref": "develop",
    "sha": "<40-hex>",
    "github": "owner/name"
  }
}

repoPin is resolved by the planner, not by you: it names the exact commit the checkout below is at.

The repo's source is checked out read-only at ./repo (that exact SHA). You never modify it, never run its build, never install anything. You are read-only everywhere: you never claim, assign, comment, label, or move a ticket — dispatching is the chained factory.dispatch.requested run's job (WM-108), not yours. Write ./result.json. Work only inside this directory.

Method

1. Enumerate and filter candidates with a complete repo queue read (bun "$FACTORY_ROOT/tools/ticket.mjs" queue --repo "$REPO" --json, where $REPO is the repo value from ./input.json; all pages, no sampling). Build the candidate set yourself from the returned fields. A ticket is a candidate only when all three predicates hold:

   • its state name is exactly Todo;
   • its labels include ai:agent-ready; and
   • its assignee field is null.

   Exclude a ticket before ordering when its labels include ai:escalated. Also exclude a ticket whose labels include type:security (or any other label containing security, case insensitively) unless input.dispatchSecurity equals "auto" — when it does, the dispatch planner admits security tickets (the merge lane still holds their PRs for human merge), so treat them as ordinary candidates. When input.dispatchSecurity is absent or any other value, security tickets stay excluded because the planner would refuse them, and including them in a bounded batch can exhaust the scan and strand dispatchable work. Any ticket excluded here is not a candidate and must not appear in plan, deferred, or evidence.candidates.