agentic-dev 0.2.11 → 0.2.12

package/sdd/01_planning/01_feature/alerts_feature_spec.md

@@ -1,55 +0,0 @@
-# alerts feature spec
-
-- 작성 버전: 1.0.0
-
-## 1. Purpose
-
-`alerts` bounded context가 제공하는 운영 알람 feed와 읽음 처리 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - admin surface의 운영 알람 목록 조회
-  - 알람 단건 읽음 처리와 전체 읽음 처리
-- 제외 범위:
-  - email, SMS, push 같은 외부 발송 인프라
-  - 주문/배송/재고 도메인 내부의 원인 계산 로직 자체
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Admin Operator` | admin 서비스에서 운영 이벤트와 예외 상황을 확인하고 알람 읽음 상태를 관리하는 운영 관리자다. | `ALR-F001`, `ALR-F002`, `ALR-F003` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `ALR` |
-| Bounded Context | Alert Center |
-| Primary Backend Owner | `server/contexts/alerts` |
-| Related Context | `orders`, `shipping`, `inventory`, `support` |
-| Main Entry Contract | `GET /api/v1/alerts`, `POST /api/v1/alerts/{alert_id}/read`, `POST /api/v1/alerts/read-all` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `AlertRecord` | 운영 알람 저장 모델 |
-| `AlertItem` | 알람 feed 응답 모델 |
-| `AlertsPayload` | unread count와 목록을 묶은 응답 모델 |
-| `AlertReadResult` | 단건 읽음 처리 결과 |
-| `AlertsReadAllResult` | 전체 읽음 처리 결과 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ALR-F001` | 운영 알람 feed를 조회한다 | Admin Operator | Alert Center | `AlertsPayload`, `AlertItem`, `AlertRecord` | Query | 관리자 토큰이 유효하고 alert bootstrap 데이터가 존재해야 한다 | unread count와 최신 운영 알람 목록을 반환한다 | feed 조회는 알람 읽음 상태를 변경하지 않는다 |
-| `ALR-F002` | 운영 알람 1건을 읽음 처리한다 | Admin Operator | Alert Center | `AlertReadResult`, `AlertRecord` | Command | 관리자 토큰이 유효하고 요청한 `alert_id`가 존재해야 한다 | 선택한 알람의 `read` 상태가 `true`가 된다 | 존재하지 않는 `alert_id`면 `404`를 반환한다 |
-| `ALR-F003` | 운영 알람 전체를 읽음 처리한다 | Admin Operator | Alert Center | `AlertsReadAllResult`, `AlertRecord` | Command | 관리자 토큰이 유효하고 alert bootstrap 데이터가 존재해야 한다 | 미읽음 알람이 모두 읽음 상태로 갱신된다 | 이미 읽은 알람은 중복 변경하지 않는다 |
-
-## 7. Notes
-
-- `alerts`는 admin dashboard의 보조 read model이 아니라 독립 운영 피드로 취급한다.
-- 원인 도메인이 무엇이든 admin이 소비하는 알람 표현과 읽음 상태는 `alerts` context가 소유한다.

package/sdd/01_planning/01_feature/auth_feature_spec.md

@@ -1,57 +0,0 @@
-# auth feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`auth` bounded context가 제공하는 인증과 현재 세션 해석 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - 이메일/비밀번호 기반 로그인과 bearer token 기반 현재 세션 해석
-  - `auth_accounts.json`이 소유하는 credential 검증과 공통 session contract
-- 제외 범위:
-  - 사용자 프로필 조회/변경과 role 관리
-  - 로그인 이후 서비스별 route 분기나 client-side token 저장 방식
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Web User` | web 서비스에서 주문/운영 기능에 접근하기 위해 인증 세션을 발급받는 사용자다. | `AUT-F001` |
-| `Mobile Operator` | mobile 서비스에서 이행 작업을 수행하기 위해 로그인하는 현장 운영자다. | `AUT-F001` |
-| `Admin Operator` | admin 서비스에서 카탈로그, 재고, 사용자 운영 명령을 수행하기 위해 관리자 세션을 발급받는 주체다. | `AUT-F001` |
-| `Landing Member` | landing 서비스에서 회원 전용 자원이나 개인화 동작을 사용하기 위해 로그인하는 사용자다. | `AUT-F001` |
-| `Authenticated Client` | 이미 bearer token을 보유한 frontend runtime 또는 HTTP client로 현재 세션 사용자 해석을 요청하는 주체다. | `AUT-F002` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `AUT` |
-| Bounded Context | Authentication & Session |
-| Primary Backend Owner | `server/contexts/auth` |
-| Related Context | `server/contexts/user` |
-| Main Entry Contract | `POST /api/v1/auth/login`, `GET /api/v1/auth/me` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `LoginCommand` | 로그인 명령 입력 모델 |
-| `AuthToken` | bearer token 응답 모델 |
-| `AuthAccountRecord` | 인증 계정 저장 모델 |
-| `AuthenticatedUser` | 현재 세션 사용자 응답 모델 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `AUT-F001` | 이메일/비밀번호로 로그인하고 access token을 발급한다 | Web User, Mobile Operator, Admin Operator, Landing Member | Authentication & Session | `LoginCommand`, `AuthToken`, `AuthAccountRecord` | Command | 이메일과 비밀번호가 전달되고, 인증 계정 저장소에 해당 사용자가 존재해야 한다 | access token과 `user_id`가 발급된다 | credential이 일치하지 않으면 `401 Invalid credentials`를 반환한다 |
-| `AUT-F002` | bearer token으로 현재 세션 사용자를 해석한다 | Authenticated Client | Authentication & Session | `AuthToken`, `AuthenticatedUser`, `AuthAccountRecord` | Query | 유효한 bearer token이 전달되고 token subject가 인증 계정 저장소에 존재해야 한다 | 현재 사용자 summary를 반환한다 | token이 위조되었거나 subject 사용자가 없으면 `401 Invalid token`을 반환한다 |
-
-## 7. Notes
-
-- `auth`는 `auth_accounts.json` bootstrap을 소유하며 `user` profile 저장과 credential 저장을 분리한다.
-- 인증 성공 이후 권한별 화면 분기는 frontend service에서 처리하고, backend는 공통 session contract만 제공한다.

package/sdd/01_planning/01_feature/catalog_feature_spec.md

@@ -1,61 +0,0 @@
-# catalog feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`catalog` bounded context가 제공하는 상품 카탈로그 조회와 관리자 상품 편집 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - landing/public 상품 카탈로그 조회와 단일 상품 상세 조회
-  - admin surface의 상품 생성, 수정, 상태 변경 command
-- 제외 범위:
-  - landing 화면의 정렬, 탭, CTA 같은 UI 상호작용
-  - 주문 생성이나 재고 선점 같은 타 context orchestration
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Landing Visitor` | 비로그인 상태로 공개 상품 카탈로그와 상품 상세를 탐색하는 방문자다. | `CAT-F001`, `CAT-F002` |
-| `Landing Member` | 로그인된 landing 회원으로 공개 상품을 둘러보고 구매 전 탐색을 수행하는 사용자다. | `CAT-F001`, `CAT-F002` |
-| `Web User` | web 서비스에서 주문 생성이나 운영 판단을 위해 상품 정보를 조회하는 내부 사용자다. | `CAT-F001`, `CAT-F002` |
-| `Admin Operator` | admin 서비스에서 상품을 등록, 수정, 상태 변경하는 운영 관리자다. | `CAT-F003`, `CAT-F004`, `CAT-F005` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `CAT` |
-| Bounded Context | Product Catalog |
-| Primary Backend Owner | `server/contexts/catalog` |
-| Related Context | `auth`, `inventory`, `orders`, `landing` |
-| Main Entry Contract | `GET /api/v1/catalog/products`, `GET /api/v1/catalog/products/{product_id}`, `POST /api/v1/catalog/products`, `PUT /api/v1/catalog/products/{product_id}`, `PATCH /api/v1/catalog/products/{product_id}/status` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `ProductRecord` | 상품 원본 저장 모델 |
-| `ProductSummary` | 상품 목록 응답 모델 |
-| `ProductDetail` | 상품 상세 응답 모델 |
-| `CreateProductCommand` | 상품 생성 명령 |
-| `UpdateProductCommand` | 상품 수정 명령 |
-| `UpdateProductStatusCommand` | 상품 상태 변경 명령 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `CAT-F001` | 상품 카탈로그 목록을 조회한다 | Landing Visitor, Landing Member, Web User | Product Catalog | `ProductSummary`, `ProductRecord` | Query | 상품 bootstrap 데이터가 존재해야 한다 | 공개 가능한 상품 목록을 필터와 검색 조건에 맞게 반환한다 | `status`, `category`, `q` 조건은 모두 현재 카탈로그 집합 안에서 계산한다 |
-| `CAT-F002` | 단일 상품 상세를 조회한다 | Landing Visitor, Landing Member, Web User | Product Catalog | `ProductDetail`, `ProductRecord` | Query | 요청한 `product_id`가 저장소에 존재해야 한다 | 상세 페이지 구성을 위한 상품 전체 속성을 반환한다 | 존재하지 않는 `product_id`면 `404 Catalog product not found`를 반환한다 |
-| `CAT-F003` | 관리자가 새 상품을 등록한다 | Admin Operator | Product Catalog | `CreateProductCommand`, `ProductDetail`, `ProductRecord` | Command | 관리자 토큰이 유효하고 slug, 이름, 가격, variant 정보가 전달되어야 한다 | 새 상품 레코드가 생성되어 카탈로그 목록에 합류한다 | `slug`는 카탈로그 내에서 유일해야 하며 variant는 최소 1개 이상이어야 한다 |
-| `CAT-F004` | 관리자가 상품 속성을 수정한다 | Admin Operator | Product Catalog | `UpdateProductCommand`, `ProductDetail`, `ProductRecord` | Command | 관리자 토큰이 유효하고 요청한 `product_id`가 존재해야 한다 | 상품 속성이 부분 갱신되고 `updated_at`이 갱신된다 | 빈 수정 요청은 `400 No catalog product fields provided`, 중복 slug는 `409`를 반환한다 |
-| `CAT-F005` | 관리자가 상품 상태를 변경한다 | Admin Operator | Product Catalog | `UpdateProductStatusCommand`, `ProductDetail`, `ProductRecord` | Command | 관리자 토큰이 유효하고 요청한 `product_id`가 존재해야 한다 | 상품 `status`가 `draft`, `active`, `archived` 중 하나로 전환된다 | 존재하지 않는 `product_id`면 `404 Catalog product not found`를 반환한다 |
-
-## 7. Notes
-
-- `catalog`는 landing/public read surface와 admin write surface를 함께 소유한다.
-- 카탈로그의 가격, 이미지, 속성, variant는 모두 product aggregate 내부 속성으로 유지한다.

package/sdd/01_planning/01_feature/fulfillment_feature_spec.md

@@ -1,58 +0,0 @@
-# fulfillment feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`fulfillment` bounded context가 제공하는 모바일 운영 overview와 task board 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - mobile 서비스의 fulfillment overview, board, note read model
-  - fulfillment task 상태 전이 command
-- 제외 범위:
-  - route 최적화나 배차 같은 고도화 계획
-  - fulfillment 외부 context를 직접 갱신하는 orchestration
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Mobile Operator` | mobile 서비스에서 현장 이행 작업을 수행하며 task 현황을 보고 상태를 갱신하는 운영자다. | `FUL-F001`, `FUL-F002`, `FUL-F003` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `FUL` |
-| Bounded Context | Fulfillment Operations |
-| Primary Backend Owner | `server/contexts/fulfillment` |
-| Related Context | `auth`, `orders`, `inventory` |
-| Main Entry Contract | `GET /api/v1/fulfillment/overview`, `GET /api/v1/fulfillment/board`, `PATCH /api/v1/fulfillment/tasks/{task_id}/status` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `FulfillmentTaskRecord` | 이행 task 원본 |
-| `FulfillmentOverview` | 모바일 dashboard overview 응답 |
-| `FulfillmentBoardPayload` | 모바일 task board 응답 |
-| `FulfillmentEvent` | timeline 이벤트 모델 |
-| `FulfillmentNote` | 운영 note 모델 |
-| `FulfillmentTaskStatusTransitionCommand` | task 상태 전이 명령 |
-| `FulfillmentTaskStatusTransition` | task 상태 전이 결과 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `FUL-F001` | 이행 overview를 조회한다 | Mobile Operator | Fulfillment Operations | `FulfillmentOverview`, `FulfillmentTaskRecord`, `FulfillmentEvent` | Query | 인증 토큰이 유효하고 task/event bootstrap 데이터가 존재해야 한다 | throughput, stat, timeline, stage load를 반환한다 | `Blocked`와 `Outbound` 지표는 현재 task 상태 집합으로 계산한다 |
-| `FUL-F002` | 이행 board와 note 목록을 조회한다 | Mobile Operator | Fulfillment Operations | `FulfillmentBoardPayload`, `FulfillmentTaskRecord`, `FulfillmentNote` | Query | 인증 토큰이 유효하고 task/note bootstrap 데이터가 존재해야 한다 | task board 목록과 note 목록을 함께 반환한다 | board payload는 `tasks`와 `notes` 두 블록을 항상 함께 반환한다 |
-| `FUL-F003` | 이행 task 상태를 전환한다 | Mobile Operator | Fulfillment Operations | `FulfillmentTaskStatusTransitionCommand`, `FulfillmentTaskStatusTransition`, `FulfillmentTaskRecord` | Command | 인증 토큰이 유효하고 요청한 `task_id`가 존재해야 한다 | task의 `status`와 선택적 `stage`가 갱신된다 | 존재하지 않는 `task_id`면 `404`를 반환한다 |
-
-## 7. Notes
-
-- `fulfillment`는 mobile 서비스의 canonical backend surface다.
-- 출고 이후 배송 추적과 carrier 진행 상태는 별도 `shipping` context가 소유한다.
-- timeline과 notes는 별도 bootstrap source를 사용하지만, screen 단위에서는 fulfillment context가 함께 조합해 반환한다.

package/sdd/01_planning/01_feature/health_feature_spec.md

@@ -1,52 +0,0 @@
-# health feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`health` bounded context가 제공하는 기술 상태 확인 contract를 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - 무인증 liveness/status probe contract
-  - runtime이 기동 중인지 확인하는 최소 운영 신호
-- 제외 범위:
-  - 알림 전파, auto-recovery, runbook 절차 같은 운영 후속 조치
-  - business domain readiness나 데이터 정합성 검증
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `CI Runner` | CI 파이프라인에서 서버 기동과 기본 응답 계약을 확인하는 자동 검증 주체다. | `HLT-F001`, `HLT-F002` |
-| `Compose Runtime` | compose healthcheck나 container supervisor처럼 주기적으로 프로브를 호출하는 런타임 주체다. | `HLT-F001`, `HLT-F002` |
-| `External Monitor` | 외부 uptime/monitoring 시스템에서 서비스 생존 여부를 확인하는 감시 주체다. | `HLT-F001`, `HLT-F002` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `HLT` |
-| Bounded Context | Technical Health |
-| Primary Backend Owner | `server/contexts/health` |
-| Related Context | `server/api/http/app.py` |
-| Main Entry Contract | `GET /health`, `GET /api/v1/status` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `health_response()` | 루트 프로브 응답 생성 함수 |
-| `get_status_payload()` | API prefix 하의 상태 응답 생성 함수 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `HLT-F001` | 루트 health probe를 조회한다 | CI Runner, Compose Runtime, External Monitor | Technical Health | `health_response()` | Query | FastAPI app이 기동 중이어야 한다 | `{"status":"ok"}` 응답을 반환한다 | 인증 없이 호출 가능해야 한다 |
-| `HLT-F002` | API status probe를 조회한다 | CI Runner, Compose Runtime, External Monitor | Technical Health | `get_status_payload()` | Query | API router가 정상 mount되어야 한다 | `{"service":"template-server","status":"healthy"}` 응답을 반환한다 | 인증 없이 호출 가능해야 한다 |
-
-## 7. Notes
-
-- `health`는 비즈니스 도메인이 아니라 technical bounded context지만, 운영/검증 contract를 위해 canonical feature spec에 포함한다.

package/sdd/01_planning/01_feature/inventory_feature_spec.md

@@ -1,60 +0,0 @@
-# inventory feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`inventory` bounded context가 제공하는 재고 조회와 관리자 재고 조정 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - SKU/거점 단위 재고 read model과 관리자 재고 mutation command
-  - 수동 조정, 선점, 해제, 절대값 설정 같은 inventory 내부 상태 변경
-- 제외 범위:
-  - 주문/이행 context가 자동으로 일으키는 재고 orchestration
-  - 창고 배차, 입고, 출고 작업 계획의 상세 workflow
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Admin Operator` | admin 서비스에서 재고 현황을 조회하고 조정, 선점, 해제, 재설정 같은 운영 명령을 수행하는 관리자다. | `INV-F001`, `INV-F002`, `INV-F003`, `INV-F004`, `INV-F005`, `INV-F006` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `INV` |
-| Bounded Context | Inventory Availability |
-| Primary Backend Owner | `server/contexts/inventory` |
-| Related Context | `auth`, `catalog`, `orders` |
-| Main Entry Contract | `GET /api/v1/inventory/levels`, `GET /api/v1/inventory/levels/{sku}/{location_id}`, `POST /api/v1/inventory/levels/{sku}/{location_id}/adjustments`, `POST /api/v1/inventory/levels/{sku}/{location_id}/reservations`, `POST /api/v1/inventory/levels/{sku}/{location_id}/releases`, `PUT /api/v1/inventory/levels/{sku}/{location_id}` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `InventoryLevelRecord` | SKU-거점별 재고 원본 |
-| `InventoryLevel` | 재고 조회 응답 모델 |
-| `AdjustInventoryCommand` | cycle count 등 수동 증감 명령 |
-| `ReserveInventoryCommand` | 주문 선점 명령 |
-| `ReleaseInventoryCommand` | 선점 해제 명령 |
-| `SetInventoryLevelCommand` | 절대값 설정 명령 |
-| `InventoryMutationReceipt` | 재고 조정 결과 응답 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `INV-F001` | 재고 레벨 목록을 조회한다 | Admin Operator | Inventory Availability | `InventoryLevel`, `InventoryLevelRecord` | Query | 관리자 토큰이 유효하고 inventory bootstrap 데이터가 존재해야 한다 | SKU, 상품, 거점, 상태 기준 재고 레벨 목록을 반환한다 | `status`는 `available_to_sell`과 `reorder_point` 계산 결과로 결정된다 |
-| `INV-F002` | 단일 SKU/거점 재고 상세를 조회한다 | Admin Operator | Inventory Availability | `InventoryLevel`, `InventoryLevelRecord` | Query | 관리자 토큰이 유효하고 요청한 `sku/location_id` 조합이 존재해야 한다 | 선택한 재고 레벨의 가용 재고와 재주문 여부를 반환한다 | 존재하지 않는 조합이면 `404 Inventory level not found`를 반환한다 |
-| `INV-F003` | 재고를 증감 조정한다 | Admin Operator | Inventory Availability | `AdjustInventoryCommand`, `InventoryMutationReceipt`, `InventoryLevelRecord` | Command | 관리자 토큰이 유효하고 요청한 재고 레벨이 존재해야 한다 | `on_hand`가 증감되고 조정 영수증을 반환한다 | delta는 0일 수 없고, 조정 후 `on_hand`는 `reserved`보다 작아질 수 없다 |
-| `INV-F004` | 재고를 선점한다 | Admin Operator | Inventory Availability | `ReserveInventoryCommand`, `InventoryMutationReceipt`, `InventoryLevelRecord` | Command | 관리자 토큰이 유효하고 요청한 재고 레벨이 존재해야 한다 | `reserved` 수량이 증가한다 | 선점 수량은 가용 재고를 초과할 수 없다 |
-| `INV-F005` | 선점된 재고를 해제한다 | Admin Operator | Inventory Availability | `ReleaseInventoryCommand`, `InventoryMutationReceipt`, `InventoryLevelRecord` | Command | 관리자 토큰이 유효하고 요청한 재고 레벨이 존재해야 한다 | `reserved` 수량이 감소한다 | 해제 수량은 현재 `reserved`를 초과할 수 없다 |
-| `INV-F006` | 재고 절대값을 재설정한다 | Admin Operator | Inventory Availability | `SetInventoryLevelCommand`, `InventoryMutationReceipt`, `InventoryLevelRecord` | Command | 관리자 토큰이 유효하고 요청한 재고 레벨이 존재해야 한다 | `on_hand`, `reserved`, `safety_stock`, `reorder_point`가 새 값으로 설정된다 | `reserved`는 `on_hand`보다 클 수 없다 |
-
-## 7. Notes
-
-- inventory는 현재 admin 전용 운영 컨텍스트다.
-- order/fulfillment에서 직접 inventory mutation을 일으키는 orchestration은 아직 없고, template baseline에서는 admin command로 먼저 노출한다.

package/sdd/01_planning/01_feature/order_feature_spec.md

@@ -1,63 +0,0 @@
-# order feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`orders` bounded context가 제공하는 web 주문 현황과 관리자 운영 큐 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - web 주문 overview/list read model과 주문 생성, 상태 전이 command
-  - admin 주문 overview/queue read model
-- 제외 범위:
-  - 외부 결제 게이트웨이 정산이나 배송사 연동
-  - 비동기 이벤트 버스 기반 후속 orchestration
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Web User` | web 서비스에서 주문 현황을 조회하고 신규 주문 생성이나 주문 상태 갱신을 수행하는 운영 사용자다. | `ORD-F001`, `ORD-F002`, `ORD-F003`, `ORD-F004` |
-| `Admin Operator` | admin 서비스에서 주문 KPI와 운영 큐를 모니터링하는 관리자다. | `ORD-F005`, `ORD-F006` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `ORD` |
-| Bounded Context | Order Operations |
-| Primary Backend Owner | `server/contexts/orders` |
-| Related Context | `auth`, `catalog`, `fulfillment` |
-| Main Entry Contract | `GET /api/v1/orders/overview`, `GET /api/v1/orders`, `POST /api/v1/orders`, `PATCH /api/v1/orders/{order_id}/status`, `GET /api/v1/orders/admin/overview`, `GET /api/v1/orders/admin/queue` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `OrderRecord` | bootstrap 기반 주문 원본 |
-| `OrderOverview` | web dashboard 요약 읽기 모델 |
-| `OrderSummary` | web orders 목록 읽기 모델 |
-| `CreateOrderCommand` | 주문 생성 명령 |
-| `UpdateOrderStatusCommand` | 주문 상태 전이 명령 |
-| `OrderStatusTransition` | 주문 상태 전이 결과 |
-| `AdminOrderOverview` | 관리자 운영 요약 읽기 모델 |
-| `AdminQueueItem` | 관리자 거래 큐 읽기 모델 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ORD-F001` | web 주문 overview를 조회한다 | Web User | Order Operations | `OrderOverview`, `OrderRecord` | Query | 인증 토큰이 유효하고 주문 bootstrap 데이터가 존재해야 한다 | 주문 카드, 최근 활동, 선택 주문 상세를 함께 반환한다 | overview는 최근 활동 3건과 선택 주문 1건을 항상 포함한다 |
-| `ORD-F002` | web 주문 목록을 조회한다 | Web User | Order Operations | `OrderSummary`, `OrderRecord` | Query | 인증 토큰이 유효하고 주문 bootstrap 데이터가 존재해야 한다 | 주문 목록을 반환한다 | 목록 행은 `id`, `product_name`, `customer_name`, `status`를 유지한다 |
-| `ORD-F003` | 신규 주문을 생성한다 | Web User | Order Operations | `CreateOrderCommand`, `OrderRecord` | Command | 인증 토큰이 유효하고 제품, 고객, 판매자, 금액 정보가 전달되어야 한다 | 새 `OrderRecord`가 생성되어 목록과 overview에 반영된다 | 새 주문은 문자열 ID를 부여받고 `Pending`과 `Queued`를 기본 상태로 사용한다 |
-| `ORD-F004` | 주문의 결제/이행 상태를 변경한다 | Web User | Order Operations | `UpdateOrderStatusCommand`, `OrderStatusTransition`, `OrderRecord` | Command | 인증 토큰이 유효하고 요청한 `order_id`가 존재해야 한다 | 주문의 `status`, `fulfillment_status`, `stage`가 변경된다 | 존재하지 않는 `order_id`면 `404`를 반환한다 |
-| `ORD-F005` | 관리자용 주문 overview를 조회한다 | Admin Operator | Order Operations | `AdminOrderOverview`, `OrderRecord` | Query | 관리자 토큰이 유효하고 주문 bootstrap 데이터가 존재해야 한다 | 관리자 KPI와 stage 현황을 반환한다 | admin surface는 web surface와 다른 운영형 read model을 사용한다 |
-| `ORD-F006` | 관리자용 거래 큐를 조회한다 | Admin Operator | Order Operations | `AdminQueueItem`, `OrderRecord` | Query | 관리자 토큰이 유효하고 주문 bootstrap 데이터가 존재해야 한다 | 주문별 운영 큐 행을 반환한다 | 큐 행은 `order_id`, `product_name`, `customer_name`, `status`, `sla`를 유지한다 |
-
-## 7. Notes
-
-- `orders`는 web surface와 admin surface에 서로 다른 read model을 제공한다.
-- 운영 알람 feed는 별도 `alerts` context가 소유하고, `orders`는 주문 자체 read/write 모델만 유지한다.
-- template baseline의 주문 상태 전이는 내부 mutation semantics까지만 다루며 외부 결제/이벤트 연동은 포함하지 않는다.

package/sdd/01_planning/01_feature/shipping_feature_spec.md

@@ -1,55 +0,0 @@
-# shipping feature spec
-
-- 작성 버전: 1.0.0
-
-## 1. Purpose
-
-`shipping` bounded context가 제공하는 배송 추적 overview와 shipment 상태 전이 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - mobile/operator surface에서 배송 현황 overview와 shipment 목록 조회
-  - shipment 상태 전이와 마지막 배송 이벤트 갱신
-- 제외 범위:
-  - 외부 택배사 webhook, 실시간 위치 추적, 고객 알림 발송
-  - 결제 승인이나 재고 선점 같은 upstream orchestration
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Mobile Operator` | mobile 서비스에서 출고 이후 배송 상태를 추적하고 shipment 진행 상태를 갱신하는 운영자다. | `SHP-F001`, `SHP-F002`, `SHP-F003` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `SHP` |
-| Bounded Context | Shipping Operations |
-| Primary Backend Owner | `server/contexts/shipping` |
-| Related Context | `orders`, `fulfillment` |
-| Main Entry Contract | `GET /api/v1/shipping/overview`, `GET /api/v1/shipping/shipments`, `PATCH /api/v1/shipping/shipments/{shipment_id}/status` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `ShipmentRecord` | 배송 원본 저장 모델 |
-| `ShippingOverview` | 배송 overview 응답 모델 |
-| `ShipmentSummary` | 배송 목록 응답 모델 |
-| `UpdateShipmentStatusCommand` | 배송 상태 전이 명령 |
-| `ShipmentStatusTransition` | 배송 상태 전이 결과 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `SHP-F001` | 배송 overview를 조회한다 | Mobile Operator | Shipping Operations | `ShippingOverview`, `ShipmentRecord` | Query | 인증 토큰이 유효하고 shipment bootstrap 데이터가 존재해야 한다 | 배송 중, 지연, 오늘 완료 건수와 carrier 현황을 반환한다 | overview 집계는 shipment 원본을 변경하지 않는다 |
-| `SHP-F002` | 배송 shipment 목록을 조회한다 | Mobile Operator | Shipping Operations | `ShipmentSummary`, `ShipmentRecord` | Query | 인증 토큰이 유효하고 shipment bootstrap 데이터가 존재해야 한다 | 배송 목록과 최신 이벤트를 반환한다 | 목록 행은 `shipment_id`, `order_id`, `carrier`, `status`, `eta`를 유지한다 |
-| `SHP-F003` | 배송 상태를 갱신한다 | Mobile Operator | Shipping Operations | `UpdateShipmentStatusCommand`, `ShipmentStatusTransition`, `ShipmentRecord` | Command | 인증 토큰이 유효하고 요청한 `shipment_id`가 존재해야 한다 | shipment의 `status`, `last_event`, 선택적 `eta`가 갱신된다 | 존재하지 않는 `shipment_id`면 `404`를 반환한다 |
-
-## 7. Notes
-
-- `shipping`은 출고 이후 배송 추적 책임을 `fulfillment`에서 분리해 downstream delivery 상태만 소유한다.
-- 고객-facing tracking 경험은 아직 포함하지 않고 operator/mobile surface만 baseline으로 제공한다.

package/sdd/01_planning/01_feature/support_feature_spec.md

@@ -1,53 +0,0 @@
-# support feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`support` bounded context가 제공하는 관리자 FAQ/support 관리 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - admin surface에서 FAQ/support 항목 목록 조회
-  - FAQ 작성과 visibility 변경 command
-- 제외 범위:
-  - end-user 문의 inbox나 대화형 support workflow
-  - notification, ticket assignment 같은 별도 support operations
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Admin Operator` | admin 서비스에서 FAQ/support 콘텐츠를 조회하고 등록하거나 공개 상태를 바꾸는 운영 관리자다. | `SUP-F001`, `SUP-F002`, `SUP-F003` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `SUP` |
-| Bounded Context | Support Content |
-| Primary Backend Owner | `server/contexts/support` |
-| Related Context | `auth` |
-| Main Entry Contract | `GET /api/v1/support/faqs`, `POST /api/v1/support/faqs`, `PATCH /api/v1/support/faqs/{faq_id}/visibility` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `SupportFaq` | FAQ/support 항목 읽기 모델 |
-| `SupportFaqRecord` | FAQ 저장/수정 결과 모델 |
-| `CreateSupportFaqCommand` | FAQ 작성 명령 |
-| `ChangeFaqVisibilityCommand` | FAQ 공개 상태 변경 명령 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `SUP-F001` | FAQ/support 목록을 조회한다 | Admin Operator | Support Content | `SupportFaq`, `SupportFaqRecord` | Query | 관리자 토큰이 유효하고 support bootstrap 데이터가 존재해야 한다 | 질문과 visibility가 포함된 FAQ 목록을 반환한다 | admin support surface는 질문 목록과 visibility를 같은 read model로 유지한다 |
-| `SUP-F002` | FAQ 항목을 새로 등록한다 | Admin Operator | Support Content | `CreateSupportFaqCommand`, `SupportFaqRecord` | Command | 관리자 토큰이 유효하고 question, answer가 전달되어야 한다 | 새 FAQ 레코드가 생성되어 목록에 추가된다 | 새 FAQ는 문자열 ID와 `updated_at`을 갖는다 |
-| `SUP-F003` | FAQ 노출 상태를 변경한다 | Admin Operator | Support Content | `ChangeFaqVisibilityCommand`, `SupportFaqRecord` | Command | 관리자 토큰이 유효하고 요청한 `faq_id`가 존재해야 한다 | FAQ의 `visibility`가 새 값으로 갱신된다 | 존재하지 않는 `faq_id`면 `404`를 반환한다 |
-
-## 7. Notes
-
-- 현재 `support`는 FAQ 중심 운영 content context이고, create/visibility change만 command surface로 제공한다.

package/sdd/01_planning/01_feature/user_feature_spec.md

@@ -1,54 +0,0 @@
-# user feature spec
-
-- 작성 버전: 1.1.0
-
-## 1. Purpose
-
-`user` bounded context가 제공하는 사용자 디렉터리 조회와 상태 변경 기능을 구현 기준으로 정리한다.
-
-## 2. Scope
-
-- 포함 범위:
-  - admin surface에서 사용자 목록/상세 조회
-  - 사용자 운영 상태 변경 command
-- 제외 범위:
-  - 로그인, 세션 발급, credential 검증
-  - end-user 자기 프로필 수정 같은 self-service profile workflow
-
-## 3. Actor Summary
-
-| Actor | Description | Appears In |
-| --- | --- | --- |
-| `Admin Operator` | admin 서비스에서 사용자 디렉터리를 조회하고 운영 상태를 변경하는 관리자다. | `USR-F001`, `USR-F002`, `USR-F003` |
-
-## 4. Bounded Context Summary
-
-| Item | Value |
-| --- | --- |
-| Domain Code | `USR` |
-| Bounded Context | User Directory |
-| Primary Backend Owner | `server/contexts/user` |
-| Related Context | `auth` |
-| Main Entry Contract | `GET /api/v1/users`, `GET /api/v1/users/{user_id}`, `PATCH /api/v1/users/{user_id}/status` |
-
-## 5. Aggregate / Model Snapshot
-
-| Aggregate / Model | Role |
-| --- | --- |
-| `UserRecord` | profile 저장 모델 |
-| `UserSummary` | 사용자 목록 응답 모델 |
-| `UserDetail` | 단일 사용자 상세 응답 모델 |
-| `UpdateUserStatusCommand` | 사용자 상태 전이 명령 |
-
-## 6. Use Case Matrix
-
-| Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
-| --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `USR-F001` | 사용자 summary 목록을 조회한다 | Admin Operator | User Directory | `UserSummary`, `UserRecord` | Query | 관리자 토큰이 유효하고 사용자 bootstrap 데이터가 존재해야 한다 | 사용자 목록을 반환한다 | 목록 행은 `id`, `name`, `email`, `role`, `status`를 유지한다 |
-| `USR-F002` | 단일 사용자 상세를 조회한다 | Admin Operator | User Directory | `UserDetail`, `UserRecord` | Query | 관리자 토큰이 유효하고 요청한 `user_id`가 저장소에 존재해야 한다 | timezone과 last login이 포함된 상세를 반환한다 | 존재하지 않는 `user_id`면 `404 User not found`를 반환한다 |
-| `USR-F003` | 사용자의 운영 상태를 변경한다 | Admin Operator | User Directory | `UpdateUserStatusCommand`, `UserDetail`, `UserRecord` | Command | 관리자 토큰이 유효하고 요청한 `user_id`가 저장소에 존재해야 한다 | 대상 사용자의 `status`가 새 값으로 갱신된다 | 존재하지 않는 `user_id`면 `404 User not found`를 반환한다 |
-
-## 7. Notes
-
-- `user`는 profile directory context이고 credential hash를 소유하지 않는다.
-- 인증 credential은 `auth` context가 별도 bootstrap 저장소로 관리한다.

package/sdd/01_planning/02_screen/INDEX.md

@@ -1,13 +0,0 @@
-# Screen Planning
-
-- screen code format: `{SERVICE}-S{NNN}`
-- canonical service code: `WEB`, `ADM`, `MOB`, `LND`
-
-- [web_screen_spec.pdf](./web_screen_spec.pdf)
-- [admin_screen_spec.pdf](./admin_screen_spec.pdf)
-- [mobile_screen_spec.pdf](./mobile_screen_spec.pdf)
-- [landing_screen_spec.pdf](./landing_screen_spec.pdf)
-
-화면 코드와 기능 설명은 각 PDF 상세 페이지의 우측 테이블을 canonical surface로 사용한다.
-build source, capture asset, generator는 `sdd/99_toolchain/01_automation` 아래에 둔다.
-`MOB-S003`의 canonical route는 `/fulfillment`이고, landing catalog proof는 `GET /api/v1/catalog/products`를 기준으로 한다.

package/sdd/01_planning/02_screen/README.md

@@ -1,41 +0,0 @@
-# Screen Planning
-
-## Naming
-
-- Folder name: `02_screen`
-- Canonical artifact: `{service}_screen_spec.pdf`
-- Source-of-truth screen spec files are service based.
-
-## Code Rule
-
-- Screen code format: `{SERVICE}-S{NNN}`
-- 각 segment는 고정 길이로 유지한다.
-
-| Segment | Rule | Example |
-| --- | --- | --- |
-| `SERVICE` | 3-letter uppercase service code | `WEB`, `ADM`, `MOB`, `LND` |
-| `TYPE` | screen 식별자 고정값 | `S` |
-| `NNN` | 3-digit sequence | `001`, `002` |
-
-## Canonical Output
-
-- [web_screen_spec.pdf](./web_screen_spec.pdf)
-- [admin_screen_spec.pdf](./admin_screen_spec.pdf)
-- [mobile_screen_spec.pdf](./mobile_screen_spec.pdf)
-- [landing_screen_spec.pdf](./landing_screen_spec.pdf)
-
-## Rule
-
-- screen spec은 서비스 surface 기준 산출물이다.
-- route, UI block, CTA, interaction, transition은 screen spec PDF 안에서 관리한다.
-- build source, capture asset, generator는 `sdd/99_toolchain/01_automation` 아래에 둔다.
-- reusable asset planning 산출물은 `sdd/01_planning/02_screen/assets/` 아래에 둔다.
-- data 모델링 상세는 `04_data`에서 다루고, architecture/system boundary는 `03_architecture`에서 다룬다.
-- screen spec에서 파생되는 로고/일러스트 등 재사용 자산은 generic asset recipe generator로 재생성 가능해야 한다.
-
-## Toolchain
-
-- generic asset recipe generator (`스펙에셋빌더`): [`spec_asset_builder.py`](../../99_toolchain/01_automation/spec_asset_builder.py)
-- compatibility wrapper: [`build_asset_recipes.py`](../../99_toolchain/01_automation/build_asset_recipes.py)
-- example recipe manifest: [`asset_recipe_manifest.example.py`](../../99_toolchain/03_templates/asset_recipe_manifest.example.py)
-- asset planning root example: [`assets/README.md`](assets/README.md)