@litfamily/litopencode 1.0.29 → 1.0.30

package/dist/v2/tui.js

@@ -0,0 +1,259 @@
+// LitOpenCode's OpenCode 2 TUI plugin: the mission panel in the session sidebar, the ignition line under
+// the prompt (`🔥 LIT IGNITED · <discipline>`, the OpenCode 2 home of the OpenCode 1 completion mark),
+// and toasts. OpenCode 2 loads it on its own for an active server plugin. The server cannot raise toasts
+// on OpenCode 2, so the ignition toast is inferred here from the lit mark the server writes into the user
+// message metadata. It only reads state. OpenTUI and Solid come from the host at run time; tests pass a
+// stand-in runtime.
+import { activationDiscipline } from "../activation-probe.js";
+import { micro, supportsMarkGlyphs } from "../lit-mark.js";
+import { buildMissionView, leadingNotice, missionNotices } from "../tui/mission-model.js";
+import { idleMotion, motionTiming, planMotion, sampleMotion } from "../tui/mission-motion.js";
+import { latestLitMarkV2, missionStateFromV2 } from "../tui/mission-source-v2.js";
+import { createLedgerReader, createWorkReader, missionProjectRoot, readLatestResearchRun, readMissionInput } from "../tui/mission-source.js";
+import { missionPanel, paletteFromTheme, panelWidth } from "../tui/mission-text.js";
+const refreshDelayMs = 80;
+const ledgerPollMs = 2000;
+const toastMs = 4000;
+const ignitionToastMs = 6000;
+const trackedSessionLimit = 4;
+// A lit mark older than the moment a session is first drawn is history being loaded, not a new turn.
+const historySlackMs = 2000;
+async function hostRuntime() {
+    const [jsxRuntime, solid] = await Promise.all([import("@opentui/solid/jsx-runtime"), import("solid-js")]);
+    return { jsx: jsxRuntime.jsx, createSignal: solid.createSignal, createEffect: solid.createEffect, createRoot: solid.createRoot };
+}
+/** OpenCode 2 theme tokens under the names the mission palette reads. */
+export function paletteFromV2Theme(theme, mode) {
+    const tokens = (typeof theme === "object" && theme !== null ? theme : {});
+    return paletteFromTheme({
+        text: tokens.text?.base,
+        textMuted: tokens.text?.muted,
+        borderActive: tokens.border?.base,
+        borderSubtle: tokens.border?.base,
+        background: tokens.background?.base,
+        backgroundPanel: tokens.background?.raised?.base,
+        backgroundElement: tokens.background?.raised?.high
+    }, mode);
+}
+export function ignitionLine(name) {
+    return `🔥 LIT IGNITED · ${activationDiscipline(name)}`;
+}
+export async function setupLitOpenCodeTui(context, runtime) {
+    const ui = runtime ?? await hostRuntime();
+    const [settings] = context.storage.store("settings", { initial: { motion: true } });
+    const motionEnabled = settings.motion !== false;
+    const directory = context.location?.directory ?? context.data.location.default().directory;
+    const root = missionProjectRoot({ directory });
+    const readLedger = createLedgerReader();
+    const readWork = createWorkReader();
+    const sessions = new Map();
+    const ignitions = new Map();
+    const trackedAt = new Map();
+    const tracked = [];
+    // Each session's store watcher lives in its own root, so it outlasts the slot render that started it
+    // and ends only on eviction or cleanup. After cleanup nothing may arm a timer again.
+    const watchers = new Map();
+    let disposed = false;
+    const [revision, setRevision] = ui.createSignal(0);
+    const [clock, setClock] = ui.createSignal(Date.now());
+    let frameTimer;
+    let refreshTimer;
+    let pollTimer;
+    const palette = () => paletteFromV2Theme(context.theme, context.themeMode);
+    function span(segment) {
+        return ui.jsx("span", {
+            style: { fg: segment.fg, ...(segment.bg === undefined ? {} : { bg: segment.bg }), ...(segment.bold === true ? { bold: true } : {}) },
+            children: segment.text
+        });
+    }
+    function line(segments) {
+        return ui.jsx("text", { wrapMode: "none", children: segments.length === 0 ? " " : segments.map(span) });
+    }
+    function viewFor(sessionID, now) {
+        const source = missionStateFromV2(context.data, directory);
+        const records = { work: readWork(root, sessionID), research: readLatestResearchRun(root) };
+        return buildMissionView(readMissionInput(source, sessionID, readLedger(root), now, {
+            ...(records.work === undefined ? {} : { work: records.work }),
+            ...(records.research === undefined ? {} : { research: records.research })
+        }));
+    }
+    function anyMoving(now) {
+        for (const entry of sessions.values())
+            if (sampleMotion(entry.motion, now).moving)
+                return true;
+        return false;
+    }
+    function ensureFrames() {
+        if (disposed || frameTimer !== undefined || !anyMoving(Date.now()))
+            return;
+        frameTimer = setInterval(() => {
+            const now = Date.now();
+            setClock(now);
+            if (!anyMoving(now)) {
+                clearInterval(frameTimer);
+                frameTimer = undefined;
+            }
+        }, motionTiming.frameMs);
+    }
+    function ignitionToast(sessionID, name) {
+        const label = `${ignitionLine(name)} 🔥`;
+        const message = supportsMarkGlyphs() ? [...micro.map((row) => row.replace(/ +$/u, "")), label].join("\n") : label;
+        context.ui.toast.show({ title: "🔥 LIT IGNITED", message, variant: "warning", duration: ignitionToastMs, sessionID });
+    }
+    function refresh(sessionID) {
+        if (disposed)
+            return;
+        const now = Date.now();
+        const mark = latestLitMarkV2(context.data, sessionID);
+        if (ignitions.get(sessionID) !== mark?.messageID) {
+            ignitions.set(sessionID, mark?.messageID);
+            if (mark !== undefined && mark.at >= (trackedAt.get(sessionID) ?? 0) - historySlackMs)
+                ignitionToast(sessionID, mark.name);
+        }
+        const next = viewFor(sessionID, now);
+        const entry = sessions.get(sessionID);
+        if (entry !== undefined && JSON.stringify(entry.view) === JSON.stringify(next))
+            return;
+        if (entry !== undefined) {
+            const notice = leadingNotice(missionNotices(entry.view, next));
+            if (notice !== undefined)
+                context.ui.toast.show({ variant: notice.variant, title: notice.title, message: notice.message, duration: toastMs, sessionID });
+        }
+        sessions.set(sessionID, { view: next, motion: planMotion(entry?.view, next, now, entry?.motion ?? idleMotion, motionEnabled) });
+        setClock(now);
+        setRevision(revision() + 1);
+        ensureFrames();
+    }
+    function syncPoll() {
+        if (disposed)
+            return;
+        const active = [...sessions.values()].some((entry) => entry.view.active);
+        if (active && pollTimer === undefined)
+            pollTimer = setInterval(refreshTracked, ledgerPollMs);
+        if (!active && pollTimer !== undefined) {
+            clearInterval(pollTimer);
+            pollTimer = undefined;
+        }
+    }
+    function refreshTracked() {
+        refreshTimer = undefined;
+        if (disposed)
+            return;
+        for (const sessionID of tracked)
+            refresh(sessionID);
+        syncPoll();
+    }
+    function scheduleRefresh() {
+        if (!disposed && refreshTimer === undefined)
+            refreshTimer = setTimeout(refreshTracked, refreshDelayMs);
+    }
+    // A session is tracked from its first render. Its existing history raises no toast; only a lit mark
+    // that appears after that does.
+    function track(sessionID) {
+        if (disposed || tracked.includes(sessionID))
+            return;
+        tracked.push(sessionID);
+        if (tracked.length > trackedSessionLimit) {
+            const dropped = tracked.shift() ?? "";
+            watchers.get(dropped)?.();
+            watchers.delete(dropped);
+            sessions.delete(dropped);
+            ignitions.delete(dropped);
+            trackedAt.delete(dropped);
+        }
+        const now = Date.now();
+        trackedAt.set(sessionID, now);
+        ignitions.set(sessionID, latestLitMarkV2(context.data, sessionID)?.messageID);
+        sessions.set(sessionID, { view: viewFor(sessionID, now), motion: idleMotion });
+        queueMicrotask(syncPoll);
+        // Opening a session loads its messages over HTTP, which raises no event. Reading the host's reactive
+        // store here re-runs this effect as they arrive, so a resumed session lights up too.
+        const dispose = ui.createRoot((release) => {
+            ui.createEffect(() => {
+                for (const message of context.data.session.message.list(sessionID) ?? [])
+                    void message.id;
+                void context.data.session.status(sessionID);
+                scheduleRefresh();
+            });
+            return release;
+        });
+        watchers.set(sessionID, dispose);
+    }
+    const unlisten = context.data.listen((event) => {
+        const type = event.details.type;
+        if (type.startsWith("session.") || type.startsWith("permission.") || type.startsWith("form."))
+            scheduleRefresh();
+    });
+    const releases = [
+        context.ui.slot({
+            append: "prompt.footer.status",
+            render(input) {
+                const sessionID = input.sessionID;
+                if (sessionID === undefined)
+                    return null;
+                track(sessionID);
+                return () => {
+                    revision();
+                    const mark = latestLitMarkV2(context.data, sessionID);
+                    if (mark === undefined)
+                        return null;
+                    return ui.jsx("box", {
+                        flexShrink: 0,
+                        children: line([{ text: ignitionLine(mark.name), fg: palette().primary, bold: true }])
+                    });
+                };
+            }
+        }),
+        context.ui.slot({
+            append: "sidebar.content",
+            render(input) {
+                track(input.sessionID);
+                return () => {
+                    revision();
+                    const entry = sessions.get(input.sessionID);
+                    if (entry === undefined || !entry.view.active)
+                        return null;
+                    const panel = missionPanel(entry.view, sampleMotion(entry.motion, clock()), palette());
+                    if (panel === undefined)
+                        return null;
+                    return ui.jsx("box", {
+                        border: true,
+                        borderStyle: "rounded",
+                        width: panelWidth,
+                        flexShrink: 0,
+                        flexDirection: "column",
+                        paddingLeft: 1,
+                        paddingRight: 1,
+                        titleAlignment: "left",
+                        bottomTitleAlignment: "right",
+                        borderColor: panel.border,
+                        title: panel.title,
+                        titleColor: panel.titleColor,
+                        bottomTitle: panel.bottomTitle ?? "",
+                        backgroundColor: panel.background ?? "transparent",
+                        children: panel.rows.map(line)
+                    });
+                };
+            }
+        })
+    ];
+    return async () => {
+        disposed = true;
+        for (const dispose of watchers.values())
+            dispose();
+        watchers.clear();
+        tracked.length = 0;
+        unlisten();
+        for (const release of releases)
+            release();
+        if (frameTimer !== undefined)
+            clearInterval(frameTimer);
+        if (refreshTimer !== undefined)
+            clearTimeout(refreshTimer);
+        if (pollTimer !== undefined)
+            clearInterval(pollTimer);
+        sessions.clear();
+        ignitions.clear();
+        trackedAt.clear();
+    };
+}

package/docs/assets/readme/badge-version.svg

@@ -1 +1 @@
-<svg xmlns="http://www.w3.org/2000/svg" width="146" height="20" role="img" aria-label="release: 1.0.29"><title>release: 1.0.29</title><g shape-rendering="crispEdges"><rect width="49" height="20" fill="#080d14"/><rect x="49" width="97" height="20" fill="#ff6337"/></g><g fill="#fff" text-anchor="middle" font-family="Verdana,Geneva,DejaVu Sans,sans-serif" text-rendering="geometricPrecision" font-size="110"><text x="255" y="140" textLength="390" transform="scale(.1)">release</text><text x="965" y="140" textLength="870" transform="scale(.1)" fill="#080D14">1.0.29</text></g></svg>
+<svg xmlns="http://www.w3.org/2000/svg" width="146" height="20" role="img" aria-label="release: 1.0.30"><title>release: 1.0.30</title><g shape-rendering="crispEdges"><rect width="49" height="20" fill="#080d14"/><rect x="49" width="97" height="20" fill="#ff6337"/></g><g fill="#fff" text-anchor="middle" font-family="Verdana,Geneva,DejaVu Sans,sans-serif" text-rendering="geometricPrecision" font-size="110"><text x="255" y="140" textLength="390" transform="scale(.1)">release</text><text x="965" y="140" textLength="870" transform="scale(.1)" fill="#080D14">1.0.30</text></g></svg>

package/docs/migration.md

@@ -52,10 +52,10 @@ Use LitOpenCode vocabulary in docs, config, runtime output, and issue reports:
 - npm package and OpenCode package-loading entry: `@litfamily/litopencode`; native namespace and binary: `litopencode`
 - activation commands/tools: `lit`, `litwork`, `start-work`, `review-work`, `lit-recap`, `lit-korean`, `text-neutralization`
 - durable loop: `lit-loop`
-- durable goal manager: `litgoal`
+- durable goal manager: `litgoal` (sets and keeps the finish line; `lit-loop` and `start-work` run toward it)
 - current planning/research workflow names: `lit-plan`, `lit-crucible`, `litresearch`, `start-work`, `review-work`
   - `lit-plan` creates a planning-only objective-achievable checklist; `lit-crucible` adversarially tests assumptions before handing surviving insights to `lit-plan`.
-  - `litresearch` runs the root-owned evidence workflow; `start-work` executes an approved plan through `lit-implement`; `review-work` reviews either a draft plan or completed work without inventing another workflow surface.
+  - `litresearch` runs the root-owned evidence workflow; `start-work` executes an approved plan through `lit-implement`; `review-work` runs plan review after `lit-plan` or work review after `lit-loop` or `start-work`, picked from what exists or forced with `lit review plan` / `lit review work`, without inventing another workflow surface.
 
 Legacy vocabulary must not appear in tracked files or release payloads. Do not introduce old package names, host claims, or environment prefixes into new product docs, tests, source, fixtures, or release artifacts.
 
@@ -72,7 +72,8 @@ Legacy vocabulary must not appear in tracked files or release payloads. Do not i
 ## Skill ID renames
 
 Use `lit-crucible`, `lit-init`, `lit-commit`, `lit-burnoff`, `lit-burnoff-file`,
-`lit-korean`, `lit-fetch`, and `lit-code`. The Unreleased changelog records the old-to-new
+`lit-korean`, `lit-fetch`, `lit-code`, and `litgoal` (formerly `durable-litgoal`, so the skill,
+the `/litgoal` command and the chat route now share one name). The Unreleased changelog records the old-to-new
 mapping. Old bare-word invocations select the new skill and inject exactly one line:
 ``Note: `<old>` was renamed to `<new>`; the old name is removed in the next minor.``
 Quoted text, code fences, and compound-word

package/docs/reference-Ko-KR.md

@@ -137,7 +137,9 @@ litopencode install
 | `/litwork` | 제한된 작업 루프 진입 |
 | `/lit-plan` | 읽기 전용 구현 계획 작성 |
 | `/start-work` | 승인된 계획을 `lit-implement`로 실행 |
-| `/review-work` | 초안 계획 또는 완료 작업 검토 |
+| `/review-work` | `lit-plan` 뒤에는 계획 검토, `lit-loop`나 `/start-work` 뒤에는 작업 검토. 있는 것을 보고 고르며 `/review-work plan`, `/review-work work`로 직접 정할 수 있음 |
+| `/litgoal` | 끝나는 지점을 정하고 지킴: 확인 가능한 기준이 붙은 목표 하나를 디스크에 남김. `lit-loop`와 `/start-work`가 그 목표를 향해 일함 |
+| `/lit-brainstorm` | 열린 질문을 여러 선택지로 펼친 뒤 짧은 목록으로 좁히고, 고른 것을 `deep-interview`나 `lit-plan`에 넘김. 채팅에서는 `lit brainstorm`, `lit brainstorming`, `lit ideation`, `lit ideate`, `lit idea`, `lit ideas`. 직접 만들지는 않음 |
 | `/litresearch` 또는 `/lit-research` | 순차 대체 경로를 포함한 근거 기반 연구 |
 | `/lit-handoff` | 이어서 작업할 수 있는 핸드오프 작성 |
 | `/lit-recap` | 로컬 ledger와 세션 맥락으로 짧은 리캡 작성 |
@@ -150,6 +152,17 @@ litopencode install
 `/autoresearch`, `/autoconference`, `/wikify-*` 경로가 있습니다. 이 경로는 안내 또는 제한된
 로컬 동작을 추가합니다. 호스트 권한은 늘리지 않습니다.
 
+### `lit` 반복 입력
+
+메시지마다 `lit`를 붙여도 안전합니다. 세션의 첫 `lit`는 전체 활성화 안내를 보냅니다. 같은 discipline의 `lit`
+(예: 실행 중에 보낸 두 번째 `lit fix ...`)는 전체 안내 대신 "이미 활성, 이어서 진행" 짧은 메모만 보내며, 기존
+계획, 기준, ledger를 건드리지 않습니다. 다른 discipline(루프 중 `lit plan ...`)은 그 discipline의 전체
+활성화 안내를 한 번 보냅니다. `lit new ...`와 `lit restart ...`는 새로 시작합니다. 승인된 계획이나 진행 중인
+`/start-work` 기록이 있으면 단독 `lit` 또는 `lit continue`가 그 작업을 이어 가며 새 계획을 만들지 않습니다.
+작업 내용도 없고 진행 중인 것도 없는 단독 `lit`는 무엇을 할지 되묻습니다. 컴팩션, 새 세션, OpenCode 재시작
+뒤에는 활성 discipline을 잊으므로 다음 `lit`는 다시 전체 안내를 보냅니다. `lit-loop`, `lit-plan`,
+`lit-humanizer`는 스킬 본문을 붙이지 않고 설치된 스킬을 가리킵니다.
+
 ### Durable loop 상태
 
 LitOpenCode는 `.litopencode/litgoal/lit-loop/`에 goal 상태를 저장합니다. append-only
@@ -245,15 +258,104 @@ npm uninstall -g @litfamily/litopencode
 프로젝트의 `.litopencode/`는 별도 ledger와 receipt입니다. 나중에 재개할 계획이 없다면
 그 상태를 버려도 되는지 확인한 뒤 직접 정리합니다.
 
-TUI 패널 항목은 `tui.json`이나 `tui.jsonc`에 있습니다. `litopencode tui remove [--root <dir>]`는
-두 파일에서 LitOpenCode 항목만 지우고, 다른 플러그인과 주석은 그대로 둡니다. 바뀌는 파일은 먼저
-`<file>.litopencode-backup`으로 복사합니다. `--dry-run`은 같은 결과를 보여 주기만 하고 아무것도 쓰지 않습니다.
+TUI 패널 항목은 `tui.json`이나 `tui.jsonc`에 있고, OpenCode 2에서는 `cli.json`에 고정된 항목이 있을 수도
+있습니다. `litopencode tui remove [--root <dir>]`는 세 파일에서 LitOpenCode 항목만 지우고, 다른 플러그인과
+주석은 그대로 둡니다. 바뀌는 파일은 먼저 `<file>.litopencode-backup`으로 복사합니다. 쓰기 전에 모든 파일을
+읽고 확인하므로, 깨진 파일이나 지워질 주석이 있으면 아무것도 바꾸지 않고 멈춥니다. `--host v1`이면
+`cli.json`은 건드리지 않습니다. `--dry-run`은 같은 결과를 보여 주기만 하고 아무것도 쓰지 않습니다.
+
+## OpenCode 2
+
+LitOpenCode는 OpenCode 1(1.18.29 이상. 패키지가 `engines.opencode >=1.18.29`를 선언하고 OpenCode 1이 이를
+확인합니다)과 OpenCode 2에서 모두 돌아갑니다. 두 호스트를 함께 설치할 수 있습니다. OpenCode 1은 `opencode`
+명령을 그대로 쓰고, OpenCode 2(npm `@opencode/cli`)는 `opencode2`로 실행합니다. 둘 다 같은
+`~/.config/opencode`를 읽으므로 한 번 설치하면 양쪽에 적용됩니다.
+
+**설치.** `litopencode install`은 무엇을 쓰기 전에 호스트부터 찾고, 그때 어느 호스트도 실행하지 않습니다.
+`opencode`와 `opencode2` 뒤에 있는 npm 패키지를 읽습니다(`opencode-ai`는 OpenCode 1, `@opencode/cli`는 OpenCode 2.
+Windows에서는 npm `.cmd` 실행 파일을 글자로 읽습니다). 뒤에 npm 패키지가 없는 `opencode`(curl 설치 스크립트,
+Homebrew, mise)는 일단 OpenCode 1로 봅니다. 어떻게 설치했든 OpenCode 1 설정이 유지되도록 하기 위해서입니다.
+`opencode2`와 같은 파일인 `opencode`는 OpenCode 2로 보고, `opencode2`는 언제나 OpenCode 2로 봅니다. OpenCode 1에는
+`opencode2`가 없기 때문입니다. 실제 설치는 OpenCode 1로 짐작한 `opencode`에 `opencode plugin`을 부르기 전에
+`opencode --version`을 묻고, 2.x라고 답하면 그 호스트에 OpenCode 2 설정을 합니다(dry run은 아무것도 실행하지 않으므로
+처음 짐작을 보여 줍니다).
+PATH에 두 명령이 모두 없으면 `tui.json`(OpenCode 1)과 `cli.json`(OpenCode 2)을 근거로 삼고, 둘 다 없으면
+OpenCode 1 설정을 유지합니다. `--host v1`이나 `--host both`인데 `opencode`가 OpenCode 2뿐이면 아무것도 실행하기
+전에 멈춥니다. 그 상태에서 `opencode plugin`을 부르면 OpenCode 2 설정이 바뀌기 때문입니다.
+기본값인 `--host auto`는 찾은 호스트를 모두 설정하고, `--host v1`, `--host v2`, `--host both`로 직접 정할 수
+있습니다. dry-run 결과의 `host`에 판단이 나옵니다. OpenCode 1 쪽은 그대로입니다. `opencode plugin`이 패키지를
+등록하고 TUI 항목은 `tui.json`에 들어갑니다. OpenCode 2 쪽에서 설치 프로그램은 다음을 합니다.
+
+- 두 호스트가 함께 읽는 `opencode.json(c)`의 `plugin` 목록에 항목 하나만 둡니다. OpenCode 2 실행 파일로
+  `opencode plugin`을 부르지 않습니다. OpenCode 2는 처음 불러올 때 패키지를 직접 설치합니다.
+- OpenCode 2 전용 `plugins` 키에 있는 LitOpenCode 항목을 지웁니다. 같은 id의 플러그인이 둘이면 OpenCode 2가
+  뒤의 것을 거부하기 때문입니다.
+- `cli.json`의 LitOpenCode 항목을 지우고 `cli.json.litopencode-backup`을 남깁니다. OpenCode 2는 활성
+  서버 플러그인의 TUI를 스스로 불러오는데, 거기에 고정된 항목이 있으면 그것이 새 TUI를 가리기 때문입니다.
+- 공유 설정에 OpenCode 2 키 `permissions`나 `policies`를 절대 쓰지 않습니다. OpenCode 1은 그 자리에서
+  `permissions`를 보면 시작하지 않습니다.
+
+두 호스트에 설치한 뒤 `opencode2` TUI를 처음 열면 OpenCode 2가 `tui.json`의 플러그인 목록을 새 `cli.json`으로
+복사하고, 여기에 LitOpenCode 항목도 따라 들어갑니다. 설치 프로그램은 이 복사를 막을 수 없습니다. doctor가 그
+항목을 알려 주고, `litopencode install`이나 `litopencode tui remove`를 다시 실행하면 지워집니다.
+
+**Doctor.** `litopencode doctor`는 `host` 블록(찾은 호스트, 근거 파일, 공유 설정의 `autoupdate`에서 읽은
+OpenCode 2 플러그인 업데이트 방식)을 보여 주고, `plugin`과 `plugins`에 걸친 LitOpenCode 항목 수를 세며,
+`cli.json`에 남은 항목과 OpenCode 1도 읽는 설정에 들어간 `permissions`를 알려 줍니다. doctor는 호스트를
+실행하지 않습니다. OpenCode 2가 대상이면 `lsp` 블록에 OpenCode 2는 `lsp` 설정을 받아 두기만 하고 언어 서버를
+돌리지 않는다는 설명이 붙습니다.
+
+**똑같이 동작하는 것.** 에이전트(기본은 `lit-loop`, `build`와 `plan`은 숨김), 도구 다섯 개, 단독 `lit` 활성화,
+정적 규칙과 독자용 계약, 도구 가드, 플래너 잠금, bounded-authority 진행 기록, 자동 인수인계,
+`~/.config/opencode/skills`의 스킬이 모두 OpenCode 2에서 돌아갑니다. OpenCode 2는 도구 두 개의 이름을 바꿨기
+때문에 권한 규칙은 `bash` 대신 `shell`, `task` 대신 `subagent`를 쓰고, `write`와 `patch`는 `edit`에 들어갑니다.
+그곳에서는 마지막에 맞는 규칙이 이기므로 `lit-plan`은 어떤 권한 모드에서도 `edit`, `shell`, `subagent`,
+`execute` 거부로 끝나고, 권한 훅이 다른 규칙과 상관없이 한 번 더 거부합니다. `execute`는 OpenCode 2의 Code Mode
+도구로, 모델이 쓴 JavaScript를 `fetch`와 다른 도구와 함께 실행합니다. OpenCode 1에는 없던 도구이고 계획만 하는
+에이전트가 가져서는 안 됩니다. 이렇게 거부된 도구는 요청에서 빠집니다. LitOpenCode 도구 다섯 개는 OpenCode 1에서처럼
+Code Mode 밖, 모델의 도구 목록에 바로 있으므로 `lit-plan`도 계속 씁니다. OpenCode 1에서 전역 권한을 넓히는 balanced와 yolo
+모드는 OpenCode 2에서는 각 LitOpenCode 에이전트 규칙의 앞부분에 들어갑니다. 플러그인이 그곳의 전역 규칙을
+바꿀 수 없기 때문입니다. 추론 강도 같은 에이전트별 요청 설정은 모델 요청마다 함께 보냅니다. OpenCode 2는
+에이전트의 요청 설정을 저장만 하고 아직 보내지 않습니다.
+
+**OpenCode 2에서 달라지는 것.**
+
+- *슬래시 명령.* 설치 프로그램은 두 호스트에 같은 `command/<id>.md` 파일을 쓰고, OpenCode 2에서는 이 파일이
+  같은 이름의 플러그인 명령을 대신합니다. 그래서 모든 lit 명령은 파일에서 오고 목록에 한 번만 나옵니다.
+  플러그인은 파일이 없는 명령만 직접 추가합니다(예를 들어 설치 프로그램 없이 `opencode plugin add`만 한 경우).
+  OpenCode 2에서 파일로 실행한 명령 차례에는 LitOpenCode 표시가 붙지 않습니다. 플러그인이 직접 보낸 명령에는
+  한 번만 쓰는 확인값이 든 표시가 붙어, 손으로 입력한 프롬프트가 흉내 낼 수 없습니다. `/lit-crucible`과
+  `/deep-interview`(`lit-plan`), `/start-work`(`lit-implement`)처럼 에이전트가 정해진 플러그인 명령은 명령 파일의
+  `agent:` 줄과 같이 먼저 세션을 그 에이전트로 바꿉니다.
+- *모델 경로.* OpenCode 2는 자기 모델이 없는 세션을 호스트의 기본 모델로 돌립니다. 에이전트의 모델은 세션을
+  만드는 클라이언트만 읽는데, TUI는 읽고 `opencode2 run`은 읽지 않습니다. 그래서 그런 세션의 첫 프롬프트에서
+  세션을 에이전트의 경로로 바꿉니다(에이전트가 없으면 `lit-loop`). 그 모델이 카탈로그에 있을 때만 바꿉니다.
+  사용자가 고른 모델과, 호스트가 이미 에이전트 모델로 시작하는 하위 세션은 그대로 둡니다. OpenCode 1과 같이
+  LitOpenCode가 쓰는 OpenAI 모델이 호스트 카탈로그에 없으면 `openai` 카탈로그에 추가합니다.
+- *사용자 메시지로 가는 프로젝트 데이터.* 로컬 지식 기록, start-work 재개 영수증, 자동 인수인계 설정 응답은
+  요청의 마지막 사용자 메시지에 붙습니다. OpenCode 1에서도 사용자 메시지의 일부였습니다. OpenCode 2의 system
+  부분은 지시를 위한 자리라서, LitOpenCode의 활성화 문구와 규칙, 독자용 계약만 그곳에 들어갑니다.
+- *따옴표 프롬프트.* `opencode2 run "lit fix it"`은 단어를 큰따옴표로 감싸 보내므로, 메시지 전체가 따옴표 한 쌍이면
+  따옴표를 벗겨 읽습니다. 서버는 이것과 TUI에서 통째로 따옴표 안에 입력한 프롬프트를 구별하지 못해서 그런 입력도
+  활성화됩니다. OpenCode 1에서는 활성화되지 않았습니다.
+- *점화 표시.* OpenCode 2에는 끝난 답변을 고치는 훅이 없어서 표시가 TUI로 옮겨 갑니다. 세션의 마지막 프롬프트가
+  lit 프롬프트이면 프롬프트 아래 줄(`prompt.footer.status`)에 `🔥 LIT IGNITED · <discipline>`이 나옵니다.
+  OpenCode 1에서는 표시가 예전 자리에 그대로 있습니다.
+- *토스트.* OpenCode 2에서는 서버가 토스트를 띄울 수 없습니다. 서버가 사용자 메시지 메타데이터에 남긴 lit 표시를
+  TUI가 보고 점화 토스트를 직접 띄웁니다. 서버만 알던 자동 인수인계 알림과 스킬 힌트는 그곳에 나오지 않습니다.
+- *TUI.* 미션 패널은 전처럼 세션 사이드바에 있습니다. OpenCode 2는 서버 플러그인과 함께 오는 TUI에 옵션을
+  넘기지 않고 할 일 목록도 두지 않으므로, 미션 진행은 ledger와 작업 기록과 계획에서 읽습니다. 세션 아래 상태 띠와
+  홈 화면 한 줄은 OpenCode 1에서만 그립니다.
+- *업데이트.* OpenCode 2에서는 플러그인 안의 자동 업데이트가 없습니다. `opencode plugin update`를 실행하거나
+  OpenCode 2의 업데이트 방식에 맡기면 됩니다.
 
 ## TUI 미션 패널
 
 OpenCode 1.18은 `tui.json`이나 `tui.jsonc`의 `plugin` 배열에 적힌 TUI 플러그인을 불러옵니다.
-이 패키지는 TUI 모듈을 서버 플러그인과 따로 `@litfamily/litopencode/tui`(`dist/tui.js`, 플러그인 id
-`litopencode`)로 내보냅니다. OpenCode가 두 대상을 한 모듈에 섞는 것을 허용하지 않기 때문입니다.
+이 패키지는 TUI 모듈을 서버 플러그인과 따로 `@litfamily/litopencode/tui`(`dist/host/tui.js`, 플러그인 id
+`litopencode`)로 내보냅니다. OpenCode가 두 대상을 한 모듈에 섞는 것을 허용하지 않기 때문입니다. OpenCode 2는
+활성 서버 플러그인을 위해 같은 모듈을 스스로 불러옵니다(위 OpenCode 2 참고). `./server`와 `./tui`의 타입 선언은
+각 진입점을 모양으로만 적으므로, 어느 호스트의 플러그인 패키지 없이도 해석됩니다.
 
 화면에 그리는 것:
 
@@ -461,7 +563,7 @@ OpenCode는 세션이 바쁜 동안 들어온 `summarize` 호출을 줄 세웠
 ## 스킬 이름 변경
 
 새 명령은 `/lit-crucible`, `/lit-init`, `/lit-commit`, `/lit-burnoff`, `/lit-burnoff-file`,
-`/lit-korean`, `/lit-fetch`, `/lit-code`입니다. 이전 이름은 한 릴리스 동안 새 명령으로
+`/lit-korean`, `/lit-fetch`, `/lit-code`, `/litgoal`(이전 `durable-litgoal`)입니다. 이전 이름은 한 릴리스 동안 새 명령으로
 연결되며, 이름 변경 안내가 한 줄 표시됩니다. 다음 마이너 버전에서 이전 이름을 제거합니다.
 설치·업데이트는 새 복사본을 검증한 뒤 설치 도구가 관리하는 이전 이름의 스킬 디렉터리를
 제거합니다. 사용자 소유 파일은 보존합니다. 자세한 내용은 [마이그레이션 안내](migration.md#skill-id-renames)를 참고하세요.

package/docs/reference.md

@@ -165,7 +165,9 @@ for an approved plan; `/review-work` checks the `DoneClaim` through a five-lane
 | `/litwork` | Enter the bounded work loop. |
 | `/lit-plan` | Create a read-only implementation plan. |
 | `/start-work` | Execute an approved plan through `lit-implement`. |
-| `/review-work` | Review a draft plan or completed work. |
+| `/review-work` | Plan review after `lit-plan` or work review after `lit-loop` or `/start-work`, picked from what exists; `/review-work plan` or `/review-work work` forces one. |
+| `/litgoal` | Set and keep the finish line: one goal with checkable criteria on durable state. `lit-loop` and `/start-work` run toward it. |
+| `/lit-brainstorm` | Open a question into options, narrow them to a short list, and hand the pick to `deep-interview` or `lit-plan`. Chat: `lit brainstorm`, `lit brainstorming`, `lit ideation`, `lit ideate`, `lit idea`, `lit ideas`. It never builds. |
 | `/litresearch` or `/lit-research` | Run evidence-backed research with a sequential fallback. |
 | `/lit-handoff` | Create a resumable handoff; exact bare `handoff` also routes here. |
 | `/lit-recap` | Read a concise recap from local ledger and session context. |
@@ -181,11 +183,23 @@ bounded local behavior; they do not silently grant new host authority. Frontend
 ships a canonical frontend library for its offline, read-only design references.
 
 The renamed routes are `/lit-crucible`, `/lit-init`, `/lit-commit`, `/lit-burnoff`,
-`/lit-burnoff-file`, `/lit-korean`, `/lit-fetch`, and `/lit-code`. Previous names remain
+`/lit-burnoff-file`, `/lit-korean`, `/lit-fetch`, `/lit-code`, and `/litgoal` (formerly
+`durable-litgoal`). Previous names remain
 compatibility redirects for one release and print one deprecation note. Install/update
 removes installer-owned old skill directories after verifying their replacements; user-owned
 files are preserved. See [migration notes](migration.md#skill-id-renames).
 
+### Repeating `lit`
+
+Typing `lit` on every message is safe. The first `lit` of a session sends the full activation. Another `lit`
+for the same discipline, such as a second `lit fix ...` while the first is running, sends a short "already
+active, continuing" note instead and leaves the existing plan, criteria and ledger alone. A different
+discipline (`lit plan ...` during a loop) sends that discipline's full activation once. `lit new ...` and
+`lit restart ...` start fresh. A bare `lit` or `lit continue` over an approved plan or an active `/start-work`
+record resumes it and never writes a new plan; a bare `lit` with no task and nothing in progress asks what to
+work on. A compaction, a new session or a restart of OpenCode forgets the active discipline, so the next `lit`
+is full again. `lit-loop`, `lit-plan` and `lit-humanizer` point to their installed skill instead of pasting it.
+
 ### Durable loop state
 
 LitOpenCode owns durable goal state under `.litopencode/litgoal/lit-loop/`. The append-only
@@ -244,11 +258,11 @@ flowchart LR
 - <code>debugging</code>
 - <code>deep-interview</code>
 - <code>doctor-installer</code>
-- <code>durable-litgoal</code>
 - <code>frontend-ui-ux</code>
 - <code>readme-studio</code>
 - <code>lit-commit</code>
 - <code>lit-crucible</code>
+- <code>lit-brainstorm</code>
 - <code>lit-init</code>
 - <code>lit-comprehend</code>
 - <code>lit-handoff</code>
@@ -259,6 +273,7 @@ flowchart LR
 - <code>lit-pptx</code>
 - <code>lit-docx</code>
 - <code>lit-typographic-motion</code>
+- <code>litgoal</code>
 - <code>litresearch</code>
 - <code>litwork</code>
 - <code>lsp</code>
@@ -346,16 +361,114 @@ OpenCode's managed `opencode.jsonc` (or the custom root's `opencode.json`). Remo
 Project `.litopencode/` state is separate; preserve it for later resume or remove it only
 when discarding that project's ledger and receipts is intentional.
 
-The TUI panel entry lives in `tui.json` or `tui.jsonc`. `litopencode tui remove [--root <dir>]`
-deletes LitOpenCode's own entry from both files, keeps every other plugin and every comment, and
-copies each changed file to `<file>.litopencode-backup` first. `--dry-run` prints the same receipt
-and writes nothing.
+The TUI panel entry lives in `tui.json` or `tui.jsonc`, and on OpenCode 2 a pinned entry can also sit
+in `cli.json`. `litopencode tui remove [--root <dir>]` deletes LitOpenCode's own entry from all three
+files, keeps every other plugin and every comment, and copies each changed file to
+`<file>.litopencode-backup` first. It reads and checks every file before it writes any, so a malformed
+file or a comment that would be lost stops it with nothing changed. `--host v1` leaves `cli.json` alone.
+`--dry-run` prints the same receipt and writes nothing.
+
+## OpenCode 2
+
+LitOpenCode runs on OpenCode 1 (1.18.29 or later; the package declares `engines.opencode >=1.18.29`,
+which OpenCode 1 checks) and on OpenCode 2. The two can be installed side by side: OpenCode 1 keeps the
+`opencode` command, and OpenCode 2 (npm `@opencode/cli`) is run as `opencode2`. Both read the same
+`~/.config/opencode`, so one install serves both.
+
+**Install.** `litopencode install` looks for each host before it writes anything, without starting
+either one. It reads the npm package behind `opencode` and `opencode2` (`opencode-ai` is OpenCode 1,
+`@opencode/cli` is OpenCode 2; on Windows it reads the npm `.cmd` shim as text). An `opencode` with no npm
+package behind it (the curl installer, Homebrew, mise) is taken for OpenCode 1, so OpenCode 1 keeps its
+setup however it was installed; an `opencode` that is the same file as `opencode2` counts as OpenCode 2.
+Any `opencode2` counts as OpenCode 2, since OpenCode 1 has no `opencode2`. Before a real install runs
+`opencode plugin` on an `opencode` it only took for OpenCode 1, it asks `opencode --version`; a 2.x answer
+gives that host the OpenCode 2 setup instead (a dry run starts nothing, so it shows the first guess). When neither command is on PATH, it takes `tui.json`
+(OpenCode 1) and `cli.json` (OpenCode 2) as evidence, and with neither it keeps the OpenCode 1 setup.
+`--host v1` or `--host both` stops before anything runs when the only `opencode` is OpenCode 2, because
+`opencode plugin` would then change OpenCode 2's config. With `--host auto`, the default, it sets up
+every host it found; `--host v1`, `--host v2` or `--host both` overrides that. The dry-run receipt shows the
+result under `host`. For OpenCode 1 nothing changes: `opencode plugin` registers the package and the TUI
+entry goes into `tui.json`. For OpenCode 2 the installer:
+
+- keeps the single entry in the `plugin` list of `opencode.json(c)`, which both hosts read, and never
+  runs `opencode plugin` with the OpenCode 2 binary (OpenCode 2 installs the package itself the first
+  time it loads it);
+- removes any LitOpenCode entry from OpenCode 2's own `plugins` key, because OpenCode 2 refuses a second
+  plugin with the same id;
+- removes any LitOpenCode entry from `cli.json`, with a `cli.json.litopencode-backup` copy, because
+  OpenCode 2 loads the TUI of an active server plugin on its own and a pinned entry there would shadow it;
+- never writes the OpenCode 2 keys `permissions` or `policies` into the shared config: OpenCode 1 stops
+  at startup when it finds `permissions` there.
+
+After an install for both hosts, the first `opencode2` TUI start copies the `tui.json` plugin list into a
+new `cli.json`, LitOpenCode's entry included. The installer cannot stop that copy; doctor flags the
+entry, and running `litopencode install` or `litopencode tui remove` again takes it out.
+
+**Doctor.** `litopencode doctor` adds a `host` block (hosts found, the evidence files, and OpenCode 2's
+plugin update policy, read from the shared `autoupdate` setting), counts LitOpenCode entries across
+`plugin` and `plugins`, flags a stale `cli.json` entry, and warns when `permissions` sits in a config that
+OpenCode 1 also reads. Doctor never starts a host. On OpenCode 2 the `lsp` block adds that OpenCode 2
+accepts the `lsp` settings but does not run language servers.
+
+**What works the same.** The agents (with `lit-loop` as the default, and `build` and `plan` hidden), the
+five tools, bare `lit` activation, the static rules and the reader contract, the tool guards, the
+planner lock, bounded-authority progress, the automatic handoff and the skills under
+`~/.config/opencode/skills` all run on OpenCode 2. OpenCode 2 renamed two tools, so the permission rules
+it gets say `shell` for `bash` and `subagent` for `task`, and `write` and `patch` fall under `edit`. The
+last matching rule wins there, so `lit-plan` ends with denials for `edit`, `shell`, `subagent` and
+`execute` in every permission mode, and a permission hook denies them again whatever other rules say.
+`execute` is OpenCode 2's Code Mode tool, which runs model-written JavaScript with `fetch` and other
+tools; OpenCode 1 had nothing like it, and a planning agent must not get it. A tool denied that way is left
+out of the request. The five LitOpenCode tools sit on the model's own tool list, outside Code Mode, as
+they did on OpenCode 1, so `lit-plan` keeps them. Balanced and yolo
+modes, which widen the global permission on OpenCode 1, lead each LitOpenCode agent's own rules on
+OpenCode 2, because a plugin cannot change the global rules there. Per-agent request settings such as the
+reasoning effort are sent with each model request, since OpenCode 2 keeps an agent's own request
+settings but does not send them yet.
+
+**What is different on OpenCode 2.**
+
+- *Slash commands.* The installer writes the same `command/<id>.md` files on both hosts, and on OpenCode 2
+  such a file replaces a plugin command of the same name. So every lit command comes from its file and is
+  listed once. The plugin adds a command only when no file covers it (for example after
+  `opencode plugin add` without the installer). A command turn from a file carries no LitOpenCode mark on
+  OpenCode 2; one the plugin itself sends carries a mark with a one-time check that a typed prompt cannot
+  copy. A plugin command with an agent route, such as `/lit-crucible` or `/deep-interview` (`lit-plan`) or
+  `/start-work` (`lit-implement`), first switches the session to that agent, as the `agent:` line of
+  the command file does.
+- *Model routes.* OpenCode 2 runs a session that has no model of its own on the host's default model;
+  only a client that creates the session reads the agent's model, and the TUI does while
+  `opencode2 run` does not. So the first prompt of such a session switches it to its agent's route
+  (`lit-loop` when it names none), once that model is in the catalog. A model you picked, and a
+  delegated child, which the host already starts on its agent's model, stay as they are. As on OpenCode 1,
+  the OpenAI rows LitOpenCode routes to are added to the `openai` catalog when the host lacks one.
+- *Project data in the user message.* Local knowledge records, a start-work resume receipt and an
+  auto-handoff setting reply are added to the latest user message of the request, where OpenCode 1 had
+  them as parts of the user message. OpenCode 2's system parts are for instructions, so only LitOpenCode's
+  own activation text, the rules and the reader contract go there.
+- *Quoted prompts.* `opencode2 run "lit fix it"` sends the words inside double quotes, so a message that
+  is exactly one quoted string is read without the quotes. The server cannot tell that from a TUI prompt
+  typed entirely in quotes, which therefore activates too; on OpenCode 1 it stayed inert.
+- *Ignition mark.* OpenCode 2 has no hook that edits the finished answer, so the mark moves into the
+  TUI: the line under the prompt (`prompt.footer.status`) reads `🔥 LIT IGNITED · <discipline>` while the
+  latest prompt of the session is a lit prompt. On OpenCode 1 the mark stays where it was.
+- *Toasts.* The server cannot show toasts on OpenCode 2. The TUI raises the ignition toast itself when a
+  user message arrives with the lit mark the server writes into its metadata. The automatic-handoff
+  notices and the skill hint, which only the server knew about, are not shown there.
+- *TUI.* The mission panel sits in the session sidebar as before. OpenCode 2 passes no options to a TUI
+  that comes with a server plugin, and it keeps no todo list, so mission progress comes from the ledger,
+  the work record and the plan. The status band under the session and the home-screen line are drawn on
+  OpenCode 1 only.
+- *Updates.* There is no automatic self-update inside the plugin on OpenCode 2. Run
+  `opencode plugin update`, or let OpenCode 2's own update policy handle it.
 
 ## TUI mission panel
 
 OpenCode 1.18 loads TUI plugins listed in the `plugin` array of `tui.json` or `tui.jsonc`. The
-package exports its TUI module as `@litfamily/litopencode/tui` (`dist/tui.js`, plugin id
-`litopencode`), separate from the server plugin, as OpenCode requires.
+package exports its TUI module as `@litfamily/litopencode/tui` (`dist/host/tui.js`, plugin id
+`litopencode`), separate from the server plugin, as OpenCode requires. OpenCode 2 loads the same module
+by itself for the active server plugin (see OpenCode 2 above). The type declarations of `./server` and
+`./tui` describe each entry by its shape, so they resolve without either host's plugin package.
 
 What it draws: