code-agent: rework issue 8
Review-ID: 38
Previous-SHA: 1f73b4bd41
Plan-SHA256: cbefda14ef548909f419e943825b3d11d9dff9809b9bb443b06d43db183063c0
Bundle-SHA256: 29ce1ef1917864f79938459725201e6e74d67e21b1f817ac53d7b294eca8f1a2
This commit is contained in:
@@ -22,51 +22,35 @@
|
||||
|
||||
## 1. 목적
|
||||
|
||||
이 요구사항은 Textual 기반 대화형 TUI에서 사용자가 입력한 메시지를 정규화하고 세션 내 대화 영역에 누적 표시하는 동작을 정의한다. 유효한 입력에는 고정된 응답 목록에서 하나를 선택하여 사용자 메시지 바로 뒤에 표시하고, 공백만 포함하거나 비어 있는 입력은 대화 상태를 변경하지 않고 무시한다. 입력을 처리한 뒤 입력창을 비우며, 기존 프로젝트 스캐폴드와 실행 진입점에 의존하여 동일한 애플리케이션 흐름 안에서 동작하도록 보장한다.
|
||||
이 요구사항은 Textual 기반 대화형 TUI에서 사용자가 제출한 입력을 정규화하고, 유효한 메시지와 고정 응답을 세션 내 대화 영역에 순서대로 누적 표시하는 동작을 정의한다. 공백만 포함하거나 비어 있는 입력은 대화 상태를 변경하지 않고 무시하며, 모든 제출 후 입력창을 비운다. 사용자와 에이전트의 역할을 라벨과 구조적 스타일로 구분하고, Escape 및 Ctrl+Q를 통한 종료 요청을 보장한다. 이 대화 동작은 프로젝트 스캐폴드와 실행 진입점을 선행 조건으로 사용하며, 원본 Gitea 이슈 #8의 재작업 범위에서 관리한다.
|
||||
|
||||
## 2. 배경
|
||||
|
||||
현재 애플리케이션은 Python 3.11 이상과 Textual 런타임을 사용하는 로컬 TUI로 제공된다. 사용자는 입력창에 메시지를 작성하고 Enter를 눌러 제출하며, 애플리케이션은 입력 양끝의 공백을 제거한 결과를 세션의 사용자 메시지로 기록한다. 정규화 결과가 유효하면 고정된 다섯 개 응답 중 하나를 표준 난수 선택 방식으로 결정하고, 사용자 메시지와 에이전트 응답을 정해진 순서로 대화 영역에 표시한다.
|
||||
애플리케이션은 Python 3.11 이상과 Textual 런타임을 사용하는 로컬 TUI로 제공된다. 사용자는 입력창에 문자열을 작성하고 Enter로 제출하며, 시스템은 입력 양끝의 공백을 제거한 뒤 유효성을 판단한다. 유효한 입력에는 사전에 정의된 다섯 개의 고정 응답 중 하나를 표준 난수 선택 방식으로 연결하고, 사용자 메시지와 에이전트 응답을 제출 순서대로 표시한다.
|
||||
|
||||
대화 기능은 외부 API, LLM, 데이터베이스 또는 영속 저장소를 사용하지 않는다. 메시지와 선택 결과는 실행 중인 세션의 메모리 상태로 관리하며, 프로젝트의 설치 및 실행 기반은 선행 요구사항에 정의된 계약을 따른다.
|
||||
메시지와 응답은 실행 중인 세션의 메모리 상태로만 관리하며 외부 API, LLM, 네트워크 서비스, 데이터베이스 또는 영속 저장소를 사용하지 않는다. 프로젝트 설치와 실행 진입점은 선행 스캐폴드 요구사항의 계약을 따르고, 대화 상호작용의 상세 규칙과 수용 기준은 이 문서에서 단일 정본으로 관리한다. 원본 근거는 Gitea 이슈 #8이다.
|
||||
|
||||
## 3. 범위
|
||||
|
||||
포함 범위는 다음과 같다.
|
||||
포함 범위는 입력 양끝의 공백 제거와 유효 입력 판정, 유효한 사용자 메시지와 고정 응답의 세션 내 누적, 표준 난수 방식의 응답 선택, 사용자 메시지 뒤에 응답을 배치하는 순서 보장, 사용자와 에이전트의 라벨 및 구조적 스타일 구분, 빈 입력과 공백 입력의 무시, 제출 후 입력창 초기화, Escape 및 Ctrl+Q 종료 요청이다. 선행 프로젝트 스캐폴드 요구사항과의 의존 관계 및 Gitea 이슈 #8 추적성도 포함한다.
|
||||
|
||||
- 입력값의 양끝 공백 제거와 정규화 결과 판정
|
||||
- 유효한 사용자 입력과 선택된 에이전트 응답의 세션 내 누적
|
||||
- 고정된 응답 목록에서 표준 난수 선택 방식으로 응답 결정
|
||||
- 사용자 메시지를 먼저 표시하고 그 바로 뒤에 에이전트 응답을 표시하는 순서 보장
|
||||
- 작성자 역할에 따른 사용자 및 에이전트 라벨과 구조적 표시 스타일 제공
|
||||
- 공백만 포함하거나 비어 있는 입력의 무시
|
||||
- 입력 제출 후 입력창 초기화
|
||||
- Escape 및 Ctrl+Q를 통한 애플리케이션 종료 요청
|
||||
- 선행 프로젝트 스캐폴드 요구사항과의 의존 관계 및 원본 이슈 추적
|
||||
|
||||
제외 범위는 다음과 같다.
|
||||
|
||||
- 프로젝트 패키징, 설치 설정 및 실행 진입점 자체의 변경
|
||||
- 고정 응답 문구, 입력 처리 순서, 사용자 인터페이스 동작의 변경
|
||||
- 외부 API, LLM, 네트워크 서비스, 데이터베이스 및 영속 저장소 연동
|
||||
- 사용자 인증, 권한 관리, 다중 세션 관리 및 메시지 복원
|
||||
- 새로운 런타임 의존성, 배포 방식 또는 실행 환경 추가
|
||||
프로젝트 패키징, 설치 설정, 실행 진입점 자체의 변경은 포함하지 않는다. 고정 응답 문구, 입력 처리 순서와 사용자 인터페이스 의미를 변경하지 않으며, 외부 API, LLM, 네트워크 서비스, 데이터베이스, 영속 저장소, 인증, 권한 관리, 다중 세션, 메시지 복원, 새 의존성, 배포 방식 또는 실행 환경의 추가도 포함하지 않는다.
|
||||
|
||||
### 포함
|
||||
|
||||
사용자 입력의 trim 정규화, 유효한 메시지의 세션 내 누적, 고정된 응답 목록에서의 응답 선택과 표시, 사용자 메시지와 에이전트 응답의 순서 보장, 빈 입력 무시, 입력창 초기화, Escape 및 Ctrl+Q 종료 동작을 다룬다. REQ-001이 제공하는 프로젝트 스캐폴드와 실행 진입점을 선행 조건으로 사용한다.
|
||||
사용자 입력의 양끝 공백 제거와 유효성 판정, 유효 메시지와 고정 응답의 세션 내 누적 및 표시, 응답 선택 순서, 사용자와 에이전트의 역할별 표시, 빈 입력 무시, 입력창 초기화, Escape와 Ctrl+Q 종료 동작 및 REQ-001 의존 관계와 원본 이슈 #8 추적성을 포함한다.
|
||||
|
||||
### 제외
|
||||
|
||||
프로젝트 스캐폴드, 패키징 메타데이터와 실행 진입점의 변경은 다루지 않는다. 고정 응답 문구, 입력 처리 순서와 사용자 인터페이스 의미를 변경하지 않으며, LLM, 외부 API, 네트워크 연동, 영속 저장소, 새 의존성, 배포 환경 변경도 포함하지 않는다.
|
||||
프로젝트 패키징, 설치 설정 및 실행 진입점의 변경, 외부 API·LLM·네트워크 서비스·데이터베이스·영속 저장소 연동, 사용자 인증과 다중 세션 관리, 새로운 의존성·배포 방식·실행 환경 추가는 포함하지 않는다.
|
||||
|
||||
## 4. 용어와 기준
|
||||
|
||||
입력은 사용자가 입력창에서 제출한 문자열이며, 정규화는 문자열 양끝의 공백을 제거하는 것을 의미한다. 정규화 결과가 빈 문자열이면 유효하지 않은 입력으로 판단한다.
|
||||
입력은 사용자가 입력창에서 제출한 문자열이고, 정규화는 문자열 양끝의 공백을 제거하는 처리다. 정규화 결과가 빈 문자열이면 유효하지 않은 입력으로 판단한다.
|
||||
|
||||
유효한 메시지는 정규화된 사용자 입력과 고정 응답 목록에서 선택된 응답으로 구성된 한 쌍의 대화 항목이다. 사용자 메시지는 사용자 역할을 가지며, 선택된 응답은 에이전트 역할을 가진다. 화면 라벨은 각각 사용자와 에이전트로 표시하고 역할에 대응하는 구조적 스타일을 적용한다.
|
||||
유효한 제출은 정규화된 사용자 메시지와 고정 응답 목록에서 선택된 에이전트 응답으로 구성된다. 사용자 메시지는 사용자 역할과 사용자 라벨을 가지며, 응답은 에이전트 역할과 에이전트 라벨을 가진다. 각 역할의 표시는 서로 다른 구조적 스타일을 사용하고, 역할과 본문은 세션 메시지의 정본 상태로 함께 보존한다.
|
||||
|
||||
고정 응답 목록은 다음 다섯 문구를 정본으로 사용한다.
|
||||
고정 응답 목록은 다음 다섯 문구로 구성한다.
|
||||
|
||||
- 안녕하세요! 무엇을 도와드릴까요?
|
||||
- 그것은 제가 처리하기 불가능합니다.
|
||||
@@ -74,68 +58,72 @@
|
||||
- 지금 처리 중입니다.
|
||||
- 작업을 완료하였습니다.
|
||||
|
||||
응답 선택은 표준 난수 선택 기능에 이 목록 전체를 전달하여 수행한다. 선택 결과는 입력마다 하나만 생성하며, 사용자 메시지 다음에 즉시 배치한다. 세션의 메시지 순서와 입력별 선택 결과는 실행 중 메모리 상태를 정본으로 삼는다. 종료 요청은 Escape 또는 Ctrl+Q 입력으로 발생하며, 종료 과정에서 외부 상태나 영속 데이터는 생성하지 않는다.
|
||||
응답 선택은 유효한 입력마다 이 목록 전체를 대상으로 표준 난수 선택을 한 번 수행한다. 선택된 응답은 해당 사용자 메시지 바로 뒤에 배치한다. 종료 요청은 Escape 또는 Ctrl+Q 입력으로 발생하며 종료 과정에서 외부 상태나 영속 데이터를 생성하지 않는다.
|
||||
|
||||
## 5. 요구사항
|
||||
|
||||
시스템은 다음 대화 상호작용 요구를 충족해야 한다.
|
||||
시스템은 다음 대화 상호작용을 제공해야 한다.
|
||||
|
||||
- 사용자가 입력을 제출하면 입력 양끝의 공백을 제거한 값을 처리 대상으로 사용해야 한다.
|
||||
- 정규화한 값이 비어 있지 않은 경우에만 유효한 사용자 메시지로 기록하고 화면에 표시해야 한다.
|
||||
- 유효한 입력마다 고정된 다섯 개 응답 목록 전체에서 표준 난수 선택 방식으로 응답 하나를 선택해야 한다.
|
||||
- 입력 제출 시 입력 양끝의 공백을 제거한 값을 처리 대상으로 사용해야 한다.
|
||||
- 정규화 결과가 비어 있지 않을 때만 사용자 메시지를 세션 상태와 화면에 기록해야 한다.
|
||||
- 유효한 입력마다 고정된 다섯 개 응답 목록 전체에서 표준 난수 방식으로 응답 하나를 선택해야 한다.
|
||||
- 사용자 메시지는 사용자 역할과 사용자 라벨로 표시하고, 선택된 응답은 에이전트 역할과 에이전트 라벨로 표시해야 한다.
|
||||
- 각 입력의 사용자 메시지와 응답은 사용자 메시지가 먼저 오고 응답이 바로 뒤따르는 순서로 대화 영역에 누적해야 한다.
|
||||
- 여러 입력을 제출한 경우 이전 대화 항목을 삭제하거나 재배열하지 않고 제출 순서를 유지해야 한다.
|
||||
- 유효한 입력을 처리한 뒤 입력창의 값은 빈 문자열로 초기화해야 한다.
|
||||
- 비어 있거나 공백만 포함한 입력은 응답을 선택하지 않고 메시지 상태와 화면을 변경하지 않아야 한다.
|
||||
- 공백 입력을 무시하더라도 입력창은 초기화해야 한다.
|
||||
- Escape와 Ctrl+Q 입력은 애플리케이션 종료 동작을 요청해야 한다.
|
||||
- 대화 동작은 외부 API, LLM, 네트워크 서비스, 데이터베이스 또는 영속 저장소를 호출하지 않아야 한다.
|
||||
- 기존 프로젝트 스캐폴드와 실행 진입점의 의미를 변경하지 않고 선행 요구사항이 제공하는 실행 환경에서 동작해야 한다.
|
||||
- 각 사용자 메시지는 대응하는 에이전트 응답보다 먼저 표시되어야 하며, 두 항목은 인접한 순서를 유지해야 한다.
|
||||
- 여러 입력을 제출해도 이전 대화 항목을 삭제하거나 재배열하지 않고 제출 순서대로 누적해야 한다.
|
||||
- 유효한 입력을 처리한 뒤 입력창은 빈 문자열로 초기화되어야 한다.
|
||||
- 빈 문자열 또는 공백, 탭, 줄바꿈만 포함한 입력은 응답 선택과 메시지 추가 없이 무시해야 한다.
|
||||
- 무효 입력을 무시하더라도 입력창은 빈 문자열로 초기화되어야 한다.
|
||||
- 역할에 따라 라벨과 구조적 스타일을 일관되게 적용해야 하며, 스타일만으로 역할을 판단하는 구조를 사용해서는 안 된다.
|
||||
- Escape와 Ctrl+Q 입력은 동일한 애플리케이션 종료 동작을 요청해야 한다.
|
||||
- 종료 입력은 메시지 제출이나 응답 선택으로 해석되어서는 안 되며, 종료 시 새 대화 항목을 추가해서는 안 된다.
|
||||
- 대화 처리는 외부 API, LLM, 네트워크 서비스, 데이터베이스 또는 영속 저장소를 호출하지 않아야 한다.
|
||||
- 선행 프로젝트 스캐폴드와 실행 진입점의 의미를 변경하지 않고 해당 실행 환경에서 동작해야 한다.
|
||||
- 기존 구현과 테스트가 보장하는 입력 정규화, 메시지 누적, 응답 선택과 표시, 빈 입력 무시, 입력창 초기화 및 종료 동작을 유지해야 한다.
|
||||
- 이 대화 동작의 근거와 변경 추적 대상은 Gitea 이슈 #8로 명시해야 하며, 패키징과 실행 기반의 상세 계약은 선행 요구사항에서 중복 정의하지 않아야 한다.
|
||||
|
||||
### REQ-002.01 — 입력 정규화와 유효 입력 판정
|
||||
|
||||
사용자가 입력을 제출하면 시스템은 앞뒤 공백을 제거한 값을 정규화한다. 정규화한 값이 빈 문자열이면 해당 제출을 유효한 메시지로 처리하지 않고, 응답을 선택하거나 대화 영역에 항목을 추가하지 않는다. 하나 이상의 문자가 남은 입력만 유효한 사용자 메시지로 처리한다.
|
||||
사용자가 입력창에서 문자열을 제출하면 시스템은 문자열 양끝의 공백을 제거한 값을 정규화된 입력으로 사용해야 한다. 정규화 결과가 하나 이상의 문자를 포함하면 유효한 사용자 메시지로 처리하고, 빈 문자열이면 유효한 메시지로 처리하지 않아야 한다. 공백, 탭 또는 줄바꿈만 포함한 입력은 응답 선택이나 대화 항목 추가 없이 무시해야 한다.
|
||||
|
||||
**영향 범위**
|
||||
|
||||
인터페이스: 입력 위젯의 제출 처리와 대화 표시 흐름에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: TUI 사용자와 대화 상태를 확인하는 테스트. 마이그레이션: 필요 없음. 호환성: 기존의 앞뒤 공백 제거와 공백 입력 무시 동작을 유지한다. 배포 전제 조건: 선언된 Textual 런타임에서 입력 이벤트를 처리할 수 있어야 한다.
|
||||
인터페이스: 입력 위젯의 제출 이벤트와 대화 표시 흐름에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: TUI 사용자와 대화 상태를 검증하는 테스트. 마이그레이션: 필요 없음. 호환성: 기존의 양끝 공백 제거와 빈 입력 무시 동작을 유지한다. 배포 전제 조건: REQ-001이 제공하는 Textual 실행 환경이 필요하다.
|
||||
|
||||
### REQ-002.02 — 유효 메시지와 고정 응답을 순서대로 누적 표시한다
|
||||
### REQ-002.02 — 유효 메시지와 고정 응답을 순서대로 누적한다
|
||||
|
||||
유효한 입력이 제출되면 시스템은 정규화된 사용자 메시지를 먼저 대화 상태와 대화 영역에 추가하고, 고정된 응답 목록에서 표준 난수 선택으로 하나의 응답을 선택한 뒤 바로 이어서 에이전트 메시지로 추가한다. 제출이 반복될 때마다 각 사용자 메시지와 응답 쌍을 기존 순서 뒤에 누적한다.
|
||||
유효한 입력이 제출되면 시스템은 정규화된 사용자 메시지를 사용자 역할로 먼저 대화 상태와 대화 영역에 추가해야 한다. 이어서 다음 다섯 개의 고정 응답 목록 전체를 표준 난수 선택 기능에 전달하여 응답 하나를 선택하고, 선택된 응답을 에이전트 역할로 사용자 메시지 바로 뒤에 추가해야 한다: 안녕하세요! 무엇을 도와드릴까요?, 그것은 제가 처리하기 불가능합니다., 맡겨만 주세요., 지금 처리 중입니다., 작업을 완료하였습니다. 여러 입력을 제출하면 각 사용자 메시지와 응답 쌍을 기존 순서 뒤에 누적해야 한다.
|
||||
|
||||
**영향 범위**
|
||||
|
||||
인터페이스: 대화 영역의 메시지 순서와 작성자 표시 계약에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: 사용자, TUI 렌더링 계층 및 회귀 테스트. 마이그레이션: 필요 없음. 호환성: 기존 고정 응답 목록과 표준 난수 선택 방식을 유지한다. 배포 전제 조건: Textual 대화 영역과 표준 Python 난수 모듈을 사용할 수 있어야 한다.
|
||||
인터페이스: 대화 영역의 메시지 순서, 본문 및 작성자 역할 표시 계약에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: 사용자, TUI 렌더링 계층 및 회귀 테스트. 마이그레이션: 필요 없음. 호환성: 기존 고정 응답 문구와 표준 난수 선택 방식을 유지한다. 배포 전제 조건: Textual 대화 영역과 Python 표준 난수 기능을 사용할 수 있어야 한다.
|
||||
|
||||
### REQ-002.03 — 제출 후 입력창을 초기화한다
|
||||
|
||||
입력 제출 이벤트가 발생하면 시스템은 제출된 값이 유효한지와 관계없이 입력 위젯의 값을 즉시 빈 문자열로 초기화한다. 초기화는 유효 메시지 처리와 독립적으로 수행되어야 하며, 사용자가 다음 메시지를 입력할 수 있는 상태를 제공한다.
|
||||
입력 제출 이벤트가 발생하면 시스템은 제출된 값이 유효한지와 관계없이 입력 위젯의 값을 빈 문자열로 초기화해야 한다. 입력창 초기화는 유효한 메시지 처리와 독립적으로 수행되어야 하며, 초기화 이후 사용자가 다음 입력을 제출할 수 있어야 한다.
|
||||
|
||||
**영향 범위**
|
||||
|
||||
인터페이스: 입력 위젯의 값과 연속 입력 경험에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: TUI 사용자와 입력 이벤트 테스트. 마이그레이션: 필요 없음. 호환성: 제출 후 입력창이 비워지는 기존 동작을 유지한다. 배포 전제 조건: Textual Input 위젯이 제출 이벤트에서 갱신 가능해야 한다.
|
||||
인터페이스: 입력 위젯의 값과 연속 입력 흐름에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: TUI 사용자와 입력 이벤트 테스트. 마이그레이션: 필요 없음. 호환성: 유효 입력과 무효 입력 제출 후 입력창을 비우는 기존 동작을 유지한다. 배포 전제 조건: Textual Input 위젯을 제출 이벤트에서 갱신할 수 있어야 한다.
|
||||
|
||||
### REQ-002.04 — 역할 기반 메시지 표시를 유지한다
|
||||
|
||||
시스템은 대화 메시지의 작성자 역할을 사용자와 에이전트로 명시적으로 보유하고, 역할에 맞는 라벨과 구조적 스타일을 적용해 표시한다. 사용자 메시지는 사용자 라벨과 사용자 스타일을 사용하고, 응답 메시지는 에이전트 라벨과 응답 스타일을 사용한다.
|
||||
시스템은 각 대화 메시지에 사용자 또는 에이전트의 작성자 역할을 명시적으로 보유해야 한다. 사용자 메시지는 사용자 라벨과 사용자용 구조적 스타일로 표시하고, 고정 응답은 에이전트 라벨과 에이전트용 구조적 스타일로 표시해야 한다. 라벨과 스타일은 임의의 본문 문자열이나 색상만으로 결정하지 않고 메시지 역할에서 일관되게 파생해야 한다.
|
||||
|
||||
**영향 범위**
|
||||
|
||||
인터페이스: 대화 영역의 라벨, 스타일 클래스 및 시각적 구분에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: 사용자, 접근 가능한 화면 검증 및 렌더링 테스트. 마이그레이션: 필요 없음. 호환성: 기존 사용자와 에이전트 역할 구분을 유지한다. 배포 전제 조건: Textual Label 및 CSS 스타일 처리를 사용할 수 있어야 한다.
|
||||
인터페이스: 대화 영역의 라벨, 스타일 식별자와 시각적 역할 구분에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: 사용자, 화면 검수자 및 렌더링 테스트. 마이그레이션: 필요 없음. 호환성: 기존 사용자와 에이전트 역할 구분 및 표시 순서를 유지한다. 배포 전제 조건: Textual Label과 CSS 스타일 처리를 사용할 수 있어야 한다.
|
||||
|
||||
### REQ-002.05 — 종료 단축키로 애플리케이션을 종료한다
|
||||
### REQ-002.05 — 종료 단축키로 애플리케이션 종료를 요청한다
|
||||
|
||||
사용자가 Escape 또는 Ctrl+Q를 누르면 시스템은 현재 TUI 애플리케이션의 종료 동작을 요청한다. 종료 요청은 해당 단축키 입력에 대해 수행되며, 종료 과정에서 대화 기능을 위해 기록된 상태를 임의로 변경하거나 외부 서비스를 호출하지 않는다.
|
||||
사용자가 Escape 또는 Ctrl+Q를 입력하면 시스템은 현재 Textual 애플리케이션의 종료 동작을 요청해야 한다. 두 단축키는 동일한 종료 경로를 사용해야 하며, 종료 입력은 메시지 제출이나 응답 선택으로 해석되어서는 안 된다. 종료 과정에서 외부 API, 네트워크 서비스, 데이터베이스 또는 영속 저장소를 호출하지 않아야 한다. 이 요구사항은 원본 Gitea 이슈 #8의 대화 상호작용 재작업 범위를 추적한다.
|
||||
|
||||
**영향 범위**
|
||||
|
||||
인터페이스: TUI 키 바인딩과 애플리케이션 종료 흐름에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: 사용자, 운영자 및 종료 회귀 테스트. 마이그레이션: 필요 없음. 호환성: Escape와 Ctrl+Q 종료 방식을 유지한다. 배포 전제 조건: Textual 애플리케이션의 종료 명령을 사용할 수 있어야 한다.
|
||||
인터페이스: TUI 키 바인딩과 애플리케이션 생명 주기에 영향을 준다. 영속성: 영향 없음. 후속 사용 주체: 사용자, 운영자 및 종료 회귀 테스트. 마이그레이션: 필요 없음. 호환성: Escape와 Ctrl+Q 종료 방식을 유지한다. 배포 전제 조건: REQ-001의 Textual 애플리케이션 실행 계약이 충족되어야 한다.
|
||||
|
||||
## 6. 제약과 불변조건
|
||||
|
||||
- 모든 입력은 제출 시점에 앞뒤 공백을 제거한 값으로 정규화한다.
|
||||
- 모든 입력은 제출 시점에 문자열 양끝의 공백을 제거한 값으로 정규화한다.
|
||||
- 정규화 결과가 빈 문자열이면 응답 선택, 메시지 목록 변경, 화면 항목 추가를 수행하지 않는다.
|
||||
- 유효한 입력은 세션 내 대화 상태에 사용자 메시지와 에이전트 응답을 순서대로 추가한다.
|
||||
- 에이전트 응답은 사전에 정의된 다섯 개의 고정 응답 중 표준 난수 선택으로 하나를 결정한다.
|
||||
@@ -143,10 +131,10 @@
|
||||
- 유효한 입력을 처리한 뒤 입력창은 항상 빈 값으로 초기화한다.
|
||||
- 빈 입력 또는 공백만 포함한 입력을 처리해도 기존 대화 상태와 응답 선택 상태는 변경되지 않아야 한다.
|
||||
- 대화 메시지는 현재 실행 세션에만 누적하며 외부 API, 데이터베이스 또는 영속 저장소를 사용하지 않는다.
|
||||
- 입력 제출 순서와 메시지 표시 순서를 보존해야 하며, 각 사용자 메시지 바로 뒤에 해당 응답을 배치한다.
|
||||
- 입력 제출 순서와 메시지 표시 순서를 보존하며, 각 사용자 메시지 바로 뒤에 해당 응답을 배치한다.
|
||||
- 종료 동작은 Escape와 Ctrl+Q 입력에 대해 애플리케이션 종료를 요청해야 하며, 종료 시 새로운 대화 메시지를 추가하지 않는다.
|
||||
- 프로젝트 실행 기반과 패키징 계약은 선행 요구사항의 범위를 유지하며, 이 문서에서는 이를 변경하지 않는다.
|
||||
- 구현은 승인된 분리 범위를 벗어나 새로운 외부 연동, 의존성, 배포 방식 또는 실행 환경을 도입하지 않는다.
|
||||
- 프로젝트 실행 기반과 패키징 계약은 선행 프로젝트 스캐폴드 요구사항의 범위를 유지하며, 이 문서에서는 변경하지 않는다.
|
||||
- 새로운 외부 연동, 의존성, 배포 방식 또는 실행 환경을 도입하지 않는다.
|
||||
|
||||
## 7. 인수 기준
|
||||
|
||||
@@ -163,15 +151,15 @@
|
||||
- 종료 단축키를 처리해도 대화 메시지나 입력 처리 상태가 새로 기록되어서는 안 된다.
|
||||
- 패키지 실행 진입점에서 대화 화면을 시작할 수 있어야 하며, 대화 기능 검증은 선행 프로젝트 스캐폴드 계약과 함께 수행할 수 있어야 한다.
|
||||
|
||||
### REQ-002.01-AC01 — 앞뒤 공백을 제거한 입력을 처리한다
|
||||
### REQ-002.01-AC01 — 양끝 공백을 제거하여 유효 입력을 처리한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
앞뒤 공백이 포함된 입력을 제출했을 때 대화 상태와 화면에는 공백이 제거된 본문만 사용자 메시지로 남으면 통과로 판정한다.
|
||||
양끝에 공백이 포함된 유효 입력을 제출했을 때 대화 상태와 화면에 공백이 제거된 본문만 사용자 메시지로 기록되면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입력 목록, 메시지 본문 및 표시 라벨을 확인한다.
|
||||
Textual 테스트에서 양끝 공백이 포함된 입력을 제출하고 제출된 입력, 메시지 본문 및 화면 표시값을 비교한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -179,17 +167,17 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
성공 시 정규화된 본문만 사용자 메시지로 기록되어야 한다. 원본의 앞뒤 공백은 표시되거나 후속 응답 선택의 입력으로 사용되지 않아야 한다.
|
||||
성공 시 정규화된 본문만 사용자 메시지로 기록되어야 하며 원본의 양끝 공백은 표시되거나 후속 처리에 사용되지 않아야 한다.
|
||||
|
||||
### REQ-002.01-AC02 — 빈 입력과 공백 입력을 무시한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
빈 문자열 또는 공백과 탭 및 줄바꿈만 포함한 값을 제출해도 응답 선택, 메시지 추가, 화면 항목 생성이 모두 발생하지 않으면 통과로 판정한다.
|
||||
빈 문자열 또는 공백, 탭, 줄바꿈만 포함한 값을 제출해도 응답 선택과 메시지 추가 및 새 화면 항목 생성이 발생하지 않으면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
빈 입력과 공백만 포함한 입력을 각각 제출하고 메시지 목록, 제출 입력 목록, 선택 응답 목록 및 대화 영역의 표시 항목 수를 확인한다.
|
||||
각 경계 입력을 제출하고 메시지 목록, 응답 선택 기록 및 대화 영역 항목 수를 확인하며 응답 선택 함수가 호출되지 않았는지 검증한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -197,35 +185,35 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
무효 입력 처리 후 대화 상태와 표시 영역은 변경되지 않아야 한다. 응답 선택 함수는 호출되지 않아야 하며 부분 메시지도 남지 않아야 한다.
|
||||
무효 입력 처리 후 기존 대화 상태와 화면은 변경되지 않아야 하며 부분 사용자 메시지나 응답이 남아서는 안 된다.
|
||||
|
||||
### REQ-002.02-AC01 — 사용자 메시지 뒤에 선택 응답을 표시한다
|
||||
### REQ-002.02-AC01 — 사용자 메시지 뒤에 고정 응답을 표시한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
유효 입력 하나를 제출했을 때 사용자 메시지와 선택된 응답이 같은 제출 순서로 연속 표시되고 작성자 라벨이 각각 사용자와 에이전트로 구분되면 통과로 판정한다.
|
||||
유효 입력 하나를 제출했을 때 정규화된 사용자 메시지와 고정 목록에서 선택된 응답이 인접한 순서로 표시되고 각각 사용자와 에이전트 역할로 구분되면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
응답 선택을 고정한 상태에서 입력을 제출하고 내부 메시지 목록과 대화 영역의 표시 순서를 비교한다.
|
||||
응답 선택 결과를 고정한 상태에서 입력을 제출하고 내부 메시지 목록과 대화 영역의 전체 순서를 확인한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
수준: integration; 백엔드: Textual 렌더링과 대화 모델; 케이스: positive
|
||||
수준: integration; 백엔드: Textual 렌더링과 대화 상태; 케이스: positive
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
성공 시 사용자 메시지가 응답보다 먼저 존재해야 한다. 두 메시지는 동일 제출에 속하지만 역할과 본문을 서로 바꾸거나 합쳐서는 안 된다.
|
||||
사용자 메시지는 응답보다 먼저 존재해야 하며 두 메시지의 역할과 본문은 서로 바뀌거나 합쳐지지 않아야 한다.
|
||||
|
||||
### REQ-002.02-AC02 — 응답을 고정 목록에서 표준 방식으로 선택한다
|
||||
### REQ-002.02-AC02 — 고정 목록에서 표준 방식으로 응답을 선택한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
유효 입력마다 고정된 응답 목록을 대상으로 표준 난수 선택이 한 번 수행되고 선택 결과가 상태와 화면에 동일하게 반영되면 통과로 판정한다.
|
||||
유효 입력마다 선언된 다섯 개 응답 목록 전체를 대상으로 표준 난수 선택이 한 번 수행되고 그 결과가 상태와 화면에 동일하게 반영되면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
난수 선택 함수를 감시하거나 고정된 결과를 반환하도록 설정한 뒤 유효 입력을 제출하고 호출 인자와 표시 결과를 확인한다.
|
||||
난수 선택 함수를 감시하거나 결과를 고정하여 유효 입력을 제출하고 호출 인자와 표시된 응답을 비교한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -233,17 +221,17 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
응답은 선언된 고정 목록 밖의 값이 될 수 없다. 무효 입력에서는 선택이 발생하지 않아야 하며 선택 결과와 표시 결과가 달라서는 안 된다.
|
||||
응답은 고정 목록 밖의 값이 될 수 없으며 무효 입력에서는 선택이 발생하지 않아야 한다.
|
||||
|
||||
### REQ-002.02-AC03 — 여러 제출을 기존 순서 뒤에 누적한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
두 번 이상의 유효 입력을 순서대로 제출했을 때 각 입력과 응답 쌍이 제출 순서와 동일하게 대화 상태 및 화면에 누적되면 통과로 판정한다.
|
||||
서로 다른 유효 입력을 두 번 이상 제출했을 때 각 입력과 응답 쌍이 제출 순서와 동일하게 상태와 화면에 누적되면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
서로 다른 두 입력을 제출하고 제출 입력 목록, 선택 응답 목록, 메시지 목록 및 렌더링된 라벨의 전체 순서를 확인한다.
|
||||
두 개 이상의 입력을 순서대로 제출하고 제출 입력, 선택 응답, 메시지 목록 및 렌더링 순서를 확인한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -251,7 +239,7 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
새 제출은 기존 메시지를 삭제하거나 재정렬하지 않아야 한다. 각 유효 입력은 사용자 메시지 하나와 응답 하나를 추가해야 하며 이전 상태는 보존되어야 한다.
|
||||
새 제출은 기존 메시지를 삭제하거나 재정렬하지 않아야 하며 각 유효 입력은 사용자 메시지 하나와 응답 하나를 추가해야 한다.
|
||||
|
||||
### REQ-002.03-AC01 — 유효 입력 제출 후 입력창을 비운다
|
||||
|
||||
@@ -261,7 +249,7 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**검증**
|
||||
|
||||
입력 위젯에 정규화 전 공백을 포함한 값을 설정하고 Enter를 누른 뒤 위젯 값을 확인한다.
|
||||
입력 위젯에 양끝 공백을 포함한 유효값을 설정하고 Enter를 누른 뒤 위젯 값과 대화 메시지를 확인한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -269,17 +257,17 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
입력창 초기화는 사용자 메시지와 응답의 기록을 삭제하거나 변경해서는 안 된다. 초기화 후 다음 제출을 위한 위젯이 재사용 가능해야 한다.
|
||||
입력창 초기화는 이미 기록된 사용자 메시지와 응답을 삭제하거나 변경해서는 안 된다.
|
||||
|
||||
### REQ-002.03-AC02 — 무효 입력 제출 후에도 입력창을 비운다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
빈 값 또는 공백만 있는 값을 제출한 뒤에도 입력 위젯의 값이 빈 문자열이면 통과로 판정한다.
|
||||
빈 값 또는 공백만 포함한 값을 제출한 뒤 입력 위젯의 값이 빈 문자열이고 대화 상태가 변경되지 않으면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
빈 입력과 공백 입력을 제출하고 각각 제출 후 입력 위젯 값을 확인한다.
|
||||
빈 입력과 공백 입력을 각각 제출하고 제출 후 입력 위젯 값, 메시지 목록 및 응답 선택 기록을 확인한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -287,35 +275,35 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
입력창은 비워져야 하지만 대화 상태, 선택 응답 및 표시 영역은 그대로 유지되어야 한다.
|
||||
입력창은 비워져야 하지만 기존 대화 상태, 응답 선택 상태와 표시 영역은 그대로 유지되어야 한다.
|
||||
|
||||
### REQ-002.04-AC01 — 역할에 따라 라벨과 스타일을 구분한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
사용자 메시지가 사용자 라벨과 사용자 메시지 스타일을 갖고 응답 메시지가 에이전트 라벨과 응답 메시지 스타일을 가지면 통과로 판정한다.
|
||||
사용자 메시지가 사용자 라벨과 사용자 스타일을 갖고 에이전트 응답이 에이전트 라벨과 에이전트 스타일을 가지면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
각 역할의 메시지를 대화 영역에 표시한 뒤 렌더링 텍스트와 스타일 클래스를 확인한다.
|
||||
각 역할의 메시지를 대화 영역에 표시한 뒤 렌더링 텍스트와 구조적 스타일 식별자를 확인하고 역할과의 대응을 비교한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
수준: unit; 백엔드: 메시지 모델과 Textual 렌더링; 케이스: positive
|
||||
수준: integration; 백엔드: 메시지 모델과 Textual 렌더링; 케이스: positive
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
메시지 역할과 표시 라벨이 서로 불일치해서는 안 된다. 역할에 따른 정렬과 경계 스타일은 반대 역할에 적용되지 않아야 한다.
|
||||
메시지 역할과 표시 라벨 및 스타일은 서로 불일치해서는 안 되며 한 역할의 스타일이 다른 역할에 적용되어서는 안 된다.
|
||||
|
||||
### REQ-002.05-AC01 — Escape 입력으로 종료를 요청한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
실행 중인 애플리케이션에서 Escape를 누르면 애플리케이션 종료 함수가 인자 없이 호출되면 통과로 판정한다.
|
||||
실행 중인 애플리케이션에서 Escape를 입력했을 때 애플리케이션 종료 동작이 정확히 한 번 요청되면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
테스트 실행 중 종료 함수를 감시하고 Escape 키를 입력한 뒤 정확히 한 번 호출되었는지 확인한다.
|
||||
종료 동작을 감시하는 Textual 테스트에서 Escape를 입력하고 종료 요청 횟수와 대화 상태 변경 여부를 확인한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -323,17 +311,17 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
종료 요청은 입력 제출이나 응답 선택으로 해석되어서는 안 된다. 종료 함수 호출 전후에 외부 연동이나 영속 상태 변경이 발생하지 않아야 한다.
|
||||
Escape 입력은 새 메시지나 응답을 생성하거나 입력 제출로 처리되어서는 안 된다.
|
||||
|
||||
### REQ-002.05-AC02 — Ctrl+Q 입력으로 종료를 요청한다
|
||||
### REQ-002.05-AC02 — Ctrl+Q 입력으로 동일한 종료를 요청한다
|
||||
|
||||
**판정 기준**
|
||||
|
||||
실행 중인 애플리케이션에서 Ctrl+Q를 누르면 Escape와 동일한 종료 동작이 수행되면 통과로 판정한다.
|
||||
실행 중인 애플리케이션에서 Ctrl+Q를 입력했을 때 Escape와 동일한 종료 동작이 정확히 한 번 요청되면 통과로 판정한다.
|
||||
|
||||
**검증**
|
||||
|
||||
종료 함수를 감시한 상태에서 Ctrl+Q를 입력하고 종료 요청이 정확히 한 번 발생하는지 확인한다.
|
||||
종료 동작을 감시한 상태에서 Ctrl+Q를 입력하고 Escape 테스트와 동일한 종료 경로, 호출 횟수 및 상태 불변조건을 확인한다.
|
||||
|
||||
**검증 분류**
|
||||
|
||||
@@ -341,11 +329,11 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
**상태 불변조건**
|
||||
|
||||
두 종료 단축키는 동일한 종료 경로를 사용해야 한다. 종료 입력은 새 메시지나 응답을 생성하거나 기존 대화 순서를 변경해서는 안 된다.
|
||||
Ctrl+Q는 Escape와 다른 메시지 처리 경로를 사용해서는 안 되며 종료 시 대화 순서와 기존 세션 상태를 변경해서는 안 된다.
|
||||
|
||||
## 8. 오류 및 충돌 계약
|
||||
|
||||
- 입력 제출 이벤트를 사용할 수 없는 초기화 실패나 위젯 조회 실패가 발생하면 정상적인 메시지 추가로 판정하지 않으며 부분적으로 생성된 대화 상태를 성공 상태로 남기지 않는다.
|
||||
- 입력 제출 이벤트를 사용할 수 없는 초기화 실패나 위젯 조회 실패가 발생하면 정상적인 메시지 추가로 판정하지 않으며, 부분적으로 생성된 대화 상태를 성공 상태로 남기지 않는다.
|
||||
- 입력값이 빈 문자열 또는 공백만 포함한 값이면 오류가 아니라 무시 가능한 입력으로 처리하고, 응답 선택과 메시지 추가를 수행하지 않는다.
|
||||
- 응답 선택에 실패하면 해당 입력에 대한 사용자 메시지와 에이전트 응답을 부분적으로 기록하지 않아야 한다.
|
||||
- 고정 응답 목록이 비어 있거나 정의된 계약과 다르면 응답을 생성하지 않고 처리 실패로 식별해야 한다.
|
||||
@@ -387,7 +375,11 @@ TUI 테스트에서 앞뒤에 공백이 있는 입력을 제출하고 제출 입
|
||||
|
||||
## 11. 검증 계획
|
||||
|
||||
Python 3.11 이상 환경에서 애플리케이션을 실행하고 대화 입력과 종료 동작을 검증한다. 정상 입력에서는 앞뒤 공백이 제거된 사용자 메시지와 고정 응답이 입력 순서대로 대화 영역에 표시되는지 확인한다. 여러 입력을 연속 제출하여 세션 내 메시지와 내부 누적 상태가 사용자 메시지와 응답의 쌍으로 유지되는지 확인한다. 공백 또는 빈 입력에서는 응답 선택, 메시지 누적, 화면 항목 추가가 발생하지 않고 입력창만 초기화되는지 확인한다. 응답 선택은 사전에 정의된 다섯 개 문구에서 표준 난수 선택으로 수행되는지 확인하며, 선택된 응답이 에이전트 역할과 구분되어 표시되는지 검증한다. 입력창 초기화는 유효 입력과 무효 입력 모두에서 제출 직후 수행되는지 확인한다. Escape와 Ctrl+Q 입력은 애플리케이션 종료를 요청하고 종료 전에 추가 메시지나 응답을 생성하지 않는지 확인한다. 기존 패키지 설치와 두 실행 진입점의 검증을 통과한 뒤 대화 기능 회귀 검증을 수행하며, 외부 API나 영속 저장소 없이 저장소의 자동화 테스트로 결과를 판정한다.
|
||||
Python 3.11 이상 환경에서 애플리케이션을 실행하여 대화 입력과 종료 동작을 검증한다. 정상 입력에서는 앞뒤 공백이 제거된 사용자 메시지와 고정 응답이 제출 순서대로 대화 영역에 표시되는지 확인한다. 여러 입력을 연속 제출하여 세션 내 메시지가 사용자 메시지와 응답의 인접한 쌍으로 누적되는지 확인한다. 빈 입력이나 공백만 포함한 입력에서는 응답 선택, 메시지 누적 및 화면 항목 추가가 발생하지 않고 입력창만 초기화되는지 확인한다. 응답 선택이 정본으로 정의된 다섯 개 문구 중 하나를 표준 난수 방식으로 결정하는지와 선택 결과가 에이전트 메시지로 표시되는지 확인한다. 사용자와 에이전트 메시지의 라벨과 구조적 스타일이 역할에 맞는지 검증한다. Escape와 Ctrl+Q 입력은 애플리케이션 종료를 요청하고 종료 전에 새 메시지나 응답을 생성하지 않는지 확인한다. 프로젝트 설치 및 두 실행 진입점의 검증을 선행한 뒤 대화 기능 회귀 검증을 수행하며, 외부 API나 영속 저장소 없이 저장소의 자동화 테스트로 결과를 판정한다.
|
||||
|
||||
테스트 추적성 계약:
|
||||
|
||||
테스트 정의와 실행 증거는 별도 테스트 카탈로그 및 증거 산출물에서 관리한다. 대화 입력 정규화, 빈 입력 무시, 메시지와 응답의 순서 및 누적, 고정 응답 선택, 입력창 초기화, 역할별 표시와 종료 단축키에 대한 각 인수 기준의 검증 연결을 빠짐없이 기록한다. 실행 증거에는 요구사항 개정, 검증한 커밋, 실행 환경, 실행 시각과 결과를 포함하며, 실행하지 않은 검증은 성공으로 간주하지 않는다.
|
||||
|
||||
### 테스트 추적성 계약
|
||||
|
||||
@@ -407,7 +399,7 @@ Verifies:
|
||||
- REQ-002.05-AC01
|
||||
- REQ-002.05-AC02
|
||||
Test reference: tests/test_app.py 및 python -m unittest discover -s tests -v
|
||||
Automated: 저장소의 기존 unittest 기반 Textual 애플리케이션 테스트를 사용하여 입력, 응답, 빈 입력, 스타일과 종료 동작을 자동 검증한다.
|
||||
Automated: 저장소의 기존 unittest 기반 Textual 애플리케이션 테스트로 입력, 응답, 빈 입력, 역할별 표시, 입력창 초기화 및 종료 동작을 자동 검증한다.
|
||||
```
|
||||
|
||||
실행 증거:
|
||||
@@ -416,18 +408,18 @@ Automated: 저장소의 기존 unittest 기반 Textual 애플리케이션 테스
|
||||
Test ID: TC-002-001
|
||||
Requirement revision: REQ-002@0.1
|
||||
Commit: d0ac7fc7bcfaf402bbda24776f051fa9992993e1
|
||||
Environment: Python 3.11 이상, 선언된 Textual 런타임 의존성이 설치된 환경
|
||||
Environment: Python 3.11 이상 및 선언된 Textual 런타임 의존성이 설치된 환경
|
||||
Result: 미실행
|
||||
Executed at: 문서 작성 시점에는 실행 증거를 기록하지 않음
|
||||
```
|
||||
|
||||
## 12. 추적성
|
||||
|
||||
근거는 원본 이슈의 요구사항 재작업 요청, 기존 프로젝트 스캐폴드 요구사항 문서, README의 사용자 동작 설명, 애플리케이션 구현과 대화 동작 테스트다. 이 문서는 프로젝트 스캐폴드와 패키징 및 실행 진입점을 선행 조건으로 사용하며, 그 선행 요구사항의 의미나 실행 계약을 변경하지 않는다. 사용자 입력 정규화, 세션 내 메시지 누적, 고정 응답 선택과 표시, 빈 입력 무시, 입력창 초기화 및 종료 동작은 이 문서에서 추적한다. 패키징 메타데이터와 실행 진입점은 선행 문서에서 추적하고 이 문서에서는 중복 정의하지 않는다. 구현 파일의 입력 제출 처리, 응답 목록, 역할별 표시 구조와 종료 바인딩 및 관련 테스트가 각 동작의 근거와 검증 지점이다.
|
||||
근거는 원본 Gitea 이슈 #8인 「요구사항명세서의 재작업」, 기존 프로젝트 스캐폴드 요구사항 문서, 저장소 README의 사용자 동작 설명, 애플리케이션 구현과 대화 동작 테스트다. 이 문서는 원본 이슈 #8에서 요구한 대화 기능 분리의 결과로 작성되며, 프로젝트 스캐폴드와 패키징 및 실행 진입점을 선행 조건으로 사용하되 그 의미와 실행 계약을 변경하지 않는다. 사용자 입력 정규화, 세션 내 메시지 누적, 고정 응답 선택과 표시, 빈 입력 무시, 입력창 초기화 및 종료 동작은 이 문서에서만 추적한다. 패키징 메타데이터와 실행 진입점은 선행 프로젝트 스캐폴드 문서에서 추적하며 이 문서에서는 상세 규칙과 수용 기준을 중복 정의하지 않는다. 구현 파일의 입력 제출 처리, 고정 응답 목록, 역할별 표시 구조, 종료 바인딩과 관련 테스트는 각 동작의 근거 및 검증 지점이다.
|
||||
|
||||
## 13. 확정된 결정
|
||||
|
||||
기존 구현과 테스트가 정의한 대화 동작을 별도 요구사항으로 분리하여 기록한다. 입력은 제출 시 앞뒤 공백을 제거하고, 정규화 결과가 비어 있으면 아무 대화 항목도 추가하지 않는다. 유효한 입력마다 사용자 메시지를 먼저 누적하고 사전 정의된 다섯 개 응답 중 하나를 표준 난수 방식으로 선택하여 에이전트 메시지로 바로 뒤에 누적한다. 사용자와 에이전트 메시지는 역할 라벨과 구조적 스타일로 구분한다. 유효 입력과 무효 입력 모두 제출 후 입력창을 비우며, Escape와 Ctrl+Q는 애플리케이션 종료 동작을 요청한다. 외부 API, LLM, 데이터베이스, 영속 저장소, 새 의존성 및 사용자 동작 변경은 도입하지 않는다.
|
||||
원본 이슈 #8의 분리 범위에 따라 기존 구현과 테스트가 정의한 대화 동작을 독립된 요구사항 문서로 기록한다. 입력은 제출 시 앞뒤 공백을 제거하고, 정규화 결과가 비어 있으면 대화 항목을 추가하지 않는다. 유효한 입력마다 사용자 메시지를 먼저 누적하고 정본으로 정의된 다섯 개 응답 중 하나를 표준 난수 방식으로 선택하여 에이전트 메시지로 바로 뒤에 누적한다. 사용자와 에이전트 메시지는 역할 라벨과 구조적 스타일로 구분한다. 유효 입력과 무효 입력 모두 제출 후 입력창을 비우며, Escape와 Ctrl+Q는 애플리케이션 종료 동작을 요청한다. 프로젝트 스캐폴드의 승인 상태와 기존 승인 이력은 선행 문서에서 보존하며, 이 문서는 대화 동작의 의미와 검증 기준만 관리한다. 외부 API, LLM, 데이터베이스, 영속 저장소, 새 의존성 및 사용자 동작 변경은 도입하지 않는다.
|
||||
|
||||
## 14. 미결 사항
|
||||
|
||||
@@ -435,4 +427,4 @@ Executed at: 문서 작성 시점에는 실행 증거를 기록하지 않음
|
||||
|
||||
## 15. 승인 기록
|
||||
|
||||
상태는 초안이다. 승인 주체는 아직 지정되지 않았으며, 승인 근거도 기록되지 않았다. 디스커버리 승인에 따라 구현 대상으로 인계되었으나, 이 요구사항 문서의 최종 승인은 별도 절차에서 수행해야 한다.
|
||||
상태는 초안이다. 승인 주체는 아직 지정되지 않았으며 승인 근거도 기록되지 않았다. 원본 Gitea 이슈 #8의 디스커버리 결과에 따라 구현 대상으로 인계되었으나, 이 요구사항 문서의 최종 승인은 별도 절차에서 수행해야 한다.
|
||||
|
||||
Reference in New Issue
Block a user