작가가 직접 채울 빈 작품 기반(world/setting.md, 빈 chapters·summaries·characters 디렉터리, .vibelore/foundation.json)을 만들거나, world/setting.md가 이미 있는 디렉터리를 쓰기 없이 이어받는다. 모델이 세계·인물을 자동 설계하게 하려면 이 도구 대신 lore_profile → lore_profile_decide → lore_create를 쓴다. lore_create는 기반이 있으면 거부하므로 둘 중 하나만 쓴다. 새 작품은 언어 계약 검증 때문에 보통 status=needs_model을 한 번 돌려주며 lore_resume으로 답해야 저장된다. 재호출은 덮어쓰지 않고 adopted=true와 현재 상태를 돌려준다.

작품 전체 진행 요약을 읽기 전용으로 조회한다. 게시된 정본(Published HEAD) 기준 화수·다음 화 번호·등장인물·세계 사실 수·미해결 떡밥·아크 진행·StoryProfile 상태와, 손수정 여부를 뜻하는 workingTree(clean·modified 등)를 돌려준다. 작품이 없으면 오류 대신 initialized=false를 돌려준다. 진행 중인 한 화의 단계는 lore_workflow_status, 설정 누락 점검은 lore_configure, 개별 계획 내용은 lore_*_status로 본다. workingTree가 clean이 아니면 집필 전에 lore_sync를 호출한다.

작품 설정을 조회하거나 바꾼다. 인자 없이 호출하면 읽기 전용으로 StoryProfile·StorySpine·WriterSkill을 하나의 NarrativeContract로 묶어 status(ready|incomplete), 누락 단계(missing), 언어·분량 계약, 검토·추적 설정을 돌려준다. disabledReviews·disabledDraftSections·tracking·customTracking·mergeRecords 중 하나라도 넘기면 .vibelore/review-policy.json에 저장한다. 목록과 tracking 객체는 통째로 교체되고(빈 배열=모두 켬), mergeRecords만 누적된다. 변경은 다음 커밋부터 적용되며 이미 쓴 화는 바뀌지 않는다. 모델 호출 없음.

사용자가 좋다고 승인한 정본 1~3화를 작품의 문체 기준으로 고정하거나 현재 기준을 조회한다. 자동으로 최신 화를 기준으로 삼지 않으므로 사용자가 특정 화를 좋다고 말했을 때만 approve한다. action=status(기본)는 읽기 전용이고 기준이 없으면 status=missing. approve는 .vibelore/style-anchor.json의 이전 기준을 새 기준으로 교체하고 {status:active, anchor(revision·발췌·기준 지문)}를 돌려준다. 모델 호출 없음. 초고 요청에서 기준 예시를 빼려면 lore_configure의 disabledDraftSections에 style-anchor를 넣는다.

Published HEAD 이후 사람이 world/·characters/·chapters/에서 직접 고친 Markdown을 정본에 반영한다. lore_status나 lore_write가 working-tree drift(needs_sync)를 보고하면 집필 전에 이 도구를 쓴다. 공백만 바뀐 편집은 무시한다. 3단계 승인 흐름: inspect(기본)는 변경을 분류만 한다(기준 지문 갱신 외 쓰기 없음). validate는 마지막 화 손수정이면 재검사(모델 작업→needs_model→lore_resume), 세계·인물 변경이면 바뀐 항목과 영향받는 계획을 보여 주고 approvalId를 발급한다. apply는 그 approvalId로 새 정본을 게시한다. approvalId는 한 번만 쓸 수 있고 validate 이후 파일이 또 바뀌면 STALE_SYNC_CANDIDATE로 거부된다. 이전 화 손수정은 반영하지 않으므로(rewrite_refold_required) 되돌려야 한다.

새 작품의 기반을 모델이 자동 설계한다: 세계 사실, 3~5인 캐스트(characters/.md), 추적 엔티티를 만들어 world/setting.md와 .vibelore/에 저장한다. 보통 lore_profile → lore_profile_decide(approve) 다음에 호출하며, 그러면 StoryProfile의 엔진 장르·시점·언어·분량을 따른다. StoryProfile 없이 genre만으로도 호출할 수 있다. 직접 쓴 설정으로 시작하려면 lore_init을 쓴다. 이미 기반이 있으면 덮어쓰지 않고 거부하며, StoryProfile이 있는데 승인 전이면 거부한다. 세계·캐스트·엔티티·언어 검증마다 status=needs_model을 돌려주므로 lore_resume을 여러 번 이어야 하고, 모두 끝나기 전에는 아무 파일도 저장하지 않는다. 성공하면 {created:true, genre, language, length, worldFacts(개수), characters[{id,name,contradiction}], entities[{id,kind,name}]}. 다음 단계는 lore_story_plan.

새 작품 설계의 첫 단계. 작품 발견 인터뷰의 브리프를 StoryProfile(엔진 장르·독서 계약·읽기 난도·이야기 동력·시점·문체 지침·언어·분량)로 컴파일해 .vibelore/story-profile.json에 저장한다. review 결과의 designReview에는 누적된 설계 결정과 최대 5개의 열린 질문이 담긴다. 질문을 사용자에게 모두 보여 주고 답을 feedback으로 넘겨 다시 호출하며, 열린 질문이 없거나 사용자가 승인하면 lore_profile_decide로 확정한다. 호출할 때마다 모델이 새로 생성해 기존 프로필을 교체한다(active였어도 review면 pending으로 돌아가 이후 단계가 막힌다). 생성과 언어 검증에 status=needs_model이 1~3회 나오며 lore_resume으로 답하기 전에는 저장하지 않는다. 기반 생성 뒤에는 언어를 바꿀 수 없다.

lore_profile이 만든 StoryProfile을 승인(active)하거나 거절(rejected)한다. 승인은 사용자가 현재 설계를 명시적으로 받아들였거나 열린 질문이 없을 때만 한다. 승인하면 읽기 난도 계약도 사용자 확인으로 기록된다. 모델 호출 없음. 프로필이 없으면 오류. 반환은 {approved, profile, instruction?}. 승인 뒤 lore_create(새 작품) 또는 lore_story_plan(기반이 이미 있을 때)으로 진행한다.

StoryProfile만 읽기 전용으로 조회한다. 없으면 {profiled:false}, 있으면 {profiled:true, profile(status: pending|active|rejected, designReview 포함), language, length}. 새 작품을 시작하기 전에 프로필이 필요한지 판단할 때 쓴다. 작품 전체 진행은 lore_status, 설정 누락 점검은 lore_configure를 쓴다.

작품 전체 StorySpine(처음부터 결말까지의 인과 사슬, 인물 동력, 중간 재해석, 최종 선택의 대가)을 생성하고 구조·품질 검증을 거쳐 .vibelore/story-spine.json과 world/story-spine.md에 저장한다. 순서는 lore_create 다음, lore_writer_skill 앞이며 기반과 승인된 StoryProfile이 필요하다. 아크 단위 계획은 lore_arc_plan이 따로 만든다. 호출할 때마다 기존 StorySpine을 이력 없이 교체한다(review면 pending으로 돌아가 이후 단계가 막힌다). 생성·품질 판정·언어 검증에 status=needs_model이 약 3회 나오며 모두 답하기 전에는 저장하지 않는다. 검증에 떨어지면 오류로 끝나고 저장하지 않는다. 반환은 {spine(quality 포함), needsApproval}.

lore_story_plan이 만든 StorySpine을 승인(active)하거나 거절(rejected)한다. 사용자가 StorySpine 내용을 보고 결정한 뒤 호출한다. 모델 호출 없음. StorySpine이 없으면 오류. 반환은 {approved, spine}. 승인 뒤 다음 단계는 lore_writer_skill.

StorySpine만 읽기 전용으로 조회한다. 없으면 {planned:false}, 있으면 {planned:true, spine(status: pending|active|rejected, 인과 사슬·인물 동력·quality)}. 아크 계획은 lore_arc_status, 작품 전체 진행은 lore_status로 본다.

이 작품을 쓸 WriterSkill(장면 판단·정보 지연·보상 지급·반복 고착 방지 방식)을 서로 다른 후보 3개로 만들고, 후보별 짧은 산문 오디션을 판정 모델이 비교해 하나를 고른다. 표면 문체가 아니라 서술 판단을 설계한다. 순서는 lore_story_decide(approve) 다음, lore_arc_plan 앞이며 기반과 승인된 StorySpine이 필요하다. 문체 예시를 고정하는 lore_style_anchor와는 다르다. 호출할 때마다 기존 WriterSkill을 이력 없이 교체해 .vibelore/writer-skill.json과 world/writer-skill.md에 저장한다. 후보 생성·오디션 판정·언어 검증에 status=needs_model이 약 3회 나온다. 반환은 {skill(선택 후보와 점수), candidates, needsApproval}.

lore_writer_skill이 오디션으로 고른 WriterSkill을 승인(active)하거나 거절(rejected)한다. 다른 후보로 바꾸는 기능은 없으므로 원하지 않으면 거절 후 feedback과 함께 다시 생성한다. 모델 호출 없음. WriterSkill이 없으면 오류. 반환은 {approved, skill}. 승인 뒤 다음 단계는 lore_arc_plan.

WriterSkill만 읽기 전용으로 조회한다. 없으면 {planned:false}, 있으면 {planned:true, skill(status: pending|active|rejected, 선택 후보, 후보 3개와 오디션 산문·점수)}. 사용자에게 오디션 결과를 보여 줄 때 쓴다. 문체 기준 예시는 lore_style_anchor, 작품 전체 진행은 lore_status로 본다.

다음 아크의 약속과 3~20개 얇은 회차 비트(사건·압력·전환·다음 상태)를 생성하고 구조·품질 검증을 거쳐 .vibelore/arc-plan.json에 저장한다(아크별 사본은 .vibelore/arcs/). lore_write 전에 lore_arc_status로 활성 아크가 없음을 확인했을 때, 또는 아크가 끝났을 때 호출한다. 기반과 승인된 StoryProfile·StorySpine·WriterSkill이 필요하다. pending 계획은 같은 번호로 교체한다. 활성 아크는 ARC_IN_PROGRESS로 거부한다. 사용자가 교체를 명시적으로 요청한 경우에만 replaceActive=true로 다음 번호의 아크로 교체한다. 생성·품질 판정·언어 검증에 status=needs_model이 약 3회 나온다. 반환은 {plan(episodes, quality), needsApproval, instruction}.

lore_arc_plan이 만든 아크 계획을 승인해 활성화하거나 거절한다. 사용자가 계획을 보고 결정한 뒤 호출한다. 활성 아크가 있어야 lore_write가 집필할 수 있고, 활성 아크를 거절하면 lore_write가 ARC_NOT_ACTIVE로 멈춘다. 생성 뒤 새 화가 게시됐으면 승인이 status=clean_fail(STALE_VALIDATION_RECEIPT)로 거부되므로 다시 계획한다. 모델 호출 없음. 반환은 {approved, plan, instruction?}.

현재 아크 계획을 읽기 전용으로 조회한다. 집필 요청을 받으면 가장 먼저 호출해 활성 아크가 있는지 확인한다. 없으면 {planned:false}, 있으면 {planned:true, plan(status: pending|active|rejected|completed, episodes), nextChapter, currentEpisode}. currentEpisode는 활성 아크에 다음 화 비트가 있을 때만 채워지며, null이면 lore_arc_plan이 필요하다.

현재 아크에서 이미 쓴 화들을 5화 단위 체크포인트 또는 종결화까지 다시 읽고, 화별 PatternLedger와 아크 품질 리뷰(7개 차원 점수·발견 사항)를 새로 만든다. lore_write가 체크포인트마다 같은 리뷰를 자동으로 하므로 선택 도구이며, 리뷰를 수동으로 갱신하거나 다시 보고 싶을 때만 쓴다. 결과는 advisory이고 원고를 고치지 않는다. .vibelore/experience-ledger.json·pattern-ledger.json과 arc-reviews/를 덮어쓴다. 화마다 한 번, 마지막에 한 번 status=needs_model이 나온다(N+1회). 체크포인트가 아닌 화나 본문이 없는 화를 지정하면 오류.

lore_rollback으로 되돌아갈 수 있는 화 번호 목록을 읽기 전용으로 조회한다. 스냅숏은 커밋할 때마다 .vibelore/snapshots/<화>/에 자동 생성되며 같은 화를 다시 커밋하면 교체된다. 반환은 {snapshots:[화 번호 오름차순]}이며 생성 시각 같은 상세는 없다. 롤백 전에 대상 화가 있는지 확인할 때 쓴다.

지정 화의 스냅숏으로 정본과 기계 상태를 되돌린다. 사용자가 이미 커밋된 화들을 취소하겠다고 명시했을 때만 호출하고, 먼저 lore_snapshot_status로 대상 화를 확인한다. 손수정 반영은 lore_sync를 쓴다. 파괴적: world/·characters/·chapters/·summaries/를 지우고 스냅숏으로 복원하므로 그 화 이후 원고가 작업 트리에서 사라진다. 진행 중인 워크플로, 대기 중인 lore_resume runId, 검사 영수증도 지워지고 이후의 lore_configure·lore_style_anchor 변경도 되돌아간다. 되돌리기 전 상태는 .vibelore/rollback-archives//에 보존되지만 복원 도구는 없어 수동으로 되살려야 한다. 모델 호출 없음. 반환은 {rolledBackTo, archiveId, archive, recoverable:true, publication}.

status=needs_model 로 중단된 작업을 이어받는다. requests 의 각 질문에 답한 텍스트를 answers 에 { id: 답변 } 형태로 넘기면 중단 지점부터 계속한다. 한 응답의 requests는 서로 독립이므로 모두 답해 한 번에 넘긴다. 원래 도구를 처음 받은 인자 그대로 다시 실행하므로 인자를 바꾸려면 원래 도구를 새로 호출한다. 재개된 도구의 부작용(저장·교체·커밋)을 그대로 가진다. 다음 단계에 새 모델 작업이 필요하면 새 requests와 함께 needs_model을 다시 돌려주므로 여러 번 이어지는 것이 정상이다. 빈 answers나 맞지 않는 id는 작업을 끝내지 않고 같은 requests를 다시 돌려준다. runId는 첫 생성 후 24시간 뒤 만료되고 완료되면 삭제된다. 답을 멈추면 소설·설계 도구는 needs_model 응답의 deterministicResult가 유일한 결과이고(lore_write는 멈춘 workflow 식별 정보뿐이며 awaiting_model로 남는다), 웹툰은 같은 단계에서 대기하며 lore_workflow_status(lane=webtoon)로 확인한다.

다음 화의 계획 확인부터 원본 초고 프롬프트, 의미·논리 검사(최대 3회, 그 사이 최소 수정 최대 2회), 검사 영수증, 승인·커밋까지 순서대로 실행하는 기본 집필 도구다. 소설을 이어 쓸 때는 이 도구만 호출한다. 항상 마지막 화의 다음 화를 쓰며 기존 화를 덮어쓰지 않는다. 같은 화의 진행 중 워크플로가 있으면 새로 만들지 않고 이어간다. 모델 작업마다 status=needs_model을 돌려주므로 lore_resume으로 답한다. 준비가 덜 됐으면 status=needs_setup(FOUNDATION_MISSING·PROFILE_NOT_ACTIVE·STORY_SPINE_NOT_ACTIVE·WRITER_SKILL_NOT_ACTIVE·ARC_NOT_ACTIVE), 손수정이 있으면 needs_sync(→lore_sync)를 돌려준다. guided는 검사를 마친 원고를 status=awaiting_approval과 approvalId로 돌려주며 lore_decide로 결정한다. auto는 검사를 통과하면 chapters/·summaries/·상태·스냅숏을 커밋하고 status=completed를 돌려준다. 실패는 clean_fail·validation_incomplete·provider_error.

lore_write가 guided 모드에서 status=awaiting_approval로 돌려준 원고에 대한 사용자 결정을 적용한다. 사용자에게 원고와 advisory를 보여 주고 답을 받은 뒤에만 호출한다. approve는 검사 영수증을 다시 확인하고 그 화를 커밋한다(chapters/·summaries/·상태·스냅숏, status=completed). request_revision은 feedback대로 같은 워크플로에서 고치게 하며 다음 lore_write가 수정·재검사한다. hold는 기록만 남기고 승인 대기를 유지한다. reject는 워크플로를 끝내며 다음 lore_write가 같은 화를 새로 쓴다. 원고 파일은 지우지 않는다. approvalId는 원고가 승인 대기에 다시 들어갈 때마다 새로 발급되므로 이전 id는 거부된다.

진행 중인 한 화(또는 웹툰 장면) 워크플로의 현재 단계, 시도 횟수, 다음 행동과 품질 결과를 읽기 전용으로 조회한다. 작품 전체 진행은 lore_status, 지난 이벤트는 lore_workflow_history를 쓴다. 소설은 {active, workflow(원고 본문 제외), resume?}를 돌려주며 워크플로가 없으면 {active:false}. 모델 응답 대기 중이면 resume.runId로 lore_resume을 이어갈 수 있다. lane=webtoon은 현재 웹툰 워크플로 상태를 돌려주며 status가 곧 단계다.

워크플로의 감사 이력(단계 전환·검토 발견·승인·커밋 이벤트)을 읽기 전용으로 조회한다. 현재 상태만 필요하면 lore_workflow_status를 쓴다. 반환은 {found, workflowId, events, modelExchanges?}. includeModelExchanges=true이면 선택된 이벤트의 실제 모델 요청과 응답 전문까지 돌려주므로 응답이 커진다. 대체된 이전 워크플로도 id로 조회할 수 있다.

기본 웹툰 제작 경로. 소설 정본의 한 장면을 대사가 작품 언어 원문으로 들어간 이미지 한 장으로 만든다. 원작→영어 장면 연출→생성 전 검증→문자 포함 장면 이미지→실제 시각 검토 순서이며 컷 배치와 카메라는 이미지 모델에 맡긴다. 호출 전에 webtoon-discovery-interview로 원작 범위·화풍·참조·칸 수·이미지 모델을 사용자와 정한다. 서버는 이미지를 직접 생성하지 않는다: needs_scene_image일 때 jobs의 요청을 호스트가 사용자가 고른 경로(hostRequest=호스트 내장 도구, apiRequest=API·별도 과금)로 실행하고 결과 파일을 asset으로 넘긴다. 선택이 없는 작품은 start가 needs_image_runtime으로 호스트의 실제 이미지 경로 보고(imageRuntime)를 받고, needs_image_choice로 선택지 전체를 사용자에게 보여 확정한다(내장 경로를 먼저 제안). 확정한 선택은 changeImageChoice로 바꾸기 전까지 재사용한다. 모델 단계(연출·검증·시각 검토)는 needs_model→lore_resume, 칸 수가 없으면 needs_interview. 상태는 .vibelore/webtoon/에 저장하고 소설 정본과 프로젝트 webtoon/ 폴더는 건드리지 않는다. 진행 중 워크플로가 있으면 start는 WEBTOON_WORKFLOW_ACTIVE로 거부되므로 revise나 retry로 끝낸다. 시각 검토를 통과하면 status=completed. 기존 컷별 workflow는 변경하지 않는다.