@operato/ops-contract 0.9.11 → 0.9.12

package/dist/canonical-record.d.ts

@@ -1,3 +1,4 @@
+import type { BizTransactionElement } from './epcis.ts';
 /** 개체 관측 — 물건 하나가 어디서 무엇이 됐나. */
 export interface CanonicalRecord {
     /**
@@ -21,6 +22,30 @@ export interface CanonicalRecord {
     action: string;
     bizStep: string;
     disposition?: string;
+    /**
+     * 오더 참조 — 「이 사실은 어느 오더 것인가」(표준 §7.3.5.4).
+     *
+     * ── 왜 뒤늦게 생겼나 (2026-09-07) ─────────────────────────────────────────
+     * 이 칸이 **다섯째 층**이었다. 같은 필드가 층마다 따로 막혀 있었고, 아래를 열어도 위에서 계속 사라졌다.
+     *
+     * ```
+     * 1  EpcisHeaderOptions      objectEvent 만 자기 인자로 갖고 있었다
+     * 2  매핑 스펙                커넥터가 어느 칸을 읽을지 선언할 자리가 없었다
+     * 3  유입 규칙 셋              선언해도 트윈이 그 스펙을 안 읽었다
+     * 4  정규 레코드              ← 여기. 내는 쪽이 값을 담을 칸이 없었다
+     * 5  원본 봉투                담을 값을 원본이 안 실었다
+     * ```
+     *
+     * 받는 쪽은 처음부터 다 서 있었다 — 저널의 `biz_transaction` 칸과 인덱스, 이력추적 질의, 커널이 그
+     * 값을 채우는 네 자리. 그래서 커널 안에서 나는 사실만 그 칸을 갖고 실 시스템이 먹이는 트윈은 비었다
+     * (시뮬 2,492건 대 `mes-line-a` 0건).
+     *
+     * ⚠ `type` 은 **거래의 종류**다. 생산 오더는 `BTT_PRODORDER`(`btt:prodorder`)이고 구매 오더의
+     * `btt:po` 와 다르다. 문자열을 손으로 적지 말고 프로파일의 상수를 부른다 — 나는 이 자리에서 `btt:po`
+     * 를 잘못 적어 전달했고, 인티그레이션 레인이 잡았다. 진짜 표준 URI 를 틀린 뜻으로 쓰는 것은 지어낸
+     * 이름보다 나쁘다: 읽는 사람이 그 뜻인 줄 배운다.
+     */
+    bizTransactionList?: BizTransactionElement[];
     readPoint?: string;
     bizLocation?: string;
 }
@@ -65,6 +90,30 @@ export interface CanonicalTransformationRecord {
     transformationID?: string;
     bizStep: string;
     disposition?: string;
+    /**
+     * 오더 참조 — 「이 사실은 어느 오더 것인가」(표준 §7.3.5.4).
+     *
+     * ── 왜 뒤늦게 생겼나 (2026-09-07) ─────────────────────────────────────────
+     * 이 칸이 **다섯째 층**이었다. 같은 필드가 층마다 따로 막혀 있었고, 아래를 열어도 위에서 계속 사라졌다.
+     *
+     * ```
+     * 1  EpcisHeaderOptions      objectEvent 만 자기 인자로 갖고 있었다
+     * 2  매핑 스펙                커넥터가 어느 칸을 읽을지 선언할 자리가 없었다
+     * 3  유입 규칙 셋              선언해도 트윈이 그 스펙을 안 읽었다
+     * 4  정규 레코드              ← 여기. 내는 쪽이 값을 담을 칸이 없었다
+     * 5  원본 봉투                담을 값을 원본이 안 실었다
+     * ```
+     *
+     * 받는 쪽은 처음부터 다 서 있었다 — 저널의 `biz_transaction` 칸과 인덱스, 이력추적 질의, 커널이 그
+     * 값을 채우는 네 자리. 그래서 커널 안에서 나는 사실만 그 칸을 갖고 실 시스템이 먹이는 트윈은 비었다
+     * (시뮬 2,492건 대 `mes-line-a` 0건).
+     *
+     * ⚠ `type` 은 **거래의 종류**다. 생산 오더는 `BTT_PRODORDER`(`btt:prodorder`)이고 구매 오더의
+     * `btt:po` 와 다르다. 문자열을 손으로 적지 말고 프로파일의 상수를 부른다 — 나는 이 자리에서 `btt:po`
+     * 를 잘못 적어 전달했고, 인티그레이션 레인이 잡았다. 진짜 표준 URI 를 틀린 뜻으로 쓰는 것은 지어낸
+     * 이름보다 나쁘다: 읽는 사람이 그 뜻인 줄 배운다.
+     */
+    bizTransactionList?: BizTransactionElement[];
     readPoint?: string;
     bizLocation?: string;
 }
@@ -81,6 +130,30 @@ export interface CanonicalAggregationRecord {
     action: string;
     bizStep: string;
     disposition?: string;
+    /**
+     * 오더 참조 — 「이 사실은 어느 오더 것인가」(표준 §7.3.5.4).
+     *
+     * ── 왜 뒤늦게 생겼나 (2026-09-07) ─────────────────────────────────────────
+     * 이 칸이 **다섯째 층**이었다. 같은 필드가 층마다 따로 막혀 있었고, 아래를 열어도 위에서 계속 사라졌다.
+     *
+     * ```
+     * 1  EpcisHeaderOptions      objectEvent 만 자기 인자로 갖고 있었다
+     * 2  매핑 스펙                커넥터가 어느 칸을 읽을지 선언할 자리가 없었다
+     * 3  유입 규칙 셋              선언해도 트윈이 그 스펙을 안 읽었다
+     * 4  정규 레코드              ← 여기. 내는 쪽이 값을 담을 칸이 없었다
+     * 5  원본 봉투                담을 값을 원본이 안 실었다
+     * ```
+     *
+     * 받는 쪽은 처음부터 다 서 있었다 — 저널의 `biz_transaction` 칸과 인덱스, 이력추적 질의, 커널이 그
+     * 값을 채우는 네 자리. 그래서 커널 안에서 나는 사실만 그 칸을 갖고 실 시스템이 먹이는 트윈은 비었다
+     * (시뮬 2,492건 대 `mes-line-a` 0건).
+     *
+     * ⚠ `type` 은 **거래의 종류**다. 생산 오더는 `BTT_PRODORDER`(`btt:prodorder`)이고 구매 오더의
+     * `btt:po` 와 다르다. 문자열을 손으로 적지 말고 프로파일의 상수를 부른다 — 나는 이 자리에서 `btt:po`
+     * 를 잘못 적어 전달했고, 인티그레이션 레인이 잡았다. 진짜 표준 URI 를 틀린 뜻으로 쓰는 것은 지어낸
+     * 이름보다 나쁘다: 읽는 사람이 그 뜻인 줄 배운다.
+     */
+    bizTransactionList?: BizTransactionElement[];
     readPoint?: string;
     bizLocation?: string;
 }

package/dist/capacity.d.ts

@@ -97,3 +97,25 @@ export declare function workingTimeOfWeek(calendar: readonly WorkCalendarEntry[]
  * 실행해 보지 않고 물을 수 있다(what-if 의 가장 싼 형태).
  */
 export declare function analyzeCapacity(input: CapacityInput): CapacityAnalysis;
+/**
+ * 이 창에서 **조업이 계획되지 않은 시간**(ms) — 없으면 `undefined`.
+ *
+ * ── 무엇에 쓰나 ─────────────────────────────────────────────────────────────
+ * ISO 22400 의 계획 조업 시간(PBT)에서 뺄 값이다(`OeeCounters.holdMs`). 커널의 PBT 가 「재기 시작한
+ * 뒤 흐른 시간 전부」였고, 그래서 주말·야간·휴일이 계획 조업으로 세어졌다.
+ *
+ * ── 선언이 없으면 `undefined` 다 ────────────────────────────────────────────
+ * **0 을 내지 않는다.** 0 은 「비근무 시간이 없다」는 주장이고, 그것은 24시간 365일 도는 현장에
+ * 대해서만 참이다. 선언이 없는 것은 **모르는 것**이고, 부르는 쪽이 그 둘을 갈라야 한다 — 0 을 받으면
+ * 「달력을 확인했고 쉬는 시간이 없었다」로 읽는다.
+ *
+ * `workingTimeOfWeek` 이 캘린더가 없을 때 종일 가동으로 보는 것과 방향이 반대로 보이지만, 그쪽은
+ * **능력**을 묻는 자리라 「최대 얼마나 돌 수 있나」에 답해야 하고, 이쪽은 **실적 지표**의 분모라
+ * 모르는 것을 채우면 그 수가 조용히 틀린다.
+ *
+ * ── 분 단위로 센다 ──────────────────────────────────────────────────────────
+ * `workingTimeOfWeek` 과 같은 방식이다(`inWorkCalendarAt` 을 분마다 묻는다). 구간 대수로 풀면
+ * 되풀이·요일·절대 구간이 겹칠 때의 규칙을 여기서 다시 적게 되고, 그 규칙은 이미 그 함수 안에 있다 —
+ * 두 곳이 다른 답을 내는 것이 이 저장소에서 여러 번 났다.
+ */
+export declare function nonWorkingMsIn(calendar: readonly WorkCalendarEntry[] | undefined, fromMs: number, toMs: number, utcOffsetMinutes?: number): number | undefined;

package/dist/capacity.js

@@ -170,3 +170,37 @@ export function analyzeCapacity(input) {
         ok: operations.every(o => o.ok)
     };
 }
+/**
+ * 이 창에서 **조업이 계획되지 않은 시간**(ms) — 없으면 `undefined`.
+ *
+ * ── 무엇에 쓰나 ─────────────────────────────────────────────────────────────
+ * ISO 22400 의 계획 조업 시간(PBT)에서 뺄 값이다(`OeeCounters.holdMs`). 커널의 PBT 가 「재기 시작한
+ * 뒤 흐른 시간 전부」였고, 그래서 주말·야간·휴일이 계획 조업으로 세어졌다.
+ *
+ * ── 선언이 없으면 `undefined` 다 ────────────────────────────────────────────
+ * **0 을 내지 않는다.** 0 은 「비근무 시간이 없다」는 주장이고, 그것은 24시간 365일 도는 현장에
+ * 대해서만 참이다. 선언이 없는 것은 **모르는 것**이고, 부르는 쪽이 그 둘을 갈라야 한다 — 0 을 받으면
+ * 「달력을 확인했고 쉬는 시간이 없었다」로 읽는다.
+ *
+ * `workingTimeOfWeek` 이 캘린더가 없을 때 종일 가동으로 보는 것과 방향이 반대로 보이지만, 그쪽은
+ * **능력**을 묻는 자리라 「최대 얼마나 돌 수 있나」에 답해야 하고, 이쪽은 **실적 지표**의 분모라
+ * 모르는 것을 채우면 그 수가 조용히 틀린다.
+ *
+ * ── 분 단위로 센다 ──────────────────────────────────────────────────────────
+ * `workingTimeOfWeek` 과 같은 방식이다(`inWorkCalendarAt` 을 분마다 묻는다). 구간 대수로 풀면
+ * 되풀이·요일·절대 구간이 겹칠 때의 규칙을 여기서 다시 적게 되고, 그 규칙은 이미 그 함수 안에 있다 —
+ * 두 곳이 다른 답을 내는 것이 이 저장소에서 여러 번 났다.
+ */
+export function nonWorkingMsIn(calendar, fromMs, toMs, utcOffsetMinutes) {
+    if (!calendar?.length)
+        return undefined;
+    if (!Number.isFinite(fromMs) || !Number.isFinite(toMs) || toMs <= fromMs)
+        return undefined;
+    const minutes = Math.floor((toMs - fromMs) / 60_000);
+    let closed = 0;
+    for (let m = 0; m < minutes; m++) {
+        if (!inWorkCalendarAt(calendar, fromMs + m * 60_000, utcOffsetMinutes))
+            closed++;
+    }
+    return closed * 60_000;
+}

package/dist/contract.d.ts

@@ -3660,6 +3660,57 @@ export interface TwinModelDef {
      * **절대 구간**(`StartDateTime`/`FinishDateTime`)을 계산해 넣는 것이다.
      */
     utcOffsetMinutes?: number;
+    /**
+     * 이 트윈이 선 곳의 **시간대 이름**(IANA — `Asia/Seoul` · `America/Tijuana`).
+     *
+     * ── 왜 오프셋 옆에 이름도 두나 (2026-09-07) ──────────────────────────────
+     * `utcOffsetMinutes` 는 **한 순간의** 오프셋이다. 호스트가 트윈을 세울 때 한 번 풀어 넣으면 그
+     * 수가 모델에 그대로 남고, 일광절약시간을 쓰는 곳에서는 계절이 바뀌는 순간부터 한 시간씩 틀린다.
+     * 트윈은 몇 주씩 돌고, `America/Tijuana`(PST −480 / PDT −420)가 이미 자료에 있다.
+     *
+     * 더 나쁜 것은 **지난 구간을 접을 때**다. 1년치 사실을 교대별로 접으면 그 1년을 한 오프셋으로
+     * 읽는데, 그 안에 전환이 두 번 들어 있다. 어긋난 시각이 오류를 내지 않고 다른 교대로 세어진다.
+     *
+     * 그래서 이름을 함께 든다. **커널은 이 값을 풀지 않는다** — zero-dep 이라 시간대 데이터를 들 수
+     * 없고, 여전히 오프셋을 호출마다 받는다(`weekdayAt` · `activeShiftAt` · `inWorkCalendarAt`).
+     * 이름은 **호스트가 매 순간마다 풀기 위한** 것이다. 그것이 이 계약이 원래 적어 둔 분담이다.
+     *
+     * 없으면 `utcOffsetMinutes` 로 떨어지고, 그것도 없으면 UTC 다 — 조용히 현지 시각으로 가정하지 않는다.
+     *
+     * ⚠ 이것으로도 완전하지 않다. 정확한 답은 여전히 호스트가 표준대로 **절대 구간**
+     * (`WorkCalendarEntry.startDateTime`/`finishDateTime`)을 계산해 넣는 것이다. 이름은 그때까지
+     * 「매 순간 다시 풀 수 있게」 해 주는 자리이고, 고정된 수보다는 맞다.
+     */
+    timezone?: string;
+    /**
+     * **이 현장이 언제 도나** — 표준 `WorkCalendarEntry`(복수). 휴일 · 주말 · 정기보수가 여기 든다.
+     *
+     * ── 왜 현장 단위인가 (2026-09-07) ────────────────────────────────────────
+     * 이 칸이 없던 동안 설비와 사람만 달력을 가질 수 있었다. 그래서 **현장이 언제 쉬는지가 어디에도
+     * 없었고**, 커널의 계획 조업 시간이 「재기 시작한 뒤 흐른 시간 전부」였다 — 주말도 야간도 휴일도
+     * 계획 조업으로 셌다.
+     *
+     * [산술] 8시간 × 주5일 현장이면 168시간 중 40시간이 조업이다. PBT 가 4.2배 크고 가동률이 그만큼
+     * 작다. 그리고 그 수가 **1로 잘려** 있어서(오늘 걷었다) 그럴싸하게 보였다 — 두 오류가 서로를 가렸다.
+     *
+     * 자리가 최상위인 이유는 `timezone` 이 이미 여기 있기 때문이다. 「이 현장의 06:00 이 언제인가」와
+     * 「이 현장이 언제 도나」는 같은 축이고, 다른 층에 두면 한쪽만 채워진 상태가 생긴다.
+     *
+     * ── 무엇이 이것을 이기나 ─────────────────────────────────────────────────
+     * ```
+     * equipment[].workCalendar   이 설비의 가동 계획 — 선언했으면 이것이 이긴다(24시간 도는 로)
+     * 이 칸                       현장의 조업 달력
+     * 아무것도 없음                제약 없음 — 커널이 멈출 이유를 모른다
+     * ```
+     *
+     * ⚠ **설비의 달력은 사람의 근무조가 아니다.** 그 둘을 한 칸에서 읽어서, 씨앗이 사람의 근무조를 설비
+     * 가동 달력에 복사한 일이 있었다 — 아무도 근무하지 않는 시간이 근무 시간으로 기록됐다. `persons[]`
+     * 의 달력이 사람 쪽이다.
+     *
+     * 없으면 **아무것도 가정하지 않는다.** 종일 가동으로 보는 것은 「제약이 없다」가 아니라 「선언되지
+     * 않았다」이고, 그 사실은 세어져야 한다(안 그러면 사람이 수를 되살리려고 아무 달력이나 채운다).
+     */
+    workCalendar?: WorkCalendarEntry[];
     /**
      * **시험 명세** — 표준 `TestSpecification`. 자원의 `testSpecificationIds` 가 가리키는 대상.
      *

package/dist/contract.js

@@ -667,13 +667,32 @@ function convertQuantity(item, uom, definitions) {
     const factor = conversionFactorOf(def, uom);
     return factor === undefined ? undefined : item.qty * factor;
 }
-/** `HH:MM` → 자정 이후 분. 형식이 아니면 `undefined`(짐작해 고치지 않는다). */
+/**
+ * `HH:MM` → 자정 이후 분. 형식이 아니면 `undefined`(짐작해 고치지 않는다).
+ *
+ * ── `24:00` 을 받는다 (2026-09-07) ──────────────────────────────────────────
+ * ISO 8601 이 `24:00` 을 **하루의 끝**으로 허용한다(같은 순간의 다른 이름 — 다음 날 `00:00`). 그것을
+ * 거절하고 있었고, 그래서 **종일 가동을 말할 방법이 없었다.**
+ *
+ * ```
+ * 00:00~24:00                  거절됐다 → 그 항목이 아무 분도 안 덮는다 → 종일 비근무
+ * 00:00~00:00 (toDayOffset 1)  from === to 라 길이 0 으로 읽힌다 → 종일 비근무
+ * ```
+ *
+ * 즉 24시간 도는 설비를 선언하면 **한 번도 안 도는 것**이 됐다. 사용자가 「aging 은 당연히 24시간
+ * 365일 도는 거지」라고 한 그 설비가 정확히 이 모양으로 선언된다.
+ *
+ * `24:00` 만 `1440` 으로 받는다 — `24:30` 은 여전히 거절한다(하루의 끝을 넘는 시각은 없다).
+ * `from === to` 는 그대로 길이 0 이다: 뜻이 갈리는 표기를 짐작하지 않고, 종일은 `24:00` 으로 적는다.
+ */
 function minutesOfDay(hhmm) {
     const m = /^(\d{1,2}):(\d{2})$/.exec(hhmm ?? '');
     if (!m)
         return undefined;
     const h = Number(m[1]);
     const mi = Number(m[2]);
+    if (h === 24)
+        return mi === 0 ? 24 * 60 : undefined;
     if (h > 23 || mi > 59)
         return undefined;
     return h * 60 + mi;

package/dist/domain-catalog.d.ts

@@ -1,6 +1,26 @@
 import type { CapabilityKey } from './capability.ts';
 import type { StandardClass } from './domain-definition.ts';
 import type { EquipmentLevel } from './contract.ts';
+/**
+ * 이 트윈이 아는 개념의 **닫힌 목록** — 화면이 무엇에 초점을 맞출 수 있나가 이 목록이다.
+ *
+ * ── 왜 닫나 (2026-09-07) ────────────────────────────────────────────────────
+ * `axis` 가 `string` 이라 아무 값이나 지났다. 그래서 두 제품이 같은 개념을 다른 이름으로 부르는 것을
+ * 타입이 못 잡았다.
+ *
+ * ```
+ * 트윈의 초점 종류   equipment · location · operation · order · sku
+ * 이 목록          equipment · locations · operations · orders · materialDefinitions …
+ *                  단수/복수가 갈리고, sku 는 이 목록에 없는 이름이다
+ * ```
+ *
+ * 그리고 내가 이 자리를 **「자원 종류 넷」으로 좁혀 답했다가 UX 레인에 교정받았다.** `operations` 와
+ * `orders` 는 자원이 아니라 축이고, 초점을 맞출 수 있는 것은 자원이 아니라 이 목록이다.
+ *
+ * ⚠ **복수형이 정본이다.** 이 이름이 `TwinModelDef` 의 키 그대로여야 하고(그 키가 복수다), 어긋나면
+ * 저장된 이름과 화면이 부르는 이름이 달라진다 — 그 어긋남은 오류를 내지 않고 **빈 목록**을 돌려준다.
+ */
+export type TwinAxis = 'locations' | 'equipment' | 'persons' | 'assets' | 'materials' | 'materialDefinitions' | 'items' | 'operations' | 'orders' | 'tasks' | 'recipes' | 'routes' | 'productionSpec' | 'testSpecifications' | 'demandWindows' | 'equipmentClasses' | 'personnelClasses' | 'materialClasses' | 'assetClasses';
 /**
  * 트윈의 종류 — 한 현실을 비추는 렌즈의 갈래.
  *
@@ -59,8 +79,11 @@ export interface TwinAxisInfo {
     /**
      * 축의 이름 — 화면·관계 선언이 쓰는 키. 최상위 축은 `TwinModelDef` 의 키 **그대로**다
      * (저장·계약의 이름과 어긋나면 그 순간 방언이 생긴다).
+     *
+     * **닫혀 있다**(§`TwinAxis`). 여기가 `string` 이던 동안 두 제품이 같은 개념을 다른 이름으로
+     * 부르는 것을 타입이 못 잡았다.
      */
-    axis: string;
+    axis: TwinAxis;
     /**
      * **무엇이 이 축의 항목을 가리키나** — 없으면 소비처가 `id` 를 쓴다.
      *

package/dist/epcis.d.ts

@@ -409,6 +409,17 @@ export interface EpcisHeaderOptions {
     eventID?: string;
     recordTime?: string;
     errorDeclaration?: ErrorDeclaration;
+    /**
+     * 오더 참조 — **표준이 헤더에 둔다**(§7.3.5.4). 어느 사건에나 붙는다.
+     *
+     * ── 왜 여기 없었나 (2026-09-07) ──────────────────────────────────────────
+     * `objectEvent` 만 자기 인자에 이 칸을 따로 갖고 있었다. 그래서 `aggregationEvent` ·
+     * `transformationEvent` 로 보낸 값은 **오류 없이 버려졌다** — 담김과 변환은 「이 물건이 어느 오더
+     * 것인가」를 말할 수 없었다.
+     *
+     * 헤더 필드를 한 갈래의 인자에 두면 이 일이 난다. `errorDeclaration` 이 같은 이유로 여기 있다.
+     */
+    bizTransactionList?: BizTransactionElement[];
     ilmd?: Record<string, unknown>;
     sourceList?: SourceElement[];
     destinationList?: DestinationElement[];

package/dist/epcis.js

@@ -357,6 +357,8 @@ function header(type, eventTime, bizStep, opts) {
         h.recordTime = opts.recordTime;
     if (opts?.errorDeclaration)
         h.errorDeclaration = opts.errorDeclaration;
+    if (opts?.bizTransactionList?.length)
+        h.bizTransactionList = opts.bizTransactionList;
     if (opts?.ilmd)
         h.ilmd = opts.ilmd;
     if (opts?.sourceList)

package/dist/face2-adapter.d.ts

@@ -75,6 +75,37 @@ export interface ObjectEventMapping {
     ilmd?: MapValue;
     readPoint?: MapValue;
     bizLocation?: MapValue;
+    /**
+     * **오더와 물건을 잇는 참조** → `bizTransactionList`(EPCIS 2.0 §7.3.5.4).
+     *
+     * ── 왜 뒤늦게 생겼나 (2026-09-07 실측) ─────────────────────────────────────
+     * `quantityList` · `ilmd` · `errorDeclaration` 과 **똑같은 모양의 결함**이다. 받는 쪽은 처음부터 다
+     * 서 있었다 — 저널에 `biz_transaction` 칸과 인덱스(`ix_twin_event_9`)가 있고, 계보 질의가
+     * `e.bizTransaction` 으로 거르고, 커널이 네 자리에서 그 값을 채운다. **문만 없었다.**
+     *
+     * 그래서 커널 안쪽에서 나는 사실만 그 칸을 갖고, 실 시스템이 먹이는 트윈은 조용히 빈다.
+     *
+     * ```
+     * hatio-mx2 (시뮬)   epcis.TransactionEvent 2,492건   채움
+     * mes-line-a          47건 → 0건
+     * mes-miratek         37건 → 0건
+     * ems · ppms · chef v1                                전부 0건
+     * ```
+     *
+     * 화면은 「이 물건이 어느 오더 것인가」에 답하지 못하는데 오류도 경고도 나지 않는다.
+     *
+     * ── 왜 `TransactionEventMapping` 을 새로 만들지 않았나 ────────────────────
+     * 표준이 이 필드를 **헤더**에 둔다(§7.3.5) — 어느 사건에나 붙는다. 그래서 재고 관측이 「이건 오더
+     * 33 것이다」라고 말하는 것은 표준 그대로이고 우회가 아니다.
+     *
+     * `TransactionEvent` 는 뜻이 다르다: **맺어졌다/풀렸다는 그 사건 자체**다(§7.4.3). 그 사실을 낼
+     * 원본이 생기면 그때 갈래를 넷으로 늘린다 — 지금 그것으로 관측을 대신 적으면, 일어나지 않은
+     * 「맺음」이 이력에 선다.
+     *
+     * 값은 **객체 배열 그대로** 받는다(`[{ type?, bizTransaction }]`). `bizTransaction` 은 URI 이고
+     * 커넥터가 `bizTransactionUri()` 로 만든다 — 여기서 이름 규칙을 다시 정하지 않는다.
+     */
+    bizTransactionList?: MapValue;
     /** 이 레코드가 앞선 사건의 정정이면 그 선언(§ErrorDeclarationMapping). */
     errorDeclaration?: ErrorDeclarationMapping;
 }
@@ -104,6 +135,37 @@ export interface AggregationEventMapping {
     childQuantityList?: MapValue;
     readPoint?: MapValue;
     bizLocation?: MapValue;
+    /**
+     * **오더와 물건을 잇는 참조** → `bizTransactionList`(EPCIS 2.0 §7.3.5.4).
+     *
+     * ── 왜 뒤늦게 생겼나 (2026-09-07 실측) ─────────────────────────────────────
+     * `quantityList` · `ilmd` · `errorDeclaration` 과 **똑같은 모양의 결함**이다. 받는 쪽은 처음부터 다
+     * 서 있었다 — 저널에 `biz_transaction` 칸과 인덱스(`ix_twin_event_9`)가 있고, 계보 질의가
+     * `e.bizTransaction` 으로 거르고, 커널이 네 자리에서 그 값을 채운다. **문만 없었다.**
+     *
+     * 그래서 커널 안쪽에서 나는 사실만 그 칸을 갖고, 실 시스템이 먹이는 트윈은 조용히 빈다.
+     *
+     * ```
+     * hatio-mx2 (시뮬)   epcis.TransactionEvent 2,492건   채움
+     * mes-line-a          47건 → 0건
+     * mes-miratek         37건 → 0건
+     * ems · ppms · chef v1                                전부 0건
+     * ```
+     *
+     * 화면은 「이 물건이 어느 오더 것인가」에 답하지 못하는데 오류도 경고도 나지 않는다.
+     *
+     * ── 왜 `TransactionEventMapping` 을 새로 만들지 않았나 ────────────────────
+     * 표준이 이 필드를 **헤더**에 둔다(§7.3.5) — 어느 사건에나 붙는다. 그래서 재고 관측이 「이건 오더
+     * 33 것이다」라고 말하는 것은 표준 그대로이고 우회가 아니다.
+     *
+     * `TransactionEvent` 는 뜻이 다르다: **맺어졌다/풀렸다는 그 사건 자체**다(§7.4.3). 그 사실을 낼
+     * 원본이 생기면 그때 갈래를 넷으로 늘린다 — 지금 그것으로 관측을 대신 적으면, 일어나지 않은
+     * 「맺음」이 이력에 선다.
+     *
+     * 값은 **객체 배열 그대로** 받는다(`[{ type?, bizTransaction }]`). `bizTransaction` 은 URI 이고
+     * 커넥터가 `bizTransactionUri()` 로 만든다 — 여기서 이름 규칙을 다시 정하지 않는다.
+     */
+    bizTransactionList?: MapValue;
     /** 이 레코드가 앞선 사건의 정정이면 그 선언(§ErrorDeclarationMapping). */
     errorDeclaration?: ErrorDeclarationMapping;
 }
@@ -136,6 +198,37 @@ export interface TransformationEventMapping {
     transformationID?: MapValue;
     readPoint?: MapValue;
     bizLocation?: MapValue;
+    /**
+     * **오더와 물건을 잇는 참조** → `bizTransactionList`(EPCIS 2.0 §7.3.5.4).
+     *
+     * ── 왜 뒤늦게 생겼나 (2026-09-07 실측) ─────────────────────────────────────
+     * `quantityList` · `ilmd` · `errorDeclaration` 과 **똑같은 모양의 결함**이다. 받는 쪽은 처음부터 다
+     * 서 있었다 — 저널에 `biz_transaction` 칸과 인덱스(`ix_twin_event_9`)가 있고, 계보 질의가
+     * `e.bizTransaction` 으로 거르고, 커널이 네 자리에서 그 값을 채운다. **문만 없었다.**
+     *
+     * 그래서 커널 안쪽에서 나는 사실만 그 칸을 갖고, 실 시스템이 먹이는 트윈은 조용히 빈다.
+     *
+     * ```
+     * hatio-mx2 (시뮬)   epcis.TransactionEvent 2,492건   채움
+     * mes-line-a          47건 → 0건
+     * mes-miratek         37건 → 0건
+     * ems · ppms · chef v1                                전부 0건
+     * ```
+     *
+     * 화면은 「이 물건이 어느 오더 것인가」에 답하지 못하는데 오류도 경고도 나지 않는다.
+     *
+     * ── 왜 `TransactionEventMapping` 을 새로 만들지 않았나 ────────────────────
+     * 표준이 이 필드를 **헤더**에 둔다(§7.3.5) — 어느 사건에나 붙는다. 그래서 재고 관측이 「이건 오더
+     * 33 것이다」라고 말하는 것은 표준 그대로이고 우회가 아니다.
+     *
+     * `TransactionEvent` 는 뜻이 다르다: **맺어졌다/풀렸다는 그 사건 자체**다(§7.4.3). 그 사실을 낼
+     * 원본이 생기면 그때 갈래를 넷으로 늘린다 — 지금 그것으로 관측을 대신 적으면, 일어나지 않은
+     * 「맺음」이 이력에 선다.
+     *
+     * 값은 **객체 배열 그대로** 받는다(`[{ type?, bizTransaction }]`). `bizTransaction` 은 URI 이고
+     * 커넥터가 `bizTransactionUri()` 로 만든다 — 여기서 이름 규칙을 다시 정하지 않는다.
+     */
+    bizTransactionList?: MapValue;
     /** 이 레코드가 앞선 사건의 정정이면 그 선언(§ErrorDeclarationMapping). */
     errorDeclaration?: ErrorDeclarationMapping;
 }

package/dist/face2-adapter.js

@@ -99,6 +99,31 @@ function resolveQuantityList(v, record, field, errors) {
     }
     return r.map(x => ({ ...x }));
 }
+/**
+ * 오더 참조 목록을 꺼낸다 — `[{ type?, bizTransaction }]`.
+ *
+ * `bizTransaction` 이 없는 원소는 **버리고 말한다.** 그 칸이 참조 자체이므로, 비면 그 원소는 아무것도
+ * 가리키지 않는다 — 그것을 통과시키면 저널에 빈 참조가 앉고 계보 질의가 그것으로 아무도 못 찾는다.
+ */
+function resolveBizTransactionList(v, record, errors) {
+    if (v === undefined)
+        return [];
+    const r = get(record, v.startsWith('$.') ? v.slice(2) : v);
+    if (r === undefined || r === null)
+        return [];
+    if (!Array.isArray(r) || r.some(x => !x || typeof x !== 'object' || Array.isArray(x))) {
+        errors.push(`bizTransactionList 가 객체 배열이 아니다(${v}): ${JSON.stringify(r).slice(0, 80)}`);
+        return [];
+    }
+    const out = [];
+    for (const x of r) {
+        if (typeof x.bizTransaction === 'string' && x.bizTransaction.trim())
+            out.push({ ...x });
+        else
+            errors.push(`bizTransactionList 의 원소에 bizTransaction 이 없다: ${JSON.stringify(x).slice(0, 80)}`);
+    }
+    return out;
+}
 /**
  * 객체 하나를 그대로 꺼낸다 — `ilmd` 처럼 **구조가 곧 값**인 자리.
  *
@@ -163,6 +188,8 @@ export function mapRecordChecked(record, mapping, eventTime) {
     /* 정정 선언은 표준 **헤더**의 것이므로 세 종류 모두에 담긴다(§7.5). 한 종류에만 내면 같은 결함이
        나머지 둘에 남는다 — 그것을 이미 두 번 겪었다(`quantityList` · `ilmd`). */
     const errorDeclaration = resolveErrorDeclaration(mapping.errorDeclaration, record, errors);
+    /* 오더 참조도 헤더의 것이라 같은 자리에서 푼다(§`bizTransactionList`). */
+    const bizTransactionList = resolveBizTransactionList(mapping.bizTransactionList, record, errors);
     if (mapping.type === 'TransformationEvent') {
         const inputEPCList = resolveList(mapping.inputEPCList, record, 'inputEPCList', errors);
         const inputQuantityList = resolveQuantityList(mapping.inputQuantityList, record, 'inputQuantityList', errors);
@@ -194,6 +221,7 @@ export function mapRecordChecked(record, mapping, eventTime) {
                 ...(outputQuantityList.length ? { outputQuantityList } : {}),
                 ...(transformationID ? { transformationID } : {}),
                 ...(errorDeclaration ? { errorDeclaration } : {}),
+                ...(bizTransactionList.length ? { bizTransactionList } : {}),
                 readPoint, bizLocation
             }),
             errors
@@ -211,6 +239,7 @@ export function mapRecordChecked(record, mapping, eventTime) {
                 ...(childEPCs.length ? { childEPCs } : {}),
                 ...(childQuantityList.length ? { childQuantityList } : {}),
                 ...(errorDeclaration ? { errorDeclaration } : {}),
+                ...(bizTransactionList.length ? { bizTransactionList } : {}),
                 readPoint, bizLocation
             }),
             errors
@@ -232,6 +261,7 @@ export function mapRecordChecked(record, mapping, eventTime) {
             ...(quantityList.length ? { quantityList } : {}),
             ...(ilmd ? { ilmd } : {}),
             ...(errorDeclaration ? { errorDeclaration } : {}),
+            ...(bizTransactionList.length ? { bizTransactionList } : {}),
             readPoint, bizLocation
         }),
         errors

package/dist/oee.js

@@ -32,7 +32,18 @@ export function computeOee(c, nowMs) {
         missing.push('planned-busy-time');
     /* 대기는 남는 시간이다 — 계획 조업에서 생산·준비·고장을 뺀 것. 따로 재지 않아도 나온다. */
     const delayMs = Math.max(0, planned - c.runMs - c.setupMs - c.downMs);
-    const availability = planned > 0 ? Math.min(1, c.runMs / planned) : undefined;
+    /*
+     * ── 1 로 자르지 않는다 (2026-09-07) ────────────────────────────────────────
+     * 여기 `Math.min(1, …)` 이 있었다. 그러면 **계획 밖에 돌린 것이 사라진다** — 휴일에 11시간을
+     * 돌렸는데 가동률이 1.0 으로 보이고, 그것은 「계획대로 꽉 돌았다」와 구별되지 않는다.
+     *
+     * ISO 22400 에서 APT 는 **잰 값**이고 PBT 는 **계획한 값**이다. 둘의 비가 1을 넘는 것은 오류가
+     * 아니라 사실이다 — 계획보다 더 돌았다. 그것이 이 지표가 말해야 하는 것 중 하나다: 휴일 가동 ·
+     * 계획 없이 돌린 설비 · 계획 조업 시간을 잘못 선언한 현장이 전부 이 모양으로 드러난다.
+     *
+     * 자르면 그 셋이 「정상」과 같아진다. plant 레인이 휴일을 선언해 보다 이 자리를 찾았다.
+     */
+    const availability = planned > 0 ? c.runMs / planned : undefined;
     const produced = c.goodCount + c.nonconformingCount;
     if (produced <= 0)
         missing.push('produced-quantity');

package/dist/operational-ingest.js

@@ -206,7 +206,24 @@ const SPECS = {
         fields: {
             orderId: 'string', kind: 'string', status: 'string', requested: 'number', fulfilled: 'number',
             gtin: 'string', held: 'boolean', lines: 'object[]', priority: 'number', startTime: 'string', endTime: 'string',
-            allocated: 'string[]', bizTransaction: 'string', operationsRequestId: 'string', dockDoor: 'string', windowStartMs: 'number', recordTime: 'string'
+            allocated: 'string[]', bizTransaction: 'string', operationsRequestId: 'string', dockDoor: 'string', windowStartMs: 'number', recordTime: 'string',
+            /*
+             * 이 오더를 어느 레시피로 돌리나 — 「이 로트를 무엇으로 만들었나」가 이 칸을 지나 답한다.
+             *
+             * ── 왜 뒤늦게 생겼나 (2026-09-07 측정) ─────────────────────────────────
+             * EPCIS 변환 사건에는 레시피 자리가 없다(표준이 그렇다). 그래서 이력추적이 **변환 → 거래
+             * 식별자 → 그 오더의 `recipeKey`** 로 건너간다(`twin-lineage-query.ts:296-315`).
+             *
+             * 변환이 오더를 가리키게 만든 뒤에 재보니, **가리켜진 오더 행에 그 칸이 없었다.** 실으면
+             * 레코드가 통째로 거절됐다 — `order: 계약에 없는 필드 — recipeKey`. 조용히 버리지 않은 것은
+             * 맞지만, 그래서 실 시스템에서는 그 물음이 계속 답이 없었다.
+             *
+             * 값은 원본에 있다: `job_orders.recipe_key` 35개 중 20개 채움
+             * (`WO-ECU-STD-2609A` = `RECIPE-ECU-STD`).
+             *
+             * 새 어휘가 아니다 — 계약이 `recipeKey` 를 네 자리에서 이미 쓴다. 오더 관측에만 자리가 없었다.
+             */
+            recipeKey: 'string'
         }
         /* 상태·종류는 도메인이 소유한다 — 닫지 않는다. */
     },

package/dist/webhook.d.ts

@@ -51,6 +51,135 @@ export type WebhookSenderAction = 'accepted' | 'partial' | 'resend-from' | 'wait
 export declare function webhookSenderAction(status: number): WebhookSenderAction;
 /** 429 를 함께 쓰는 곳이 있다 — 받는 쪽이 따라가지 못한다는 뜻이고, 행동은 503 과 같다. */
 export declare const WEBHOOK_TOO_MANY = 429;
+/**
+ * One record the receiver would not take.
+ *
+ * Two shapes, because the sender's own row can only be found one of two ways. When the batch
+ * carried an envelope id, that id comes back and the sender marks exactly that row. When it did
+ * not, the record itself comes back, so a person can at least see what was dropped.
+ *
+ * **An empty id is never sent instead.** A sender that looks up "" finds no row and reads the
+ * response as "nothing was rejected", which is the failure this whole declaration exists to stop.
+ */
+export type WebhookRejection = {
+    eventId: string;
+    errors: string[];
+} | {
+    record: unknown;
+    errors: string[];
+};
+/**
+ * What the receiver replies with — **the shape the sender has to read.**
+ *
+ * ── Why this is declared at all (2026-09-07, measured by the plant and integration lanes) ──
+ * Three other modules in this contract pin `rejected` as `{ record, errors }[]`
+ * (`face2-adapter`, `energy-ingest`, `master-data`). This module — the only one a sender reads —
+ * had it in prose alone: `WebhookSenderAction` says "keep the response's `rejected` aside" without
+ * ever saying its shape.
+ *
+ * So a sender guessed. operato-plant read it as a list of envelope id strings and wrote that guess
+ * into its own file as if it were the contract. `Array.isArray` passes on both shapes, so no guard
+ * caught it: the ids matched nothing, and the whole batch was stamped delivered.
+ *
+ * ```
+ * mes_outbox_events seq 178   status SENT · attempts 0 · no error
+ * the envelope                had no inputQuantityList — the kernel was right to reject it
+ * the twin's journal          two transformations seated; 178 is not among them
+ * ```
+ *
+ * The sender was told nothing. Neither side could see it alone — one saw three delivered, the
+ * other saw two stored.
+ *
+ * **Prose that instructs without describing is the gap.** A contract that says what to do with a
+ * field, but not what the field looks like, sends every reader off to guess the same way.
+ *
+ * ── What is optional and why ───────────────────────────────────────────────
+ * Nothing here is filled in with a default when absent. `lastSeq` missing is not seq 0, and
+ * `rejected` missing is not an empty list — it is a receiver that had nothing to reject, which is
+ * a different statement from "the field arrived empty". A sender that cannot tell those apart
+ * marks rows on a guess.
+ */
+export interface WebhookResponse {
+    /** Whether the receiver took the batch. `false` rides along with every non-200 status. */
+    ok: boolean;
+    /** Short reason, present when `ok` is false. Not for branching on — the status code decides. */
+    error?: string;
+    /** Echo of the envelope's numbering unit, so a sender with several can tell which line replied. */
+    scope?: string;
+    /**
+     * Whether numbering was checked at all. **`false` is not "no problem"** — it means the source
+     * does not number, so there was nothing to verify. Folding the two together hides which
+     * connections are actually keeping continuity.
+     */
+    sequenceChecked?: boolean;
+    /** Highest number taken. Everything up to it may be marked sent. */
+    lastSeq?: number;
+    /** With a 409: resend from here. */
+    expectedSeq?: number;
+    /**
+     * With a first envelope: how many numbers below it were never received (`seq - 1`).
+     *
+     * Not a loss count — a source that ran for a year before the twin was attached legitimately
+     * starts at seq 4,712. The contract cannot tell the two apart, so it reports the fact and
+     * leaves the judgement to whoever knows when the source started sending.
+     */
+    firstUnseenBefore?: number;
+    /** With a 503 or 429: hold the facts this long before trying again. Do not drop them. */
+    retryAfterMs?: number;
+    /**
+     * How many records the batch handed over — **the left side of a sum that closes.**
+     *
+     * ```
+     * offered === applied + duplicates + rejected.length + vocabulary
+     * ```
+     *
+     * A sender can check this without reading `rejected` at all, which is the point: on seq 178,
+     * three offered against two applied says something was dropped even while the rejection list
+     * itself is being misread as a list of ids.
+     *
+     * **Check it only where the terms are reported — the 200 and the 422.** A 409 says the batch
+     * was not taken at all and a 503 says nothing landed, so neither carries `applied`; reading an
+     * absent term as zero there would make every hold look like a loss. Both statuses already tell
+     * the sender what to do (resend from `expectedSeq`, or wait `retryAfterMs`), and neither asks it
+     * to reconcile. This paragraph is here because the first version of this field claimed the sum
+     * closes on every reply, which is a second over-broad claim in the same doc comment.
+     *
+     * **`vocabulary` belongs in the sum, and leaving it out was wrong.** This field first said the
+     * sum closed on `applied + duplicates` alone. It does not: vocabulary elements are counted in
+     * `offered` and are deliberately kept out of the other three, so every batch carrying one would
+     * have failed the check. A sender that is warned on ordinary traffic stops reading the warning,
+     * and then misses the real one — which is the whole defect this field exists to catch.
+     *
+     * The integration lane found that by looking for a counterexample instead of confirmation, and
+     * had a measured one: 32 distinct facts reconciled as 29 journal + 2 rejected + 1 vocabulary.
+     *
+     * This field is also why the declaration was written from a typecheck and not a grep — the
+     * receiver had been sending it on the 200, the 422 and the 503 for months, undeclared.
+     */
+    offered?: number;
+    /**
+     * How many records were vocabulary, not events.
+     *
+     * These set state and never reach the journal: they carry no time axis, so seating them as
+     * "what happened then" would date a fact that has no date. The receiver splits them by type so
+     * that mistake cannot be made (§`CanonicalIngestResult.masterData`).
+     *
+     * They are reported because the alternative is a sum that does not close. A sender told only
+     * `applied` and `duplicates` sees a vocabulary element as a loss.
+     */
+    vocabulary?: number;
+    /** How many records were newly applied. */
+    applied?: number;
+    /** How many were already known. Not a failure — resends are normal here. */
+    duplicates?: number;
+    /**
+     * What was not taken. Present only when something was rejected.
+     *
+     * A sender must set these aside rather than resend them: the shape is wrong, so the same bytes
+     * would be refused again, and everything that travelled with them is already in.
+     */
+    rejected?: WebhookRejection[];
+}
 /**
  * 봉투 하나 — 번호와 사실을 함께 든다.
  *

package/dist-cjs/index.cjs

@@ -173,6 +173,7 @@ __export(index_exports, {
   minuteOfDayAt: () => minuteOfDayAt,
   missingCommandPayload: () => missingCommandPayload,
   nextCommandState: () => nextCommandState,
+  nonWorkingMsIn: () => nonWorkingMsIn,
   normalizeEquipmentStatus: () => normalizeEquipmentStatus,
   objectEvent: () => objectEvent,
   objectUri: () => objectUri,
@@ -667,6 +668,7 @@ function minutesOfDay(hhmm) {
   if (!m) return void 0;
   const h = Number(m[1]);
   const mi = Number(m[2]);
+  if (h === 24) return mi === 0 ? 24 * 60 : void 0;
   if (h > 23 || mi > 59) return void 0;
   return h * 60 + mi;
 }
@@ -1201,6 +1203,16 @@ function analyzeCapacity(input) {
     ok: operations.every((o) => o.ok)
   };
 }
+function nonWorkingMsIn(calendar, fromMs, toMs, utcOffsetMinutes) {
+  if (!calendar?.length) return void 0;
+  if (!Number.isFinite(fromMs) || !Number.isFinite(toMs) || toMs <= fromMs) return void 0;
+  const minutes = Math.floor((toMs - fromMs) / 6e4);
+  let closed = 0;
+  for (let m = 0; m < minutes; m++) {
+    if (!inWorkCalendarAt(calendar, fromMs + m * 6e4, utcOffsetMinutes)) closed++;
+  }
+  return closed * 6e4;
+}
 
 // src/wms-profile.ts
 var BIZSTEP = {
@@ -2871,6 +2883,7 @@ function header(type, eventTime, bizStep, opts) {
   if (opts?.eventID) h.eventID = opts.eventID;
   if (opts?.recordTime) h.recordTime = opts.recordTime;
   if (opts?.errorDeclaration) h.errorDeclaration = opts.errorDeclaration;
+  if (opts?.bizTransactionList?.length) h.bizTransactionList = opts.bizTransactionList;
   if (opts?.ilmd) h.ilmd = opts.ilmd;
   if (opts?.sourceList) h.sourceList = opts.sourceList;
   if (opts?.destinationList) h.destinationList = opts.destinationList;
@@ -3103,6 +3116,21 @@ function resolveQuantityList(v, record, field, errors) {
   }
   return r.map((x) => ({ ...x }));
 }
+function resolveBizTransactionList(v, record, errors) {
+  if (v === void 0) return [];
+  const r = get(record, v.startsWith("$.") ? v.slice(2) : v);
+  if (r === void 0 || r === null) return [];
+  if (!Array.isArray(r) || r.some((x) => !x || typeof x !== "object" || Array.isArray(x))) {
+    errors.push(`bizTransactionList \uAC00 \uAC1D\uCCB4 \uBC30\uC5F4\uC774 \uC544\uB2C8\uB2E4(${v}): ${JSON.stringify(r).slice(0, 80)}`);
+    return [];
+  }
+  const out = [];
+  for (const x of r) {
+    if (typeof x.bizTransaction === "string" && x.bizTransaction.trim()) out.push({ ...x });
+    else errors.push(`bizTransactionList \uC758 \uC6D0\uC18C\uC5D0 bizTransaction \uC774 \uC5C6\uB2E4: ${JSON.stringify(x).slice(0, 80)}`);
+  }
+  return out;
+}
 function resolveObject(v, record, field, errors) {
   if (v === void 0) return void 0;
   const r = get(record, v.startsWith("$.") ? v.slice(2) : v);
@@ -3138,6 +3166,7 @@ function mapRecordChecked(record, mapping, eventTime) {
   const readPoint = resolve(mapping.readPoint, record, "readPoint", errors);
   const bizLocation = resolve(mapping.bizLocation, record, "bizLocation", errors);
   const errorDeclaration = resolveErrorDeclaration(mapping.errorDeclaration, record, errors);
+  const bizTransactionList = resolveBizTransactionList(mapping.bizTransactionList, record, errors);
   if (mapping.type === "TransformationEvent") {
     const inputEPCList = resolveList(mapping.inputEPCList, record, "inputEPCList", errors);
     const inputQuantityList = resolveQuantityList(mapping.inputQuantityList, record, "inputQuantityList", errors);
@@ -3163,6 +3192,7 @@ function mapRecordChecked(record, mapping, eventTime) {
         ...outputQuantityList.length ? { outputQuantityList } : {},
         ...transformationID ? { transformationID } : {},
         ...errorDeclaration ? { errorDeclaration } : {},
+        ...bizTransactionList.length ? { bizTransactionList } : {},
         readPoint,
         bizLocation
       }),
@@ -3185,6 +3215,7 @@ function mapRecordChecked(record, mapping, eventTime) {
         ...childEPCs.length ? { childEPCs } : {},
         ...childQuantityList.length ? { childQuantityList } : {},
         ...errorDeclaration ? { errorDeclaration } : {},
+        ...bizTransactionList.length ? { bizTransactionList } : {},
         readPoint,
         bizLocation
       }),
@@ -3208,6 +3239,7 @@ function mapRecordChecked(record, mapping, eventTime) {
       ...quantityList.length ? { quantityList } : {},
       ...ilmd ? { ilmd } : {},
       ...errorDeclaration ? { errorDeclaration } : {},
+      ...bizTransactionList.length ? { bizTransactionList } : {},
       readPoint,
       bizLocation
     }),
@@ -3503,7 +3535,24 @@ var SPECS = {
       operationsRequestId: "string",
       dockDoor: "string",
       windowStartMs: "number",
-      recordTime: "string"
+      recordTime: "string",
+      /*
+       * 이 오더를 어느 레시피로 돌리나 — 「이 로트를 무엇으로 만들었나」가 이 칸을 지나 답한다.
+       *
+       * ── 왜 뒤늦게 생겼나 (2026-09-07 측정) ─────────────────────────────────
+       * EPCIS 변환 사건에는 레시피 자리가 없다(표준이 그렇다). 그래서 이력추적이 **변환 → 거래
+       * 식별자 → 그 오더의 `recipeKey`** 로 건너간다(`twin-lineage-query.ts:296-315`).
+       *
+       * 변환이 오더를 가리키게 만든 뒤에 재보니, **가리켜진 오더 행에 그 칸이 없었다.** 실으면
+       * 레코드가 통째로 거절됐다 — `order: 계약에 없는 필드 — recipeKey`. 조용히 버리지 않은 것은
+       * 맞지만, 그래서 실 시스템에서는 그 물음이 계속 답이 없었다.
+       *
+       * 값은 원본에 있다: `job_orders.recipe_key` 35개 중 20개 채움
+       * (`WO-ECU-STD-2609A` = `RECIPE-ECU-STD`).
+       *
+       * 새 어휘가 아니다 — 계약이 `recipeKey` 를 네 자리에서 이미 쓴다. 오더 관측에만 자리가 없었다.
+       */
+      recipeKey: "string"
     }
     /* 상태·종류는 도메인이 소유한다 — 닫지 않는다. */
   },
@@ -4043,7 +4092,7 @@ function computeOee(c, nowMs) {
   const planned = c.metricsSinceMs == null ? 0 : Math.max(0, nowMs - c.metricsSinceMs - (c.holdMs ?? 0));
   if (planned <= 0) missing.push("planned-busy-time");
   const delayMs = Math.max(0, planned - c.runMs - c.setupMs - c.downMs);
-  const availability = planned > 0 ? Math.min(1, c.runMs / planned) : void 0;
+  const availability = planned > 0 ? c.runMs / planned : void 0;
   const produced = c.goodCount + c.nonconformingCount;
   if (produced <= 0) missing.push("produced-quantity");
   const quality = produced > 0 ? c.goodCount / produced : void 0;
@@ -4495,6 +4544,7 @@ function commandSpecGaps(specs, command) {
   minuteOfDayAt,
   missingCommandPayload,
   nextCommandState,
+  nonWorkingMsIn,
   normalizeEquipmentStatus,
   objectEvent,
   objectUri,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@operato/ops-contract",
-  "version": "0.9.11",
+  "version": "0.9.12",
   "description": "Operations domain contract — the standard vocabulary that producers and readers agree on (EPCIS 2.0/GS1, ISA-95, IEC 61850/ISO 50001). Types, guards, validation. No state, no engine.",
   "type": "module",
   "main": "./dist-cjs/index.cjs",