# OMS·WMS·ERP Strategic Execution Framework v1.0 # Based on actual PDF specifications (not hallucinated) # 30 Strategic Principles Applied Throughout # Created: 2026-07-26 (Post-Advisor Correction) --- ## GROUNDTRUTH: PDF-Derived Specifications ### Architecture (From PDF 1: Vue 3·TypeScript OMS·WMS·ERP 아키텍처.pdf) **Recommended Architecture**: Domain-Centric Modular Monolith + Layered Internal Structure ``` Application Shell (routing, auth, global state) ↓ Workflow (cross-domain orchestration) ↓ Module Presentation (Vue, Pinia, Router) ↓ Application Use Case (business logic entry points) ↓ Domain (entities, value objects, rules) ↑ Infrastructure Adapter (API clients, DB, cache) ``` **Core Principles** (PDF explicit): 1. Module by business domain, not by screen 2. Vue, Pinia, Router confined to Presentation layer only 3. Domain layer NEVER imports Vue/HTTP libraries 4. API DTO ≠ Screen Model ≠ Domain Model (3-way separation) 5. Inter-module access only via public index.ts 6. Distinguish common UI from business rules 7. Workflows coordinate multi-domain logic **Folder Structure** (PDF prescribed): ``` src/ ├─ app/ (shell, bootstrap, config) ├─ shared/ (primitives, fields, forms, data-grid) ├─ modules/ │ ├─ order/ (OMS domain) │ ├─ inventory/ (WMS domain) │ └─ accounting/ (ERP domain) ├─ domain/ (entities, repositories, use cases) ├─ infrastructure/ (API clients, adapters) └─ workflows/ (multi-domain orchestration) ``` --- ### CRUD Templates (From PDF 2: 공통 CRUD 화면 템플릿 상세 명세.pdf) **11 Standard Template Types**: | Template ID | Screen Type | Representative Business | Key Features | |-----------|-----------|----------------------|--------------| | TPL-LIST-01 | List/Search | Orders, inventory, vouchers | Saved queries, column preferences, multi-filter, bulk actions, async export | | TPL-CREATE-01 | Single Create | Vendor, product, simple order | Direct input, simple validation | | TPL-CREATE-02 | Header-Line Create | Order, PO, receipt, voucher | Master-detail, line auto-calc, currency standardization | | TPL-CREATE-03 | Wizard Create | Complex order, return, contract | Multi-step workflow, conditional logic, branch preview | | TPL-DETAIL-01 | Detail View | Order detail, receipt detail, voucher detail | Tabs (Info, History, Attachments, Audit), read-only by default | | TPL-EDIT-01 | General Edit | Master data, order provisional state | Full form edit, save/cancel, undo/redo | | TPL-BULK-01 | Bulk Edit | Owner, due date, status batch change | Multi-row mutation, impact preview | | TPL-DELETE-01 | Delete | Unused temp data | Soft-delete only, never hard-delete live records | | TPL-CANCEL-01 | Cancel/Reversal | Order cancel, shipment cancel, voucher reversal | Create reversal transaction, NOT overwrite original | | TPL-APPROVAL-01 | Approval/Rejection | PO approval, voucher approval | Workflow state machine, approval reason capture | | TPL-HISTORY-01 | Change History | Value changes, state transitions, system processing | Before/after comparison, worker, reason, source trace | **Screen Layout (PDF mandatory)**: ``` ┌────────────────────────────────────────────────┐ │ Global Header (system switch, org select, │ │ global search, notifications) │ ├────────────────────────────────────────────────┤ │ Breadcrumb │ ├────────────────────────────────────────────────┤ │ Page Header (title, ID, status, last editor) │ ├────────────────────────────────────────────────┤ │ Context Bar (facility, warehouse, date, lock) │ ├────────────────────────────────────────────────┤ │ │ │ Main Content (list, form, detail) │ │ │ ├────────────────────────────────────────────────┤ │ Sticky Action Bar ([Cancel] [Draft] [Save]) │ └────────────────────────────────────────────────┘ ``` --- ### Input Component Hierarchy (From PDF 3: 입력 컴포넌트 상세 명세.pdf) **4 Layers** (strict separation): #### Layer 1: Primitive Visual + interaction foundation (no business knowledge). **Components** (10 types): - TextInput, Button, Checkbox, Radio, Select - Popover, Dialog, Calendar, Listbox, Grid Cell #### Layer 2: Typed Field Data type awareness (format, validation, but no domain). **Components** (8 types): - StringField, IntegerField, DecimalField - DateField, DateTimeField, CurrencyField, PercentageField, CodeField #### Layer 3: Domain Field Business domain understanding (item lookup, warehouse context). **Components** (10 types): - ItemLookup, CustomerLookup, WarehouseLookup, LocationLookup - QuantityField, MoneyField, LotField, SerialNumberInput - BusinessRegistrationNumberField, AccountLookup #### Layer 4: Business Composite Multiple fields + business rules (e.g., tax calculation). **Components** (8 types): - AddressEditor, OrderLineEditor, InventoryAllocationEditor - LotSerialEditor, TaxAmountEditor, DeliveryScheduleEditor - BarcodeWorkInput, ApprovalReasonEditor **Strict Rule** (PDF emphasis): > "복잡한 컴포넌트가 거대한 범용 컴포넌트로 변질되지 않게 한다." > (Prevent complex components from degenerating into bloated monoliths.) Business Composites own field combinations, NOT full-screen logic. --- ### Design Principles (From PDF 4: CRUD 화면 및 입력 컴포넌트 상용화 제안.pdf) **Core Principle**: TRANSACTIONS, not CRUD Business transactions extend beyond simple Create/Read/Update/Delete: | Category | Operations | Example | |----------|-----------|---------| | **Inquiry** | Search, filter, compare, aggregate, download | Order list with saved filters | | **Creation** | Direct input, copy, template, external sync | Order creation from EDI | | **Modification** | Inline edit, bulk edit, record edit | Status batch change | | **State Transition** | Approve, confirm, allocate, close, suspend, release | Order confirmation → inventory reserve | | **Exception Handling** | Cancel, return, reversal, reprocess, correction | Order cancel (reversal transaction) | | **History** | Before/after, worker, reason, source trace | Audit trail for regulatory compliance | | **Collaboration** | Comments, attachments, approval requests, handoff | Approval workflow + reason capture | | **AI Assistance** | Value recommend, anomaly detect, input correct, explain | Predictive analytics for order priority | **Critical**: Completed data is never deleted or overwritten. Use reversal transactions instead. --- ### Phased Rollout Strategy (From PDF 5: 단계별 구축 백로그.pdf) **Phased Approach** (NOT all-at-once): ``` 0. Current State Analysis & Standard Decisions ↓ 1. Vue 3·TypeScript Development Foundation ↓ 2. Common Models & API Boundary ↓ 3. Primitive & Input Components ↓ 4. CRUD Screen Templates ↓ 5. OMS Order Pilot (order registration) ↓ 6. WMS Receipt/Picking Pilot (warehouse floor validation) ↓ 7. ERP Voucher/Approval Pilot (accounting integration) ↓ 8. Integrated Workflow & Batch Processing ↓ 9. AI/AX Enhancements ↓ 10. Legacy Migration & Operational Stability ``` **Rationale** (PDF explicit): > "처음부터 OMS·WMS·ERP 전체를 동시에 구현하지 않는다." > (Don't implement OMS·WMS·ERP simultaneously from day one.) > "주문 등록처럼 입력·조회·계산·상태 전이·재고 연계가 모두 포함된 대표 업무를 먼저 구현하여 구조의 실효성을 검증한다." > (Validate architecture with representative end-to-end business: order registration includes input, inquiry, calculation, state transition, inventory linking.) **Work Hierarchy** (PDF prescribed): ``` Initiative (OMS·WMS·ERP Unified Business Platform) └─ Epic (e.g., "Order Registration Standardization") └─ Feature (e.g., "Header-Line Order Create") └─ Story (e.g., "User saves order with vendor + item") ├─ Task: OrderFormModel implementation ├─ Task: CreateOrderUseCase implementation ├─ Task: API Mapper └─ Task: E2E test implementation ``` **Priority Matrix** (PDF defined): | Level | Meaning | Examples | |-------|---------|----------| | P0 | Service operation + data consistency critical | Order state machine, inventory reserve atomicity | | P1 | Required for first business release | OMS order pilot | | P2 | Operational efficiency + scalability | Bulk processing, async export | | P3 | Enhancement or optional feature | AI recommendations, advanced reporting | **Task Sizing** (PDF criteria): | Size | Effort | Guidance | |------|--------|----------| | XS | <0.5 day | Simple change, no decomposition needed | | S | 1-2 days | Standard task, low risk | | M | 3-5 days | Multi-component, moderate coordination | | L | 1 sprint | Substantial, can break into substories | | XL | >1 sprint | MUST be decomposed, never assign as single ticket | --- ## 30 STRATEGIC PRINCIPLES (Integrated with PDF Specifications) ### Principle 1: SOLID (Software Design) **Application**: Architecture layer in PDF 1 - **S**ingle Responsibility: Each module (order, inventory, accounting) owns one domain - **O**pen/Closed: Add new domains without modifying existing layers - **L**iskov Substitution: All Field components swap without caller changes - **I**nterface Segregation: Primitive doesn't bloat with domain knowledge - **D**ependency Inversion: Domain layer depends on repositories (abstract), not HTTP client (concrete) **Verification Checkpoint**: Code review: no circular imports, all domain-to-infrastructure flow one-way --- ### Principle 2: Code Refactoring (Continuous) **Application**: Prevent "complex component degenerates into monolith" (PDF explicit warning) - Extract reusable patterns at 3+ usage point threshold - Componentize OrderLineEditor when same fields+logic appear in order, PO, receipt - Break down TPL-CREATE-02 if >500 lines (template too complex) **Verification Checkpoint**: Component size < 300 lines (.vue file), dependencies < 5 imports --- ### Principle 3: Data Consistency (SSOT) **Application**: "화면과 서버의 데이터 해석이 달라지지 않게 한다" (PDF 1.1) - API DTO ≠ Screen Model ≠ Domain Model (PDF explicit 3-way separation) - All currency decimals conform to PostgreSQL NUMERIC(19,4) standard - Quantity unit (each, kg, meter) enforced server-side, never client-side formatting **Verification Checkpoint**: Schema review + integration test: CurrencyField value round-trip == API response --- ### Principle 4: Parsimony (No Gold-Plating) **Application**: Template specification precise, not aspirational - TPL-LIST-01 includes saved filters + bulk actions (PDF spec) - TPL-CREATE-03 (wizard) only for complex orders (PDF: "복합 주문") - Reject "nice-to-have" export formats until P1 release proven stable **Verification Checkpoint**: Feature checklist matches PDF requirement, no extras (backlog → Phase 12) --- ### Principle 5: Normalization (Database) **Application**: Schema design for master data (vendors, items, GL accounts) - 3NF minimum (vendor table: vendor_id → name, country; no address duplication) - Separate master from transactional (items in item_master, not repeated in order_line) - LOT/Serial data as separate entity (denormalized only if 100M+ rows proven slow) **Verification Checkpoint**: ER diagram review, no repeating groups, referential integrity 100% --- ### Principle 6: Denormalization (Justified) **Application**: Only after performance proof - Cache order total instead of sum(order_line.qty * price) IFF - Query <200ms target breached (P95 measurement) - Denormalization reduces to <100ms (proof required) - Cascade update logic fully tested (no orphaned totals) - Example: order_summary.total_amount auto-updated via trigger **Verification Checkpoint**: Load test before/after, TTL strategy for cache invalidation --- ### Principle 7: Process Simplification **Application**: Validate BEFORE automating - Manual order entry: 5 steps (enter customer → items → dates → validate → save) - Automate only after 100 live orders confirm 5-step workflow is universal - Never assume "users want copy-paste bulk" until stated explicitly - Approval workflow: Confirm 2-person dual-approval rule is actual business requirement, not preference **Verification Checkpoint**: Workflow diagram reviewed by domain experts (OMS user, WMS supervisor, accounting manager) --- ### Principle 8: Patterns & Design **Application**: Reusable patterns for business transactions - **Pattern 1**: List + Detail (TPL-LIST-01 + TPL-DETAIL-01 pair) - **Pattern 2**: Header-Line with auto-calc (TPL-CREATE-02, e.g., order → line items → total) - **Pattern 3**: State Machine (approve → confirm → ship, never skip backward) - **Pattern 4**: Reversal Transaction (cancel = create opposite entry, not delete) **Verification Checkpoint**: Common pattern identified for 3+ templates → abstract into reusable module --- ### Principle 9: Standardization (Conventions) **Application**: Consistent naming, API contracts, component interfaces - Field naming: `quantity`, `quantity_unit`, `quantity_reserved` (not `qty`, `qtyUnit`, `reserved_qty`) - API endpoints: `/api/orders/{orderId}/lines` (nested resource) not `/api/orders/lines?order_id=...` - Component props: `modelValue`, `@update:modelValue` (Vue 3 standard, not custom `value`/`onChange`) - Error codes: ERR_ORDER_VALIDATION_QUANTITY_EXCEEDS_STOCK (fully qualified, i18n key) **Verification Checkpoint**: Linting rules enforce naming (ESLint), OpenAPI schema validation, Storybook prop documentation --- ### Principle 10: Structuring (Layered Architecture) **Application**: PDF 1 architecture enforced - Presentation Layer (Vue, Pinia, Router): handles user interaction, routes, component state - Application Layer (Use Cases): orchestrates domain logic (CreateOrderUseCase) - Domain Layer (Entities, Value Objects, Rules): business logic, NO Vue/HTTP knowledge - Infrastructure Layer (Adapters): API clients, DB repositories **Verification Checkpoint**: No imports from higher layers into lower (e.g., domain never imports presentation) --- ### Principle 11: Vibes Coding (Cognitive Load) **Application**: Clear naming, minimal mental overhead, consistency - Component naming: `CustomerLookup` (not `CustmrSrch`, not `CustomerAutocompleteSearchWithValidation`) - Variable names: `orderTotal`, not `t` or `sum_$_from_items` - Error messages: "Order quantity exceeds available stock (reserve: 100, order: 150)" (context, not cryptic code) - Code structure: 1 function = 1 responsibility (CreateOrderUseCase doesn't also handle price calculation) **Verification Checkpoint**: Pair programming review, PR comment: "readable without documentation?" --- ### Principle 12: Hallucination Prevention (Ground Truth) **Application**: Explicit test-driven, no assumptions - Requirement: "Save order with customer + items" - NOT assumed: "Orders can have unlimited line items" (test: max 999 lines per business rule) - NOT assumed: "Items can be duplicated in one order" (test: confirm if allowed or enforce uniqueness) - Verified via: PDF spec, stakeholder sign-off, acceptance test - Never code "nice-to-have" features without explicit P0/P1 tag **Verification Checkpoint**: Acceptance test references PDF page, stakeholder email, or JIRA requirement, not general assumption --- ### Principle 13: Ground Truth & Reproducibility **Application**: All results deterministic, traceable to source - Test data: seed.sql from GatherTradingData.json (not random generation) - Calculations: CurrencyField(100.50, "USD") → API response `{"amount": "100.5000"}` (4 decimals, always) - Audit trail: OrderCreated event includes user, timestamp, IP, all changes logged - Reproducible: QA can replay issue from 2 weeks ago using same test data snapshot **Verification Checkpoint**: E2E test passes in CI pipeline, seed data versioned in git, audit log exported for review --- ### Principle 14: Traceability (Audit) **Application**: Complete history of all changes - Create: `audit_log.operation = 'INSERT', changed_by = user_id, changed_at = now()` - Update: `audit_log.operation = 'UPDATE', old_value = '{"status": "DRAFT"}', new_value = '{"status": "CONFIRMED"}', reason = 'Admin action'` - Delete: `audit_log.operation = 'DELETE'` (soft-delete only, never erase) - Reversal: `audit_log.related_transaction_id = original_order_id` (link cancel to original) **Verification Checkpoint**: All CRUD operations produce audit_log row, audit UI queries pass, compliance report shows 100% coverage --- ### Principle 15: Reliability (Fault Tolerance) **Application**: Graceful degradation, auto-recovery - Network failure: Retry 3x with exponential backoff (1s, 2s, 4s), then user-friendly error - Validation failure: Clear error message with fix guidance ("Quantity exceeds stock by 50 units, reduce or request allocation") - State inconsistency: Transaction rollback (order saved + inventory reserved atomically, no orphaned state) - Cascade failure: If GL account API down, order can still save (audit flag: "GL posting pending") **Verification Checkpoint**: Chaos engineering test, network latency/loss simulation, error handling 100% tested --- ### Principle 16: Technical Debt (Zero New, Reduce Old) **Application**: No shortcuts, audit existing debt - No: hardcoded user IDs, no-verify deployments, TODO comments without ticket - Yes: Refactor one legacy component per sprint (e.g., old BaseForm → new Typed Field approach) - Quarterly audit: Debt spreadsheet (complexity, security, performance) with mitigation plan **Verification Checkpoint**: Debt review in sprint retrospective, tech lead sign-off on any debt deferral --- ### Principle 17: Componentization (Smart + Dumb) **Application**: Clear separation (PDF implicit in 4-layer hierarchy) - **Dumb (Presentation)**: Primitive, Typed Field (TextInput, CurrencyField) — props in, events out, zero side effects - **Smart (Business Logic)**: Use Cases (CreateOrderUseCase), Stores (OrderStore) — owns state, API calls, calculations - **Composite (Pattern)**: OrderLineEditor (coordinates field + validation + auto-calc) — re-used in multiple contexts - **Page (Container)**: OrderCreatePage (composes OrderForm + UseCase orchestration) — specific to single business process **Verification Checkpoint**: Storybook for Dumb components (no backend needed), separate integration test for Smart (mocked API) --- ### Principle 18: Professional Approach (정공법) **Application**: Best practices, no cutting corners - Code review before merge (all changes reviewed, approved) - Pair programming for high-risk code (state machine logic, data validation) - Documentation: API contracts (OpenAPI), component props (TypeScript types), workflows (ADRs) - Testing: Unit (70%+), Integration (API mocks), E2E (Playwright) - Security: OWASP validation, RBAC tests, SQL injection prevention (parameterized queries) **Verification Checkpoint**: PR checklist: tests pass, docs updated, no security warnings, code review approved --- ### Principles 19-30 (Continuation for Comprehensiveness) **Principle 19: Type Safety (TypeScript)** - All components export TypeScript interfaces for Props, Emits, Model - No `any` type, strict mode enabled - Domain entities typed (Order, OrderLine, etc.) **Principle 20: Accessibility (WCAG 2.1)** - All fields: label linked, ARIA attributes, keyboard navigation - Colors: WCAG AA contrast ratio (4.5:1 for text) - Form errors: announced to screen readers **Principle 21: Internationalization (i18n)** - All user-facing text: externalized to .i18n.ts files - Supported languages: Korean, English, Japanese (per PDF) - Date/currency formatting: locale-aware (not hardcoded) **Principle 22: Performance (Response Time)** - API P95 response: <250ms - Component render: <100ms - Bundle size: <500KB (gzip) - Measured: Lighthouse, browser DevTools, load testing **Principle 23: Security (OWASP)** - Input validation: Server-side + client-side redundant - XSS prevention: Never innerHTML, use Vue templates - CSRF tokens: All state-changing requests - SQL injection: Parameterized queries only (Dapper/TypeORM) **Principle 24: Error Handling (User-Centric)** - Show: "Order cannot be canceled after shipment confirmed" (clear business rule) - NOT: "SQL error: constraint violation" (technical jargon) - Recovery: Suggest next action ("Contact admin to unlock" / "Request manager approval") **Principle 25: API Consistency (REST Contracts)** - GET /api/orders → list with pagination - POST /api/orders → create - GET /api/orders/{id} → detail - PUT /api/orders/{id} → full update - PATCH /api/orders/{id} → partial update - DELETE /api/orders/{id} → soft-delete - All responses: 200 success, 400 validation, 401 auth, 403 forbidden, 404 not found, 500 server error **Principle 26: Testing Pyramid (Automated)** - Unit (50%): Components, Use Cases, Validation rules - Integration (30%): API + Store + Component workflows (with mock backend) - E2E (20%): Critical user journeys (order create → confirm → ship) - Coverage: 70%+ code coverage, 100% critical path coverage **Principle 27: Deployment Pipeline (CI/CD)** - Automated: Code merge → lint → test → build → deploy-staging → health-check - Manual gate: Staging validation → production approval - Rollback: Blue-green deployment, 1-click revert to previous version - Monitoring: Sentry (errors), DataDog (performance), uptime checks **Principle 28: Documentation (Durable)** - Architecture Decision Records (ADRs) for major choices - OpenAPI 3.0 for all APIs (auto-generated, never stale) - Storybook for component library (visual + prop docs) - README per module (setup, usage, testing) - Wiki (deployment, ops runbooks, troubleshooting) **Principle 29: Team Discipline (Enforcement)** - Code review checklist enforced (ESLint, type-check, test coverage) - Commit message standard: type(scope): subject (feat, fix, docs, refactor, test) - Git workflow: feature branches → PR → squash merge (clean history) - Ownership: Module lead responsible for code quality + debt in their domain **Principle 30: Continuous Improvement (Iteration)** - Weekly retrospectives: What went well, what failed, action items - Monthly metrics review: Test coverage, bug count, deployment frequency, lead time - Quarterly strategy: Architecture debt audit, technology updates, team skill development - Post-mortems for P1+ incidents: Root cause, prevention, learning documented --- ## EXECUTION ROADMAP (PDF-Aligned, 30 Principles Applied) ### Phase 0: Foundation & Standards (Week 1-2) **Objectives**: - Establish architecture patterns (Principle 8: Patterns) - Define API contracts (Principle 25: REST) - Create component hierarchy (Principle 10: Structuring) - Validate data model (Principle 3: Consistency) **Deliverables**: - Architecture Decision Record (ADR-001): Monolithic SPA + 7-layer stack - OpenAPI 3.0 spec (30 endpoints) reviewed by backend/frontend - Component taxonomy (4 layers: Primitive, Typed Field, Domain Field, Business Composite) - Database schema v1 (orders, order_lines, inventory, vendors, customers, gl_accounts, audit_log) **30 Principles Applied**: 1. SOLID: Review architecture diagram, no circular dependencies (Principle 1) 2. Refactoring: Identify legacy patterns to replace (Principle 2) 3. Consistency: Schema review for 3-way Model separation (Principle 3) 4. Parsimony: Spec = PDF requirement, nothing extra (Principle 4) 5. Normalization: 3NF schema design (Principle 5) 6. Processes: Confirm workflows with domain experts (Principle 7) 7. Patterns: Map 11 CRUD templates to code patterns (Principle 8) 8. Standardization: Naming convention doc (Principle 9) 9. Structuring: Layer diagram finalized (Principle 10) 10. Vibes: Code style guide + Prettier config (Principle 11) 11. Hallucination: All specs sourced from PDF, signed off (Principle 12) 12. Reproducibility: Seed test data from GatherTradingData.json (Principle 13) 13. Traceability: ADR + design decisions in git (Principle 14) 14. Reliability: Error handling patterns defined (Principle 15) 15. Tech Debt: Baseline inventory of legacy code (Principle 16) 16. Componentization: Layer 1-2 reusability rules (Principle 17) 17. Professional: Code review SLA 24h (Principle 18) 18. TypeScript: Strict mode enabled, no `any` allowed (Principle 19) 19. Accessibility: WCAG audit checklist created (Principle 20) 20. i18n: Locale file structure (Principle 21) 21. Performance: Budget defined (<250ms P95) (Principle 22) 22. Security: OWASP threat model documented (Principle 23) 23. Error Handling: Message template library (Principle 24) 24. API: REST contract checklist (Principle 25) 25. Testing: Test pyramid strategy (Principle 26) 26. CI/CD: Pipeline skeleton (linting, build, test) (Principle 27) 27. Documentation: README template for modules (Principle 28) 28. Ownership: DRI (directly responsible individual) assigned per module (Principle 29) 29. Retrospectives: Weekly standup template (Principle 30) **Exit Criteria**: - All 11 PDF pages reviewed, specifications confirmed - Architecture diagram approved by tech lead - OpenAPI spec 100% complete, no endpoints TBD - Component taxonomy examples in Storybook v0 - DB schema passes referential integrity audit - Risk register: 15+ identified with mitigations --- ### Phase 1-2: Development Foundation & Components (Week 3-6) **Objectives** (Principle 4: only what PDF requires): - Implement 4-layer component hierarchy - Establish Pinia stores + API client - Create CRUD template scaffolds - Automated testing pipeline **Deliverables**: - Layer 1-2 components: 30 Primitive + Typed Field (TextInput, CurrencyField, DateField, etc.) - Layer 3-4 sample components: ItemLookup, OrderLineEditor - CRUD template stubs: TPL-LIST-01, TPL-CREATE-02, TPL-DETAIL-01, TPL-EDIT-01 - Storybook with 100 component stories - Test suite: 70%+ coverage (Principle 26) **30 Principles Applied**: 1. SOLID: Each component single responsibility (Principle 1) 2. Refactoring: Generic input → Type-specific (TextInput → CurrencyField) (Principle 2) 3. Consistency: API DTO ≠ Model ensured in mappers (Principle 3) 4. Parsimony: Only 4 layers, no 5th "super" layer (Principle 4) 5. Componentization: Dumb/Smart split enforced in tests (Principle 17) 6. TypeScript: `