36 lines
1.2 KiB
Markdown
36 lines
1.2 KiB
Markdown
# 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.
|