# Workflow Core

## 목표

Plane 통신 토대와 별도 pipeline 설계가 정리된 뒤 실제 상태 변화를 기준으로 task 상태 전이를 정리하고 enqueue / running / completed / failed 흐름을 안정화한다. retry, timeout, notification event의 기본 구조를 추가해 core workflow의 운영 기준을 만든다.

## 단계

Workflow Core

## 상태

계획

## 구현 잠금

- 상태: 해제
- 결정 필요: 없음

## 범위

- task 상태 전이 정리
- enqueue / running / completed / failed 흐름 안정화
- retry / timeout 기본 구조 추가
- notification event 구조 정리
- Plane 통신 토대와 후속 pipeline 설계에서 확인된 상태 변화와 실패 케이스 반영

## 필수 기능

- [ ] [lifecycle-model] task lifecycle 상태 모델 점검
- [ ] [transition-ownership] scheduler와 workflow service의 상태 전이 책임 정리
- [ ] [failure-policy] 실패 task 처리 기준
- [ ] [retry-timeout] retry와 timeout의 최소 정책
- [ ] [notification-model] notification event 모델과 발행 지점

## 완료 기준

- [ ] task가 enqueue 이후 running, completed, failed 상태로 일관되게 전이된다.
- [ ] 실패와 timeout이 관찰 가능한 상태로 남는다.
- [ ] retry 정책의 최소 동작 방식이 구현되거나 명확히 문서화된다.
- [ ] notification event가 workflow 상태 변화와 연결된다.

## 범위 제외

- 실제 외부 협업 도구로 notification 발송
- 복잡한 workflow DSL
- 고급 권한 정책
- multi-tenant 운영 정책

## 작업 컨텍스트

- 이전 출처: `services/core/README.md`의 `## 단계별 다음 작업`
- 주요 작업 영역: `services/core/internal/workflow/`, `services/core/internal/scheduler/`, `services/core/internal/notification/`
- 선행 작업: Plane Communication Foundation, Work Item Provider Pipeline Design
- 후속 작업: External Integration
- 책임 경계:
  - NomadCode Workflow Core는 task lifecycle 전이, retry/timeout envelope, heartbeat, terminal 상태 기록을 소유한다.
  - IOP/A2A/model runtime은 외부 실행 표면이며, 내부 실행 정책과 런타임 세부 retry는 각 adapter 또는 외부 런타임 책임으로 둔다.
  - Workflow Core는 외부 호출 결과를 `completed`, `failed`, `canceled`, `waiting_for_user` 같은 canonical 상태/metadata로 정규화한다.
- notification 최소 범위:
  - 이번 Milestone에서는 core 내부 상태 변화 event 모델과 발행 지점까지만 정한다.
  - Mattermost 등 외부 협업 도구 발송은 External Integration 범위로 넘긴다.
  - provider comment/status/label projection은 workflow 상태 변화의 부수 효과로 재시도 가능해야 하며, projection 실패가 canonical task 상태를 되돌리지는 않는다.
- 검증 기준: scheduler, persistence, adapter behavior를 크게 바꾸면 관련 테스트를 함께 갱신한다.
- 확인 필요: 없음