agentic-dev 0.2.10 → 0.2.12

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

@@ -1,25 +0,0 @@
-# Architecture Planning
-
-- 범위: 서비스별 세부 화면보다 시스템 공통 구조와 구현 선택을 우선 기록한다.
-- architecture 문서는 공통/일반화된 기준을 먼저 두고, 필요할 때만 특화 문서를 추가한다.
-- 주요 축:
-  - frontend architecture
-  - backend architecture
-  - infra architecture
-  - auth/session
-  - deployment topology
-  - migration
-- frontend architecture 문서는 모듈화, 컴포넌트, store/state, domain/use case, UI/UX, storage, API adapter 패턴을 다룬다.
-- backend architecture 문서는 DDD context 구조, context 내부 계층, 3-layer, hexagonal, monolithic, EDA, MSA, CQRS와 실제 구현체 선택을 다룬다.
-- infra architecture 문서는 container, orchestration, database, network, redundancy, multi-region 같은 서비스 기반 구조를 다룬다.
-- 데이터 모델링은 architecture 범위에 포함하지 않고 `sdd/01_planning/04_data/`에서 다룬다.
-
-## Canonical Docs
-
-- [INDEX.md](./INDEX.md)
-- [architecture_document_structure.md](./architecture_document_structure.md)
-- [templates_system_architecture.md](./templates_system_architecture.md)
-- [frontend/README.md](./frontend/README.md)
-- [backend/README.md](./backend/README.md)
-- [infra/README.md](./infra/README.md)
-- [tech-research/README.md](./tech-research/README.md)

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

@@ -1,77 +0,0 @@
-# Architecture Document Structure
-
-## 1. Purpose
-
-- `sdd/01_planning/03_architecture`는 프론트엔드, 백엔드, 인프라를 아우르는 공통 구조와 구현 선택을 기록한다.
-- architecture 문서는 주로 일반화/공통화된 기준을 설명한다.
-- 특정 기술, 인증, 배포, 런타임처럼 개별 주제가 독립 가치가 있으면 특화 문서를 함께 둔다.
-
-## 2. Boundary
-
-### Included In Architecture
-
-- frontend architecture
-  - module composition
-  - component structure
-  - store/state management
-  - domain / use case / adapter structure
-  - UI/UX patterns
-  - local storage / session storage / cache
-  - API client / facade / contract adapter
-- backend architecture
-  - DDD bounded context structure
-  - domain / application / infrastructure / contracts layers
-  - structural choices such as 3-layer, hexagonal, monolithic
-  - pattern adoption such as EDA, MSA, CQRS and the selected implementation
-  - runtime composition and service boundaries
-- infra architecture
-  - container runtime
-  - orchestration
-  - database runtime
-  - network / domain / routing
-  - redundancy / HA
-  - multi-region / deployment topology
-
-### Excluded From Architecture
-
-- entity, schema, relationship, key policy 같은 데이터 모델링 상세
-- table/column 수준 ERD 정의
-- above items belong to [`sdd/01_planning/04_data/README.md`](../04_data/README.md)
-
-## 3. Document Structure
-
-### Root
-
-- 공통/횡단 아키텍처 문서를 둔다.
-- 예:
-  - structure principle
-  - document boundary
-  - migration guide
-  - runtime alignment rule
-
-### frontend/
-
-- 프런트엔드 특화 아키텍처 문서를 둔다.
-- 특정 surface에 종속되더라도 재사용 가능한 구조 원칙이면 여기에 둔다.
-
-### backend/
-
-- 백엔드 특화 아키텍처 문서를 둔다.
-- context structure, layering, pattern, runtime composition을 기록한다.
-
-### infra/
-
-- 인프라 특화 아키텍처 문서를 둔다.
-- deployment topology, networking, orchestration, runtime platform을 기록한다.
-
-### tech-research/
-
-- 인증, 외부 provider, 실험 기술 같은 특정 주제 리서치를 둔다.
-- research는 architecture 하위에 두되 공통 구조 문서와 분리한다.
-
-## 4. Writing Rule
-
-- 공통 문서를 먼저 작성하고, 특화 문서는 필요할 때만 추가한다.
-- 이론 자체보다 현재 repo가 어떤 구조와 구현체를 채택했는지를 우선 기록한다.
-- 여러 대안이 있을 때는 후보 나열로 끝내지 않고 현재 권장안과 이유를 적는다.
-- feature, screen, data 문서가 맡아야 할 내용을 architecture에 중복 기록하지 않는다.

package/sdd/01_planning/03_architecture/backend/README.md

@@ -1,10 +0,0 @@
-# Backend Architecture Planning
-
-- 범위: 백엔드의 공통 구조와 구현 패턴
-- 주요 축:
-  - DDD bounded context
-  - domain/application/infrastructure/contracts layering
-  - 3-layer / hexagonal / monolithic structure
-  - adoption of patterns such as EDA, MSA, CQRS
-  - actual runtime composition and implementation choices
-- entity/schema/relationship 정의는 `04_data`에서 다룬다.

package/sdd/01_planning/03_architecture/frontend/README.md

@@ -1,12 +0,0 @@
-# Frontend Architecture Planning
-
-- 범위: 프런트엔드의 공통 구조와 구현 패턴
-- 주요 축:
-  - 모듈화
-  - 컴포넌트 구조
-  - store/state
-  - domain/use case
-  - UI/UX 패턴
-  - storage/session/cache
-  - API client / facade / adapter
-- 화면별 route/CTA/전이는 `02_screen`에서 다루고, 기능별 business rule은 `01_feature`에서 다룬다.

package/sdd/01_planning/03_architecture/infra/README.md

@@ -1,10 +0,0 @@
-# Infra Architecture Planning
-
-- 범위: 프런트엔드, 백엔드, supporting service를 올리는 기반 구조
-- 주요 축:
-  - docker / compose / kubernetes
-  - container runtime / orchestration
-  - database / storage / secret / network
-  - redundancy / HA / multi-region
-  - deployment topology / runtime boundary
-- 운영 절차 자체는 필요 시 `05_operate` runbook과 분리해 기록한다.

package/sdd/01_planning/03_architecture/tech-research/README.md

@@ -1,4 +0,0 @@
-# Tech Research
-
-- 이 폴더는 architecture 하위의 주제별 기술 리서치를 둔다.
-- 인증, 외부 provider, 실험 기술처럼 공통 구조 문서와 분리할 가치가 있는 주제만 둔다.

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

@@ -1,84 +0,0 @@
-# templates system architecture
-
-- 작성 버전: 1.0.0
-
-## Purpose
-
-`templates` 레포의 현재 runtime 구조와 bounded context 경계를 구현 기준으로 정리한다.
-
-## Document Boundary
-
-- frontend, backend, infra 공통 구조와 구현 선택을 이 문서에서 다룬다.
-- entity/schema/relationship/key policy 같은 데이터 모델링 상세는 `sdd/01_planning/04_data/`에서 다룬다.
-
-## 1. Runtime Topology
-
-| Layer | Owner | Responsibility |
-| --- | --- | --- |
-| `server` | HTTP backend | auth, user, catalog, inventory, orders, fulfillment, shipping, alerts, support, health를 HTTP API 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 |
-| `infra/compose` | container runtime | root compose baseline + dedicated DEV(개발계)/PROD overlay 레이아웃 |
-
-## 2. Transport Topology
-
-| Surface | Module | Responsibility |
-| --- | --- | --- |
-| HTTP | `server/api/http` | FastAPI app, router aggregation, `/health`, `/api/v1/*` 제공 |
-
-## 3. Backend Context Map
-
-| Bounded Context | Module | Role |
-| --- | --- | --- |
-| Authentication & Session | `server/contexts/auth` | login, bearer token 해석, 인증 계정 저장 |
-| 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` | 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, 읽음 처리 |
-| Support Content | `server/contexts/support` | 관리자 FAQ 목록/작성/노출 상태 변경 |
-| Health | `server/contexts/health` | technical health/status contract |
-
-## 4. Context Relationship
-
-- `auth`는 `user`와 분리된 인증 계정 bootstrap을 사용한다.
-- `user`는 profile directory만 소유하고 credential hash를 저장하지 않는다.
-- `catalog`는 landing/public read와 admin write surface를 함께 소유한다.
-- `inventory`는 현재 admin 운영 surface를 통해 직접 조정되고, `orders`와 `fulfillment`의 참조 도메인으로 연결된다.
-- `orders`는 web read model과 admin read model을 동시에 노출한다.
-- `fulfillment`는 mobile 서비스의 canonical backend surface다.
-- `shipping`은 `fulfillment`의 downstream delivery 상태를 분리해 mobile/operator surface에 제공한다.
-- `alerts`는 admin이 소비하는 운영 알람 표현과 읽음 상태를 별도 context로 소유한다.
-
-## 5. Layering Rule
-
-- context 외부 진입점은 `contexts/*/contracts/http`에 둔다.
-- application layer는 use case orchestration만 담당한다.
-- domain layer는 request/response model과 aggregate/read model을 가진다.
-- infrastructure layer는 adapter, repository factory, shared gateway binding을 담당한다.
-- shared logic는 `shared/application`, `shared/infrastructure`에 두되, 특정 domain 소유물이 되면 context 내부로 이동한다.
-- transport wiring은 `api/http`에 두고 domain 로직은 `contexts/*`에만 둔다.
-
-## 6. Runtime Component Baseline
-
-| Component | Current Baseline | Next Step |
-| --- | --- | --- |
-| HTTP server | `FastAPI + Uvicorn` | authz, rate limit, observability middleware 추가 |
-| Persistence | bootstrap JSON + selectable DB adapter | transaction boundary와 repository parity 강화 |
-| Frontend runtime | `React 18 + Vite 5 + pnpm workspace` | contract-driven env injection 자동화 |
-
-## 7. Current Known Gaps
-
-- persistence baseline은 여전히 bootstrap JSON + in-memory mutation 중심이다.
-- order 생성과 fulfillment/shipping 전이가 inventory 자동 연동까지는 아직 확장되지 않았다.
-- support는 FAQ 관리 중심이고 ticket/workflow 도메인까지는 아직 포함하지 않는다.
-
-## 8. Next Refactoring Direction
-
-- catalog/inventory/order/fulfillment/shipping 간의 orchestration을 application service 수준으로 확장한다.
-- auth account와 user profile 사이의 provisioning 흐름을 별도 domain service로 일반화한다.
-- admin surface에서 alerts/support/catalog/inventory command를 직접 소비하도록 frontend scope를 넓힌다.

package/sdd/01_planning/04_data/INDEX.md

@@ -1,4 +0,0 @@
-# Data Planning
-
-- [README.md](./README.md)
-- [templates_data_modeling.md](./templates_data_modeling.md)

package/sdd/01_planning/04_data/README.md

@@ -1,10 +0,0 @@
-# Data Planning
-
-- 범위: 공통 데이터 모델과 엔티티 관계 정의
-- architecture 문서에서 다루지 않는 entity/schema/relationship/key policy는 이 루트에서 다룬다.
-- 데이터 모델링은 current canonical 기준만 남기고, 구조 문서와 중복 기록하지 않는다.
-
-## Canonical Docs
-
-- [INDEX.md](./INDEX.md)
-- [templates_data_modeling.md](./templates_data_modeling.md)

package/sdd/01_planning/04_data/templates_data_modeling.md

@@ -1,119 +0,0 @@
-# templates data modeling
-
-- 작성 버전: 1.0.0
-
-## Purpose
-
-현재 구현된 backend domain model과 저장 관점을 entity 수준으로 요약한다.
-
-## 1. Auth Account
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `id` | `str` | 인증 계정 식별자 |
-| `name` | `str` | 표시 이름 |
-| `email` | `EmailStr` | 로그인 이메일 |
-| `role` | `str` | `admin`, `operator` 등 인증 역할 |
-| `status` | `str` | 인증 가능 상태 |
-| `password_hash` | `str` | credential hash |
-
-## 2. User Profile
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `id` | `str` | 사용자 식별자 |
-| `name` | `str` | 사용자 이름 |
-| `email` | `EmailStr` | 연락/표시 이메일 |
-| `role` | `str` | 운영 역할 |
-| `status` | `str` | 활성 상태 |
-| `timezone` | `str` | 지역/표시용 timezone |
-| `last_login_at` | `str` | 최근 로그인 시각 |
-
-## 3. Catalog Product
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `id` | `str` | 상품 식별자 |
-| `slug` | `str` | URL/업무용 유니크 slug |
-| `name` | `str` | 상품명 |
-| `brand` | `str` | 브랜드명 |
-| `category` | `str` | 카테고리 |
-| `status` | `draft|active|archived` | 카탈로그 노출 상태 |
-| `short_description` | `str` | 카드용 요약 문구 |
-| `description` | `str` | 상세 설명 |
-| `hero_image` | `MediaAsset` | 대표 이미지 |
-| `gallery` | `list[MediaAsset]` | 추가 이미지 |
-| `price` | `Money` | 판매가 |
-| `compare_at_price` | `Money?` | 비교가 |
-| `tags` | `list[str]` | 태그 |
-| `attributes` | `list[ProductAttribute]` | 속성 리스트 |
-| `variants` | `list[ProductVariant]` | SKU variant 리스트 |
-| `created_at` | `str` | 생성 시각 |
-| `updated_at` | `str` | 수정 시각 |
-
-## 4. Inventory Level
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `sku` | `str` | 재고 식별 단위 |
-| `product_id` | `str` | catalog product 참조 |
-| `product_name` | `str` | 표시용 상품명 |
-| `variant_name` | `str` | variant 이름 |
-| `location_id` | `str` | 물류 거점 식별자 |
-| `location_name` | `str` | 거점 이름 |
-| `on_hand` | `int` | 실재고 |
-| `reserved` | `int` | 선점 재고 |
-| `safety_stock` | `int` | 안전 재고 |
-| `reorder_point` | `int` | 재주문 기준점 |
-| `updated_at` | `str` | 수정 시각 |
-
-## 5. Order
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `id` | `str` | 주문 식별자 |
-| `product_id` | `str` | 상품 참조 |
-| `product_name` | `str` | 표시용 상품명 |
-| `customer_name` | `str` | 고객명 |
-| `seller_name` | `str` | 판매자/셀러명 |
-| `status` | `str` | 결제/주문 상태 |
-| `fulfillment_status` | `str` | 이행 상태 |
-| `created_at` | `str` | 생성 시각 |
-| `amount_krw` | `int` | 주문 금액 |
-| `risk` | `str` | 운영 위험도 |
-| `stage` | `str` | 운영 단계 |
-| `sla` | `str` | SLA 표시 |
-| `is_new_today` | `bool` | 당일 신규 여부 |
-
-## 6. Fulfillment Task
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `id` | `str` | task 식별자 |
-| `order_id` | `str` | 주문 참조 |
-| `title` | `str` | 작업 제목 |
-| `assignee` | `str` | 담당자 |
-| `stage` | `str` | 이행 단계 |
-| `status` | `str` | task 상태 |
-| `priority` | `str` | 우선순위 |
-| `channel` | `str` | 유입 채널 |
-| `sla_minutes` | `int` | SLA 분 단위 |
-| `units` | `int` | 처리 수량 |
-
-## 7. Support FAQ
-
-| Field | Type | Meaning |
-| --- | --- | --- |
-| `id` | `str` | FAQ 식별자 |
-| `question` | `str` | 질문 |
-| `answer` | `str` | 답변 |
-| `category` | `str` | FAQ 카테고리 |
-| `visibility` | `str` | 노출 여부 |
-| `updated_at` | `str` | 수정 시각 |
-
-## 8. Key Policy
-
-- 현재 템플릿은 string id를 사용한다.
-- 실제 서비스 구현 시 time-ordered UUID v7을 기본 식별자로 채택한다.
-- legacy numeric id는 새 이커머스 baseline에서 사용하지 않는다.
-- `auth`와 `user`는 같은 사람을 표현하더라도 저장 목적이 다르므로 독립 레코드로 유지한다.

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

@@ -1,12 +0,0 @@
-# 05 API
-
-API 원천 계약을 둔다.
-
-- `/api/v1/auth/login`
-- `/api/v1/auth/me`
-- `/api/v1/users`
-- template example endpoint
-
-## Canonical Docs
-
-- [templates_api_contract.md](./templates_api_contract.md)

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

@@ -1,90 +0,0 @@
-# templates server contract
-
-- 작성 버전: 1.0.0
-
-## Purpose
-
-현재 server runtime이 제공하는 HTTP contract를 구현 기준으로 정리한다.
-
-## 1. HTTP Endpoint Matrix
-
-| Method | Path | Domain | Purpose | Response |
-| --- | --- | --- | --- | --- |
-| `GET` | `/health` | health | root health probe | `{"status":"ok"}` |
-| `GET` | `/api/v1/status` | health | API health/status probe | `{"service":"template-server","status":"healthy"}` |
-| `POST` | `/api/v1/auth/login` | auth | credential 로그인과 token 발급 | `AuthToken` |
-| `GET` | `/api/v1/auth/me` | auth | bearer token 기반 현재 사용자 조회 | `AuthenticatedUser` |
-| `GET` | `/api/v1/users` | user | 사용자 summary 목록 조회 | `list[UserSummary]` |
-| `GET` | `/api/v1/users/{user_id}` | user | 단일 사용자 상세 조회 | `UserDetail` |
-| `PATCH` | `/api/v1/users/{user_id}/status` | user | 사용자 상태 변경 | `UserDetail` |
-| `GET` | `/api/v1/catalog/products` | catalog | 공개/운영 상품 목록 조회 | `list[ProductSummary]` |
-| `GET` | `/api/v1/catalog/products/{product_id}` | catalog | 단일 상품 상세 조회 | `ProductDetail` |
-| `POST` | `/api/v1/catalog/products` | catalog | 상품 생성 | `ProductDetail` |
-| `PUT` | `/api/v1/catalog/products/{product_id}` | catalog | 상품 수정 | `ProductDetail` |
-| `PATCH` | `/api/v1/catalog/products/{product_id}/status` | catalog | 상품 상태 변경 | `ProductDetail` |
-| `GET` | `/api/v1/inventory/levels` | inventory | 재고 레벨 목록 조회 | `list[InventoryLevel]` |
-| `GET` | `/api/v1/inventory/levels/{sku}/{location_id}` | inventory | 단일 재고 레벨 조회 | `InventoryLevel` |
-| `POST` | `/api/v1/inventory/levels/{sku}/{location_id}/adjustments` | inventory | 재고 증감 조정 | `InventoryMutationReceipt` |
-| `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 | 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` |
-| `GET` | `/api/v1/orders/admin/queue` | orders | admin queue table row 조회 | `list[AdminQueueItem]` |
-| `GET` | `/api/v1/shipping/overview` | shipping | mobile 배송 overview 조회 | `ShippingOverview` |
-| `GET` | `/api/v1/shipping/shipments` | shipping | shipment 목록 조회 | `list[ShipmentSummary]` |
-| `PATCH` | `/api/v1/shipping/shipments/{shipment_id}/status` | shipping | 배송 상태 전이 | `ShipmentStatusTransition` |
-| `GET` | `/api/v1/alerts` | alerts | admin 운영 알람 feed 조회 | `AlertsPayload` |
-| `POST` | `/api/v1/alerts/{alert_id}/read` | alerts | 운영 알람 1건 읽음 처리 | `AlertReadResult` |
-| `POST` | `/api/v1/alerts/read-all` | alerts | 운영 알람 전체 읽음 처리 | `AlertsReadAllResult` |
-| `GET` | `/api/v1/support/faqs` | support | admin FAQ 목록 조회 | `list[SupportFaq]` |
-| `POST` | `/api/v1/support/faqs` | support | FAQ 생성 | `SupportFaqRecord` |
-| `PATCH` | `/api/v1/support/faqs/{faq_id}/visibility` | support | FAQ visibility 변경 | `SupportFaqRecord` |
-| `GET` | `/api/v1/fulfillment/overview` | fulfillment | mobile dashboard 운영 overview 조회 | `FulfillmentOverview` |
-| `GET` | `/api/v1/fulfillment/board` | fulfillment | mobile fulfillment board 조회 | `FulfillmentBoardPayload` |
-| `PATCH` | `/api/v1/fulfillment/tasks/{task_id}/status` | fulfillment | fulfillment task 상태 전이 | `FulfillmentTaskStatusTransition` |
-
-## 2. Auth Contract
-
-- 인증 방식: `Authorization: Bearer <token>`
-- login 입력: `email`, `password`
-- login 성공 시 `access_token`, `token_type`, `user_id` 반환
-- `auth/me`는 유효 token subject를 `AuthenticatedUser`로 해석
-- `users`, `catalog` command, `inventory`, `orders`, `shipping`, `alerts`, `support`, `fulfillment`는 보호된 contract다
-
-## 3. Error Baseline
-
-- invalid credential: `401 Invalid credentials`
-- invalid token: `401 Invalid token`
-- forbidden role: `403 Forbidden`
-- missing resource:
-  - HTTP: `404 ... not found`
-- conflict:
-  - duplicate catalog slug: `409 Catalog product slug already exists`
-  - invalid inventory mutation: `409 ...`
-
-## 4. Frontend Binding Notes
-
-- `client/web`
-  - `/`는 `GET /api/v1/orders/overview`를 소비한다.
-  - `/orders`는 `GET /api/v1/orders`를 소비한다.
-- `client/admin`
-  - `/`는 `GET /api/v1/orders/admin/overview`를 소비한다.
-  - admin shell과 dashboard는 `GET /api/v1/alerts`를 운영 알람 source로 사용한다.
-  - `/queue`는 `GET /api/v1/orders/admin/queue`를 소비한다.
-  - `/support`는 `GET /api/v1/support/faqs`를 소비한다.
-- `client/mobile`
-  - `/`는 `GET /api/v1/fulfillment/overview`를 소비한다.
-  - `/fulfillment`는 `GET /api/v1/fulfillment/board`를 소비한다.
-  - `/shipping`은 `GET /api/v1/shipping/overview`, `GET /api/v1/shipping/shipments`를 소비한다.
-- `client/landing`
-  - `/`와 `/workspace`는 `GET /api/v1/catalog/products`를 live catalog surface로 사용한다.
-- auth flow는 네 app 모두 `POST /api/v1/auth/login`과 `GET /api/v1/auth/me`를 유지한다.
-
-## 5. Stack Notes
-
-- HTTP: `FastAPI 0.116.x + Uvicorn 0.35.x`
-- Compose runtime: `server`

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

@@ -1,11 +0,0 @@
-# 06 IaC
-
-템플릿 런타임 부팅 원천 자료를 둔다.
-
-- Dockerfile
-- compose
-- env contracts
-
-## Canonical Docs
-
-- [templates_runtime_and_cicd_baseline.md](./templates_runtime_and_cicd_baseline.md)

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

@@ -1,46 +0,0 @@
-# templates runtime and cicd baseline
-
-- 작성 버전: 1.0.0
-
-## Purpose
-
-템플릿 저장소의 root compose runtime baseline과 CI baseline을 정리한다.
-
-## 1. Compose Runtime Baseline
-
-| Surface | Default Port |
-| --- | --- |
-| landing | `3000` |
-| web | `3001` |
-| mobile | `3002` |
-| admin | `4000` |
-| api | `8000` |
-
-## 2. Compose Rule
-
-- root `compose.yml`이 canonical dev-focused runtime baseline이다.
-- dedicated host용 DEV(개발계)/PROD overlay는 `infra/compose/dev.yml`, `infra/compose/prod.yml`을 사용한다.
-- 환경변수 contract는 `.env.example`을 source-of-truth로 유지한다.
-
-## 3. CI/CD Rule
-
-- 이 레포는 템플릿 저장소이므로 실제 배포를 수행하지 않는다.
-- `.github/workflows`는 다음만 책임진다.
-  - root compose/overlay config validation
-  - backend test
-  - frontend build matrix
-  - AST build audit와 parity target resolution
-  - canonical Terraform skeleton validate
-
-## 4. Delivery Note
-
-- 실제 서비스 레포로 clone된 뒤 DEV/PROD deploy workflow를 추가한다.
-- template repo의 workflow는 `검증용 CI`만 유지한다.
-
-## 5. Remote Infra Template Layout
-
-- canonical Terraform split은 `infra/terraform/aws/data`, `infra/terraform/aws/domain`, `infra/terraform/openstack/server`다.
-- `infra/terraform/openstack/dev`, `infra/terraform/openstack/prod`는 lower-level starter root로 유지한다.
-- 공통 OpenStack host/network/security group 로직은 `infra/terraform/openstack/modules/environment_host`에 둔다.
-- DEV(개발계)와 PROD는 별도 Terraform state를 사용한다.
-- cloud-init compose 자동 기동은 각 환경 root의 `compose_env_content`와 `deploy_compose_on_boot`로 제어한다.

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

@@ -1,11 +0,0 @@
-# 07 Integration
-
-프론트와 `api`의 통합 원천 시나리오를 둔다.
-
-- login flow
-- token persistence
-- adapter selection
-
-## Canonical Docs
-
-- [templates_frontend_api_integration.md](./templates_frontend_api_integration.md)

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

@@ -1,46 +0,0 @@
-# templates frontend api integration
-
-- 작성 버전: 1.0.0
-
-## Purpose
-
-현재 frontend와 backend의 실제 연결 지점을 정리한다.
-
-## 1. Shared Integration Rule
-
-- 네 개의 frontend 모두 공통 `auth` contract를 사용한다.
-- `POST /api/v1/auth/login`으로 access token을 발급받고 로컬 storage에 저장한다.
-- `GET /api/v1/auth/me`로 초기 세션을 복원한다.
-
-## 2. Service Coupling Summary
-
-| Service | Real Backend Coupling | Note |
-| --- | --- | --- |
-| 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
-
-- web
-  - bearer session은 기존 `AuthProvider`가 유지한다.
-  - page load 시 `orders/overview`, `orders`를 fetch하고 search는 client-side filter로 처리한다.
-- admin
-  - protected route는 그대로 유지한다.
-  - dashboard는 `orders/admin/overview`와 `alerts`를 병렬 fetch한다.
-  - queue, support, alerts drawer는 개별 page-level effect로 fetch한다.
-- mobile
-  - overview와 board payload는 mobile shell 진입 후 fetch한다.
-  - status/tone badge는 response의 string field를 frontend palette에 매핑한다.
-  - board route는 `/fulfillment`다.
-  - shipping route는 `/shipping`이고 shipment status feed를 별도 fetch한다.
-- landing
-  - public home에서도 `catalog/products`를 읽어 live catalog proof를 보여준다.
-  - protected workspace는 auth user summary와 catalog product grid를 함께 노출한다.
-
-## 4. Known Gaps
-
-- 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/08_nonfunctional/README.md

@@ -1,7 +0,0 @@
-# 08 Nonfunctional
-
-비기능 요구 원천 자료를 둔다.
-
-- build reproducibility
-- template startup speed
-- DX requirements

package/sdd/01_planning/09_security/README.md

@@ -1,7 +0,0 @@
-# 09 Security
-
-보안 원천 자료를 둔다.
-
-- bootstrap credential handling
-- JWT secret rules
-- CORS baseline

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

@@ -1,12 +0,0 @@
-# 10 Test
-
-테스트 원천 목록을 둔다.
-
-- frontend build matrix
-- api pytest matrix
-- auth runtime smoke
-- compose validation
-
-## Canonical Docs
-
-- [templates_test_strategy.md](./templates_test_strategy.md)