sdlc 정리
This commit is contained in:
@@ -1,314 +0,0 @@
|
|||||||
# REQ-003: 포트폴리오 필수 필드 및 거래소/시장 데이터 정의
|
|
||||||
|
|
||||||
- Status: Proposed
|
|
||||||
- Type: Data
|
|
||||||
- Priority: Medium
|
|
||||||
- Owner: Justin
|
|
||||||
|
|
||||||
## Intent
|
|
||||||
- `portfolio` 데이터가 운용 및 검색 맥락에서 일관되게 해석될 수 있도록 필수 필드와 저장 규칙을 명확히 정의한다.
|
|
||||||
- 종목 이름, 심볼, 거래소, 시장 정보를 표준화된 스키마로 관리하여 API, CLI, DB 간 데이터 계약 불일치를 줄인다.
|
|
||||||
- 태그 기반으로 포트폴리오 목록을 소비하는 외부 서비스가 필요로 하는 원천 데이터 필드 계약을 정확히 정의한다.
|
|
||||||
|
|
||||||
## Requirement
|
|
||||||
- 시스템은 신규로 생성되거나 수정되는 각 `portfolio` 레코드에 대해 `name`, `symbol`, `exchange`, `market` 필드를 데이터 계약상 포함해야 한다.
|
|
||||||
- 시스템은 `name`과 `symbol`을 각 포트폴리오의 식별 및 표시를 위한 기본 필드로 유지해야 한다.
|
|
||||||
- 시스템은 `exchange` 필드에서 하나 이상의 거래소 문자열을 표현할 수 있어야 하며, 단일 포트폴리오에 복수 거래소가 연결될 수 있어야 한다.
|
|
||||||
- 시스템은 `exchange` 값을 특정 enum으로 제한하지 않아야 하며, 공백이 아닌 임의 문자열 값을 저장할 수 있어야 한다.
|
|
||||||
- 시스템은 `market` 값을 특정 enum으로 제한하지 않아야 하며, 공백이 아닌 임의 문자열 값을 저장할 수 있어야 한다.
|
|
||||||
- 시스템은 복수 거래소 지원을 위해 `exchange`를 복수 문자열을 표현할 수 있는 데이터 구조로 저장해야 한다.
|
|
||||||
- 시스템은 기존 `portfolio` 레코드에 `exchange` 또는 `market` 값이 누락되어 있더라도 마이그레이션 과정에서 `NULL` 또는 빈 문자열(`""`)로 보정할 수 있어야 한다.
|
|
||||||
- 시스템은 필수 필드 계약이 추가된 이후에도 기존 레코드 조회가 실패하지 않도록 하위 호환성을 유지해야 한다.
|
|
||||||
- 시스템은 태그 기반 포트폴리오 목록 조회 응답에서 각 항목의 최소 필드(`symbol`, `name`, `exchange`, `market`, `updated_at`)를 제공해야 한다.
|
|
||||||
- 시스템은 태그 필터 파라미터를 사용한 목록 조회에서 태그 등록/검색 규칙을 REQ-002 계약에 따라 처리해야 한다.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
1. Given 새 포트폴리오 레코드가 생성되거나 기존 포트폴리오가 수정될 때, When 시스템이 데이터를 저장하면, Then 해당 레코드는 `name`, `symbol`, `exchange`, `market` 필드를 포함하는 구조로 저장되거나 반환되어야 한다.
|
|
||||||
2. Given 하나의 포트폴리오가 `KRX`, `NXT`, `SOR`와 같은 여러 거래소 문자열을 가질 때, When 시스템이 해당 포트폴리오를 저장하거나 조회하면, Then `exchange` 필드는 복수 문자열을 보존할 수 있어야 한다.
|
|
||||||
3. Given 사용자가 enum에 없는 새로운 거래소 문자열 또는 시장 문자열을 제공할 때, When 시스템이 이를 저장하면, Then 시스템은 값 목록 제한만을 이유로 해당 값을 거부하지 않아야 한다.
|
|
||||||
4. Given 기존 포트폴리오 레코드에 `exchange` 또는 `market` 값이 없는 상태에서 스키마가 적용될 때, When 마이그레이션 또는 후속 조회가 수행되면, Then 시스템은 누락 값을 `NULL` 또는 빈 문자열(`""`)로 처리하고 레코드 조회를 실패시키지 않아야 한다.
|
|
||||||
5. Given 기존 포트폴리오 레코드가 이미 `name`과 `symbol`을 포함하고 있을 때, When 새 필드 계약이 적용된 후 데이터를 조회하면, Then 기존 `name`과 `symbol` 값은 변경되지 않고 그대로 반환되어야 한다.
|
|
||||||
6. Given 소비 서비스가 태그 기반 목록 조회를 수행하는 상태, When 응답 항목을 확인하면, Then 각 항목에는 최소 `symbol`, `name`, `exchange`, `market`, `updated_at` 필드가 포함되어야 한다.
|
|
||||||
7. Given 소비 서비스가 태그 필터를 포함해 목록 조회를 요청한 상태, When 조회를 수행하면, Then 태그 필터 적용 규칙은 REQ-002에서 정의한 include/exclude 및 매칭 규칙을 따라야 한다.
|
|
||||||
|
|
||||||
## Impacted Area
|
|
||||||
- Docs: `docs/technical/architecture-overview.md`, `docs/technical/api-contracts.md`, `docs/technical/persistence-and-migrations.md`, `docs/SRS/index.md`, `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules: `app/domain/models.py`, `app/schemas/portfolio.py`, `app/repositories/portfolio_repository.py`, `app/repositories/postgres.py`, `app/services/portfolio_service.py`, `migrations/versions/*`
|
|
||||||
- Tests: `tests/test_app.py`, `tests/test_domain_services.py`
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
- Assumption: 복수 거래소 지원은 별도 정규화 테이블보다 `exchange` 배열 컬럼이 현재 범위에 더 단순하고 적합한 권장 방식이다.
|
|
||||||
- 신규 생성/수정 계약에서는 `name`, `symbol`, `exchange`, `market` 필드를 모두 포함하되, 기존 데이터 호환성을 위해 레거시 레코드의 누락 신규 필드는 `NULL` 또는 `""`로 허용한다.
|
|
||||||
- `exchange`와 `market`은 허용값 enum을 두지 않고 자유 문자열로 저장한다.
|
|
||||||
- Note: 본 requirement는 portfolio-hub의 원천 데이터 제공 계약만 다루며, 조회 결과를 스냅샷화하거나 캐시/복구하는 책임은 소비 서비스에 있다.
|
|
||||||
- Note: 조회 결과의 결정성(동일 tag 필터 입력에 대한 동일 응답 항목 집합 및 정렬 순서) 유지는 소비 서비스(예: stock-picker)의 책임이다. portfolio-hub는 tag 필터를 적용하여 목록을 반환하기만 한다.
|
|
||||||
- Note: 태그 등록과 태그 필터 세부 규칙은 REQ-002를 단일 source of truth로 사용한다.
|
|
||||||
|
|
||||||
## Change Log
|
|
||||||
|
|
||||||
### CHG-20260413-08
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 삭제 예정인 상위 docs 경로를 technical 문서 경로로 정리했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 데이터 계약 requirement가 삭제 후에도 유효한 구현 추적 문서를 가리키도록 유지하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Impacted Area의 docs 경로를 `docs/technical/` 기준으로 갱신
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Data/REQ-003_portfolio-required-fields.md`
|
|
||||||
- `docs/technical/architecture-overview.md`
|
|
||||||
- `docs/technical/api-contracts.md`
|
|
||||||
- `docs/technical/persistence-and-migrations.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 삭제 대상 문서 제거 후에도 REQ-003의 docs 추적 링크가 모두 유효한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260413-07
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-003에서 tag 필터 기반 조회의 결정성(동일 항목 집합/정렬) 유지 책임을 portfolio-hub에서 제거하고 stock-picker(소비 서비스)로 이관했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- portfolio-hub의 책임을 "tag 필터 적용 후 목록 반환"으로 최소화하고, 조회 결과의 캐시/복구/결정성 추적은 소비 서비스가 담당하도록 명확히 하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Requirement에서 "동일 tag 필터 조건에서 항목 집합과 정렬 기준을 결정적으로 유지" 요구사항 제거
|
|
||||||
- Notes에 결정성 책임이 소비 서비스에 있음을 명시
|
|
||||||
- Removed:
|
|
||||||
- Acceptance Criteria #7 (결정성 검증 기준)
|
|
||||||
- Requirement의 결정성 유지 조항
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Data/REQ-003_portfolio-required-fields.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- REQ-003의 tag 필터 기반 목록 조회 응답이 필수 필드와 REQ-002 필터 규칙을 만족하는지로 검증한다.
|
|
||||||
- 결정성 검증(동일 tag 필터 입력에 대한 동일 응답)은 stock-picker 테스트에서 담당한다.
|
|
||||||
|
|
||||||
### CHG-20260413-06
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-003에서 `sourceVersion`/`sourceTimestamp` 메타데이터 요구를 제거하고 태그 필터 기반 조회 결정성 계약만 유지했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- portfolio-hub가 특정 소비자 전용 메타데이터를 제공하지 않고도 공용 태그 기반 목록 조회 계약을 만족하도록 경계를 명확히 하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Requirement의 조회 결정성 기준을 태그 필터 조건 기준으로 정리
|
|
||||||
- Acceptance Criteria에서 source metadata 검증 항목 제거 및 결정성 검증 항목 재정의
|
|
||||||
- Removed:
|
|
||||||
- `sourceVersion`/`sourceTimestamp` 제공 검증 기준
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Data/REQ-003_portfolio-required-fields.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 동일 태그 필터 조건으로 반복 조회 시 항목 집합/정렬이 동일한지로 계약 충족 여부를 검증한다.
|
|
||||||
|
|
||||||
### CHG-20260413-05
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-003의 stock-picker 전용 표현을 소비 서비스 중립 표현으로 정리했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- portfolio-hub가 특정 소비자 구현을 인지하지 않아도 되는 일반 태그 기반 목록 조회 계약으로 요구사항 경계를 명확히 하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Intent/Requirement/Acceptance Criteria의 소비자 표현을 일반화
|
|
||||||
- Notes의 책임 주체를 특정 서비스명 대신 소비 서비스로 일반화
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Data/REQ-003_portfolio-required-fields.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- REQ-003 본문에서 특정 소비자 고정 표현 없이 태그 기반 조회 계약이 동일하게 해석되는지 문서 리뷰로 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260413-04
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-003에 stock-picker 태그 필터 조회 시 REQ-002 계약을 따른다는 교차 참조를 추가했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 원천 데이터 필드 계약과 태그 필터 계약의 문서 경계를 명확히 분리하고 추적성을 강화하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 태그 필터 조회가 REQ-002 규칙을 따르는지 검증하는 기준
|
|
||||||
- Updated:
|
|
||||||
- Requirement에 REQ-002 교차 참조 조항 추가
|
|
||||||
- Notes에 태그 계약 source of truth 명시
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Data/REQ-003_portfolio-required-fields.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 태그 필터 조회 계약 연계 테스트 항목 추가
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- REQ-003과 REQ-002 간 참조가 충돌 없이 추적 가능한지 문서 리뷰로 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260413-03
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- stock-picker 기본 유니버스 소비를 위한 원천 데이터 필드/버전 메타데이터/조회 정합성 최소 계약을 REQ-003에 추가했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- portfolio-hub 책임을 원천 데이터 계약으로 한정하면서 소비자(stock-picker)의 입력 고정 요구를 지원한다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 원천 데이터 조회 필수 필드 검증 기준
|
|
||||||
- sourceVersion/sourceTimestamp 메타데이터 검증 기준
|
|
||||||
- 동일 sourceVersion 조회 정합성 검증 기준
|
|
||||||
- Updated:
|
|
||||||
- Requirement에 stock-picker 원천 데이터 제공 계약 조항 추가
|
|
||||||
- Notes에 책임 분리 문구 추가
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- REQ-003 원천 데이터 계약 보강
|
|
||||||
- Modules:
|
|
||||||
- portfolio list response serializer 및 metadata 노출 경로 영향 식별
|
|
||||||
- Tests:
|
|
||||||
- source metadata 및 deterministic ordering 검증 테스트 항목 추가
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 동일 sourceVersion 기준 조회 2회 결과의 항목 집합/정렬 일치 여부를 검증한다.
|
|
||||||
- 원천 데이터 조회 응답에 필수 필드와 source metadata가 존재하는지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-02
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- `REQ-003`에 신규 입력 계약과 레거시 호환성 규칙을 분리해 명확화하고, impacted path 표기를 정리했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- requirement 검토 피드백을 반영해 필수 필드 의미와 하위 호환성 범위를 test 가능하게 구분하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 신규 생성/수정 시 필드 포함 요구를 명확히 한 저장 기준
|
|
||||||
- Updated:
|
|
||||||
- `exchange` 저장 표현을 복수 문자열 데이터 구조 기준으로 일반화
|
|
||||||
- `Impacted Area` 경로를 repository-relative path로 정리
|
|
||||||
- 레거시 레코드의 `NULL`/`""` 허용 범위를 하위 호환성 규칙으로 명시
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Data/REQ-003_portfolio-required-fields.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 추후 schema compatibility 및 migration regression 테스트 추가 필요
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 문서 리뷰 시 신규 생성/수정 계약과 레거시 호환성 계약이 각각 독립 acceptance criterion으로 추적 가능한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-01
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 포트폴리오 필수 필드와 복수 거래소/시장 데이터 계약에 대한 신규 SRS requirement 초안을 작성했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- `portfolio` 데이터 구조에 대한 필수 필드와 하위 호환성 기준을 명확히 정의하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- `name`, `symbol`, `exchange`, `market` 필드 정의 요구
|
|
||||||
- 복수 거래소 저장 요구
|
|
||||||
- 자유 문자열 허용 요구
|
|
||||||
- 기존 레코드의 `NULL`/`""` 보정 및 조회 호환성 요구
|
|
||||||
- Updated:
|
|
||||||
- 없음
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- docs/technical/architecture-overview.md
|
|
||||||
- docs/technical/api-contracts.md
|
|
||||||
- docs/technical/persistence-and-migrations.md
|
|
||||||
- index.md
|
|
||||||
- traceability-matrix.md
|
|
||||||
- Modules:
|
|
||||||
- models.py
|
|
||||||
- portfolio.py
|
|
||||||
- portfolio_repository.py
|
|
||||||
- postgres.py
|
|
||||||
- portfolio_service.py
|
|
||||||
- `migrations/versions/*`
|
|
||||||
- Tests:
|
|
||||||
- test_app.py
|
|
||||||
- test_domain_services.py
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 스키마 리뷰 시 `exchange` 복수 값 저장 방식과 `market` 자유 문자열 저장 규칙이 문서와 구현 테스트에 직접 매핑되는지 확인한다.
|
|
||||||
- 마이그레이션 검토 시 기존 레코드의 누락 필드가 `NULL` 또는 `""` 처리로 조회 호환성을 유지하는지 확인한다.
|
|
||||||
@@ -1,179 +0,0 @@
|
|||||||
# REQ-001: 포트폴리오 댓글형 메모 이력 지원
|
|
||||||
|
|
||||||
- Status: Approved
|
|
||||||
- Type: Interface
|
|
||||||
- Priority: Medium
|
|
||||||
- Owner: Justin
|
|
||||||
|
|
||||||
## Intent
|
|
||||||
- 사용자가 각 `portfolio`에 대해 사람이 읽고 쓰는 메모를 이력 형태로 남기고 열람할 수 있도록 한다.
|
|
||||||
- 단일 `note` 필드가 아니라 여러 건의 댓글형 기록을 지원하여 운용 맥락과 판단 근거를 보존한다.
|
|
||||||
|
|
||||||
## Requirement
|
|
||||||
- 시스템은 각 포트폴리오에 대해 댓글형 메모 이력을 저장·조회·수정·삭제할 수 있어야 한다.
|
|
||||||
- 시스템은 포트폴리오 메모 이력을 메인 포트폴리오 레코드와 분리된 **별도 테이블**에 저장해야 한다.
|
|
||||||
- 시스템은 HTTP API와 CLI를 통해 동일한 포트폴리오 메모 이력 기능을 제공해야 한다.
|
|
||||||
- 각 메모 이력 항목은 최소한 고유 식별자, 연결된 `portfolio_id`, 본문 내용, 생성 시각, 수정 시각을 포함해야 한다.
|
|
||||||
- 시스템은 특정 포트폴리오의 메모 이력을 다른 포트폴리오와 구분하여 조회해야 하며, 조회 결과는 최신 생성 시각 기준 내림차순으로 반환되어야 한다.
|
|
||||||
- 시스템은 메모 생성·수정·삭제 요청에 대해 기존 포트폴리오 접근 권한 정책을 적용해야 하며, 인증 실패 또는 권한 부족 시 기존 인증 오류 계약에 따라 요청을 거부해야 한다.
|
|
||||||
- 시스템은 사용자가 입력한 메모 본문에 대해 애플리케이션 정의 최대 길이 제한으로 입력을 차단하지 않아야 하며, 일반적인 다중 라인 텍스트를 저장·조회할 수 있어야 한다.
|
|
||||||
- 시스템은 존재하지 않는 `portfolio_id` 또는 `comment_id`를 대상으로 한 요청에 대해 Not Found 오류를 반환해야 한다.
|
|
||||||
- 시스템은 메모 삭제 후 해당 항목이 후속 조회 결과에 더 이상 노출되지 않도록 해야 한다.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
1. Given 기존 포트폴리오가 존재하고 권한이 있는 사용자가 API 또는 CLI로 메모를 생성할 때, When 메모 본문을 제출하면, Then 시스템은 별도 포트폴리오 메모 테이블에 새 항목을 저장하고 생성된 메모의 식별자와 타임스탬프를 포함한 결과를 반환해야 한다.
|
|
||||||
2. Given 특정 포트폴리오에 메모가 2건 이상 존재할 때, When 사용자가 API 또는 CLI로 메모 이력을 조회하면, Then 시스템은 해당 포트폴리오에 속한 메모만 반환해야 하며 각 항목의 `id`, `content`, `created_at`, `updated_at`를 포함하고 최신 생성 시각 기준으로 정렬되어야 한다.
|
|
||||||
3. Given 기존 메모 항목이 존재할 때, When 사용자가 API 또는 CLI로 메모 본문을 수정하면, Then 시스템은 동일한 메모 식별자를 유지한 채 본문과 `updated_at`를 갱신하고 후속 조회에서 수정된 내용을 반환해야 한다.
|
|
||||||
4. Given 기존 메모 항목이 존재할 때, When 사용자가 API 또는 CLI로 해당 메모를 삭제하면, Then 시스템은 성공 응답을 반환하고 이후 동일 포트폴리오 메모 이력 조회 결과에서 해당 항목을 노출하지 않아야 한다.
|
|
||||||
5. Given 사용자가 장문의 다중 라인 텍스트 메모를 입력할 때, When API 또는 CLI를 통해 생성 또는 수정을 요청하면, Then 시스템은 애플리케이션 정의 최대 길이 제한 오류 없이 해당 내용을 저장하고 조회 시 동일 텍스트를 반환해야 한다.
|
|
||||||
6. Given 인증되지 않았거나 해당 포트폴리오 메모에 접근 권한이 없는 사용자가 API 또는 CLI로 조회·생성·수정·삭제를 시도할 때, When 요청을 전송하면, Then 시스템은 기존 인증/인가 계약에 따라 `401` 또는 `403` 응답을 반환하고 메모 데이터를 변경하지 않아야 한다.
|
|
||||||
7. Given 존재하지 않는 `portfolio_id` 또는 `comment_id`가 요청에 포함될 때, When 사용자가 API 또는 CLI로 조회·수정·삭제를 시도하면, Then 시스템은 `404` 응답 또는 이에 대응하는 CLI 오류를 반환하고 새로운 메모를 생성하거나 기존 데이터를 변경하지 않아야 한다.
|
|
||||||
|
|
||||||
## Impacted Area
|
|
||||||
- Docs: `docs/technical/api-contracts.md`, `docs/technical/persistence-and-migrations.md`, `docs/SRS/index.md`
|
|
||||||
- Modules: `app/api/portfolios.py`, `app/cli/commands/portfolio.py`, `app/schemas/portfolio.py`, `app/services/portfolio_service.py`, `app/repositories/portfolio_repository.py`, `app/repositories/postgres.py`, `migrations/versions/*`
|
|
||||||
- Tests: `tests/test_app.py`, `tests/test_cli.py`, `tests/test_domain_services.py`
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
- 본 초안은 메모가 **사용자가 기록하고 열람하는 용도**임을 전제로 한다.
|
|
||||||
- 조회/생성/수정/삭제 권한은 기존 포트폴리오 접근 권한 정책을 재사용한다.
|
|
||||||
- 삭제의 내부 구현은 hard delete 또는 soft delete 중 선택 가능하되, 외부 계약상 삭제된 메모는 후속 조회에 노출되지 않아야 한다.
|
|
||||||
|
|
||||||
## Change Log
|
|
||||||
|
|
||||||
### CHG-20260413-04
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 삭제 예정인 상위 docs 경로를 technical 문서 경로로 정리했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 구현 추적 문서가 삭제 후에도 유효한 참조를 유지하도록 하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Impacted Area의 docs 경로를 `docs/technical/` 기준으로 갱신
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-001_portfolio-comment-history.md`
|
|
||||||
- `docs/technical/api-contracts.md`
|
|
||||||
- `docs/technical/persistence-and-migrations.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 삭제 대상 문서 제거 후에도 REQ-001의 구현 추적 문서 링크가 모두 유효한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-03
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- Owner 지정과 문서 리뷰 완료를 근거로 `REQ-001` 상태를 `Approved`로 전환했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 구현 착수 전 기준 requirement로 승인 상태를 명확히 하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- 없음
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-001_portfolio-comment-history.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- SRS index와 traceability matrix에서 `REQ-001` 상태가 `Approved`로 일치하는지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-02
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- requirement 품질 검토 결과를 반영해 권한, 오류 응답, 정렬 규칙, 경로 표기를 구체화했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- acceptance criteria를 더 test 가능하게 만들고 모호한 표현을 줄이기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 인증/인가 실패 시 거부 동작
|
|
||||||
- 존재하지 않는 포트폴리오/메모에 대한 오류 응답
|
|
||||||
- 조회 정렬 규칙
|
|
||||||
- Updated:
|
|
||||||
- 메모 길이 제한 표현을 애플리케이션 정의 제한 기준으로 명확화
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-001_portfolio-comment-history.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 추후 API/CLI 권한 및 오류 케이스 테스트 추가 필요
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- REQ 문서 리뷰 시 각 acceptance criterion이 단일 테스트 케이스로 변환 가능한지 확인한다.
|
|
||||||
- 권한/오류/정렬 규칙이 구현 테스트 항목으로 직접 추적 가능한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-01
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 포트폴리오별 댓글형 메모 이력 기능에 대한 신규 SRS requirement 초안을 작성했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 사용자 관찰 가능한 API/CLI 계약과 데이터 저장 요구를 명확히 정의하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- API/CLI를 통한 메모 생성, 조회, 수정, 삭제 요구
|
|
||||||
- 별도 테이블 저장 요구
|
|
||||||
- 애플리케이션 레벨 길이 제한 없음 요구
|
|
||||||
- Updated:
|
|
||||||
- 없음
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- docs/technical/api-contracts.md
|
|
||||||
- docs/technical/persistence-and-migrations.md
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- portfolios.py
|
|
||||||
- portfolio.py
|
|
||||||
- portfolio.py
|
|
||||||
- portfolio_service.py
|
|
||||||
- portfolio_repository.py
|
|
||||||
- postgres.py
|
|
||||||
- `migrations/versions/*`
|
|
||||||
- Tests:
|
|
||||||
- test_app.py
|
|
||||||
- test_cli.py
|
|
||||||
- test_domain_services.py
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- API 테스트로 메모 CRUD 및 포트폴리오별 조회 격리를 검증한다.
|
|
||||||
- CLI 테스트로 동일 기능의 입력/출력 계약을 검증한다.
|
|
||||||
- DB 마이그레이션 및 저장소 테스트로 별도 테이블 저장과 조회 일관성을 검증한다.
|
|
||||||
@@ -1,287 +0,0 @@
|
|||||||
# REQ-002: 포트폴리오 태깅 및 태그 기반 검색 지원
|
|
||||||
|
|
||||||
- Status: Approved
|
|
||||||
- Type: Interface
|
|
||||||
- Priority: Medium
|
|
||||||
- Owner: Justin
|
|
||||||
|
|
||||||
## Intent
|
|
||||||
- 사용자가 각 `portfolio`에 의미 있는 태그를 부여하고, 특정 태그가 포함된 포트폴리오를 빠르게 검색할 수 있도록 한다.
|
|
||||||
- API와 CLI에서 동일한 태깅 계약을 제공하여 운용 자동화와 수동 조회 흐름을 모두 지원한다.
|
|
||||||
|
|
||||||
## Requirement
|
|
||||||
- 시스템은 각 포트폴리오에 대해 하나 이상의 태그를 추가하고 제거할 수 있어야 한다.
|
|
||||||
- 시스템은 HTTP API와 CLI를 통해 동일한 포트폴리오 태깅 기능을 제공해야 한다.
|
|
||||||
- 시스템은 태그 추가 시 입력 문자열의 앞뒤 공백을 제거한 값을 저장 및 비교 기준으로 사용해야 하며, 정규화 결과가 빈 문자열이면 validation 오류를 반환해야 한다.
|
|
||||||
- 시스템은 태그 문자열의 대소문자, 내부 공백, 네임스페이스 구분자(`:`)를 정규화 과정에서 변경하지 않아야 하며, 앞뒤 공백 제거 외의 추가 정규화는 수행하지 않아야 한다.
|
|
||||||
- 시스템은 둘 이상의 태그를 조건으로 포트폴리오를 검색할 수 있어야 하며, 검색 요청에서 `AND` 또는 `OR` 매칭 방식을 선택할 수 있어야 한다.
|
|
||||||
- 시스템은 HTTP API의 포트폴리오 목록 조회 인터페이스와 CLI의 동일 의미 인터페이스에서 포함 태그(`includeTags`), 제외 태그(`excludeTags`), 포함 태그 매칭 방식(`matchMode`: `AND` 또는 `OR`)을 동시에 지원해야 한다.
|
|
||||||
- 시스템은 `matchMode`를 `includeTags` 집합에만 적용해야 하며, `excludeTags`는 요청된 태그 중 하나라도 일치하면 해당 포트폴리오를 결과에서 제외해야 한다.
|
|
||||||
- 시스템은 태그 기반 조회에서 `grade:*`, `blacklist:*`와 같은 태그 네임스페이스를 그대로 보존하고 필터 조건으로 사용할 수 있어야 한다.
|
|
||||||
- 시스템은 공백만으로 이루어지지 않은 태그 문자열을 추가 대상으로 받아들여야 한다.
|
|
||||||
- 시스템은 동일 포트폴리오에 이미 연결된 태그와 앞뒤 공백 제거 후 동일한 태그 문자열을 다시 추가하려는 요청에 대해 `409 Conflict` 또는 이에 대응하는 CLI 오류를 반환해야 하며, 기존 태그 상태를 변경하지 않아야 한다.
|
|
||||||
- 시스템은 태그 추가·삭제·검색 요청에 대해 기존 포트폴리오 접근 권한 정책을 적용해야 하며, 인증 실패 또는 권한 부족 시 기존 인증 오류 계약에 따라 요청을 거부해야 한다.
|
|
||||||
- 시스템은 존재하지 않는 `portfolio_id`를 대상으로 한 태그 추가·삭제 요청에 대해 Not Found 오류를 반환해야 한다.
|
|
||||||
- 시스템은 태그 검색 결과에서 각 포트폴리오를 중복 없이 한 번만 반환해야 한다.
|
|
||||||
- 시스템은 태그 문자열 길이 또는 포트폴리오당 태그 개수에 대해 애플리케이션 정의 최대 제한만을 이유로 요청을 거부하지 않아야 한다.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
1. Given 기존 포트폴리오가 존재하고 권한이 있는 사용자가 API 또는 CLI로 새 태그를 추가할 때, When 공백만으로 이루어지지 않은 태그 문자열을 제출하면, Then 시스템은 입력값의 앞뒤 공백을 제거한 태그를 해당 포트폴리오에 연결하고 후속 조회에서 그 정규화된 태그가 포함된 상태를 반환해야 한다.
|
|
||||||
2. Given 특정 포트폴리오에 이미 연결된 태그가 있을 때, When 사용자가 API 또는 CLI로 해당 태그를 제거하면, Then 시스템은 성공 응답을 반환하고 후속 조회 및 태그 검색 결과에서 그 연결을 노출하지 않아야 한다.
|
|
||||||
3. Given 여러 포트폴리오에 서로 다른 태그 조합이 연결되어 있을 때, When 사용자가 API 또는 CLI로 `includeTags`에 둘 이상의 태그와 `matchMode=AND`를 지정해 검색하면, Then 시스템은 요청한 모든 포함 태그를 가진 포트폴리오만 반환해야 한다.
|
|
||||||
4. Given 여러 포트폴리오에 서로 다른 태그 조합이 연결되어 있을 때, When 사용자가 API 또는 CLI로 `includeTags`에 둘 이상의 태그와 `matchMode=OR`를 지정해 검색하면, Then 시스템은 요청한 포함 태그 중 하나 이상을 가진 포트폴리오를 반환해야 한다.
|
|
||||||
5. Given 동일 포트폴리오에 이미 앞뒤 공백 제거 후 동일한 태그 문자열이 존재할 때, When 사용자가 API 또는 CLI로 같은 태그를 다시 추가하면, Then 시스템은 `409 Conflict` 응답 또는 이에 대응하는 CLI 오류를 반환하고 중복 태그 연결을 생성하지 않아야 한다.
|
|
||||||
6. Given 인증되지 않았거나 해당 포트폴리오에 접근 권한이 없는 사용자가 API 또는 CLI로 태그 추가·삭제·검색을 시도할 때, When 요청을 전송하면, Then 시스템은 기존 인증/인가 계약에 따라 `401` 또는 `403` 응답을 반환하고 태그 상태를 변경하지 않아야 한다.
|
|
||||||
7. Given 존재하지 않는 `portfolio_id`가 요청에 포함될 때, When 사용자가 API 또는 CLI로 태그 추가 또는 삭제를 시도하면, Then 시스템은 `404` 응답 또는 이에 대응하는 CLI 오류를 반환하고 어떤 태그 연결도 생성·변경하지 않아야 한다.
|
|
||||||
8. Given 포트폴리오에 이미 여러 태그가 연결되어 있고 사용자가 긴 태그 문자열을 추가할 때, When API 또는 CLI로 태그 추가를 요청하면, Then 시스템은 앞뒤 공백 제거 후 빈 문자열이 아닌 한 애플리케이션 정의 최대 길이 제한 또는 최대 개수 제한만을 이유로 요청을 거부하지 않아야 한다.
|
|
||||||
9. Given `OR` 모드의 다중 태그 검색에서 하나의 포트폴리오가 두 개 이상의 요청 태그와 동시에 일치할 때, When 사용자가 검색을 수행하면, Then 시스템은 해당 포트폴리오를 결과에 한 번만 반환해야 한다.
|
|
||||||
10. Given 소비 서비스가 `includeTags=["grade:A", "grade:B"]`, `excludeTags=["blacklist:trade"]`, `matchMode=OR` 조건으로 목록 조회를 요청한 상태, When 태그 필터 검색을 수행하면, Then 시스템은 `grade:A` 또는 `grade:B` 중 하나 이상을 포함하고 `blacklist:trade`를 하나라도 포함하지 않는 항목만 반환해야 한다.
|
|
||||||
|
|
||||||
## Impacted Area
|
|
||||||
- Docs: `docs/technical/api-contracts.md`, `docs/technical/persistence-and-migrations.md`, `docs/SRS/index.md`, `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules: `app/api/portfolios.py`, `app/cli/commands/portfolio.py`, `app/schemas/portfolio.py`, `app/services/portfolio_service.py`, `app/repositories/portfolio_repository.py`, `app/repositories/postgres.py`, `app/domain/models.py`, `migrations/versions/*`
|
|
||||||
- Tests: `tests/test_app.py`, `tests/test_cli.py`, `tests/test_domain_services.py`
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
- 본 requirement의 검색 범위는 다중 태그 검색을 포함하며, 호출자는 `AND` 또는 `OR` 모드를 선택할 수 있다.
|
|
||||||
- 태그 최대 길이와 포트폴리오당 최대 태그 개수에 대한 애플리케이션 정의 상한은 두지 않는다.
|
|
||||||
- 동일 포트폴리오에 같은 태그 문자열을 다시 추가하는 요청은 `409 Conflict` 또는 이에 대응하는 CLI 오류로 처리한다.
|
|
||||||
- 태그 정규화는 앞뒤 공백 제거만 수행하며, 대소문자와 내부 문자열은 보존한다.
|
|
||||||
- HTTP API와 CLI는 `includeTags`, `excludeTags`, `matchMode`에 대해 동일 의미의 검색 계약을 제공한다.
|
|
||||||
- 특정 소비 서비스의 입력 고정/스냅샷 책임은 소비 서비스 측 requirement에서 관리하며, portfolio-hub는 태그 등록/검색 계약만 제공한다.
|
|
||||||
|
|
||||||
## Change Log
|
|
||||||
|
|
||||||
### CHG-20260414-02
|
|
||||||
- Date: 2026-04-14
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-002를 Proposed에서 Approved로 전환했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 태그 정규화 규칙과 태그 검색 입력 계약이 승인 기준을 충족했음을 반영하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Status를 Approved로 전환
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 승인 후 technical spec 동기화 시 REQ-002의 정규화 및 검색 계약이 관련 technical 문서에 동일하게 반영되는지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260414-01
|
|
||||||
- Date: 2026-04-14
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-002의 태그 정규화 규칙과 태그 검색 입력 계약을 구체화해 승인 blocker를 해소할 수 있도록 보강했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 태그 중복 판단과 include/exclude 검색 동작이 구현마다 다르게 해석되지 않도록 인터페이스 계약을 고정하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 앞뒤 공백 제거 기반 태그 정규화 규칙
|
|
||||||
- `includeTags`, `excludeTags`, `matchMode`의 결합 규칙
|
|
||||||
- Updated:
|
|
||||||
- AC1, AC3, AC4, AC5, AC8, AC10의 입력/비교 기준 명확화
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- tag input normalization 및 검색 query parser 구현 경로
|
|
||||||
- Tests:
|
|
||||||
- 태그 정규화, 중복 추가 충돌, include/exclude 조합 검색 검증 시나리오
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 문서 리뷰 시 태그 정규화 규칙과 `includeTags`/`excludeTags`/`matchMode` 조합 규칙이 각각 독립 테스트로 매핑 가능한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260413-05
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 삭제 예정인 상위 docs 경로를 technical 문서 경로로 정리했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 태그 기능 requirement가 삭제 후에도 유효한 구현 추적 문서를 가리키도록 유지하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Impacted Area의 docs 경로를 `docs/technical/` 기준으로 갱신
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md`
|
|
||||||
- `docs/technical/api-contracts.md`
|
|
||||||
- `docs/technical/persistence-and-migrations.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 삭제 대상 문서 제거 후에도 REQ-002의 docs 추적 링크가 모두 유효한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260413-04
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-002의 stock-picker 특정 소비자 표현을 다운스트림 소비자 일반 계약으로 정리했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- portfolio-hub 태그 검색 기능을 특정 소비자 전용 기능이 아닌 공용 인터페이스 계약으로 유지하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 없음
|
|
||||||
- Updated:
|
|
||||||
- Requirement/Acceptance Criteria/Notes의 소비자 표현 일반화
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- REQ-002 본문이 특정 소비자 구현을 전제하지 않고 include/exclude 태그 검색 계약만 명확히 정의하는지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260413-03
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- REQ-002에 stock-picker 기본 유니버스 소비를 위한 include/exclude 태그 필터 계약을 추가했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- portfolio-hub 태그 등록값(예: grade, blacklist)을 downstream 필터 인자로 직접 활용하는 계약을 명시하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- includeTags/excludeTags 동시 적용 검증 기준
|
|
||||||
- Updated:
|
|
||||||
- Requirement에 stock-picker 소비자 관점 필터 계약 추가
|
|
||||||
- Notes에 stock-picker 연계 경계 문구 추가
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- Modules:
|
|
||||||
- portfolio tag search API/CLI query parser 영향 식별
|
|
||||||
- Tests:
|
|
||||||
- include/exclude 조합 필터링 테스트 항목 추가
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- includeTags/excludeTags 조합 요청에서 반환 집합이 예상과 일치하는지 API/CLI 테스트로 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-02
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 다중 태그 `AND`/`OR` 검색, 중복 추가 시 `409 Conflict`, 태그 길이/개수 상한 없음 계약을 REQ-002에 반영했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 검토 피드백과 owner 결정을 반영해 모호한 인터페이스 계약을 test 가능하게 확정하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 다중 태그 `AND` 검색 결과 규칙
|
|
||||||
- 다중 태그 `OR` 검색 결과 규칙
|
|
||||||
- 중복 태그 추가 시 `409 Conflict` 처리
|
|
||||||
- 태그 길이/개수 상한 없음 검증 기준
|
|
||||||
- Updated:
|
|
||||||
- 태그 입력 유효성 표현을 공백이 아닌 문자열 기준으로 명확화
|
|
||||||
- `Impacted Area` 경로 표기를 repository-relative path로 정리
|
|
||||||
- Removed:
|
|
||||||
- 단일 태그 검색 assumption
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules:
|
|
||||||
- 없음
|
|
||||||
- Tests:
|
|
||||||
- 추후 API/CLI 다중 태그 검색 및 중복 충돌 테스트 추가 필요
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 문서 리뷰 시 다중 태그 `AND`/`OR` 검색, 중복 추가 `409 Conflict`, 태그 길이/개수 상한 없음 조건이 각각 독립 테스트로 매핑 가능한지 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260410-01
|
|
||||||
- Date: 2026-04-10
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 포트폴리오 태깅 및 태그 기반 검색 기능에 대한 신규 SRS requirement 초안을 작성했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 사용자 관찰 가능한 API/CLI 계약과 검색 동작을 명확히 정의하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- API/CLI를 통한 태그 추가 및 제거 요구
|
|
||||||
- 특정 태그 기반 포트폴리오 검색 요구
|
|
||||||
- 중복 태그 방지, 권한 검증, Not Found 오류 처리 요구
|
|
||||||
- Updated:
|
|
||||||
- 없음
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- docs/technical/api-contracts.md
|
|
||||||
- docs/technical/persistence-and-migrations.md
|
|
||||||
- index.md
|
|
||||||
- traceability-matrix.md
|
|
||||||
- Modules:
|
|
||||||
- portfolios.py
|
|
||||||
- portfolio.py
|
|
||||||
- portfolio.py
|
|
||||||
- portfolio_service.py
|
|
||||||
- portfolio_repository.py
|
|
||||||
- postgres.py
|
|
||||||
- models.py
|
|
||||||
- `migrations/versions/*`
|
|
||||||
- Tests:
|
|
||||||
- test_app.py
|
|
||||||
- test_cli.py
|
|
||||||
- test_domain_services.py
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- API 테스트로 태그 추가/삭제 및 태그 기반 검색 계약을 검증한다.
|
|
||||||
- CLI 테스트로 동일 기능의 입력/출력 계약을 검증한다.
|
|
||||||
- 저장소 및 서비스 테스트로 중복 태그 방지와 포트폴리오별 태그 연결 일관성을 검증한다.
|
|
||||||
@@ -1,113 +0,0 @@
|
|||||||
# REQ-004: 포트폴리오 소유주 기반 접근 제어
|
|
||||||
|
|
||||||
- Status: Proposed
|
|
||||||
- Type: Interface
|
|
||||||
- Priority: High
|
|
||||||
- Owner: Justin
|
|
||||||
|
|
||||||
## Intent
|
|
||||||
- 시스템은 각 포트폴리오의 소유주를 명시적으로 저장하고, 인증된 주체의 권한과 소유권을 함께 평가해 접근 제어를 수행해야 한다.
|
|
||||||
- 동일 서버에서 운영되는 frontend와 portfolio-hub가 공통 인증 기반을 공유하더라도, 포트폴리오 단위 데이터 격리가 보장되도록 한다.
|
|
||||||
|
|
||||||
## Requirement
|
|
||||||
- 시스템은 각 `portfolio` 레코드에 소유주 식별자 `owner_user_id`를 저장해야 한다.
|
|
||||||
- 시스템은 신규 포트폴리오 생성 시 요청 본문으로 소유주를 임의 지정받지 않고, 인증 컨텍스트의 사용자 식별자를 `owner_user_id`로 저장해야 한다.
|
|
||||||
- 시스템은 `admin` 권한을 제외한 모든 사용자/토큰 요청에서 `owner_user_id`가 인증 주체와 일치하는 포트폴리오만 조회/변경/삭제 가능해야 한다.
|
|
||||||
- 시스템은 `admin` 권한 요청에서 소유권 제약 없이 포트폴리오 전체를 조회/변경/삭제할 수 있어야 한다.
|
|
||||||
- 시스템은 소유권 불일치로 거부된 요청에 대해 `403 Forbidden`을 반환해야 한다.
|
|
||||||
- 시스템은 봇 principal에 소유 사용자 식별자(`bot_principals.owner_user_id`)를 저장해야 하며, 봇 토큰 인증 시 해당 값을 실효 사용자 식별자로 해석해야 한다.
|
|
||||||
- 시스템은 사용자 귀속 정보가 해석되지 않는 토큰이 소유권이 필요한 포트폴리오 작업을 요청하면 `403 Forbidden`을 반환해야 한다.
|
|
||||||
- 시스템은 기존 포트폴리오 데이터에 대해 마이그레이션 시 `owner_user_id`를 null 허용으로 추가한 뒤, 백필 완료 후 not null 제약을 적용할 수 있어야 한다.
|
|
||||||
- 시스템은 기존 봇 principal 데이터에 대해 마이그레이션 시 `bot_principals.owner_user_id`를 null 허용으로 추가한 뒤, 백필 완료 후 not null 및 FK(`users.id`) 제약을 적용할 수 있어야 한다.
|
|
||||||
|
|
||||||
## Acceptance Criteria
|
|
||||||
1. Given 인증된 일반 사용자(또는 해당 사용자에 귀속된 토큰)가 `POST /portfolios`를 호출할 때, When 포트폴리오가 생성되면, Then 저장된 `owner_user_id`는 요청자 사용자 식별자와 동일해야 하며 요청 본문으로 다른 소유주를 지정할 수 없어야 한다.
|
|
||||||
2. Given 서로 다른 두 사용자 A와 B가 존재하고 A 소유 포트폴리오가 있을 때, When B가 `GET /portfolios/{portfolio_id}` 또는 변경 API를 호출하면, Then 시스템은 `403`을 반환하고 데이터를 노출/변경하지 않아야 한다.
|
|
||||||
3. Given 일반 사용자 A가 목록 조회를 수행할 때, When `GET /portfolios`를 호출하면, Then 응답 목록에는 A 소유 포트폴리오만 포함되어야 한다.
|
|
||||||
4. Given `admin` 권한 사용자가 존재할 때, When `GET /portfolios` 또는 특정 포트폴리오 변경 API를 호출하면, Then 시스템은 소유권 검사로 요청을 거부하지 않아야 한다.
|
|
||||||
5. Given 마이그레이션 적용 전 생성된 레거시 포트폴리오가 존재할 때, When ownership 마이그레이션을 적용하면, Then 데이터 손실 없이 `owner_user_id`가 백필되고 이후 읽기/쓰기 API가 실패 없이 동작해야 한다.
|
|
||||||
6. Given 사용자 A에 귀속된 bot 토큰이 존재할 때, When bot 토큰이 `GET /portfolios/{portfolio_id}` 또는 변경 API를 호출하면, Then A 소유 포트폴리오에는 접근 가능하고 A가 아닌 사용자 소유 포트폴리오에는 `403`을 반환해야 한다.
|
|
||||||
7. Given 인증 컨텍스트에 사용자 식별자가 해석되지 않는 토큰(예: DB 비연결 정적 토큰)이 포트폴리오 생성/수정/삭제를 요청할 때, When 소유권이 필요한 API를 호출하면, Then 시스템은 `403`을 반환해야 한다.
|
|
||||||
|
|
||||||
## Impacted Area
|
|
||||||
- Docs: `docs/SRS/index.md`, `docs/SRS/traceability-matrix.md`, `docs/technical/auth-and-token-lifecycle.md`, `docs/technical/api-contracts.md`, `docs/technical/persistence-and-migrations.md`, `docs/technical/portfolio-ownership-and-auth-design.md`
|
|
||||||
- Modules: `app/core/auth.py`, `app/api/portfolios.py`, `app/services/portfolio_service.py`, `app/repositories/portfolio_repository.py`, `app/repositories/postgres.py`, `app/domain/models.py`, `app/schemas/portfolio.py`, `migrations/versions/*`
|
|
||||||
- Tests: `tests/test_portfolio_ownership.py`, `tests/test_users.py`, `tests/test_auth.py`, `tests/test_portfolio_comments.py`
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
- 본 requirement는 인증 서비스 분리 여부와 무관하게 portfolio-hub 내부에서 반드시 충족되어야 하는 리소스 소유권 계약이다.
|
|
||||||
- 소유권 기반 제어는 기존 RBAC(`read`, `trade-write`, `admin`)를 대체하지 않고 보완한다.
|
|
||||||
|
|
||||||
## Change Log
|
|
||||||
|
|
||||||
### CHG-20260413-01
|
|
||||||
- Date: 2026-04-13
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 포트폴리오 소유주 필드와 소유권 기반 접근 제어를 정의하는 신규 requirement를 추가했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- frontend와 API가 동일 인증 체계를 사용할 때도 포트폴리오 단위 데이터 격리를 강제하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 소유주 저장 규칙
|
|
||||||
- 일반 사용자 소유권 격리 규칙
|
|
||||||
- admin 예외 규칙
|
|
||||||
- 레거시 백필 규칙
|
|
||||||
- user_id 없는 주체 거부 규칙
|
|
||||||
- Updated:
|
|
||||||
- 없음
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-004_portfolio-ownership-access-control.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- `docs/SRS/traceability-matrix.md`
|
|
||||||
- `docs/technical/portfolio-ownership-and-auth-design.md`
|
|
||||||
- Modules:
|
|
||||||
- ownership 검사 경로 전반
|
|
||||||
- Tests:
|
|
||||||
- API/권한/백필 검증 시나리오
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 사용자별 소유권 격리 통합 테스트, admin 우회 테스트, 마이그레이션 백필 테스트를 통해 계약 충족 여부를 확인한다.
|
|
||||||
|
|
||||||
### CHG-20260414-01
|
|
||||||
- Date: 2026-04-14
|
|
||||||
- Author: GitHub Copilot
|
|
||||||
|
|
||||||
#### Change Summary
|
|
||||||
- 봇 principal의 사용자 귀속(`bot_principals.owner_user_id`) 및 봇 토큰 실효 사용자 매핑 규칙을 requirement에 추가했다.
|
|
||||||
|
|
||||||
#### Intent
|
|
||||||
- 사용자별 봇 bearer token이 해당 사용자 포트폴리오 경계 내에서만 동작하도록 계약을 명확히 하기 위함이다.
|
|
||||||
|
|
||||||
#### Acceptance Criteria Delta
|
|
||||||
- Added:
|
|
||||||
- 사용자 귀속 bot 토큰의 소유권 허용/거부 기준 (AC6)
|
|
||||||
- 사용자 식별자 미해석 토큰 거부 기준 (AC7)
|
|
||||||
- Updated:
|
|
||||||
- Requirement 본문의 bot 토큰 처리 규칙
|
|
||||||
- Removed:
|
|
||||||
- 없음
|
|
||||||
|
|
||||||
#### Impacted Area Delta
|
|
||||||
- Docs:
|
|
||||||
- `docs/SRS/Interface/REQ-004_portfolio-ownership-access-control.md`
|
|
||||||
- `docs/SRS/index.md`
|
|
||||||
- `docs/SRS/traceability-matrix.md`
|
|
||||||
- Modules:
|
|
||||||
- `app/repositories/postgres.py`
|
|
||||||
- `app/services/auth_service.py`
|
|
||||||
- `app/schemas/auth.py`
|
|
||||||
- `migrations/versions/20260414_0011_bot_principal_owner_user_id.py`
|
|
||||||
- Tests:
|
|
||||||
- `tests/test_portfolio_ownership.py`
|
|
||||||
- `tests/test_users.py`
|
|
||||||
|
|
||||||
#### Validation Plan
|
|
||||||
- 사용자 귀속 bot 토큰의 owner 허용/타 사용자 거부 시나리오와 봇 owner 백필 마이그레이션 적용 검증을 수행한다.
|
|
||||||
@@ -1,44 +0,0 @@
|
|||||||
# PortfolioHub SRS Index
|
|
||||||
|
|
||||||
이 문서는 `docs/SRS/` 하위 requirement 문서의 운영 기준과 등록 현황을 관리한다.
|
|
||||||
|
|
||||||
## Requirement 작성 규칙
|
|
||||||
- Requirement 하나당 문서 하나를 사용한다.
|
|
||||||
- 새 requirement ID의 source of truth는 이 문서의 `Next Requirement ID`다.
|
|
||||||
- Type 분류는 주된 사용자/외부 계약을 기준으로 결정한다.
|
|
||||||
- `Interface`: API, CLI, UI 등 사용자가 직접 조작하거나 호출하는 방식
|
|
||||||
- `Data`: 저장 구조, 스키마, 데이터 형식 자체가 핵심 제약인 경우
|
|
||||||
- `Exception & Error Handling`: 오류 응답, 복구, 재시도 전략이 핵심인 경우
|
|
||||||
- 그 외는 관련 운영 기준에 따라 적절한 Type을 선택한다.
|
|
||||||
- 각 requirement는 최소한 `Status`, `Type`, `Priority`, `Owner`, `Intent`, `Requirement`, `Acceptance Criteria`, `Impacted Area`, `Change Log`를 포함해야 한다.
|
|
||||||
- 새 requirement가 추가되면 `Requirement Register`와 `Next Requirement ID`를 함께 갱신한다.
|
|
||||||
- 최근 변경 요약은 최신 항목을 위에 두고 최대 5건만 유지한다.
|
|
||||||
|
|
||||||
## Next Requirement ID
|
|
||||||
- `REQ-005`
|
|
||||||
|
|
||||||
## Requirement Register
|
|
||||||
|
|
||||||
| REQ ID | Title | Type | Status | Priority | Owner | File |
|
|
||||||
|---|---|---|---|---|---|---|
|
|
||||||
| REQ-001 | 포트폴리오 댓글형 메모 이력 지원 | Interface | Approved | Medium | Justin | `docs/SRS/Interface/REQ-001_portfolio-comment-history.md` |
|
|
||||||
| REQ-002 | 포트폴리오 태깅 및 태그 기반 검색 지원 | Interface | Approved | Medium | Justin | `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md` |
|
|
||||||
| REQ-003 | 포트폴리오 필수 필드 및 거래소/시장 데이터 정의 | Data | Proposed | Medium | Justin | `docs/SRS/Data/REQ-003_portfolio-required-fields.md` |
|
|
||||||
| REQ-004 | 포트폴리오 소유주 기반 접근 제어 | Interface | Proposed | High | Justin | `docs/SRS/Interface/REQ-004_portfolio-ownership-access-control.md` |
|
|
||||||
|
|
||||||
## Recent Change Log Summary
|
|
||||||
- 2026-04-14 — `REQ-002`를 Approved로 전환했다.
|
|
||||||
- 2026-04-14 — `REQ-002`에 태그 정규화 규칙과 `includeTags`/`excludeTags`/`matchMode` 검색 계약을 추가해 승인 blocker를 줄였다.
|
|
||||||
- 2026-04-14 — `REQ-004`에 사용자 귀속 봇 principal(`bot_principals.owner_user_id`) 및 봇 토큰 실효 사용자 매핑 규칙(AC6, AC7)을 추가했다.
|
|
||||||
- 2026-04-13 — `REQ-004` 포트폴리오 소유주(`owner_user_id`) 및 소유권 기반 접근 제어 requirement를 추가했다.
|
|
||||||
- 2026-04-13 — `REQ-003`에서 태그 필터 기반 조회의 결정성 유지 책임을 소비 서비스(stock-picker)로 이관했다.
|
|
||||||
|
|
||||||
## Status Transition Evidence
|
|
||||||
- `Proposed` → `Approved`: Owner가 지정되고 requirement 문서 리뷰가 완료되며 acceptance criteria가 누락 없이 검토되어야 한다.
|
|
||||||
- `Approved` → `Implemented`: 구현 코드가 병합되고 관련 문서 및 테스트 경로가 requirement 또는 traceability matrix에 연결되어야 한다.
|
|
||||||
- `Implemented` → `Verified`: 자동 테스트 또는 수동 검증 evidence가 확인되어야 한다.
|
|
||||||
- `Verified` → `Released`: 배포 또는 릴리스 노트 반영 evidence가 확인되어야 한다.
|
|
||||||
|
|
||||||
## Related Documents
|
|
||||||
- Requirement files: `docs/SRS/<Type>/REQ-XXX_<slug>.md`
|
|
||||||
- Traceability matrix: `docs/SRS/traceability-matrix.md`
|
|
||||||
@@ -1,23 +0,0 @@
|
|||||||
# SRS Traceability Matrix
|
|
||||||
|
|
||||||
## Status Definition
|
|
||||||
- Planned: Requirement is defined but not yet implemented.
|
|
||||||
- In Progress: Implementation issue/PR exists and work is ongoing.
|
|
||||||
- Implemented: Code is merged and mapped acceptance criteria are complete.
|
|
||||||
- Verified: Required tests and manual checks are completed.
|
|
||||||
- Released: Included in a released version.
|
|
||||||
|
|
||||||
## Matrix
|
|
||||||
|
|
||||||
| REQ ID | AC Mapping | Requirement File | Implementation Issue | PR | Test Evidence | Requirement Status | Delivery Status | Last Updated |
|
|
||||||
|---|---|---|---|---|---|---|---|---|
|
|
||||||
| REQ-001 | AC1, AC2, AC3, AC4, AC5, AC6, AC7 | `docs/SRS/Interface/REQ-001_portfolio-comment-history.md` | #2 | TBD | TBD | Approved | In Progress | 2026-04-10 |
|
|
||||||
| REQ-002 | AC1, AC2, AC3, AC4, AC5, AC6, AC7, AC8, AC9, AC10 | `docs/SRS/Interface/REQ-002_portfolio-tagging-and-search.md` | TBD | TBD | `tests/test_portfolio_tags.py`, `tests/test_cli.py`, local `pytest` pass (65 passed, 2026-04-14) | Approved | Verified | 2026-04-14 |
|
|
||||||
| REQ-003 | AC1, AC2, AC3, AC4, AC5 | `docs/SRS/Data/REQ-003_portfolio-required-fields.md` | TBD | TBD | TBD | Proposed | Planned | 2026-04-10 |
|
|
||||||
| REQ-004 | AC1, AC2, AC3, AC4, AC5, AC6, AC7 | `docs/SRS/Interface/REQ-004_portfolio-ownership-access-control.md` | TBD | TBD | `tests/test_portfolio_ownership.py`, `tests/test_users.py`, `tests/test_auth.py`, `tests/test_portfolio_comments.py`, local `pytest` pass (2026-04-14) | Proposed | In Progress | 2026-04-14 |
|
|
||||||
|
|
||||||
## Update Rules
|
|
||||||
- REQ ID must exactly match the SRS requirement file prefix.
|
|
||||||
- AC Mapping should reference concrete IDs such as `AC1`, `AC2`.
|
|
||||||
- Test Evidence should point to executable artifacts such as test file paths, CI runs, or manual verification notes.
|
|
||||||
- Use `TBD` where implementation or verification evidence does not yet exist.
|
|
||||||
@@ -1,6 +0,0 @@
|
|||||||
item_id,work_item,business_value,time_criticality,rr_oe,job_size,reach,impact,confidence,effort,method,selected_score,priority,notes
|
|
||||||
P-002,만기 정책 및 권한 가드 구현 (--no-expiry 및 기본 TTL 365일),9,10,9,4,,,,,WSJF,7.00,1,"FR-3/R-1"
|
|
||||||
P-003,토큰 출력 마스킹 및 감사 로그 구현,8,8,10,4,,,,,WSJF,6.50,2,"NFR-1/NFR-2/R-3"
|
|
||||||
P-001,CLI bot 토큰 발급/삭제 명령 추가,10,9,8,5,,,,,WSJF,5.40,3,"FR-1/FR-2/FR-4/FR-5"
|
|
||||||
P-004,CLI UX 정합성 보강 (confirm-force/오류/출력 포맷),7,7,7,4,,,,,WSJF,5.25,4,"NFR-3/NFR-4"
|
|
||||||
P-005,테스트 및 문서 동기화,7,6,8,5,,,,,WSJF,4.20,5,"S-1/S-2/S-3"
|
|
||||||
|
Reference in New Issue
Block a user