agentic-dev 0.2.3 → 0.2.6

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

@@ -19,7 +19,7 @@
 
 | Actor | Description | Appears In |
 | --- | --- | --- |
-| `Platform User` | platform 서비스에서 주문/운영 기능에 접근하기 위해 인증 세션을 발급받는 사용자다. | `AUT-F001` |
+| `Web User` | web 서비스에서 주문/운영 기능에 접근하기 위해 인증 세션을 발급받는 사용자다. | `AUT-F001` |
 | `Mobile Operator` | mobile 서비스에서 이행 작업을 수행하기 위해 로그인하는 현장 운영자다. | `AUT-F001` |
 | `Admin Operator` | admin 서비스에서 카탈로그, 재고, 사용자 운영 명령을 수행하기 위해 관리자 세션을 발급받는 주체다. | `AUT-F001` |
 | `Landing Member` | landing 서비스에서 회원 전용 자원이나 개인화 동작을 사용하기 위해 로그인하는 사용자다. | `AUT-F001` |
@@ -48,7 +48,7 @@
 
 | Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `AUT-F001` | 이메일/비밀번호로 로그인하고 access token을 발급한다 | Platform User, Mobile Operator, Admin Operator, Landing Member | Authentication & Session | `LoginCommand`, `AuthToken`, `AuthAccountRecord` | Command | 이메일과 비밀번호가 전달되고, 인증 계정 저장소에 해당 사용자가 존재해야 한다 | access token과 `user_id`가 발급된다 | credential이 일치하지 않으면 `401 Invalid credentials`를 반환한다 |
+| `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

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

@@ -21,7 +21,7 @@
 | --- | --- | --- |
 | `Landing Visitor` | 비로그인 상태로 공개 상품 카탈로그와 상품 상세를 탐색하는 방문자다. | `CAT-F001`, `CAT-F002` |
 | `Landing Member` | 로그인된 landing 회원으로 공개 상품을 둘러보고 구매 전 탐색을 수행하는 사용자다. | `CAT-F001`, `CAT-F002` |
-| `Platform User` | platform 서비스에서 주문 생성이나 운영 판단을 위해 상품 정보를 조회하는 내부 사용자다. | `CAT-F001`, `CAT-F002` |
+| `Web User` | web 서비스에서 주문 생성이나 운영 판단을 위해 상품 정보를 조회하는 내부 사용자다. | `CAT-F001`, `CAT-F002` |
 | `Admin Operator` | admin 서비스에서 상품을 등록, 수정, 상태 변경하는 운영 관리자다. | `CAT-F003`, `CAT-F004`, `CAT-F005` |
 
 ## 4. Bounded Context Summary
@@ -49,8 +49,8 @@
 
 | Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `CAT-F001` | 상품 카탈로그 목록을 조회한다 | Landing Visitor, Landing Member, Platform User | Product Catalog | `ProductSummary`, `ProductRecord` | Query | 상품 bootstrap 데이터가 존재해야 한다 | 공개 가능한 상품 목록을 필터와 검색 조건에 맞게 반환한다 | `status`, `category`, `q` 조건은 모두 현재 카탈로그 집합 안에서 계산한다 |
-| `CAT-F002` | 단일 상품 상세를 조회한다 | Landing Visitor, Landing Member, Platform User | Product Catalog | `ProductDetail`, `ProductRecord` | Query | 요청한 `product_id`가 저장소에 존재해야 한다 | 상세 페이지 구성을 위한 상품 전체 속성을 반환한다 | 존재하지 않는 `product_id`면 `404 Catalog product not found`를 반환한다 |
+| `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`를 반환한다 |

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

@@ -4,12 +4,12 @@
 
 ## 1. Purpose
 
-`orders` bounded context가 제공하는 플랫폼 주문 현황과 관리자 운영 큐 기능을 구현 기준으로 정리한다.
+`orders` bounded context가 제공하는 web 주문 현황과 관리자 운영 큐 기능을 구현 기준으로 정리한다.
 
 ## 2. Scope
 
 - 포함 범위:
-  - platform 주문 overview/list read model과 주문 생성, 상태 전이 command
+  - web 주문 overview/list read model과 주문 생성, 상태 전이 command
   - admin 주문 overview/queue read model
 - 제외 범위:
   - 외부 결제 게이트웨이 정산이나 배송사 연동
@@ -19,7 +19,7 @@
 
 | Actor | Description | Appears In |
 | --- | --- | --- |
-| `Platform User` | platform 서비스에서 주문 현황을 조회하고 신규 주문 생성이나 주문 상태 갱신을 수행하는 운영 사용자다. | `ORD-F001`, `ORD-F002`, `ORD-F003`, `ORD-F004` |
+| `Web User` | web 서비스에서 주문 현황을 조회하고 신규 주문 생성이나 주문 상태 갱신을 수행하는 운영 사용자다. | `ORD-F001`, `ORD-F002`, `ORD-F003`, `ORD-F004` |
 | `Admin Operator` | admin 서비스에서 주문 KPI와 운영 큐를 모니터링하는 관리자다. | `ORD-F005`, `ORD-F006` |
 
 ## 4. Bounded Context Summary
@@ -37,8 +37,8 @@
 | Aggregate / Model | Role |
 | --- | --- |
 | `OrderRecord` | bootstrap 기반 주문 원본 |
-| `OrderOverview` | 플랫폼 dashboard 요약 읽기 모델 |
-| `OrderSummary` | 플랫폼 orders 목록 읽기 모델 |
+| `OrderOverview` | web dashboard 요약 읽기 모델 |
+| `OrderSummary` | web orders 목록 읽기 모델 |
 | `CreateOrderCommand` | 주문 생성 명령 |
 | `UpdateOrderStatusCommand` | 주문 상태 전이 명령 |
 | `OrderStatusTransition` | 주문 상태 전이 결과 |
@@ -49,15 +49,15 @@
 
 | Feature Code | Use Case | Actor | Bounded Context | Aggregate / Model | Type | Preconditions | Domain Outcome | Invariant / Business Rule |
 | --- | --- | --- | --- | --- | --- | --- | --- | --- |
-| `ORD-F001` | 플랫폼 주문 overview를 조회한다 | Platform User | Order Operations | `OrderOverview`, `OrderRecord` | Query | 인증 토큰이 유효하고 주문 bootstrap 데이터가 존재해야 한다 | 주문 카드, 최근 활동, 선택 주문 상세를 함께 반환한다 | overview는 최근 활동 3건과 선택 주문 1건을 항상 포함한다 |
-| `ORD-F002` | 플랫폼 주문 목록을 조회한다 | Platform User | Order Operations | `OrderSummary`, `OrderRecord` | Query | 인증 토큰이 유효하고 주문 bootstrap 데이터가 존재해야 한다 | 주문 목록을 반환한다 | 목록 행은 `id`, `product_name`, `customer_name`, `status`를 유지한다 |
-| `ORD-F003` | 신규 주문을 생성한다 | Platform User | Order Operations | `CreateOrderCommand`, `OrderRecord` | Command | 인증 토큰이 유효하고 제품, 고객, 판매자, 금액 정보가 전달되어야 한다 | 새 `OrderRecord`가 생성되어 목록과 overview에 반영된다 | 새 주문은 문자열 ID를 부여받고 `Pending`과 `Queued`를 기본 상태로 사용한다 |
-| `ORD-F004` | 주문의 결제/이행 상태를 변경한다 | Platform 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는 platform surface와 다른 운영형 read model을 사용한다 |
+| `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`는 platform surface와 admin surface에 서로 다른 read model을 제공한다.
+- `orders`는 web surface와 admin surface에 서로 다른 read model을 제공한다.
 - 운영 알람 feed는 별도 `alerts` context가 소유하고, `orders`는 주문 자체 read/write 모델만 유지한다.
 - template baseline의 주문 상태 전이는 내부 mutation semantics까지만 다루며 외부 결제/이벤트 연동은 포함하지 않는다.

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

@@ -1,9 +1,9 @@
 # Screen Planning
 
 - screen code format: `{SERVICE}-S{NNN}`
-- canonical service code: `PLT`, `ADM`, `MOB`, `LND`
+- canonical service code: `WEB`, `ADM`, `MOB`, `LND`
 
-- [platform_screen_spec.pdf](./platform_screen_spec.pdf)
+- [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)

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

@@ -13,13 +13,13 @@
 
 | Segment | Rule | Example |
 | --- | --- | --- |
-| `SERVICE` | 3-letter uppercase service code | `PLT`, `ADM`, `MOB`, `LND` |
+| `SERVICE` | 3-letter uppercase service code | `WEB`, `ADM`, `MOB`, `LND` |
 | `TYPE` | screen 식별자 고정값 | `S` |
 | `NNN` | 3-digit sequence | `001`, `002` |
 
 ## Canonical Output
 
-- [platform_screen_spec.pdf](./platform_screen_spec.pdf)
+- [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)

package/sdd/01_planning/03_architecture/templates_system_architecture.md

@@ -16,7 +16,7 @@
 | Layer | Owner | Responsibility |
 | --- | --- | --- |
 | `server` | HTTP backend | auth, user, catalog, inventory, orders, fulfillment, shipping, alerts, support, health를 HTTP API surface로 제공 |
-| `client/platform` | React + Vite frontend | 보호된 플랫폼 shell과 dashboard/orders surface |
+| `client/web` | React + Vite frontend | 보호된 web shell과 dashboard/orders surface |
 | `client/admin` | React + Vite frontend | 보호된 관리자 shell과 overview/queue/support surface |
 | `client/mobile` | React + Vite frontend | 보호된 모바일 shell과 dashboard/fulfillment surface |
 | `client/landing` | React + Vite frontend | public landing + protected workspace surface |
@@ -36,7 +36,7 @@
 | User Directory | `server/contexts/user` | 사용자 profile 목록/상세/상태 관리 |
 | Product Catalog | `server/contexts/catalog` | public catalog read와 admin catalog write |
 | Inventory Availability | `server/contexts/inventory` | SKU/거점 재고 조회와 운영 mutation |
-| Order Operations | `server/contexts/orders` | platform/admin 주문 overview, 목록, 생성, 상태 전이 |
+| Order Operations | `server/contexts/orders` | web/admin 주문 overview, 목록, 생성, 상태 전이 |
 | Fulfillment Operations | `server/contexts/fulfillment` | mobile overview, board, task 상태 전이 |
 | Shipping Operations | `server/contexts/shipping` | mobile 배송 overview, shipment 목록, 배송 상태 전이 |
 | Alert Center | `server/contexts/alerts` | admin 운영 알람 feed, 읽음 처리 |
@@ -49,7 +49,7 @@
 - `user`는 profile directory만 소유하고 credential hash를 저장하지 않는다.
 - `catalog`는 landing/public read와 admin write surface를 함께 소유한다.
 - `inventory`는 현재 admin 운영 surface를 통해 직접 조정되고, `orders`와 `fulfillment`의 참조 도메인으로 연결된다.
-- `orders`는 platform read model과 admin read model을 동시에 노출한다.
+- `orders`는 web read model과 admin read model을 동시에 노출한다.
 - `fulfillment`는 mobile 서비스의 canonical backend surface다.
 - `shipping`은 `fulfillment`의 downstream delivery 상태를 분리해 mobile/operator surface에 제공한다.
 - `alerts`는 admin이 소비하는 운영 알람 표현과 읽음 상태를 별도 context로 소유한다.

package/sdd/01_planning/05_api/templates_api_contract.md

@@ -28,8 +28,8 @@
 | `POST` | `/api/v1/inventory/levels/{sku}/{location_id}/reservations` | inventory | 재고 선점 | `InventoryMutationReceipt` |
 | `POST` | `/api/v1/inventory/levels/{sku}/{location_id}/releases` | inventory | 재고 선점 해제 | `InventoryMutationReceipt` |
 | `PUT` | `/api/v1/inventory/levels/{sku}/{location_id}` | inventory | 재고 절대값 재설정 | `InventoryMutationReceipt` |
-| `GET` | `/api/v1/orders/overview` | orders | platform dashboard overview 조회 | `OrderOverview` |
-| `GET` | `/api/v1/orders` | orders | platform order table row 조회 | `list[OrderSummary]` |
+| `GET` | `/api/v1/orders/overview` | orders | web dashboard overview 조회 | `OrderOverview` |
+| `GET` | `/api/v1/orders` | orders | web order table row 조회 | `list[OrderSummary]` |
 | `POST` | `/api/v1/orders` | orders | 주문 생성 | `OrderRecord` |
 | `PATCH` | `/api/v1/orders/{order_id}/status` | orders | 주문 상태 전이 | `OrderStatusTransition` |
 | `GET` | `/api/v1/orders/admin/overview` | orders | admin dashboard 운영 overview 조회 | `AdminOrderOverview` |
@@ -68,7 +68,7 @@
 
 ## 4. Frontend Binding Notes
 
-- `client/platform`
+- `client/web`
   - `/`는 `GET /api/v1/orders/overview`를 소비한다.
   - `/orders`는 `GET /api/v1/orders`를 소비한다.
 - `client/admin`

package/sdd/01_planning/06_iac/templates_runtime_and_cicd_baseline.md

@@ -11,7 +11,7 @@
 | Surface | Default Port |
 | --- | --- |
 | landing | `3000` |
-| platform | `3001` |
+| web | `3001` |
 | mobile | `3002` |
 | admin | `4000` |
 | api | `8000` |

package/sdd/01_planning/07_integration/templates_frontend_api_integration.md

@@ -16,14 +16,14 @@
 
 | Service | Real Backend Coupling | Note |
 | --- | --- | --- |
-| platform | `auth`, `orders` | dashboard overview와 orders table을 live contract에 연결 |
+| web | `auth`, `orders` | dashboard overview와 orders table을 live contract에 연결 |
 | admin | `auth`, `orders`, `alerts`, `support` | overview/queue/support surface와 alerts drawer를 live contract에 연결 |
 | mobile | `auth`, `fulfillment`, `shipping` | dashboard overview와 fulfillment/shipping surface를 live contract에 연결 |
 | landing | `auth`, `catalog` | home/workspace에서 catalog products를 읽어 public/protected surface를 구성 |
 
 ## 3. Coupling Detail
 
-- platform
+- web
   - bearer session은 기존 `AuthProvider`가 유지한다.
   - page load 시 `orders/overview`, `orders`를 fetch하고 search는 client-side filter로 처리한다.
 - admin
@@ -41,6 +41,6 @@
 
 ## 4. Known Gaps
 
-- platform/admin은 아직 catalog/inventory command surface를 직접 소비하지 않는다.
+- web/admin은 아직 catalog/inventory command surface를 직접 소비하지 않는다.
 - order 생성, fulfillment 전이, shipping 전이, support create/update, alerts read는 backend contract로 존재하지만 frontend action UI는 baseline 최소 액션 중심이다.
 - landing은 catalog read를 public/protected दोनों surface에 재사용하지만 category/detail 분해까지는 아직 없다.

package/sdd/01_planning/10_test/templates_test_strategy.md

@@ -49,8 +49,8 @@ template baseline을 유지하기 위한 테스트 전략을 정의한다.
 
 ## 2. Frontend
 
-- `platform`, `admin`, `mobile`, `landing`는 각 서비스별 production build를 통과해야 한다.
-- screen spec은 `PLT-S001`, `ADM-S001`, `MOB-S001`, `LND-S001` 규칙으로 구현 route와 관련 feature를 함께 검증한다.
+- `web`, `admin`, `mobile`, `landing`는 각 서비스별 production build를 통과해야 한다.
+- screen spec은 `WEB-S001`, `ADM-S001`, `MOB-S001`, `LND-S001` 규칙으로 구현 route와 관련 feature를 함께 검증한다.
 - parity harness가 활성화되면 route-gap과 proof artifact를 추가 검증한다.
 
 ## 3. CI Gate

package/sdd/01_planning/INDEX.md

@@ -13,7 +13,7 @@
 
 ## Structure Rule
 
-- `01_feature`, `02_screen`는 실제 서비스 표면(`platform`, `mobile`, `admin`, `landing`) 기준으로 유지한다.
+- `01_feature`, `02_screen`는 실제 서비스 표면(`web`, `mobile`, `admin`, `landing`) 기준으로 유지한다.
 - `03_architecture` 이후는 서비스별 실산출물이 없으면 common-first로 유지한다.
 - `03_architecture`는 공통 문서를 먼저 두고 필요 시 `frontend/`, `backend/`, `infra/`, `tech-research/`로 세분화한다.
 - 데이터 모델링은 `04_data`에서 다루고 architecture 문서에는 중복 기록하지 않는다.

package/sdd/02_plan/02_screen/INDEX.md

@@ -3,7 +3,7 @@
 ## Canonical Sources
 
 - [mobile_screen_spec.pdf](../../01_planning/02_screen/mobile_screen_spec.pdf)
-- [platform_screen_spec.pdf](../../01_planning/02_screen/platform_screen_spec.pdf)
+- [web_screen_spec.pdf](../../01_planning/02_screen/web_screen_spec.pdf)
 - [admin_screen_spec.pdf](../../01_planning/02_screen/admin_screen_spec.pdf)
 - [landing_screen_spec.pdf](../../01_planning/02_screen/landing_screen_spec.pdf)
 

package/sdd/02_plan/02_screen/README.md

@@ -19,7 +19,7 @@
 - 서비스별 화면 TODO는 `sdd/02_plan/02_screen/` root에 둔다.
 - 예:
   - `sdd/02_plan/02_screen/mobile_todos.md`
-  - `sdd/02_plan/02_screen/platform_todos.md`
+  - `sdd/02_plan/02_screen/web_todos.md`
 
 ## Naming
 

package/sdd/02_plan/03_architecture/build_ast_runtime_tree_governance.md

@@ -23,7 +23,7 @@
 ## Acceptance Criteria
 
 - [x] `scripts/dev/audit_sdd_build_ast.py`가 `ast_similarity=10`, `implementation_traceability=10`, `human_agent_readability=10`을 반환한다.
-- [x] `mobile`, `platform`, `admin`, `landing` service summary가 실제 `main.tsx -> AuthProvider -> BrowserRouter -> App -> ProtectedRoute/shell -> route leaf` 체인을 반영한다.
+- [x] `mobile`, `web`, `admin`, `landing` service summary가 실제 `main.tsx -> AuthProvider -> BrowserRouter -> App -> ProtectedRoute/shell -> route leaf` 체인을 반영한다.
 - [x] `README`, `AGENTS`, `CLAUDE`, toolchain policy가 `.agent`, role agent, skill alias, AST current-state 규칙을 같이 설명한다.
 - [x] template infra 문서는 provider-first baseline(`aws/data`, `aws/domain`, `openstack/server`)을 current canonical split으로 설명한다.
 

package/sdd/02_plan/03_architecture/repository_governance.md

@@ -27,7 +27,7 @@
 ## Current Notes
 
 - `main`을 canonical branch로 유지하는 규칙을 사용한다.
-- 템플릿 frontend 경로는 `client/platform`, `client/admin`, `client/mobile`, `client/landing` 기준이다.
+- 템플릿 frontend 경로는 `client/web`, `client/admin`, `client/mobile`, `client/landing` 기준이다.
 - SDD는 최종 일관성 문서만 유지하고, raw 운영 로그는 runtime logging system에 남긴다.
 - data modeling 계획 루트는 `sdd/01_planning/04_data`와 `sdd/02_plan/04_data`를 기준으로 유지한다.
 
@@ -36,4 +36,4 @@
 - current references:
   - `AGENTS.md`
   - `sdd/03_build/03_architecture/repository_governance.md`
-  - `sdd/04_verify/03_architecture/repository_governance.md`
+  - `sdd/03_verify/03_architecture/repository_governance.md`

package/sdd/02_plan/03_architecture/runtime_and_structure_governance.md

@@ -35,4 +35,4 @@
 - current references:
   - `sdd/01_planning/README.md`
   - `sdd/03_build/03_architecture/repository_governance.md`
-  - `sdd/04_verify/03_architecture/repository_governance.md`
+  - `sdd/03_verify/03_architecture/repository_governance.md`

package/sdd/02_plan/03_architecture/toolchain_governance.md

@@ -61,7 +61,7 @@
 - toolchain은 `sdd/99_toolchain/01_automation`, `02_policies`, `03_templates` current split을 따른다.
 - Playwright local exactness는 `run_playwright_exactness.py`와 `playwright_exactness_manifest.py`를 canonical entrypoint로 사용한다.
 - screen 작업은 가능하면 `npx playwright test ...`를 직접 쓰지 않고 toolchain runner를 통해 suite id 기준으로 실행한다.
-- proof artifact는 `sdd/04_verify/10_test/ui_parity/` current path를 기준으로 관리한다.
+- proof artifact는 `sdd/03_verify/10_test/ui_parity/` current path를 기준으로 관리한다.
 - toolchain 정책 문서의 정본은 `sdd/99_toolchain/02_policies`에 둔다.
 - skill/tooling 사용 여부는 개별 dated memo가 아니라 현재 workflow rule로만 유지한다.
 - 화면명세서의 icon/image/logo 등 재사용 가능한 정적 자산은 `spec_asset_builder.py` 또는 wrapper를 먼저 사용해 추출하고, 수동 재작성은 builder가 표현하지 못하는 경우에만 예외로 허용한다.
@@ -93,6 +93,6 @@
   - `sdd/99_toolchain/01_automation/playwright_exactness_manifest.py`
   - `sdd/99_toolchain/01_automation/run_playwright_exactness.py`
   - `sdd/02_plan/10_test/verification_strategy.md`
-  - `sdd/04_verify/10_test/verification_harness.md`
+  - `sdd/03_verify/10_test/verification_harness.md`
   - `sdd/99_toolchain/02_policies/regression-verification-policy.md`
   - `sdd/02_plan/10_test/regression_verification.md`

package/sdd/02_plan/06_iac/dev_runtime_delivery.md

@@ -33,4 +33,4 @@
 
 - current references:
   - `sdd/03_build/06_iac/dev_runtime_delivery.md`
-  - `sdd/04_verify/06_iac/dev_runtime_delivery.md`
+  - `sdd/03_verify/06_iac/dev_runtime_delivery.md`

package/sdd/02_plan/07_integration/frontend_live_integration.md

@@ -6,7 +6,7 @@
 ## Scope
 
 - In scope:
-  - platform/admin/mobile/landing과 backend domain contract 연결 기준
+  - web/admin/mobile/landing과 backend domain contract 연결 기준
   - typed API helper와 current live wiring baseline
 
 ## Acceptance Criteria
@@ -16,7 +16,7 @@
 
 ## Current Notes
 
-- `platform`은 catalog/orders/support 중심 operator surface를 사용한다.
+- `web`은 catalog/orders/support 중심 operator surface를 사용한다.
 - `admin`은 alerts, catalog, orders 관리 surface를 사용한다.
 - `mobile`은 fulfillment, shipping 중심 surface를 사용한다.
 - `landing`은 catalog/public read surface를 사용한다.
@@ -25,7 +25,7 @@
 ## Validation
 
 - current references:
-  - `client/platform/src`
+  - `client/web/src`
   - `client/admin/src`
   - `client/mobile/src`
   - `client/landing/src`

package/sdd/02_plan/10_test/regression_verification.md

@@ -15,7 +15,7 @@
 ## Acceptance Criteria
 
 - [x] 회귀 검수는 direct target-only로 끝내지 않는다.
-- [x] selected regression surface는 `sdd/02_plan`, `sdd/03_build`, `sdd/04_verify`에 current-state로 이어진다.
+- [x] selected regression surface는 `sdd/02_plan`, `sdd/03_build`, `sdd/03_verify`에 current-state로 이어진다.
 - [x] automation gap은 scope 축소가 아니라 residual risk로 기록한다.
 
 ## Execution Checklist
@@ -36,4 +36,4 @@
   - `AGENTS.md`
   - `.codex/skills/sdd/SKILL.md`
   - `sdd/99_toolchain/01_automation/README.md`
-  - `sdd/04_verify/10_test/verification_harness.md`
+  - `sdd/03_verify/10_test/verification_harness.md`

package/sdd/02_plan/10_test/templates/{ui_parity_platform_contract.template.yaml → ui_parity_web_contract.template.yaml}

@@ -5,11 +5,11 @@ metadata:
   generated_by: sdd/99_toolchain/01_automation/ui-parity/cli/scaffold-contract.mjs
 spec:
   target_base_url: http://127.0.0.1:4301
-  adapter_path: client/platform/scripts/ui-parity-platform-adapter.mjs
+  adapter_path: client/web/scripts/ui-parity-web-adapter.mjs
 screens:
   - id: TMP_001
     route: /
-    reference_image: sdd/04_verify/10_test/ui_parity/reference/TMP_001.png
+    reference_image: sdd/03_verify/10_test/ui_parity/reference/TMP_001.png
     max_diff_ratio: 0
     allow_resize: false
     pixelmatch_threshold: 0.1

package/sdd/02_plan/10_test/verification_strategy.md

@@ -38,6 +38,6 @@
 ## Validation
 
 - current references:
-  - `sdd/04_verify/README.md`
-  - `sdd/04_verify/10_test/verification_harness.md`
+  - `sdd/03_verify/README.md`
+  - `sdd/03_verify/10_test/verification_harness.md`
   - `sdd/02_plan/10_test/regression_verification.md`

package/sdd/03_build/01_feature/domain/account_and_access.md

@@ -13,7 +13,7 @@
 ## Implementation Shape
 
 - backend owner는 `server/contexts/auth`, `server/contexts/user`다.
-- frontend surface는 `client/platform`, `client/admin`, `client/mobile`에서 공통 auth/session contract를 소비한다.
+- frontend surface는 `client/web`, `client/admin`, `client/mobile`에서 공통 auth/session contract를 소비한다.
 
 ## Current Behavior
 

package/sdd/03_build/01_feature/domain/catalog_and_inventory.md

@@ -8,7 +8,7 @@
 ## Implemented Scope
 
 - 상품/카탈로그와 재고 baseline은 `catalog`, `inventory` context로 분리되어 있다.
-- landing/platform surface는 catalog read model을, admin surface는 catalog/inventory 관리 contract를 사용한다.
+- landing/web surface는 catalog read model을, admin surface는 catalog/inventory 관리 contract를 사용한다.
 
 ## Implementation Shape
 

package/sdd/03_build/01_feature/domain/ordering_and_fulfillment.md

@@ -9,7 +9,7 @@
 ## Implemented Scope
 
 - 주문, 처리, 배송 baseline은 `orders`, `fulfillment`, `shipping` context로 분리되어 있다.
-- mobile/operator surface는 fulfillment/shipping read model을 사용하고, admin/platform은 order overview contract를 사용한다.
+- mobile/operator surface는 fulfillment/shipping read model을 사용하고, admin/web은 order overview contract를 사용한다.
 
 ## Implementation Shape
 

package/sdd/03_build/01_feature/service/README.md

@@ -1,3 +1,3 @@
 # Service Build Summaries
 
-- platform, admin, mobile, landing current implementation을 service baseline 기준으로 설명한다.
+- web, admin, mobile, landing current implementation을 service baseline 기준으로 설명한다.

package/sdd/03_build/01_feature/service/{platform_surface.md → web_surface.md}

@@ -1,4 +1,4 @@
-# Platform Surface
+# Web Surface
 
 ## Covered Planning Artifacts
 
@@ -8,7 +8,7 @@
 
 ## Implemented Scope
 
-- runtime root는 `client/platform/src/main.tsx -> AuthProvider -> BrowserRouter -> client/platform/src/app/App.tsx` 순서로 조립된다.
+- runtime root는 `client/web/src/main.tsx -> AuthProvider -> BrowserRouter -> client/web/src/app/App.tsx` 순서로 조립된다.
 - public leaf는 `LoginPage`이며, gated branch는 `ProtectedRoute -> AppShell` 뒤에 `/`와 `/orders` route leaf를 둔다.
 - route leaf는 `DashboardPage`, `OrdersPage`로 끝나고 backend leaf는 `server/main.py -> server/api/http/app.py -> server/api/http/router.py -> contexts/auth/contracts/http/router.py`, `contexts/catalog/contracts/http/router.py`, `contexts/orders/contracts/http/router.py` 체인으로 이어진다.
-- platform surface는 인증, catalog, orders baseline을 current runtime tree로 제공한다.
+- web surface는 인증, catalog, orders baseline을 current runtime tree로 제공한다.

package/sdd/03_build/02_screen/README.md

@@ -10,7 +10,7 @@
 
 - 예:
   - `sdd/03_build/02_screen/mobile/MOB-S001_example.md`
-  - `sdd/03_build/02_screen/platform/PLT-S001_example.md`
+  - `sdd/03_build/02_screen/web/WEB-S001_example.md`
 
 ## Recommended Sections
 

package/sdd/03_build/02_screen/web/README.md

@@ -0,0 +1,5 @@
+# Web Screen Build Summaries
+
+- current source: `sdd/01_planning/02_screen/web_screen_spec.pdf`
+- 이 폴더는 web screen별 build summary를 유지한다.
+- 현재 web baseline은 dashboard, catalog, orders surface를 기준으로 해석한다.

package/sdd/03_build/03_architecture/toolchain_governance.md

@@ -10,7 +10,7 @@
 - Playwright exactness runner/manifest를 local screen exactness의 canonical toolchain entrypoint로 추가했다.
 - `AGENTS.md`, `.codex/skills/sdd/SKILL.md`, `sdd/99_toolchain/01_automation/README.md`가 같은 회귀 검수 기준을 공유한다.
 - reusable asset planning root를 `sdd/01_planning/02_screen/assets/`로 정리하고, local Codex/Claude `sdd` skill에 같은 path를 반영했다.
-- `sdd/02_plan/10_test`, `sdd/03_build/10_test`, `sdd/04_verify/10_test`에 regression verification current-state 문서를 추가했다.
+- `sdd/02_plan/10_test`, `sdd/03_build/10_test`, `sdd/03_verify/10_test`에 regression verification current-state 문서를 추가했다.
 - `.claude/skills/sdd-dev/SKILL.md`의 stale Codex canonical path를 현재 `.codex/skills/sdd/` 구조로 교체했다.
 - `.codex/skills/sdd/SKILL.md`와 `.claude/skills/sdd-dev/SKILL.md`에서 DEV/PROD rollout gate를 explicit deployment scope 조건으로 제한했다.
 - 디자인 가이드 builder 안내는 고정 file path 대신 `sdd/99_toolchain/01_automation/README.md`와 실제 존재하는 builder inventory 기준으로 정리했다.

package/sdd/03_build/06_iac/template_runtime_delivery.md

@@ -34,7 +34,7 @@
 - `server/Dockerfile.dev`
 - `server/docker-entrypoint.sh`
 - `client/landing/Dockerfile.dev`
-- `client/platform/Dockerfile.dev`
+- `client/web/Dockerfile.dev`
 - `client/mobile/Dockerfile.dev`
 - `client/admin/Dockerfile.dev`
 - `infra/compose/dev.yml`

package/sdd/03_build/07_integration/frontend_live_integration.md

@@ -7,5 +7,5 @@
 ## Implemented Scope
 
 - service app은 backend domain contract와 typed API helper를 통해 연결된다.
-- landing/catalog, mobile/fulfillment-shipping, admin/alerts-orders, platform/catalog-orders-support 흐름을 current baseline으로 유지한다.
+- landing/catalog, mobile/fulfillment-shipping, admin/alerts-orders, web/catalog-orders-support 흐름을 current baseline으로 유지한다.
 - mobile template shared lib에 `useSpeechRecognitionInput.ts`를 추가해 browser Web Speech API 입력을 consumer screen에서 재사용할 수 있게 했다.

package/sdd/{04_verify → 03_verify}/01_feature/service_verification.md

@@ -2,11 +2,11 @@
 
 ## Scope
 
-- platform, admin, mobile, landing 서비스 surface의 현재 retained verification을 요약한다.
+- web, admin, mobile, landing 서비스 surface의 현재 retained verification을 요약한다.
 
 ## Current Status
 
-- `platform`: pass
+- `web`: pass
 - `admin`: pass
 - `mobile`: pass
 - `landing`: pass
@@ -15,7 +15,7 @@
 
 - service별 frontend build가 current baseline 검증 surface다.
 - typed API contract와 backend domain contract 정합성은 domain verification을 상속한다.
-- screen surface 상세는 `04_verify/02_screen/` 기준으로 읽는다.
+- screen surface 상세는 `03_verify/02_screen/` 기준으로 읽는다.
 
 ## Residual Risk
 

package/sdd/{04_verify → 03_verify}/02_screen/README.md

@@ -1,6 +1,6 @@
 # Screen Verification
 
 - 이 폴더는 screen별 현재 retained verification 상태를 유지한다.
-- service split을 따라 `04_verify/02_screen/<service>/` 아래에 둔다.
+- service split을 따라 `03_verify/02_screen/<service>/` 아래에 둔다.
 - dated gate/test log를 쌓지 않고, current retained checks와 residual risk만 남긴다.
 - 새 verify section을 추가할 때는 `_screen_verify_template.md`를 기준으로 runtime tree, Playwright suite id, canonical runner command, artifact path를 함께 남긴다.

package/sdd/03_verify/02_screen/web/README.md

@@ -0,0 +1,4 @@
+# Web Screen Verification
+
+- current source: `sdd/01_planning/02_screen/web_screen_spec.pdf`
+- 이 폴더는 web screen별 retained verification summary를 유지한다.

package/sdd/{04_verify → 03_verify}/03_architecture/toolchain_governance.md

@@ -36,12 +36,12 @@
 - `rg -n "brand_assets|brand asset|Brand Asset|브랜드 자산|브랜드 에셋|build_mobile_brand_assets|mobile_brand_asset_manifest|BRAND_ASSET_RECIPES" sdd/01_planning/02_screen sdd/02_plan/03_architecture sdd/03_build/03_architecture sdd/99_toolchain .codex/skills/sdd .claude/skills/sdd`
   - pass
   - template repo planning/toolchain/local skill에서 legacy brand asset naming이 제거됐다
-- `git diff --check -- SDD_SKILL.md sdd/02_plan/03_architecture/toolchain_governance.md sdd/03_build/03_architecture/toolchain_governance.md sdd/04_verify/03_architecture/toolchain_governance.md .codex/skills/sdd/SKILL.md .claude/skills/sdd-dev/SKILL.md`
+- `git diff --check -- SDD_SKILL.md sdd/02_plan/03_architecture/toolchain_governance.md sdd/03_build/03_architecture/toolchain_governance.md sdd/03_verify/03_architecture/toolchain_governance.md .codex/skills/sdd/SKILL.md .claude/skills/sdd-dev/SKILL.md`
   - pass
 - `sdd/99_toolchain/02_policies/regression-verification-policy.md`가 회귀 검수 규칙의 정본으로 추가됐다.
 - `AGENTS.md`, `.codex/skills/sdd/SKILL.md`, `sdd/99_toolchain/01_automation/README.md`가 direct-only verification 금지와 selected regression surface 기록 규칙을 함께 설명한다.
 - `sdd/01_planning/02_screen/assets/README.md`, `.codex/skills/sdd/SKILL.md`, `.claude/skills/sdd/SKILL.md`, `sdd/99_toolchain/01_automation/README.md`가 reusable asset planning root를 `assets/`로 일치시킨다.
-- `sdd/02_plan/10_test/regression_verification.md`, `sdd/03_build/10_test/regression_verification.md`, `sdd/04_verify/10_test/regression_verification.md`가 current-state trail을 이룬다.
+- `sdd/02_plan/10_test/regression_verification.md`, `sdd/03_build/10_test/regression_verification.md`, `sdd/03_verify/10_test/regression_verification.md`가 current-state trail을 이룬다.
 - `.claude/skills/sdd-dev/SKILL.md`가 현재 Codex canonical path와 section map path를 직접 가리킨다.
 - `.codex/skills/sdd/SKILL.md`는 rollout scope를 `sdd/05_operate` 존재 여부가 아니라 explicit deployment scope 또는 completion policy로 해석한다.
 - `.codex/skills/sdd/SKILL.md`, `sdd/99_toolchain/01_automation/README.md`, `sdd/99_toolchain/02_policies/regression-verification-policy.md`가 Playwright exactness wrapper/manifest를 canonical local gate로 함께 설명한다.

package/sdd/{04_verify → 03_verify}/06_iac/dev_runtime_delivery.md

@@ -7,4 +7,4 @@
 ## Retained Checks
 
 - current delivery baseline은 frontend build, backend test, screen capture/PDF generation 조합으로 유지된다.
-- proof/output path는 current `sdd/04_verify/10_test/ui_parity/` 구조를 따른다.
+- proof/output path는 current `sdd/03_verify/10_test/ui_parity/` 구조를 따른다.

package/sdd/{04_verify → 03_verify}/06_iac/template_runtime_delivery.md

@@ -18,15 +18,15 @@
   - pass
 - `docker compose --env-file infra/compose/.env.prod.example -f infra/compose/prod.yml config`
   - pass
-- `docker compose --env-file .env.example -f compose.yml build server client-landing client-platform client-mobile client-admin`
+- `docker compose --env-file .env.example -f compose.yml build server client-landing client-web client-mobile client-admin`
   - pass
-- `SERVER_HTTP_PORT=38080 CLIENT_LANDING_PORT=33000 CLIENT_PLATFORM_PORT=33001 CLIENT_MOBILE_PORT=33002 CLIENT_ADMIN_PORT=34000 docker compose --env-file .env.example -f compose.yml up -d postgres server client-landing client-platform client-mobile client-admin`
+- `SERVER_HTTP_PORT=38080 CLIENT_LANDING_PORT=33000 CLIENT_WEB_PORT=33001 CLIENT_MOBILE_PORT=33002 CLIENT_ADMIN_PORT=34000 docker compose --env-file .env.example -f compose.yml up -d postgres server client-landing client-web client-mobile client-admin`
   - pass
   - root compose baseline이 high-port override에서도 `postgres + server + 4 clients`를 모두 기동했다.
 - `curl -sf http://127.0.0.1:38080/health`
   - pass
   - backend health 응답은 `{"status":"ok"}`였다.
-- `SERVER_HTTP_PORT=38080 CLIENT_LANDING_PORT=33000 CLIENT_PLATFORM_PORT=33001 CLIENT_MOBILE_PORT=33002 CLIENT_ADMIN_PORT=34000 docker compose --env-file .env.example -f compose.yml down`
+- `SERVER_HTTP_PORT=38080 CLIENT_LANDING_PORT=33000 CLIENT_WEB_PORT=33001 CLIENT_MOBILE_PORT=33002 CLIENT_ADMIN_PORT=34000 docker compose --env-file .env.example -f compose.yml down`
   - pass
 - `terraform -chdir=infra/terraform/aws/data init -backend=false && terraform -chdir=infra/terraform/aws/data validate`
   - pass
@@ -34,7 +34,7 @@
   - pass
 - `terraform -chdir=infra/terraform/openstack/server init -backend=false && terraform -chdir=infra/terraform/openstack/server validate`
   - pass
-- `git diff --check -- README.md infra/compose/README.md sdd/02_plan/06_iac/template_runtime_delivery.md sdd/03_build/06_iac/template_runtime_delivery.md sdd/04_verify/06_iac/template_runtime_delivery.md sdd/99_toolchain/README.md sdd/99_toolchain/02_policies/compose-runtime-baseline-policy.md sdd/99_toolchain/02_policies/convention-storage-policy.md`
+- `git diff --check -- README.md infra/compose/README.md sdd/02_plan/06_iac/template_runtime_delivery.md sdd/03_build/06_iac/template_runtime_delivery.md sdd/03_verify/06_iac/template_runtime_delivery.md sdd/99_toolchain/README.md sdd/99_toolchain/02_policies/compose-runtime-baseline-policy.md sdd/99_toolchain/02_policies/convention-storage-policy.md`
   - pass
 
 ## Residual Risk

package/sdd/{04_verify → 03_verify}/README.md

@@ -2,14 +2,14 @@
 
 ## Purpose
 
-- `sdd/04_verify/`는 현재 구현 상태에 대한 retained verification을 durable 문서로 유지하는 루트다.
+- `sdd/03_verify/`는 현재 구현 상태에 대한 retained verification을 durable 문서로 유지하는 루트다.
 - 날짜별 gate/test log를 쌓지 않고, 현재 기준의 pass/fail 상태와 residual risk만 남긴다.
 
 ## Canonical Rule
 
-- `04_verify`는 `02_plan`, `03_build`와 같은 section 축을 따른다.
+- `03_verify`는 `02_plan`, `03_build`와 같은 section 축을 따른다.
 - feature, screen, architecture, IAC, test surface별 verification summary를 같은 파일에서 갱신한다.
-- history성 gate/test 로그는 `04_verify`에 두지 않는다.
+- history성 gate/test 로그는 `03_verify`에 두지 않는다.
 
 ## Sections