@operato/twin-kernel 0.6.14 → 0.7.0

package/dist/flow-engine.d.ts

@@ -135,7 +135,7 @@ export interface FlowTask {
      * **실제로 들어가고 나온 자재** — ISA-95 `JobResponse.MaterialActual`.
      *
      * 명세(계획)가 아니라 **일어난 일**이다. 투입 인원·설비가 이미 작업 델타에 타고 있으니 자재도 같은
-     * 채널에 실어야 실적을 **한 곳에서** 읽는다(EPCIS 이벤트에서 되짚으려면 작업과 잇는 끈이 없다).
+     * 채널에 실어야 실적을 **한 곳에서** 읽는다(EPCIS 이벤트에서 다시 계산하려면 작업과 잇는 끈이 없다).
      */
     materialActual?: {
         definitionId: string;
@@ -340,7 +340,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      */
     observe(): void;
     /**
-     * 돌면서 공장을 갈아탄다 — **현실이 안 멈추므로 미러도 멈출 수 없다.**
+     * 돌면서 공장을 전환한다 — **현실이 안 멈추므로 미러도 멈출 수 없다.**
      *
      * ── 왜 관측 구동에만 여는가 ────────────────────────────────────────────────
      * 미러는 이미 있는 현실을 따라갈 뿐이라, 설비가 한 대 늘었다고 멈췄다 서는 것은 그 사이의
@@ -353,7 +353,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 자원은 버리되 **몇 개를 버렸는지 돌려준다.** 여기서는 그 판단을 커널 자신의 선언 표에도
      * 그대로 옮긴다. 관측층만 갈면 사라진 설비가 커널 표에 남아 **화면이 없는 설비를 그린다.**
      *
-     * 관측으로 알게 된 자리는 선언에 없어도 지운 뒤 다시 심는다 — 다음 스냅샷에서 관측층이
+     * 관측으로 알게 된 자리는 선언에 없어도 지운 뒤 다시 주입한다 — 다음 스냅샷에서 관측층이
      * 되살리므로(`settleObserved` → `hydrateObserved`), 여기서 지켜야 할 것은 **선언분**뿐이다.
      */
     adoptStructure(def: TwinModelDef): StructureShift;
@@ -432,7 +432,7 @@ export declare abstract class FlowEngine implements TwinKernel {
     protected computeAttentions(): Attention[];
     /**
      * fork — 현재 상태를 정확히 복제한 새 엔진 (디지털트윈 본연: "현재로부터 예측").
-     * 원본(live/sim)은 계속 진행, fork 는 what-if 를 앞으로 굴려 forecast·발산(predicted vs actual) 검사에 쓴다.
+     * 원본(live/sim)은 계속 진행, fork 는 what-if 를 앞으로 시뮬레이션해 forecast·발산(predicted vs actual) 검사에 쓴다.
      * fork 는 자기 구독자·시나리오를 갖고 원본과 격리(handlers·gens 비움, generating=false).
      * rng 는 fork 의 시나리오 load 시 재시드(드레인 예측은 생성 없어 rng 무관·결정적).
      */
@@ -441,7 +441,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 이 커널의 **지금**(ms) — 시각으로 바뀌는 모든 판정의 단일 기준.
      *
      * ── 관측 모드에서 시계가 멈춰 있었다 ────────────────────────────────────
-     * `apply()` 는 `clockMs` 를 밀지 않는다(관측은 시간을 굴리지 않는다). 그래서 라이브 트윈의 "지금" 이
+     * `apply()` 는 `clockMs` 를 밀지 않는다(관측은 시간을 진행시키지 않는다). 그래서 라이브 트윈의 "지금" 이
      * **BASE_EPOCH(2026-01-01)에 얼어 있었다.** 실 이벤트는 실제 시각을 달고 오므로 결과가 이렇게 된다:
      *  · **납기 초과를 영원히 보고하지 않는다** — 실 납기가 항상 미래로 보인다
      *  · 폐기·도입예정 판정이 틀린다(§EffectivePeriod)
@@ -472,14 +472,14 @@ export declare abstract class FlowEngine implements TwinKernel {
     };
     protected randInt(min: number, max: number): number;
     /**
-     * 관측 구동(P0 스파이크) — **이벤트로 커널을 굴린다.**
+     * 관측 구동(P0 스파이크) — **이벤트로 커널을 실행한다.**
      *
      * 상태를 만드는 구동이 둘인데(시뮬 `tick` / 미러 `apply`) 지금은 **모델도 둘**이라 한쪽만 고치면
-     * 갈라진다(2026-08-01 하루에 아홉 곳). 근본 해법은 **한 상태 모델 두 구동**이고, 이것은 그 실현
+     * 어긋난다(2026-08-01 하루에 아홉 곳). 근본 해법은 **한 상태 모델 두 구동**이고, 이것은 그 실현
      * 가능성을 재는 스파이크다(design/plans/kernel-unification-live-observe.md P0).
      *
      * 여기서는 **이미 검증된 조각을 조립**한다: 투영기가 이벤트를 접고, 그 결과를 씨앗 경로
-     * (`hydrateObserved`)로 커널 상태에 심는다. 그래서 관측으로 굴린 커널을 그대로 `fork`·`tick` 할 수
+     * (`hydrateObserved`)로 커널 상태에 주입한다. 그래서 관측으로 실행한 커널을 그대로 `fork`·`tick` 할 수
      * 있다 — "미러에서 예측한다" 가 별도 배관 없이 성립하는지가 이 스파이크의 질문이다.
      *
      * **비용은 정직하게**: 이벤트마다 전체를 다시 심으므로 O(상태 크기)다. P1 에서 반영 로직을 순수
@@ -512,14 +512,14 @@ export declare abstract class FlowEngine implements TwinKernel {
      */
     protected routeKeys(): string[] | undefined;
     /**
-     * **이 공장이 하루 몇 대를 낼 수 있는가** — 굴려 보지 않고 답한다.
+     * **이 공장이 하루 몇 대를 낼 수 있는가** — 실행해 보지 않고 답한다.
      *
      * 커널이 직접 답하는 이유: 필요한 사실이 전부 여기 있다(공정 명세·설비와 신뢰도·인원·물리자산·
      * 자리·근무 달력·시각 기준). 밖에서 모으면 그 값을 옮겨 적게 되고, 한쪽만 바뀌는 순간 "충분하다"
      * 가 조용히 거짓이 된다. 계산 자체는 순수 함수(`analyzeCapacity`)에 맡긴다.
      *
      * 달력은 **자원이 선언한 것**을 쓴다. 자원마다 다른 달력을 쓰는 현장이면 대표를 고를 수 없으므로
-     * 그 사실을 결과에 실어 보낸다(`mixedCalendars`) — 조용히 하나를 골라 계산하면 천장이 틀린 채로
+     * 그 사실을 결과에 실어 보낸다(`mixedCalendars`) — 조용히 하나를 골라 계산하면 상한이 틀린 채로
      * 그럴듯해 보인다.
      */
     capacity(opts: {
@@ -562,7 +562,7 @@ export declare abstract class FlowEngine implements TwinKernel {
     /**
      * task 소요 산출 — 우선순위: **① 추정기(이력 보정) → ② 명세(ISA-95 Duration + 변동) → ③ 도메인 상수.**
      *
-     * 이 순서인 이유: 실측에서 배운 값이 선언값을 이기고, 선언값이 우리가 코드에 박아 둔 상수를 이긴다.
+     * 이 순서인 이유: 실측에서 배운 값이 선언값을 이기고, 선언값이 우리가 코드에 고정한 상수를 이긴다.
      * 셋 중 무엇을 썼는지는 `specCoverage()` 로 드러낸다 — 상수를 쓴 것이 조용히 넘어가지 않게.
      * "얼마"만 소비하고 "경로"는 씬이 소유한다(좌표-free 유지).
      */
@@ -585,7 +585,7 @@ export declare abstract class FlowEngine implements TwinKernel {
     private noteSpecUse;
     private noteParamUse;
     /**
-     * 시뮬 명세 자기보고 — **어디까지 데이터로 말했고 어디부터 우리가 박아 둔 상수인가.**
+     * 시뮬 명세 자기보고 — **어디까지 데이터로 말했고 어디부터 우리가 코드에 고정한 상수인가.**
      *
      * 시뮬레이션 결과를 받는 쪽이 이걸 봐야 한다: 소요시간이 전부 기본값이면 그 예측으로 말할 수 있는 것은
      * "같은 조건에서의 상대 비교" 뿐이고 "몇 시에 끝난다" 는 근거가 없다. 그 구분을 숫자로 드러낸다.
@@ -653,7 +653,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      */
     protected reserve(epcs: string[], bizStep: string): void;
     /**
-     * 처분 변화 관측 — **상태와 이벤트를 한 번에.** 둘을 따로 쓰면 반드시 갈라진다.
+     * 처분 변화 관측 — **상태와 이벤트를 한 번에.** 둘을 따로 쓰면 반드시 어긋난다.
      *
      * 실제로 양쪽으로 갈라져 있었다: 할당은 상태만 바꾸고 이벤트를 안 냈고(미러가 모름), 야드 도크
      * 도착은 이벤트만 내고 상태를 안 바꿨다(이벤트와 상태가 다른 말). 적합성 하네스가 둘 다 잡았다.
@@ -758,7 +758,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 지금은 자리를 따지지 않는다 — 따지려면 자산 이송 작업이 먼저 있어야 한다).
      */
     private claimAssets;
-    /** 확보한 자산을 작업에 묶는다 — 싣는 물류단위(SSCC)가 있으면 연결한다(GRAI ↔ SSCC). */
+    /** 확보한 자산을 작업에 배정한다 — 싣는 물류단위(SSCC)가 있으면 연결한다(GRAI ↔ SSCC). */
     private assignAssets;
     /**
      * 작업이 끝나면 자산을 놓아 준다 — **사람과 다른 점: 자산은 도착 자리에 남는다**(물건이므로).
@@ -805,7 +805,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 이 작업이 **딛고 선 것**이 아직 있나 — 없으면 무엇이 없는지 답한다.
      *
      * 작업은 혼자 서지 못한다: 옮길 **물품**과, (있다면) 그것을 시킨 **오더** 위에 선다. 진행 중에
-     * 둘 중 하나가 사라질 수 있다 — 물품은 포장·출하·소비로, 오더는 이미 이행돼 씨앗이 심지 않아서.
+     * 둘 중 하나가 사라질 수 있다 — 물품은 포장·출하·소비로, 오더는 이미 이행돼 씨앗이 주입하지 않아서.
      *
      * 그때 도메인 훅은 없는 것을 딛으려다 던진다(`order.gtin` · `item.location`). 그 예외 하나가
      * **예측 전체를 죽였다** — 사용자에게는 기능이 통째로 사라진 것으로 보였다. 그래서 완료 **전에**
@@ -859,7 +859,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 자원 하나의 **가용 능력** — 계약의 판정에 이 커널의 시각·시간대·필수 시험을 채워 넘긴다.
      *
      * 배정도 스냅샷도 이 자리를 지난다. 예전에는 배정이 조건을 늘어놓고 화면이 플래그를 보고 짐작해서,
-     * **자격이 만료된 사람이 화면에서는 `대기` 로 보였다**(놀고 있는 것은 맞지만 쓸 수 있는 것은 아니다).
+     * **자격이 만료된 사람이 화면에서는 `대기` 로 보였다**(대기 중인 것은 맞지만 쓸 수 있는 것은 아니다).
      * 판정에 필요한 둘(시각·등급 상속)을 아는 것은 커널뿐이므로, 답도 커널이 낸다.
      */
     private capabilityOfResource;
@@ -870,7 +870,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 여기서는 고르기만 한다 — 확정은 호출부가 다른 자원까지 확보한 뒤에 한다.
      */
     private claimEquipment;
-    /** 확보한 사람을 작업에 묶는다(설비까지 확정된 뒤). */
+    /** 확보한 사람을 작업에 배정한다(설비까지 확정된 뒤). */
     private assignCrew;
     /** 작업이 끝나면 사람을 놓아 준다 — 설비 해제와 별개 경로. */
     private releaseCrew;
@@ -897,7 +897,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 유효 기간 밖인가 — **네 번째 이유**(§Effectivity). 설비·사람·자산이 같은 규칙을 쓴다.
      *
      * 시뮬 시각을 ISO 로 풀어 계약의 `effectivityAt` 에 넘긴다. **판정은 커널에 두지 않는다** —
-     * 호스트(라이브 관측)도 같은 판정을 해야 하고, 규칙이 두 벌이면 갈라진다.
+     * 호스트(라이브 관측)도 같은 판정을 해야 하고, 규칙이 두 벌이면 어긋난다.
      */
     protected effectivityOf(r: EffectivePeriod): Effectivity | undefined;
     /**
@@ -912,7 +912,7 @@ export declare abstract class FlowEngine implements TwinKernel {
     /**
      * 스냅샷·델타에 실을 조각 — **선언한 기간과 판정을 함께** 낸다.
      *
-     * 판정만 내면 화면이 "왜" 를 말할 수 없고(언제 폐기됐나), 기간만 내면 소비처마다 다시 판정해 갈라진다.
+     * 판정만 내면 화면이 "왜" 를 말할 수 없고(언제 폐기됐나), 기간만 내면 소비처마다 다시 판정해 어긋난다.
      * 선언이 없으면 아무것도 붙이지 않는다(대부분의 자원이 그렇다 — 필드를 늘리지 않는다).
      */
     protected effectivePart(r: EffectivePeriod): Partial<EffectivePeriod> & {
@@ -922,7 +922,7 @@ export declare abstract class FlowEngine implements TwinKernel {
      * 지금 근무 시간 밖인가 — **캘린더가 있으면 그것으로, 없으면 옛 `window` 로** 판정한다.
      *
      * `window`(시 단위 하나)는 캘린더의 특수한 경우다. 둘을 한 함수로 모아 두면 인원·설비가 같은 규칙을
-     * 쓴다(예전에는 같은 식이 두 곳에 복사돼 있었다 — 한쪽만 고치면 조용히 갈라진다).
+     * 쓴다(예전에는 같은 식이 두 곳에 복사돼 있었다 — 한쪽만 고치면 조용히 어긋난다).
      */
     protected offCalendar(r: {
         window?: {

package/dist/flow-engine.js

@@ -88,7 +88,7 @@ nowIso) {
      *
      * 재는 방법은 스냅샷만으로 답할 수 있어야 한다(추세를 쌓아 두지 않는다). 그래서 같은 공정에서
      * **기다리는 일과 하고 있는 일의 비**를 본다 — 처리 능력이 충분하면 대기가 길게 늘지 않는다.
-     * 공정이 아예 안 돌면(하는 일 0, 기다리는 일 여럿) 그것이 가장 강한 신호다.
+     * 공정이 전혀 진행되지 않으면(하는 일 0, 기다리는 일 여럿) 그것이 가장 강한 신호다.
      *
      * 공정 이름은 작업이 스스로 말하는 것(`kind`)을 쓴다. 설비 종류로 환산하지 않는다 — 그 대응은
      * 현장마다 다르고, 커널이 그 방언을 알면 보편 계약이 깨진다.
@@ -100,7 +100,7 @@ nowIso) {
      * 막혔을 때의 경고까지 같이 무시하게 된다.
      *
      * 쉬는 중인지는 **설비가 이미 말하고 있다**(`offShift`, 달력에서 파생). 여기서 달력을 다시 읽지
-     * 않는다 — 두 벌이 되면 갈라진다. 설비를 아예 모르면 판단하지 않는다(줄만 보고 단정하지 않는다).
+     * 않는다 — 두 벌이 되면 어긋난다. 설비를 아예 모르면 판단하지 않는다(줄만 보고 단정하지 않는다).
      */
     const shutdown = (view.equipment?.length ?? 0) > 0 && view.equipment.every(m => m.offShift);
     if (view.tasks?.length && !shutdown) {
@@ -157,7 +157,7 @@ nowIso) {
     }
     /* 납기 초과 — **표준 `EndTime` 이 있어야 판정할 수 있다.** 없으면 신호를 만들지 않는다(없는 납기를
        지연으로도 정시로도 말하지 않는다). 이미 끝난 오더는 대상이 아니다.
-       심각도는 얼마나 늦었는지로 가른다 — 방금 넘긴 것과 하루 넘긴 것을 같게 부르면 신호가 무의미해진다. */
+       심각도는 얼마나 늦었는지로 구분한다 — 방금 넘긴 것과 하루 넘긴 것을 같게 부르면 신호가 무의미해진다. */
     for (const o of view.orders) {
         if (o.status === 'completed' || o.status === 'fulfilled')
             continue;
@@ -288,7 +288,7 @@ export class FlowEngine {
     /*
      * ── 선언 하나를 상태 하나로 짓는 자리 ─────────────────────────────────────
      * 최초 적재(`loadTwinModel`)와 가동 중 교체(`adoptStructure`)가 **같은 구성을 쓴다.** 두 곳에서
-     * 따로 지으면 곧 갈라지고, 갈라진 쪽으로 들어온 자원만 필드 하나가 비는 식으로 조용히 다르다.
+     * 따로 지으면 곧 갈라지고, 어긋난 쪽으로 들어온 자원만 필드 하나가 비는 식으로 조용히 다르다.
      */
     buildLocation(n) {
         return { id: n.id, type: n.type, capacity: n.capacity, parallelism: n.parallelism, occupancy: 0, status: 'idle', parentId: n.parentId };
@@ -312,7 +312,7 @@ export class FlowEngine {
         this.observeMode = true;
     }
     /**
-     * 돌면서 공장을 갈아탄다 — **현실이 안 멈추므로 미러도 멈출 수 없다.**
+     * 돌면서 공장을 전환한다 — **현실이 안 멈추므로 미러도 멈출 수 없다.**
      *
      * ── 왜 관측 구동에만 여는가 ────────────────────────────────────────────────
      * 미러는 이미 있는 현실을 따라갈 뿐이라, 설비가 한 대 늘었다고 멈췄다 서는 것은 그 사이의
@@ -325,7 +325,7 @@ export class FlowEngine {
      * 자원은 버리되 **몇 개를 버렸는지 돌려준다.** 여기서는 그 판단을 커널 자신의 선언 표에도
      * 그대로 옮긴다. 관측층만 갈면 사라진 설비가 커널 표에 남아 **화면이 없는 설비를 그린다.**
      *
-     * 관측으로 알게 된 자리는 선언에 없어도 지운 뒤 다시 심는다 — 다음 스냅샷에서 관측층이
+     * 관측으로 알게 된 자리는 선언에 없어도 지운 뒤 다시 주입한다 — 다음 스냅샷에서 관측층이
      * 되살리므로(`settleObserved` → `hydrateObserved`), 여기서 지켜야 할 것은 **선언분**뿐이다.
      */
     adoptStructure(def) {
@@ -337,7 +337,7 @@ export class FlowEngine {
         this.classDefs = { personnel: def.personnelClasses, equipment: def.equipmentClasses, asset: def.assetClasses, material: def.materialClasses };
         this.materialDefs = new Map((def.materialDefinitions ?? []).filter(d => d?.id).map(d => [d.id, d]));
         /* **살아남은 것은 그대로 둔다** — 다시 지으면 가동시간·양품수가 0 으로 돌아간다(OEE 가 리셋된다).
-           선언이 바뀐 트윈에서 성과 지표가 조용히 끊기는 것이 이 갈아타기의 가장 비싼 오류다. */
+           선언이 바뀐 트윈에서 성과 지표가 조용히 끊기는 것이 이 구조 전환의 가장 비싼 오류다. */
         const sync = (map, declared, build) => {
             const ids = new Set(declared.map(d => d.id));
             let dropped = 0;
@@ -429,22 +429,22 @@ export class FlowEngine {
         this.revision = from;
     }
     hydrateObserved(snap, orders = []) {
-        /* 확인 처리를 먼저 이어받는다 — 아래에서 상태를 심으면 곧바로 주목 신호가 계산되므로, 늦게
+        /* 확인 처리를 먼저 이어받는다 — 아래에서 상태를 주입하면 곧바로 주목 신호가 계산되므로, 늦게
          * 이어받으면 그 한 번은 확인 안 된 것으로 계산된다(화면이 잠깐 빨개진다). */
         for (const id of snap.acked ?? [])
             this._acked.add(id);
         /* **관측된 것을 버리지 않는다.** 예전에는 자리·설비 상태를 'idle' 로, OEE 누적을 0 으로 덮고
          * 물품의 로트·단위·소속·마스터데이터를 떨어뜨렸다. 씨앗이 잃은 것은 **예측도 모른다** —
-         * 고장 난 설비를 정상으로, 진행 중인 일을 없는 것으로 놓고 미래를 굴리면 답이 낙관 쪽으로 치우친다. */
+         * 고장 난 설비를 정상으로, 진행 중인 일을 없는 것으로 놓고 미래를 실행하면 답이 낙관 쪽으로 치우친다. */
         for (const n of snap.locations) {
             this.locations.set(n.id, { id: n.id, type: n.type, capacity: n.capacity ?? 0, parallelism: n.parallelism, occupancy: n.occupancy ?? 0, status: n.status ?? 'idle', parentId: n.parentId });
         }
         this.items.clear();
         for (const it of snap.items) {
-            /* **부분마다 한 줄로 심는다** — `epc` 로 키를 잡으면 같은 로트의 두 부분이 하나로 접혀
+            /* **부분마다 한 줄로 주입한다** — `epc` 로 키를 잡으면 같은 로트의 두 부분이 하나로 접혀
                씨앗에서 재고가 줄어든다(§MaterialSubLot 에서 겪은 것과 같은 오류의 세 번째 자리). */
             this.items.set(itemKeyOf(it), {
-                /* 품번 키·로트는 식별자에서 파생되므로 심지 않는다(스냅샷이 다시 낸다 — 두 벌을 두면 어긋난다). */
+                /* 품번 키·로트는 식별자에서 파생되므로 주입하지 않는다(스냅샷이 다시 낸다 — 두 벌을 두면 어긋난다). */
                 epc: it.epc, location: it.location, disposition: it.disposition ?? DISP.sellable,
                 ...(it.subLotId ? { subLotId: it.subLotId } : {}),
                 ...(it.definitionId ? { definitionId: it.definitionId } : {}),
@@ -480,7 +480,7 @@ export class FlowEngine {
                  * **잰 값을 이어받으면 잰 구간도 이어받아야 한다.**
                  *
                  * 카운터만 되살리고 창을 지금으로 두면 둘이 어긋난다: 이어받은 가동 8시간이 방금 시작한 창
-                 * 안에 앉아, 놀고 있는 설비가 **가동률 100%·유휴 0초**로 보인다(화면에서 관측됨).
+                 * 안에 앉아, 대기 중인 설비가 **가동률 100%·유휴 0초**로 보인다(화면에서 관측됨).
                  *
                  * 창은 지표 자신이 말해 준다 — 계획 시간은 가동·준비·고장·유휴의 합이다. 그래서 그 합만큼
                  * 뒤로 물려 창을 다시 세운다. 지표가 없으면 창도 없다(그때는 지금부터 새로 잰다).
@@ -488,7 +488,7 @@ export class FlowEngine {
                 ...(oee
                     ? { metricsSinceMs: this.clockMs - ((oee.runMs ?? 0) + (oee.setupMs ?? 0) + (oee.downMs ?? 0) + (oee.idleMs ?? 0)) }
                     : {}),
-                /* 계획 정지를 이어받는다 — 잃으면 씨앗이 **정비 중인 설비를 가용으로 놓고** 미래를 굴린다
+                /* 계획 정지를 이어받는다 — 잃으면 씨앗이 **정비 중인 설비를 가용으로 놓고** 미래를 시뮬레이션한다
                    (예측이 낙관 쪽으로 치우친다). 씨앗 왕복 대조가 이것을 잡았다. */
                 ...(m.held ? { held: true } : {}),
                 /* 관측 스냅샷이 들고 있는 것은 관측을 따른다(미러가 보드에서 읽어 실어 온다). */
@@ -530,7 +530,7 @@ export class FlowEngine {
         }
         /* 진행 중이던 작업을 이어 붙인다 — 없으면 예측이 "일이 하나도 없는 현장" 에서 출발한다.
          * 남은 시간을 모르면 **진척을 꾸미지 않고** 미착수(created)로 되돌린다: 그 일이 남아 있다는 사실은
-         * 지키면서, 얼마나 진행됐는지는 모른다고 말하는 쪽이 정직하다(커널이 다시 배정해 굴린다). */
+         * 지키면서, 얼마나 진행됐는지는 모른다고 말하는 쪽이 정직하다(커널이 다시 배정해 실행한다). */
         /*
          * **주체가 없는 작업은 되살리지 않는다.**
          *
@@ -597,8 +597,8 @@ export class FlowEngine {
                 orphaned++;
                 continue;
             }
-            /* 오더도 같다 — 이미 이행된 오더는 심지 않으므로(위 `remaining <= 0`), 그 오더에 딸린 작업만
-               남으면 완료 시점에 없는 오더를 딛는다. 심는 단계에서 함께 뺀다. */
+            /* 오더도 같다 — 이미 이행된 오더는 주입하지 않으므로(위 `remaining <= 0`), 그 오더에 딸린 작업만
+               남으면 완료 시점에 없는 오더를 딛는다. 주입 단계에서 함께 뺀다. */
             if (t.orderId && !seededOrderIds.has(t.orderId)) {
                 orphaned++;
                 continue;
@@ -626,7 +626,7 @@ export class FlowEngine {
                     mv.taskId = t.id;
                 }
             }
-            /* 사람도 같다 — 진행 중이던 작업에 투입돼 있던 사람은 여전히 묶여 있어야 한다. */
+            /* 사람도 같다 — 진행 중이던 작업에 투입돼 있던 사람은 여전히 점유되어 있어야 한다. */
             if (known && t.status === 'in-progress') {
                 const restored = this.tasks.get(t.id);
                 if (restored)
@@ -716,7 +716,7 @@ export class FlowEngine {
                     this._acked.add(id);
                     /*
                      * **사실로 남긴다.** 확인 처리는 사람이 한 행위라 상태에서 다시 계산될 수 없다. 저널에
-                     * 남기지 않으면 재기동하면 확인해 둔 신호가 다시 빨개지고, 과거를 되짚어도 그때 무엇을
+                     * 남기지 않으면 재기동하면 확인해 둔 신호가 다시 빨개지고, 과거를 다시 계산해도 그때 무엇을
                      * 확인했는지 알 수 없다. 다른 커맨드(보류·재개)가 델타를 내는 것과 같은 길이다.
                      */
                     this.emitOp(OP_EVENT.attentionAck, { id, at: this.now() });
@@ -837,7 +837,7 @@ export class FlowEngine {
              * 시뮬이 아무 표시도 안 하면 소비처가 두 스냅샷을 같은 규칙으로 읽지 못한다. */
             locations: [...this.locations.values()].map(n => {
                 const { status, ...rest } = n;
-                /* 상태는 저장값이 아니라 포화도 파생 — 미러와 **같은 함수**를 쓴다(규칙이 둘이면 갈라진다). */
+                /* 상태는 저장값이 아니라 포화도 파생 — 미러와 **같은 함수**를 쓴다(규칙이 둘이면 어긋난다). */
                 const derived = locationStatusOf(n);
                 return { ...rest, ...(derived ? { status: derived } : {}), origin: 'master' };
             }),
@@ -887,7 +887,7 @@ export class FlowEngine {
                 return st;
             }),
             /* 스냅샷이 **델타보다 가난하면 안 된다** — 예전에는 소요·남은 시간을 빼고 내보내서, 이 스냅샷으로
-             * 다른 커널을 심으면(hydrateObserved) 진행 중이던 작업을 이어 굴릴 수 없었다(미러 스냅샷은
+             * 다른 커널을 주입하면(hydrateObserved) 진행 중이던 작업을 이어 굴릴 수 없었다(미러 스냅샷은
              * 델타에서 왔으므로 갖고 있었다 — 같은 계약을 두 구동이 다르게 채우던 자리). */
             tasks: [...this.tasks.values()].map(t => ({
                 id: t.id, kind: t.kind, status: t.status, itemRefs: [t.itemEpc],
@@ -971,7 +971,7 @@ export class FlowEngine {
     }
     /**
      * fork — 현재 상태를 정확히 복제한 새 엔진 (디지털트윈 본연: "현재로부터 예측").
-     * 원본(live/sim)은 계속 진행, fork 는 what-if 를 앞으로 굴려 forecast·발산(predicted vs actual) 검사에 쓴다.
+     * 원본(live/sim)은 계속 진행, fork 는 what-if 를 앞으로 시뮬레이션해 forecast·발산(predicted vs actual) 검사에 쓴다.
      * fork 는 자기 구독자·시나리오를 갖고 원본과 격리(handlers·gens 비움, generating=false).
      * rng 는 fork 의 시나리오 load 시 재시드(드레인 예측은 생성 없어 rng 무관·결정적).
      */
@@ -1004,7 +1004,7 @@ export class FlowEngine {
      * 이 커널의 **지금**(ms) — 시각으로 바뀌는 모든 판정의 단일 기준.
      *
      * ── 관측 모드에서 시계가 멈춰 있었다 ────────────────────────────────────
-     * `apply()` 는 `clockMs` 를 밀지 않는다(관측은 시간을 굴리지 않는다). 그래서 라이브 트윈의 "지금" 이
+     * `apply()` 는 `clockMs` 를 밀지 않는다(관측은 시간을 진행시키지 않는다). 그래서 라이브 트윈의 "지금" 이
      * **BASE_EPOCH(2026-01-01)에 얼어 있었다.** 실 이벤트는 실제 시각을 달고 오므로 결과가 이렇게 된다:
      *  · **납기 초과를 영원히 보고하지 않는다** — 실 납기가 항상 미래로 보인다
      *  · 폐기·도입예정 판정이 틀린다(§EffectivePeriod)
@@ -1039,14 +1039,14 @@ export class FlowEngine {
     }
     randInt(min, max) { return max <= min ? min : min + Math.floor(this.rng() * (max - min + 1)); }
     /**
-     * 관측 구동(P0 스파이크) — **이벤트로 커널을 굴린다.**
+     * 관측 구동(P0 스파이크) — **이벤트로 커널을 실행한다.**
      *
      * 상태를 만드는 구동이 둘인데(시뮬 `tick` / 미러 `apply`) 지금은 **모델도 둘**이라 한쪽만 고치면
-     * 갈라진다(2026-08-01 하루에 아홉 곳). 근본 해법은 **한 상태 모델 두 구동**이고, 이것은 그 실현
+     * 어긋난다(2026-08-01 하루에 아홉 곳). 근본 해법은 **한 상태 모델 두 구동**이고, 이것은 그 실현
      * 가능성을 재는 스파이크다(design/plans/kernel-unification-live-observe.md P0).
      *
      * 여기서는 **이미 검증된 조각을 조립**한다: 투영기가 이벤트를 접고, 그 결과를 씨앗 경로
-     * (`hydrateObserved`)로 커널 상태에 심는다. 그래서 관측으로 굴린 커널을 그대로 `fork`·`tick` 할 수
+     * (`hydrateObserved`)로 커널 상태에 주입한다. 그래서 관측으로 실행한 커널을 그대로 `fork`·`tick` 할 수
      * 있다 — "미러에서 예측한다" 가 별도 배관 없이 성립하는지가 이 스파이크의 질문이다.
      *
      * **비용은 정직하게**: 이벤트마다 전체를 다시 심으므로 O(상태 크기)다. P1 에서 반영 로직을 순수
@@ -1112,14 +1112,14 @@ export class FlowEngine {
         return undefined;
     }
     /**
-     * **이 공장이 하루 몇 대를 낼 수 있는가** — 굴려 보지 않고 답한다.
+     * **이 공장이 하루 몇 대를 낼 수 있는가** — 실행해 보지 않고 답한다.
      *
      * 커널이 직접 답하는 이유: 필요한 사실이 전부 여기 있다(공정 명세·설비와 신뢰도·인원·물리자산·
      * 자리·근무 달력·시각 기준). 밖에서 모으면 그 값을 옮겨 적게 되고, 한쪽만 바뀌는 순간 "충분하다"
      * 가 조용히 거짓이 된다. 계산 자체는 순수 함수(`analyzeCapacity`)에 맡긴다.
      *
      * 달력은 **자원이 선언한 것**을 쓴다. 자원마다 다른 달력을 쓰는 현장이면 대표를 고를 수 없으므로
-     * 그 사실을 결과에 실어 보낸다(`mixedCalendars`) — 조용히 하나를 골라 계산하면 천장이 틀린 채로
+     * 그 사실을 결과에 실어 보낸다(`mixedCalendars`) — 조용히 하나를 골라 계산하면 상한이 틀린 채로
      * 그럴듯해 보인다.
      */
     capacity(opts) {
@@ -1209,14 +1209,14 @@ export class FlowEngine {
     /**
      * task 소요 산출 — 우선순위: **① 추정기(이력 보정) → ② 명세(ISA-95 Duration + 변동) → ③ 도메인 상수.**
      *
-     * 이 순서인 이유: 실측에서 배운 값이 선언값을 이기고, 선언값이 우리가 코드에 박아 둔 상수를 이긴다.
+     * 이 순서인 이유: 실측에서 배운 값이 선언값을 이기고, 선언값이 우리가 코드에 고정한 상수를 이긴다.
      * 셋 중 무엇을 썼는지는 `specCoverage()` 로 드러낸다 — 상수를 쓴 것이 조용히 넘어가지 않게.
      * "얼마"만 소비하고 "경로"는 씬이 소유한다(좌표-free 유지).
      */
     durationOf(ctx, fallbackMs) {
         const estimated = this.durationEstimator?.estimate(ctx);
         /* 추정기가 답한 것은 **실측·계산에서 온 값**이므로 선언값과 구별해 기록한다 — "현장이 선언했다" 와
-         * "이력에서 배웠다" 는 예측의 자격이 다르다(후자가 더 강하다). 뭉개면 그 차이가 사라진다. */
+         * "이력에서 배웠다" 는 예측의 자격이 다르다(후자가 더 강하다). 합치면 그 차이가 사라진다. */
         if (typeof estimated === 'number') {
             this.noteSpecUse(ctx.kind, 'measured');
             return estimated;
@@ -1309,7 +1309,7 @@ export class FlowEngine {
             this.specUse.set(kind, { duration: 'default', params: new Set([id]) });
     }
     /**
-     * 시뮬 명세 자기보고 — **어디까지 데이터로 말했고 어디부터 우리가 박아 둔 상수인가.**
+     * 시뮬 명세 자기보고 — **어디까지 데이터로 말했고 어디부터 우리가 코드에 고정한 상수인가.**
      *
      * 시뮬레이션 결과를 받는 쪽이 이걸 봐야 한다: 소요시간이 전부 기본값이면 그 예측으로 말할 수 있는 것은
      * "같은 조건에서의 상대 비교" 뿐이고 "몇 시에 끝난다" 는 근거가 없다. 그 구분을 숫자로 드러낸다.
@@ -1317,7 +1317,7 @@ export class FlowEngine {
     specCoverage() {
         const operations = [...this.specUse.entries()].map(([kind, u]) => {
             const spec = this.operationSpecs.get(kind);
-            /* 실측 분포를 쓴 경우가 우선 — 선언 명세의 변동보다 실제로 굴린 것이 사실이다. */
+            /* 실측 분포를 쓴 경우가 우선 — 선언 명세의 변동보다 실제로 실행한 것이 사실이다. */
             const variability = u.variability ?? spec?.variability?.distribution;
             return {
                 kind,
@@ -1409,7 +1409,7 @@ export class FlowEngine {
         this.observeDisposition(epcs, DISP.reserved, bizStep);
     }
     /**
-     * 처분 변화 관측 — **상태와 이벤트를 한 번에.** 둘을 따로 쓰면 반드시 갈라진다.
+     * 처분 변화 관측 — **상태와 이벤트를 한 번에.** 둘을 따로 쓰면 반드시 어긋난다.
      *
      * 실제로 양쪽으로 갈라져 있었다: 할당은 상태만 바꾸고 이벤트를 안 냈고(미러가 모름), 야드 도크
      * 도착은 이벤트만 내고 상태를 안 바꿨다(이벤트와 상태가 다른 말). 적합성 하네스가 둘 다 잡았다.
@@ -1682,7 +1682,7 @@ export class FlowEngine {
         }
         return picked;
     }
-    /** 확보한 자산을 작업에 묶는다 — 싣는 물류단위(SSCC)가 있으면 연결한다(GRAI ↔ SSCC). */
+    /** 확보한 자산을 작업에 배정한다 — 싣는 물류단위(SSCC)가 있으면 연결한다(GRAI ↔ SSCC). */
     assignAssets(t, gear) {
         if (!gear.length)
             return;
@@ -1848,7 +1848,7 @@ export class FlowEngine {
      * 이 작업이 **딛고 선 것**이 아직 있나 — 없으면 무엇이 없는지 답한다.
      *
      * 작업은 혼자 서지 못한다: 옮길 **물품**과, (있다면) 그것을 시킨 **오더** 위에 선다. 진행 중에
-     * 둘 중 하나가 사라질 수 있다 — 물품은 포장·출하·소비로, 오더는 이미 이행돼 씨앗이 심지 않아서.
+     * 둘 중 하나가 사라질 수 있다 — 물품은 포장·출하·소비로, 오더는 이미 이행돼 씨앗이 주입하지 않아서.
      *
      * 그때 도메인 훅은 없는 것을 딛으려다 던진다(`order.gtin` · `item.location`). 그 예외 하나가
      * **예측 전체를 죽였다** — 사용자에게는 기능이 통째로 사라진 것으로 보였다. 그래서 완료 **전에**
@@ -1966,7 +1966,7 @@ export class FlowEngine {
      * 자원 하나의 **가용 능력** — 계약의 판정에 이 커널의 시각·시간대·필수 시험을 채워 넘긴다.
      *
      * 배정도 스냅샷도 이 자리를 지난다. 예전에는 배정이 조건을 늘어놓고 화면이 플래그를 보고 짐작해서,
-     * **자격이 만료된 사람이 화면에서는 `대기` 로 보였다**(놀고 있는 것은 맞지만 쓸 수 있는 것은 아니다).
+     * **자격이 만료된 사람이 화면에서는 `대기` 로 보였다**(대기 중인 것은 맞지만 쓸 수 있는 것은 아니다).
      * 판정에 필요한 둘(시각·등급 상속)을 아는 것은 커널뿐이므로, 답도 커널이 낸다.
      */
     capabilityOfResource(r, directClassIds, defs, 
@@ -2041,7 +2041,7 @@ export class FlowEngine {
         }
         return picked.length ? picked : null;
     }
-    /** 확보한 사람을 작업에 묶는다(설비까지 확정된 뒤). */
+    /** 확보한 사람을 작업에 배정한다(설비까지 확정된 뒤). */
     assignCrew(t, crew) {
         if (!crew.length)
             return;
@@ -2099,7 +2099,7 @@ export class FlowEngine {
      * 유효 기간 밖인가 — **네 번째 이유**(§Effectivity). 설비·사람·자산이 같은 규칙을 쓴다.
      *
      * 시뮬 시각을 ISO 로 풀어 계약의 `effectivityAt` 에 넘긴다. **판정은 커널에 두지 않는다** —
-     * 호스트(라이브 관측)도 같은 판정을 해야 하고, 규칙이 두 벌이면 갈라진다.
+     * 호스트(라이브 관측)도 같은 판정을 해야 하고, 규칙이 두 벌이면 어긋난다.
      */
     effectivityOf(r) {
         if (!r.effectiveStart && !r.effectiveEnd)
@@ -2123,7 +2123,7 @@ export class FlowEngine {
     /**
      * 스냅샷·델타에 실을 조각 — **선언한 기간과 판정을 함께** 낸다.
      *
-     * 판정만 내면 화면이 "왜" 를 말할 수 없고(언제 폐기됐나), 기간만 내면 소비처마다 다시 판정해 갈라진다.
+     * 판정만 내면 화면이 "왜" 를 말할 수 없고(언제 폐기됐나), 기간만 내면 소비처마다 다시 판정해 어긋난다.
      * 선언이 없으면 아무것도 붙이지 않는다(대부분의 자원이 그렇다 — 필드를 늘리지 않는다).
      */
     effectivePart(r) {
@@ -2140,7 +2140,7 @@ export class FlowEngine {
      * 지금 근무 시간 밖인가 — **캘린더가 있으면 그것으로, 없으면 옛 `window` 로** 판정한다.
      *
      * `window`(시 단위 하나)는 캘린더의 특수한 경우다. 둘을 한 함수로 모아 두면 인원·설비가 같은 규칙을
-     * 쓴다(예전에는 같은 식이 두 곳에 복사돼 있었다 — 한쪽만 고치면 조용히 갈라진다).
+     * 쓴다(예전에는 같은 식이 두 곳에 복사돼 있었다 — 한쪽만 고치면 조용히 어긋난다).
      */
     offCalendar(r) {
         return offCalendarAt(r, this.nowMs(), this.boardDef?.utcOffsetMinutes);
@@ -2434,7 +2434,7 @@ export class FlowEngine {
             eq.taskId = null;
             if (t.intent !== 'process')
                 eq.location = t.toNode; // 운반만 위치 이동; process 는 제자리
-            /* 함께 잡힌 설비도 같은 규칙으로 놓아 준다 — 대표만 풀면 나머지가 영원히 묶인다. */
+            /* 함께 잡힌 설비도 같은 규칙으로 놓아 준다 — 대표만 풀면 나머지가 영원히 점유된다. */
             for (const id of t.resources ?? []) {
                 if (id === eq.id)
                     continue;

package/dist/forecast.js

@@ -1,7 +1,7 @@
 /*
  * Probabilistic Forecast — 몬테카를로 예측 (단일 결정값 → 분포).
  *
- * 예측은 본질적으로 불확실하다. 현재 상태를 fork 하고 seed 를 달리해(확률적 미래) N회 굴려,
+ * 예측은 본질적으로 불확실하다. 현재 상태를 fork 하고 seed 를 달리해(확률적 미래) N회 실행해,
  * 관심 지표를 분포로 준다: "언제 끝나?"가 아니라 "P50/P90 완료시각·재고소진 확률".
  * fork(현재예측) + 시나리오 재시드로 미래만 변주 — 현재 상태(재고·오더·태스크)는 보존.
  */

package/dist/index.d.ts

@@ -8,6 +8,7 @@ export * from './event-journal.ts';
 export * from './divergence.ts';
 export * from './epcis.ts';
 export * from './wms-profile.ts';
+export * from './ems-profile.ts';
 export * from './capability.ts';
 export * from './domain-catalog.ts';
 export * from './allocation-policy.ts';
@@ -27,4 +28,6 @@ export * from './operations-capability.ts';
 export { WmsKernel } from './kernel.ts';
 export { YmsKernel } from './yms-kernel.ts';
 export { MesKernel, MES_PART_GTINS, MES_PRODUCT_GTINS, MES_PRODUCTS } from './mes-kernel.ts';
+export { EmsKernel, DEMAND_WINDOW_MS, demandWindowStart } from './ems-kernel.ts';
+export type { EnergyState, DemandWindowState, MeterPointState } from './ems-kernel.ts';
 export * from './vocabulary.ts';

package/dist/index.js

@@ -8,6 +8,7 @@ export * from "./event-journal.js";
 export * from "./divergence.js";
 export * from "./epcis.js";
 export * from "./wms-profile.js";
+export * from "./ems-profile.js";
 export * from "./capability.js";
 export * from "./domain-catalog.js";
 export * from "./allocation-policy.js";
@@ -27,4 +28,5 @@ export * from "./operations-capability.js";
 export { WmsKernel } from "./kernel.js";
 export { YmsKernel } from "./yms-kernel.js";
 export { MesKernel, MES_PART_GTINS, MES_PRODUCT_GTINS, MES_PRODUCTS } from "./mes-kernel.js";
+export { EmsKernel, DEMAND_WINDOW_MS, demandWindowStart } from "./ems-kernel.js";
 export * from "./vocabulary.js";

package/dist/kernel.d.ts

@@ -35,11 +35,11 @@ export declare class WmsKernel extends FlowEngine {
      * 자재는 **작업이 일어나는 자리에** 있어야 소비되고, 산출물은 `in_progress` 로 태어나 **팔 수 있는
      * 재고가 아니다.** 그래서 부품을 작업대로 옮기고, 가공하고, 나온 것을 보관 자리로 되돌린다.
      *
-     * **한 오더에 사슬 하나만** 굴린다. 매 tick 마다 다시 발행하면 같은 부품을 두 번 끌어오는 작업이
+     * **한 오더에 사슬 하나만** 실행한다. 매 tick 마다 다시 발행하면 같은 부품을 두 번 끌어오는 작업이
      * 쌓이고, 그중 하나만 성공한 뒤 나머지는 영원히 재료를 기다린다.
      */
     private makeShortLines;
-    /** 이 오더가 굴리고 있는 생산 사슬이 있나 — 이송·가공·되돌리기 중 하나라도 열려 있으면 그렇다. */
+    /** 이 오더가 실행 중인 생산 사슬이 있나 — 이송·가공·되돌리기 중 하나라도 열려 있으면 그렇다. */
     private hasOpenMakeChain;
     /** 지금 재고 — 판단 함수가 보는 형태로. */
     private stockLines;
@@ -53,7 +53,7 @@ export declare class WmsKernel extends FlowEngine {
      * 들여놓는 것**이다: 산출물은 `in_progress` 로 태어나 팔 수 있는 재고가 아니다.
      *
      * ── 왜 팔레트로 묶나 ───────────────────────────────────────────────────────
-     * 코어의 산출은 **클래스+수량 줄**이고 그 키에는 자리가 박혀 있다(`품목@자리`). 창고의 출고 경로는
+     * 코어의 산출은 **클래스+수량 줄**이고 그 키에는 자리가 고정되어 있다(`품목@자리`). 창고의 출고 경로는
      * 직렬 물류단위(팔레트 SSCC)를 다루므로, 그 줄을 그대로 출고에 태우면 키를 EPC 로 착각해 조회가
      * 깨진다(실제로 그렇게 터졌다). 억지로 태우면 EPCIS 에도 **EPC 가 아닌 문자열**이 `epcList` 로
      * 나가는데, 그것은 코어가 산출에서 경계한 바로 그 일이다.

package/dist/kernel.js

@@ -164,7 +164,7 @@ export class WmsKernel extends FlowEngine {
     /** 태스크 완료 — 이동 반영 후 putaway=storing, pick=picking(+전량 시 pack→stage→ship). */
     onTaskComplete(t) {
         /*
-         * **생산 사슬의 걸음들을 먼저 가른다.** 아래 이동 처리는 "주체가 팔레트 하나" 를 전제하는데,
+         * **생산 사슬의 걸음들을 먼저 구분한다.** 아래 이동 처리는 "주체가 팔레트 하나" 를 전제하는데,
          * 가공은 클래스+수량 소비/산출이라 주체가 없다 — 그대로 두면 물품을 찾지 못해 터진다(실제로
          * 그랬다). 걸음마다 무엇이 끝난 것인지 다르므로 각각 답한다.
          */
@@ -211,7 +211,7 @@ export class WmsKernel extends FlowEngine {
      * 자재는 **작업이 일어나는 자리에** 있어야 소비되고, 산출물은 `in_progress` 로 태어나 **팔 수 있는
      * 재고가 아니다.** 그래서 부품을 작업대로 옮기고, 가공하고, 나온 것을 보관 자리로 되돌린다.
      *
-     * **한 오더에 사슬 하나만** 굴린다. 매 tick 마다 다시 발행하면 같은 부품을 두 번 끌어오는 작업이
+     * **한 오더에 사슬 하나만** 실행한다. 매 tick 마다 다시 발행하면 같은 부품을 두 번 끌어오는 작업이
      * 쌓이고, 그중 하나만 성공한 뒤 나머지는 영원히 재료를 기다린다.
      */
     makeShortLines(o) {
@@ -239,7 +239,7 @@ export class WmsKernel extends FlowEngine {
                 return; // 한 번에 한 라인씩 — 부품을 여러 라인이 동시에 다투지 않게
         }
     }
-    /** 이 오더가 굴리고 있는 생산 사슬이 있나 — 이송·가공·되돌리기 중 하나라도 열려 있으면 그렇다. */
+    /** 이 오더가 실행 중인 생산 사슬이 있나 — 이송·가공·되돌리기 중 하나라도 열려 있으면 그렇다. */
     hasOpenMakeChain(orderId) {
         for (const t of this.tasks.values()) {
             if (t.orderId !== orderId || t.status === 'completed')
@@ -274,7 +274,7 @@ export class WmsKernel extends FlowEngine {
         /* 물품을 지목하지 않는다 — 클래스+수량 소비/산출이므로 주체가 팔레트 하나가 아니다.
            코어의 작업 게이트는 빈 `itemEpc` 를 견딘다(`t.itemEpc && …` 조건부 확인). */
         /* **의도를 process 로 밝힌다** — 코어가 이 표시로 이동(모션)과 변환을 가르고, 이 커널의 완료 훅도
-           그것으로 판단한다. "선언된 오퍼레이션인가" 로 가르면 산출을 선언한 이동 작업까지 삼킨다. */
+           그것으로 판단한다. "선언된 오퍼레이션인가" 로 구분하면 산출을 선언한 이동 작업까지 삼킨다. */
         this.pushTask(o, operation, '', at, at, 'process');
     }
     pushTask(o, kind, itemEpc, from, to, intent) {
@@ -293,7 +293,7 @@ export class WmsKernel extends FlowEngine {
      * 들여놓는 것**이다: 산출물은 `in_progress` 로 태어나 팔 수 있는 재고가 아니다.
      *
      * ── 왜 팔레트로 묶나 ───────────────────────────────────────────────────────
-     * 코어의 산출은 **클래스+수량 줄**이고 그 키에는 자리가 박혀 있다(`품목@자리`). 창고의 출고 경로는
+     * 코어의 산출은 **클래스+수량 줄**이고 그 키에는 자리가 고정되어 있다(`품목@자리`). 창고의 출고 경로는
      * 직렬 물류단위(팔레트 SSCC)를 다루므로, 그 줄을 그대로 출고에 태우면 키를 EPC 로 착각해 조회가
      * 깨진다(실제로 그렇게 터졌다). 억지로 태우면 EPCIS 에도 **EPC 가 아닌 문자열**이 `epcList` 로
      * 나가는데, 그것은 코어가 산출에서 경계한 바로 그 일이다.

package/dist/mes-kernel.d.ts

@@ -27,7 +27,7 @@ export declare class MesKernel extends FlowEngine {
      * **산출을 두 곳에서 만들지 않는다** — 기동 때 막는다.
      *
      * MES 는 레시피로 산출을 만든다: WIP 사슬(스텝마다 앞의 WIP 을 먹고 다음 WIP 을 낸다) · **직렬번호**
-     * (회사 프리픽스 + 일련번호) · **수율**(양품/불량이 처분을 가른다) · 생산오더 연결. 코어의 일반
+     * (회사 프리픽스 + 일련번호) · **수율**(양품/불량이 처분을 구분한다) · 생산오더 연결. 코어의 일반
      * 자재 명세(`use: 'produced'`)는 **비직렬 클래스+수량**이라 그 넷을 표현하지 못한다.
      *
      * 그래서 MES 를 일반 선언으로 옮기지 않는다 — 옮기면 정체성·수율·오더 연결을 **잃는다**(§4-20).
@@ -56,7 +56,7 @@ export declare class MesKernel extends FlowEngine {
     /**
      * MES 는 완료 시점에 **오더와 제품 정의**를 딛고 선다 — 둘 중 하나만 없어도 끝맺을 수 없다.
      *
-     * 씨앗이 이미 이행된 오더를 심지 않으므로(남은 수량 0) 그 오더에 딸린 작업만 남을 수 있고,
+     * 씨앗이 이미 이행된 오더를 주입하지 않으므로(남은 수량 0) 그 오더에 딸린 작업만 남을 수 있고,
      * 관측이 오더 연결을 담지 못한 작업도 있다. 그때 예전에는 `order.gtin` 에서 던졌고 **그 예외
      * 하나가 정확도 추세 전체를 죽였다.** 이제 코어가 이 답을 보고 그 작업만 접는다.
      */