# Defect classification rubric

Classify every merged PR from its title, body, and changed files. Do not infer a defect merely because a PR contains tests, validation, hardening, or the word `fix` in a non-product context.

## Primary classification

- `strict_bug`: Clear evidence that behavior already expected to work was incorrect, broken, regressed, crashed, produced wrong results, exposed a security/privacy problem, or violated an existing contract.
- `incomplete_feature`: A prior implementation shipped or merged without a required part, acceptance criterion, integration, or reachable workflow. This is a defect for broad change-failure analysis but remains separate from strict bugs.
- `ux_defect`: Existing behavior worked mechanically but was materially misleading, inaccessible, unreachable, confusing, or unusable. Keep separate from strict correctness defects.
- `new_functionality`: Adds a new behavior or capability without evidence that a prior change was defective.
- `spec_only`: Commits only planning/specification artifacts.
- `docs_content`: Documentation, editorial, research, or marketing content without a product-code defect.
- `infra_maintenance`: CI, deployment, dependency, tooling, observability, or operational work without evidence of a prior failure caused by a change.
- `refactor_test_only`: Refactor or test expansion without evidence of repairing a product defect.
- `unclear`: The description is insufficient for a defensible classification.

## Fields

Return one JSON object per PR with:

- `pr_number`, `title`
- `classification`
- `defect_domain`: one of `product`, `calculation_model`, `ux`, `security_privacy`, `data`, `test`, `infra`, `docs`, `none`
- `defect_candidate`: true only for `strict_bug`, `incomplete_feature`, or `ux_defect`
- `evidence`: concise description-specific reason
- `origin_pr_hints`: explicit earlier PR numbers named as introducing or owning the behavior; empty when absent
- `same_defect_hints`: related fix PRs named in the body or an obvious shared incident/defect label
- `confidence`: `high`, `medium`, or `low`

Be conservative. A follow-up is not automatically a defect. A PR that fixes an issue in its own unmerged branch is not a post-merge defect. A production incident, wrong financial result, broken route, missing required integration, or regression is a defect candidate.

## Full-history phase analysis

Keep repair workload and defect creation separate:

- **Fix phase** is the active-development phase in which the first PR repairing an underlying defect merged. PR-level strict/broad repair share measures workload in that phase.
- **Origin phase** is the phase containing the inferred PR that introduced the defect. Defective-origin rate and defects per KLOC of changed lines measure later discoveries attributed to that cohort.

An origin must have merged before the first fix PR according to `merged_at`/Git chronology. PR number is not a chronology proxy because long-lived branches can merge out of numerical order.

Phase-origin rates are right-censored. Report the observation-day distribution for each origin cohort and do not compare Phase 3 directly with older phases as if every origin had equal time to reveal a defect. The current ledger uses fixed 14-day and 30-day views; 60/90-day views should be added once enough Phase 3 origins mature.

Work provenance is also separate from authorship:

- `spec implement`: mapped to a committed full specification.
- `spec task`: mapped to a committed task specification.
- `other code`: not durably mapped to either committed-spec run mode.
- `spec authoring`: commits the specification/task without implementing it.

`other code` does not imply manual coding.