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

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.