npm - @things-factory/ai-client-base - Versions diffs - 10.1.3 → 10.1.7 - Mend

@things-factory/ai-client-base 10.1.3 → 10.1.7

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (44) hide show

package/dist-server/service/tool-registry/registry.js.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"registry.js","sourceRoot":"","sources":["../../../server/service/tool-registry/registry.ts"],"names":[],"mappings":";;AAkCA,~~oDAuBC~~;AAmBD,8CAEC;AAMD,0CAEC;AAMD,0CAOC;AAQD,kDAQC;AAKD,oCAOC;AAMD,kCAEC;AAKD,0BAEC;AAKD,4CAEC;AASD,8CAEC;~~AAnID~~,MAAM,UAAU,GAA8B,IAAI,GAAG,EAAE,CAAA;AAEvD;;GAEG;AACH,SAAgB,oBAAoB,CAAC,QAAsB;IACzD,IAAI,UAAU,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,EAAE,CAAC;QAClC,OAAO,CAAC,IAAI,CACV,sCAAsC,QAAQ,CAAC,IAAI,sCAAsC;YACvF,mDAAmD,CACtD,CAAA;IACH,CAAC;IAED,4CAA4C;IAC5C,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAA;IACzD,KAAK,MAAM,CAAC,SAAS,EAAE,KAAK,CAAC,IAAI,UAAU,EAAE,CAAC;QAC5C,IAAI,SAAS,KAAK,QAAQ,CAAC,IAAI;YAAE,SAAQ,CAAC,uBAAuB;QACjE,KAAK,MAAM,IAAI,IAAI,KAAK,CAAC,KAAK,EAAE,CAAC;YAC/B,IAAI,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;gBAC5B,MAAM,IAAI,KAAK,CACb,uCAAuC,IAAI,CAAC,IAAI,mCAAmC;oBACjF,IAAI,SAAS,0BAA0B,QAAQ,CAAC,IAAI,wCAAwC,CAC/F,CAAA;YACH,CAAC;QACH,CAAC;IACH,CAAC;IAED,UAAU,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,EAAE,QAAQ,CAAC,CAAA;AACzC,CAAC;AAWD,sCAAsC;AACtC,SAAS,OAAO,CAAC,IAAY,EAAE,MAA0B;IACvD,OAAO,CAAC,MAAM,IAAI,MAAM,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAA;AACzC,CAAC;AAED;;GAEG;AACH,SAAgB,iBAAiB;IAC/B,OAAO,KAAK,CAAC,IAAI,CAAC,UAAU,CAAC,MAAM,EAAE,CAAC,CAAA;AACxC,CAAC;AAED;;;GAGG;AACH,SAAgB,eAAe;IAC7B,OAAO,eAAe,CAAC,SAAS,CAAC,CAAA;AACnC,CAAC;AAED;;;GAGG;AACH,SAAgB,eAAe,CAAC,MAA0B;IACxD,MAAM,GAAG,GAAe,EAAE,CAAA;IAC1B,KAAK,MAAM,CAAC,OAAO,EAAE,GAAG,CAAC,IAAI,UAAU,EAAE,CAAC;QACxC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,MAAM,CAAC;YAAE,SAAQ;QACvC,KAAK,MAAM,IAAI,IAAI,GAAG,CAAC,KAAK;YAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;IAC9C,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED;;;;;GAKG;AACH,SAAgB,mBAAmB,CAAC,MAA0B;IAC5D,MAAM,GAAG,GAAa,EAAE,CAAA;IACxB,KAAK,MAAM,CAAC,OAAO,EAAE,GAAG,CAAC,IAAI,UAAU,EAAE,CAAC;QACxC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,MAAM,CAAC;YAAE,SAAQ;QACvC,MAAM,QAAQ,GAAG,CAAC,GAAG,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAA;QAC5C,IAAI,QAAQ;YAAE,GAAG,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAA;IAClC,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED;;GAEG;AACH,SAAgB,YAAY,CAAC,IAAY,EAAE,MAA2B;IACpE,KAAK,MAAM,CAAC,OAAO,EAAE,GAAG,CAAC,IAAI,UAAU,EAAE,CAAC;QACxC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,MAAM,CAAC;YAAE,SAAQ;QACvC,MAAM,IAAI,GAAG,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC,CAAA;QACjD,IAAI,IAAI;YAAE,OAAO,IAAI,CAAA;IACvB,CAAC;IACD,OAAO,SAAS,CAAA;AAClB,CAAC;AAED;;;GAGG;AACH,SAAgB,WAAW,CAAC,IAAY,EAAE,MAA2B;IACnE,OAAO,YAAY,CAAC,IAAI,EAAE,MAAM,CAAC,EAAE,IAAI,CAAA;AACzC,CAAC;AAED;;GAEG;AACH,SAAgB,OAAO,CAAC,IAAY,EAAE,MAA2B;IAC/D,OAAO,YAAY,CAAC,IAAI,EAAE,MAAM,CAAC,KAAK,SAAS,CAAA;AACjD,CAAC;AAED;;GAEG;AACH,SAAgB,gBAAgB,CAAC,YAAoB;IACnD,OAAO,UAAU,CAAC,GAAG,CAAC,YAAY,CAAC,EAAE,KAAK,IAAI,EAAE,CAAA;AAClD,CAAC;AAED;;;;;;GAMG;AACH,SAAgB,iBAAiB;IAC/B,UAAU,CAAC,KAAK,EAAE,CAAA;AACpB,CAAC","sourcesContent":["/*\n ToolCategoryRegistry — 외부 도메인 패키지가 LLM tool category 를 동적 등록하는 점.\n \n 사용 패턴 (외부 패키지의 server bootstrap):\n * ```ts\n * import { registerToolCategory } from '@things-factory/board-ai'\n \n registerToolCategory({\n * name: 'board-import',\n * specs: [\n * { kind: 'external', name: 'importBoardAsync', schema: {...}, builder: ... },\n * { kind: 'read', name: 'getImportSession', schema: {...}, builder: ... },\n * ...\n * ]\n * })\n * ```\n \n board-ai assistant.ts 의 buildBoardEditTools / dispatch / isWriteTool 등이\n * 본 registry 에서 자동 도출.\n \n 정책:\n * - 카테고리 이름은 unique. 같은 이름으로 재등록하면 덮어쓰기 (외부 패키지의\n * hot-reload / dev 환경 대응). console.warn 으로 알림.\n * - tool name 은 카테고리 간 통틀어 unique. 충돌 시 등록 거부 + 명확한 에러\n * (LLM dispatch 가 모호해지지 않도록).\n * - clear() 는 테스트 전용. 운영 환경에서 호출 금지.\n /\nimport type { ToolCategory, ToolSpec } from './types'\n\nconst categories: Map<string, ToolCategory> = new Map()\n\n/\n 카테고리 등록. tool name 충돌 시 throw, 이름 중복 등록 시 덮어쓰기 + warn.\n /\nexport function registerToolCategory(category: ToolCategory): void {\n if (categories.has(category.name)) {\n console.warn(\n `[board-ai/tool-registry] category '${category.name}' already registered — overwriting. ` +\n `(dev hot-reload 시 정상이지만 운영 환경에서 발생하면 buildup bug)`\n )\n }\n\n // tool name 충돌 검사 — 다른 카테고리에 같은 name 있으면 거부\n const newNames = new Set(category.specs.map(s => s.name))\n for (const [otherName, other] of categories) {\n if (otherName === category.name) continue // 같은 카테고리 재등록은 덮어쓰기 OK\n for (const spec of other.specs) {\n if (newNames.has(spec.name)) {\n throw new Error(\n `[board-ai/tool-registry] tool name '${spec.name}' already registered in category ` +\n `'${otherName}', cannot register in '${category.name}'. tool names must be globally unique.`\n )\n }\n }\n }\n\n categories.set(category.name, category)\n}\n\n/\n 대화별 도구 노출 제한 — 허용 카테고리 목록.\n \n `undefined` 는 제한 없음(등록된 전부). 호스트가 목록을 주면 그 카테고리에 속한 spec 만\n * 정의·실행 대상이 된다. 정의를 숨기는 것만으로는 부족하다 — 모델이 이름을 추측하거나 옛 대화가\n * 재생되면 숨긴 도구도 호출되므로 dispatch 조회(findToolSpec)에도 같은 목록을 넘겨야 한다.\n /\nexport type ToolCategoryFilter = ReadonlyArray<string> \| undefined\n\n/* 허용 목록에 든 카테고리인가. 목록 없음 = 전부 허용. /\nfunction allowed(name: string, filter: ToolCategoryFilter): boolean {\n return !filter \|\| filter.includes(name)\n}\n\n/\n 등록된 모든 카테고리 (등록 순서 보존). 외부에서 불변 read-only 로 사용.\n /\nexport function getToolCategories(): ReadonlyArray<ToolCategory> {\n return Array.from(categories.values())\n}\n\n/\n 등록된 모든 tool spec 의 평면 view. assistant.ts 의 buildBoardEditTools 가\n * LLM tool 정의 합집합으로 사용.\n /\nexport function getAllToolSpecs(): ReadonlyArray<ToolSpec> {\n return getToolSpecsFor(undefined)\n}\n\n/\n 허용 카테고리의 spec 평면 view. `undefined` = 전부(= getAllToolSpecs 와 동일).\n * LLM 도구 정의를 만들 때 이 함수를 쓰면 대화별 노출 제한이 그대로 반영된다.\n /\nexport function getToolSpecsFor(filter: ToolCategoryFilter): ReadonlyArray<ToolSpec> {\n const out: ToolSpec[] = []\n for (const [catName, cat] of categories) {\n if (!allowed(catName, filter)) continue\n for (const spec of cat.specs) out.push(spec)\n }\n return out\n}\n\n/\n 노출된 카테고리들의 사용 규율 모음(등록 순서). 시스템 프롬프트에 붙이는 용도.\n \n 도구 목록만 보내면 모델은 \"무엇이 있는지\" 는 알지만 \"언제 반드시 불러야 하는지\" 는 모른다.\n * 규율은 도구를 등록한 쪽이 소유하고, 호스트는 노출된 것만 모아 붙인다(도메인 지식이 새지 않는다).\n /\nexport function getCategoryGuidance(filter: ToolCategoryFilter): string[] {\n const out: string[] = []\n for (const [catName, cat] of categories) {\n if (!allowed(catName, filter)) continue\n const guidance = (cat.guidance ?? '').trim()\n if (guidance) out.push(guidance)\n }\n return out\n}\n\n/\n tool name 으로 spec 검색. 없으면 undefined.\n /\nexport function findToolSpec(name: string, filter?: ToolCategoryFilter): ToolSpec \| undefined {\n for (const [catName, cat] of categories) {\n if (!allowed(catName, filter)) continue\n const spec = cat.specs.find(s => s.name === name)\n if (spec) return spec\n }\n return undefined\n}\n\n/\n tool name 의 카테고리 (read/write/action/external). 미등록 tool 은 undefined.\n * assistant.ts 의 isReadTool / isWriteTool / isActionTool 이 이 함수에 위임할 수 있다.\n /\nexport function getToolKind(name: string, filter?: ToolCategoryFilter): ToolSpec['kind'] \| undefined {\n return findToolSpec(name, filter)?.kind\n}\n\n/\n 등록된 tool 인지. dispatch path 가 hardcoded set 와 registry 양쪽 fallback 시 사용.\n /\nexport function hasTool(name: string, filter?: ToolCategoryFilter): boolean {\n return findToolSpec(name, filter) !== undefined\n}\n\n/\n 카테고리 이름으로 spec 만 추출.\n /\nexport function getCategorySpecs(categoryName: string): ReadonlyArray<ToolSpec> {\n return categories.get(categoryName)?.specs ?? []\n}\n\n/\n 테스트 전용 — 모든 등록 해제. 운영 환경에서 호출 금지.\n \n jest 의 setupFilesAfterEach 또는 명시적 afterEach 에서 호출해 테스트 간 격리.\n * 실제로 STYLING_TOOLS 는 board-ai 자체 부트스트랩에서 다시 등록되므로 clear 후\n * 명시 register 가 필요한 것은 동적 카테고리 (board-import 등) 뿐.\n */\nexport function clearToolRegistry(): void {\n categories.clear()\n}\n"]}
1	+ {"version":3,"file":"registry.js","sourceRoot":"","sources":["../../../server/service/tool-registry/registry.ts"],"names":[],"mappings":";;AAkCA,oDA6CC;AAmBD,8CAEC;AAMD,0CAEC;AAMD,0CAOC;AAQD,kDAQC;AAKD,oCAOC;AAMD,kCAEC;AAKD,0BAEC;AAKD,4CAEC;AASD,8CAEC;AAzJD,MAAM,UAAU,GAA8B,IAAI,GAAG,EAAE,CAAA;AAEvD;;GAEG;AACH,SAAgB,oBAAoB,CAAC,QAAsB;IACzD;;;;;;;;;;;;OAYG;IACH,IAAI,CAAC,MAAM,CAAC,QAAQ,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,EAAE,CAAC;QAC5C,MAAM,IAAI,KAAK,CACb,4CAA4C,QAAQ,CAAC,IAAI,qBAAqB;YAC5E,sFAAsF;YACtF,wFAAwF;YACxF,yFAAyF,CAC5F,CAAA;IACH,CAAC;IAED,IAAI,UAAU,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,CAAC,EAAE,CAAC;QAClC,OAAO,CAAC,IAAI,CACV,sCAAsC,QAAQ,CAAC,IAAI,sCAAsC;YACvF,mDAAmD,CACtD,CAAA;IACH,CAAC;IAED,4CAA4C;IAC5C,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,QAAQ,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC,CAAA;IACzD,KAAK,MAAM,CAAC,SAAS,EAAE,KAAK,CAAC,IAAI,UAAU,EAAE,CAAC;QAC5C,IAAI,SAAS,KAAK,QAAQ,CAAC,IAAI;YAAE,SAAQ,CAAC,uBAAuB;QACjE,KAAK,MAAM,IAAI,IAAI,KAAK,CAAC,KAAK,EAAE,CAAC;YAC/B,IAAI,QAAQ,CAAC,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;gBAC5B,MAAM,IAAI,KAAK,CACb,uCAAuC,IAAI,CAAC,IAAI,mCAAmC;oBACjF,IAAI,SAAS,0BAA0B,QAAQ,CAAC,IAAI,wCAAwC,CAC/F,CAAA;YACH,CAAC;QACH,CAAC;IACH,CAAC;IAED,UAAU,CAAC,GAAG,CAAC,QAAQ,CAAC,IAAI,EAAE,QAAQ,CAAC,CAAA;AACzC,CAAC;AAWD,sCAAsC;AACtC,SAAS,OAAO,CAAC,IAAY,EAAE,MAA0B;IACvD,OAAO,CAAC,MAAM,IAAI,MAAM,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAA;AACzC,CAAC;AAED;;GAEG;AACH,SAAgB,iBAAiB;IAC/B,OAAO,KAAK,CAAC,IAAI,CAAC,UAAU,CAAC,MAAM,EAAE,CAAC,CAAA;AACxC,CAAC;AAED;;;GAGG;AACH,SAAgB,eAAe;IAC7B,OAAO,eAAe,CAAC,SAAS,CAAC,CAAA;AACnC,CAAC;AAED;;;GAGG;AACH,SAAgB,eAAe,CAAC,MAA0B;IACxD,MAAM,GAAG,GAAe,EAAE,CAAA;IAC1B,KAAK,MAAM,CAAC,OAAO,EAAE,GAAG,CAAC,IAAI,UAAU,EAAE,CAAC;QACxC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,MAAM,CAAC;YAAE,SAAQ;QACvC,KAAK,MAAM,IAAI,IAAI,GAAG,CAAC,KAAK;YAAE,GAAG,CAAC,IAAI,CAAC,IAAI,CAAC,CAAA;IAC9C,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED;;;;;GAKG;AACH,SAAgB,mBAAmB,CAAC,MAA0B;IAC5D,MAAM,GAAG,GAAa,EAAE,CAAA;IACxB,KAAK,MAAM,CAAC,OAAO,EAAE,GAAG,CAAC,IAAI,UAAU,EAAE,CAAC;QACxC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,MAAM,CAAC;YAAE,SAAQ;QACvC,MAAM,QAAQ,GAAG,CAAC,GAAG,CAAC,QAAQ,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAA;QAC5C,IAAI,QAAQ;YAAE,GAAG,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAA;IAClC,CAAC;IACD,OAAO,GAAG,CAAA;AACZ,CAAC;AAED;;GAEG;AACH,SAAgB,YAAY,CAAC,IAAY,EAAE,MAA2B;IACpE,KAAK,MAAM,CAAC,OAAO,EAAE,GAAG,CAAC,IAAI,UAAU,EAAE,CAAC;QACxC,IAAI,CAAC,OAAO,CAAC,OAAO,EAAE,MAAM,CAAC;YAAE,SAAQ;QACvC,MAAM,IAAI,GAAG,GAAG,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,KAAK,IAAI,CAAC,CAAA;QACjD,IAAI,IAAI;YAAE,OAAO,IAAI,CAAA;IACvB,CAAC;IACD,OAAO,SAAS,CAAA;AAClB,CAAC;AAED;;;GAGG;AACH,SAAgB,WAAW,CAAC,IAAY,EAAE,MAA2B;IACnE,OAAO,YAAY,CAAC,IAAI,EAAE,MAAM,CAAC,EAAE,IAAI,CAAA;AACzC,CAAC;AAED;;GAEG;AACH,SAAgB,OAAO,CAAC,IAAY,EAAE,MAA2B;IAC/D,OAAO,YAAY,CAAC,IAAI,EAAE,MAAM,CAAC,KAAK,SAAS,CAAA;AACjD,CAAC;AAED;;GAEG;AACH,SAAgB,gBAAgB,CAAC,YAAoB;IACnD,OAAO,UAAU,CAAC,GAAG,CAAC,YAAY,CAAC,EAAE,KAAK,IAAI,EAAE,CAAA;AAClD,CAAC;AAED;;;;;;GAMG;AACH,SAAgB,iBAAiB;IAC/B,UAAU,CAAC,KAAK,EAAE,CAAA;AACpB,CAAC","sourcesContent":["/*\n ToolCategoryRegistry — 외부 도메인 패키지가 LLM tool category 를 동적 등록하는 점.\n \n 사용 패턴 (외부 패키지의 server bootstrap):\n * ```ts\n * import { registerToolCategory } from '@things-factory/board-ai'\n \n registerToolCategory({\n * name: 'board-import',\n * specs: [\n * { kind: 'external', name: 'importBoardAsync', schema: {...}, builder: ... },\n * { kind: 'read', name: 'getImportSession', schema: {...}, builder: ... },\n * ...\n * ]\n * })\n * ```\n \n board-ai assistant.ts 의 buildBoardEditTools / dispatch / isWriteTool 등이\n * 본 registry 에서 자동 도출.\n \n 정책:\n * - 카테고리 이름은 unique. 같은 이름으로 재등록하면 덮어쓰기 (외부 패키지의\n * hot-reload / dev 환경 대응). console.warn 으로 알림.\n * - tool name 은 카테고리 간 통틀어 unique. 충돌 시 등록 거부 + 명확한 에러\n * (LLM dispatch 가 모호해지지 않도록).\n * - clear() 는 테스트 전용. 운영 환경에서 호출 금지.\n /\nimport type { ToolCategory, ToolSpec } from './types'\n\nconst categories: Map<string, ToolCategory> = new Map()\n\n/\n 카테고리 등록. tool name 충돌 시 throw, 이름 중복 등록 시 덮어쓰기 + warn.\n /\nexport function registerToolCategory(category: ToolCategory): void {\n /\n * 지침 없는 카테고리는 등록하지 않는다.\n \n 도구 목록만 보낸 모델이 「불러야 할 때 부른다」를 맞히지 못한 사고가 있었다 — 조치 요청에\n * `proposeAction` 을 부르지 않고 「제안해 두었습니다」라고 답해, 사용자에게 없는 버튼을 누르라고\n * 안내했다. 화면에는 아무 일도 없었고 오류도 나지 않았다(§`ToolCategory.guidance`).\n \n 그 뒤로 규율을 적는 자리를 만들었지만 선택이었다. 선택인 규율은 그 사고를 아는 사람만\n * 채운다. 여기서 거절하는 이유가 그것이다 — 빠진 것을 부팅에서 만든 사람이 보고, 모델이 헛말을\n * 한 뒤에 사용자가 보지 않는다.\n \n 빈 문자열·공백도 거절한다. 통과시키면 이 검사가 형식이 되고, 형식이 된 검사는 없는 것과 같다.\n /\n if (!String(category.guidance ?? '').trim()) {\n throw new Error(\n `[ai-client-base/tool-registry] category '${category.name}' has no guidance. ` +\n 'Tool descriptions say what a tool does; guidance says when the model must call one. ' +\n 'Without it a model answers as though it called a tool it did not, and nothing errors. ' +\n 'Write the rules for these tools in `guidance` — the side that registers them owns them.'\n )\n }\n\n if (categories.has(category.name)) {\n console.warn(\n `[board-ai/tool-registry] category '${category.name}' already registered — overwriting. ` +\n `(dev hot-reload 시 정상이지만 운영 환경에서 발생하면 buildup bug)`\n )\n }\n\n // tool name 충돌 검사 — 다른 카테고리에 같은 name 있으면 거부\n const newNames = new Set(category.specs.map(s => s.name))\n for (const [otherName, other] of categories) {\n if (otherName === category.name) continue // 같은 카테고리 재등록은 덮어쓰기 OK\n for (const spec of other.specs) {\n if (newNames.has(spec.name)) {\n throw new Error(\n `[board-ai/tool-registry] tool name '${spec.name}' already registered in category ` +\n `'${otherName}', cannot register in '${category.name}'. tool names must be globally unique.`\n )\n }\n }\n }\n\n categories.set(category.name, category)\n}\n\n/\n 대화별 도구 노출 제한 — 허용 카테고리 목록.\n \n `undefined` 는 제한 없음(등록된 전부). 호스트가 목록을 주면 그 카테고리에 속한 spec 만\n * 정의·실행 대상이 된다. 정의를 숨기는 것만으로는 부족하다 — 모델이 이름을 추측하거나 옛 대화가\n * 재생되면 숨긴 도구도 호출되므로 dispatch 조회(findToolSpec)에도 같은 목록을 넘겨야 한다.\n /\nexport type ToolCategoryFilter = ReadonlyArray<string> \| undefined\n\n/* 허용 목록에 든 카테고리인가. 목록 없음 = 전부 허용. /\nfunction allowed(name: string, filter: ToolCategoryFilter): boolean {\n return !filter \|\| filter.includes(name)\n}\n\n/\n 등록된 모든 카테고리 (등록 순서 보존). 외부에서 불변 read-only 로 사용.\n /\nexport function getToolCategories(): ReadonlyArray<ToolCategory> {\n return Array.from(categories.values())\n}\n\n/\n 등록된 모든 tool spec 의 평면 view. assistant.ts 의 buildBoardEditTools 가\n * LLM tool 정의 합집합으로 사용.\n /\nexport function getAllToolSpecs(): ReadonlyArray<ToolSpec> {\n return getToolSpecsFor(undefined)\n}\n\n/\n 허용 카테고리의 spec 평면 view. `undefined` = 전부(= getAllToolSpecs 와 동일).\n * LLM 도구 정의를 만들 때 이 함수를 쓰면 대화별 노출 제한이 그대로 반영된다.\n /\nexport function getToolSpecsFor(filter: ToolCategoryFilter): ReadonlyArray<ToolSpec> {\n const out: ToolSpec[] = []\n for (const [catName, cat] of categories) {\n if (!allowed(catName, filter)) continue\n for (const spec of cat.specs) out.push(spec)\n }\n return out\n}\n\n/\n 노출된 카테고리들의 사용 규율 모음(등록 순서). 시스템 프롬프트에 붙이는 용도.\n \n 도구 목록만 보내면 모델은 \"무엇이 있는지\" 는 알지만 \"언제 반드시 불러야 하는지\" 는 모른다.\n * 규율은 도구를 등록한 쪽이 소유하고, 호스트는 노출된 것만 모아 붙인다(도메인 지식이 새지 않는다).\n /\nexport function getCategoryGuidance(filter: ToolCategoryFilter): string[] {\n const out: string[] = []\n for (const [catName, cat] of categories) {\n if (!allowed(catName, filter)) continue\n const guidance = (cat.guidance ?? '').trim()\n if (guidance) out.push(guidance)\n }\n return out\n}\n\n/\n tool name 으로 spec 검색. 없으면 undefined.\n /\nexport function findToolSpec(name: string, filter?: ToolCategoryFilter): ToolSpec \| undefined {\n for (const [catName, cat] of categories) {\n if (!allowed(catName, filter)) continue\n const spec = cat.specs.find(s => s.name === name)\n if (spec) return spec\n }\n return undefined\n}\n\n/\n tool name 의 카테고리 (read/write/action/external). 미등록 tool 은 undefined.\n * assistant.ts 의 isReadTool / isWriteTool / isActionTool 이 이 함수에 위임할 수 있다.\n /\nexport function getToolKind(name: string, filter?: ToolCategoryFilter): ToolSpec['kind'] \| undefined {\n return findToolSpec(name, filter)?.kind\n}\n\n/\n 등록된 tool 인지. dispatch path 가 hardcoded set 와 registry 양쪽 fallback 시 사용.\n /\nexport function hasTool(name: string, filter?: ToolCategoryFilter): boolean {\n return findToolSpec(name, filter) !== undefined\n}\n\n/\n 카테고리 이름으로 spec 만 추출.\n /\nexport function getCategorySpecs(categoryName: string): ReadonlyArray<ToolSpec> {\n return categories.get(categoryName)?.specs ?? []\n}\n\n/\n 테스트 전용 — 모든 등록 해제. 운영 환경에서 호출 금지.\n \n jest 의 setupFilesAfterEach 또는 명시적 afterEach 에서 호출해 테스트 간 격리.\n * 실제로 STYLING_TOOLS 는 board-ai 자체 부트스트랩에서 다시 등록되므로 clear 후\n * 명시 register 가 필요한 것은 동적 카테고리 (board-import 등) 뿐.\n */\nexport function clearToolRegistry(): void {\n categories.clear()\n}\n"]}

package/dist-server/service/tool-registry/types.d.ts CHANGED Viewed

@@ -124,6 +124,16 @@ export interface ToolCategory {
      *
      * 규율은 도구를 등록한 쪽이 소유한다. 호스트(board-ai)는 도메인을 모르는 채 **노출된 카테고리의
      * 규율만 모아 붙인다** — 도메인 지식이 호스트 프롬프트로 새지 않는다.
+     *
+     * ── 왜 필수인가 (2026-09-09) ──────────────────────────────────────────────
+     * 선택 필드였다. 그래서 위에 적힌 사고를 아는 사람만 채웠고, 세 제품이 각자 도구를 붙이기
+     * 시작한 지금 **채운 넷과 안 채운 하나**가 있었다.
+     *
+     * 안 채운 쪽은 조용하다 — 등록은 성공하고 부팅도 성공하고, 모델이 도구를 덜 부르거나 지어낸
+     * 뒤에 사람이 화면을 보고 안다. **두 개를 기억해야 성립하는 규칙은 다음 새 카테고리까지만
+     * 간다.** 그래서 기억이 아니라 등록이 거절한다(§`registerToolCategory`).
+     *
+     * 빈 문자열도 거절한다. 「없음」을 「적었다」로 위장하는 값이 통과하면 이 강제가 형식이 된다.
      */
-    guidance?: string;
+    guidance: string;
 }

package/dist-server/service/tool-registry/types.js.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"types.js","sourceRoot":"","sources":["../../../server/service/tool-registry/types.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,uEAAuE;AACvE,kEAAkE;AAClE,iFAAiF;AACjF,mEAAmE;AACnE,wDAAwD","sourcesContent":["/*\n Tool Registry — board-ai 의 LLM tool 노출 plugin point.\n \n 동기:\n * 기존엔 board-ai 가 자기 도메인 (board edit) tool 들만 hardcoded 정의했고, styling\n * 영역만 STYLING_TOOLS registry 로 분리되어 있었다. 외부 도메인 패키지 (board-import,\n * fmsim 등) 가 자기 tool 을 LLM 에 노출하려면 board-ai 자체를 fork/수정해야 했다.\n \n 본 registry 는 외부 패키지가 server bootstrap 시 자기 tool category 를 등록하면\n * assistant.ts 의 buildBoardEditTools / dispatch / isWriteTool 등이 자동으로 통합\n * 하도록 한다. styling-tools 의 single-source-of-truth 패턴을 일반화한 형태.\n \n 설계 원칙:\n * - 카테고리별 builder 시그니처 다양성을 통합: read 는 (args, ctx) → any,\n * write 는 (args, components) → BoardEditOp[], action 은 (args) → BoardActionOp.\n * 하나의 ToolSpec 에 모든 시그니처를 union 으로 담지 않고, 카테고리에 맞는\n * builder 만 채우면 되도록 카테고리별 sub-interface 분리.\n * - kind 필드로 자가 분류: registry 가 isReadTool / isWriteTool 자동 도출.\n * hardcoded set 동기화 누락 위험 제거.\n * - 점진 마이그레이션: 기존 STYLING_TOOLS 가 본 registry 의 첫 사용자.\n * 점진적으로 다른 hardcoded tool 들 (addComponent / alignComponents 등) 도\n * 같은 registry 로 흡수 가능. 한 단계씩 byte-단위 동등성 단위 테스트 보장.\n /\n// 본 registry 는 LLM tool 노출 plugin point 에 한정되므로 도메인 type (BoardEditOp,\n// BoardActionOp 등) 은 알지 않는다. builder return 은 unknown 으로 두고, 카테고리\n// dispatcher (board-ai 의 toolCallToBoardEditOp / toolCallToBoardActionOp 등) 가 자기\n// 도메인 type 으로 좁힌다. 사용자가 ToolSpec<TWrite, TAction> generic 까지 정밀화하면\n// 좋겠지만, 11~50 개 spec 마다 type 인자 전파가 부담이라 unknown 으로 합의.\n\n// ── 카테고리별 builder 시그니처 ──────────────────────────────────────\n\n/\n Read tool — server 측 즉시 실행, 결과를 LLM 에 회신. board model 변경 X.\n * 예: getSelection / findComponents / importSession (query)\n /\nexport type ReadToolBuilder = (\n args: any,\n context: ReadToolContext\n) => any \| Promise<any>\n\nexport interface ReadToolContext {\n /* 현재 board model — 일부 read tool 이 사용 (getSelection 등). /\n board?: any\n /* 현재 선택된 refids. /\n selectedRefids?: number[]\n /* 호출자 도메인 / 사용자 / 트랜잭션. registry 외부에서 주입. /\n state?: any\n /* 이외 주입은 카테고리별로 자유. tool 등록자가 type 좁힐 수 있도록 unknown 으로 보존. /\n [k: string]: any\n}\n\n/\n Write tool — domain edit op 발생. host 가 patch 적용 후 영속화.\n * 예: board-ai 의 addComponent / setFill / modifyBoard.\n \n builder 의 return type 은 unknown 으로 둔다 — 도메인별 dispatcher (예: board-ai 의\n * toolCallToBoardEditOp) 가 자기 EditOp[] 로 cast. ops/errors wrapper 형태도 동일 의미.\n /\nexport type WriteToolBuilder = (\n args: any,\n context: WriteToolContext\n) => any[] \| { ops: any[]; errors?: string[] } \| null\n\nexport interface WriteToolContext {\n components?: ReadonlyArray<any>\n [k: string]: any\n}\n\n/\n Action tool — ephemeral scene 조작 (select / center / fit / sceneMode).\n * board model 변경 X, undo 영향 X. host 가 별도 channel 로 적용.\n \n return type 은 unknown — 도메인별 dispatcher (예: board-ai 의 toolCallToBoardActionOp)\n * 가 자기 BoardActionOp 으로 cast.\n /\nexport type ActionToolBuilder = (args: any) => any \| null\n\n/\n External-call tool — 외부 service / mutation / RPC 호출. 직접 board model 영향 X\n * (별도 entity 변경은 가능). 결과는 LLM 에 회신.\n \n board-import 의 importBoardAsync / materializeImportSession 같이 board-ai 외부\n * 도메인을 호출하는 tool 의 카테고리.\n /\nexport type ExternalToolBuilder = (\n args: any,\n context: ExternalToolContext\n) => any \| Promise<any>\n\nexport interface ExternalToolContext {\n state?: any\n [k: string]: any\n}\n\n// ── ToolSpec — 카테고리별 변형 ──────────────────────────────────────\n\n/\n 모든 ToolSpec 공통 메타데이터.\n /\nexport interface ToolSpecBase {\n /* AIToolCall.name 매칭. 전 카테고리 통틀어 unique. /\n name: string\n /* 기능 설명 (영문 위주). LLM 의 tool description 으로 사용. /\n description: string\n /\n 선택 — 정책 / 테마 가이드 단문. tool description 끝에 자동 부착.\n * styling-tools 의 themeNote 와 동일 의미. 기타 카테고리도 사용 가능.\n /\n themeNote?: string\n /* JSON Schema for parameters — LLM tool schema 에 그대로 노출. /\n schema: any\n}\n\nexport interface ReadToolSpec extends ToolSpecBase {\n kind: 'read'\n builder: ReadToolBuilder\n}\n\nexport interface WriteToolSpec extends ToolSpecBase {\n kind: 'write'\n builder: WriteToolBuilder\n}\n\nexport interface ActionToolSpec extends ToolSpecBase {\n kind: 'action'\n builder: ActionToolBuilder\n}\n\nexport interface ExternalToolSpec extends ToolSpecBase {\n kind: 'external'\n builder: ExternalToolBuilder\n}\n\nexport type ToolSpec = ReadToolSpec \| WriteToolSpec \| ActionToolSpec \| ExternalToolSpec\n\n// ── 카테고리 (등록 단위) ─────────────────────────────────────────────\n\n/\n 한 도메인 / 패키지가 등록하는 tool 묶음.\n * 카테고리 이름은 식별자 (debug log / 분쟁 시 origin 추적). unique.\n /\nexport interface ToolCategory {\n /* 등록 식별자. 예: 'styling', 'board-import', 'fmsim'. /\n name: string\n /* 이 카테고리에 속한 tool spec 들. /\n specs: ToolSpec[]\n /* 선택 — 디버깅용 짧은 설명. /\n description?: string\n /\n 이 카테고리 도구를 어떻게 써야 하는지에 대한 규율 — 노출된 대화의 시스템 프롬프트에 실린다.\n \n 왜 필요한가: 도구 목록(이름·설명·스키마)만 보내면 모델은 \"무엇이 있는지\" 는 알지만 \"언제 반드시\n * 불러야 하는지\" 는 모른다. 실제로 그 공백에서 사고가 났다 — 조치 요청에 `proposeAction` 을 부르지\n * 않고 \"제안해 두었습니다\" 라고만 답해, 사용자에게는 없는 버튼을 누르라고 안내했다.\n \n 규율은 도구를 등록한 쪽이 소유한다. 호스트(board-ai)는 도메인을 모르는 채 *노출된 카테고리의\n 규율만 모아 붙인다** — 도메인 지식이 호스트 프롬프트로 새지 않는다.\n */\n guidance?: string\n}\n"]}
1	+ {"version":3,"file":"types.js","sourceRoot":"","sources":["../../../server/service/tool-registry/types.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,uEAAuE;AACvE,kEAAkE;AAClE,iFAAiF;AACjF,mEAAmE;AACnE,wDAAwD","sourcesContent":["/*\n Tool Registry — board-ai 의 LLM tool 노출 plugin point.\n \n 동기:\n * 기존엔 board-ai 가 자기 도메인 (board edit) tool 들만 hardcoded 정의했고, styling\n * 영역만 STYLING_TOOLS registry 로 분리되어 있었다. 외부 도메인 패키지 (board-import,\n * fmsim 등) 가 자기 tool 을 LLM 에 노출하려면 board-ai 자체를 fork/수정해야 했다.\n \n 본 registry 는 외부 패키지가 server bootstrap 시 자기 tool category 를 등록하면\n * assistant.ts 의 buildBoardEditTools / dispatch / isWriteTool 등이 자동으로 통합\n * 하도록 한다. styling-tools 의 single-source-of-truth 패턴을 일반화한 형태.\n \n 설계 원칙:\n * - 카테고리별 builder 시그니처 다양성을 통합: read 는 (args, ctx) → any,\n * write 는 (args, components) → BoardEditOp[], action 은 (args) → BoardActionOp.\n * 하나의 ToolSpec 에 모든 시그니처를 union 으로 담지 않고, 카테고리에 맞는\n * builder 만 채우면 되도록 카테고리별 sub-interface 분리.\n * - kind 필드로 자가 분류: registry 가 isReadTool / isWriteTool 자동 도출.\n * hardcoded set 동기화 누락 위험 제거.\n * - 점진 마이그레이션: 기존 STYLING_TOOLS 가 본 registry 의 첫 사용자.\n * 점진적으로 다른 hardcoded tool 들 (addComponent / alignComponents 등) 도\n * 같은 registry 로 흡수 가능. 한 단계씩 byte-단위 동등성 단위 테스트 보장.\n /\n// 본 registry 는 LLM tool 노출 plugin point 에 한정되므로 도메인 type (BoardEditOp,\n// BoardActionOp 등) 은 알지 않는다. builder return 은 unknown 으로 두고, 카테고리\n// dispatcher (board-ai 의 toolCallToBoardEditOp / toolCallToBoardActionOp 등) 가 자기\n// 도메인 type 으로 좁힌다. 사용자가 ToolSpec<TWrite, TAction> generic 까지 정밀화하면\n// 좋겠지만, 11~50 개 spec 마다 type 인자 전파가 부담이라 unknown 으로 합의.\n\n// ── 카테고리별 builder 시그니처 ──────────────────────────────────────\n\n/\n Read tool — server 측 즉시 실행, 결과를 LLM 에 회신. board model 변경 X.\n * 예: getSelection / findComponents / importSession (query)\n /\nexport type ReadToolBuilder = (\n args: any,\n context: ReadToolContext\n) => any \| Promise<any>\n\nexport interface ReadToolContext {\n /* 현재 board model — 일부 read tool 이 사용 (getSelection 등). /\n board?: any\n /* 현재 선택된 refids. /\n selectedRefids?: number[]\n /* 호출자 도메인 / 사용자 / 트랜잭션. registry 외부에서 주입. /\n state?: any\n /* 이외 주입은 카테고리별로 자유. tool 등록자가 type 좁힐 수 있도록 unknown 으로 보존. /\n [k: string]: any\n}\n\n/\n Write tool — domain edit op 발생. host 가 patch 적용 후 영속화.\n * 예: board-ai 의 addComponent / setFill / modifyBoard.\n \n builder 의 return type 은 unknown 으로 둔다 — 도메인별 dispatcher (예: board-ai 의\n * toolCallToBoardEditOp) 가 자기 EditOp[] 로 cast. ops/errors wrapper 형태도 동일 의미.\n /\nexport type WriteToolBuilder = (\n args: any,\n context: WriteToolContext\n) => any[] \| { ops: any[]; errors?: string[] } \| null\n\nexport interface WriteToolContext {\n components?: ReadonlyArray<any>\n [k: string]: any\n}\n\n/\n Action tool — ephemeral scene 조작 (select / center / fit / sceneMode).\n * board model 변경 X, undo 영향 X. host 가 별도 channel 로 적용.\n \n return type 은 unknown — 도메인별 dispatcher (예: board-ai 의 toolCallToBoardActionOp)\n * 가 자기 BoardActionOp 으로 cast.\n /\nexport type ActionToolBuilder = (args: any) => any \| null\n\n/\n External-call tool — 외부 service / mutation / RPC 호출. 직접 board model 영향 X\n * (별도 entity 변경은 가능). 결과는 LLM 에 회신.\n \n board-import 의 importBoardAsync / materializeImportSession 같이 board-ai 외부\n * 도메인을 호출하는 tool 의 카테고리.\n /\nexport type ExternalToolBuilder = (\n args: any,\n context: ExternalToolContext\n) => any \| Promise<any>\n\nexport interface ExternalToolContext {\n state?: any\n [k: string]: any\n}\n\n// ── ToolSpec — 카테고리별 변형 ──────────────────────────────────────\n\n/\n 모든 ToolSpec 공통 메타데이터.\n /\nexport interface ToolSpecBase {\n /* AIToolCall.name 매칭. 전 카테고리 통틀어 unique. /\n name: string\n /* 기능 설명 (영문 위주). LLM 의 tool description 으로 사용. /\n description: string\n /\n 선택 — 정책 / 테마 가이드 단문. tool description 끝에 자동 부착.\n * styling-tools 의 themeNote 와 동일 의미. 기타 카테고리도 사용 가능.\n /\n themeNote?: string\n /* JSON Schema for parameters — LLM tool schema 에 그대로 노출. /\n schema: any\n}\n\nexport interface ReadToolSpec extends ToolSpecBase {\n kind: 'read'\n builder: ReadToolBuilder\n}\n\nexport interface WriteToolSpec extends ToolSpecBase {\n kind: 'write'\n builder: WriteToolBuilder\n}\n\nexport interface ActionToolSpec extends ToolSpecBase {\n kind: 'action'\n builder: ActionToolBuilder\n}\n\nexport interface ExternalToolSpec extends ToolSpecBase {\n kind: 'external'\n builder: ExternalToolBuilder\n}\n\nexport type ToolSpec = ReadToolSpec \| WriteToolSpec \| ActionToolSpec \| ExternalToolSpec\n\n// ── 카테고리 (등록 단위) ─────────────────────────────────────────────\n\n/\n 한 도메인 / 패키지가 등록하는 tool 묶음.\n * 카테고리 이름은 식별자 (debug log / 분쟁 시 origin 추적). unique.\n /\nexport interface ToolCategory {\n /* 등록 식별자. 예: 'styling', 'board-import', 'fmsim'. /\n name: string\n /* 이 카테고리에 속한 tool spec 들. /\n specs: ToolSpec[]\n /* 선택 — 디버깅용 짧은 설명. /\n description?: string\n /\n 이 카테고리 도구를 어떻게 써야 하는지에 대한 규율 — 노출된 대화의 시스템 프롬프트에 실린다.\n \n 왜 필요한가: 도구 목록(이름·설명·스키마)만 보내면 모델은 \"무엇이 있는지\" 는 알지만 \"언제 반드시\n * 불러야 하는지\" 는 모른다. 실제로 그 공백에서 사고가 났다 — 조치 요청에 `proposeAction` 을 부르지\n * 않고 \"제안해 두었습니다\" 라고만 답해, 사용자에게는 없는 버튼을 누르라고 안내했다.\n \n 규율은 도구를 등록한 쪽이 소유한다. 호스트(board-ai)는 도메인을 모르는 채 *노출된 카테고리의\n 규율만 모아 붙인다** — 도메인 지식이 호스트 프롬프트로 새지 않는다.\n \n ── 왜 필수인가 (2026-09-09) ──────────────────────────────────────────────\n * 선택 필드였다. 그래서 위에 적힌 사고를 아는 사람만 채웠고, 세 제품이 각자 도구를 붙이기\n * 시작한 지금 채운 넷과 안 채운 하나가 있었다.\n \n 안 채운 쪽은 조용하다 — 등록은 성공하고 부팅도 성공하고, 모델이 도구를 덜 부르거나 지어낸\n * 뒤에 사람이 화면을 보고 안다. *두 개를 기억해야 성립하는 규칙은 다음 새 카테고리까지만\n 간다.** 그래서 기억이 아니라 등록이 거절한다(§`registerToolCategory`).\n \n 빈 문자열도 거절한다. 「없음」을 「적었다」로 위장하는 값이 통과하면 이 강제가 형식이 된다.\n */\n guidance: string\n}\n"]}

package/dist-server/service/utils/grounding.d.ts CHANGED Viewed

@@ -17,9 +17,15 @@
  * 기준이 없다. 그래서 보수적으로 id 관례(하이픈 포함 소문자-영숫자)만 추출한다 —
  * 한국어·하이픈 없는 일반어는 애초에 매칭하지 않는다.
  */
-/** 문자열에서 id 후보 토큰을 뽑는다(중복 제거). */
+/** 문자열에서 id 후보 토큰을 뽑는다(중복 제거). **쓰인 그대로** 담는다 — 사람에게 보일 값이다. */
 export declare function extractIdTokens(s: string): Set<string>;
-/** 답이 언급한 id − 근거 코퍼스의 id = 미확인(환각 후보). 순서는 답에 나온 순서. */
+/**
+ * 답이 언급한 id − 근거 코퍼스의 id = 미확인(환각 후보). 순서는 답에 나온 순서.
+ *
+ * **대조는 대소문자를 무시한다.** 모델이 `WO-2609B` 를 `wo-2609b` 로 적는 것은 표기이지 다른
+ * 대상이 아니다. 엄격히 보면 그 한 글자 차이로 정상 답이 경고를 받고, 그런 경고가 몇 번 나오면
+ * 사람이 경고 자체를 안 본다. 대소문자만 다른 두 식별자를 쓰는 체계라면 그것이 먼저 고칠 문제다.
+ */
 export declare function checkGrounding(reply: string, groundedCorpus: string): string[];
 /**
  * 소음 제거 — 미확인 토큰 중 **엔티티 참조로 보이는 것만** 남긴다.
@@ -42,3 +48,20 @@ export declare function filterEntityLike(tokens: string[], groundedCorpus: strin
  * 반환이 비면 접지 정상(경고 없음).
  */
 export declare function groundingWarnings(reply: string, groundedCorpus: string): string[];
+export interface GroundingSources {
+    /** 시스템 프롬프트 — 생성 가능한 타입 목록·규칙 등. 여기 있는 이름을 말하는 것은 정상이다. */
+    systemPrompt?: string;
+    /** 호스트가 대화 앞에 붙인 문맥 — 보드 요약·현장 상태·저작 중인 자산. */
+    hostContext?: string;
+    /** 사용자·어시스턴트 이력 텍스트. 사용자가 말한 식별자를 되받는 것은 정상이다. */
+    messages?: string[];
+    /**
+     * `tool_result` 로 회신된 **원문**(시간순).
+     *
+     * ⚠ `toolUsages[].result` 를 넣지 말 것 — 그것은 화면 표시용으로 깊이·길이가 잘린 값이다. 잘려
+     * 나간 식별자를 「근거 없음」으로 오판한다. 넣을 값은 `AgenticLoopResult.groundedTexts` 다.
+     */
+    toolResults?: string[];
+}
+/** 근거집합을 한 덩어리로. 식별자 토큰만 대조하므로 구분자는 개행으로 충분하다. */
+export declare function buildGroundedCorpus(sources: GroundingSources): string;

package/dist-server/service/utils/grounding.js CHANGED Viewed

@@ -23,20 +23,43 @@ exports.extractIdTokens = extractIdTokens;
 exports.checkGrounding = checkGrounding;
 exports.filterEntityLike = filterEntityLike;
 exports.groundingWarnings = groundingWarnings;
-/** id 관례 — 소문자로 시작, 하이픈으로 이어진 소문자·숫자 토큰. `fk-1` `weld-station` `a-dc` 등. */
-const ID_TOKEN = /[a-z][a-z0-9]*(?:-[a-z0-9]+)+/g;
-/** 문자열에서 id 후보 토큰을 뽑는다(중복 제거). */
+exports.buildGroundedCorpus = buildGroundedCorpus;
+/**
+ * id 관례 — 영문자로 시작, 하이픈으로 이어진 영숫자 토큰. `fk-1` · `weld-station` · `WO-ECU-2609B`.
+ *
+ * ── 소문자만 보다가 두 제품을 통째로 놓치고 있었다 (2026-09-10) ──────────────
+ * 이 패턴이 `[a-z]…` 였다. 그래서 **대문자 식별자를 쓰는 제품에는 이 가드가 아예 닿지 않았다.**
+ * 실측:
+ *
+ *   'WO-ECU-SET-2609B'  → []      plant 의 실제 오더 이름(seed/sets/svm-gunsan.ts)
+ *   'TAG-FUNC-AGING'    → []      트윈의 태그
+ *   'dock-3'            → ['dock-3']
+ *
+ * 즉 「지어낸 오더 번호를 잡는다」는 보장이 plant 에서는 성립하지 않았고, 경고가 0 건인 것이
+ * 「깨끗하다」로 읽혔다. 없는 것과 안 보는 것이 같은 그림이었다.
+ *
+ * 넓혀도 소음이 늘지 않는 이유는 `filterEntityLike` 가 뒤에 있기 때문이다 — `Read-Only` 는 숫자도
+ * 없고 근거에 `Read-` 계열도 없어 그대로 걸러진다.
+ */
+const ID_TOKEN = /[A-Za-z][A-Za-z0-9]*(?:-[A-Za-z0-9]+)+/g;
+/** 문자열에서 id 후보 토큰을 뽑는다(중복 제거). **쓰인 그대로** 담는다 — 사람에게 보일 값이다. */
 function extractIdTokens(s) {
     const out = new Set();
     for (const m of (s ?? '').matchAll(ID_TOKEN))
         out.add(m[0]);
     return out;
 }
-/** 답이 언급한 id − 근거 코퍼스의 id = 미확인(환각 후보). 순서는 답에 나온 순서. */
+/**
+ * 답이 언급한 id − 근거 코퍼스의 id = 미확인(환각 후보). 순서는 답에 나온 순서.
+ *
+ * **대조는 대소문자를 무시한다.** 모델이 `WO-2609B` 를 `wo-2609b` 로 적는 것은 표기이지 다른
+ * 대상이 아니다. 엄격히 보면 그 한 글자 차이로 정상 답이 경고를 받고, 그런 경고가 몇 번 나오면
+ * 사람이 경고 자체를 안 본다. 대소문자만 다른 두 식별자를 쓰는 체계라면 그것이 먼저 고칠 문제다.
+ */
 function checkGrounding(reply, groundedCorpus) {
-    const grounded = extractIdTokens(groundedCorpus);
+    const grounded = new Set([...extractIdTokens(groundedCorpus)].map(id => id.toLowerCase()));
     const mentioned = extractIdTokens(reply);
-    return [...mentioned].filter(id => !grounded.has(id));
+    return [...mentioned].filter(id => !grounded.has(id.toLowerCase()));
 }
 /**
  * 소음 제거 — 미확인 토큰 중 **엔티티 참조로 보이는 것만** 남긴다.
@@ -54,10 +77,12 @@ function checkGrounding(reply, groundedCorpus) {
  * 잡으려면 일반 영어 합성어를 함께 잡게 되므로, 이 가드는 **정확도를 택하고 재현율을 버린다**.
  */
 function filterEntityLike(tokens, groundedCorpus) {
+    /* 계열 대조도 대소문자를 무시한다 — `checkGrounding` 과 같은 규칙이어야 한다. 한쪽만 엄격하면
+     * 근거에 `WO-1` 이 있는데 답의 `wo-7` 이 계열 밖으로 새어 경고를 놓친다. */
     const families = new Set();
     for (const id of extractIdTokens(groundedCorpus))
-        families.add(id.split('-')[0]);
-    return tokens.filter(t => /[0-9]/.test(t) || families.has(t.split('-')[0]));
+        families.add(id.split('-')[0].toLowerCase());
+    return tokens.filter(t => /[0-9]/.test(t) || families.has(t.split('-')[0].toLowerCase()));
 }
 /**
  * 접지 검사 + 소음 제거를 한 번에. 대화면에서 쓰는 기본 진입점.
@@ -66,4 +91,15 @@ function filterEntityLike(tokens, groundedCorpus) {
 function groundingWarnings(reply, groundedCorpus) {
     return filterEntityLike(checkGrounding(reply, groundedCorpus), groundedCorpus);
 }
+/** 근거집합을 한 덩어리로. 식별자 토큰만 대조하므로 구분자는 개행으로 충분하다. */
+function buildGroundedCorpus(sources) {
+    return [
+        sources.systemPrompt ?? '',
+        sources.hostContext ?? '',
+        ...(sources.messages ?? []),
+        ...(sources.toolResults ?? [])
+    ]
+        .filter(Boolean)
+        .join('\n');
+}
 //# sourceMappingURL=grounding.js.map

package/dist-server/service/utils/grounding.js.map CHANGED Viewed

	@@ -1 +1 @@
1	- {"version":3,"file":"grounding.js","sourceRoot":"","sources":["../../../server/service/utils/grounding.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;GAkBG;;~~AAMH~~,0CAIC;~~AAGD~~,wCAIC;AAiBD,~~4CAIC~~;AAMD,8CAEC;~~AA5CD~~,~~4EAA4E~~;~~AAC5E~~,MAAM,QAAQ,GAAG,~~gCAAgC~~,CAAA;~~AAEjD~~,~~kCAAkC~~;~~AAClC~~,SAAgB,eAAe,CAAC,CAAS;IACvC,MAAM,GAAG,GAAG,IAAI,GAAG,EAAU,CAAA;IAC7B,KAAK,MAAM,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC;QAAE,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;IAC3D,OAAO,GAAG,CAAA;AACZ,CAAC;AAED~~,yDAAyD~~;~~AACzD~~,SAAgB,cAAc,CAAC,KAAa,EAAE,cAAsB;IAClE,MAAM,QAAQ,GAAG,eAAe,CAAC,cAAc,CAAC,CAAA;~~IAChD~~,MAAM,SAAS,GAAG,eAAe,CAAC,KAAK,CAAC,CAAA;IACxC,OAAO,CAAC,GAAG,SAAS,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAA;~~AACvD~~,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,SAAgB,gBAAgB,CAAC,MAAgB,EAAE,cAAsB;IACvE,MAAM,QAAQ,GAAG,IAAI,GAAG,EAAU,CAAA;IAClC,KAAK,MAAM,EAAE,IAAI,eAAe,CAAC,cAAc,CAAC;QAAE,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;~~IAChF~~,OAAO,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;~~AAC7E~~,CAAC;AAED;;;GAGG;AACH,SAAgB,iBAAiB,CAAC,KAAa,EAAE,cAAsB;IACrE,OAAO,gBAAgB,CAAC,cAAc,CAAC,KAAK,EAAE,cAAc,CAAC,EAAE,cAAc,CAAC,CAAA;AAChF,CAAC","sourcesContent":["/*\n 접지 가드 — LLM 의 답이 자기가 받은 근거 안에서 말했는지 검사한다.\n \n ── 왜 필요한가 ─────────────────────────────────────────────────────────────\n * LLM 이 가진 근거는 세 가지뿐이다: 시스템 프롬프트(현재 상태 요약), 사용자·이력 텍스트,\n * 도구 결과(JSON). 답이 그 어디에도 없는 엔티티를 지목하면(존재하지 않는 노드·설비·주문\n * 식별자) 그건 만들어 낸 것이다. 사용자는 그것을 검증할 수단이 없으므로 시스템이 표시해야 한다.\n \n ── 무엇을 하지 않는가 ──────────────────────────────────────────────────────\n * 답을 고치거나 막지 않는다. 구조화된 경고만 낸다(비파괴) — 문장을 다시 쓰게 하는 판단은\n * 호출부(대화면)의 정책이다. 또한 문장으로 지어낸 상황(\"지게차들이 바쁘게 움직인다\")은\n * 이 가드가 잡지 못한다. 그건 도구를 아예 부르지 않고 답한 경우이고, 별도 레버(도구 호출\n * 강제)로 다뤄야 한다. 이 가드의 사정거리는 식별자다.\n \n ── 왜 식별자만 보는가 ──────────────────────────────────────────────────────\n * 식별자는 근거집합과 문자 단위로 대조할 수 있는 유일한 요소다. 서술문의 사실성은 대조할\n * 기준이 없다. 그래서 보수적으로 id 관례(하이픈 포함 소문자-영숫자)만 추출한다 —\n * 한국어·하이픈 없는 일반어는 애초에 매칭하지 않는다.\n /\n\n/* id 관례 — ~~소문자로~~ 시작, 하이픈으로 이어진 ~~소문자·숫자~~ 토큰. `fk-1` `weld-station` `a-dc` 등. /\nconst ID_TOKEN = /[a-z][a-z0-9](?:-[a-z0-9]+)+/g\n\n/** 문자열에서 id 후보 토큰을 뽑는다(중복 제거). /\nexport function extractIdTokens(s: string): Set<string> {\n const out = new Set<string>()\n for (const m of (s ?? '').matchAll(ID_TOKEN)) out.add(m[0])\n return out\n}\n\n/* 답이 언급한 id − 근거 코퍼스의 id = 미확인(환각 후보). 순서는 답에 나온 ~~순서.~~ /\nexport function checkGrounding(reply: string, groundedCorpus: string): string[] {\n const grounded = extractIdTokens(groundedCorpus)\n const mentioned = extractIdTokens(reply)\n return [...mentioned].filter(id => !grounded.has(id))\n}\n\n/\n 소음 제거 — 미확인 토큰 중 엔티티 참조로 보이는 것만 남긴다.\n \n 왜 필요한가: id 관례는 영어 합성어와 구별되지 않는다(`read-only` `hand-off` `real-time`\n * `zero-to-twin`). 영어로 답하는 대화면에서 그것들을 \"근거 없는 식별자\" 로 경고하면 경고가\n * 소음이 되고, 소음이 되면 사용자는 경고 자체를 무시한다 — 가드가 있으나 없느니만 못해진다.\n \n 판정 기준(둘 중 하나):\n * ① 숫자를 포함한다 — `dock-3` `fk-12`. 일반 영어 합성어에는 숫자가 없다.\n * ② 근거에 있는 어떤 id 와 첫 마디를 공유한다 — 근거가 `dock-1` 을 담고 있는데 답이\n * `dock-7` 을 말하면 같은 계열의 없는 대상을 지목한 것이다.\n \n 놓치는 것: 숫자도 없고 근거에 같은 계열도 없는 순수 창작(`weld-station`). 그 경우까지\n * 잡으려면 일반 영어 합성어를 함께 잡게 되므로, 이 가드는 정확도를 택하고 재현율을 버린다.\n /\nexport function filterEntityLike(tokens: string[], groundedCorpus: string): string[] {\n const families = new Set<string>()\n for (const id of extractIdTokens(groundedCorpus)) families.add(id.split('-')[0])\n return tokens.filter(t => /[0-9]/.test(t) \|\| families.has(t.split('-')[0]))\n}\n\n/\n 접지 검사 + 소음 제거를 한 번에. 대화면에서 쓰는 기본 진입점.\n * 반환이 비면 접지 정상(경고 없음).\n */\nexport function groundingWarnings(reply: string, groundedCorpus: string): string[] {\n return filterEntityLike(checkGrounding(reply, groundedCorpus), groundedCorpus)\n}\n"]}
1	+ {"version":3,"file":"grounding.js","sourceRoot":"","sources":["../../../server/service/utils/grounding.ts"],"names":[],"mappings":";AAAA;;;;;;;;;;;;;;;;;;GAkBG;;AAsBH,0CAIC;AASD,wCAIC;AAiBD,4CAMC;AAMD,8CAEC;AAiCD,kDASC;AA9GD;;;;;;;;;;;;;;;;GAgBG;AACH,MAAM,QAAQ,GAAG,yCAAyC,CAAA;AAE1D,gEAAgE;AAChE,SAAgB,eAAe,CAAC,CAAS;IACvC,MAAM,GAAG,GAAG,IAAI,GAAG,EAAU,CAAA;IAC7B,KAAK,MAAM,CAAC,IAAI,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC,QAAQ,CAAC,QAAQ,CAAC;QAAE,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,CAAA;IAC3D,OAAO,GAAG,CAAA;AACZ,CAAC;AAED;;;;;;GAMG;AACH,SAAgB,cAAc,CAAC,KAAa,EAAE,cAAsB;IAClE,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,CAAC,GAAG,eAAe,CAAC,cAAc,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,EAAE,CAAC,EAAE,CAAC,WAAW,EAAE,CAAC,CAAC,CAAA;IAC1F,MAAM,SAAS,GAAG,eAAe,CAAC,KAAK,CAAC,CAAA;IACxC,OAAO,CAAC,GAAG,SAAS,CAAC,CAAC,MAAM,CAAC,EAAE,CAAC,EAAE,CAAC,CAAC,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC,WAAW,EAAE,CAAC,CAAC,CAAA;AACrE,CAAC;AAED;;;;;;;;;;;;;;GAcG;AACH,SAAgB,gBAAgB,CAAC,MAAgB,EAAE,cAAsB;IACvE;yDACqD;IACrD,MAAM,QAAQ,GAAG,IAAI,GAAG,EAAU,CAAA;IAClC,KAAK,MAAM,EAAE,IAAI,eAAe,CAAC,cAAc,CAAC;QAAE,QAAQ,CAAC,GAAG,CAAC,EAAE,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC,CAAA;IAC9F,OAAO,MAAM,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,QAAQ,CAAC,GAAG,CAAC,CAAC,CAAC,KAAK,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,WAAW,EAAE,CAAC,CAAC,CAAA;AAC3F,CAAC;AAED;;;GAGG;AACH,SAAgB,iBAAiB,CAAC,KAAa,EAAE,cAAsB;IACrE,OAAO,gBAAgB,CAAC,cAAc,CAAC,KAAK,EAAE,cAAc,CAAC,EAAE,cAAc,CAAC,CAAA;AAChF,CAAC;AAgCD,kDAAkD;AAClD,SAAgB,mBAAmB,CAAC,OAAyB;IAC3D,OAAO;QACL,OAAO,CAAC,YAAY,IAAI,EAAE;QAC1B,OAAO,CAAC,WAAW,IAAI,EAAE;QACzB,GAAG,CAAC,OAAO,CAAC,QAAQ,IAAI,EAAE,CAAC;QAC3B,GAAG,CAAC,OAAO,CAAC,WAAW,IAAI,EAAE,CAAC;KAC/B;SACE,MAAM,CAAC,OAAO,CAAC;SACf,IAAI,CAAC,IAAI,CAAC,CAAA;AACf,CAAC","sourcesContent":["/*\n 접지 가드 — LLM 의 답이 자기가 받은 근거 안에서 말했는지 검사한다.\n \n ── 왜 필요한가 ─────────────────────────────────────────────────────────────\n * LLM 이 가진 근거는 세 가지뿐이다: 시스템 프롬프트(현재 상태 요약), 사용자·이력 텍스트,\n * 도구 결과(JSON). 답이 그 어디에도 없는 엔티티를 지목하면(존재하지 않는 노드·설비·주문\n * 식별자) 그건 만들어 낸 것이다. 사용자는 그것을 검증할 수단이 없으므로 시스템이 표시해야 한다.\n \n ── 무엇을 하지 않는가 ──────────────────────────────────────────────────────\n * 답을 고치거나 막지 않는다. 구조화된 경고만 낸다(비파괴) — 문장을 다시 쓰게 하는 판단은\n * 호출부(대화면)의 정책이다. 또한 문장으로 지어낸 상황(\"지게차들이 바쁘게 움직인다\")은\n * 이 가드가 잡지 못한다. 그건 도구를 아예 부르지 않고 답한 경우이고, 별도 레버(도구 호출\n * 강제)로 다뤄야 한다. 이 가드의 사정거리는 식별자다.\n \n ── 왜 식별자만 보는가 ──────────────────────────────────────────────────────\n * 식별자는 근거집합과 문자 단위로 대조할 수 있는 유일한 요소다. 서술문의 사실성은 대조할\n * 기준이 없다. 그래서 보수적으로 id 관례(하이픈 포함 소문자-영숫자)만 추출한다 —\n * 한국어·하이픈 없는 일반어는 애초에 매칭하지 않는다.\n /\n\n/\n id 관례 — 영문자로 시작, 하이픈으로 이어진 영숫자 토큰. `fk-1` · `weld-station` · `WO-ECU-2609B`.\n \n ── 소문자만 보다가 두 제품을 통째로 놓치고 있었다 (2026-09-10) ──────────────\n * 이 패턴이 `[a-z]…` 였다. 그래서 대문자 식별자를 쓰는 제품에는 이 가드가 아예 닿지 않았다.\n * 실측:\n \n 'WO-ECU-SET-2609B' → [] plant 의 실제 오더 이름(seed/sets/svm-gunsan.ts)\n * 'TAG-FUNC-AGING' → [] 트윈의 태그\n * 'dock-3' → ['dock-3']\n \n 즉 「지어낸 오더 번호를 잡는다」는 보장이 plant 에서는 성립하지 않았고, 경고가 0 건인 것이\n * 「깨끗하다」로 읽혔다. 없는 것과 안 보는 것이 같은 그림이었다.\n \n 넓혀도 소음이 늘지 않는 이유는 `filterEntityLike` 가 뒤에 있기 때문이다 — `Read-Only` 는 숫자도\n * 없고 근거에 `Read-` 계열도 없어 그대로 걸러진다.\n /\nconst ID_TOKEN = /[A-Za-z][A-Za-z0-9](?:-[A-Za-z0-9]+)+/g\n\n/ 문자열에서 id 후보 토큰을 뽑는다(중복 제거). 쓰인 그대로** 담는다 — 사람에게 보일 값이다. /\nexport function extractIdTokens(s: string): Set<string> {\n const out = new Set<string>()\n for (const m of (s ?? '').matchAll(ID_TOKEN)) out.add(m[0])\n return out\n}\n\n/\n 답이 언급한 id − 근거 코퍼스의 id = 미확인(환각 후보). 순서는 답에 나온 순서.\n \n 대조는 대소문자를 무시한다. 모델이 `WO-2609B` 를 `wo-2609b` 로 적는 것은 표기이지 다른\n * 대상이 아니다. 엄격히 보면 그 한 글자 차이로 정상 답이 경고를 받고, 그런 경고가 몇 번 나오면\n * 사람이 경고 자체를 안 본다. 대소문자만 다른 두 식별자를 쓰는 체계라면 그것이 먼저 고칠 문제다.\n /\nexport function checkGrounding(reply: string, groundedCorpus: string): string[] {\n const grounded = new Set([...extractIdTokens(groundedCorpus)].map(id => id.toLowerCase()))\n const mentioned = extractIdTokens(reply)\n return [...mentioned].filter(id => !grounded.has(id.toLowerCase()))\n}\n\n/\n 소음 제거 — 미확인 토큰 중 엔티티 참조로 보이는 것만 남긴다.\n \n 왜 필요한가: id 관례는 영어 합성어와 구별되지 않는다(`read-only` `hand-off` `real-time`\n * `zero-to-twin`). 영어로 답하는 대화면에서 그것들을 \"근거 없는 식별자\" 로 경고하면 경고가\n * 소음이 되고, 소음이 되면 사용자는 경고 자체를 무시한다 — 가드가 있으나 없느니만 못해진다.\n \n 판정 기준(둘 중 하나):\n * ① 숫자를 포함한다 — `dock-3` `fk-12`. 일반 영어 합성어에는 숫자가 없다.\n * ② 근거에 있는 어떤 id 와 첫 마디를 공유한다 — 근거가 `dock-1` 을 담고 있는데 답이\n * `dock-7` 을 말하면 같은 계열의 없는 대상을 지목한 것이다.\n \n 놓치는 것: 숫자도 없고 근거에 같은 계열도 없는 순수 창작(`weld-station`). 그 경우까지\n * 잡으려면 일반 영어 합성어를 함께 잡게 되므로, 이 가드는 정확도를 택하고 재현율을 버린다.\n /\nexport function filterEntityLike(tokens: string[], groundedCorpus: string): string[] {\n / 계열 대조도 대소문자를 무시한다 — `checkGrounding` 과 같은 규칙이어야 한다. 한쪽만 엄격하면\n * 근거에 `WO-1` 이 있는데 답의 `wo-7` 이 계열 밖으로 새어 경고를 놓친다. /\n const families = new Set<string>()\n for (const id of extractIdTokens(groundedCorpus)) families.add(id.split('-')[0].toLowerCase())\n return tokens.filter(t => /[0-9]/.test(t) \|\| families.has(t.split('-')[0].toLowerCase()))\n}\n\n/\n 접지 검사 + 소음 제거를 한 번에. 대화면에서 쓰는 기본 진입점.\n * 반환이 비면 접지 정상(경고 없음).\n /\nexport function groundingWarnings(reply: string, groundedCorpus: string): string[] {\n return filterEntityLike(checkGrounding(reply, groundedCorpus), groundedCorpus)\n}\n\n/\n * ── 근거집합의 정의 (2026-09-10 에 board-ai 에서 옮겨 왔다) ────────────────────\n \n 이 모양이 `board-ai` 에 있었고, 그래서 접지 검사를 하려면 보드 편집기를 지나야 했다. 판정 규칙은\n * 여기 있었는데 무엇을 근거로 볼 것인가가 저기 있었으니, 보드가 없는 제품은 규칙만 있고 쓸 길이\n * 없었다. 자리는 있고 길이 없는 쪽이다.\n \n 옮기면서 칸 하나를 고쳤다: `boardContext` → `hostContext`. 근거는 보드일 수도 있고 공장 현황일\n * 수도 있고 저작 중인 자산일 수도 있다 — 그것을 아는 것은 호스트뿐이다.\n \n 하나라도 빼면 정상 답이 경고를 받는다. 모델이 시스템 프롬프트에서 읽은 타입 이름을 말하는 것은\n * 근거 있는 발언이다. 그래서 이 목록은 「모델이 이 턴에 본 것 전부」이고, 줄이는 것이 아니라 채우는\n * 것이 맞다.\n /\nexport interface GroundingSources {\n /* 시스템 프롬프트 — 생성 가능한 타입 목록·규칙 등. 여기 있는 이름을 말하는 것은 정상이다. /\n systemPrompt?: string\n /* 호스트가 대화 앞에 붙인 문맥 — 보드 요약·현장 상태·저작 중인 자산. /\n hostContext?: string\n /* 사용자·어시스턴트 이력 텍스트. 사용자가 말한 식별자를 되받는 것은 정상이다. /\n messages?: string[]\n /\n `tool_result` 로 회신된 원문(시간순).\n \n ⚠ `toolUsages[].result` 를 넣지 말 것 — 그것은 화면 표시용으로 깊이·길이가 잘린 값이다. 잘려\n * 나간 식별자를 「근거 없음」으로 오판한다. 넣을 값은 `AgenticLoopResult.groundedTexts` 다.\n /\n toolResults?: string[]\n}\n\n/* 근거집합을 한 덩어리로. 식별자 토큰만 대조하므로 구분자는 개행으로 충분하다. */\nexport function buildGroundedCorpus(sources: GroundingSources): string {\n return [\n sources.systemPrompt ?? '',\n sources.hostContext ?? '',\n ...(sources.messages ?? []),\n ...(sources.toolResults ?? [])\n ]\n .filter(Boolean)\n .join('\\n')\n}\n"]}