MoringDocs
대시보드
Morit Plugin1. 시작과 개발 흐름

Morit Plugin 개발 문서

이 문서는 아이디어를 실제 설치 가능한 .mplg로 만드는 순서대로 구성되어 있습니다. 플러그인은 실행 코드를 앱에 직접 주입하지 않습니다. Manifest와 JSON fragment로 기능·화면·권한을 선언하고, Morit Host가 서명과 계약을 확인한 뒤 공용 런타임으로 실행합니다.

가장 짧은 개발 경로

text
요구사항 정리
  → 프로젝트 생성
  → manifest와 기능 fragment 작성
  → 화면·상태·내비게이션 작성
  → 권한·설정·알림 연결
  → validate
  → preview
  → build
  → verify
  → 실제 앱 설치·실사용 테스트
  → deploy

공식 CLI를 사용하는 기본 명령은 다음과 같습니다.

bash
npx -y @morit/cli plugin setup . \
  --id com.example.study \
  --name "Study" \
  --publisher example
npx -y @morit/cli plugin validate .
npx -y @morit/cli plugin preview . --output ./dist/preview.html
npx -y @morit/cli plugin build .
npx -y @morit/cli login
npx -y @morit/cli plugin add .
npx -y @morit/cli plugin deploy . --visibility private

preview는 공식 CLI와 Local/Remote Plugin MCP의 morit_project_preview에서 만들 수 있습니다. preview로 계약과 배치를 확인하고, 실제 Flutter focus·navigation·Tool 흐름은 앱에서도 확인합니다.

개발 순서별 인덱스

1. 시작과 개발 흐름

  1. 시작하기와 개발 흐름 — 개발 방식 선택, 첫 프로젝트, 완료 조건
  2. 앱에서 플러그인 만들기 — 단순 Tool을 앱 Builder로 만드는 범위

2. 프로젝트와 계약

  1. 프로젝트 구조와 fragment — 디렉터리, 병합 규칙, 패키지 포함 파일
  2. Manifest 레퍼런스 — ID, 버전, capability, connector, dependency
  3. Instance, Connector, 복합 패키지 — 사용자별 실행 단위와 계정 연결

3. 화면과 사용자 경험

  1. 화면, 레이아웃, 내비게이션 — 화면 역할과 이동 구조
  2. 기본·커스텀 컴포넌트 — 각 node의 목적, 속성, 제약
  3. 토큰, 크기, 색, 여백, 반응형 — Material 3 기반 시각 규칙
  4. 화면 분리와 정보 계층 — 한 화면에 정보를 몰지 않는 설계
  5. UI extension point — Host의 어느 위치에 UI를 노출할지 선택
  6. UI Runtime v3와 Morit Script — script, state, data, repeat, responsive UI
  7. UI Runtime v2 레퍼런스 — 기존 JSON-only 플러그인 호환 계약
  8. Response UI와 Agent Timeline — AI 메시지 안의 결과 UI
  9. Morit Script 레퍼런스 — 문법, 내장 함수, 한도

4. 기능, 데이터, 사용자 제어

  1. Tool, Skill, Search, Slash Command — capability와 runtime adapter
  2. 권한, 설정, 저장소, 알림 — 최소 권한과 Host action
  3. Plugin Local Storage와 AI 접근 — namespace, CRUD, migration, 격리, AI Tool
  4. 외부 서비스 인증과 Cloud Secrets — OAuth, API key, 비밀 값 경계
  5. AI Skill과 파일 산출물 — 실제 파일을 반환하는 완료 흐름

5. 플랫폼

  1. 지원 플랫폼 — Android 전용 지원과 플랫폼 중립 작성 원칙

6. 검증과 배포

  1. 공식 CLI 개발 흐름 — setup, sync, preview, build, deploy
  2. 패키징과 테스트 — 서명, 무결성, 테스트 층
  3. 오류 해결 — validate, preview, build, 설치, 실행 오류 구분
  4. 검증 기록과 경계 — 자동·live·실기기 검증의 차이

7. SDK, MCP, API

  1. CLI와 AI 에이전트 MCP — Codex·Claude 등 로컬/원격 연결
  2. 원격 Plugin MCP — Cloud Project를 다루는 Tool 계약
  3. 수명주기와 HTTP API — Host API와 설치·실행 상태

8. 예제

  1. Runtime v3 예제: 날짜별 학교생활 — manifest, Morit Script, runtime-test, build
  2. UI 디자인 예제 4종 (Runtime v2) — 검색, 목록, 대시보드, AI 결과 화면

문서 배포 절차

이 디렉터리의 MDX가 canonical 원본입니다. Local·Remote Plugin MCP는 /api/docs/morit-plugin을 ETag로 갱신하고 마지막 정상 응답을 cache하므로 npm package나 서비스 image에 문서 사본을 넣지 않습니다.

문서를 배포할 때는 다음 순서를 지킵니다.

  1. MDX 검증과 production build를 통과시킵니다.
  2. Vercel preview의 문서 API가 200, 비어 있지 않은 전체 문서, ETag을 반환하는지 확인합니다.
  3. 같은 ETag의 If-None-Match 요청이 304인지 확인합니다.
  4. Local Node MCP와 Remote Python MCP의 search/get을 preview 응답으로 확인합니다.
  5. 검증한 정확한 preview deployment를 production으로 승격합니다.
  6. public production URL에서 200/304와 두 MCP client를 다시 확인한 뒤 Remote MCP와 npm package를 순서대로 배포합니다.

canonical endpoint가 배포되기 전에 이를 기본값으로 사용하는 MCP를 먼저 배포하지 않습니다. 일시적 장애에는 cache를 사용하지만, 첫 요청부터 endpoint를 사용할 수 없으면 문서 Tool만 명확한 재시도 가능 오류를 반환해야 합니다.