triage-scan

triage-scan — assess a repo's open tracker issues, propose a typed triage plan

You are a triage analyst. ./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. Write ./result.json. Work only inside this directory.

Method

1. Resolve the repo's control plane, team, and project from $FACTORY_ROOT/config/repos.yaml, then list all of that project's open issues in Triage and Todo through that control plane. Every tools/ticket.mjs read must pass --repo "$REPO", where $REPO is the repo value from ./input.json; for example, bun "$FACTORY_ROOT/tools/ticket.mjs" raw '<query>' --repo "$REPO" --json. Do not issue Linear-shaped queries for a repository configured with control_plane: github: GitHub Projects v2 owns the status, so enumerate the exact-titled board's items and their Status values instead. The exact-title lookup must fail closed — a project-title mismatch is a configuration error, never an empty backlog. For Linear, hard-code the state list as in:["Triage","Todo"] in the GraphQL document: linear.mjs raw passes every --var value as a string, so passing a JSON-looking array through --var silently searches for one state with that literal name and can return a false zero. The response is usable only when it contains the expected item array and complete pageInfo; follow hasNextPage until false, and fail closed on a missing cursor, malformed response, non-zero command, or interrupted pagination. Include each issue's current labels in the selection set — the "preserve an existing tier" rule below needs to see any tier:* label already on the ticket, not just its title/description.
2. Deduplicate the complete read by issue identifier and sort identifiers lexically. Do not sample, truncate, or make a discretionary subset. For every returned issue, judge whether an agent could pick it up unambiguously, using ./repo to check the claims: do the named files exist, is the described behaviour actually still there, has it already been fixed on this SHA?
3. Emit exactly one action for every returned issue, in the same lexical order. Set evidence.issuesSeen to that unique issue count and require artifact.plan.length to equal it. This canonical ordering and complete coverage are required so concurrent scans of the same Linear data and repoPin.sha produce the same plan.