refactor: 분리되어 관리하고 있던 문서 시스템을 하나로 통일

.agents/skills/refactoring-from-analysis/references/work-item-contract.md

@@ -0,0 +1,35 @@
+# 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.