Lore Board 파이프라인

lore-ai 패키지는 대시보드를 직접 포함하지 않습니다. 대신 Lore Board 라는 별도 Next.js 앱이 회사 단일 위키 역할을 합니다.

한 장 그림

┌──────────────────┐  @tag  ┌─────────────┐  publish   ┌──────────────────┐
│ source repo A    │ ────▶  │  lore CLI   │ ────────▶  │  lore-board      │
│ (Django)         │        │  .lore/flows│            │  content/        │
└──────────────────┘        └─────────────┘            │   projects/A/    │
┌──────────────────┐                                   │   projects/B/    │
│ source repo B    │ @tag                              │   handbook/      │
│ (RN Expo)        │ ────▶  ──┐                        └──────────────────┘
└──────────────────┘          │                                   │
                              └────────────────────────────────────┘
                                   같은 패턴, --target 만 동일

새 프로젝트 등록 (코드 수정 없음)

1. 소스 레포에서 lore init → lore.config.yaml 의 publish.project 를 원하는 slug 로
2. 어노테이션 작성 → lore check → lore sync
3. 첫 lore publish → content/projects/<slug>/flows/ 가 채워짐
4. Lore Board 의 content/projects.json 에 한 항목 append:

   { "slug": "foodcook", "name": "식자재쿡", "icon": "🍚", "order": 2, "status": "draft" }
5. (권한 시스템 도입 후) Django User.projects 에 slug 부여

보호 경로

lore publish 는 다음을 절대 덮어쓰지 않습니다:

• content/handbook/** — HR/운영팀이 손수 관리
• content/projects.json — 사람이 직접 편집

기본 설정은 publish.skipPaths 에 정의되어 있습니다 (reference/config 참고).

서버·앱 분리 저장소

백엔드와 프론트엔드가 별도 git 저장소로 분리되어 있으면 lore init 을 한 번 할지 두 번 할지, publish 충돌을 어떻게 피할지 결정해야 합니다. 세 가지 운영 모델 (모노레포 / 도메인 분리 / 워크스페이스 가짜 저장소) 의 비교는 Multi-repo 가이드 참고.

자체 호스팅 옵션

Lore Board 가 과한 경우 (단일 OSS 프로젝트 등), 패키지에 포함될 예정인 셀프호스트 fallback 을 사용할 수 있습니다 (v1+).

lore dashboard
# → http://localhost:4321