워크스페이스 및 프로젝트 지식 정의
워크스페이스 지식과 프로젝트 지식을 사용하여 Lovable에 지속적인 지침을 정의하세요. 공유 코딩 표준, 아키텍처 규칙, 프로젝트 컨텍스트를 설정하면 Lovable이 대화와 프로젝트 전반에서 이를 기억합니다.
지식을 사용하면 Lovable 에이전트에 지속적인 지침과 컨텍스트를 제공할 수 있습니다. 매번 대화에서 같은 설명을 반복하는 대신, 한 번 정의하면 Lovable이 편집을 생성할 때 이를 참고합니다.
지식은 두 가지 수준에서 정의됩니다:
- 워크스페이스 지식은 코딩 표준, 선호 라이브러리, 네이밍 규칙 등 워크스페이스 내 모든 프로젝트에 적용되는 공유 규칙을 정의합니다.
- 프로젝트 지식은 애플리케이션 목적, 데이터베이스 스키마, 아키텍처 결정, 도메인 용어 등 단일 프로젝트에 특화된 컨텍스트를 추가합니다.
둘 다 Lovable 에이전트에 지속적인 지침을 제공하는 일반 텍스트 필드입니다.
워크스페이스 지식
워크스페이스 지식은 공유 규칙을 한 번 정의하고 워크스페이스 내 모든 프로젝트에 적용할 수 있는 텍스트 필드입니다. 프로젝트 지식은 특정 프로젝트에 한정된 컨텍스트를 추가할 수 있습니다.
여러 프로젝트에서 일관되어야 하는 규칙과 규칙에 가장 적합합니다. 이러한 가이드라인을 한 번 정의하면 모든 프로젝트의 지식 필드에서 같은 지침을 반복할 필요가 없습니다.
워크스페이스 지식은 여러 사람이 프로젝트를 빌드하는 팀 환경에서 특히 유용합니다. 워크스페이스 관리자가 코딩 표준, 테스트 요구사항, 아키텍처 규칙 등의 가이드라인을 정의하면 모든 프로젝트가 자동으로 동일한 규칙을 따릅니다.
워크스페이스 소유자와 관리자만 워크스페이스 지식을 관리할 수 있습니다. 워크스페이스 지식을 관리하려면 다음 중 하나로 이동하세요:
- Settings → Knowledge
- Project settings → Knowledge
워크스페이스 지식은 최대 10,000자를 지원합니다.
포함할 내용
워크스페이스 지식에 적합한 항목:
- 코딩 스타일 규칙
- 네이밍 규칙
- 선호 라이브러리 또는 프레임워크
- 공유 아키텍처 패턴
- 테스트 요구사항
- 코드 품질 또는 린팅 규칙
- 언어 또는 포맷팅 선호도
- 브랜드 보이스, UI 카피, 디자인 가이드라인
- Lovable이 하지 말아야 할 것들
예시
Coding standards
- Always enable TypeScript strict mode.
- Never use `any`. Use `unknown` and narrow the type.
- Prefer named exports. Do not use default exports.
- Prefer `const` over `let`. Never use `var`.
Naming conventions
- Use camelCase for variables and functions.
- Use PascalCase for components and types.
- Use kebab-case for file names.
Styling
- Use Tailwind CSS for styling.
- Do not use inline styles.
- Do not use CSS modules.
Libraries
- Use shadcn/ui components when possible.
- Use React Query for server state.
- Use Zustand for client state.
Architecture
- Route API calls through a service layer.
- Do not call `fetch` directly from React components.
Testing
- Write unit tests for new utility functions and hooks.
- Run existing tests after making changes.
- Verify new functionality in the browser before marking it complete.
Code quality
- Run the linter after significant changes.
- Remove unused imports and dead code.
Localization
- Write code comments and variable names in English.
- Use date format DD/MM/YYYY.
- Use European number formatting (comma as decimal separator).
Brand voice
- Use a friendly, professional tone in all user-facing copy.
- Use sentence case for headings and buttons (for example, "Create new project", not "Create New Project").
- Do not use placeholder text like "Lorem ipsum", always write realistic copy.
General rules
- Do not add `console.log` statements.
- Do not use deprecated React patterns.
- Write code comments in English.중요 참고사항
- 변경 사항은 즉시 적용됩니다
활성 대화 중에 워크스페이스 지식을 업데이트하면 Lovable이 후속 메시지에서 업데이트된 지침을 사용합니다. - 워크스페이스당 하나의 워크스페이스 지식
각 워크스페이스에는 모든 프로젝트에서 공유되는 단일 워크스페이스 지식이 있습니다. 같은 워크스페이스 내 프로젝트 하위 그룹에 대해 다른 워크스페이스 수준 지침을 정의할 수 없습니다. - 긴 대화에서의 워크스페이스 지식
워크스페이스 지식은 항상 프로젝트 지식, 프로젝트 코드 및 기타 컨텍스트 소스와 함께 포함됩니다. 그러나 컨텍스트가 매우 많은 긴 대화에서는 지침이 항상 일관되게 따르지 않을 수 있습니다.
프로젝트 지식
프로젝트 지식은 단일 프로젝트에 대한 지속적인 지침과 컨텍스트를 저장하는 텍스트 필드입니다. 애플리케이션 목적, 아키텍처, 도메인 용어 등 해당 프로젝트에만 적용되는 정보를 제공하는 데 사용하세요.
프로젝트 편집 권한이 있는 모든 사람이 프로젝트 지식을 업데이트할 수 있습니다. 프로젝트 지식을 관리하려면 Project settings → Knowledge로 이동하세요.
프로젝트 지식은 최대 10,000자를 지원합니다.
포함할 내용
좋은 프로젝트 지식에는 일반적으로 다음이 포함됩니다:
- 애플리케이션이 하는 일
- 사용자 페르소나 또는 타겟 사용자
- 데이터베이스 스키마 또는 주요 테이블
- 아키텍처 결정
- 도메인 용어
- 프로젝트별 제약 조건
- 디자인 가이드라인(색상, 타이포그래피, 레이아웃)
- API 문서나 내부 도구 등 중요한 참조 링크
- 보안 또는 규정 준수 요구사항
예시
Project overview
This is a B2B SaaS application for restaurant managers to track food inventory across multiple locations.
Users
Primary users are restaurant managers who need quick visibility into stock levels and ingredient usage.
Secondary users are staff responsible for logging inventory changes.
Key database tables
- inventory_items (id, name, category, quantity, unit, location_id)
- locations (id, name, workspace_id)
- transactions (id, item_id, quantity_change, type, created_at)
Design guidelines
- Use Tailwind CSS for styling.
- Follow the existing color palette and spacing scale.
- Use consistent spacing and layout patterns across pages.
- Prefer shadcn/ui components when available.
Architecture rules
- Store monetary values in cents as integers.
- Use optimistic updates for all mutations.
- Place reusable components in /components.
Domain terminology
- "Inventory item" refers to a tracked ingredient or product.
- "Transaction" represents a change in inventory quantity.
External references
- API documentation: https://docs.example.com/api