Chorus에서 다루는 모든 일은 세 가지 엔티티, 즉 **아이디어(Idea)**, **제안(Proposal)**, **작업(Task)** 중
하나이며, 각각은 작고 고정된 상태 집합을 거쳐 갑니다. 이 페이지는 엔티티별로 그 상태를 나열하고,
각 상태가 무엇을 뜻하며, 어떤 동작이 엔티티를 앞으로 나아가게 하는지 설명합니다.

전달 흐름 전체가 단계 사이를 어떻게 인계하는지에 대한 상위 관점은
[워크플로 참고](/ko/reference/workflow/)를 보세요. 이 페이지는 그 내용을 엔티티별로 자세히 다룹니다.

## 아이디어(Idea)

아이디어 자체에 저장되는 상태는 **요구사항 구체화(elaboration)** 단계만 나타냅니다. 구체화가
완료되면 아이디어는 끝난 것으로 간주됩니다. 보드에서 보이는 이후의 진행, 즉 계획, 개발, 검증, 완료는
아이디어 자체에 저장된 것이 아니라 연결된 제안과 작업에서 **파생**됩니다.

| 상태 | 의미 | 앞으로 나아가게 하는 것 |
| --- | --- | --- |
| `open` | 만들어졌지만 아직 아무도 맡지 않음. | 누군가 아이디어를 가져가거나 에이전트가 구체화를 시작함 → `elaborating`. |
| `elaborating` | 요구사항 구체화 진행 중: 에이전트가 확인 질문을 라운드로 던지고 사용자가 답함. | 구체화가 확정됨(모든 질문에 답하거나 구체화를 건너뜀) → `elaborated`. |
| `elaborated` | 마지막 저장 상태. 공통된 이해가 확인되었고 아이디어가 제안으로 넘어갈 준비가 됨. | 더 이상의 저장 상태 전이는 없음. 이후의 진행은 파생됨(아래 참조). |

### 파생되는 진행

아이디어가 `elaborated`에 이르면, Chorus는 연결된 제안과 작업의 상태로부터 보드용 표시 상태를
계산합니다. 아이디어에는 저장된 `completed`나 `closed` 상태가 없으며, 아이디어의 상태를 직접 설정하는
방법도 없습니다. 상태는 요구사항 구체화와 후속 작업의 진행에 따라서만 바뀝니다.

| 파생 라벨 | 적용되는 경우 |
| --- | --- |
| 계획 중 | 구체화되었지만 아직 제출된 제안이 없음(제안이 없거나 초안 상태). |
| 제안 검토 | 제안이 제출되어 사용자의 검토를 기다리는 중. |
| 개발 중 | 제안이 승인되었고 그 작업이 진행되고 있음. |
| 작업 검증 | 최소 하나의 작업이 검증에 제출됨. |
| 완료 | 제안이 승인되었고 모든 작업이 `done`(또는 `closed`)에 도달함. |

## 제안(Proposal)

제안은 검토용 컨테이너입니다. 에이전트가 준비한 문서 초안과 작업 초안을 담으며, 승인하면 그 초안들로부터
**실제 문서와 작업이 생성**됩니다.

| 상태 | 의미 | 앞으로 나아가게 하는 것 |
| --- | --- | --- |
| `draft` | 작성·편집 중. 문서 초안과 작업 초안은 이 상태에서만 추가하거나 변경할 수 있음. | 작성자가 검토에 제출함 → `pending`. |
| `pending` | 제출되어 검토자를 기다리는 중. | 검토자가 승인함 → `approved`, 또는 거부함 → `draft`로 돌아감(검토 메모 포함). |
| `approved` | 받아들여짐. 문서 초안과 작업 초안으로부터 실제 문서와 작업이 생성됨. | 검토 흐름의 최종 상태. |
| `closed` | 철회되거나 폐기됨. 이 제안에서 만든 작업도 닫힘. | 최종 상태. |

거부된 제안은 `draft`로 돌아가 작성자가 수정해 다시 제출할 수 있으며, 검토자의 메모는 수정 맥락으로
남습니다. 삭제할 수 있는 것은 `draft` 또는 `closed` 상태의 제안뿐입니다.

## 작업(Task)

작업은 하나의 작업 단위가 실행과 검증을 거치는 과정을 나타냅니다.

| 상태 | 의미 | 앞으로 나아가게 하는 것 |
| --- | --- | --- |
| `open` | 맡지 않았고 가져갈 수 있음. | 누군가 가져가거나 배정됨 → `assigned`. |
| `assigned` | 담당자는 있지만 작업이 시작되지 않음. | 담당자가 작업을 시작함 → `in_progress`(모든 의존 관계가 해소된 경우에만). |
| `in_progress` | 작업 중. | 담당자가 제출함 → `to_verify`. |
| `to_verify` | 작업이 끝나고 증거가 제출되어 검증을 기다리는 중. | 검증자가 받아들임 → `done`, 또는 되돌려 보냄 → `in_progress`. |
| `done` | 검증되어 완료됨. | 정상 흐름의 최종 상태. |
| `closed` | 취소됨. 예를 들어 해당 제안이 철회된 경우. | 최종 상태. |

### 의존과 잠금 해제

작업은 다른 작업에 의존할 수 있으며, 이 관계는 유향 비순환 그래프를 이룹니다. 의존하는 작업은 **선행 작업이 모두
`done`에 도달해야만 차단이 풀립니다**(선행 작업이 `closed`인 경우도 해소된 것으로 간주). 그전까지는
`in_progress`로 넘어갈 수 없습니다. 작업이 `to_verify`에서 `done` 이외의 상태로 이동하면
그 수락 기준이 초기화됩니다. 이 의존 연결은 [프로젝트 리소스 그래프](/ko/reference/resource-graph/)에서
볼 수 있으며, 작업 페이지의 **DAG** 뷰에서 추가·편집할 수 있습니다([작업 실행](/ko/guides/run-tasks/) 참조).

:::note[에이전트가 하는 일]
에이전트는 작업을 `assigned → in_progress → to_verify`로 진행시키고, 각 작업의 수락 기준에 대해 증거를
제출합니다. 최종 `to_verify → done` 검증은 사람(또는 그를 대신하는 관리자 에이전트)이 수행합니다. 그
연결이 어떻게 작동하는지는 [에이전트 플랫폼](/ko/reference/agents/) 참고 문서를 보세요.
:::