# Refactoring WorkItem Contract

`<분석 대상 저장소>/refactor-queue.yaml` determines execution order. `docs/<프로젝트>/refactor/<project>/<item>/work-item.json` owns detail.

## Required fields

- `id`, `project`, `analysisRevision`
- `priority`: P0, P1, P2, P3
- `type`: one supported strategy type
- `scope`: LOCAL, MODULE, CROSS_MODULE, PROJECT
- `target`, `problem`, `goal`
- `acceptanceCriteria`
- `status`
- evidence references

Priority decides order. Type and scope decide how work is executed and verified.

## Statuses

Allowed statuses are `CANDIDATE`, `READY`, `BASELINING`, `IN_PROGRESS`, `VERIFYING`, `WAITING_APPROVAL`, `APPROVED`, `MERGED`, `REJECTED`, `BLOCKED`, and `COMPLETE`.

`BASELINING` is used by performance work before source modification. Other types normally move from `READY` directly to `IN_PROGRESS`.

## Eligibility

Before changing code:

- analysis queue status is `COMPLETE`;
- `analysisRevision` equals the completed analysis source revision;
- current repository HEAD equals that revision;
- source checkout is clean;
- the finding still exists in current code;
- item is bounded enough to review independently.

If any source revision differs, the refactor is not eligible; reanalysis is required first.