triaging-issueslisted

# Triaging Issues How to ground a GitHub issue before the factory pipeline runs on it, or when someone asks for a triage pass outright. The order matters: read, dedupe, label, then decide what the issue needs. Never comment on or change an issue you haven't read in full, including its existing comments and labels. ## 1. Check for duplicates before anything else Running the pipeline on a duplicate wastes a full implementation cycle, and a duplicate comment on a fresh report saves everyone the most time, but only if you are right. - Search the repo's existing issues for the same symptom before doing anything. Search closed issues as well as open ones: many "new" bugs were already fixed or already rejected. - Search by the error message, the API or feature name, and a plain description of the symptom. One search is not enough; reporters describe the same bug in different words. - Treat it as a duplicate only when the underlying cause matches, not just the surface symptom. Two crashes with the same error text can have different roots. - When it is a duplicate of an open issue: comment linking the original by number, apply the repo's duplicate label if one exists, and note anything the new report adds on the original. Don't run the pipeline twice for one problem. - When it duplicates a closed issue that was fixed: point to the fix and the release that carries it, and ask the reporter to confirm on that version before closing. - When you are not sure, say so in your comment ("t