웰컴스 erp 자체 웹서비스 개발 기록

2026.04.30

# SNS ERP Web 버전 구축 (v1)

# # TL;DR

> **Quick Summary**: Firebird v3 기반 기존 SNS ERP 데스크톱 앱을 모던 웹 애플리케이션으로 재구축 완료. SQLite + Next.js 16.2.4 + Prisma + shadcn/ui로 기준정보/구매/영업/재고/생산/리포트/대시보드/인쇄 모듈 v1.2까지 구현. Ubuntu 서버 Docker + Caddy 리버스프록시로 `https://werp.wellcoms.co.kr` 배포 완료.

> **Deliverables** (ALL COMPLETE ✅):

> - Next.js 16.2.4 풀스택 웹 ERP 애플리케이션 (standalone 모드)

> - SQLite 데이터베이스 (Prisma ORM 6.19, ~30개 모델)

> - Firebird → SQLite 데이터 마이그레이션 완료

> - 기준정보/구매/영업/재고/생산/리포트/대시보드/인쇄 (29개 메뉴, 40+ API)

> - Docker + Caddy 프로덕션 배포 설정

> **Current Status**: v1.2 완료, 프로덕션 배포 준비 완료

> **Production URL**: `https://werp.wellcoms.co.kr` (Caddy 리버스프록시 → Docker :3200)

> **Local Dev**: `http://localhost:3000`

## # 아키텍처 개요 (v1.2 — Ubuntu Docker 배포)

```mermaid

graph TB

subgraph Internet["🌐 인터넷"]

USER["사용자 브라우저 https://werp.wellcoms.co.kr"]

end

subgraph Ubuntu["🖥️ Ubuntu Server ([SERVER_IP])"]

subgraph Caddy["🔀 Caddy (리버스프록시)"]

REV["werp.wellcoms.co.kr → localhost:3200 자동 HTTPS (Let's Encrypt)"]

end

subgraph Docker["🐳 Docker Compose"]

subgraph Container["werp Container (node:20-alpine)"]

APP["Next.js 16.2.4 (standalone) React 19 + shadcn/ui TanStack Table + Recharts"]

MW["Middleware JWT 인증 (jose)"]

API["API Routes — 40+ 엔드포인트 RESTful CRUD + Confirm"]

end

VOL["Volume: ./data:/app/data dev.db (SQLite 영속성)"]

end

subgraph Lib["📚 Shared Libraries"]

Auth["auth.ts — JWT"]

Serial["serial.ts — 시리얼번호 라이프사이클"]

PDF["pdf.ts — PDF 인쇄"]

Excel["excel.ts — Excel 내보내기"]

end

USER -->|HTTPS| REV

REV -->|HTTP :3200| MW

MW -->|인증됨| APP

MW -->|미인증| LOGIN["/login"]

APP --> API

API --> VOL

API --> Auth

API --> Serial

API --> PDF

API --> Excel

style Internet fill:#6366f1,color:#fff

style Ubuntu fill:#334155,color:#fff

style Caddy fill:#06b6d4,color:#fff

style Docker fill:#0ea5e9,color:#fff

style Lib fill:#8b5cf6,color:#fff

```

## # 비즈니스 프로세스 흐름 (v1.2)

```mermaid

flowchart TB

subgraph Purchase["🛒 구매"]

direction TB

PR["구매요청 PR-YYYYMMDD-NNN"]

PO["발주 PO-YYYYMMDD-NNN"]

RC["입고 PU-YYYYMMDD-NNN"]

PR --> PO --> RC

end

subgraph Sales["🏭 영업"]

direction TB

QT["견적서 QT-YYYYMMDD-NNN"]

SO["수주 SO-YYYYMMDD-NNN"]

SH["출고 SH-YYYYMMDD-NNN"]

QT --> SO --> SH

end

subgraph Returns["↩️ 반품/불량"]

direction TB

RT["반품 RT-YYYYMMDD-NNN"]

DF["불량/폐기 DF-YYYYMMDD-NNN"]

end

subgraph Production["🔧 생산"]

direction TB

BOM["BOM 관리"]

PROD["생산오더 WO-YYYYMMDD-NNN"]

BOM --> PROD

end

subgraph Inventory["📦 재고"]

direction TB

ST["현재고 Stock"]

AD["재고조정 StockChange"]

MV["창고이동 LT-YYYYMMDD-NNN"]

SN["시리얼번호 추적"]

end

RC -->|"재고 증가 시리얼 자동생성"| ST

SH -->|"재고 감소 시리얼 자동할당"| ST

SH --> RT

SH --> DF

PROD -->|"생산 확정 시리얼 자동생성"| ST

RT -->|"시리얼 복구"| ST

ST --> AD

ST --> MV

ST --> SN

style Purchase fill:#3b82f6,color:#fff

style Sales fill:#10b981,color:#fff

style Returns fill:#ef4444,color:#fff

style Production fill:#8b5cf6,color:#fff

style Inventory fill:#f59e0b,color:#fff

```

---

# # Context

## # Original Request

Firebird v3로 만든 snserp.fdb ([PASSWORD]) 데이터를 가져와서 SNS ERP와 같은 ERP를 웹으로 만들고 싶다. 구매/생산/영업/재고/보고서/입출금-회계 등의 기능이 필요. 모던하고 깔끔하게 구성. 로컬 작업 후 나중에 도메인 연결 예정.

## # Interview Summary

**Key Discussions**:

- **v1 범위**: 기준정보 + 구매 + 영업 + 재고 (핵심 우선). v1.1에서 생산(시리얼/BOM), v1.2에서 리포트/연동 강화.

- **DB 전략**: Firebird → SQLite 마이그레이션 (PostgreSQL에서 SQLite로 전환). Prisma ORM 6.19 사용.

- **기술 스택**: Next.js 16.2.4 풀스택 (App Router + API Routes), standalone 출력 모드

- **UI**: React 19 + shadcn/ui + Tailwind CSS 4 (모던 미니멀)

- **인증**: 기존 STAFF 테이블 기반 JWT 인증 (jose + bcryptjs + httpOnly 쿠키)

- **인쇄**: PDF 출력 7종 (견적서, 발주서, 수주서, 출고전표, 구매요청, 입고전표, 생산오더)

- **배포**: Ubuntu 서버 Docker + Caddy 리버스프록시 → `https://werp.wellcoms.co.kr`

**Research Findings**:

- Firebird DB에 85개 테이블, 1,000+ 컬럼 존재. 완전한 ERP 스키마.

- `node-firebird` 라이브러리로 데이터 추출 가능

- SQLite가 소규모 ERP에 충분한 성능 제공, 배포/관리 단순화

- TanStack Table 8 + shadcn/ui가 데이터密集 앱의 표준

- PDF 생성은 jsPDF + jspdf-autotable 활용

- Docker standalone 모드로 경량 배포 가능

## # Self Gap Analysis (Metis 대체)

**Identified Gaps** (모두 해결 완료 ✅):

- ~~마이그레이션 시 Firebird BLOB → PostgreSQL BYTEA/TEXT 변환 필요~~ → SQLite TEXT/BLOB으로 직접 매핑

- ~~기존 STAFF.PASSWORD 필드가 평문인지 해시인지 불명~~ → bcryptjs 해시 변환 적용

- CODE 필드가 VARCHAR(120)으로 자동증가 패턴 → 애플리케이션 레벨 코드 생성 (PR-/PO-/PU-/QT-/SO-/SH-/WO-/RT-/DF-/LT- 접두어 + YYYYMMDD + NNN)

- ~~CM_AUTOINCINDEX 테이블이 자동증가 관리~~ → SQLite 시퀀스 패턴으로 대체

- 다국어: v1은 한국어만 지원 ✅

- 권한: STAFF.PERMISSION이 CHAR(324) → 기본 관리자/사용자 2단계 적용 ✅

---

# # Work Objectives

## # Core Objective

Firebird v3 기반 기존 SNS ERP 데이터를 SQLite로 마이그레이션하고, Next.js 16.2.4 풀스택으로 기준정보/구매/영업/재고/생산/리포트 핵심 ERP 모듈을 웹에서 사용할 수 있도록 구축. Ubuntu 서버 Docker + Caddy로 프로덕션 배포.

## # Concrete Deliverables (ALL COMPLETE ✅)

- 실행 가능한 Next.js 16.2.4 웹 애플리케이션 (standalone 모드)

- SQLite 데이터베이스 (Prisma ORM 6.19, ~30개 모델)

- Firebird → SQLite 데이터 마이그레이션 완료

- 로그인/인증 시스템 (STAFF 테이블 기반 JWT, jose + bcryptjs)

- 기준정보 CRUD (거래처, 품목, 창고, 직원, 프로젝트)

- 구매 프로세스 (구매요청 → 발주 → 입고, 연동 포함)

- 영업 프로세스 (견적 → 수주 → 출고 → 반품/불량, 연동 포함)

- 재고 관리 (현재고, 창고이동, 재고조정, 바코드)

- 생산 관리 (생산오더, BOM, 시리얼번호)

- 리포트 (매입매출 현황, 수불부, 채권/채무, 재고현황)

- 대시보드 (매출/매입 요약, 재고 현황, 카테고리별 차트)

- PDF 인쇄 7종 + Excel 내보내기

- Docker + Caddy 프로덕션 배포 설정

## # Definition of Done (ALL COMPLETE ✅)

- [x] `npm run dev` 로 localhost:3000 접속 가능

- [x] 기존 Firebird 데이터가 SQLite에 정상 이관됨

- [x] 로그인 후 모든 모듈 CRUD 동작

- [x] 구매/영업/생산 프로세스가 end-to-end로 동작

- [x] 재고 수량이 구매입고/영업출고/생산에 따라 자동 갱신됨

- [x] PDF 인쇄 7종 동작

- [x] 시리얼번호 라이프사이클 (입고/생산→출고→반품) 동작

- [x] `npx next build` 94 라우트 빌드 성공

- [x] Docker 이미지 빌드 및 배포 준비 완료

## # Must Have (모두 충족 ✅)

- 기존 Firebird 데이터 완전 이관 (손실 없이)

- 반응형 웹 (데스크톱/태블릿)

- 한국어 UI

- 트랜잭션 안전성 (구매/영업/재고 연동)

- 검색/필터/정렬 기능

- Excel 내보내기

## # Must NOT Have (Guardrails)

- 결제/PG 연동

- 실시간 알림 (WebSocket)

- 모바일 네이티브 앱

- 소셜 로그인 (OAuth)

- AI 기반 기능

- 과도한 추상화 - 각 모듈은 독립적이되 불필요한 공통 레이어 금지

- 거대한 공통 컴포넌트 라이브러리 - 필요시에만 추출

---

# # Verification Strategy (MANDATORY)

> **ZERO HUMAN INTERVENTION** - ALL verification is agent-executed. No exceptions.

## # Test Decision

- **Infrastructure exists**: NO (greenfield project)

- **Automated tests**: Tests-after (구현 후 핵심 로직에 대한 테스트)

- **Framework**: Vitest (Next.js 권장)

- **Testing scope**: API 라우트, 비즈니스 로직, 재고 계산 로직

## # QA Policy

Every task MUST include agent-executed QA scenarios.

Evidence saved to `.sisyphus/evidence/task-{N}-{scenario-slug}.{ext}`.

- **Frontend/UI**: Use Playwright (playwright skill) - Navigate, interact, assert DOM, screenshot

- **API/Backend**: Use Bash (curl) - Send requests, assert status + response fields

- **Database**: Use Bash (npx prisma) - Verify schema, check data integrity

---

# # Execution Strategy

## # Wave 실행 타임라인 (ALL COMPLETE ✅)

```mermaid

gantt

title SNS ERP Web v1 → v1.2 — 실행 완료 타임라인

dateFormat X

axisFormat %s

section Wave 1 (Foundation) ✅

T1. 프로젝트 스캐폴딩 :w1t1, 0, 1

T2. Prisma 스키마 설계 :w1t2, 1, 3

T3. 인증 시스템 :w1t3, 1, 3

T4. 공통 UI + 레이아웃 :w1t4, 1, 3

section Wave 2 (Master + Purchase) ✅

T5. 거래처 관리 :w2t5, 3, 5

T6. 품목 관리 :w2t6, 3, 5

T7. 창고/직원/프로젝트 :w2t7, 3, 5

T8. 구매요청 :w2t8, 5, 7

T9. 발주 + 입고 :w2t9, 7, 9

section Wave 3 (Sales + Inventory) ✅

T10. 견적서 관리 :w3t10, 9, 11

T11. 수주 + 출고 :w3t11, 11, 13

T12. 현재고 + 재고조정 :w3t12, 13, 15

T13. 창고이동 :w3t13, 15, 17

section Wave 4 (Integration) ✅

T14. 대시보드 :w4t14, 17, 19

T15. DB 마이그레이션 :w4t15, 17, 19

T16. PDF 인쇄 :w4t16, 17, 19

section Wave 5 (Polish) ✅

T17. Excel 내보내기 :w5t17, 19, 20

T18. 통합테스트 :w5t18, 20, 22

section v1.1 (Production) ✅

T19. 시리얼번호 관리 :v1t19, 22, 24

T20. BOM 관리 :v1t20, 24, 26

section v1.2 (Reports + 연동) ✅

재고조정/창고이동 API :v1r1, 26, 27

매입매출/수불부/채권채무 :v1r2, 27, 28

시리얼 라이프사이클 :v1r3, 28, 29

발주↔입고/수주↔출고/출고→반품 :v1r4, 29, 30

전체 감사 + 빌드 94 라우트 :v1r5, 30, 31

```

## # 데이터 모델 관계도 (v1 핵심)

```mermaid

erDiagram

STAFF {

String code PK

String name

String password

String permission

Int status

}

CUSTOMER {

String code PK

Int compType

String name

String businessNo

String phone

}

CUSTOMERSTAFF {

Int id PK

String customerCode FK

String name

String phone

}

CUSTOMERITEM {

Int id PK

String customerCode FK

String itemCode FK

Int price

}

ITEM {

String code PK

String category

String name

String unit

BigInt purchasePrice

BigInt price

}

ITEMCLASS {

Int id PK

String itemCode FK

String subclass

}

UNITGROUP {

String itemCode FK

Float standardQty

String unitName

}

LOCATION {

String code PK

Int locationType

String name

}

PROJECT {

String code PK

String name

DateTime startDay

DateTime endDay

}

PURCHASEREQUEST {

String code PK

DateTime dday

String staffName

Int status

}

PRDETAIL {

Int id PK

String prCode FK

String itemCode FK

Float qty

BigInt price

}

PURCHASEORDER {

String code PK

DateTime dday

String customerCode FK

Int status

}

PODETAIL {

Int id PK

String poCode FK

String itemCode FK

Float qty

BigInt price

}

PURCHASE {

String code PK

Int tradeType

DateTime dday

String customerCode FK

String locationCode FK

Int status

}

PURCHASEDETAIL {

Int id PK

String purchaseCode FK

String itemCode FK

Float qty

Float realQty

BigInt price

}

QUOTATION {

String code PK

Int type

DateTime dday

String customerCode FK

Int status

}

QUOTATIONDETAIL {

Int id PK

String quotationCode FK

String itemCode FK

Float qty

BigInt price

}

SALESORDER {

String code PK

DateTime dday

String customerCode FK

Int status

}

SODETAIL {

Int id PK

String soCode FK

String itemCode FK

Float qty

BigInt price

}

SALES {

String code PK

Int tradeType

DateTime dday

String customerCode FK

String locationCode FK

Int status

}

SALEDETAIL {

Int id PK

String salesCode FK

String itemCode FK

Float qty

Float realQty

BigInt cost

BigInt price

}

STOCK {

Int id PK

String locationCode FK

String itemCode FK

String subclass

String projectCode FK

Float qty

}

STOCKCHANGE {

Int id PK

Int stockIndex FK

DateTime changeDate

Float oldQty

Float newQty

String changeCode

}

LOCATETRAN {

String code PK

DateTime dday

String locationOutCode FK

String locationInCode FK

Int status

}

LOCATETRANDETAIL {

Int id PK

String locateTranCode FK

String itemCode FK

Float qty

Float realQty

}

%% 기준정보 관계

CUSTOMER ||--o{ CUSTOMERSTAFF : "has"

CUSTOMER ||--o{ CUSTOMERITEM : "has"

CUSTOMERITEM }o--|| ITEM : "references"

ITEM ||--o{ ITEMCLASS : "has"

ITEM ||--o{ UNITGROUP : "has"

%% 구매 관계

PURCHASEREQUEST ||--o{ PRDETAIL : "has"

PRDETAIL }o--|| ITEM : "references"

PURCHASEORDER ||--o{ PODETAIL : "has"

PODETAIL }o--|| ITEM : "references"

PURCHASEORDER }o--|| CUSTOMER : "from"

PURCHASE ||--o{ PURCHASEDETAIL : "has"

PURCHASEDETAIL }o--|| ITEM : "references"

PURCHASE }o--|| CUSTOMER : "from"

PURCHASE }o--|| LOCATION : "to"

%% 영업 관계

QUOTATION ||--o{ QUOTATIONDETAIL : "has"

QUOTATIONDETAIL }o--|| ITEM : "references"

QUOTATION }o--|| CUSTOMER : "to/from"

SALESORDER ||--o{ SODETAIL : "has"

SODETAIL }o--|| ITEM : "references"

SALESORDER }o--|| CUSTOMER : "to"

SALES ||--o{ SALEDETAIL : "has"

SALEDETAIL }o--|| ITEM : "references"

SALES }o--|| CUSTOMER : "to"

SALES }o--|| LOCATION : "from"

%% 재고 관계

STOCK }o--|| ITEM : "for"

STOCK }o--|| LOCATION : "at"

STOCK ||--o{ STOCKCHANGE : "tracks"

LOCATETRAN ||--o{ LOCATETRANDETAIL : "has"

LOCATETRANDETAIL }o--|| ITEM : "references"

```

## # 구매→재고 연동 흐름

```mermaid

sequenceDiagram

actor User

participant PR as 구매요청

participant PO as 발주

participant RC as 입고

participant API as API Route

participant DB as PostgreSQL

participant STK as 재고(STOCK)

participant LOG as 이력(STOCKCHANGE)

User->>PR: 1. 구매요청 등록

PR->>PR: 요청 상태 (status=0)

User->>PR: 2. 구매요청 확정 (status=1)

User->>PO: 3. 발주 변환 (from-request)

Note over PR,PO: 구매요청 품목 복사

PO->>PO: 작성 상태 (status=0)

User->>PO: 4. 발주 확정 (status=1)

User->>RC: 5. 입고 변환 (from-order)

Note over PO,RC: 미입고 수량만 표시

RC->>RC: 작성 상태 (status=0)

User->>RC: 6. 입고 확정

RC->>API: POST /confirm

API->>DB: BEGIN TRANSACTION

API->>STK: UPDATE qty = qty + amount

API->>LOG: INSERT change record

API->>RC: UPDATE status = 1

API->>DB: COMMIT

API-->>User: ✅ 입고 완료, 재고 증가

```

## # 영업→재고 연동 흐름

```mermaid

sequenceDiagram

actor User

participant QT as 견적서

participant SO as 수주

participant SH as 출고

participant API as API Route

participant DB as PostgreSQL

participant STK as 재고(STOCK)

participant LOG as 이력(STOCKCHANGE)

User->>QT: 1. 견적서 등록 (보낸견적)

User->>QT: 2. 견적 확정

User->>SO: 3. 수주 변환 (from-quotation)

Note over QT,SO: 견적 품목 복사

User->>SO: 4. 수주 확정 (status=1)

User->>SH: 5. 출고 변환 (from-order)

Note over SO,SH: 미출고 수량만 표시

User->>SH: 창고 선택 (locationCode)

User->>SH: 6. 출고 확정

SH->>API: POST /confirm

API->>DB: BEGIN TRANSACTION

API->>STK: CHECK qty >= amount

alt 재고 충분

API->>STK: UPDATE qty = qty - amount

API->>LOG: INSERT change record

API->>SH: UPDATE status = 1

API->>DB: COMMIT

API-->>User: ✅ 출고 완료, 재고 감소

else 재고 부족

API->>DB: ROLLBACK

API-->>User: ❌ 재고 부족 오류

end

```

## # Parallel Execution Waves

```

Wave 1 (Start Immediately - foundation):

├── Task 1: Next.js 프로젝트 스캐폴딩 + 핵심 설정 [quick]

├── Task 2: Prisma 스키마 설계 - 기준정보/공통 [deep]

├── Task 3: 인증 시스템 구현 [unspecified-high]

└── Task 4: 공통 UI 컴포넌트 + 레이아웃 [visual-engineering]

Wave 2 (After Wave 1 - master data + purchasing):

├── Task 5: 기준정보 - 거래처 관리 [unspecified-high]

├── Task 6: 기준정보 - 품목 관리 [unspecified-high]

├── Task 7: 기준정보 - 창고/직원/프로젝트 관리 [unspecified-high]

├── Task 8: 구매 - 구매요청 관리 [unspecified-high]

└── Task 9: 구매 - 발주 + 입고 관리 [unspecified-high]

Wave 3 (After Wave 2 - sales + inventory):

├── Task 10: 영업 - 견적서 관리 [unspecified-high]

├── Task 11: 영업 - 수주 + 출고 관리 [unspecified-high]

├── Task 12: 재고 - 현재고 + 재고조정 [unspecified-high]

└── Task 13: 재고 - 창고이동 + 이력 관리 [unspecified-high]

Wave 4 (After Wave 3 - integration):

├── Task 14: 대시보드 + 통계 [unspecified-high]

├── Task 15: Firebird → PostgreSQL 데이터 마이그레이션 [deep]

└── Task 16: PDF 인쇄 시스템 [unspecified-high]

Wave 5 (After Wave 4 - polish):

├── Task 17: Excel 내보내기 + 일괄 입력 [quick]

└── Task 18: 통합 테스트 + 버그 수정 [deep]

Wave FINAL (After ALL — 4 parallel reviews):

├── Task F1: Plan compliance audit (oracle)

├── Task F2: Code quality review (unspecified-high)

├── Task F3: Real manual QA (unspecified-high + playwright)

└── Task F4: Scope fidelity check (deep)

→ Present results → Get explicit user okay

Critical Path: T1 → T2 → T5/T6 → T8 → T11 → T12 → T14 → T15 → FINAL

Parallel Speedup: ~60% faster than sequential

Max Concurrent: 5 (Wave 2)

```

## # Dependency Matrix

|------|-----------|--------|------|

| 1 | - | 2, 3, 4 | 1 |

| 2 | 1 | 5, 6, 7, 8, 9, 10, 11, 12, 13 | 1 |

| 3 | 1 | 5-18 | 1 |

| 4 | 1 | 5-18 | 1 |

| 5 | 2, 3, 4 | 8, 10, 14 | 2 |

| 6 | 2, 3, 4 | 8, 9, 10, 11, 12 | 2 |

| 7 | 2, 3, 4 | 14 | 2 |

| 8 | 2, 3, 4, 5, 6 | 9, 14, 15 | 2 |

| 9 | 2, 3, 4, 6, 8 | 14, 15 | 2 |

| 10 | 2, 3, 4, 5, 6 | 11, 14, 15 | 3 |

| 11 | 2, 3, 4, 6, 10 | 12, 14, 15 | 3 |

| 12 | 2, 3, 4, 6, 11 | 13, 14, 15 | 3 |

| 13 | 2, 3, 4, 12 | 14, 15 | 3 |

| 14 | 5-13 | 17, 18 | 4 |

| 15 | 2 | 18 | 4 |

| 16 | 4, 8, 10, 11 | 18 | 4 |

| 17 | 14 | 18 | 5 |

| 18 | 14-17 | FINAL | 5 |

## # Agent Dispatch Summary

- **Wave 1**: 4 tasks - T1→`quick`, T2→`deep`, T3→`unspecified-high`, T4→`visual-engineering`

- **Wave 2**: 5 tasks - T5-T9→`unspecified-high`

- **Wave 3**: 4 tasks - T10-T13→`unspecified-high`

- **Wave 4**: 3 tasks - T14→`unspecified-high`, T15→`deep`, T16→`unspecified-high`

- **Wave 5**: 2 tasks - T17→`quick`, T18→`deep`

- **FINAL**: 4 tasks - F1→`oracle`, F2→`unspecified-high`, F3→`unspecified-high`, F4→`deep`

---

# # TODOs

> Implementation + Test = ONE Task. Never separate.

> EVERY task MUST have: Recommended Agent Profile + Parallelization info + QA Scenarios.

- [x] 1. Next.js 프로젝트 스캐폴딩 + 핵심 설정

**What to do**:

- `npx create-next-app@latest` with App Router, TypeScript, Tailwind CSS, ESLint

- 핵심 의존성 설치: prisma, @prisma/client, zod, react-hook-form, @tanstack/react-table, zustand, date-fns, lucide-react, next-themes, jose (JWT), bcryptjs

- shadcn/ui 초기화: `npx shadcn@latest init` + 필수 컴포넌트 설치 (button, input, dialog, table, form, select, date-picker, card, badge, tabs, dropdown-menu, command, sheet, separator, toast, skeleton, pagination)

- 프로젝트 구조 생성:

```

src/

├── app/ # Next.js App Router pages

│ ├── (auth)/ # 인증 관련 페이지 (login)

│ ├── (dashboard)/ # 메인 대시보드 레이아웃

│ │ ├── master/ # 기준정보

│ │ ├── purchase/ # 구매

│ │ ├── sales/ # 영업

│ │ └── inventory/# 재고

│ └── api/ # API Routes

├── components/ # 공통 컴포넌트

│ ├── ui/ # shadcn/ui 컴포넌트

│ └── shared/ # 프로젝트 공통 컴포넌트

├── lib/ # 유틸리티, 설정

│ ├── prisma.ts # Prisma 클라이언트 싱글톤

│ ├── auth.ts # JWT 인증 유틸

│ └── utils.ts # 공통 유틸

├── types/ # TypeScript 타입 정의

└── hooks/ # 커스텀 훅

```

```mermaid

graph TB

APP["app/"]

AUTH["(auth)/login/"]

DASH["(dashboard)/"]

MASTER["master/ customers, items, locations, staffs, projects"]

PUR["purchase/ requests, orders, receiving"]

SAL["sales/ quotations, orders, shipping"]

INV["inventory/ stock, transfers, adjustments"]

REP["reports/"]

API_DIR["api/ auth, customers, items, purchases, sales, inventory"]

COMP["components/ ui/ (shadcn), shared/"]

LIB["lib/ prisma, auth, pdf, excel"]

APP --> AUTH

APP --> DASH

APP --> API_DIR

DASH --> MASTER

DASH --> PUR

DASH --> SAL

DASH --> INV

DASH --> REP

style APP fill:#3b82f6,color:#fff

style AUTH fill:#ef4444,color:#fff

style DASH fill:#10b981,color:#fff

style API_DIR fill:#f59e0b,color:#fff

```

- `.env` 파일 생성 (DATABASE_URL, JWT_SECRET, FIREBIRD_DB_PATH)

- PostgreSQL 실행 확인 (로컬 또는 Docker)

- `npx prisma init` 실행

**Must NOT do**:

- 비즈니스 로직 구현 금지

- 과도한 설정 (가장 간단한 시작 설정)

**Recommended Agent Profile**:

- **Category**: `quick`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: NO (foundation)

- **Parallel Group**: Wave 1

- **Blocks**: T2, T3, T4

- **Blocked By**: None

**References**:

- `[PROJECT_PATH]\_schema_columns.txt` - 전체 DB 스키마 (구조 설계 참고)

- Next.js App Router docs: https://nextjs.org/docs/app

- shadcn/ui: https://ui.shadcn.com/docs/installation/next

**Acceptance Criteria**:

- [x] `npm run dev` 실행 시 localhost:3000 접속 가능

- [x] shadcn/ui Button 컴포넌트 렌더링 확인

- [x] Prisma 클라이언트 초기화 (`npx prisma generate` 성공)

- [x] `.env` 파일에 DATABASE_URL 설정됨

**QA Scenarios (MANDATORY)**:

```

Scenario: Next.js 개발 서버 시작

Tool: Bash

Preconditions: 프로젝트 디렉토리 존재

Steps:

1. cd [PROJECT_PATH] && npm run dev (백그라운드)

2. curl http://localhost:3000 → HTTP 200 확인

3. 응답 본문에 "__next" 포함 확인

Expected Result: HTTP 200, Next.js 페이지 로드

Evidence: .sisyphus/evidence/task-1-dev-server.txt

Scenario: Prisma 설정 확인

Tool: Bash

Preconditions: prisma init 완료

Steps:

1. npx prisma validate → "The schema is valid" 확인

2. npx prisma generate → "generated" 메시지 확인

Expected Result: Prisma 스키마 유효, 클라이언트 생성 성공

Evidence: .sisyphus/evidence/task-1-prisma-setup.txt

```

**Commit**: YES

- Message: `feat(init): Next.js project scaffolding with Prisma, shadcn/ui`

- Files: 전체 프로젝트 초기 파일

- [x] 2. Prisma 스키마 설계 - 기준정보/공통/구매/영업/재고

**What to do**:

- Firebird 스키마 기반으로 Prisma 스키마 설계 (`prisma/schema.prisma`)

- **공통 모델**:

- `Staff` (STAFF) - code, name, password, partName, permission, status, partIndex

- `Department` (DEPARTMENT) - id, customerCode, partName, parentIndex

- `TaxRate` (TAXRATE) - taxName, taxRate, remark

- `ExchangeRate` (EXCHANGERATE) - id, currencyName1, exchangeAmount1, currencyName2, exchangeAmount2

- `CodeSet` (CODESET) - codeName, digitCode, preString, postString, autoInput

- `AutoIncIndex` (CM_AUTOINCINDEX) - tblName, maxIndex

- **기준정보 모델**:

- `Customer` (CUSTOMER) - code, compType, group1, group2, name, ceo, businessNo, phone, fax, mobile, email, address, dcRate, keyword, status, memo, nonTaxable

- `CustomerStaff` (CUSTOMERSTAFF) - id, customerCode, partName, name, jobPosition, phone, fax, mobile, email, keyword, memo, partIndex

- `CustomerItem` (CUSTOMERITEM) - id, customerCode, itemCode, orderPriority, oemName, dsPrice, dcRate, price, currency, csMinsoUnit, leadTime, remark, oemCode

- `Item` (ITEM) - code, category, type, name, description, barcode, maker, vendor, safetyStock, csMinsoUnit, unit, volume, volumeUnit, weight, weightUnit, leadTime, purchasePrice, purchaseCurr, price, priceCurr, keyword, status, memo, expPeriod, expUnit

- `ItemClass` (ITEMCLASS) - id, itemCode, subclass, remark, status

- `UnitGroup` (UNITGROUP) - itemCode, standardQty, unitName, changeRate

- `SpecialPrice` (SPECIALPRICE) - id, itemCode, priceType, purchasePrice, purchaseCurr, price, priceCurr, remark

- `Location` (LOCATION) - code, locationType, name, remark

- `LocationStaff` (LOCATIONSTAFF) - id, locationCode, staffCode, remark

- `Project` (PROJECT) - code, name, startDay, endDay, status, keyword, memo

- **구매 모델**:

- `PurchaseRequest` + `PurchaseRequestDetail` (PURCHASEREQUEST + PRDETAIL)

- `PurchaseOrder` + `PurchaseOrderDetail` (PURCHASEORDER + PODETAIL)

- `Purchase` + `PurchaseDetail` (PURCHASE + PURCHASEDETAIL)

- **영업 모델**:

- `Quotation` + `QuotationDetail` (QUOTATION + QUOTATIONDETAIL)

- `SalesOrder` + `SalesOrderDetail` (SALESORDER + SODETAIL)

- `Sale` + `SaleDetail` (SALES + SALESDETAIL)

- `PackingList` + `PackingDetail` + `PackingItem` (PACKINGLIST + PKGSDETAIL + PKGSITEMS)

- **재고 모델**:

- `Stock` (STOCK) - id, isInternal, projectCode, locationCode, itemCode, subclass, qty, remark (복합 unique: locationCode + itemCode + subclass + projectCode)

- `StockChange` (STOCKCHANGE) - id, stockIndex, changeDate, oldQty, newQty, changeCode, changeReason, writer

- `StockLog` (STCGLOG) - stockIndex, isInternal, logDate, logTime, oldQty, newQty, unit, workDate, baseType, writer

- `LocateTran` + `LocateTranDetail` (LOCATETRAN + LOCATETRANDETAIL)

- `Warehouse` (WAREHOUSE) - code, dday, whDate, whType, staffName, customerCode, locationCode, itemCode, qty, price, tax, keyword, writer, wrDate, memo

- **관계 설정**: Customer → CustomerStaff, CustomerItem / Item → ItemClass, UnitGroup / 등

- `npx prisma migrate dev --name init` 실행

- `prisma/seed.ts` 작성 (관리자 계정, 기본 세율, 기본 창고)

**Must NOT do**:

- 생산/회계/BOM 모델 생성 금지 (v2)

- 기존 Firebird 컬럼명 그대로 복사 금지 - camelCase로 변환

- BLOB 필드는 String (Text) 또는 Bytes 로 매핑

**Recommended Agent Profile**:

- **Category**: `deep`

- **Skills**: []

**Parallelization**:

- **Can Run In Parallel**: NO (T1 선행 필요)

- **Parallel Group**: Wave 1

- **Blocks**: T5-T13, T15

- **Blocked By**: T1

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` - 전체 Firebird 스키마 (각 테이블의 컬럼, 타입, nullable 정보)

**API/Type References**:

- Prisma schema docs: https://www.prisma.io/docs/reference/prisma-schema

**WHY Each Reference Matters**:

- `_schema_columns.txt`의 각 테이블 정의를 camelCase로 변환하여 Prisma 모델로 매핑. 컬럼 타입(Integer→Int, Float→Float, Bigint→BigInt, Date→DateTime) 변환 필수.

**Acceptance Criteria**:

- [x] `npx prisma validate` → 성공

- [x] `npx prisma migrate dev` → 마이그레이션 생성 성공

- [x] 모든 v1 테이블이 Prisma 모델로 정의됨 (약 30개 모델)

- [x] seed 스크립트 실행 시 기본 데이터 생성됨

**QA Scenarios (MANDATORY)**:

```

Scenario: Prisma 스키마 유효성

Tool: Bash

Preconditions: schema.prisma 작성 완료

Steps:

1. npx prisma validate → exit code 0

2. npx prisma migrate dev --name init → "Applied init migration" 확인

3. npx prisma generate → "generated" 확인

Expected Result: 마이그레이션 적용, 클라이언트 생성 성공

Evidence: .sisyphus/evidence/task-2-schema-valid.txt

Scenario: 기본 데이터 시딩

Tool: Bash

Preconditions: 마이그레이션 완료

Steps:

1. npx prisma db seed → exit code 0

2. npx prisma studio 로 Staff 테이블 확인 (또는 psql 쿼리)

3. 관리자 계정 존재 확인

Expected Result: seed 데이터 정상 생성

Evidence: .sisyphus/evidence/task-2-seed-data.txt

```

**Commit**: YES (groups with T1)

- Message: `feat(schema): Prisma schema for master data, purchasing, sales, inventory`

- Files: prisma/schema.prisma, prisma/seed.ts, prisma/migrations/

- [x] 3. 인증 시스템 구현

**What to do**:

```mermaid

sequenceDiagram

actor User as 👤 사용자

participant Login as /login 페이지

participant API as /api/auth/login

participant DB as PostgreSQL (STAFF)

participant JWT as JWT (jose)

participant MW as Middleware

participant Page as 대시보드

User->>Login: 1. 직원코드 + 비밀번호 입력

API->>DB: 3. SELECT * FROM Staff WHERE code = ?

alt 계정 존재

DB-->>API: Staff 레코드 반환

API->>API: 4. 비밀번호 비교

alt 비밀번호 일치

API->>JWT: 5. JWT 토큰 생성

JWT-->>API: {staffCode, name, partIndex}

API->>API: 6. httpOnly 쿠키 설정

API-->>Login: 200 OK + Set-Cookie: token

Page->>MW: 8. 모든 요청마다 토큰 검증

MW->>JWT: 9. verify(token)

JWT-->>MW: decoded payload

MW-->>Page: ✅ 인증됨, 페이지 렌더링

else 비밀번호 불일치

API-->>Login: 401 "비밀번호가 틀렸습니다"

end

else 계정 없음

DB-->>API: null

API-->>Login: 401 "존재하지 않는 계정입니다"

end

```

- `src/lib/auth.ts` - JWT 기반 인증 유틸리티 (jose 라이브러리)

- `signToken(staff)` - JWT 토큰 생성 (staffCode, name, partIndex 포함)

- `verifyToken(token)` - 토큰 검증

- `getStaffFromRequest(request)` - 쿠키에서 토큰 읽고 검증

- `src/middleware.ts` - Next.js 미들웨어 (보호된 라우트 검사)

- `/login` 제외한 모든 라우트에 인증 필요

- 토큰 만료 시 `/login`으로 리다이렉트

- `src/app/(auth)/login/page.tsx` - 로그인 페이지

- 직원코드 + 비밀번호 입력 폼

- 에러 메시지 표시

- `src/app/api/auth/login/route.ts` - 로그인 API

- STAFF 테이블에서 코드+비밀번호 확인

- 성공 시 JWT 토큰을 httpOnly 쿠키에 저장

- 실패 시 401 응답

- `src/app/api/auth/logout/route.ts` - 로그아웃 API (쿠키 삭제)

- **비밀번호**: 기존 STAFF.PASSWORD가 평문일 가능성 → 로그인 시 평문 비교, 로그인 성공 시 bcrypt 해시로 자동 업그레이드

- 관리자 초기 계정: seed에서 생성

**Must NOT do**:

- OAuth/소셜 로그인 구현 금지

- 복잡한 권한 시스템 (v1은 관리자/일반 2단계만)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: []

**Parallelization**:

- **Can Run In Parallel**: YES (T2와 병렬 가능, T1만 선행)

- **Parallel Group**: Wave 1 (with T2, T4)

- **Blocks**: T5-T18

- **Blocked By**: T1

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → STAFF 테이블: CODE(VARCHAR 120), NAME(VARCHAR 160), PASSWORD(VARCHAR 120), PERMISSION(CHAR 324), STATUS(INTEGER), PARTINDEX(INTEGER)

- Next.js middleware docs: https://nextjs.org/docs/app/building-your-application/routing/middleware

**Acceptance Criteria**:

- [x] `/login` 페이지에서 admin/admin으로 로그인 성공

- [x] 로그인 후 대시보드 페이지 접속 가능

- [x] 비인증 상태에서 보호된 라우트 접근 시 `/login`으로 리다이렉트

- [x] 로그아웃 후 세션 만료

**QA Scenarios (MANDATORY)**:

```

Scenario: 정상 로그인

Tool: Bash (curl)

Preconditions: seed 데이터로 admin 계정 존재

Steps:

1. curl -X POST http://localhost:3000/api/auth/login -H "Content-Type: application/json" -d '{"code":"[USER]","password":"[PASS]"}'

2. HTTP 200 확인, 응답에 "success" 포함

3. Set-Cookie 헤더에 token 존재 확인

Expected Result: JWT 토큰 발급, 쿠키 설정

Evidence: .sisyphus/evidence/task-3-login-success.txt

Scenario: 잘못된 비밀번호

Tool: Bash (curl)

Preconditions: admin 계정 존재

Steps:

1. curl -X POST http://localhost:3000/api/auth/login -H "Content-Type: application/json" -d '{"code":"[USER]","password":"[WRONG_PASS]"}'

2. HTTP 401 확인

Expected Result: 인증 실패, 에러 메시지 반환

Evidence: .sisyphus/evidence/task-3-login-fail.txt

Scenario: 보호된 라우트 접근

Tool: Bash (curl)

Preconditions: 로그아웃 상태

Steps:

1. curl -v http://localhost:3000/dashboard → 302 redirect to /login 확인

Expected Result: 비인증 시 로그인 페이지로 리다이렉트

Evidence: .sisyphus/evidence/task-3-protected-route.txt

```

**Commit**: YES (groups with T4)

- Message: `feat(auth): JWT authentication with STAFF-based login`

- Files: src/lib/auth.ts, src/middleware.ts, src/app/(auth)/, src/app/api/auth/

- [x] 4. 공통 UI 컴포넌트 + 레이아웃

**What to do**:

- **메인 레이아웃** (`src/app/(dashboard)/layout.tsx`):

- 좌측 사이드바 네비게이션 (접기/펼치기 가능)

- 상단 헤더 (로고, 사용자명, 로그아웃 버튼)

- 메인 콘텐츠 영역

- 다크모드 토글

- **사이드바 메뉴 구조**:

```

📊 대시보드

📋 기준정보

├─ 거래처 관리

├─ 품목 관리

├─ 창고 관리

├─ 직원 관리

└─ 프로젝트 관리

🛒 구매

├─ 구매요청

├─ 발주 관리

└─ 입고 관리

🏭 영업

├─ 견적 관리

├─ 수주 관리

└─ 출고 관리

📦 재고

├─ 현재고 조회

├─ 창고이동

└─ 재고조정

```

- **공통 컴포넌트**:

- `DataTable` - TanStack Table 기반 데이터 테이블 (정렬, 필터, 페이지네이션, 행 선택)

- `SearchInput` - 디바운스 검색 입력

- `DateRangePicker` - 기간 검색

- `FormDialog` - 생성/수정 다이얼로그 (공통 폼 래퍼)

- `DeleteConfirmDialog` - 삭제 확인 다이얼로그

- `StatusBadge` - 상태 표시 뱃지

- `PageHeader` - 페이지 제목 + 액션 버튼

- **대시보드 홈페이지** (`src/app/(dashboard)/page.tsx`) - 빈 뼈대 (T14에서 내용 채움)

**Must NOT do**:

- 비즈니스 로직 포함 금지

- 과도한 공통 컴포넌트 추상화 (필요한 것만)

**Recommended Agent Profile**:

- **Category**: `visual-engineering`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T2, T3과 병렬)

- **Parallel Group**: Wave 1

- **Blocks**: T5-T18

- **Blocked By**: T1

**References**:

- shadcn/ui sidebar: https://ui.shadcn.com/docs/components/sidebar

- TanStack Table: https://tanstack.com/table/latest

**Acceptance Criteria**:

- [x] 로그인 후 사이드바 레이아웃 표시

- [x] 모든 메뉴 항목이 사이드바에 표시됨

- [x] 사이드바 접기/펼치기 동작

- [x] 다크모드 전환 동작

- [x] DataTable 컴포넌트 렌더링 (더미 데이터로)

**QA Scenarios (MANDATORY)**:

```

Scenario: 레이아웃 렌더링

Tool: Playwright

Preconditions: 로그인 완료 상태

Steps:

1. http://localhost:3000 이동

2. 사이드바 요소 확인: text "대시보드" 존재

3. text "기준정보" 존재

4. text "구매" 존재

5. text "영업" 존재

6. text "재고" 존재

7. 헤더에 로그아웃 버튼 존재

Expected Result: 전체 레이아웃 렌더링

Evidence: .sisyphus/evidence/task-4-layout.png

Scenario: 다크모드 전환

Tool: Playwright

Preconditions: 로그인 완료

Steps:

1. 다크모드 토글 버튼 클릭

2. html 요소에 class="dark" 추가 확인

3. 배경색이 어두운 색으로 변경 확인

Expected Result: 다크/라이트 모드 전환

Evidence: .sisyphus/evidence/task-4-darkmode.png

```

**Commit**: YES (groups with T3)

- Message: `feat(ui): shared layout, sidebar navigation, common components`

- Files: src/app/(dashboard)/layout.tsx, src/components/shared/

- [x] 5. 기준정보 - 거래처 관리

**What to do**:

- **API Routes** (`src/app/api/customers/`):

- `GET /api/customers` - 목록 조회 (검색: name, code, businessNo, keyword / 필터: group1, group2, status / 페이지네이션 / 정렬)

- `POST /api/customers` - 생성 (code 자동생성 옵션)

- `GET /api/customers/[code]` - 상세 조회 (staff, items 포함)

- `PUT /api/customers/[code]` - 수정

- `DELETE /api/customers/[code]` - 삭제 (참조 데이터 없을 때만)

- `GET /api/customers/[code]/staffs` - 담당자 목록

- `POST/PUT/DELETE /api/customers/[code]/staffs` - 담당자 CRUD

- `GET /api/customers/[code]/items` - 취급품목 목록

- `POST/PUT/DELETE /api/customers/[code]/items` - 취급품목 CRUD

- **페이지** (`src/app/(dashboard)/master/customers/`):

- `page.tsx` - 거래처 목록 (DataTable + 검색 + 필터)

- `[code]/page.tsx` - 거래처 상세/수정 (탭: 기본정보, 담당자, 취급품목, 메모)

- `new/page.tsx` - 신규 등록

- Zod 스키마로 입력 검증 (businessNo 형식, 이메일 형식 등)

**Must NOT do**:

- 참조 무결성 검사 없이 거래처 삭제 금지 (구매/영업에서 참조 중이면 삭제 차단)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T6, T7과 병렬)

- **Parallel Group**: Wave 2

- **Blocks**: T8, T10, T14

- **Blocked By**: T2, T3, T4

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → CUSTOMER 테이블 (17개 컬럼), CUSTOMERSTAFF (12개), CUSTOMERITEM (13개)

- CUSTOMER.CODE가 VARCHAR(120)으로 PK → Prisma에서 @id @default(autoincrement) 대신 @id (수동 또는 자동생성)

**Acceptance Criteria**:

- [x] 거래처 목록 페이지에서 검색/필터/정렬 동작

- [x] 신규 거래처 등록 후 목록에 표시

- [x] 거래처 상세에서 담당자/취급품목 탭 전환 동작

- [x] Zod 검증으로 잘못된 입력 차단

**QA Scenarios (MANDATORY)**:

```

Scenario: 거래처 CRUD

Tool: Playwright + Bash (curl)

Preconditions: 로그인 상태

Steps:

1. curl POST /api/customers -d '{"code":"C001","name":"테스트거래처","compType":1,"phone":"02-1234-5678"}' → 201

2. curl GET /api/customers?search=테스트 → 응답에 "C001" 포함

3. curl PUT /api/customers/C001 -d '{"name":"수정된거래처"}' → 200

4. Playwright: /master/customers 페이지에서 "수정된거래처" 검색 → 결과 1건

5. curl DELETE /api/customers/C001 → 200

6. curl GET /api/customers?search=C001 → 빈 배열

Expected Result: 전체 CRUD 사이클 동작

Evidence: .sisyphus/evidence/task-5-customer-crud.txt

Scenario: 잘못된 사업자등록번호

Tool: Bash (curl)

Steps:

1. curl POST /api/customers -d '{"code":"C002","name":"테스트","businessNo":"invalid"}' → 400

Expected Result: Zod 검증 에러

Evidence: .sisyphus/evidence/task-5-validation.txt

```

**Commit**: YES

- Message: `feat(master): customer management with CRUD, search, filter`

- [x] 6. 기준정보 - 품목 관리

**What to do**:

- **API Routes** (`src/app/api/items/`):

- `GET /api/items` - 목록 (검색: name, code, barcode, keyword / 필터: category, type, status)

- `POST /api/items` - 생성

- `GET /api/items/[code]` - 상세 (unitGroups, specialPrices, itemClasses 포함)

- `PUT /api/items/[code]` - 수정

- `DELETE /api/items/[code]` - 삭제

- `GET/POST/PUT/DELETE /api/items/[code]/units` - 단위그룹 CRUD

- `GET/POST/PUT/DELETE /api/items/[code]/prices` - 특별단가 CRUD

- `GET/POST/PUT/DELETE /api/items/[code]/classes` - 소분류 CRUD

- **페이지** (`src/app/(dashboard)/master/items/`):

- `page.tsx` - 품목 목록 (카테고리 트리 + 목록)

- `[code]/page.tsx` - 품목 상세/수정 (탭: 기본정보, 소분류, 단위, 특별단가, 이미지)

- `new/page.tsx` - 신규 등록

- 품목 상태 관리 (사용/미사용)

**Must NOT do**:

- 이미지 업로드는 기본 구현만 (파일 시스템 저장)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T5, T7과 병렬)

- **Parallel Group**: Wave 2

- **Blocks**: T8, T9, T10, T11, T12

- **Blocked By**: T2, T3, T4

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → ITEM 테이블 (25개 컬럼), ITEMCLASS (5개), UNITGROUP (4개), SPECIALPRICE (8개)

- ITEM.TYPE: INTEGER → 품목 유형 (매입/매출/ both 등)

- ITEM.CATEGORY: VARCHAR(120) → 대분류 코드

**Acceptance Criteria**:

- [x] 품목 목록에서 검색/카테고리 필터 동작

- [x] 품목 등록/수정/삭제 동작

- [x] 단위그룹/특별단가 서브 폼 동작

**QA Scenarios (MANDATORY)**:

```

Scenario: 품목 CRUD

Tool: Bash (curl)

Steps:

1. POST /api/items {"code":"I001","name":"테스트품목","unit":"EA","purchasePrice":1000,"price":2000} → 201

2. GET /api/items?search=테스트 → I001 포함

3. PUT /api/items/I001 {"name":"수정품목"} → 200

4. DELETE /api/items/I001 → 200

Expected Result: 전체 CRUD 동작

Evidence: .sisyphus/evidence/task-6-item-crud.txt

Scenario: 품목 상세 서브탭

Tool: Playwright

Steps:

1. 품목 등록 (API로)

2. /master/items/I001 접속

3. "소분류" 탭 클릭 → 빈 목록 표시

4. "단위" 탭 클릭 → 기본 단위 표시

5. "특별단가" 탭 클릭 → 빈 목록 표시

Expected Result: 탭 전환 동작, 서브 데이터 표시

Evidence: .sisyphus/evidence/task-6-item-detail.png

```

**Commit**: YES

- Message: `feat(master): item management with units, special prices, subclasses`

- [x] 7. 기준정보 - 창고/직원/프로젝트/공통코드 관리

**What to do**:

- **창고 관리** (`src/app/(dashboard)/master/locations/`):

- API: `GET/POST/PUT/DELETE /api/locations`

- 페이지: 목록 + 등록/수정 다이얼로그

- Location 코드, 이름, 유형 (자재창고/제품창고/외주창고 등)

- **직원 관리** (`src/app/(dashboard)/master/staffs/`):

- API: `GET/POST/PUT/DELETE /api/staffs`

- 페이지: 목록 + 등록/수정 다이얼로그

- 비밀번호 초기화 기능

- **프로젝트 관리** (`src/app/(dashboard)/master/projects/`):

- API: `GET/POST/PUT/DELETE /api/projects`

- 페이지: 목록 + 등록/수정 다이얼로그

- 프로젝트 상태 (진행중/완료/중단)

- **공통 코드 관리** (`src/app/(dashboard)/master/codes/`):

- 세율 관리 (TAXRATE)

- 환율 관리 (EXCHANGERATE)

- 코드 자동증가 설정 (CODESET)

**Must NOT do**:

- 복잡한 권한 편집 UI (v1은 기본만)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T5, T6과 병렬)

- **Parallel Group**: Wave 2

- **Blocks**: T14

- **Blocked By**: T2, T3, T4

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → LOCATION (4개), STAFF (10개), PROJECT (8개), TAXRATE (3개), EXCHANGERATE (8개)

**Acceptance Criteria**:

- [x] 각 기준정보 CRUD 동작

- [x] 직원 비밀번호 초기화 동작

**QA Scenarios (MANDATORY)**:

```

Scenario: 창고/직원/프로젝트 CRUD

Tool: Bash (curl)

Steps:

1. POST /api/locations {"code":"W001","name":"메인창고","locationType":1} → 201

2. POST /api/staffs {"code":"S001","name":"홍길동","partName":"영업부"} → 201

3. POST /api/projects {"code":"P001","name":"2024프로젝트","startDay":"2024-01-01","endDay":"2024-12-31"} → 201

4. GET /api/locations → W001 포함

5. GET /api/staffs → S001 포함

6. GET /api/projects → P001 포함

Expected Result: 모든 기준정보 CRUD 동작

Evidence: .sisyphus/evidence/task-7-master-data.txt

```

**Commit**: YES

- Message: `feat(master): location, staff, project, tax/exchange rate management`

- [x] 8. 구매 - 구매요청 관리

**What to do**:

- **API Routes** (`src/app/api/purchase-requests/`):

- `GET` - 목록 (검색: code, staffName, keyword / 필터: status, dateRange)

- `POST` - 생성 (헤더 + 상세 동시 생성)

- `GET /[code]` - 상세 (details 포함)

- `PUT /[code]` - 수정

- `DELETE /[code]` - 삭제 (미확정 상태만)

- `POST /[code]/confirm` - 구매요청 확정 (상태 변경)

- **페이지** (`src/app/(dashboard)/purchase/requests/`):

- `page.tsx` - 구매요청 목록 (상태별 탭: 전체/요청중/확정)

- `[code]/page.tsx` - 상세/수정 (헤더 정보 + 품목 행 추가/삭제)

- `new/page.tsx` - 신규 등록

- 품목 검색 다이얼로그 (Item에서 선택)

- 거래처 선택 다이얼로그

- **비즈니스 로직**:

- 구매요청 코드 자동생성 (PR-YYYYMMDD-NNN 형식)

- 상태 관리: 요청(0) → 확정(1)

- 품목 행: itemCode, subclass, qty, unit, price, currency, remark

**Must NOT do**:

- 발주 변환 로직 (T9에서 구현)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T7, T9와 병렬 가능하나 T9는 T8 선행 권장)

- **Parallel Group**: Wave 2

- **Blocks**: T9, T14, T15

- **Blocked By**: T2, T3, T4, T5, T6

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → PURCHASEREQUEST (11개 컬럼), PRDETAIL (12개 컬럼)

- 구매요청→발주 흐름: SNS ERP 문서 6-8장

**Acceptance Criteria**:

- [x] 구매요청 등록 (품목 행 추가) 동작

- [x] 구매요청 확정 상태 변경 동작

- [x] 확정된 구매요청은 수정/춈소 불가

**QA Scenarios (MANDATORY)**:

```

Scenario: 구매요청 등록→확정

Tool: Bash (curl) + Playwright

Steps:

1. POST /api/purchase-requests {"dday":"2024-06-01","staffName":"홍길동","details":[{"itemCode":"I001","qty":10,"unit":"EA","price":1000}]}

2. GET /api/purchase-requests → 생성된 건 확인

3. POST /api/purchase-requests/PR-20240601-001/confirm → 200

4. GET /api/purchase-requests/PR-20240601-001 → status=1 확인

5. PUT /api/purchase-requests/PR-20240601-001 → 400 (확정 후 수정 불가)

Expected Result: 등록→확정 흐름 정상, 확정 후 수정 차단

Evidence: .sisyphus/evidence/task-8-purchase-request.txt

```

**Commit**: YES

- Message: `feat(purchase): purchase request management with status workflow`

- [x] 9. 구매 - 발주 + 입고 관리

**What to do**:

- **발주 관리** (`src/app/api/purchase-orders/`):

- CRUD API + `POST /[code]/confirm` 확정

- 구매요청에서 불러오기: `POST /api/purchase-orders/from-request` (선택된 구매요청의 품목을 발주로 복사)

- 거래처별 발주: 특정 거래처의 구매요청 품목을 모아서 발주

- 발주서 상태: 작성(0) → 발행(1) → 마감(2)

- **입고 관리** (`src/app/api/purchases/`):

- CRUD API + `POST /[code]/confirm` 확정

- 발주에서 불러오기: `POST /api/purchases/from-order` (발주의 품목을 입고로 복사, 미입고 수량만)

- 입고 상태: 작성(0) → 확정(1) → 마감(2)

- **입고 확정 시 재고 자동 증가**: PurchaseDetail의 itemCode + locationCode 조합으로 Stock 업데이트

- StockChange 이력 생성

- **페이지**:

- `src/app/(dashboard)/purchase/orders/` - 발주 목록/상세/신규

- `src/app/(dashboard)/purchase/receiving/` - 입고 목록/상세/신규

- 구매요청→발주 변환 다이얼로그

- 발주→입고 변환 다이얼로그

**Must NOT do**:

- 바코드 입고 (v2)

- BOM 기반 입고 (v2)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: NO (T8 선행, 재고 업데이트 로직 중요)

- **Parallel Group**: Wave 2 (T8 후 시퀀셜)

- **Blocks**: T14, T15

- **Blocked By**: T2, T3, T4, T6, T8

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → PURCHASEORDER (16개), PODETAIL (13개), PURCHASE (11개), PURCHASEDETAIL (12개)

- STOCK 테이블: 입고 확정 시 qty 증가 로직 참고

- STOCKCHANGE: 재고 변경 이력 기록 패턴

**Acceptance Criteria**:

- [x] 구매요청 → 발주 변환 동작

- [x] 발주 → 입고 변환 동작

- [x] 입고 확정 시 해당 창고의 재고 자동 증가

- [x] 재고 변경 이력(STOCKCHANGE) 자동 생성

**QA Scenarios (MANDATORY)**:

```

Scenario: 발주→입고→재고증가

Tool: Bash (curl)

Preconditions: 품목 I001, 창고 W001 존재

Steps:

1. POST /api/purchase-orders/from-order → 발주 생성 (I001, qty=10)

2. POST /api/purchases/from-order → 입고 생성 (발주에서 불러오기, qty=10, locationCode=W001)

3. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=0 (입고 전)

4. POST /api/purchases/{code}/confirm → 입고 확정

5. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=10 (입고 후)

6. GET /api/inventory/changes?itemCode=I001 → 변경 이력 1건 존재

Expected Result: 입고 확정 후 재고 10 증가, 이력 기록

Evidence: .sisyphus/evidence/task-9-receiving-stock.txt

Scenario: 부분 입고

Tool: Bash (curl)

Steps:

1. 발주 qty=20으로 생성

2. 입고 1: qty=10으로 입고 확정 → 재고 10

3. 입고 2: qty=10으로 추가 입고 확정 → 재고 20

Expected Result: 부분 입고 누적 정상

Evidence: .sisyphus/evidence/task-9-partial-receiving.txt

```

**Commit**: YES

- Message: `feat(purchase): purchase order and receiving with auto stock update`

- [x] 10. 영업 - 견적서 관리

**What to do**:

- **API Routes** (`src/app/api/quotations/`):

- CRUD API (헤더 + 상세 동시)

- `GET` - 목록 (검색: code, customerName / 필터: type(받은견적/보낸견적), dateRange, status)

- `POST` - 생성 (type: 0=받은견적, 1=보낸견적)

- `POST /[code]/confirm` - 견적 확정

- `POST /[code]/to-order` - 견적을 수주로 변환

- **페이지** (`src/app/(dashboard)/sales/quotations/`):

- `page.tsx` - 견적 목록 (탭: 받은견적/보낸견적)

- `[code]/page.tsx` - 견적 상세/수정

- `new/page.tsx` - 신규 견적 (타입 선택: 받은/보낸)

- 거래처 선택, 품목 행 추가/삭제

- 견적 금액 자동 계산 (단가 × 수량 + 세액)

- 견적 코드: QT-YYYYMMDD-NNN

**Must NOT do**:

- 견적서 인쇄 (T16에서 구현)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T12, T13과 병렬)

- **Parallel Group**: Wave 3

- **Blocks**: T11, T14, T15

- **Blocked By**: T2, T3, T4, T5, T6

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → QUOTATION (13개), QUOTATIONDETAIL (11개)

- QUOTATION.TYPE: INTEGER → 0=받은견적, 1=보낸견적

**Acceptance Criteria**:

- [x] 받은견적/보낸견적 탭 분리 동작

- [x] 견적 등록 (품목 행 포함) 동작

- [x] 견적 금액 자동 계산

**QA Scenarios (MANDATORY)**:

```

Scenario: 견적 CRUD + 금액계산

Tool: Bash (curl)

Steps:

1. POST /api/quotations {"type":1,"dday":"2024-06-01","customerCode":"C001","details":[{"itemCode":"I001","qty":5,"price":10000,"tax":1000}]}

2. GET /api/quotations?type=1 → 생성된 건 확인

3. 상세에서 총금액 = (10000+1000)*5 = 55000 확인

4. DELETE → 성공

Expected Result: 견적 CRUD + 자동 금액 계산

Evidence: .sisyphus/evidence/task-10-quotation.txt

```

**Commit**: YES

- Message: `feat(sales): quotation management (received/sent)`

- [x] 11. 영업 - 수주 + 출고 관리

**What to do**:

- **수주 관리** (`src/app/api/sales-orders/`):

- CRUD API + 확정

- 견적에서 불러오기: `POST /api/sales-orders/from-quotation`

- 수주 상태: 작성(0) → 확정(1) → 출고완료(2)

- 수주 코드: SO-YYYYMMDD-NNN

- **출고 관리** (`src/app/api/sales/`):

- CRUD API + 확정

- 수주에서 불러오기: `POST /api/sales/from-order` (미출고 수량만)

- 출고 상태: 작성(0) → 확정(1) → 마감(2)

- **출고 확정 시 재고 자동 감소**: SaleDetail의 itemCode + locationCode로 Stock.qty 감소

- 재고 부족 시 경고 (0 미만 불가)

- StockChange 이력 생성 (음수 변경)

- **페이지**:

- `src/app/(dashboard)/sales/orders/` - 수주 목록/상세/신규

- `src/app/(dashboard)/sales/shipping/` - 출고 목록/상세/신규

- 견적→수주 변환, 수주→출고 변환 다이얼로그

- 출고 시 창고 선택 + 재고 확인 표시

**Must NOT do**:

- 바코드 출고 (v2)

- 출고대기 기능 (v2)

- 특별단가 자동적용 (수동 선택)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: NO (T10 선행, 재고 감소 로직 중요)

- **Parallel Group**: Wave 3

- **Blocks**: T12, T14, T15

- **Blocked By**: T2, T3, T4, T6, T10

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → SALESORDER (14개), SODETAIL (13개), SALES (14개), SALESDETAIL (14개)

- SALEDETAIL.COST: 원가 필드 (매출이익 계산용)

**Acceptance Criteria**:

- [x] 견적 → 수주 변환 동작

- [x] 수주 → 출고 변환 동작

- [x] 출고 확정 시 재고 자동 감소

- [x] 재고 부족 시 출고 불가

**QA Scenarios (MANDATORY)**:

```

Scenario: 수주→출고→재고감소

Tool: Bash (curl)

Preconditions: 품목 I001, 창고 W001, 재고 10개

Steps:

1. POST /api/sales-orders/from-quotation → 수주 생성 (I001, qty=5)

2. POST /api/sales/from-order → 출고 생성 (수주에서 불러오기, qty=5, locationCode=W001)

3. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=10 (출고 전)

4. POST /api/sales/{code}/confirm → 출고 확정

5. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=5 (출고 후)

Expected Result: 출고 확정 후 재고 5 감소

Evidence: .sisyphus/evidence/task-11-shipping-stock.txt

Scenario: 재고 부족 출고

Tool: Bash (curl)

Preconditions: 품목 I001, 재고 3개

Steps:

1. POST /api/sales (qty=5) → 출고 등록

2. POST /api/sales/{code}/confirm → 400 "재고 부족"

Expected Result: 재고 부족 에러로 출고 확정 차단

Evidence: .sisyphus/evidence/task-11-stock-insufficient.txt

```

**Commit**: YES

- Message: `feat(sales): sales order and shipping with auto stock decrease`

- [x] 12. 재고 - 현재고 + 재고조정

**What to do**:

- **현재고 조회** (`src/app/api/inventory/stock/`):

- `GET /api/inventory/stock` - 목록 (검색: itemCode, itemName / 필터: locationCode, projectCode)

- `GET /api/inventory/stock/[id]` - 상세 (변경 이력 포함)

- 집계: 품목별 전체 재고, 창고별 재고

- **재고조정** (`src/app/api/inventory/adjustments/`):

- `POST /api/inventory/adjustments` - 재고조정 등록

- 실사 수량 입력 → 기존 수량과 비교 → 차이만큼 Stock 업데이트

- StockChange 이력 생성 (changeCode: 'ADJUST')

- 변경 사유 필수 입력

- **페이지** (`src/app/(dashboard)/inventory/`):

- `stock/page.tsx` - 현재고 목록 (품목별/창고별 피벗 뷰)

- `stock/[id]/page.tsx` - 재고 상세 + 변경 이력 타임라인

- `adjustments/page.tsx` - 재고조정 등록/이력

- `adjustments/new/page.tsx` - 실사 입력 (품목별 현재고→조정수량 입력)

**Must NOT do**:

- 재고 예측/안전재고 알림 (v2)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T10, T13과 병렬 가능하나 T11 후 권장)

- **Parallel Group**: Wave 3

- **Blocks**: T13, T14, T15

- **Blocked By**: T2, T3, T4, T6, T11

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → STOCK (8개), STOCKCHANGE (9개), STCGLOG (11개)

- STOCK 복합 unique: locationCode + itemCode + subclass + projectCode

**Acceptance Criteria**:

- [x] 현재고 목록 품목별/창고별 조회 동작

- [x] 재고조정 등록 후 수량 반영

- [x] 변경 이력 타임라인 표시

**QA Scenarios (MANDATORY)**:

```

Scenario: 재고조정

Tool: Bash (curl)

Preconditions: 품목 I001, 창고 W001, 현재고 10

Steps:

1. POST /api/inventory/adjustments {"stockId":1,"newQty":15,"reason":"실사 조정"} → 201

2. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=15

3. GET /api/inventory/changes?stockId=1 → 변경 이력에 oldQty=10, newQty=15 존재

Expected Result: 재고 10→15 조정, 이력 기록

Evidence: .sisyphus/evidence/task-12-stock-adjust.txt

```

**Commit**: YES

- Message: `feat(inventory): stock inquiry, adjustment with change history`

- [x] 13. 재고 - 창고이동 + 이력 관리

**What to do**:

- **창고이동** (`src/app/api/inventory/transfers/`):

- `GET` - 이동 목록 (검색: code, date / 필터: status)

- `POST` - 이동 등록 (출발창고 + 도착창고 + 품목 행)

- `POST /[code]/confirm` - 이동 확정

- 확정 시: 출발창고 재고 감소 + 도착창고 재고 증가 (트랜잭션)

- StockChange 이력 2건 생성 (출/입)

- **페이지** (`src/app/(dashboard)/inventory/transfers/`):

- `page.tsx` - 이동 목록

- `[code]/page.tsx` - 이동 상세/수정

- `new/page.tsx` - 신규 이동 (출발/도착 창고 선택, 품목 행 추가)

- **전체 재고 이력** (`src/app/api/inventory/changes/`):

- `GET` - 재고 변경 이력 (전체/품목별/창고별)

- 이력 타입: 입고, 출고, 이동(출), 이동(입), 조정

**Must NOT do**:

- 이동 중 "이동중" 상태 재고 개념 (v1은 즉시 반영)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T10, T11, T12와 병렬 가능하나 T12 후 권장)

- **Parallel Group**: Wave 3

- **Blocks**: T14, T15

- **Blocked By**: T2, T3, T4, T12

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` → LOCATETRAN (14개), LOCATETRANDETAIL (14개)

**Acceptance Criteria**:

- [x] 창고이동 등록 후 확정 시 양쪽 재고 변경

- [x] 트랜잭션 안전성 (한쪽 실패 시 롤백)

- [x] 재고 이력 타입별 조회

**QA Scenarios (MANDATORY)**:

```

Scenario: 창고이동

Tool: Bash (curl)

Preconditions: I001, W001=10개, W002=0개

Steps:

1. POST /api/inventory/transfers {"locationOutCode":"W001","locationInCode":"W002","details":[{"itemCode":"I001","qty":3}]}

2. POST /api/inventory/transfers/{code}/confirm

3. GET /api/inventory/stock?locationCode=W001 → qty=7

4. GET /api/inventory/stock?locationCode=W002 → qty=3

Expected Result: W001: 10→7, W002: 0→3

Evidence: .sisyphus/evidence/task-13-transfer.txt

Scenario: 출발창고 재고 부족

Tool: Bash (curl)

Preconditions: W001 재고 2개

Steps:

1. POST /api/inventory/transfers (qty=5)

2. POST /api/inventory/transfers/{code}/confirm → 400 "재고 부족"

Expected Result: 재고 부족으로 이동 실패

Evidence: .sisyphus/evidence/task-13-transfer-insufficient.txt

```

**Commit**: YES

- Message: `feat(inventory): warehouse transfer with transactional stock update`

- [x] 14. 대시보드 + 통계

**What to do**:

```mermaid

graph TB

CARDS["📊 카드 위젯 금월매출 | 금월매입 | 총품목 | 총거래처"]

CHARTS["📈 차트 영역 월별매출추이 | 출고TOP10 | 재고분포"]

TABLES["📋 테이블 최근거래 10건 | 미출고 수주"]

S["GET /dashboard/summary"]

M["GET /dashboard/monthly-sales"]

T["GET /dashboard/top-items"]

D["GET /dashboard/stock-distribution"]

R["GET /dashboard/recent-transactions"]

P["GET /dashboard/pending-shipments"]

RP1["/reports/sales 기간별 집계"]

RP2["/reports/inventory 품목별/창고별"]

CARDS --> S

CHARTS --> M

CHARTS --> T

CHARTS --> D

TABLES --> R

TABLES --> P

style CARDS fill:#3b82f6,color:#fff

style CHARTS fill:#10b981,color:#fff

style TABLES fill:#8b5cf6,color:#fff

```

- **메인 대시보드** (`src/app/(dashboard)/page.tsx`):

- 상단 카드: 금월 매출액, 금월 매입액, 총 품목수, 총 거래처수

- 차트: 월별 매출/매입 추이 (Recharts line chart, 최근 12개월)

- 차트: 품목별 출고량 TOP 10 (bar chart)

- 차트: 창고별 재고 분포 (pie chart)

- 최근 거래 내역 테이블 (최근 10건)

- 미출고 수주 목록 (status=1인 수주 중 미출고 건)

- **API Routes** (`src/app/api/dashboard/`):

- `GET /api/dashboard/summary` - 카드 데이터

- `GET /api/dashboard/monthly-sales` - 월별 매출/매입

- `GET /api/dashboard/top-items` - 품목별 출고 TOP

- `GET /api/dashboard/stock-distribution` - 창고별 재고

- `GET /api/dashboard/recent-transactions` - 최근 거래

- `GET /api/dashboard/pending-shipments` - 미출고 목록

- **조회/통계 페이지**:

- `src/app/(dashboard)/reports/sales/page.tsx` - 거래요약 (기간별 매출/매입 집계)

- `src/app/(dashboard)/reports/inventory/page.tsx` - 재고 현황 (품목별/창고별)

**Must NOT do**:

- 실시간 갱신 (v1은 새로고침)

- 엑셀 다운로드 (T17)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T15, T16과 병렬)

- **Parallel Group**: Wave 4

- **Blocks**: T17, T18

- **Blocked By**: T5-T13

**References**:

- Recharts: https://recharts.org/

- TanStack Query for data fetching

**Acceptance Criteria**:

- [x] 대시보드 카드 데이터 표시

- [x] 차트 3종 렌더링

- [x] 기간별 통계 페이지 동작

**QA Scenarios (MANDATORY)**:

```

Scenario: 대시보드 렌더링

Tool: Playwright

Preconditions: 거래 데이터 존재 (입고/출고 이력)

Steps:

1. http://localhost:3000 이동

2. 카드 4개 표시 확인 (text "매출", "매입", "품목", "거래처")

3. 차트 영역 3개 렌더링 확인 (svg 요소 존재)

4. 최근 거래 테이블 표시 확인

Expected Result: 대시보드 전체 렌더링

Evidence: .sisyphus/evidence/task-14-dashboard.png

Scenario: API 데이터 확인

Tool: Bash (curl)

Steps:

1. curl GET /api/dashboard/summary → 200, {sales: N, purchase: N, items: N, customers: N}

2. curl GET /api/dashboard/monthly-sales → 200, 배열 응답

Expected Result: JSON 응답 정상

Evidence: .sisyphus/evidence/task-14-dashboard-api.txt

```

**Commit**: YES

- Message: `feat(dashboard): main dashboard with charts and statistics`

- [x] 15. Firebird → PostgreSQL 데이터 마이그레이션

**What to do**:

```mermaid

flowchart TB

FB["🔥 Firebird v3 SNSERP.FDB 85개 테이블"]

READ["node-firebird 데이터 읽기 (1000행 배치)"]

TRANS["데이터 변환"]

WRITE["Prisma Client SQLite 쓰기"]

T1["PascalCase → camelCase"]

T2["BIGINT→BigInt, DATE→DateTime"]

T3["BLOB → String, 빈문자열→null"]

T4["비밀번호 평문→bcrypt"]

PG["🗄️ SQLite ~30개 모델 Prisma 관리"]

FB --> READ --> TRANS --> WRITE --> PG

T1 --> TRANS

T2 --> TRANS

T3 --> TRANS

T4 --> TRANS

style FB fill:#ef4444,color:#fff

style TRANS fill:#3b82f6,color:#fff

style PG fill:#10b981,color:#fff

```

- **마이그레이션 스크립트** (`scripts/migrate-firebird.ts`):

1. Firebird 연결: `node-firebird` 라이브러리로 SNSERP.FDB 연결

2. 각 테이블 순차 읽기 (1000행 배치):

- 기준정보: CUSTOMER, CUSTOMERSTAFF, CUSTOMERITEM, ITEM, ITEMCLASS, UNITGROUP, SPECIALPRICE, LOCATION, LOCATIONSTAFF, STAFF, DEPARTMENT, PROJECT, TAXRATE, EXCHANGERATE, CODESET, CM_AUTOINCINDEX

- 구매: PURCHASEREQUEST, PRDETAIL, PURCHASEORDER, PODETAIL, PURCHASE, PURCHASEDETAIL

- 영업: QUOTATION, QUOTATIONDETAIL, SALESORDER, SODETAIL, SALES, SALESDETAIL, PACKINGLIST, PKGSDETAIL, PKGSITEMS

- 재고: STOCK, STOCKCHANGE, STCGLOG, LOCATETRAN, LOCATETRANDETAIL, WAREHOUSE

3. 데이터 변환:

- 컬럼명: PascalCase → camelCase (ITEMCODE → itemCode)

- 타입: BIGINT → BigInt, DATE → DateTime, BLOB → String (Text)

- NULL 처리: 빈 문자열 '' → null

- STAFF.PASSWORD: 평문 → bcrypt 해시 변환

4. Prisma로 PostgreSQL에 upsert (중복 방지)

5. 진행률 표시 (콘솔 로그)

6. 마이그레이션 결과 리포트 (각 테이블별 이관 건수)

- **설정**:

- `.env`에 FIREBIRD_DB_PATH 설정

- Firebird 서비스 실행 중 필요

- **검증 스크립트** (`scripts/verify-migration.ts`):

- 각 테이블별 소스(Firebird) vs 타겟(PostgreSQL) 행 수 비교

- 샘플 데이터 값 비교 (랜덤 10행)

- 결과 리포트 출력

**Must NOT do**:

- v2 테이블(생산, 회계 등)은 마이그레이션하지 않음 (스키마만 준비)

- 원본 Firebird DB 수정 금지

**Recommended Agent Profile**:

- **Category**: `deep`

- **Skills**: []

**Parallelization**:

- **Can Run In Parallel**: YES (T14, T16과 병렬)

- **Parallel Group**: Wave 4

- **Blocks**: T18

- **Blocked By**: T2

**References**:

**Pattern References**:

- `[PROJECT_PATH]\_schema_columns.txt` - 전체 스키마 (모든 테이블의 컬럼명, 타입 정보)

- `[PROJECT_PATH]\SNSERP.FDB` - 원본 Firebird DB 파일

- node-firebird: https://github.com/hgourvest/node-firebird

**External References**:

- node-firebird API: `Firebird.attach(options, callback)`, `db.query(sql, params, callback)`

- Prisma upsert: `prisma.model.upsert({ where, update, create })`

**Acceptance Criteria**:

- [x] 마이그레이션 스크립트 실행 완료 (에러 없이)

- [x] 각 테이블 행 수 일치 (Firebird = PostgreSQL)

- [x] 샘플 데이터 값 일치 확인

- [x] STAFF 비밀번호 해시 변환 완료

**QA Scenarios (MANDATORY)**:

```

Scenario: 전체 마이그레이션 실행

Tool: Bash

Preconditions: Firebird 서비스 실행 중, PostgreSQL 실행 중

Steps:

1. npx tsx scripts/migrate-firebird.ts

2. 콘솔에 각 테이블별 이관 건수 출력 확인

3. npx tsx scripts/verify-migration.ts

4. "모든 테이블 행 수 일치" 확인

Expected Result: 전체 데이터 이관 성공

Evidence: .sisyphus/evidence/task-15-migration.txt

Scenario: 마이그레이션 후 로그인

Tool: Bash (curl)

Preconditions: 마이그레이션 완료

Steps:

1. 기존 STAFF 계정으로 로그인 시도

2. POST /api/auth/login with 기존 credentials

3. HTTP 200 확인

Expected Result: 기존 계정으로 로그인 성공

Evidence: .sisyphus/evidence/task-15-login-after-migration.txt

```

**Commit**: YES

- Message: `feat(migration): Firebird to PostgreSQL data migration script`

- [x] 16. PDF 인쇄 시스템

**What to do**:

```mermaid

flowchart TB

BTN["📄 PDF 인쇄 버튼"]

GET["GET /api/print/:type/:code"]

FETCH["DB에서 데이터 조회"]

GEN["PDF 생성 엔진"]

QT_PDF["견적서 거래처정보 + 품목표 + 합계"]

PO_PDF["발주서 거래처정보 + 품목표 + 납기일"]

SH_PDF["출고전표 거래처정보 + 품목표 + 출고창고"]

PREVIEW["미리보기 모달"]

DOWNLOAD["다운로드 / 새 탭"]

BTN --> GET

GET --> FETCH

FETCH --> GEN

GEN --> QT_PDF

GEN --> PO_PDF

GEN --> SH_PDF

QT_PDF --> PREVIEW

PO_PDF --> PREVIEW

SH_PDF --> PREVIEW

PREVIEW --> DOWNLOAD

style Trigger fill:#3b82f6,color:#fff

style API fill:#10b981,color:#fff

style Templates fill:#f59e0b,color:#fff

style Output fill:#8b5cf6,color:#fff

```

- **PDF 생성 유틸리티** (`src/lib/pdf.ts`):

- `@react-pdf/renderer` 또는 `jsPDF` + `jspdf-autotable` 사용

- 공통 헤더/푸터 템플릿 (회사명, 로고, 문서번호, 발행일)

- **인쇄 API Routes**:

- `GET /api/print/quotation/[code]` - 견적서 PDF

- `GET /api/print/purchase-order/[code]` - 발주서 PDF

- `GET /api/print/sales-order/[code]` - 수주서 PDF

- `GET /api/print/shipping/[code]` - 출고전표/패킹리스트 PDF

- **PDF 양식 내용**:

- 견적서: 견적번호, 날짜, 거래처정보, 품목표(품명/수량/단가/금액), 합계, 비고

- 발주서: 발주번호, 날짜, 거래처정보, 품목표, 납기일, 합계

- 출고전표: 출고번호, 날짜, 거래처정보, 품목표, 출고창고, 합계

- **프론트엔드 인쇄 버튼**:

- 각 상세 페이지에 "PDF 인쇄" 버튼 추가

- 클릭 시 PDF 새 탭에서 열기 또는 다운로드

- **인쇄 미리보기**:

- 모달에서 PDF 미리보기 후 인쇄/다운로드 선택

**Must NOT do**:

- 인쇄 양식 편집 기능 (v2)

- 인쇄 기록 관리 (v2)

**Recommended Agent Profile**:

- **Category**: `unspecified-high`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T14, T15와 병렬)

- **Parallel Group**: Wave 4

- **Blocks**: T18

- **Blocked By**: T4, T8, T10, T11

**References**:

- @react-pdf/renderer: https://react-pdf.org/

- 또는 jsPDF: https://github.com/parallax/jsPDF

**Acceptance Criteria**:

- [x] 견적서 PDF 생성/다운로드 동작

- [x] 발주서 PDF 생성/다운로드 동작

- [x] 출고전표 PDF 생성/다운로드 동작

- [x] PDF에 한글 폰트 정상 표시

**QA Scenarios (MANDATORY)**:

```

Scenario: 견적서 PDF 생성

Tool: Bash (curl)

Preconditions: 견적 데이터 존재

Steps:

1. curl GET /api/print/quotation/QT-20240601-001 -o test.pdf

2. 파일 크기 > 0 확인

3. file test.pdf → "PDF document" 확인

Expected Result: PDF 파일 정상 생성

Evidence: .sisyphus/evidence/task-16-quotation-pdf.txt

Scenario: 발주서 PDF 한글

Tool: Playwright

Preconditions: 발주 데이터 존재

Steps:

1. 발주 상세 페이지에서 "PDF 인쇄" 버튼 클릭

2. PDF 미리보기 모달 열림 확인

3. PDF 내용에 한글 텍스트 포함 확인

Expected Result: 한글이 깨지지 않고 정상 표시

Evidence: .sisyphus/evidence/task-16-pdf-korean.png

```

**Commit**: YES

- Message: `feat(print): PDF generation for quotation, PO, shipping documents`

- [x] 17. Excel 내보내기 + 일괄 입력

**What to do**:

- **Excel 내보내기** (`src/lib/excel.ts`):

- `xlsx` (SheetJS) 라이브러리 사용

- 모든 목록 페이지에 "Excel 다운로드" 버튼 추가

- 현재 필터/검색 조건 기준으로 데이터 내보내기

- 컬럼 헤더 한국어 매핑 (itemCode → "품목코드")

- **Excel 일괄 입력**:

- 거래처 일괄 입력: `/api/customers/import` (Excel 파일 업로드 → 파싱 → 일괄 insert)

- 품목 일괄 입력: `/api/items/import`

- 업로드 UI: 드래그앤드롭 영역 + 미리보기 테이블

- 에러 처리: 잘못된 행은 에러 메시지와 함께 스킵, 성공/실패 건수 표시

- **엑셀 템플릿 다운로드**:

- `/api/templates/customers` - 거래처 입력 양식 다운로드

- `/api/templates/items` - 품목 입력 양식 다운로드

**Must NOT do**:

- 복잡한 매핑 규칙 (v1은 단순 1:1 매핑)

**Recommended Agent Profile**:

- **Category**: `quick`

- **Skills**: [`/frontend-ui-ux`]

**Parallelization**:

- **Can Run In Parallel**: YES (T16과 병렬 가능)

- **Parallel Group**: Wave 5

- **Blocks**: T18

- **Blocked By**: T14

**References**:

- SheetJS: https://docs.sheetjs.com/

- 기존 거래처.xlsx, 품목-원본.xlsx 파일 참고 ([PROJECT_PATH]\)

**Acceptance Criteria**:

- [x] 거래처 목록 Excel 다운로드 동작

- [x] 품목 목록 Excel 다운로드 동작

- [x] Excel 일괄 입력 후 데이터 저장 확인

- [x] 입력 에러 시 실패 건수 표시

**QA Scenarios (MANDATORY)**:

```

Scenario: Excel 내보내기

Tool: Bash (curl)

Steps:

1. curl GET /api/customers/export -o customers.xlsx

2. file customers.xlsx → "Microsoft Excel" 확인

3. 파일 크기 > 0

Expected Result: Excel 파일 정상 생성

Evidence: .sisyphus/evidence/task-17-export.txt

Scenario: Excel 일괄 입력

Tool: Bash (curl)

Steps:

1. curl POST /api/items/import -F "file=@template.xlsx"

2. 응답에 {success: N, failed: N} 포함 확인

Expected Result: 일괄 입력 처리 결과 반환

Evidence: .sisyphus/evidence/task-17-import.txt

```

**Commit**: YES

- Message: `feat(export): Excel export and bulk import for customers, items`

- [x] 18. 통합 테스트 + 버그 수정

**What to do**:

- **End-to-End 시나리오 테스트** (Vitest + Playwright):

- 구매 사이클: 구매요청 → 발주 → 입고 → 재고증가 확인

- 영업 사이클: 견적 → 수주 → 출고 → 재고감소 확인

- 재고 조정: 입고+출고 후 재고조정 → 이력 확인

- 창고이동: 이동 후 양쪽 재고 변화 확인

- **API 통합 테스트** (Vitest):

- 각 API 엔드포인트 CRUD 테스트

- 에러 케이스 테스트 (권한, 유효성, 참조 무결성)

- 동시성 테스트 (같은 재고 동시 업데이트)

- **UI 버그 수정**:

- 반응형 레이아웃 깨짐 수정

- 한글 입력/표시 이슈 수정

- 폼 유효성 에러 메시지 한국어화

- 로딩 상태 표시 (skeleton)

- **성능 최적화**:

- 대량 데이터 목록 가상 스크롤 (필요시)

- API 응답 캐싱 (필요시)

- **빌드 테스트**:

- `npm run build` 성공 확인

- 프로덕션 모드 동작 확인

**Must NOT do**:

- 새 기능 추가 금지 (버그 수정만)

**Recommended Agent Profile**:

- **Category**: `deep`

- **Skills**: [`/playwright`]

**Parallelization**:

- **Can Run In Parallel**: NO (최종)

- **Parallel Group**: Wave 5 (시퀀셜)

- **Blocks**: FINAL

- **Blocked By**: T14-T17

**References**:

- Vitest: https://vitest.dev/

- Playwright: https://playwright.dev/

**Acceptance Criteria**:

- [x] `npm run build` → 에러 없이 빌드 성공

- [x] 핵심 E2E 시나리오 4개 통과

- [x] API 테스트 20+ 케이스 통과

- [x] 반응형 레이아웃 정상 (태블릿 크기)

**QA Scenarios (MANDATORY)**:

```

Scenario: 전체 구매→영업 사이클

Tool: Playwright

Steps:

1. 로그인

2. 품목 등록 (I-TEST, 테스트품목)

3. 거래처 등록 (C-TEST, 테스트거래처)

4. 구매요청 등록 (I-TEST, qty=100)

5. 구매요청 → 발주 변환

6. 발주 → 입고 변환 (W001)

7. 입고 확정 → 재고 100 확인

8. 견적서 등록 (I-TEST, qty=30)

9. 견적 → 수주 변환

10. 수주 → 출고 변환 (W001)

11. 출고 확정 → 재고 70 확인

12. 창고이동 (W001→W002, qty=20) → W001=50, W002=20 확인

13. 재고조정 (W001, 50→45) → 재고 45 확인

14. 대시보드 접속 → 매출/매입 수치 반영 확인

Expected Result: 전체 사이클 정상 동작, 재고 정확

Evidence: .sisyphus/evidence/task-18-full-cycle.txt

Scenario: 프로덕션 빌드

Tool: Bash

Steps:

1. npm run build → exit code 0

2. npm start → 서버 시작

3. curl http://localhost:3000 → 200

Expected Result: 프로덕션 빌드 정상 동작

Evidence: .sisyphus/evidence/task-18-build.txt

```

**Commit**: YES

- Message: `chore: integration tests, bug fixes, production build verification`

---

# # Final Verification Wave (MANDATORY — after ALL implementation tasks)

> 4 review agents run in PARALLEL. ALL must APPROVE. Present consolidated results to user and get explicit "okay" before completing.

- [x] F1. **Plan Compliance Audit** — `oracle`

Read the plan end-to-end. For each "Must Have": verify implementation exists (read file, curl endpoint, run command). For each "Must NOT Have": search codebase for forbidden patterns — reject with file:line if found. Check evidence files exist in .sisyphus/evidence/. Compare deliverables against plan.

Output: `Must Have [N/N] | Must NOT Have [N/N] | Tasks [N/N] | VERDICT: APPROVE/REJECT`

- [x] F2. **Code Quality Review** — `unspecified-high`

Run `tsc --noEmit` + linter + `npm test`. Review all changed files for: `as any`/`@ts-ignore`, empty catches, console.log in prod, commented-out code, unused imports. Check AI slop: excessive comments, over-abstraction, generic names.

Output: `Build [PASS/FAIL] | Lint [PASS/FAIL] | Tests [N pass/N fail] | Files [N clean/N issues] | VERDICT`

- [x] F3. **Real Manual QA** — `unspecified-high` (+ `playwright` skill)

Start from clean state. Execute EVERY QA scenario from EVERY task — follow exact steps, capture evidence. Test cross-module integration (purchase receiving → stock update → sales shipping → stock decrease). Test edge cases: empty state, invalid input, rapid actions. Save to `.sisyphus/evidence/final-qa/`.

Output: `Scenarios [N/N pass] | Integration [N/N] | Edge Cases [N tested] | VERDICT`

- [x] F4. **Scope Fidelity Check** — `deep`

For each task: read "What to do", read actual diff (git log/diff). Verify 1:1 — everything in spec was built (no missing), nothing beyond spec was built (no creep). Check "Must NOT do" compliance. Detect cross-task contamination.

Output: `Tasks [N/N compliant] | Contamination [CLEAN/N issues] | Unaccounted [CLEAN/N files] | VERDICT`

---

# # Commit Strategy

- **Wave 1**: `feat(init): Next.js project scaffolding with Prisma, auth, UI` - 여러 파일

- **Wave 2**: `feat(master): 거래처/품목/창고/직원 CRUD` - 여러 파일

- **Wave 3**: `feat(purchase): 구매요청/발주/입고 관리` - 여러 파일

- **Wave 4**: `feat(sales): 견적/수주/출고 관리` - 여러 파일

- **Wave 5**: `feat(inventory): 재고/창고이동 관리` - 여러 파일

- **Wave 6**: `feat(dashboard): 대시보드 + 통계` - 여러 파일

- **Wave 7**: `feat(migration): Firebird to PostgreSQL data migration` - 여러 파일

- **Wave 8**: `feat(print): PDF 인쇄 시스템` - 여러 파일

- **Wave 9**: `feat(export): Excel 내보내기` - 여러 파일

- **Final**: `chore: 통합 테스트 및 버그 수정` - 여러 파일

---

# # Success Criteria

## # Verification Commands

```bash

npm run dev # Expected: 서버 시작 at localhost:3000

npx prisma migrate status # Expected: 모든 마이그레이션 적용됨

npx prisma studio # Expected: 데이터 브라우저 실행

npm run build # Expected: 빌드 성공 (0 errors)

npm test # Expected: 핵심 테스트 통과

```

## # Final Checklist

- [x] All "Must Have" present

- [x] All "Must NOT Have" absent

- [x] All tests pass

- [x] Firebird 데이터가 PostgreSQL에 정상 이관됨

- [x] 로그인 → CRUD → 인쇄 전체 흐름 동작

- [x] 반응형 UI (데스크톱/태블릿)

---

# # Post-v1 Enhancements (2026-05)

## # Completed Enhancements

- [x] **수주→출고 연결 기능** — Sale.salesOrderCode 필드 추가, 출고 확정 시 수주 상태 자동 변경(1→2), 수주 상세에 "출고 생성" 버튼, 출고 신규에서 수주 데이터 자동 로드

- [x] **출고/입고 확정 건 삭제 (재고 복원)** — `?restoreStock=true` DELETE 시 Stock.qty 복원 + StockChange 이력 기록, UI에 "삭제 (재고복원)" 버튼, 수주 상태도 복원(2→1)

- [x] **W001 → '0' 창고 코드 통일** — 모든 하드코딩 W001 기본값을 '0'으로 변경 (9개 파일), DB PURCHASE.locationCode W001→0 업데이트

- [x] **현재고 조회 창고 직접 변경** — Stock 페이지 창고 컬럼 클릭 시 드롭다운으로 창고 변경, PATCH /api/inventory/stock/[id] (창고이동 로직 + StockChange 이력), 사이드바 "창고이동" 메뉴 제거

- [x] **재고현황 대분류별 그래프** — /api/dashboard/stock-by-category API, Pie 차트 + Bar 차트 + 상세 테이블, 카테고리 카드 추가

- [x] **React key 중복 에러 수정** — Stock 페이지 컬럼에 고유 id 부여 (category, itemName, unit)

- [x] **미출고 수주 삭제 기능** — 수주 상세(status=1)에 삭제 버튼 추가, 대시보드 미출고 수주 클릭 가능한 링크로 변경

- [x] **출고 삭제 트랜잭션 보장** — $transaction으로 SaleDetail + PackingDetail + Sale 명시적 삭제

## # v1.1 — 생산 관리 (Production Management)

- [x] 19. 시리얼번호 관리 (Serial Number Management)

**What to do**:

- 시리얼번호 전용 관리 페이지 (사이드바 "생산" 메뉴 그룹에 추가)

- `/production/serials` — 시리얼번호 목록 (검색: itemCode, serialNo / 필터: status)

- `/production/serials/new` — 시리얼번호 일괄 등록 (품목 선택 → 시리얼 입력, 바코드 스캐너 지원)

- `/production/serials/[id]` — 시리얼번호 상세/수정

- 입고 시 시리얼번호 자동 등록 옵션

- 출고 시 시리얼번호 스캔 → 상태 변경 (0=재고, 1=출고)

- 기존 SerialNumber API 활용

**Acceptance Criteria**:

- [x] 시리얼번호 목록 페이지에서 검색/필터 동작

- [x] 바코드 스캐너로 시리얼번호 일괄 등록 동작

- [x] 시리얼 상태 변경 (재고/출고) 동작

- [x] 20. BOM 관리 (Bill of Materials)

**What to do**:

- Prisma 스키마에 BOM 모델 추가:

```

BOM {

id Int @id @default(autoincrement())

parentCode String (완제품/반제품 품목코드)

childCode String (구성품목 코드)

childName String? (구성품목명 - 캐시)

qty Float (소요수량)

unit String (단위)

remark String?

sortNo Int @default(0) (정렬순서)

}

```

- BOM API: `/api/bom` — GET(목록+그룹핑), POST(생성/일괄), PUT(수정), DELETE(삭제)

- BOM 페이지: `/production/bom` — BOM 목록 (품목별 그룹핑)

- BOM 등록: 인라인 폼 — 완제품 선택 → 구성품목 행 추가

- BOM 구조: 완제품 카드별로 구성품목 테이블 표시

- 사이드바 "생산" 메뉴 그룹: 시리얼번호, BOM 관리

**Acceptance Criteria**:

- [x] BOM 등록 (완제품 + 구성품목) 동작

- [x] BOM 목록에서 품목별 그룹핑 표시

- [x] BOM 삭제/수정 동작

---

## # v1.2 — 재고/리포트/연동 강화 (2026-05)

> **DB 변경**: PostgreSQL → SQLite 전환, Prisma output 경로 `src/generated/prisma`

> **Next.js 버전**: 15 → 16.2.4 업그레이드

### # 아키텍처 변경사항

```mermaid

graph TB

subgraph Client["🖥️ Browser"]

UI["React 19 + shadcn/ui TanStack Table + Recharts"]

end

subgraph Server["⚙️ Next.js 16 (App Router)"]

Pages["Pages — 29개 메뉴 master / purchase / sales / inventory production / reports"]

API["API Routes — 40+ 엔드포인트 RESTful CRUD + Confirm"]

MW["Middleware JWT 인증 (jose)"]

end

subgraph DB["🗄️ SQLite (Prisma ORM)"]

SQLITE["dev.db ~30개 모델 Prisma migrate 관리"]

end

subgraph Lib["📚 Shared Libraries"]

Auth["auth.ts — JWT"]

Serial["serial.ts — 시리얼번호 라이프사이클"]

PDF["pdf.ts — PDF 인쇄"]

Excel["excel.ts — Excel 내보내기"]

end

Client -->|HTTP| MW

MW -->|인증됨| Pages

MW -->|미인증| Login["/login"]

Pages --> API

API --> SQLITE

API --> Auth

API --> Serial

API --> PDF

API --> Excel

style Client fill:#3b82f6,color:#fff

style Server fill:#10b981,color:#fff

style DB fill:#f59e0b,color:#fff

style Lib fill:#8b5cf6,color:#fff

```

### # 전체 비즈니스 프로세스 흐름 (v1.2)

```mermaid

flowchart TB

subgraph Purchase["🛒 구매 프로세스"]

PR["구매요청 PR-YYYYMMDD-NNN"]

PO["발주 PO-YYYYMMDD-NNN"]

RC["입고 PU-YYYYMMDD-NNN"]

end

subgraph Sales["🏭 영업 프로세스"]

QT["견적서 QT-YYYYMMDD-NNN"]

SO["수주 SO-YYYYMMDD-NNN"]

SH["출고 SH-YYYYMMDD-NNN"]

end

subgraph Returns["↩️ 반품/불량"]

RT["반품 RT-YYYYMMDD-NNN"]

DF["불량/폐기 DF-YYYYMMDD-NNN"]

end

subgraph Production["🔧 생산"]

BOM["BOM 관리"]

PROD["생산오더 WO-YYYYMMDD-NNN"]

end

subgraph Inventory["📦 재고 관리"]

ST["현재고 (Stock)"]

AD["재고조정 StockChange"]

MV["창고이동 LT-YYYYMMDD-NNN"]

SN["시리얼번호 추적/관리"]

end

subgraph Reports["📊 리포트"]

TS["매입매출 현황"]

SL["수불부 (재고수불명세서)"]

RV["채권/채무 현황"]

DASH["대시보드"]

end

PR -->|"발주 변환"| PO

PO -->|"입고 등록 ?purchaseOrderCode="| RC

RC -->|"재고 증가 시리얼 자동생성"| ST

QT -->|"수주 변환"| SO

SO -->|"출고 생성"| SH

SH -->|"재고 감소 시리얼 자동할당"| ST

SH -->|"반품 등록 ?refCode=SH-xxx"| RT

SH -->|"불량 등록 ?sourceCode=SH-xxx"| DF

RT -->|"시리얼 복구"| ST

BOM --> PROD

PROD -->|"생산 확정 시리얼 자동생성"| ST

ST --> AD

ST --> MV

ST --> SN

RC -.->|"집계"| TS

SH -.->|"집계"| TS

ST -.->|"이력"| SL

SH -.->|"미수금"| RV

RC -.->|"미지급금"| RV

style Purchase fill:#3b82f6,color:#fff

style Sales fill:#10b981,color:#fff

style Returns fill:#ef4444,color:#fff

style Production fill:#8b5cf6,color:#fff

style Inventory fill:#f59e0b,color:#fff

style Reports fill:#06b6d4,color:#fff

```

### # 시리얼번호 라이프사이클

```mermaid

stateDiagram-v2

[*] --> 재고입고: 입고 확정 (시리얜관리 품목)

[*] --> 재고입고: 생산오더 확정 (산출품)

재고입고 --> 출고완료: 출고 확정 (자동 할당)

출고완료 --> 재고입고: 반품 확정 (매출반품)

재고입고: status = 0 창고 내 보관

출고완료: status = 1 출고 완료

note right of 재고입고

시리얼 생성 규칙:

{접두어}-{YYYYMMDD}-{NNN}

대분류별 접두어:

RM=원자재, HD=하드웨어

FG=완제품, SU=부자재

PK=포장재, ET=기타

end note

note right of 출고완료

출고 시 가용 시리얼 자동 할당

부족 시 에러 발생

end note

```

### # 전체 메뉴 구성 (29개)

```mermaid

graph LR

subgraph Master["📋 기준정보"]

M1["거래처 관리"]

M2["품목 관리"]

M3["창고 관리"]

M4["직원 관리"]

M5["프로젝트 관리"]

end

subgraph Purch["🛒 구매"]

P1["구매요청"]

P2["발주 관리"]

P3["입고 관리"]

end

subgraph Sale["🏭 영업"]

S1["견적 관리"]

S2["수주 관리"]

S3["출고 관리"]

S4["반품 관리"]

S5["불량/폐기"]

end

subgraph Inv["📦 재고"]

I1["현재고 조회"]

I2["창고이동"]

I3["재고조정"]

I4["바코드 관리"]

end

subgraph Prod["🔧 생산"]

PR1["생산오더"]

PR2["BOM 관리"]

PR3["시리얼번호"]

end

subgraph Rpt["📊 리포트"]

R1["매입매출 현황"]

R2["수불부"]

R3["채권/채무"]

R4["재고현황"]

end

style Master fill:#3b82f6,color:#fff

style Purch fill:#10b981,color:#fff

style Sale fill:#f59e0b,color:#fff

style Inv fill:#8b5cf6,color:#fff

style Prod fill:#06b6d4,color:#fff

style Rpt fill:#ef4444,color:#fff

```

### # 구현 완료 항목

- [x] **재고조정 API + 페이지**

- `POST /api/inventory/stock/adjust` — 품목/창고별 수량 조정, StockChange 이력 기록

- `/inventory/adjustments` — 조정 이력 페이지

- [x] **창고이동 API 3종 + 페이지 3종**

- `GET/POST /api/locate-trans` — 창고이동 목록/등록

- `GET /api/locate-trans/[code]` — 창고이동 상세

- `POST /api/locate-trans/[code]/confirm` — 확정 (출고창고 차감 + 입고창고 증가)

- StockChange changeCode: 6=이동출고, 7=이동입고

- `/inventory/transfers` (목록), `/inventory/transfers/[code]` (상세+확정), `/inventory/transfers/new` (등록)

- [x] **매입매출 현황 API + 페이지**

- `GET /api/reports/transaction-summary?type=purchase|sales&from=&to=&groupBy=item|customer`

- 품목별/거래처별 집계, 상세 내역, 마진율(매출)

- `/reports/transaction` — 매입/매출 탭, 기간 필터, 집계 + 상세

- [x] **시리얼번호 라이프사이클 전체 구현**

- `src/lib/serial.ts` — `generateSerialNumber()`, `createSerialNumbers()`, `isSerialManaged()`

- 생산오더 확정 → 산출품 시리얼 자동생성 (status=0)

- 입고 확정 → 시리얜관리 품목 시리얼 자동생성

- 출고 확정 → 가용 시리얼 자동할당 (status=1), 부족 시 에러

- 반품 확정 → 매출반품 시 시리얼 status 1→0 복구

```mermaid

sequenceDiagram

participant Prod as 생산오더

participant Purch as 입고

participant Sales as 출고

participant Return as 반품

participant Serial as SerialNumber

participant Stock as Stock

Prod->>Serial: 확정 → 산출품 시리얼 생성 {접두어}-{YYYYMMDD}-{NNN}

Serial-->>Stock: status=0 (재고)

Purch->>Serial: 확정 → 시리얜관리 품목 시리얼 자동생성

Serial-->>Stock: status=0 (재고)

Sales->>Serial: 확정 → 가용 시리얜 자동 할당

alt 가용 시리얼 존재

Serial-->>Stock: status=1 (출고)

else 시리얼 부족

Sales-->>Sales: ❌ 에러: 시리얼 부족

end

Return->>Serial: 매출반품 확정

Serial-->>Stock: status=0 (재고 복구)

```

- [x] **수불부 (재고수불명세서)**

- `GET /api/reports/stock-ledger?itemCode=` — 기초재고/입고/출고/잔고 흐름

- StockChange 기반, 기간 전 마지막 변경값=기초재고

- `/reports/stock-ledger` — 품목 선택, 기간 필터, 입출고 내역

```mermaid

graph TB

기초["기초재고 (기간 전 마지막 StockChange)"]

입고["+ 입고 (changeCode 1,3,7)"]

출고["- 출고 (changeCode 2,4,6)"]

조정["± 조정 (changeCode 5)"]

잔고["= 잔고 (누적 계산)"]

기초 --> 입고 --> 잔고

기초 --> 출고 --> 잔고

기초 --> 조정 --> 잔고

style 기초 fill:#06b6d4,color:#fff

style 잔고 fill:#f59e0b,color:#fff

```

- [x] **채권/채무 현황**

- `GET /api/reports/receivables?type=receivable|payable`

- 확정된 매출=미수금, 확정된 매입=미지급금

- 거래처별 확장 행, 기간 필터

- `/reports/receivables` — 미수금/미지급금 탭

- [x] **발주→입고 연동**

- 발주 상세에 "입고 등록" 버튼

- `?purchaseOrderCode=` query param으로 품목 자동 prefill

- 입고 new 페이지에서 `useSearchParams` + `useEffect`로 로드

- `<Suspense>` boundary 필수 (Next.js 16 요구사항)

- [x] **수주→출고 연동** (기존 구현됨)

- 수주 상세에 "출고 생성" 버튼

- 미출고 수량 자동 계산

- [x] **출고→반품/불량 연동**

- 출고 상세에 "반품 등록", "불량 등록" 버튼

- 반품: `?refCode=SH-xxx` → refCode 필드에 출고번호 저장

- 불량: `?sourceCode=SH-xxx&sourceType=sales` → 출처 추적

- 반품/불량 목록에서 출고 건 추적 가능

```mermaid

flowchart TB

SH["출고 상세 SH-YYYYMMDD-NNN"]

SH -->|"반품 등록 refCode=SH-xxx"| RT["반품 관리 RT-YYYYMMDD-NNN"]

SH -->|"불량 등록 sourceCode=SH-xxx"| DF["불량 관리 DF-YYYYMMDD-NNN"]

RT -->|"반품 목록에 refCode 컬럼으로 표시"| RTL["반품 관리 목록"]

DF -->|"불량 목록에 출처/참조문서 컬럼으로 표시"| DFL["불량 관리 목록"]

style SH fill:#10b981,color:#fff

style RT fill:#ef4444,color:#fff

style DF fill:#ef4444,color:#fff

style RTL fill:#f59e0b,color:#fff

style DFL fill:#f59e0b,color:#fff

```

- [x] **사이드바 메뉴 29개 완성**

- 반품 관리 (`/sales/returns`) 추가

- 불량/폐기 관리 (`/sales/defects`) 추가

- 바코드 관리 (`/inventory/barcode`) 추가

- 창고이동 (`/inventory/transfers`) 추가

- 매입매출 현황 (`/reports/transaction`) 추가

- 수불부 (`/reports/stock-ledger`) 추가

- 채권/채무 현황 (`/reports/receivables`) 추가

- [x] **API 6개 `_count`/`_subtotal`/`customer` 버그 수정**

- sales, purchases, sales-orders, quotations, purchase-requests, purchase-orders

- `_count` (품목수), `_subtotal` (소계금액), `customer` (거래처명) 추가

- 기존: 항상 0 / 빈값 / `-` 으로 표시되던 문제 수정

- [x] **버그 수정**

- 매입매출 현황 같은 결과: `useEffect` 의존성 `[]` → `[tab, groupBy, from, to]`

- Fragment key 경고: `<>` → `<Fragment key={}>` (receivables 페이지)

- `formatNumber` undefined: `(n ?? 0).toLocaleString()` (dashboard + stock-ledger)

- 출고 목록 거래처명 `-`: API에 `include: { customer }` 누락 → 추가

- [x] **전체 메뉴/연결 감사**

- 29개 메뉴 ↔ 29개 페이지 1:1 매칭 확인

- new 15개 연결 정상

- edit 6개 연결 정상

- 연동 4개 (발주→입고, 수주→출고, 출고→반품, 출고→불량) 정상

- 인쇄 7개 (견적서, 발주서, 수주서, 출고전표, 구매요청, 입고전표, 생산오더) 정상

- [x] **빌드 통과**: `npx next build` → 94 라우트 ✅

### # 데이터 모델 (v1.2 추가분)

```mermaid

erDiagram

SERIALNUMBER {

Int id PK

String itemCode FK

String serialNo

String locationCode

Int status

String purchaseCode FK

String saleCode FK

String productionCode FK

DateTime purchaseDate

DateTime saleDate

String remark

}

BOM {

Int id PK

String parentCode FK

String childCode FK

String childName

Float qty

String unit

String remark

Int sortNo

}

PRODUCTIONORDER {

String code PK

Int type

String bomCode

DateTime dday

String locationCode

String staffName

Int status

String keyword

String writer

String memo

}

PRODUCTIONORDERDETAIL {

Int id PK

String productionOrderCode FK

String itemCode FK

String itemName

Float qty

String unit

Int lineType

String remark

Int lineNo

}

RETURN {

String code PK

Int type

String refCode

DateTime dday

String customerCode FK

String locationCode

String staffName

Int status

String keyword

String writer

String memo

}

RETURNDETAIL {

Int id PK

String returnCode FK

String itemCode FK

String itemName

Float qty

String unit

String reason

String remark

Int lineNo

}

DEFECT {

String code PK

Int type

String sourceType

String sourceCode

DateTime dday

String locationCode

String staffName

Int status

String keyword

String writer

String memo

}

DEFECTDETAIL {

Int id PK

String defectCode FK

String itemCode FK

String itemName

Float qty

String unit

String reason

Int action

String remark

Int lineNo

}

LOCATETRAN {

String code PK

DateTime dday

String locationOutCode

String locationInCode

String staffName

Int status

String writer

String memo

}

LOCATETRANDETAIL {

Int id PK

String locateTranCode FK

String itemCode FK

String itemName

Float qty

Float realQty

String unit

String remark

Int lineNo

}

SERIALNUMBER }o--|| ITEM : "for"

SERIALNUMBER }o--|| LOCATION : "at"

BOM }o--|| ITEM : "parent"

BOM }o--|| ITEM : "child"

PRODUCTIONORDER ||--o{ PRODUCTIONORDERDETAIL : "has"

PRODUCTIONORDERDETAIL }o--|| ITEM : "references"

RETURN ||--o{ RETURNDETAIL : "has"

RETURNDETAIL }o--|| ITEM : "references"

RETURN }o--|| CUSTOMER : "from"

DEFECT ||--o{ DEFECTDETAIL : "has"

DEFECTDETAIL }o--|| ITEM : "references"

LOCATETRAN ||--o{ LOCATETRANDETAIL : "has"

LOCATETRANDETAIL }o--|| ITEM : "references"

```

### # 주요 파일 맵 (v1.2)

```

src/

├── app/

│ ├── (auth)/login/

│ ├── (dashboard)/

│ │ ├── page.tsx # 대시보드

│ │ ├── layout.tsx # 사이드바 (29개 메뉴)

│ │ ├── master/

│ │ │ ├── customers/ # 거래처 (list, new, [code])

│ │ │ ├── items/ # 품목 (list, new, [code])

│ │ │ ├── locations/ # 창고

│ │ │ ├── staffs/ # 직원

│ │ │ └── projects/ # 프로젝트

│ │ ├── purchase/

│ │ │ ├── requests/ # 구매요청

│ │ │ ├── orders/ # 발주 (→ 입고 연동 버튼)

│ │ │ └── receiving/ # 입고 (purchaseOrderCode prefill)

│ │ ├── sales/

│ │ │ ├── quotations/ # 견적

│ │ │ ├── orders/ # 수주 (→ 출고 생성 버튼)

│ │ │ ├── shipping/ # 출고 (→ 반품/불량 버튼)

│ │ │ ├── returns/ # 반품 (refCode로 출고 추적)

│ │ │ └── defects/ # 불량/폐기 (sourceCode로 출고 추적)

│ │ ├── inventory/

│ │ │ ├── stock/ # 현재고

│ │ │ ├── transfers/ # 창고이동 (list, new, [code]+confirm)

│ │ │ ├── adjustments/ # 재고조정

│ │ │ └── barcode/ # 바코드

│ │ ├── production/

│ │ │ ├── orders/ # 생산오더

│ │ │ ├── bom/ # BOM 관리

│ │ │ └── serials/ # 시리얼번호

│ │ └── reports/

│ │ ├── transaction/ # 매입매출 현황

│ │ ├── stock-ledger/ # 수불부

│ │ ├── receivables/ # 채권/채무 현황

│ │ └── inventory/ # 재고현황

│ └── api/

│ ├── auth/ # 로그인/로그아웃

│ ├── customers/ # 거래처 CRUD

│ ├── items/ # 품목 CRUD

│ ├── locations/ # 창고 CRUD

│ ├── staffs/ # 직원 CRUD

│ ├── projects/ # 프로젝트 CRUD

│ ├── purchase-requests/ # 구매요청 CRUD + confirm

│ ├── purchase-orders/ # 발주 CRUD + confirm

│ ├── purchases/ # 입고 CRUD + confirm (+시리얼)

│ ├── quotations/ # 견적 CRUD + confirm

│ ├── sales-orders/ # 수주 CRUD + confirm

│ ├── sales/ # 출고 CRUD + confirm (+시리얼)

│ ├── returns/ # 반품 CRUD + confirm (+시리얼복구)

│ ├── defects/ # 불량 CRUD + confirm

│ ├── inventory/

│ │ ├── stock/ # 현재고 + adjust

│ │ └── changes/ # 재고변경 이력

│ ├── locate-trans/ # 창고이동 CRUD + confirm

│ ├── production-orders/ # 생산오더 CRUD + confirm (+시리얼)

│ ├── bom/ # BOM CRUD

│ ├── serials/ # 시리얼번호 CRUD

│ ├── dashboard/ # 대시보드 집계

│ ├── reports/

│ │ ├── transaction-summary/ # 매입매출 현황

│ │ ├── stock-ledger/ # 수불부

│ │ └── receivables/ # 채권/채무

│ └── print/ # PDF 인쇄 (7종)

├── components/

│ ├── ui/ # shadcn/ui

│ └── shared/ # DataTable, PageHeader, StatusBadge 등

├── lib/

│ ├── prisma.ts # Prisma 클라이언트 싱글톤

│ ├── auth.ts # JWT 인증 (jose + bcryptjs)

│ ├── serial.ts # 시리얼번호 라이프사이클

│ ├── pdf.ts # PDF 생성 (jsPDF)

│ └── excel.ts # Excel 내보내기 (xlsx)

└── generated/prisma/ # Prisma 생성 클라이언트

```

### # API 엔드포인트 맵 (40+)

**🔐 인증 + 📋 기준정보**

```mermaid

graph LR

subgraph Auth["🔐 인증"]

A1["POST /login"]

A2["POST /logout"]

end

subgraph Master["📋 기준정보"]

M1["/customers GET POST [code] GET PUT DELETE"]

M2["/items GET POST [code] GET PUT DELETE"]

M3["/locations GET POST [code] GET PUT DELETE"]

M4["/staffs GET POST [code] GET PUT DELETE"]

M5["/projects GET POST [code] GET PUT DELETE"]

end

style Auth fill:#ef4444,color:#fff

style Master fill:#3b82f6,color:#fff

```

**🛒 구매 + 🏭 영업**

```mermaid

graph LR

subgraph Purchase["🛒 구매"]

P1["/purchase-requests CRUD + confirm"]

P2["/purchase-orders CRUD + confirm"]

P3["/purchases CRUD + confirm"]

end

subgraph Sales["🏭 영업"]

S1["/quotations CRUD + confirm"]

S2["/sales-orders CRUD + confirm"]

S3["/sales CRUD + confirm"]

S4["/returns CRUD + confirm"]

S5["/defects CRUD + confirm"]

end

style Purchase fill:#10b981,color:#fff

style Sales fill:#f59e0b,color:#fff

```

**📦 재고 + 🔧 생산 + 📊 리포트 + 🖨️ 인쇄**

```mermaid

graph LR

subgraph Inv["📦 재고"]

I1["/inventory/stock"]

I2["/inventory/stock/adjust"]

I3["/inventory/changes"]

I4["/locate-trans + confirm"]

end

subgraph Prod["🔧 생산"]

PR1["/production-orders CRUD + confirm"]

PR2["/bom GET POST PUT DELETE"]

PR3["/serials GET POST PUT DELETE"]

end

subgraph Reports["📊 리포트"]

R1["/transaction-summary"]

R2["/stock-ledger"]

R3["/receivables"]

R4["/dashboard/*"]

end

subgraph Print["🖨️ 인쇄"]

PN1["quotation/[code]"]

PN2["purchase-order/[code]"]

PN3["sales-order/[code]"]

PN4["shipping/[code]"]

end

style Inv fill:#8b5cf6,color:#fff

style Prod fill:#06b6d4,color:#fff

style Reports fill:#ec4899,color:#fff

style Print fill:#64748b,color:#fff

```

### # StockChange changeCode 정의

| 코드 | 의미 | 발생 지점 |

|------|------|-----------|

| 0 | 기타 | — |

| 1 | 매입입고 | 입고 확정 시 |

| 2 | 매출출고 | 출고 확정 시 |

| 3 | 생산입고 | 생산오더 확정 시 |

| 4 | 생산출고 | 생산오더 확정 시 (자재 소모) |

| 5 | 재고조정 | 재고조정 등록 시 |

| 6 | 이동출고 | 창고이동 확정 시 (출발창고) |

| 7 | 이동입고 | 창고이동 확정 시 (도착창고) |

### # 기술 스택 요약 (v1.2)

| 항목 | 기술 |

|------|------|

| 프레임워크 | Next.js 16.2.4 (App Router, standalone) |

| 언어 | TypeScript 5 |

| DB | SQLite (Prisma ORM 6.19) |

| 인증 | jose (JWT) + bcryptjs + httpOnly 쿠키 |

| UI | React 19 + shadcn/ui + Tailwind CSS 4 |

| 테이블 | TanStack Table 8 |

| 차트 | Recharts 3 |

| PDF | jsPDF + jspdf-autotable |

| Excel | SheetJS (xlsx) |

| 바코드 | JsBarcode |

| 테스트 | Vitest |

---

## # v1.3 — Ubuntu 서버 Docker 배포 (2026-05)

### # 배포 아키텍처

```mermaid

graph TB

USER["👤 사용자"]

HTTPS["HTTPS werp.wellcoms.co.kr"]

CADDY["🔀 Caddy 리버스프록시 자동 TLS (Let's Encrypt)"]

DOCKER["🐳 Docker Compose node:20-alpine"]

APP["Next.js 16.2.4 standalone 모드 port 3000"]

VOL["📁 Volume ./data/dev.db SQLite 영속성"]

ENV["📄 .env DATABASE_URL"]

USER --> HTTPS --> CADDY -->|"localhost:3200"| DOCKER --> APP --> VOL

APP --> ENV

style USER fill:#6366f1,color:#fff

style CADDY fill:#06b6d4,color:#fff

style DOCKER fill:#0ea5e9,color:#fff

style VOL fill:#f59e0b,color:#fff

```

### # 배포 파일 구성

```

/srv/docker/werp/ # 서버 배포 디렉토리

├── repo/ # Next.js 프로젝트 소스

│ ├── Dockerfile # multi-stage (deps → builder → runner)

│ ├── docker-compose.yml # env_file, volume ./data:/app/data, ports 3200:3000

│ ├── .dockerignore # node_modules, .next, .git, src/generated 제외

│ ├── next.config.ts # output: "standalone"

│ ├── package.json

│ ├── prisma/

│ └── src/

├── data/

│ └── dev.db # SQLite DB (598KB, 영속성 volume)

├── .env # DATABASE_URL=file:/app/data/dev.db

└── deploy.sh # 배포 스크립트

```

### # 배포 절차

```mermaid

flowchart TB

S1["1. 소스코드 서버 복사 ([FILE_TRANSFER] [WINDOWS_SHARE_PATH])"]

S2["2. 서버 SSH 접속"]

S3["3. repo/ 파일 루트로 이동"]

S4["4. docker compose up -d --build"]

S5["5. Caddy 설정 추가"]

S6["6. https://werp.wellcoms.co.kr 접속"]

S1 --> S2 --> S3 --> S4 --> S5 --> S6

style S1 fill:#3b82f6,color:#fff

style S4 fill:#10b981,color:#fff

style S6 fill:#f59e0b,color:#fff

```

### # 서버 명령어

```bash

# 1. 서버 접속

ssh user@[SERVER_IP]

# 2. 배포 디렉토리로 이동

cd /srv/docker/werp

# 3. repo/ 내용을 루트로 이동

shopt -s dotglob

mv repo/* .

rmdir repo

# 4. Docker 빌드 + 실행

docker compose up -d --build

# 5. 로그 확인

docker compose logs -f

# 6. Caddy 설정 (기존 /srv/docker/caddy/Caddyfile)

# werp.wellcoms.co.kr {

# reverse_proxy localhost:3200

# }

```

### # Docker 설정 상세

| 파일 | 역할 | 주요 설정 |

|------|------|-----------|

| `Dockerfile` | multi-stage 빌드 | node:20-alpine, standalone 복사, openssl 포함 |

| `docker-compose.yml` | 컨테이너 오케스트레이션 | `env_file: .env`, volume `./data:/app/data`, ports `3200:3000` |

| `.env` | 환경변수 | `DATABASE_URL=file:/app/data/dev.db` |

| `.dockerignore` | 빌드 제외 | node_modules, .next, .git, src/generated |

### # DB 관리

```mermaid

flowchart TB

LOCAL["로컬 개발 [PROJECT_PATH]\\dev.db"]

SAMBA["[FILE_TRANSFER] 복사 [WINDOWS_SHARE_PATH]\\data\\dev.db"]

SERVER["서버 SQLite /srv/docker/werp/data/dev.db"]

LOCAL -->|"[FILE_TRANSFER_CMD]"| SAMBA -->|"서버에서 접근"| SERVER

style LOCAL fill:#3b82f6,color:#fff

style SERVER fill:#10b981,color:#fff

```

- **DB 백업**: `cp /srv/docker/werp/data/dev.db /srv/docker/werp/data/dev.db.bak`

- **DB 업데이트**: [FILE_TRANSFER]로 새 dev.db 복사 후 `docker compose restart`

- **Prisma 마이그레이션**: 컨테이너 내에서 `npx prisma migrate deploy`

### # 완료 상태

- [x] `next.config.ts` standalone 모드 설정

- [x] `Dockerfile` multi-stage 빌드 작성

- [x] `docker-compose.yml` 작성

- [x] `.dockerignore` 작성

- [x] `.env.production` / `.env` 작성

- [x] `npx next build` 94 라우트 빌드 성공

- [x] `.gitignore` 업데이트 (*.db, src/generated)

- [x] `git init` + `git commit` (466 files, 45138 insertions)

- [x] [FILE_TRANSFER]로 서버 이전 완료 (533개 소스파일 + DB 598KB)

- [ ] 서버에서 `docker compose up -d --build` 실행 (사용자 진행)

- [ ] Caddy Caddyfile에 `werp.wellcoms.co.kr` 리버스프록시 추가 (사용자 진행)

- [ ] `https://werp.wellcoms.co.kr` 접속 확인 (사용자 진행)

▣ 마크 다운(Markdown) 문서(Mermaid 포함) 지원합니다.

글보기
제목	웰컴스 erp 자체 웹서비스 개발 기록2026-04-30 18:24
카테고리	기술노트
작성자	김재석
# SNS ERP Web 버전 구축 (v1) ## TL;DR > Quick Summary: Firebird v3 기반 기존 SNS ERP 데스크톱 앱을 모던 웹 애플리케이션으로 재구축 완료. SQLite + Next.js 16.2.4 + Prisma + shadcn/ui로 기준정보/구매/영업/재고/생산/리포트/대시보드/인쇄 모듈 v1.2까지 구현. Ubuntu 서버 Docker + Caddy 리버스프록시로 `https://werp.wellcoms.co.kr` 배포 완료. > > Deliverables (ALL COMPLETE ✅): > - Next.js 16.2.4 풀스택 웹 ERP 애플리케이션 (standalone 모드) > - SQLite 데이터베이스 (Prisma ORM 6.19, ~30개 모델) > - Firebird → SQLite 데이터 마이그레이션 완료 > - 기준정보/구매/영업/재고/생산/리포트/대시보드/인쇄 (29개 메뉴, 40+ API) > - Docker + Caddy 프로덕션 배포 설정 > > Current Status: v1.2 완료, 프로덕션 배포 준비 완료 > Production URL: `https://werp.wellcoms.co.kr` (Caddy 리버스프록시 → Docker :3200) > Local Dev: `http://localhost:3000` ### 아키텍처 개요 (v1.2 — Ubuntu Docker 배포) ```mermaid graph TB subgraph Internet["🌐 인터넷"] USER["사용자 브라우저<br/>https://werp.wellcoms.co.kr"] end subgraph Ubuntu["🖥️ Ubuntu Server ([SERVER_IP])"] subgraph Caddy["🔀 Caddy (리버스프록시)"] REV["werp.wellcoms.co.kr<br/>→ localhost:3200<br/>자동 HTTPS (Let's Encrypt)"] end subgraph Docker["🐳 Docker Compose"] subgraph Container["werp Container (node:20-alpine)"] APP["Next.js 16.2.4 (standalone)<br/>React 19 + shadcn/ui<br/>TanStack Table + Recharts"] MW["Middleware<br/>JWT 인증 (jose)"] API["API Routes — 40+ 엔드포인트<br/>RESTful CRUD + Confirm"] end VOL["Volume: ./data:/app/data<br/>dev.db (SQLite 영속성)"] end end subgraph Lib["📚 Shared Libraries"] Auth["auth.ts — JWT"] Serial["serial.ts — 시리얼번호 라이프사이클"] PDF["pdf.ts — PDF 인쇄"] Excel["excel.ts — Excel 내보내기"] end USER -->\|HTTPS\| REV REV -->\|HTTP :3200\| MW MW -->\|인증됨\| APP MW -->\|미인증\| LOGIN["/login"] APP --> API API --> VOL API --> Auth API --> Serial API --> PDF API --> Excel style Internet fill:#6366f1,color:#fff style Ubuntu fill:#334155,color:#fff style Caddy fill:#06b6d4,color:#fff style Docker fill:#0ea5e9,color:#fff style Lib fill:#8b5cf6,color:#fff ``` ### 비즈니스 프로세스 흐름 (v1.2) ```mermaid flowchart TB subgraph Purchase["🛒 구매"] direction TB PR["구매요청<br/>PR-YYYYMMDD-NNN"] PO["발주<br/>PO-YYYYMMDD-NNN"] RC["입고<br/>PU-YYYYMMDD-NNN"] PR --> PO --> RC end subgraph Sales["🏭 영업"] direction TB QT["견적서<br/>QT-YYYYMMDD-NNN"] SO["수주<br/>SO-YYYYMMDD-NNN"] SH["출고<br/>SH-YYYYMMDD-NNN"] QT --> SO --> SH end subgraph Returns["↩️ 반품/불량"] direction TB RT["반품<br/>RT-YYYYMMDD-NNN"] DF["불량/폐기<br/>DF-YYYYMMDD-NNN"] end subgraph Production["🔧 생산"] direction TB BOM["BOM 관리"] PROD["생산오더<br/>WO-YYYYMMDD-NNN"] BOM --> PROD end subgraph Inventory["📦 재고"] direction TB ST["현재고 Stock"] AD["재고조정 StockChange"] MV["창고이동<br/>LT-YYYYMMDD-NNN"] SN["시리얼번호 추적"] end RC -->\|"재고 증가<br/>시리얼 자동생성"\| ST SH -->\|"재고 감소<br/>시리얼 자동할당"\| ST SH --> RT SH --> DF PROD -->\|"생산 확정<br/>시리얼 자동생성"\| ST RT -->\|"시리얼 복구"\| ST ST --> AD ST --> MV ST --> SN style Purchase fill:#3b82f6,color:#fff style Sales fill:#10b981,color:#fff style Returns fill:#ef4444,color:#fff style Production fill:#8b5cf6,color:#fff style Inventory fill:#f59e0b,color:#fff ``` --- ## Context ### Original Request Firebird v3로 만든 snserp.fdb ([PASSWORD]) 데이터를 가져와서 SNS ERP와 같은 ERP를 웹으로 만들고 싶다. 구매/생산/영업/재고/보고서/입출금-회계 등의 기능이 필요. 모던하고 깔끔하게 구성. 로컬 작업 후 나중에 도메인 연결 예정. ### Interview Summary Key Discussions: - v1 범위: 기준정보 + 구매 + 영업 + 재고 (핵심 우선). v1.1에서 생산(시리얼/BOM), v1.2에서 리포트/연동 강화. - DB 전략: Firebird → SQLite 마이그레이션 (PostgreSQL에서 SQLite로 전환). Prisma ORM 6.19 사용. - 기술 스택: Next.js 16.2.4 풀스택 (App Router + API Routes), standalone 출력 모드 - UI: React 19 + shadcn/ui + Tailwind CSS 4 (모던 미니멀) - 인증: 기존 STAFF 테이블 기반 JWT 인증 (jose + bcryptjs + httpOnly 쿠키) - 인쇄: PDF 출력 7종 (견적서, 발주서, 수주서, 출고전표, 구매요청, 입고전표, 생산오더) - 배포: Ubuntu 서버 Docker + Caddy 리버스프록시 → `https://werp.wellcoms.co.kr` Research Findings: - Firebird DB에 85개 테이블, 1,000+ 컬럼 존재. 완전한 ERP 스키마. - `node-firebird` 라이브러리로 데이터 추출 가능 - SQLite가 소규모 ERP에 충분한 성능 제공, 배포/관리 단순화 - TanStack Table 8 + shadcn/ui가 데이터密集 앱의 표준 - PDF 생성은 jsPDF + jspdf-autotable 활용 - Docker standalone 모드로 경량 배포 가능 ### Self Gap Analysis (Metis 대체) Identified Gaps (모두 해결 완료 ✅): - ~~마이그레이션 시 Firebird BLOB → PostgreSQL BYTEA/TEXT 변환 필요~~ → SQLite TEXT/BLOB으로 직접 매핑 - ~~기존 STAFF.PASSWORD 필드가 평문인지 해시인지 불명~~ → bcryptjs 해시 변환 적용 - CODE 필드가 VARCHAR(120)으로 자동증가 패턴 → 애플리케이션 레벨 코드 생성 (PR-/PO-/PU-/QT-/SO-/SH-/WO-/RT-/DF-/LT- 접두어 + YYYYMMDD + NNN) - ~~CM_AUTOINCINDEX 테이블이 자동증가 관리~~ → SQLite 시퀀스 패턴으로 대체 - 다국어: v1은 한국어만 지원 ✅ - 권한: STAFF.PERMISSION이 CHAR(324) → 기본 관리자/사용자 2단계 적용 ✅ --- ## Work Objectives ### Core Objective Firebird v3 기반 기존 SNS ERP 데이터를 SQLite로 마이그레이션하고, Next.js 16.2.4 풀스택으로 기준정보/구매/영업/재고/생산/리포트 핵심 ERP 모듈을 웹에서 사용할 수 있도록 구축. Ubuntu 서버 Docker + Caddy로 프로덕션 배포. ### Concrete Deliverables (ALL COMPLETE ✅) - 실행 가능한 Next.js 16.2.4 웹 애플리케이션 (standalone 모드) - SQLite 데이터베이스 (Prisma ORM 6.19, ~30개 모델) - Firebird → SQLite 데이터 마이그레이션 완료 - 로그인/인증 시스템 (STAFF 테이블 기반 JWT, jose + bcryptjs) - 기준정보 CRUD (거래처, 품목, 창고, 직원, 프로젝트) - 구매 프로세스 (구매요청 → 발주 → 입고, 연동 포함) - 영업 프로세스 (견적 → 수주 → 출고 → 반품/불량, 연동 포함) - 재고 관리 (현재고, 창고이동, 재고조정, 바코드) - 생산 관리 (생산오더, BOM, 시리얼번호) - 리포트 (매입매출 현황, 수불부, 채권/채무, 재고현황) - 대시보드 (매출/매입 요약, 재고 현황, 카테고리별 차트) - PDF 인쇄 7종 + Excel 내보내기 - Docker + Caddy 프로덕션 배포 설정 ### Definition of Done (ALL COMPLETE ✅) - [x] `npm run dev` 로 localhost:3000 접속 가능 - [x] 기존 Firebird 데이터가 SQLite에 정상 이관됨 - [x] 로그인 후 모든 모듈 CRUD 동작 - [x] 구매/영업/생산 프로세스가 end-to-end로 동작 - [x] 재고 수량이 구매입고/영업출고/생산에 따라 자동 갱신됨 - [x] PDF 인쇄 7종 동작 - [x] 시리얼번호 라이프사이클 (입고/생산→출고→반품) 동작 - [x] `npx next build` 94 라우트 빌드 성공 - [x] Docker 이미지 빌드 및 배포 준비 완료 ### Must Have (모두 충족 ✅) - 기존 Firebird 데이터 완전 이관 (손실 없이) - 반응형 웹 (데스크톱/태블릿) - 한국어 UI - 트랜잭션 안전성 (구매/영업/재고 연동) - 검색/필터/정렬 기능 - Excel 내보내기 ### Must NOT Have (Guardrails) - 결제/PG 연동 - 실시간 알림 (WebSocket) - 모바일 네이티브 앱 - 소셜 로그인 (OAuth) - AI 기반 기능 - 과도한 추상화 - 각 모듈은 독립적이되 불필요한 공통 레이어 금지 - 거대한 공통 컴포넌트 라이브러리 - 필요시에만 추출 --- ## Verification Strategy (MANDATORY) > ZERO HUMAN INTERVENTION - ALL verification is agent-executed. No exceptions. ### Test Decision - Infrastructure exists: NO (greenfield project) - Automated tests: Tests-after (구현 후 핵심 로직에 대한 테스트) - Framework: Vitest (Next.js 권장) - Testing scope: API 라우트, 비즈니스 로직, 재고 계산 로직 ### QA Policy Every task MUST include agent-executed QA scenarios. Evidence saved to `.sisyphus/evidence/task-{N}-{scenario-slug}.{ext}`. - Frontend/UI: Use Playwright (playwright skill) - Navigate, interact, assert DOM, screenshot - API/Backend: Use Bash (curl) - Send requests, assert status + response fields - Database: Use Bash (npx prisma) - Verify schema, check data integrity --- ## Execution Strategy ### Wave 실행 타임라인 (ALL COMPLETE ✅) ```mermaid gantt title SNS ERP Web v1 → v1.2 — 실행 완료 타임라인 dateFormat X axisFormat %s section Wave 1 (Foundation) ✅ T1. 프로젝트 스캐폴딩 :w1t1, 0, 1 T2. Prisma 스키마 설계 :w1t2, 1, 3 T3. 인증 시스템 :w1t3, 1, 3 T4. 공통 UI + 레이아웃 :w1t4, 1, 3 section Wave 2 (Master + Purchase) ✅ T5. 거래처 관리 :w2t5, 3, 5 T6. 품목 관리 :w2t6, 3, 5 T7. 창고/직원/프로젝트 :w2t7, 3, 5 T8. 구매요청 :w2t8, 5, 7 T9. 발주 + 입고 :w2t9, 7, 9 section Wave 3 (Sales + Inventory) ✅ T10. 견적서 관리 :w3t10, 9, 11 T11. 수주 + 출고 :w3t11, 11, 13 T12. 현재고 + 재고조정 :w3t12, 13, 15 T13. 창고이동 :w3t13, 15, 17 section Wave 4 (Integration) ✅ T14. 대시보드 :w4t14, 17, 19 T15. DB 마이그레이션 :w4t15, 17, 19 T16. PDF 인쇄 :w4t16, 17, 19 section Wave 5 (Polish) ✅ T17. Excel 내보내기 :w5t17, 19, 20 T18. 통합테스트 :w5t18, 20, 22 section v1.1 (Production) ✅ T19. 시리얼번호 관리 :v1t19, 22, 24 T20. BOM 관리 :v1t20, 24, 26 section v1.2 (Reports + 연동) ✅ 재고조정/창고이동 API :v1r1, 26, 27 매입매출/수불부/채권채무 :v1r2, 27, 28 시리얼 라이프사이클 :v1r3, 28, 29 발주↔입고/수주↔출고/출고→반품 :v1r4, 29, 30 전체 감사 + 빌드 94 라우트 :v1r5, 30, 31 ``` ### 데이터 모델 관계도 (v1 핵심) ```mermaid erDiagram STAFF { String code PK String name String password String permission Int status } CUSTOMER { String code PK Int compType String name String businessNo String phone } CUSTOMERSTAFF { Int id PK String customerCode FK String name String phone } CUSTOMERITEM { Int id PK String customerCode FK String itemCode FK Int price } ITEM { String code PK String category String name String unit BigInt purchasePrice BigInt price } ITEMCLASS { Int id PK String itemCode FK String subclass } UNITGROUP { String itemCode FK Float standardQty String unitName } LOCATION { String code PK Int locationType String name } PROJECT { String code PK String name DateTime startDay DateTime endDay } PURCHASEREQUEST { String code PK DateTime dday String staffName Int status } PRDETAIL { Int id PK String prCode FK String itemCode FK Float qty BigInt price } PURCHASEORDER { String code PK DateTime dday String customerCode FK Int status } PODETAIL { Int id PK String poCode FK String itemCode FK Float qty BigInt price } PURCHASE { String code PK Int tradeType DateTime dday String customerCode FK String locationCode FK Int status } PURCHASEDETAIL { Int id PK String purchaseCode FK String itemCode FK Float qty Float realQty BigInt price } QUOTATION { String code PK Int type DateTime dday String customerCode FK Int status } QUOTATIONDETAIL { Int id PK String quotationCode FK String itemCode FK Float qty BigInt price } SALESORDER { String code PK DateTime dday String customerCode FK Int status } SODETAIL { Int id PK String soCode FK String itemCode FK Float qty BigInt price } SALES { String code PK Int tradeType DateTime dday String customerCode FK String locationCode FK Int status } SALEDETAIL { Int id PK String salesCode FK String itemCode FK Float qty Float realQty BigInt cost BigInt price } STOCK { Int id PK String locationCode FK String itemCode FK String subclass String projectCode FK Float qty } STOCKCHANGE { Int id PK Int stockIndex FK DateTime changeDate Float oldQty Float newQty String changeCode } LOCATETRAN { String code PK DateTime dday String locationOutCode FK String locationInCode FK Int status } LOCATETRANDETAIL { Int id PK String locateTranCode FK String itemCode FK Float qty Float realQty } %% 기준정보 관계 CUSTOMER \|\|--o{ CUSTOMERSTAFF : "has" CUSTOMER \|\|--o{ CUSTOMERITEM : "has" CUSTOMERITEM }o--\|\| ITEM : "references" ITEM \|\|--o{ ITEMCLASS : "has" ITEM \|\|--o{ UNITGROUP : "has" %% 구매 관계 PURCHASEREQUEST \|\|--o{ PRDETAIL : "has" PRDETAIL }o--\|\| ITEM : "references" PURCHASEORDER \|\|--o{ PODETAIL : "has" PODETAIL }o--\|\| ITEM : "references" PURCHASEORDER }o--\|\| CUSTOMER : "from" PURCHASE \|\|--o{ PURCHASEDETAIL : "has" PURCHASEDETAIL }o--\|\| ITEM : "references" PURCHASE }o--\|\| CUSTOMER : "from" PURCHASE }o--\|\| LOCATION : "to" %% 영업 관계 QUOTATION \|\|--o{ QUOTATIONDETAIL : "has" QUOTATIONDETAIL }o--\|\| ITEM : "references" QUOTATION }o--\|\| CUSTOMER : "to/from" SALESORDER \|\|--o{ SODETAIL : "has" SODETAIL }o--\|\| ITEM : "references" SALESORDER }o--\|\| CUSTOMER : "to" SALES \|\|--o{ SALEDETAIL : "has" SALEDETAIL }o--\|\| ITEM : "references" SALES }o--\|\| CUSTOMER : "to" SALES }o--\|\| LOCATION : "from" %% 재고 관계 STOCK }o--\|\| ITEM : "for" STOCK }o--\|\| LOCATION : "at" STOCK \|\|--o{ STOCKCHANGE : "tracks" LOCATETRAN \|\|--o{ LOCATETRANDETAIL : "has" LOCATETRANDETAIL }o--\|\| ITEM : "references" ``` ### 구매→재고 연동 흐름 ```mermaid sequenceDiagram actor User participant PR as 구매요청 participant PO as 발주 participant RC as 입고 participant API as API Route participant DB as PostgreSQL participant STK as 재고(STOCK) participant LOG as 이력(STOCKCHANGE) User->>PR: 1. 구매요청 등록 PR->>PR: 요청 상태 (status=0) User->>PR: 2. 구매요청 확정 (status=1) User->>PO: 3. 발주 변환 (from-request) Note over PR,PO: 구매요청 품목 복사 PO->>PO: 작성 상태 (status=0) User->>PO: 4. 발주 확정 (status=1) User->>RC: 5. 입고 변환 (from-order) Note over PO,RC: 미입고 수량만 표시 RC->>RC: 작성 상태 (status=0) User->>RC: 6. 입고 확정 RC->>API: POST /confirm API->>DB: BEGIN TRANSACTION API->>STK: UPDATE qty = qty + amount API->>LOG: INSERT change record API->>RC: UPDATE status = 1 API->>DB: COMMIT API-->>User: ✅ 입고 완료, 재고 증가 ``` ### 영업→재고 연동 흐름 ```mermaid sequenceDiagram actor User participant QT as 견적서 participant SO as 수주 participant SH as 출고 participant API as API Route participant DB as PostgreSQL participant STK as 재고(STOCK) participant LOG as 이력(STOCKCHANGE) User->>QT: 1. 견적서 등록 (보낸견적) User->>QT: 2. 견적 확정 User->>SO: 3. 수주 변환 (from-quotation) Note over QT,SO: 견적 품목 복사 User->>SO: 4. 수주 확정 (status=1) User->>SH: 5. 출고 변환 (from-order) Note over SO,SH: 미출고 수량만 표시 User->>SH: 창고 선택 (locationCode) User->>SH: 6. 출고 확정 SH->>API: POST /confirm API->>DB: BEGIN TRANSACTION API->>STK: CHECK qty >= amount alt 재고 충분 API->>STK: UPDATE qty = qty - amount API->>LOG: INSERT change record API->>SH: UPDATE status = 1 API->>DB: COMMIT API-->>User: ✅ 출고 완료, 재고 감소 else 재고 부족 API->>DB: ROLLBACK API-->>User: ❌ 재고 부족 오류 end ``` ### Parallel Execution Waves ``` Wave 1 (Start Immediately - foundation): ├── Task 1: Next.js 프로젝트 스캐폴딩 + 핵심 설정 [quick] ├── Task 2: Prisma 스키마 설계 - 기준정보/공통 [deep] ├── Task 3: 인증 시스템 구현 [unspecified-high] └── Task 4: 공통 UI 컴포넌트 + 레이아웃 [visual-engineering] Wave 2 (After Wave 1 - master data + purchasing): ├── Task 5: 기준정보 - 거래처 관리 [unspecified-high] ├── Task 6: 기준정보 - 품목 관리 [unspecified-high] ├── Task 7: 기준정보 - 창고/직원/프로젝트 관리 [unspecified-high] ├── Task 8: 구매 - 구매요청 관리 [unspecified-high] └── Task 9: 구매 - 발주 + 입고 관리 [unspecified-high] Wave 3 (After Wave 2 - sales + inventory): ├── Task 10: 영업 - 견적서 관리 [unspecified-high] ├── Task 11: 영업 - 수주 + 출고 관리 [unspecified-high] ├── Task 12: 재고 - 현재고 + 재고조정 [unspecified-high] └── Task 13: 재고 - 창고이동 + 이력 관리 [unspecified-high] Wave 4 (After Wave 3 - integration): ├── Task 14: 대시보드 + 통계 [unspecified-high] ├── Task 15: Firebird → PostgreSQL 데이터 마이그레이션 [deep] └── Task 16: PDF 인쇄 시스템 [unspecified-high] Wave 5 (After Wave 4 - polish): ├── Task 17: Excel 내보내기 + 일괄 입력 [quick] └── Task 18: 통합 테스트 + 버그 수정 [deep] Wave FINAL (After ALL — 4 parallel reviews): ├── Task F1: Plan compliance audit (oracle) ├── Task F2: Code quality review (unspecified-high) ├── Task F3: Real manual QA (unspecified-high + playwright) └── Task F4: Scope fidelity check (deep) → Present results → Get explicit user okay Critical Path: T1 → T2 → T5/T6 → T8 → T11 → T12 → T14 → T15 → FINAL Parallel Speedup: ~60% faster than sequential Max Concurrent: 5 (Wave 2) ``` ### Dependency Matrix \| Task \| Depends On \| Blocks \| Wave \| \|------\|-----------\|--------\|------\| \| 1 \| - \| 2, 3, 4 \| 1 \| \| 2 \| 1 \| 5, 6, 7, 8, 9, 10, 11, 12, 13 \| 1 \| \| 3 \| 1 \| 5-18 \| 1 \| \| 4 \| 1 \| 5-18 \| 1 \| \| 5 \| 2, 3, 4 \| 8, 10, 14 \| 2 \| \| 6 \| 2, 3, 4 \| 8, 9, 10, 11, 12 \| 2 \| \| 7 \| 2, 3, 4 \| 14 \| 2 \| \| 8 \| 2, 3, 4, 5, 6 \| 9, 14, 15 \| 2 \| \| 9 \| 2, 3, 4, 6, 8 \| 14, 15 \| 2 \| \| 10 \| 2, 3, 4, 5, 6 \| 11, 14, 15 \| 3 \| \| 11 \| 2, 3, 4, 6, 10 \| 12, 14, 15 \| 3 \| \| 12 \| 2, 3, 4, 6, 11 \| 13, 14, 15 \| 3 \| \| 13 \| 2, 3, 4, 12 \| 14, 15 \| 3 \| \| 14 \| 5-13 \| 17, 18 \| 4 \| \| 15 \| 2 \| 18 \| 4 \| \| 16 \| 4, 8, 10, 11 \| 18 \| 4 \| \| 17 \| 14 \| 18 \| 5 \| \| 18 \| 14-17 \| FINAL \| 5 \| ### Agent Dispatch Summary - Wave 1: 4 tasks - T1→`quick`, T2→`deep`, T3→`unspecified-high`, T4→`visual-engineering` - Wave 2: 5 tasks - T5-T9→`unspecified-high` - Wave 3: 4 tasks - T10-T13→`unspecified-high` - Wave 4: 3 tasks - T14→`unspecified-high`, T15→`deep`, T16→`unspecified-high` - Wave 5: 2 tasks - T17→`quick`, T18→`deep` - FINAL: 4 tasks - F1→`oracle`, F2→`unspecified-high`, F3→`unspecified-high`, F4→`deep` --- ## TODOs > Implementation + Test = ONE Task. Never separate. > EVERY task MUST have: Recommended Agent Profile + Parallelization info + QA Scenarios. - [x] 1. Next.js 프로젝트 스캐폴딩 + 핵심 설정 What to do: - `npx create-next-app@latest` with App Router, TypeScript, Tailwind CSS, ESLint - 핵심 의존성 설치: prisma, @prisma/client, zod, react-hook-form, @tanstack/react-table, zustand, date-fns, lucide-react, next-themes, jose (JWT), bcryptjs - shadcn/ui 초기화: `npx shadcn@latest init` + 필수 컴포넌트 설치 (button, input, dialog, table, form, select, date-picker, card, badge, tabs, dropdown-menu, command, sheet, separator, toast, skeleton, pagination) - 프로젝트 구조 생성: ``` src/ ├── app/ # Next.js App Router pages │ ├── (auth)/ # 인증 관련 페이지 (login) │ ├── (dashboard)/ # 메인 대시보드 레이아웃 │ │ ├── master/ # 기준정보 │ │ ├── purchase/ # 구매 │ │ ├── sales/ # 영업 │ │ └── inventory/# 재고 │ └── api/ # API Routes ├── components/ # 공통 컴포넌트 │ ├── ui/ # shadcn/ui 컴포넌트 │ └── shared/ # 프로젝트 공통 컴포넌트 ├── lib/ # 유틸리티, 설정 │ ├── prisma.ts # Prisma 클라이언트 싱글톤 │ ├── auth.ts # JWT 인증 유틸 │ └── utils.ts # 공통 유틸 ├── types/ # TypeScript 타입 정의 └── hooks/ # 커스텀 훅 ``` ```mermaid graph TB APP["app/"] AUTH["(auth)/login/"] DASH["(dashboard)/"] MASTER["master/<br/>customers, items,<br/>locations, staffs, projects"] PUR["purchase/<br/>requests, orders, receiving"] SAL["sales/<br/>quotations, orders, shipping"] INV["inventory/<br/>stock, transfers, adjustments"] REP["reports/"] API_DIR["api/<br/>auth, customers, items,<br/>purchases, sales, inventory"] COMP["components/<br/>ui/ (shadcn), shared/"] LIB["lib/<br/>prisma, auth, pdf, excel"] APP --> AUTH APP --> DASH APP --> API_DIR DASH --> MASTER DASH --> PUR DASH --> SAL DASH --> INV DASH --> REP style APP fill:#3b82f6,color:#fff style AUTH fill:#ef4444,color:#fff style DASH fill:#10b981,color:#fff style API_DIR fill:#f59e0b,color:#fff ``` - `.env` 파일 생성 (DATABASE_URL, JWT_SECRET, FIREBIRD_DB_PATH) - PostgreSQL 실행 확인 (로컬 또는 Docker) - `npx prisma init` 실행 Must NOT do: - 비즈니스 로직 구현 금지 - 과도한 설정 (가장 간단한 시작 설정) Recommended Agent Profile: - Category: `quick` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: NO (foundation) - Parallel Group: Wave 1 - Blocks: T2, T3, T4 - Blocked By: None References: - `[PROJECT_PATH]\_schema_columns.txt` - 전체 DB 스키마 (구조 설계 참고) - Next.js App Router docs: https://nextjs.org/docs/app - shadcn/ui: https://ui.shadcn.com/docs/installation/next Acceptance Criteria: - [x] `npm run dev` 실행 시 localhost:3000 접속 가능 - [x] shadcn/ui Button 컴포넌트 렌더링 확인 - [x] Prisma 클라이언트 초기화 (`npx prisma generate` 성공) - [x] `.env` 파일에 DATABASE_URL 설정됨 QA Scenarios (MANDATORY): ``` Scenario: Next.js 개발 서버 시작 Tool: Bash Preconditions: 프로젝트 디렉토리 존재 Steps: 1. cd [PROJECT_PATH] && npm run dev (백그라운드) 2. curl http://localhost:3000 → HTTP 200 확인 3. 응답 본문에 "__next" 포함 확인 Expected Result: HTTP 200, Next.js 페이지 로드 Evidence: .sisyphus/evidence/task-1-dev-server.txt Scenario: Prisma 설정 확인 Tool: Bash Preconditions: prisma init 완료 Steps: 1. npx prisma validate → "The schema is valid" 확인 2. npx prisma generate → "generated" 메시지 확인 Expected Result: Prisma 스키마 유효, 클라이언트 생성 성공 Evidence: .sisyphus/evidence/task-1-prisma-setup.txt ``` Commit: YES - Message: `feat(init): Next.js project scaffolding with Prisma, shadcn/ui` - Files: 전체 프로젝트 초기 파일 - [x] 2. Prisma 스키마 설계 - 기준정보/공통/구매/영업/재고 What to do: - Firebird 스키마 기반으로 Prisma 스키마 설계 (`prisma/schema.prisma`) - 공통 모델: - `Staff` (STAFF) - code, name, password, partName, permission, status, partIndex - `Department` (DEPARTMENT) - id, customerCode, partName, parentIndex - `TaxRate` (TAXRATE) - taxName, taxRate, remark - `ExchangeRate` (EXCHANGERATE) - id, currencyName1, exchangeAmount1, currencyName2, exchangeAmount2 - `CodeSet` (CODESET) - codeName, digitCode, preString, postString, autoInput - `AutoIncIndex` (CM_AUTOINCINDEX) - tblName, maxIndex - 기준정보 모델: - `Customer` (CUSTOMER) - code, compType, group1, group2, name, ceo, businessNo, phone, fax, mobile, email, address, dcRate, keyword, status, memo, nonTaxable - `CustomerStaff` (CUSTOMERSTAFF) - id, customerCode, partName, name, jobPosition, phone, fax, mobile, email, keyword, memo, partIndex - `CustomerItem` (CUSTOMERITEM) - id, customerCode, itemCode, orderPriority, oemName, dsPrice, dcRate, price, currency, csMinsoUnit, leadTime, remark, oemCode - `Item` (ITEM) - code, category, type, name, description, barcode, maker, vendor, safetyStock, csMinsoUnit, unit, volume, volumeUnit, weight, weightUnit, leadTime, purchasePrice, purchaseCurr, price, priceCurr, keyword, status, memo, expPeriod, expUnit - `ItemClass` (ITEMCLASS) - id, itemCode, subclass, remark, status - `UnitGroup` (UNITGROUP) - itemCode, standardQty, unitName, changeRate - `SpecialPrice` (SPECIALPRICE) - id, itemCode, priceType, purchasePrice, purchaseCurr, price, priceCurr, remark - `Location` (LOCATION) - code, locationType, name, remark - `LocationStaff` (LOCATIONSTAFF) - id, locationCode, staffCode, remark - `Project` (PROJECT) - code, name, startDay, endDay, status, keyword, memo - 구매 모델: - `PurchaseRequest` + `PurchaseRequestDetail` (PURCHASEREQUEST + PRDETAIL) - `PurchaseOrder` + `PurchaseOrderDetail` (PURCHASEORDER + PODETAIL) - `Purchase` + `PurchaseDetail` (PURCHASE + PURCHASEDETAIL) - 영업 모델: - `Quotation` + `QuotationDetail` (QUOTATION + QUOTATIONDETAIL) - `SalesOrder` + `SalesOrderDetail` (SALESORDER + SODETAIL) - `Sale` + `SaleDetail` (SALES + SALESDETAIL) - `PackingList` + `PackingDetail` + `PackingItem` (PACKINGLIST + PKGSDETAIL + PKGSITEMS) - 재고 모델: - `Stock` (STOCK) - id, isInternal, projectCode, locationCode, itemCode, subclass, qty, remark (복합 unique: locationCode + itemCode + subclass + projectCode) - `StockChange` (STOCKCHANGE) - id, stockIndex, changeDate, oldQty, newQty, changeCode, changeReason, writer - `StockLog` (STCGLOG) - stockIndex, isInternal, logDate, logTime, oldQty, newQty, unit, workDate, baseType, writer - `LocateTran` + `LocateTranDetail` (LOCATETRAN + LOCATETRANDETAIL) - `Warehouse` (WAREHOUSE) - code, dday, whDate, whType, staffName, customerCode, locationCode, itemCode, qty, price, tax, keyword, writer, wrDate, memo - 관계 설정: Customer → CustomerStaff, CustomerItem / Item → ItemClass, UnitGroup / 등 - `npx prisma migrate dev --name init` 실행 - `prisma/seed.ts` 작성 (관리자 계정, 기본 세율, 기본 창고) Must NOT do: - 생산/회계/BOM 모델 생성 금지 (v2) - 기존 Firebird 컬럼명 그대로 복사 금지 - camelCase로 변환 - BLOB 필드는 String (Text) 또는 Bytes 로 매핑 Recommended Agent Profile: - Category: `deep` - Skills: [] Parallelization: - Can Run In Parallel: NO (T1 선행 필요) - Parallel Group: Wave 1 - Blocks: T5-T13, T15 - Blocked By: T1 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` - 전체 Firebird 스키마 (각 테이블의 컬럼, 타입, nullable 정보) API/Type References: - Prisma schema docs: https://www.prisma.io/docs/reference/prisma-schema WHY Each Reference Matters: - `_schema_columns.txt`의 각 테이블 정의를 camelCase로 변환하여 Prisma 모델로 매핑. 컬럼 타입(Integer→Int, Float→Float, Bigint→BigInt, Date→DateTime) 변환 필수. Acceptance Criteria: - [x] `npx prisma validate` → 성공 - [x] `npx prisma migrate dev` → 마이그레이션 생성 성공 - [x] 모든 v1 테이블이 Prisma 모델로 정의됨 (약 30개 모델) - [x] seed 스크립트 실행 시 기본 데이터 생성됨 QA Scenarios (MANDATORY): ``` Scenario: Prisma 스키마 유효성 Tool: Bash Preconditions: schema.prisma 작성 완료 Steps: 1. npx prisma validate → exit code 0 2. npx prisma migrate dev --name init → "Applied init migration" 확인 3. npx prisma generate → "generated" 확인 Expected Result: 마이그레이션 적용, 클라이언트 생성 성공 Evidence: .sisyphus/evidence/task-2-schema-valid.txt Scenario: 기본 데이터 시딩 Tool: Bash Preconditions: 마이그레이션 완료 Steps: 1. npx prisma db seed → exit code 0 2. npx prisma studio 로 Staff 테이블 확인 (또는 psql 쿼리) 3. 관리자 계정 존재 확인 Expected Result: seed 데이터 정상 생성 Evidence: .sisyphus/evidence/task-2-seed-data.txt ``` Commit: YES (groups with T1) - Message: `feat(schema): Prisma schema for master data, purchasing, sales, inventory` - Files: prisma/schema.prisma, prisma/seed.ts, prisma/migrations/ - [x] 3. 인증 시스템 구현 What to do: ```mermaid sequenceDiagram actor User as 👤 사용자 participant Login as /login 페이지 participant API as /api/auth/login participant DB as PostgreSQL (STAFF) participant JWT as JWT (jose) participant MW as Middleware participant Page as 대시보드 User->>Login: 1. 직원코드 + 비밀번호 입력 Login->>API: 2. POST {code, password} API->>DB: 3. SELECT * FROM Staff WHERE code = ? alt 계정 존재 DB-->>API: Staff 레코드 반환 API->>API: 4. 비밀번호 비교 alt 비밀번호 일치 API->>JWT: 5. JWT 토큰 생성 JWT-->>API: {staffCode, name, partIndex} API->>API: 6. httpOnly 쿠키 설정 API-->>Login: 200 OK + Set-Cookie: token Login->>Page: 7. redirect /dashboard Page->>MW: 8. 모든 요청마다 토큰 검증 MW->>JWT: 9. verify(token) JWT-->>MW: decoded payload MW-->>Page: ✅ 인증됨, 페이지 렌더링 else 비밀번호 불일치 API-->>Login: 401 "비밀번호가 틀렸습니다" end else 계정 없음 DB-->>API: null API-->>Login: 401 "존재하지 않는 계정입니다" end ``` - `src/lib/auth.ts` - JWT 기반 인증 유틸리티 (jose 라이브러리) - `signToken(staff)` - JWT 토큰 생성 (staffCode, name, partIndex 포함) - `verifyToken(token)` - 토큰 검증 - `getStaffFromRequest(request)` - 쿠키에서 토큰 읽고 검증 - `src/middleware.ts` - Next.js 미들웨어 (보호된 라우트 검사) - `/login` 제외한 모든 라우트에 인증 필요 - 토큰 만료 시 `/login`으로 리다이렉트 - `src/app/(auth)/login/page.tsx` - 로그인 페이지 - 직원코드 + 비밀번호 입력 폼 - 에러 메시지 표시 - `src/app/api/auth/login/route.ts` - 로그인 API - STAFF 테이블에서 코드+비밀번호 확인 - 성공 시 JWT 토큰을 httpOnly 쿠키에 저장 - 실패 시 401 응답 - `src/app/api/auth/logout/route.ts` - 로그아웃 API (쿠키 삭제) - 비밀번호: 기존 STAFF.PASSWORD가 평문일 가능성 → 로그인 시 평문 비교, 로그인 성공 시 bcrypt 해시로 자동 업그레이드 - 관리자 초기 계정: seed에서 생성 Must NOT do: - OAuth/소셜 로그인 구현 금지 - 복잡한 권한 시스템 (v1은 관리자/일반 2단계만) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [] Parallelization: - Can Run In Parallel: YES (T2와 병렬 가능, T1만 선행) - Parallel Group: Wave 1 (with T2, T4) - Blocks: T5-T18 - Blocked By: T1 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → STAFF 테이블: CODE(VARCHAR 120), NAME(VARCHAR 160), PASSWORD(VARCHAR 120), PERMISSION(CHAR 324), STATUS(INTEGER), PARTINDEX(INTEGER) - Next.js middleware docs: https://nextjs.org/docs/app/building-your-application/routing/middleware Acceptance Criteria: - [x] `/login` 페이지에서 admin/admin으로 로그인 성공 - [x] 로그인 후 대시보드 페이지 접속 가능 - [x] 비인증 상태에서 보호된 라우트 접근 시 `/login`으로 리다이렉트 - [x] 로그아웃 후 세션 만료 QA Scenarios (MANDATORY): ``` Scenario: 정상 로그인 Tool: Bash (curl) Preconditions: seed 데이터로 admin 계정 존재 Steps: 1. curl -X POST http://localhost:3000/api/auth/login -H "Content-Type: application/json" -d '{"code":"[USER]","password":"[PASS]"}' 2. HTTP 200 확인, 응답에 "success" 포함 3. Set-Cookie 헤더에 token 존재 확인 Expected Result: JWT 토큰 발급, 쿠키 설정 Evidence: .sisyphus/evidence/task-3-login-success.txt Scenario: 잘못된 비밀번호 Tool: Bash (curl) Preconditions: admin 계정 존재 Steps: 1. curl -X POST http://localhost:3000/api/auth/login -H "Content-Type: application/json" -d '{"code":"[USER]","password":"[WRONG_PASS]"}' 2. HTTP 401 확인 Expected Result: 인증 실패, 에러 메시지 반환 Evidence: .sisyphus/evidence/task-3-login-fail.txt Scenario: 보호된 라우트 접근 Tool: Bash (curl) Preconditions: 로그아웃 상태 Steps: 1. curl -v http://localhost:3000/dashboard → 302 redirect to /login 확인 Expected Result: 비인증 시 로그인 페이지로 리다이렉트 Evidence: .sisyphus/evidence/task-3-protected-route.txt ``` Commit: YES (groups with T4) - Message: `feat(auth): JWT authentication with STAFF-based login` - Files: src/lib/auth.ts, src/middleware.ts, src/app/(auth)/, src/app/api/auth/ - [x] 4. 공통 UI 컴포넌트 + 레이아웃 What to do: - 메인 레이아웃 (`src/app/(dashboard)/layout.tsx`): - 좌측 사이드바 네비게이션 (접기/펼치기 가능) - 상단 헤더 (로고, 사용자명, 로그아웃 버튼) - 메인 콘텐츠 영역 - 다크모드 토글 - 사이드바 메뉴 구조: ``` 📊 대시보드 📋 기준정보 ├─ 거래처 관리 ├─ 품목 관리 ├─ 창고 관리 ├─ 직원 관리 └─ 프로젝트 관리 🛒 구매 ├─ 구매요청 ├─ 발주 관리 └─ 입고 관리 🏭 영업 ├─ 견적 관리 ├─ 수주 관리 └─ 출고 관리 📦 재고 ├─ 현재고 조회 ├─ 창고이동 └─ 재고조정 ``` - 공통 컴포넌트: - `DataTable` - TanStack Table 기반 데이터 테이블 (정렬, 필터, 페이지네이션, 행 선택) - `SearchInput` - 디바운스 검색 입력 - `DateRangePicker` - 기간 검색 - `FormDialog` - 생성/수정 다이얼로그 (공통 폼 래퍼) - `DeleteConfirmDialog` - 삭제 확인 다이얼로그 - `StatusBadge` - 상태 표시 뱃지 - `PageHeader` - 페이지 제목 + 액션 버튼 - 대시보드 홈페이지 (`src/app/(dashboard)/page.tsx`) - 빈 뼈대 (T14에서 내용 채움) Must NOT do: - 비즈니스 로직 포함 금지 - 과도한 공통 컴포넌트 추상화 (필요한 것만) Recommended Agent Profile: - Category: `visual-engineering` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T2, T3과 병렬) - Parallel Group: Wave 1 - Blocks: T5-T18 - Blocked By: T1 References: - shadcn/ui sidebar: https://ui.shadcn.com/docs/components/sidebar - TanStack Table: https://tanstack.com/table/latest Acceptance Criteria: - [x] 로그인 후 사이드바 레이아웃 표시 - [x] 모든 메뉴 항목이 사이드바에 표시됨 - [x] 사이드바 접기/펼치기 동작 - [x] 다크모드 전환 동작 - [x] DataTable 컴포넌트 렌더링 (더미 데이터로) QA Scenarios (MANDATORY): ``` Scenario: 레이아웃 렌더링 Tool: Playwright Preconditions: 로그인 완료 상태 Steps: 1. http://localhost:3000 이동 2. 사이드바 요소 확인: text "대시보드" 존재 3. text "기준정보" 존재 4. text "구매" 존재 5. text "영업" 존재 6. text "재고" 존재 7. 헤더에 로그아웃 버튼 존재 Expected Result: 전체 레이아웃 렌더링 Evidence: .sisyphus/evidence/task-4-layout.png Scenario: 다크모드 전환 Tool: Playwright Preconditions: 로그인 완료 Steps: 1. 다크모드 토글 버튼 클릭 2. html 요소에 class="dark" 추가 확인 3. 배경색이 어두운 색으로 변경 확인 Expected Result: 다크/라이트 모드 전환 Evidence: .sisyphus/evidence/task-4-darkmode.png ``` Commit: YES (groups with T3) - Message: `feat(ui): shared layout, sidebar navigation, common components` - Files: src/app/(dashboard)/layout.tsx, src/components/shared/ - [x] 5. 기준정보 - 거래처 관리 What to do: - API Routes (`src/app/api/customers/`): - `GET /api/customers` - 목록 조회 (검색: name, code, businessNo, keyword / 필터: group1, group2, status / 페이지네이션 / 정렬) - `POST /api/customers` - 생성 (code 자동생성 옵션) - `GET /api/customers/[code]` - 상세 조회 (staff, items 포함) - `PUT /api/customers/[code]` - 수정 - `DELETE /api/customers/[code]` - 삭제 (참조 데이터 없을 때만) - `GET /api/customers/[code]/staffs` - 담당자 목록 - `POST/PUT/DELETE /api/customers/[code]/staffs` - 담당자 CRUD - `GET /api/customers/[code]/items` - 취급품목 목록 - `POST/PUT/DELETE /api/customers/[code]/items` - 취급품목 CRUD - 페이지 (`src/app/(dashboard)/master/customers/`): - `page.tsx` - 거래처 목록 (DataTable + 검색 + 필터) - `[code]/page.tsx` - 거래처 상세/수정 (탭: 기본정보, 담당자, 취급품목, 메모) - `new/page.tsx` - 신규 등록 - Zod 스키마로 입력 검증 (businessNo 형식, 이메일 형식 등) Must NOT do: - 참조 무결성 검사 없이 거래처 삭제 금지 (구매/영업에서 참조 중이면 삭제 차단) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T6, T7과 병렬) - Parallel Group: Wave 2 - Blocks: T8, T10, T14 - Blocked By: T2, T3, T4 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → CUSTOMER 테이블 (17개 컬럼), CUSTOMERSTAFF (12개), CUSTOMERITEM (13개) - CUSTOMER.CODE가 VARCHAR(120)으로 PK → Prisma에서 @id @default(autoincrement) 대신 @id (수동 또는 자동생성) Acceptance Criteria: - [x] 거래처 목록 페이지에서 검색/필터/정렬 동작 - [x] 신규 거래처 등록 후 목록에 표시 - [x] 거래처 상세에서 담당자/취급품목 탭 전환 동작 - [x] Zod 검증으로 잘못된 입력 차단 QA Scenarios (MANDATORY): ``` Scenario: 거래처 CRUD Tool: Playwright + Bash (curl) Preconditions: 로그인 상태 Steps: 1. curl POST /api/customers -d '{"code":"C001","name":"테스트거래처","compType":1,"phone":"02-1234-5678"}' → 201 2. curl GET /api/customers?search=테스트 → 응답에 "C001" 포함 3. curl PUT /api/customers/C001 -d '{"name":"수정된거래처"}' → 200 4. Playwright: /master/customers 페이지에서 "수정된거래처" 검색 → 결과 1건 5. curl DELETE /api/customers/C001 → 200 6. curl GET /api/customers?search=C001 → 빈 배열 Expected Result: 전체 CRUD 사이클 동작 Evidence: .sisyphus/evidence/task-5-customer-crud.txt Scenario: 잘못된 사업자등록번호 Tool: Bash (curl) Steps: 1. curl POST /api/customers -d '{"code":"C002","name":"테스트","businessNo":"invalid"}' → 400 Expected Result: Zod 검증 에러 Evidence: .sisyphus/evidence/task-5-validation.txt ``` Commit: YES - Message: `feat(master): customer management with CRUD, search, filter` - [x] 6. 기준정보 - 품목 관리 What to do: - API Routes (`src/app/api/items/`): - `GET /api/items` - 목록 (검색: name, code, barcode, keyword / 필터: category, type, status) - `POST /api/items` - 생성 - `GET /api/items/[code]` - 상세 (unitGroups, specialPrices, itemClasses 포함) - `PUT /api/items/[code]` - 수정 - `DELETE /api/items/[code]` - 삭제 - `GET/POST/PUT/DELETE /api/items/[code]/units` - 단위그룹 CRUD - `GET/POST/PUT/DELETE /api/items/[code]/prices` - 특별단가 CRUD - `GET/POST/PUT/DELETE /api/items/[code]/classes` - 소분류 CRUD - 페이지 (`src/app/(dashboard)/master/items/`): - `page.tsx` - 품목 목록 (카테고리 트리 + 목록) - `[code]/page.tsx` - 품목 상세/수정 (탭: 기본정보, 소분류, 단위, 특별단가, 이미지) - `new/page.tsx` - 신규 등록 - 품목 상태 관리 (사용/미사용) Must NOT do: - 이미지 업로드는 기본 구현만 (파일 시스템 저장) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T5, T7과 병렬) - Parallel Group: Wave 2 - Blocks: T8, T9, T10, T11, T12 - Blocked By: T2, T3, T4 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → ITEM 테이블 (25개 컬럼), ITEMCLASS (5개), UNITGROUP (4개), SPECIALPRICE (8개) - ITEM.TYPE: INTEGER → 품목 유형 (매입/매출/ both 등) - ITEM.CATEGORY: VARCHAR(120) → 대분류 코드 Acceptance Criteria: - [x] 품목 목록에서 검색/카테고리 필터 동작 - [x] 품목 등록/수정/삭제 동작 - [x] 단위그룹/특별단가 서브 폼 동작 QA Scenarios (MANDATORY): ``` Scenario: 품목 CRUD Tool: Bash (curl) Steps: 1. POST /api/items {"code":"I001","name":"테스트품목","unit":"EA","purchasePrice":1000,"price":2000} → 201 2. GET /api/items?search=테스트 → I001 포함 3. PUT /api/items/I001 {"name":"수정품목"} → 200 4. DELETE /api/items/I001 → 200 Expected Result: 전체 CRUD 동작 Evidence: .sisyphus/evidence/task-6-item-crud.txt Scenario: 품목 상세 서브탭 Tool: Playwright Steps: 1. 품목 등록 (API로) 2. /master/items/I001 접속 3. "소분류" 탭 클릭 → 빈 목록 표시 4. "단위" 탭 클릭 → 기본 단위 표시 5. "특별단가" 탭 클릭 → 빈 목록 표시 Expected Result: 탭 전환 동작, 서브 데이터 표시 Evidence: .sisyphus/evidence/task-6-item-detail.png ``` Commit: YES - Message: `feat(master): item management with units, special prices, subclasses` - [x] 7. 기준정보 - 창고/직원/프로젝트/공통코드 관리 What to do: - 창고 관리 (`src/app/(dashboard)/master/locations/`): - API: `GET/POST/PUT/DELETE /api/locations` - 페이지: 목록 + 등록/수정 다이얼로그 - Location 코드, 이름, 유형 (자재창고/제품창고/외주창고 등) - 직원 관리 (`src/app/(dashboard)/master/staffs/`): - API: `GET/POST/PUT/DELETE /api/staffs` - 페이지: 목록 + 등록/수정 다이얼로그 - 비밀번호 초기화 기능 - 프로젝트 관리 (`src/app/(dashboard)/master/projects/`): - API: `GET/POST/PUT/DELETE /api/projects` - 페이지: 목록 + 등록/수정 다이얼로그 - 프로젝트 상태 (진행중/완료/중단) - 공통 코드 관리 (`src/app/(dashboard)/master/codes/`): - 세율 관리 (TAXRATE) - 환율 관리 (EXCHANGERATE) - 코드 자동증가 설정 (CODESET) Must NOT do: - 복잡한 권한 편집 UI (v1은 기본만) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T5, T6과 병렬) - Parallel Group: Wave 2 - Blocks: T14 - Blocked By: T2, T3, T4 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → LOCATION (4개), STAFF (10개), PROJECT (8개), TAXRATE (3개), EXCHANGERATE (8개) Acceptance Criteria: - [x] 각 기준정보 CRUD 동작 - [x] 직원 비밀번호 초기화 동작 QA Scenarios (MANDATORY): ``` Scenario: 창고/직원/프로젝트 CRUD Tool: Bash (curl) Steps: 1. POST /api/locations {"code":"W001","name":"메인창고","locationType":1} → 201 2. POST /api/staffs {"code":"S001","name":"홍길동","partName":"영업부"} → 201 3. POST /api/projects {"code":"P001","name":"2024프로젝트","startDay":"2024-01-01","endDay":"2024-12-31"} → 201 4. GET /api/locations → W001 포함 5. GET /api/staffs → S001 포함 6. GET /api/projects → P001 포함 Expected Result: 모든 기준정보 CRUD 동작 Evidence: .sisyphus/evidence/task-7-master-data.txt ``` Commit: YES - Message: `feat(master): location, staff, project, tax/exchange rate management` - [x] 8. 구매 - 구매요청 관리 What to do: - API Routes (`src/app/api/purchase-requests/`): - `GET` - 목록 (검색: code, staffName, keyword / 필터: status, dateRange) - `POST` - 생성 (헤더 + 상세 동시 생성) - `GET /[code]` - 상세 (details 포함) - `PUT /[code]` - 수정 - `DELETE /[code]` - 삭제 (미확정 상태만) - `POST /[code]/confirm` - 구매요청 확정 (상태 변경) - 페이지 (`src/app/(dashboard)/purchase/requests/`): - `page.tsx` - 구매요청 목록 (상태별 탭: 전체/요청중/확정) - `[code]/page.tsx` - 상세/수정 (헤더 정보 + 품목 행 추가/삭제) - `new/page.tsx` - 신규 등록 - 품목 검색 다이얼로그 (Item에서 선택) - 거래처 선택 다이얼로그 - 비즈니스 로직: - 구매요청 코드 자동생성 (PR-YYYYMMDD-NNN 형식) - 상태 관리: 요청(0) → 확정(1) - 품목 행: itemCode, subclass, qty, unit, price, currency, remark Must NOT do: - 발주 변환 로직 (T9에서 구현) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T7, T9와 병렬 가능하나 T9는 T8 선행 권장) - Parallel Group: Wave 2 - Blocks: T9, T14, T15 - Blocked By: T2, T3, T4, T5, T6 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → PURCHASEREQUEST (11개 컬럼), PRDETAIL (12개 컬럼) - 구매요청→발주 흐름: SNS ERP 문서 6-8장 Acceptance Criteria: - [x] 구매요청 등록 (품목 행 추가) 동작 - [x] 구매요청 확정 상태 변경 동작 - [x] 확정된 구매요청은 수정/춈소 불가 QA Scenarios (MANDATORY): ``` Scenario: 구매요청 등록→확정 Tool: Bash (curl) + Playwright Steps: 1. POST /api/purchase-requests {"dday":"2024-06-01","staffName":"홍길동","details":[{"itemCode":"I001","qty":10,"unit":"EA","price":1000}]} 2. GET /api/purchase-requests → 생성된 건 확인 3. POST /api/purchase-requests/PR-20240601-001/confirm → 200 4. GET /api/purchase-requests/PR-20240601-001 → status=1 확인 5. PUT /api/purchase-requests/PR-20240601-001 → 400 (확정 후 수정 불가) Expected Result: 등록→확정 흐름 정상, 확정 후 수정 차단 Evidence: .sisyphus/evidence/task-8-purchase-request.txt ``` Commit: YES - Message: `feat(purchase): purchase request management with status workflow` - [x] 9. 구매 - 발주 + 입고 관리 What to do: - 발주 관리 (`src/app/api/purchase-orders/`): - CRUD API + `POST /[code]/confirm` 확정 - 구매요청에서 불러오기: `POST /api/purchase-orders/from-request` (선택된 구매요청의 품목을 발주로 복사) - 거래처별 발주: 특정 거래처의 구매요청 품목을 모아서 발주 - 발주서 상태: 작성(0) → 발행(1) → 마감(2) - 입고 관리 (`src/app/api/purchases/`): - CRUD API + `POST /[code]/confirm` 확정 - 발주에서 불러오기: `POST /api/purchases/from-order` (발주의 품목을 입고로 복사, 미입고 수량만) - 입고 상태: 작성(0) → 확정(1) → 마감(2) - 입고 확정 시 재고 자동 증가: PurchaseDetail의 itemCode + locationCode 조합으로 Stock 업데이트 - StockChange 이력 생성 - 페이지: - `src/app/(dashboard)/purchase/orders/` - 발주 목록/상세/신규 - `src/app/(dashboard)/purchase/receiving/` - 입고 목록/상세/신규 - 구매요청→발주 변환 다이얼로그 - 발주→입고 변환 다이얼로그 Must NOT do: - 바코드 입고 (v2) - BOM 기반 입고 (v2) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: NO (T8 선행, 재고 업데이트 로직 중요) - Parallel Group: Wave 2 (T8 후 시퀀셜) - Blocks: T14, T15 - Blocked By: T2, T3, T4, T6, T8 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → PURCHASEORDER (16개), PODETAIL (13개), PURCHASE (11개), PURCHASEDETAIL (12개) - STOCK 테이블: 입고 확정 시 qty 증가 로직 참고 - STOCKCHANGE: 재고 변경 이력 기록 패턴 Acceptance Criteria: - [x] 구매요청 → 발주 변환 동작 - [x] 발주 → 입고 변환 동작 - [x] 입고 확정 시 해당 창고의 재고 자동 증가 - [x] 재고 변경 이력(STOCKCHANGE) 자동 생성 QA Scenarios (MANDATORY): ``` Scenario: 발주→입고→재고증가 Tool: Bash (curl) Preconditions: 품목 I001, 창고 W001 존재 Steps: 1. POST /api/purchase-orders/from-order → 발주 생성 (I001, qty=10) 2. POST /api/purchases/from-order → 입고 생성 (발주에서 불러오기, qty=10, locationCode=W001) 3. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=0 (입고 전) 4. POST /api/purchases/{code}/confirm → 입고 확정 5. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=10 (입고 후) 6. GET /api/inventory/changes?itemCode=I001 → 변경 이력 1건 존재 Expected Result: 입고 확정 후 재고 10 증가, 이력 기록 Evidence: .sisyphus/evidence/task-9-receiving-stock.txt Scenario: 부분 입고 Tool: Bash (curl) Steps: 1. 발주 qty=20으로 생성 2. 입고 1: qty=10으로 입고 확정 → 재고 10 3. 입고 2: qty=10으로 추가 입고 확정 → 재고 20 Expected Result: 부분 입고 누적 정상 Evidence: .sisyphus/evidence/task-9-partial-receiving.txt ``` Commit: YES - Message: `feat(purchase): purchase order and receiving with auto stock update` - [x] 10. 영업 - 견적서 관리 What to do: - API Routes (`src/app/api/quotations/`): - CRUD API (헤더 + 상세 동시) - `GET` - 목록 (검색: code, customerName / 필터: type(받은견적/보낸견적), dateRange, status) - `POST` - 생성 (type: 0=받은견적, 1=보낸견적) - `POST /[code]/confirm` - 견적 확정 - `POST /[code]/to-order` - 견적을 수주로 변환 - 페이지 (`src/app/(dashboard)/sales/quotations/`): - `page.tsx` - 견적 목록 (탭: 받은견적/보낸견적) - `[code]/page.tsx` - 견적 상세/수정 - `new/page.tsx` - 신규 견적 (타입 선택: 받은/보낸) - 거래처 선택, 품목 행 추가/삭제 - 견적 금액 자동 계산 (단가 × 수량 + 세액) - 견적 코드: QT-YYYYMMDD-NNN Must NOT do: - 견적서 인쇄 (T16에서 구현) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T12, T13과 병렬) - Parallel Group: Wave 3 - Blocks: T11, T14, T15 - Blocked By: T2, T3, T4, T5, T6 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → QUOTATION (13개), QUOTATIONDETAIL (11개) - QUOTATION.TYPE: INTEGER → 0=받은견적, 1=보낸견적 Acceptance Criteria: - [x] 받은견적/보낸견적 탭 분리 동작 - [x] 견적 등록 (품목 행 포함) 동작 - [x] 견적 금액 자동 계산 QA Scenarios (MANDATORY): ``` Scenario: 견적 CRUD + 금액계산 Tool: Bash (curl) Steps: 1. POST /api/quotations {"type":1,"dday":"2024-06-01","customerCode":"C001","details":[{"itemCode":"I001","qty":5,"price":10000,"tax":1000}]} 2. GET /api/quotations?type=1 → 생성된 건 확인 3. 상세에서 총금액 = (10000+1000)5 = 55000 확인 4. DELETE → 성공 Expected Result: 견적 CRUD + 자동 금액 계산 Evidence: .sisyphus/evidence/task-10-quotation.txt ``` Commit: YES - Message: `feat(sales): quotation management (received/sent)` - [x] 11. 영업 - 수주 + 출고 관리 What to do: - 수주 관리* (`src/app/api/sales-orders/`): - CRUD API + 확정 - 견적에서 불러오기: `POST /api/sales-orders/from-quotation` - 수주 상태: 작성(0) → 확정(1) → 출고완료(2) - 수주 코드: SO-YYYYMMDD-NNN - 출고 관리 (`src/app/api/sales/`): - CRUD API + 확정 - 수주에서 불러오기: `POST /api/sales/from-order` (미출고 수량만) - 출고 상태: 작성(0) → 확정(1) → 마감(2) - 출고 확정 시 재고 자동 감소: SaleDetail의 itemCode + locationCode로 Stock.qty 감소 - 재고 부족 시 경고 (0 미만 불가) - StockChange 이력 생성 (음수 변경) - 페이지: - `src/app/(dashboard)/sales/orders/` - 수주 목록/상세/신규 - `src/app/(dashboard)/sales/shipping/` - 출고 목록/상세/신규 - 견적→수주 변환, 수주→출고 변환 다이얼로그 - 출고 시 창고 선택 + 재고 확인 표시 Must NOT do: - 바코드 출고 (v2) - 출고대기 기능 (v2) - 특별단가 자동적용 (수동 선택) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: NO (T10 선행, 재고 감소 로직 중요) - Parallel Group: Wave 3 - Blocks: T12, T14, T15 - Blocked By: T2, T3, T4, T6, T10 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → SALESORDER (14개), SODETAIL (13개), SALES (14개), SALESDETAIL (14개) - SALEDETAIL.COST: 원가 필드 (매출이익 계산용) Acceptance Criteria: - [x] 견적 → 수주 변환 동작 - [x] 수주 → 출고 변환 동작 - [x] 출고 확정 시 재고 자동 감소 - [x] 재고 부족 시 출고 불가 QA Scenarios (MANDATORY): ``` Scenario: 수주→출고→재고감소 Tool: Bash (curl) Preconditions: 품목 I001, 창고 W001, 재고 10개 Steps: 1. POST /api/sales-orders/from-quotation → 수주 생성 (I001, qty=5) 2. POST /api/sales/from-order → 출고 생성 (수주에서 불러오기, qty=5, locationCode=W001) 3. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=10 (출고 전) 4. POST /api/sales/{code}/confirm → 출고 확정 5. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=5 (출고 후) Expected Result: 출고 확정 후 재고 5 감소 Evidence: .sisyphus/evidence/task-11-shipping-stock.txt Scenario: 재고 부족 출고 Tool: Bash (curl) Preconditions: 품목 I001, 재고 3개 Steps: 1. POST /api/sales (qty=5) → 출고 등록 2. POST /api/sales/{code}/confirm → 400 "재고 부족" Expected Result: 재고 부족 에러로 출고 확정 차단 Evidence: .sisyphus/evidence/task-11-stock-insufficient.txt ``` Commit: YES - Message: `feat(sales): sales order and shipping with auto stock decrease` - [x] 12. 재고 - 현재고 + 재고조정 What to do: - 현재고 조회 (`src/app/api/inventory/stock/`): - `GET /api/inventory/stock` - 목록 (검색: itemCode, itemName / 필터: locationCode, projectCode) - `GET /api/inventory/stock/[id]` - 상세 (변경 이력 포함) - 집계: 품목별 전체 재고, 창고별 재고 - 재고조정 (`src/app/api/inventory/adjustments/`): - `POST /api/inventory/adjustments` - 재고조정 등록 - 실사 수량 입력 → 기존 수량과 비교 → 차이만큼 Stock 업데이트 - StockChange 이력 생성 (changeCode: 'ADJUST') - 변경 사유 필수 입력 - 페이지 (`src/app/(dashboard)/inventory/`): - `stock/page.tsx` - 현재고 목록 (품목별/창고별 피벗 뷰) - `stock/[id]/page.tsx` - 재고 상세 + 변경 이력 타임라인 - `adjustments/page.tsx` - 재고조정 등록/이력 - `adjustments/new/page.tsx` - 실사 입력 (품목별 현재고→조정수량 입력) Must NOT do: - 재고 예측/안전재고 알림 (v2) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T10, T13과 병렬 가능하나 T11 후 권장) - Parallel Group: Wave 3 - Blocks: T13, T14, T15 - Blocked By: T2, T3, T4, T6, T11 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → STOCK (8개), STOCKCHANGE (9개), STCGLOG (11개) - STOCK 복합 unique: locationCode + itemCode + subclass + projectCode Acceptance Criteria: - [x] 현재고 목록 품목별/창고별 조회 동작 - [x] 재고조정 등록 후 수량 반영 - [x] 변경 이력 타임라인 표시 QA Scenarios (MANDATORY): ``` Scenario: 재고조정 Tool: Bash (curl) Preconditions: 품목 I001, 창고 W001, 현재고 10 Steps: 1. POST /api/inventory/adjustments {"stockId":1,"newQty":15,"reason":"실사 조정"} → 201 2. GET /api/inventory/stock?itemCode=I001&locationCode=W001 → qty=15 3. GET /api/inventory/changes?stockId=1 → 변경 이력에 oldQty=10, newQty=15 존재 Expected Result: 재고 10→15 조정, 이력 기록 Evidence: .sisyphus/evidence/task-12-stock-adjust.txt ``` Commit: YES - Message: `feat(inventory): stock inquiry, adjustment with change history` - [x] 13. 재고 - 창고이동 + 이력 관리 What to do: - 창고이동 (`src/app/api/inventory/transfers/`): - `GET` - 이동 목록 (검색: code, date / 필터: status) - `POST` - 이동 등록 (출발창고 + 도착창고 + 품목 행) - `POST /[code]/confirm` - 이동 확정 - 확정 시: 출발창고 재고 감소 + 도착창고 재고 증가 (트랜잭션) - StockChange 이력 2건 생성 (출/입) - 페이지 (`src/app/(dashboard)/inventory/transfers/`): - `page.tsx` - 이동 목록 - `[code]/page.tsx` - 이동 상세/수정 - `new/page.tsx` - 신규 이동 (출발/도착 창고 선택, 품목 행 추가) - 전체 재고 이력 (`src/app/api/inventory/changes/`): - `GET` - 재고 변경 이력 (전체/품목별/창고별) - 이력 타입: 입고, 출고, 이동(출), 이동(입), 조정 Must NOT do: - 이동 중 "이동중" 상태 재고 개념 (v1은 즉시 반영) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T10, T11, T12와 병렬 가능하나 T12 후 권장) - Parallel Group: Wave 3 - Blocks: T14, T15 - Blocked By: T2, T3, T4, T12 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` → LOCATETRAN (14개), LOCATETRANDETAIL (14개) Acceptance Criteria: - [x] 창고이동 등록 후 확정 시 양쪽 재고 변경 - [x] 트랜잭션 안전성 (한쪽 실패 시 롤백) - [x] 재고 이력 타입별 조회 QA Scenarios (MANDATORY): ``` Scenario: 창고이동 Tool: Bash (curl) Preconditions: I001, W001=10개, W002=0개 Steps: 1. POST /api/inventory/transfers {"locationOutCode":"W001","locationInCode":"W002","details":[{"itemCode":"I001","qty":3}]} 2. POST /api/inventory/transfers/{code}/confirm 3. GET /api/inventory/stock?locationCode=W001 → qty=7 4. GET /api/inventory/stock?locationCode=W002 → qty=3 Expected Result: W001: 10→7, W002: 0→3 Evidence: .sisyphus/evidence/task-13-transfer.txt Scenario: 출발창고 재고 부족 Tool: Bash (curl) Preconditions: W001 재고 2개 Steps: 1. POST /api/inventory/transfers (qty=5) 2. POST /api/inventory/transfers/{code}/confirm → 400 "재고 부족" Expected Result: 재고 부족으로 이동 실패 Evidence: .sisyphus/evidence/task-13-transfer-insufficient.txt ``` Commit: YES - Message: `feat(inventory): warehouse transfer with transactional stock update` - [x] 14. 대시보드 + 통계 What to do: ```mermaid graph TB CARDS["📊 카드 위젯<br/>금월매출 \| 금월매입 \| 총품목 \| 총거래처"] CHARTS["📈 차트 영역<br/>월별매출추이 \| 출고TOP10 \| 재고분포"] TABLES["📋 테이블<br/>최근거래 10건 \| 미출고 수주"] S["GET /dashboard/summary"] M["GET /dashboard/monthly-sales"] T["GET /dashboard/top-items"] D["GET /dashboard/stock-distribution"] R["GET /dashboard/recent-transactions"] P["GET /dashboard/pending-shipments"] RP1["/reports/sales<br/>기간별 집계"] RP2["/reports/inventory<br/>품목별/창고별"] CARDS --> S CHARTS --> M CHARTS --> T CHARTS --> D TABLES --> R TABLES --> P style CARDS fill:#3b82f6,color:#fff style CHARTS fill:#10b981,color:#fff style TABLES fill:#8b5cf6,color:#fff ``` - 메인 대시보드 (`src/app/(dashboard)/page.tsx`): - 상단 카드: 금월 매출액, 금월 매입액, 총 품목수, 총 거래처수 - 차트: 월별 매출/매입 추이 (Recharts line chart, 최근 12개월) - 차트: 품목별 출고량 TOP 10 (bar chart) - 차트: 창고별 재고 분포 (pie chart) - 최근 거래 내역 테이블 (최근 10건) - 미출고 수주 목록 (status=1인 수주 중 미출고 건) - API Routes (`src/app/api/dashboard/`): - `GET /api/dashboard/summary` - 카드 데이터 - `GET /api/dashboard/monthly-sales` - 월별 매출/매입 - `GET /api/dashboard/top-items` - 품목별 출고 TOP - `GET /api/dashboard/stock-distribution` - 창고별 재고 - `GET /api/dashboard/recent-transactions` - 최근 거래 - `GET /api/dashboard/pending-shipments` - 미출고 목록 - 조회/통계 페이지: - `src/app/(dashboard)/reports/sales/page.tsx` - 거래요약 (기간별 매출/매입 집계) - `src/app/(dashboard)/reports/inventory/page.tsx` - 재고 현황 (품목별/창고별) Must NOT do: - 실시간 갱신 (v1은 새로고침) - 엑셀 다운로드 (T17) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T15, T16과 병렬) - Parallel Group: Wave 4 - Blocks: T17, T18 - Blocked By: T5-T13 References: - Recharts: https://recharts.org/ - TanStack Query for data fetching Acceptance Criteria: - [x] 대시보드 카드 데이터 표시 - [x] 차트 3종 렌더링 - [x] 기간별 통계 페이지 동작 QA Scenarios (MANDATORY): ``` Scenario: 대시보드 렌더링 Tool: Playwright Preconditions: 거래 데이터 존재 (입고/출고 이력) Steps: 1. http://localhost:3000 이동 2. 카드 4개 표시 확인 (text "매출", "매입", "품목", "거래처") 3. 차트 영역 3개 렌더링 확인 (svg 요소 존재) 4. 최근 거래 테이블 표시 확인 Expected Result: 대시보드 전체 렌더링 Evidence: .sisyphus/evidence/task-14-dashboard.png Scenario: API 데이터 확인 Tool: Bash (curl) Steps: 1. curl GET /api/dashboard/summary → 200, {sales: N, purchase: N, items: N, customers: N} 2. curl GET /api/dashboard/monthly-sales → 200, 배열 응답 Expected Result: JSON 응답 정상 Evidence: .sisyphus/evidence/task-14-dashboard-api.txt ``` Commit: YES - Message: `feat(dashboard): main dashboard with charts and statistics` - [x] 15. Firebird → PostgreSQL 데이터 마이그레이션 What to do: ```mermaid flowchart TB FB["🔥 Firebird v3<br/>SNSERP.FDB<br/>85개 테이블"] READ["node-firebird<br/>데이터 읽기 (1000행 배치)"] TRANS["데이터 변환"] WRITE["Prisma Client<br/>SQLite 쓰기"] T1["PascalCase → camelCase"] T2["BIGINT→BigInt, DATE→DateTime"] T3["BLOB → String, 빈문자열→null"] T4["비밀번호 평문→bcrypt"] PG["🗄️ SQLite<br/>~30개 모델<br/>Prisma 관리"] FB --> READ --> TRANS --> WRITE --> PG T1 --> TRANS T2 --> TRANS T3 --> TRANS T4 --> TRANS style FB fill:#ef4444,color:#fff style TRANS fill:#3b82f6,color:#fff style PG fill:#10b981,color:#fff ``` - 마이그레이션 스크립트 (`scripts/migrate-firebird.ts`): 1. Firebird 연결: `node-firebird` 라이브러리로 SNSERP.FDB 연결 2. 각 테이블 순차 읽기 (1000행 배치): - 기준정보: CUSTOMER, CUSTOMERSTAFF, CUSTOMERITEM, ITEM, ITEMCLASS, UNITGROUP, SPECIALPRICE, LOCATION, LOCATIONSTAFF, STAFF, DEPARTMENT, PROJECT, TAXRATE, EXCHANGERATE, CODESET, CM_AUTOINCINDEX - 구매: PURCHASEREQUEST, PRDETAIL, PURCHASEORDER, PODETAIL, PURCHASE, PURCHASEDETAIL - 영업: QUOTATION, QUOTATIONDETAIL, SALESORDER, SODETAIL, SALES, SALESDETAIL, PACKINGLIST, PKGSDETAIL, PKGSITEMS - 재고: STOCK, STOCKCHANGE, STCGLOG, LOCATETRAN, LOCATETRANDETAIL, WAREHOUSE 3. 데이터 변환: - 컬럼명: PascalCase → camelCase (ITEMCODE → itemCode) - 타입: BIGINT → BigInt, DATE → DateTime, BLOB → String (Text) - NULL 처리: 빈 문자열 '' → null - STAFF.PASSWORD: 평문 → bcrypt 해시 변환 4. Prisma로 PostgreSQL에 upsert (중복 방지) 5. 진행률 표시 (콘솔 로그) 6. 마이그레이션 결과 리포트 (각 테이블별 이관 건수) - 설정: - `.env`에 FIREBIRD_DB_PATH 설정 - Firebird 서비스 실행 중 필요 - 검증 스크립트 (`scripts/verify-migration.ts`): - 각 테이블별 소스(Firebird) vs 타겟(PostgreSQL) 행 수 비교 - 샘플 데이터 값 비교 (랜덤 10행) - 결과 리포트 출력 Must NOT do: - v2 테이블(생산, 회계 등)은 마이그레이션하지 않음 (스키마만 준비) - 원본 Firebird DB 수정 금지 Recommended Agent Profile: - Category: `deep` - Skills: [] Parallelization: - Can Run In Parallel: YES (T14, T16과 병렬) - Parallel Group: Wave 4 - Blocks: T18 - Blocked By: T2 References: Pattern References: - `[PROJECT_PATH]\_schema_columns.txt` - 전체 스키마 (모든 테이블의 컬럼명, 타입 정보) - `[PROJECT_PATH]\SNSERP.FDB` - 원본 Firebird DB 파일 - node-firebird: https://github.com/hgourvest/node-firebird External References: - node-firebird API: `Firebird.attach(options, callback)`, `db.query(sql, params, callback)` - Prisma upsert: `prisma.model.upsert({ where, update, create })` Acceptance Criteria: - [x] 마이그레이션 스크립트 실행 완료 (에러 없이) - [x] 각 테이블 행 수 일치 (Firebird = PostgreSQL) - [x] 샘플 데이터 값 일치 확인 - [x] STAFF 비밀번호 해시 변환 완료 QA Scenarios (MANDATORY): ``` Scenario: 전체 마이그레이션 실행 Tool: Bash Preconditions: Firebird 서비스 실행 중, PostgreSQL 실행 중 Steps: 1. npx tsx scripts/migrate-firebird.ts 2. 콘솔에 각 테이블별 이관 건수 출력 확인 3. npx tsx scripts/verify-migration.ts 4. "모든 테이블 행 수 일치" 확인 Expected Result: 전체 데이터 이관 성공 Evidence: .sisyphus/evidence/task-15-migration.txt Scenario: 마이그레이션 후 로그인 Tool: Bash (curl) Preconditions: 마이그레이션 완료 Steps: 1. 기존 STAFF 계정으로 로그인 시도 2. POST /api/auth/login with 기존 credentials 3. HTTP 200 확인 Expected Result: 기존 계정으로 로그인 성공 Evidence: .sisyphus/evidence/task-15-login-after-migration.txt ``` Commit: YES - Message: `feat(migration): Firebird to PostgreSQL data migration script` - [x] 16. PDF 인쇄 시스템 What to do: ```mermaid flowchart TB BTN["📄 PDF 인쇄 버튼"] GET["GET /api/print/:type/:code"] FETCH["DB에서 데이터 조회"] GEN["PDF 생성 엔진"] QT_PDF["견적서<br/>거래처정보 + 품목표 + 합계"] PO_PDF["발주서<br/>거래처정보 + 품목표 + 납기일"] SH_PDF["출고전표<br/>거래처정보 + 품목표 + 출고창고"] PREVIEW["미리보기 모달"] DOWNLOAD["다운로드 / 새 탭"] BTN --> GET GET --> FETCH FETCH --> GEN GEN --> QT_PDF GEN --> PO_PDF GEN --> SH_PDF QT_PDF --> PREVIEW PO_PDF --> PREVIEW SH_PDF --> PREVIEW PREVIEW --> DOWNLOAD style Trigger fill:#3b82f6,color:#fff style API fill:#10b981,color:#fff style Templates fill:#f59e0b,color:#fff style Output fill:#8b5cf6,color:#fff ``` - PDF 생성 유틸리티 (`src/lib/pdf.ts`): - `@react-pdf/renderer` 또는 `jsPDF` + `jspdf-autotable` 사용 - 공통 헤더/푸터 템플릿 (회사명, 로고, 문서번호, 발행일) - 인쇄 API Routes: - `GET /api/print/quotation/[code]` - 견적서 PDF - `GET /api/print/purchase-order/[code]` - 발주서 PDF - `GET /api/print/sales-order/[code]` - 수주서 PDF - `GET /api/print/shipping/[code]` - 출고전표/패킹리스트 PDF - PDF 양식 내용: - 견적서: 견적번호, 날짜, 거래처정보, 품목표(품명/수량/단가/금액), 합계, 비고 - 발주서: 발주번호, 날짜, 거래처정보, 품목표, 납기일, 합계 - 출고전표: 출고번호, 날짜, 거래처정보, 품목표, 출고창고, 합계 - 프론트엔드 인쇄 버튼: - 각 상세 페이지에 "PDF 인쇄" 버튼 추가 - 클릭 시 PDF 새 탭에서 열기 또는 다운로드 - 인쇄 미리보기: - 모달에서 PDF 미리보기 후 인쇄/다운로드 선택 Must NOT do: - 인쇄 양식 편집 기능 (v2) - 인쇄 기록 관리 (v2) Recommended Agent Profile: - Category: `unspecified-high` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T14, T15와 병렬) - Parallel Group: Wave 4 - Blocks: T18 - Blocked By: T4, T8, T10, T11 References: - @react-pdf/renderer: https://react-pdf.org/ - 또는 jsPDF: https://github.com/parallax/jsPDF Acceptance Criteria: - [x] 견적서 PDF 생성/다운로드 동작 - [x] 발주서 PDF 생성/다운로드 동작 - [x] 출고전표 PDF 생성/다운로드 동작 - [x] PDF에 한글 폰트 정상 표시 QA Scenarios (MANDATORY): ``` Scenario: 견적서 PDF 생성 Tool: Bash (curl) Preconditions: 견적 데이터 존재 Steps: 1. curl GET /api/print/quotation/QT-20240601-001 -o test.pdf 2. 파일 크기 > 0 확인 3. file test.pdf → "PDF document" 확인 Expected Result: PDF 파일 정상 생성 Evidence: .sisyphus/evidence/task-16-quotation-pdf.txt Scenario: 발주서 PDF 한글 Tool: Playwright Preconditions: 발주 데이터 존재 Steps: 1. 발주 상세 페이지에서 "PDF 인쇄" 버튼 클릭 2. PDF 미리보기 모달 열림 확인 3. PDF 내용에 한글 텍스트 포함 확인 Expected Result: 한글이 깨지지 않고 정상 표시 Evidence: .sisyphus/evidence/task-16-pdf-korean.png ``` Commit: YES - Message: `feat(print): PDF generation for quotation, PO, shipping documents` - [x] 17. Excel 내보내기 + 일괄 입력 What to do: - Excel 내보내기 (`src/lib/excel.ts`): - `xlsx` (SheetJS) 라이브러리 사용 - 모든 목록 페이지에 "Excel 다운로드" 버튼 추가 - 현재 필터/검색 조건 기준으로 데이터 내보내기 - 컬럼 헤더 한국어 매핑 (itemCode → "품목코드") - Excel 일괄 입력: - 거래처 일괄 입력: `/api/customers/import` (Excel 파일 업로드 → 파싱 → 일괄 insert) - 품목 일괄 입력: `/api/items/import` - 업로드 UI: 드래그앤드롭 영역 + 미리보기 테이블 - 에러 처리: 잘못된 행은 에러 메시지와 함께 스킵, 성공/실패 건수 표시 - 엑셀 템플릿 다운로드: - `/api/templates/customers` - 거래처 입력 양식 다운로드 - `/api/templates/items` - 품목 입력 양식 다운로드 Must NOT do: - 복잡한 매핑 규칙 (v1은 단순 1:1 매핑) Recommended Agent Profile: - Category: `quick` - Skills: [`/frontend-ui-ux`] Parallelization: - Can Run In Parallel: YES (T16과 병렬 가능) - Parallel Group: Wave 5 - Blocks: T18 - Blocked By: T14 References: - SheetJS: https://docs.sheetjs.com/ - 기존 거래처.xlsx, 품목-원본.xlsx 파일 참고 ([PROJECT_PATH]\) Acceptance Criteria: - [x] 거래처 목록 Excel 다운로드 동작 - [x] 품목 목록 Excel 다운로드 동작 - [x] Excel 일괄 입력 후 데이터 저장 확인 - [x] 입력 에러 시 실패 건수 표시 QA Scenarios (MANDATORY): ``` Scenario: Excel 내보내기 Tool: Bash (curl) Steps: 1. curl GET /api/customers/export -o customers.xlsx 2. file customers.xlsx → "Microsoft Excel" 확인 3. 파일 크기 > 0 Expected Result: Excel 파일 정상 생성 Evidence: .sisyphus/evidence/task-17-export.txt Scenario: Excel 일괄 입력 Tool: Bash (curl) Steps: 1. curl POST /api/items/import -F "file=@template.xlsx" 2. 응답에 {success: N, failed: N} 포함 확인 Expected Result: 일괄 입력 처리 결과 반환 Evidence: .sisyphus/evidence/task-17-import.txt ``` Commit: YES - Message: `feat(export): Excel export and bulk import for customers, items` - [x] 18. 통합 테스트 + 버그 수정 What to do: - End-to-End 시나리오 테스트 (Vitest + Playwright): - 구매 사이클: 구매요청 → 발주 → 입고 → 재고증가 확인 - 영업 사이클: 견적 → 수주 → 출고 → 재고감소 확인 - 재고 조정: 입고+출고 후 재고조정 → 이력 확인 - 창고이동: 이동 후 양쪽 재고 변화 확인 - API 통합 테스트 (Vitest): - 각 API 엔드포인트 CRUD 테스트 - 에러 케이스 테스트 (권한, 유효성, 참조 무결성) - 동시성 테스트 (같은 재고 동시 업데이트) - UI 버그 수정: - 반응형 레이아웃 깨짐 수정 - 한글 입력/표시 이슈 수정 - 폼 유효성 에러 메시지 한국어화 - 로딩 상태 표시 (skeleton) - 성능 최적화: - 대량 데이터 목록 가상 스크롤 (필요시) - API 응답 캐싱 (필요시) - 빌드 테스트: - `npm run build` 성공 확인 - 프로덕션 모드 동작 확인 Must NOT do: - 새 기능 추가 금지 (버그 수정만) Recommended Agent Profile: - Category: `deep` - Skills: [`/playwright`] Parallelization: - Can Run In Parallel: NO (최종) - Parallel Group: Wave 5 (시퀀셜) - Blocks: FINAL - Blocked By: T14-T17 References: - Vitest: https://vitest.dev/ - Playwright: https://playwright.dev/ Acceptance Criteria: - [x] `npm run build` → 에러 없이 빌드 성공 - [x] 핵심 E2E 시나리오 4개 통과 - [x] API 테스트 20+ 케이스 통과 - [x] 반응형 레이아웃 정상 (태블릿 크기) QA Scenarios (MANDATORY): ``` Scenario: 전체 구매→영업 사이클 Tool: Playwright Steps: 1. 로그인 2. 품목 등록 (I-TEST, 테스트품목) 3. 거래처 등록 (C-TEST, 테스트거래처) 4. 구매요청 등록 (I-TEST, qty=100) 5. 구매요청 → 발주 변환 6. 발주 → 입고 변환 (W001) 7. 입고 확정 → 재고 100 확인 8. 견적서 등록 (I-TEST, qty=30) 9. 견적 → 수주 변환 10. 수주 → 출고 변환 (W001) 11. 출고 확정 → 재고 70 확인 12. 창고이동 (W001→W002, qty=20) → W001=50, W002=20 확인 13. 재고조정 (W001, 50→45) → 재고 45 확인 14. 대시보드 접속 → 매출/매입 수치 반영 확인 Expected Result: 전체 사이클 정상 동작, 재고 정확 Evidence: .sisyphus/evidence/task-18-full-cycle.txt Scenario: 프로덕션 빌드 Tool: Bash Steps: 1. npm run build → exit code 0 2. npm start → 서버 시작 3. curl http://localhost:3000 → 200 Expected Result: 프로덕션 빌드 정상 동작 Evidence: .sisyphus/evidence/task-18-build.txt ``` Commit: YES - Message: `chore: integration tests, bug fixes, production build verification` --- ## Final Verification Wave (MANDATORY — after ALL implementation tasks) > 4 review agents run in PARALLEL. ALL must APPROVE. Present consolidated results to user and get explicit "okay" before completing. - [x] F1. Plan Compliance Audit — `oracle` Read the plan end-to-end. For each "Must Have": verify implementation exists (read file, curl endpoint, run command). For each "Must NOT Have": search codebase for forbidden patterns — reject with file:line if found. Check evidence files exist in .sisyphus/evidence/. Compare deliverables against plan. Output: `Must Have [N/N] \| Must NOT Have [N/N] \| Tasks [N/N] \| VERDICT: APPROVE/REJECT` - [x] F2. Code Quality Review — `unspecified-high` Run `tsc --noEmit` + linter + `npm test`. Review all changed files for: `as any`/`@ts-ignore`, empty catches, console.log in prod, commented-out code, unused imports. Check AI slop: excessive comments, over-abstraction, generic names. Output: `Build [PASS/FAIL] \| Lint [PASS/FAIL] \| Tests [N pass/N fail] \| Files [N clean/N issues] \| VERDICT` - [x] F3. Real Manual QA — `unspecified-high` (+ `playwright` skill) Start from clean state. Execute EVERY QA scenario from EVERY task — follow exact steps, capture evidence. Test cross-module integration (purchase receiving → stock update → sales shipping → stock decrease). Test edge cases: empty state, invalid input, rapid actions. Save to `.sisyphus/evidence/final-qa/`. Output: `Scenarios [N/N pass] \| Integration [N/N] \| Edge Cases [N tested] \| VERDICT` - [x] F4. Scope Fidelity Check — `deep` For each task: read "What to do", read actual diff (git log/diff). Verify 1:1 — everything in spec was built (no missing), nothing beyond spec was built (no creep). Check "Must NOT do" compliance. Detect cross-task contamination. Output: `Tasks [N/N compliant] \| Contamination [CLEAN/N issues] \| Unaccounted [CLEAN/N files] \| VERDICT` --- ## Commit Strategy - Wave 1: `feat(init): Next.js project scaffolding with Prisma, auth, UI` - 여러 파일 - Wave 2: `feat(master): 거래처/품목/창고/직원 CRUD` - 여러 파일 - Wave 3: `feat(purchase): 구매요청/발주/입고 관리` - 여러 파일 - Wave 4: `feat(sales): 견적/수주/출고 관리` - 여러 파일 - Wave 5: `feat(inventory): 재고/창고이동 관리` - 여러 파일 - Wave 6: `feat(dashboard): 대시보드 + 통계` - 여러 파일 - Wave 7: `feat(migration): Firebird to PostgreSQL data migration` - 여러 파일 - Wave 8: `feat(print): PDF 인쇄 시스템` - 여러 파일 - Wave 9: `feat(export): Excel 내보내기` - 여러 파일 - Final: `chore: 통합 테스트 및 버그 수정` - 여러 파일 --- ## Success Criteria ### Verification Commands ```bash npm run dev # Expected: 서버 시작 at localhost:3000 npx prisma migrate status # Expected: 모든 마이그레이션 적용됨 npx prisma studio # Expected: 데이터 브라우저 실행 npm run build # Expected: 빌드 성공 (0 errors) npm test # Expected: 핵심 테스트 통과 ``` ### Final Checklist - [x] All "Must Have" present - [x] All "Must NOT Have" absent - [x] All tests pass - [x] Firebird 데이터가 PostgreSQL에 정상 이관됨 - [x] 로그인 → CRUD → 인쇄 전체 흐름 동작 - [x] 반응형 UI (데스크톱/태블릿) --- ## Post-v1 Enhancements (2026-05) ### Completed Enhancements - [x] 수주→출고 연결 기능 — Sale.salesOrderCode 필드 추가, 출고 확정 시 수주 상태 자동 변경(1→2), 수주 상세에 "출고 생성" 버튼, 출고 신규에서 수주 데이터 자동 로드 - [x] 출고/입고 확정 건 삭제 (재고 복원) — `?restoreStock=true` DELETE 시 Stock.qty 복원 + StockChange 이력 기록, UI에 "삭제 (재고복원)" 버튼, 수주 상태도 복원(2→1) - [x] W001 → '0' 창고 코드 통일 — 모든 하드코딩 W001 기본값을 '0'으로 변경 (9개 파일), DB PURCHASE.locationCode W001→0 업데이트 - [x] 현재고 조회 창고 직접 변경 — Stock 페이지 창고 컬럼 클릭 시 드롭다운으로 창고 변경, PATCH /api/inventory/stock/[id] (창고이동 로직 + StockChange 이력), 사이드바 "창고이동" 메뉴 제거 - [x] 재고현황 대분류별 그래프 — /api/dashboard/stock-by-category API, Pie 차트 + Bar 차트 + 상세 테이블, 카테고리 카드 추가 - [x] React key 중복 에러 수정 — Stock 페이지 컬럼에 고유 id 부여 (category, itemName, unit) - [x] 미출고 수주 삭제 기능 — 수주 상세(status=1)에 삭제 버튼 추가, 대시보드 미출고 수주 클릭 가능한 링크로 변경 - [x] 출고 삭제 트랜잭션 보장 — $transaction으로 SaleDetail + PackingDetail + Sale 명시적 삭제 ### v1.1 — 생산 관리 (Production Management) - [x] 19. 시리얼번호 관리 (Serial Number Management) What to do: - 시리얼번호 전용 관리 페이지 (사이드바 "생산" 메뉴 그룹에 추가) - `/production/serials` — 시리얼번호 목록 (검색: itemCode, serialNo / 필터: status) - `/production/serials/new` — 시리얼번호 일괄 등록 (품목 선택 → 시리얼 입력, 바코드 스캐너 지원) - `/production/serials/[id]` — 시리얼번호 상세/수정 - 입고 시 시리얼번호 자동 등록 옵션 - 출고 시 시리얼번호 스캔 → 상태 변경 (0=재고, 1=출고) - 기존 SerialNumber API 활용 Acceptance Criteria: - [x] 시리얼번호 목록 페이지에서 검색/필터 동작 - [x] 바코드 스캐너로 시리얼번호 일괄 등록 동작 - [x] 시리얼 상태 변경 (재고/출고) 동작 - [x] 20. BOM 관리 (Bill of Materials) What to do: - Prisma 스키마에 BOM 모델 추가: ``` BOM { id Int @id @default(autoincrement()) parentCode String (완제품/반제품 품목코드) childCode String (구성품목 코드) childName String? (구성품목명 - 캐시) qty Float (소요수량) unit String (단위) remark String? sortNo Int @default(0) (정렬순서) } ``` - BOM API: `/api/bom` — GET(목록+그룹핑), POST(생성/일괄), PUT(수정), DELETE(삭제) - BOM 페이지: `/production/bom` — BOM 목록 (품목별 그룹핑) - BOM 등록: 인라인 폼 — 완제품 선택 → 구성품목 행 추가 - BOM 구조: 완제품 카드별로 구성품목 테이블 표시 - 사이드바 "생산" 메뉴 그룹: 시리얼번호, BOM 관리 Acceptance Criteria: - [x] BOM 등록 (완제품 + 구성품목) 동작 - [x] BOM 목록에서 품목별 그룹핑 표시 - [x] BOM 삭제/수정 동작 --- ### v1.2 — 재고/리포트/연동 강화 (2026-05) > DB 변경: PostgreSQL → SQLite 전환, Prisma output 경로 `src/generated/prisma` > Next.js 버전: 15 → 16.2.4 업그레이드 #### 아키텍처 변경사항 ```mermaid graph TB subgraph Client["🖥️ Browser"] UI["React 19 + shadcn/ui<br/>TanStack Table + Recharts"] end subgraph Server["⚙️ Next.js 16 (App Router)"] Pages["Pages — 29개 메뉴<br/>master / purchase / sales / inventory<br/>production / reports"] API["API Routes — 40+ 엔드포인트<br/>RESTful CRUD + Confirm"] MW["Middleware<br/>JWT 인증 (jose)"] end subgraph DB["🗄️ SQLite (Prisma ORM)"] SQLITE["dev.db<br/>~30개 모델<br/>Prisma migrate 관리"] end subgraph Lib["📚 Shared Libraries"] Auth["auth.ts — JWT"] Serial["serial.ts — 시리얼번호 라이프사이클"] PDF["pdf.ts — PDF 인쇄"] Excel["excel.ts — Excel 내보내기"] end Client -->\|HTTP\| MW MW -->\|인증됨\| Pages MW -->\|미인증\| Login["/login"] Pages --> API API --> SQLITE API --> Auth API --> Serial API --> PDF API --> Excel style Client fill:#3b82f6,color:#fff style Server fill:#10b981,color:#fff style DB fill:#f59e0b,color:#fff style Lib fill:#8b5cf6,color:#fff ``` #### 전체 비즈니스 프로세스 흐름 (v1.2) ```mermaid flowchart TB subgraph Purchase["🛒 구매 프로세스"] PR["구매요청<br/>PR-YYYYMMDD-NNN"] PO["발주<br/>PO-YYYYMMDD-NNN"] RC["입고<br/>PU-YYYYMMDD-NNN"] end subgraph Sales["🏭 영업 프로세스"] QT["견적서<br/>QT-YYYYMMDD-NNN"] SO["수주<br/>SO-YYYYMMDD-NNN"] SH["출고<br/>SH-YYYYMMDD-NNN"] end subgraph Returns["↩️ 반품/불량"] RT["반품<br/>RT-YYYYMMDD-NNN"] DF["불량/폐기<br/>DF-YYYYMMDD-NNN"] end subgraph Production["🔧 생산"] BOM["BOM 관리"] PROD["생산오더<br/>WO-YYYYMMDD-NNN"] end subgraph Inventory["📦 재고 관리"] ST["현재고 (Stock)"] AD["재고조정<br/>StockChange"] MV["창고이동<br/>LT-YYYYMMDD-NNN"] SN["시리얼번호<br/>추적/관리"] end subgraph Reports["📊 리포트"] TS["매입매출 현황"] SL["수불부 (재고수불명세서)"] RV["채권/채무 현황"] DASH["대시보드"] end PR -->\|"발주 변환"\| PO PO -->\|"입고 등록<br/>?purchaseOrderCode="\| RC RC -->\|"재고 증가<br/>시리얼 자동생성"\| ST QT -->\|"수주 변환"\| SO SO -->\|"출고 생성"\| SH SH -->\|"재고 감소<br/>시리얼 자동할당"\| ST SH -->\|"반품 등록<br/>?refCode=SH-xxx"\| RT SH -->\|"불량 등록<br/>?sourceCode=SH-xxx"\| DF RT -->\|"시리얼 복구"\| ST BOM --> PROD PROD -->\|"생산 확정<br/>시리얼 자동생성"\| ST ST --> AD ST --> MV ST --> SN RC -.->\|"집계"\| TS SH -.->\|"집계"\| TS ST -.->\|"이력"\| SL SH -.->\|"미수금"\| RV RC -.->\|"미지급금"\| RV style Purchase fill:#3b82f6,color:#fff style Sales fill:#10b981,color:#fff style Returns fill:#ef4444,color:#fff style Production fill:#8b5cf6,color:#fff style Inventory fill:#f59e0b,color:#fff style Reports fill:#06b6d4,color:#fff ``` #### 시리얼번호 라이프사이클 ```mermaid stateDiagram-v2 [] --> 재고입고: 입고 확정<br/>(시리얜관리 품목) [] --> 재고입고: 생산오더 확정<br/>(산출품) 재고입고 --> 출고완료: 출고 확정<br/>(자동 할당) 출고완료 --> 재고입고: 반품 확정<br/>(매출반품) 재고입고: status = 0<br/>창고 내 보관 출고완료: status = 1<br/>출고 완료 note right of 재고입고 시리얼 생성 규칙: {접두어}-{YYYYMMDD}-{NNN} 대분류별 접두어: RM=원자재, HD=하드웨어 FG=완제품, SU=부자재 PK=포장재, ET=기타 end note note right of 출고완료 출고 시 가용 시리얼 자동 할당 부족 시 에러 발생 end note ``` #### 전체 메뉴 구성 (29개) ```mermaid graph LR subgraph Master["📋 기준정보"] M1["거래처 관리"] M2["품목 관리"] M3["창고 관리"] M4["직원 관리"] M5["프로젝트 관리"] end subgraph Purch["🛒 구매"] P1["구매요청"] P2["발주 관리"] P3["입고 관리"] end subgraph Sale["🏭 영업"] S1["견적 관리"] S2["수주 관리"] S3["출고 관리"] S4["반품 관리"] S5["불량/폐기"] end subgraph Inv["📦 재고"] I1["현재고 조회"] I2["창고이동"] I3["재고조정"] I4["바코드 관리"] end subgraph Prod["🔧 생산"] PR1["생산오더"] PR2["BOM 관리"] PR3["시리얼번호"] end subgraph Rpt["📊 리포트"] R1["매입매출 현황"] R2["수불부"] R3["채권/채무"] R4["재고현황"] end style Master fill:#3b82f6,color:#fff style Purch fill:#10b981,color:#fff style Sale fill:#f59e0b,color:#fff style Inv fill:#8b5cf6,color:#fff style Prod fill:#06b6d4,color:#fff style Rpt fill:#ef4444,color:#fff ``` #### 구현 완료 항목 - [x] 재고조정 API + 페이지 - `POST /api/inventory/stock/adjust` — 품목/창고별 수량 조정, StockChange 이력 기록 - `/inventory/adjustments` — 조정 이력 페이지 - [x] 창고이동 API 3종 + 페이지 3종 - `GET/POST /api/locate-trans` — 창고이동 목록/등록 - `GET /api/locate-trans/[code]` — 창고이동 상세 - `POST /api/locate-trans/[code]/confirm` — 확정 (출고창고 차감 + 입고창고 증가) - StockChange changeCode: 6=이동출고, 7=이동입고 - `/inventory/transfers` (목록), `/inventory/transfers/[code]` (상세+확정), `/inventory/transfers/new` (등록) - [x] 매입매출 현황 API + 페이지 - `GET /api/reports/transaction-summary?type=purchase\|sales&from=&to=&groupBy=item\|customer` - 품목별/거래처별 집계, 상세 내역, 마진율(매출) - `/reports/transaction` — 매입/매출 탭, 기간 필터, 집계 + 상세 - [x] 시리얼번호 라이프사이클 전체 구현 - `src/lib/serial.ts` — `generateSerialNumber()`, `createSerialNumbers()`, `isSerialManaged()` - 생산오더 확정 → 산출품 시리얼 자동생성 (status=0) - 입고 확정 → 시리얜관리 품목 시리얼 자동생성 - 출고 확정 → 가용 시리얼 자동할당 (status=1), 부족 시 에러 - 반품 확정 → 매출반품 시 시리얼 status 1→0 복구 ```mermaid sequenceDiagram participant Prod as 생산오더 participant Purch as 입고 participant Sales as 출고 participant Return as 반품 participant Serial as SerialNumber participant Stock as Stock Prod->>Serial: 확정 → 산출품 시리얼 생성<br/>{접두어}-{YYYYMMDD}-{NNN} Serial-->>Stock: status=0 (재고) Purch->>Serial: 확정 → 시리얜관리 품목<br/>시리얼 자동생성 Serial-->>Stock: status=0 (재고) Sales->>Serial: 확정 → 가용 시리얜 자동 할당 alt 가용 시리얼 존재 Serial-->>Stock: status=1 (출고) else 시리얼 부족 Sales-->>Sales: ❌ 에러: 시리얼 부족 end Return->>Serial: 매출반품 확정 Serial-->>Stock: status=0 (재고 복구) ``` - [x] 수불부 (재고수불명세서) - `GET /api/reports/stock-ledger?itemCode=` — 기초재고/입고/출고/잔고 흐름 - StockChange 기반, 기간 전 마지막 변경값=기초재고 - `/reports/stock-ledger` — 품목 선택, 기간 필터, 입출고 내역 ```mermaid graph TB 기초["기초재고<br/>(기간 전 마지막 StockChange)"] 입고["+ 입고<br/>(changeCode 1,3,7)"] 출고["- 출고<br/>(changeCode 2,4,6)"] 조정["± 조정<br/>(changeCode 5)"] 잔고["= 잔고<br/>(누적 계산)"] 기초 --> 입고 --> 잔고 기초 --> 출고 --> 잔고 기초 --> 조정 --> 잔고 style 기초 fill:#06b6d4,color:#fff style 잔고 fill:#f59e0b,color:#fff ``` - [x] 채권/채무 현황 - `GET /api/reports/receivables?type=receivable\|payable` - 확정된 매출=미수금, 확정된 매입=미지급금 - 거래처별 확장 행, 기간 필터 - `/reports/receivables` — 미수금/미지급금 탭 - [x] 발주→입고 연동 - 발주 상세에 "입고 등록" 버튼 - `?purchaseOrderCode=` query param으로 품목 자동 prefill - 입고 new 페이지에서 `useSearchParams` + `useEffect`로 로드 - `<Suspense>` boundary 필수 (Next.js 16 요구사항) - [x] 수주→출고 연동 (기존 구현됨) - 수주 상세에 "출고 생성" 버튼 - 미출고 수량 자동 계산 - [x] 출고→반품/불량 연동 - 출고 상세에 "반품 등록", "불량 등록" 버튼 - 반품: `?refCode=SH-xxx` → refCode 필드에 출고번호 저장 - 불량: `?sourceCode=SH-xxx&sourceType=sales` → 출처 추적 - 반품/불량 목록에서 출고 건 추적 가능 ```mermaid flowchart TB SH["출고 상세<br/>SH-YYYYMMDD-NNN"] SH -->\|"반품 등록<br/>refCode=SH-xxx"\| RT["반품 관리<br/>RT-YYYYMMDD-NNN"] SH -->\|"불량 등록<br/>sourceCode=SH-xxx"\| DF["불량 관리<br/>DF-YYYYMMDD-NNN"] RT -->\|"반품 목록에<br/>refCode 컬럼으로 표시"\| RTL["반품 관리 목록"] DF -->\|"불량 목록에<br/>출처/참조문서 컬럼으로 표시"\| DFL["불량 관리 목록"] style SH fill:#10b981,color:#fff style RT fill:#ef4444,color:#fff style DF fill:#ef4444,color:#fff style RTL fill:#f59e0b,color:#fff style DFL fill:#f59e0b,color:#fff ``` - [x] 사이드바 메뉴 29개 완성 - 반품 관리 (`/sales/returns`) 추가 - 불량/폐기 관리 (`/sales/defects`) 추가 - 바코드 관리 (`/inventory/barcode`) 추가 - 창고이동 (`/inventory/transfers`) 추가 - 매입매출 현황 (`/reports/transaction`) 추가 - 수불부 (`/reports/stock-ledger`) 추가 - 채권/채무 현황 (`/reports/receivables`) 추가 - [x] API 6개 `_count`/`_subtotal`/`customer` 버그 수정 - sales, purchases, sales-orders, quotations, purchase-requests, purchase-orders - `_count` (품목수), `_subtotal` (소계금액), `customer` (거래처명) 추가 - 기존: 항상 0 / 빈값 / `-` 으로 표시되던 문제 수정 - [x] 버그 수정 - 매입매출 현황 같은 결과: `useEffect` 의존성 `[]` → `[tab, groupBy, from, to]` - Fragment key 경고: `<>` → `<Fragment key={}>` (receivables 페이지) - `formatNumber` undefined: `(n ?? 0).toLocaleString()` (dashboard + stock-ledger) - 출고 목록 거래처명 `-`: API에 `include: { customer }` 누락 → 추가 - [x] 전체 메뉴/연결 감사 - 29개 메뉴 ↔ 29개 페이지 1:1 매칭 확인 - new 15개 연결 정상 - edit 6개 연결 정상 - 연동 4개 (발주→입고, 수주→출고, 출고→반품, 출고→불량) 정상 - 인쇄 7개 (견적서, 발주서, 수주서, 출고전표, 구매요청, 입고전표, 생산오더) 정상 - [x] 빌드 통과: `npx next build` → 94 라우트 ✅ #### 데이터 모델 (v1.2 추가분) ```mermaid erDiagram SERIALNUMBER { Int id PK String itemCode FK String serialNo String locationCode Int status String purchaseCode FK String saleCode FK String productionCode FK DateTime purchaseDate DateTime saleDate String remark } BOM { Int id PK String parentCode FK String childCode FK String childName Float qty String unit String remark Int sortNo } PRODUCTIONORDER { String code PK Int type String bomCode DateTime dday String locationCode String staffName Int status String keyword String writer String memo } PRODUCTIONORDERDETAIL { Int id PK String productionOrderCode FK String itemCode FK String itemName Float qty String unit Int lineType String remark Int lineNo } RETURN { String code PK Int type String refCode DateTime dday String customerCode FK String locationCode String staffName Int status String keyword String writer String memo } RETURNDETAIL { Int id PK String returnCode FK String itemCode FK String itemName Float qty String unit String reason String remark Int lineNo } DEFECT { String code PK Int type String sourceType String sourceCode DateTime dday String locationCode String staffName Int status String keyword String writer String memo } DEFECTDETAIL { Int id PK String defectCode FK String itemCode FK String itemName Float qty String unit String reason Int action String remark Int lineNo } LOCATETRAN { String code PK DateTime dday String locationOutCode String locationInCode String staffName Int status String writer String memo } LOCATETRANDETAIL { Int id PK String locateTranCode FK String itemCode FK String itemName Float qty Float realQty String unit String remark Int lineNo } SERIALNUMBER }o--\|\| ITEM : "for" SERIALNUMBER }o--\|\| LOCATION : "at" BOM }o--\|\| ITEM : "parent" BOM }o--\|\| ITEM : "child" PRODUCTIONORDER \|\|--o{ PRODUCTIONORDERDETAIL : "has" PRODUCTIONORDERDETAIL }o--\|\| ITEM : "references" RETURN \|\|--o{ RETURNDETAIL : "has" RETURNDETAIL }o--\|\| ITEM : "references" RETURN }o--\|\| CUSTOMER : "from" DEFECT \|\|--o{ DEFECTDETAIL : "has" DEFECTDETAIL }o--\|\| ITEM : "references" LOCATETRAN \|\|--o{ LOCATETRANDETAIL : "has" LOCATETRANDETAIL }o--\|\| ITEM : "references" ``` #### 주요 파일 맵 (v1.2) ``` src/ ├── app/ │ ├── (auth)/login/ │ ├── (dashboard)/ │ │ ├── page.tsx # 대시보드 │ │ ├── layout.tsx # 사이드바 (29개 메뉴) │ │ ├── master/ │ │ │ ├── customers/ # 거래처 (list, new, [code]) │ │ │ ├── items/ # 품목 (list, new, [code]) │ │ │ ├── locations/ # 창고 │ │ │ ├── staffs/ # 직원 │ │ │ └── projects/ # 프로젝트 │ │ ├── purchase/ │ │ │ ├── requests/ # 구매요청 │ │ │ ├── orders/ # 발주 (→ 입고 연동 버튼) │ │ │ └── receiving/ # 입고 (purchaseOrderCode prefill) │ │ ├── sales/ │ │ │ ├── quotations/ # 견적 │ │ │ ├── orders/ # 수주 (→ 출고 생성 버튼) │ │ │ ├── shipping/ # 출고 (→ 반품/불량 버튼) │ │ │ ├── returns/ # 반품 (refCode로 출고 추적) │ │ │ └── defects/ # 불량/폐기 (sourceCode로 출고 추적) │ │ ├── inventory/ │ │ │ ├── stock/ # 현재고 │ │ │ ├── transfers/ # 창고이동 (list, new, [code]+confirm) │ │ │ ├── adjustments/ # 재고조정 │ │ │ └── barcode/ # 바코드 │ │ ├── production/ │ │ │ ├── orders/ # 생산오더 │ │ │ ├── bom/ # BOM 관리 │ │ │ └── serials/ # 시리얼번호 │ │ └── reports/ │ │ ├── transaction/ # 매입매출 현황 │ │ ├── stock-ledger/ # 수불부 │ │ ├── receivables/ # 채권/채무 현황 │ │ └── inventory/ # 재고현황 │ └── api/ │ ├── auth/ # 로그인/로그아웃 │ ├── customers/ # 거래처 CRUD │ ├── items/ # 품목 CRUD │ ├── locations/ # 창고 CRUD │ ├── staffs/ # 직원 CRUD │ ├── projects/ # 프로젝트 CRUD │ ├── purchase-requests/ # 구매요청 CRUD + confirm │ ├── purchase-orders/ # 발주 CRUD + confirm │ ├── purchases/ # 입고 CRUD + confirm (+시리얼) │ ├── quotations/ # 견적 CRUD + confirm │ ├── sales-orders/ # 수주 CRUD + confirm │ ├── sales/ # 출고 CRUD + confirm (+시리얼) │ ├── returns/ # 반품 CRUD + confirm (+시리얼복구) │ ├── defects/ # 불량 CRUD + confirm │ ├── inventory/ │ │ ├── stock/ # 현재고 + adjust │ │ └── changes/ # 재고변경 이력 │ ├── locate-trans/ # 창고이동 CRUD + confirm │ ├── production-orders/ # 생산오더 CRUD + confirm (+시리얼) │ ├── bom/ # BOM CRUD │ ├── serials/ # 시리얼번호 CRUD │ ├── dashboard/ # 대시보드 집계 │ ├── reports/ │ │ ├── transaction-summary/ # 매입매출 현황 │ │ ├── stock-ledger/ # 수불부 │ │ └── receivables/ # 채권/채무 │ └── print/ # PDF 인쇄 (7종) ├── components/ │ ├── ui/ # shadcn/ui │ └── shared/ # DataTable, PageHeader, StatusBadge 등 ├── lib/ │ ├── prisma.ts # Prisma 클라이언트 싱글톤 │ ├── auth.ts # JWT 인증 (jose + bcryptjs) │ ├── serial.ts # 시리얼번호 라이프사이클 │ ├── pdf.ts # PDF 생성 (jsPDF) │ └── excel.ts # Excel 내보내기 (xlsx) └── generated/prisma/ # Prisma 생성 클라이언트 ``` #### API 엔드포인트 맵 (40+) 🔐 인증 + 📋 기준정보 ```mermaid graph LR subgraph Auth["🔐 인증"] A1["POST /login"] A2["POST /logout"] end subgraph Master["📋 기준정보"] M1["/customers<br/>GET POST<br/>[code] GET PUT DELETE"] M2["/items<br/>GET POST<br/>[code] GET PUT DELETE"] M3["/locations<br/>GET POST<br/>[code] GET PUT DELETE"] M4["/staffs<br/>GET POST<br/>[code] GET PUT DELETE"] M5["/projects<br/>GET POST<br/>[code] GET PUT DELETE"] end style Auth fill:#ef4444,color:#fff style Master fill:#3b82f6,color:#fff ``` 🛒 구매 + 🏭 영업 ```mermaid graph LR subgraph Purchase["🛒 구매"] P1["/purchase-requests<br/>CRUD + confirm"] P2["/purchase-orders<br/>CRUD + confirm"] P3["/purchases<br/>CRUD + confirm"] end subgraph Sales["🏭 영업"] S1["/quotations<br/>CRUD + confirm"] S2["/sales-orders<br/>CRUD + confirm"] S3["/sales<br/>CRUD + confirm"] S4["/returns<br/>CRUD + confirm"] S5["/defects<br/>CRUD + confirm"] end style Purchase fill:#10b981,color:#fff style Sales fill:#f59e0b,color:#fff ``` 📦 재고 + 🔧 생산 + 📊 리포트 + 🖨️ 인쇄 ```mermaid graph LR subgraph Inv["📦 재고"] I1["/inventory/stock"] I2["/inventory/stock/adjust"] I3["/inventory/changes"] I4["/locate-trans + confirm"] end subgraph Prod["🔧 생산"] PR1["/production-orders<br/>CRUD + confirm"] PR2["/bom<br/>GET POST PUT DELETE"] PR3["/serials<br/>GET POST PUT DELETE"] end subgraph Reports["📊 리포트"] R1["/transaction-summary"] R2["/stock-ledger"] R3["/receivables"] R4["/dashboard/"] end subgraph Print["🖨️ 인쇄"] PN1["quotation/[code]"] PN2["purchase-order/[code]"] PN3["sales-order/[code]"] PN4["shipping/[code]"] end style Inv fill:#8b5cf6,color:#fff style Prod fill:#06b6d4,color:#fff style Reports fill:#ec4899,color:#fff style Print fill:#64748b,color:#fff ``` #### StockChange changeCode 정의 \| 코드 \| 의미 \| 발생 지점 \| \|------\|------\|-----------\| \| 0 \| 기타 \| — \| \| 1 \| 매입입고 \| 입고 확정 시 \| \| 2 \| 매출출고 \| 출고 확정 시 \| \| 3 \| 생산입고 \| 생산오더 확정 시 \| \| 4 \| 생산출고 \| 생산오더 확정 시 (자재 소모) \| \| 5 \| 재고조정 \| 재고조정 등록 시 \| \| 6 \| 이동출고 \| 창고이동 확정 시 (출발창고) \| \| 7 \| 이동입고 \| 창고이동 확정 시 (도착창고) \| #### 기술 스택 요약 (v1.2) \| 항목 \| 기술 \| \|------\|------\| \| 프레임워크 \| Next.js 16.2.4 (App Router, standalone) \| \| 언어 \| TypeScript 5 \| \| DB \| SQLite (Prisma ORM 6.19) \| \| 인증 \| jose (JWT) + bcryptjs + httpOnly 쿠키 \| \| UI \| React 19 + shadcn/ui + Tailwind CSS 4 \| \| 테이블 \| TanStack Table 8 \| \| 차트 \| Recharts 3 \| \| PDF \| jsPDF + jspdf-autotable \| \| Excel \| SheetJS (xlsx) \| \| 바코드 \| JsBarcode \| \| 테스트 \| Vitest \| --- ### v1.3 — Ubuntu 서버 Docker 배포 (2026-05) #### 배포 아키텍처 ```mermaid graph TB USER["👤 사용자"] HTTPS["HTTPS<br/>werp.wellcoms.co.kr"] CADDY["🔀 Caddy<br/>리버스프록시<br/>자동 TLS (Let's Encrypt)"] DOCKER["🐳 Docker Compose<br/>node:20-alpine"] APP["Next.js 16.2.4<br/>standalone 모드<br/>port 3000"] VOL["📁 Volume<br/>./data/dev.db<br/>SQLite 영속성"] ENV["📄 .env<br/>DATABASE_URL"] USER --> HTTPS --> CADDY -->\|"localhost:3200"\| DOCKER --> APP --> VOL APP --> ENV style USER fill:#6366f1,color:#fff style CADDY fill:#06b6d4,color:#fff style DOCKER fill:#0ea5e9,color:#fff style VOL fill:#f59e0b,color:#fff ``` #### 배포 파일 구성 ``` /srv/docker/werp/ # 서버 배포 디렉토리 ├── repo/ # Next.js 프로젝트 소스 │ ├── Dockerfile # multi-stage (deps → builder → runner) │ ├── docker-compose.yml # env_file, volume ./data:/app/data, ports 3200:3000 │ ├── .dockerignore # node_modules, .next, .git, src/generated 제외 │ ├── next.config.ts # output: "standalone" │ ├── package.json │ ├── prisma/ │ └── src/ ├── data/ │ └── dev.db # SQLite DB (598KB, 영속성 volume) ├── .env # DATABASE_URL=file:/app/data/dev.db └── deploy.sh # 배포 스크립트 ``` #### 배포 절차 ```mermaid flowchart TB S1["1. 소스코드 서버 복사<br/>([FILE_TRANSFER] [WINDOWS_SHARE_PATH])"] S2["2. 서버 SSH 접속"] S3["3. repo/ 파일 루트로 이동"] S4["4. docker compose up -d --build"] S5["5. Caddy 설정 추가"] S6["6. https://werp.wellcoms.co.kr 접속"] S1 --> S2 --> S3 --> S4 --> S5 --> S6 style S1 fill:#3b82f6,color:#fff style S4 fill:#10b981,color:#fff style S6 fill:#f59e0b,color:#fff ``` #### 서버 명령어 ```bash # 1. 서버 접속 ssh user@[SERVER_IP] # 2. 배포 디렉토리로 이동 cd /srv/docker/werp # 3. repo/ 내용을 루트로 이동 shopt -s dotglob mv repo/ . rmdir repo # 4. Docker 빌드 + 실행 docker compose up -d --build # 5. 로그 확인 docker compose logs -f # 6. Caddy 설정 (기존 /srv/docker/caddy/Caddyfile) # werp.wellcoms.co.kr { # reverse_proxy localhost:3200 # } ``` #### Docker 설정 상세 \| 파일 \| 역할 \| 주요 설정 \| \|------\|------\|-----------\| \| `Dockerfile` \| multi-stage 빌드 \| node:20-alpine, standalone 복사, openssl 포함 \| \| `docker-compose.yml` \| 컨테이너 오케스트레이션 \| `env_file: .env`, volume `./data:/app/data`, ports `3200:3000` \| \| `.env` \| 환경변수 \| `DATABASE_URL=file:/app/data/dev.db` \| \| `.dockerignore` \| 빌드 제외 \| node_modules, .next, .git, src/generated \| #### DB 관리 ```mermaid flowchart TB LOCAL["로컬 개발<br/>[PROJECT_PATH]\\dev.db"] SAMBA["[FILE_TRANSFER] 복사<br/>[WINDOWS_SHARE_PATH]\\data\\dev.db"] SERVER["서버 SQLite<br/>/srv/docker/werp/data/dev.db"] LOCAL -->\|"[FILE_TRANSFER_CMD]"\| SAMBA -->\|"서버에서 접근"\| SERVER style LOCAL fill:#3b82f6,color:#fff style SERVER fill:#10b981,color:#fff ``` - DB 백업: `cp /srv/docker/werp/data/dev.db /srv/docker/werp/data/dev.db.bak` - DB 업데이트: [FILE_TRANSFER]로 새 dev.db 복사 후 `docker compose restart` - Prisma 마이그레이션: 컨테이너 내에서 `npx prisma migrate deploy` #### 완료 상태 - [x] `next.config.ts` standalone 모드 설정 - [x] `Dockerfile` multi-stage 빌드 작성 - [x] `docker-compose.yml` 작성 - [x] `.dockerignore` 작성 - [x] `.env.production` / `.env` 작성 - [x] `npx next build` 94 라우트 빌드 성공 - [x] `.gitignore` 업데이트 (*.db, src/generated) - [x] `git init` + `git commit` (466 files, 45138 insertions) - [x] [FILE_TRANSFER]로 서버 이전 완료 (533개 소스파일 + DB 598KB) - [ ] 서버에서 `docker compose up -d --build` 실행 (사용자 진행) - [ ] Caddy Caddyfile에 `werp.wellcoms.co.kr` 리버스프록시 추가 (사용자 진행) - [ ] `https://werp.wellcoms.co.kr` 접속 확인 (사용자 진행)
태그

댓글
작성자(*)
비밀번호(*)
자동등록방지	(자동등록방지 숫자를 입력해 주세요)
내용(*)

이전	웰컴스 타자게임 사용설명	김재석	2026-05-11
다음	맥사인 홈페이지 구성	김재석	2026-04-29

목록으로