# Trinity v0.7.0 후속 구현 후보

작성일: 2026-06-04  
대상 브랜치: `codex/v070-workflow-followups`  
상태: 후속 구현 후보 정리

## 1. 현재 기준선

v0.7.0 workflow engine의 주요 구조는 구현되어 있다.

- Provider readiness/auth gating
- Interactive response contract와 response artifact 저장
- Workflow state machine과 user decision loop
- Structured deliberation/blueprint consensus
- Blueprint decomposition과 work package execution protocol MVP
- Shared ledger renderer, LifecycleGuard MVP, peer review planning foundation
- 명시적 `/answer` UX, `/questions --select`, `/questions --select --all`
- 한국어/번호형 open question parser 보강

자동 검증 기준선:

```text
uv run pytest -q
901 passed, 1 warning
```

남은 작업은 크게 두 종류다.

1. **릴리스 전 검증 게이트**: 실제 WSL/tmux/provider 환경에서 지금 구현이 동작하는지 확인한다.
2. **후속 구현 후보**: v0.7.0 이후 또는 v0.7.x에서 workflow 완성도를 높이는 기능이다.

## 2. 릴리스 전 검증 게이트

### G0. WSL/tmux/provider end-to-end smoke

이 항목은 코드 구현보다 먼저 수행해야 하는 검증이다.

#### 이유

현재 자동 테스트는 unit/mock 중심이다. provider CLI의 실제 TUI repaint, tmux pane 폭, 인증/모델 로딩 화면,
prompt echo 경계는 자동 테스트만으로 완전히 검증하기 어렵다.

#### 실행 범위

- Claude/Codex/Gemini가 모두 ready 상태인 세션
- readiness strict mode에서 unready provider 차단
- degraded mode에서 ready provider만으로 진행
- 설계 요청에서 structured open question 생성
- `/questions --select --all`로 decision wizard 처리
- decision 이후 deliberation 재개
- blueprint 생성
- execution package dispatch와 `Task Results` 기록

#### 산출물

- `docs/test-results/v070-smoke-checklist.md` Pass/Fail 업데이트
- 실패 시 pane capture 일부와 원인 분류 기록
- 실패가 재현 가능하면 별도 follow-up issue/PR 후보로 분리

#### 완료 기준

- 최소 1회 실제 3-provider smoke가 blueprint 또는 명확한 readiness failure까지 도달한다.
- `needs_user_decision` 상태에서 일반 텍스트가 자동 decision으로 오기록되지 않는다.
- `/questions --select --all`이 options 질문과 자유 텍스트 질문을 모두 처리한다.

## 3. 후속 구현 후보

### F1. Peer review prompt execution loop

#### 현재 상태

`PeerReviewPlanner`는 execution result 이후 review package를 계획하고 persistence한다.
하지만 실제 reviewer agent에게 review prompt를 보내고 결과를 workflow state에 반영하는 loop는 아직 없다.

#### 목표

`REVIEWING` 상태를 실제 agent review 단계로 확장한다.

```text
EXECUTING
  -> REVIEWING
  -> review package dispatch
  -> review result collect
  -> DONE | NEEDS_USER_DECISION | FAILED
```

#### 구현 후보

- `ReviewExecutionProtocol` 또는 `ExecutionProtocol` 내 review dispatch 경로 추가
- `ReviewResult` persistence와 shared ledger `## Reviews` 렌더링
- TUI 명령 추가 후보:
  - `/reviews`: planned/running/done review 표시
  - `/review run`: pending review 실행
- reviewer response contract:

```text
## Review Summary
## Findings
## Required Changes
## Approval
APPROVE | CHANGES_REQUIRED | BLOCKED
```

#### 테스트 후보

- `tests/test_peer_review.py`: review result parsing/serialization
- `tests/test_workflow_engine.py`: `REVIEWING -> DONE/NEEDS_USER_DECISION/FAILED`
- `tests/test_tui_session.py`: `/reviews` 표시
- `tests/test_execution_protocol.py`: review prompt dispatch mock

#### 완료 기준

- execution이 모두 `DONE`이면 review package가 실제 reviewer agent에게 전송된다.
- 모든 review가 `APPROVE`이면 workflow가 `DONE`으로 이동한다.
- `CHANGES_REQUIRED` 또는 `BLOCKED`이면 work package 상태와 user decision/open question으로 연결된다.

### F2. Lifecycle rotation 실 workflow 통합 보강

#### 현재 상태

`LifecycleGuard`는 process/readiness/context ratio/projected ratio를 평가한다.
문서상 hook은 deliberation/execution 전후까지 확장되어 있지만, 실제 provider 세션에서
rotation이 모든 workflow 구간에서 안정적으로 이어지는지는 smoke가 필요하다.

#### 목표

context threshold 도달 시 workflow state를 잃지 않고 다음 prompt 전에 세션 요약과 새 provider session을 보장한다.

#### 구현 후보

- user decision 이후 deliberation continuation prompt 직전 guard 평가
- review dispatch 전후 guard 평가
- rotation 발생 시 `events.jsonl`에 `rotation_requested`, `rotation_completed` 기록
- `shared.md ## Session History`에 rotation summary가 누락되지 않도록 검증
- TUI `/status`에 projected prompt ratio와 rotation action hint 표시

#### 테스트 후보

- `tests/test_lifecycle_guard.py`: user decision/review hook coverage
- `tests/test_workflow_engine.py`: rotation event persistence
- `tests/test_tui_session.py`: rotation hint rendering
- 실제 smoke: context threshold를 낮춘 config로 강제 rotation

#### 완료 기준

- threshold 초과 시 다음 provider call 전에 rotation이 수행된다.
- rotation 이후 workflow id, decisions, open questions, work packages가 유지된다.
- rotation summary가 shared ledger와 event log에 남는다.

### F3. Non-blocking question 정책

#### 현재 상태

`OpenQuestion.blocking` 필드는 존재하지만, workflow는 open question이 있으면 대체로
`NEEDS_USER_DECISION`으로 이동한다. non-blocking question을 표시만 하고 진행하는 정책은 아직 명확하지 않다.

#### 목표

blocking question과 non-blocking question을 분리한다.

```text
blocking open question 있음 -> NEEDS_USER_DECISION
non-blocking open question만 있음 -> workflow 계속 진행, /questions에 표시
```

#### 구현 후보

- `WorkflowSession.blocking_open_questions` property 추가
- `WorkflowEngine._apply_structured_questions()`에서 blocking 여부에 따라 state transition 분기
- `/questions`에 `blocking` column/badge 표시
- `/questions --select --all`은 blocking 질문을 우선 처리
- non-blocking question answer는 workflow continuation을 강제로 시작하지 않음

#### 테스트 후보

- `tests/test_workflow_engine.py`: non-blocking question만 있을 때 `BLUEPRINT_READY` 또는 `DELIBERATING` 유지
- `tests/test_tui_session.py`: blocking/non-blocking 표시
- `tests/test_shared_ledger.py`: question blocking flag 렌더링

#### 완료 기준

- non-blocking question만 남아도 workflow가 멈추지 않는다.
- 사용자는 `/questions`에서 non-blocking question을 확인하고 선택적으로 답할 수 있다.
- blocking question은 기존처럼 answer 전까지 continuation을 막는다.

### F4. Workflow repair/reset UX

#### 현재 상태

`/answer --replace`로 잘못 기록한 decision을 정정할 수 있다.
하지만 smoke 중 깨진 workflow session을 깨끗하게 되돌리거나 특정 decision을 제거하는 UX는 없다.

#### 목표

실사용 중 잘못 기록된 workflow state를 안전하게 복구한다.

#### 구현 후보

- `/workflow reset`: 현재 workflow session을 백업 후 idle로 초기화
- `/undo dec-001`: decision 제거 또는 이전 값 복원
- `/workflow export`: session/debug bundle 생성
- reset 전 확인 prompt 또는 `--yes` 옵션
- `.trinity/workflow/backups/`에 reset 전 session snapshot 저장

#### 테스트 후보

- `tests/test_workflow_engine.py`: decision undo와 state recompute
- `tests/test_workflow_persistence.py`: reset backup persistence
- `tests/test_tui_session.py`: command routing과 확인 메시지

#### 완료 기준

- 사용자가 잘못된 decision/session을 삭제하지 않고 백업 후 초기화할 수 있다.
- reset/undo 후 `session.json`과 `events.jsonl`이 일관된다.
- 일반 입력 오기록 같은 smoke 실패를 사용자가 수동 파일 삭제 없이 복구할 수 있다.

## 4. 권장 순서

1. **G0 WSL/tmux/provider smoke**
   - 지금 구현의 실제 수용 여부를 먼저 확인한다.
2. **F1 Peer review prompt execution loop**
   - workflow의 `REVIEWING` 상태를 실제 완료 루프로 연결한다.
3. **F2 Lifecycle rotation 실 workflow 통합 보강**
   - 긴 workflow에서 session/context 안정성을 확보한다.
4. **F3 Non-blocking question 정책**
   - 질문 UX를 blocking/non-blocking으로 정교화한다.
5. **F4 Workflow repair/reset UX**
   - 실사용 복구성과 디버깅 편의성을 높인다.

## 5. PR 분리 기준

각 후보는 별도 PR로 분리하는 것이 좋다.

| 후보 | 권장 PR 범위 | 이유 |
|------|--------------|------|
| G0 | 문서/결과 기록 또는 smoke failure fix | 검증 결과에 따라 코드 수정 범위가 달라짐 |
| F1 | review protocol + tests + docs | workflow state transition에 영향이 큼 |
| F2 | lifecycle hooks + rotation evidence | provider/session runtime 리스크가 큼 |
| F3 | question state policy + TUI 표시 | decision UX와 state transition 변경 |
| F4 | persistence repair commands | destructive/backup UX가 필요 |

## 6. 비목표

다음은 이 후보 문서의 직접 범위가 아니다.

- 새 provider 추가
- GUI/web dashboard
- provider 내부 subagent 직접 제어
- secrets/config 자동 마이그레이션
- release/publish 절차

위 항목은 필요하면 별도 계획 문서로 분리한다.
