@things-factory/headless-twin 10.0.9 → 10.0.10

package/server/service/twin-journal/twin-journal-query.ts

@@ -16,6 +16,20 @@ import { computeTwinKpi, resolveTwinTargets } from '../../engine/kpi-query.js'
  * twinReplay : 내구 저널을 replay 해 상태 재구성(재부팅 복구·시간여행) — untilRevision 으로 임의 과거.
  * (실시간 스트림은 twinState subscription, 명령은 twin-control mutation. 이건 '질의' 표면.)
  */
+/**
+ * 시각 필터 값을 날짜로 — 배열(between)이면 원소마다.
+ *
+ * 못 읽는 값은 **그대로 둔다.** 여기서 지어내면 사용자가 요청하지 않은 구간을 조회하게 된다.
+ */
+function toDateValue(v: any): any {
+  const one = (x: any) => {
+    if (x instanceof Date) return x
+    const t = typeof x === 'string' ? Date.parse(x) : NaN
+    return Number.isNaN(t) ? x : new Date(t)
+  }
+  return Array.isArray(v) ? v.map(one) : one(v)
+}
+
 @Resolver()
 export class TwinJournalQuery {
   @Query(returns => [TwinEvent], {
@@ -32,8 +46,8 @@ export class TwinJournalQuery {
   ): Promise<TwinEvent[]> {
     const where: any = { domain: { id: context.state.domain.id }, instanceId }
     if (eventType) where.eventType = eventType
-    /* 시각 커서(untilTime, ISO) 우선 — eventTime ≤ T(공유 clock). eventTime 은 ISO 문자열 컬럼이라 lexicographic 비교 성립. */
-    if (untilTime != null) where.eventTime = LessThanOrEqual(untilTime)
+    /* 시각 커서(untilTime, ISO) 우선 — eventTime ≤ T(공유 clock). 컬럼이 날짜라 **날짜로 넘긴다.** */
+    if (untilTime != null) where.eventTime = LessThanOrEqual(new Date(untilTime))
     else if (fromRevision != null && toRevision != null) where.revision = Between(fromRevision, toRevision)
     else if (fromRevision != null) where.revision = MoreThanOrEqual(fromRevision)
     else if (toRevision != null) where.revision = LessThanOrEqual(toRevision)
@@ -91,7 +105,16 @@ export class TwinJournalQuery {
       pagination: { page: params.pagination?.page ?? 1, limit },
       /* 기본 정렬은 시각 내림차순 — 여러 트윈을 합칠 때 공통 축은 revision(트윈별 카운터)이 아니라
        * **시각**이다. revision 으로 섞으면 서로 다른 트윈의 무관한 카운터가 뒤엉킨다. */
-      sortings: params.sortings?.length ? params.sortings : [{ name: 'eventTime', desc: true }]
+      sortings: params.sortings?.length ? params.sortings : [{ name: 'eventTime', desc: true }],
+      /*
+       * 시각 필터는 **날짜로 바꿔서** 질의 빌더에 넘긴다.
+       *
+       * 화면은 ISO 문자열(`2026-08-07T11:00:00.000Z`)을 보내는데 eventTime 은 날짜 컬럼이고,
+       * sqlite 는 그것을 공백 구분 형식(`2026-08-07 11:00:00.000`)으로 저장한다. 문자열 그대로
+       * 비교하면 사전식으로 어긋나 **오류 없이 빈 결과**가 나온다(실측으로 확인했다).
+       * 화면이 날짜를 어떻게 적어 보내든 서버가 받아 주는 편이 맞다 — 계약을 좁히는 대신 경계에서 옮긴다.
+       */
+      filters: (params.filters ?? []).map(f => (f.name === 'eventTime' ? { ...f, value: toDateValue(f.value) } : f))
     }
 
     const qb = getQueryBuilderFromListParams({
@@ -99,7 +122,7 @@ export class TwinJournalQuery {
       params: effective,
       domain,
       /* 전부 인덱스 가능한 승격 컬럼 — 자유 검색어는 서버가 이 축들로 펼친다. */
-      searchables: ['epc', 'orderId', 'locationId', 'moverId', 'bizStep', 'eventType'],
+      searchables: ['epc', 'orderId', 'locationId', 'moverId', 'bizStep', 'eventType', 'correlationId'],
       /* 정렬은 인덱스가 받쳐 주는 축으로만 — 큰 저널에서 임의 컬럼 정렬은 전체 정렬 스캔이다. */
       sortables: ['eventTime', 'revision', 'eventType', 'bizStep'],
       defaultLimit: 100,
@@ -118,7 +141,7 @@ export class TwinJournalQuery {
   }
 
   /**
-   * 업무 KPI — 시간창 처리량·소요시간·자원 점유. 저널을 **접어서** 만든다(새 계측을 심지 않는다).
+   * 업무 KPI — 시간창 처리량·소요시간·자원 점유. 저널을 **접어서** 만든다(새 계측을 주입하지 않는다).
    *
    * `twinMetrics`(초당 이벤트 수 = 인프라 부하)와 **다른 것**이다: 이건 "지난 한 시간에 몇 건 처리했고
    * 한 건에 얼마나 걸렸나" 다. 이름이 비슷해 헷갈리기 쉬우므로 설명에 명시한다.
@@ -128,7 +151,7 @@ export class TwinJournalQuery {
    */
   @Query(returns => ScalarObject, {
     description:
-      'Windowed business KPI folded from the event journal, for one space (every running twin in it, folded together — averaging per-twin percentiles would be wrong) or one twin: throughput (completed tasks / orders), lead / work / wait time distributions (p50·p90), and per-resource busy ratio. Distinct from twinMetrics, which reports infrastructure throughput (events per second). When toTime is omitted the window ends at the twin\'s own last recorded event time, not wall clock — a simulated twin lives on its own clock, so asking for \'the last hour\' in real time would always find nothing. The basis used is reported in window.basis. Pass groupBy (resource | taskKind | location | order | area | shift) to break the same window down by that perspective. The shift axis is **computed, not stored**: the journal records only times, and the shift is derived from each completion\'s time plus the declared site shifts and time zone — so correcting a shift definition re-counts history correctly instead of leaving it frozen under the old boundaries. Sites that declare no shifts report every group as unknown rather than inventing shift names — per-group numbers use the same rules as the totals, so group counts sum to the total, and groups beyond groupLimit are reported as groups.truncated (how many groups) and groups.truncatedTasks (how much work those groups held) rather than silently dropped. Pass compareTo (previous | yesterday) to fold the same-length window shifted back and get comparison.delta (current minus that window); when the comparison window has no records, comparison.measured is false and no delta is produced rather than reporting zero change. Passing groupBy together with compareTo crosses the two: each group carries prevTasks / deltaTasks / deltaWorkP50Ms, groups absent from the comparison window are flagged isNew (no delta, so growth is not implied), and groups that had work before but none now are returned in groups.disappeared so a stopped area is never silently missing from the table. Area breakdown needs board locations to carry a parent area; when they do not, groups.note says so instead of implying there was no work. When the journal read hits its row cap, eventsCapped is true and every number is a lower bound — narrow the window and ask again rather than reading the smaller figures as a drop in performance. When operational targets are set for the space or instance, `targets` carries the verdicts [{metric, actual, target, direction, met, ratio}] — ratio is normalised so that 1 or more is always good, letting throughput and duration metrics be compared on one scale. A metric with no target, or with no measurement in the window, is absent from `targets` rather than reported as a miss, because a period with no work would otherwise read as a perfect score on duration metrics. Completions are counted in the window they complete; starts are looked up before the window, and any completion whose start was not found is reported in `unpaired` rather than silently dropped. Pass baselinePeriods (1-14, with baselineStride day | week) to fold the same time-of-day window on each of the last N days (or the same weekday on each of the last N weeks) and get `baseline.metrics` — per metric the distribution of those windows (min / median / max) plus where the current window sits: `rank` (1 = smallest, direction-free) and `standing` (best | better-than-typical | typical | worse-than-typical | worst, which does apply the metric direction). This answers what a single comparison cannot: comparing to yesterday alone is useless if yesterday was also bad. Every requested window is returned in `samples` with `measured` true or false — windows without records are kept and counted (measuredCount vs requested) rather than dropped, so "the last 7 days" never silently means 3. No position is reported when the current window has no value or fewer than two baseline windows were measured; `noPosition` says which, because a missing distribution drawn as neutral would read as "typical". The baseline is produced even when the current window itself has no records, since that is exactly when knowing the usual level matters (a stopped line).'
+      'Windowed business KPI folded from the event journal, for one space (every running twin in it, folded together — averaging per-twin percentiles would be wrong) or one twin: throughput (completed tasks / orders), lead / work / wait time distributions (p50·p90), and per-resource busy ratio. Distinct from twinMetrics, which reports infrastructure throughput (events per second). When toTime is omitted the window ends at the twin\'s own last recorded event time, not wall clock — a simulated twin lives on its own clock, so asking for \'the last hour\' in real time would always find nothing. The basis used is reported in window.basis. Pass groupBy (resource | taskKind | location | order | area | shift) to break the same window down by that perspective. The shift axis is **computed, not stored**: the journal records only times, and the shift is derived from each completion\'s time plus the declared site shifts and time zone — so correcting a shift definition re-counts history correctly instead of leaving it frozen under the old boundaries. Sites that declare no shifts report every group as unknown rather than inventing shift names — per-group numbers use the same rules as the totals, so group counts sum to the total, and groups beyond groupLimit are reported as groups.truncated (how many groups) and groups.truncatedTasks (how much work those groups held) rather than silently dropped. Pass compareTo (previous | yesterday) to fold the same-length window shifted back and get comparison.delta (current minus that window); when the comparison window has no records, comparison.measured is false and no delta is produced rather than reporting zero change. Passing groupBy together with compareTo crosses the two: each group carries prevTasks / deltaTasks / deltaWorkP50Ms, groups absent from the comparison window are flagged isNew (no delta, so growth is not implied), and groups that had work before but none now are returned in groups.disappeared so a stopped area is never silently missing from the table. Area breakdown needs model locations to carry a parent area; when they do not, groups.note says so instead of implying there was no work. When the journal read hits its row cap, eventsCapped is true and every number is a lower bound — narrow the window and ask again rather than reading the smaller figures as a drop in performance. When operational targets are set for the space or instance, `targets` carries the verdicts [{metric, actual, target, direction, met, ratio}] — ratio is normalised so that 1 or more is always good, letting throughput and duration metrics be compared on one scale. A metric with no target, or with no measurement in the window, is absent from `targets` rather than reported as a miss, because a period with no work would otherwise read as a perfect score on duration metrics. Completions are counted in the window they complete; starts are looked up before the window, and any completion whose start was not found is reported in `unpaired` rather than silently dropped. Pass baselinePeriods (1-14, with baselineStride day | week) to fold the same time-of-day window on each of the last N days (or the same weekday on each of the last N weeks) and get `baseline.metrics` — per metric the distribution of those windows (min / median / max) plus where the current window sits: `rank` (1 = smallest, direction-free) and `standing` (best | better-than-typical | typical | worse-than-typical | worst, which does apply the metric direction). This answers what a single comparison cannot: comparing to yesterday alone is useless if yesterday was also bad. Every requested window is returned in `samples` with `measured` true or false — windows without records are kept and counted (measuredCount vs requested) rather than dropped, so "the last 7 days" never silently means 3. No position is reported when the current window has no value or fewer than two baseline windows were measured; `noPosition` says which, because a missing distribution drawn as neutral would read as "typical". The baseline is produced even when the current window itself has no records, since that is exactly when knowing the usual level matters (a stopped line).'
   })
   async twinKpi(
     @Ctx() context: ResolverContext,
@@ -227,7 +250,7 @@ export class TwinJournalQuery {
     @Arg('unitsPerDay', type => Float) unitsPerDay: number,
     /**
      * 가용 시간을 잴 기준 주의 시작(ISO, 월요일). 공휴일이 없는 평상주여야 한다 —
-     * 공휴일은 연간 가용량을 따로 깎지, 이 공장의 평상시 천장을 정하지 않는다.
+     * 공휴일은 연간 가용량을 따로 깎지, 이 공장의 평상시 상한을 정하지 않는다.
      */
     @Arg('sampleWeekStart', { nullable: true }) sampleWeekStart: string,
     @Ctx() context: ResolverContext
@@ -239,8 +262,8 @@ export class TwinJournalQuery {
     if (!(unitsPerDay > 0)) throw new Error('unitsPerDay must be greater than zero')
 
     /*
-     * 기준 주를 안 주면 **이번 주 월요일**을 쓴다. 그 주에 공휴일이 끼면 천장이 조금 낮게 나오는데,
-     * 그것은 조용한 오류가 아니라 **이번 주의 실제 가용 시간**이라 답으로서 정직하다. 평상시 천장을
+     * 기준 주를 안 주면 **이번 주 월요일**을 쓴다. 그 주에 공휴일이 끼면 상한이 조금 낮게 나오는데,
+     * 그것은 조용한 오류가 아니라 **이번 주의 실제 가용 시간**이라 답으로서 정직하다. 평상시 상한을
      * 보려는 호출자는 평상주를 지정한다.
      */
     const base = sampleWeekStart ? Date.parse(sampleWeekStart) : Date.now()
@@ -251,9 +274,50 @@ export class TwinJournalQuery {
     return TwinEngine.capacity(context.state.domain.id, { instanceId, spaceId }, unitsPerDay, monday)
   }
 
+  @Query(returns => ScalarObject, {
+    nullable: true,
+    description:
+      'Operations capability of a twin for a time window (ISA-95 Part 4 OperationsCapability): per operation the ceiling for that window split into Committed (already promised), Unattainable (lost to resources that cannot be used — down, held, off-shift, expired qualification) and Available (what is left). Answers "can we take more work?" — which the steady-state rate alone cannot. Null when the twin is not running.'
+  })
+  async twinOperationsCapability(
+    @Arg('instanceId', { nullable: true }) instanceId: string,
+    @Arg('spaceId', { nullable: true }) spaceId: string,
+    @Arg('unitsPerDay', type => Float) unitsPerDay: number,
+    /** 능력을 물을 구간 — **구간 없이 능력은 존재하지 않는다**(표준 StartTime/EndTime). */
+    @Arg('fromTime') fromTime: string,
+    @Arg('toTime') toTime: string,
+    @Arg('sampleWeekStart', { nullable: true }) sampleWeekStart: string,
+    @Ctx() context: ResolverContext
+  ): Promise<any> {
+    if (instanceId && !(await TwinEngine.ownsRegistered(context.state.domain.id, instanceId))) {
+      throw new Error(`twin instance not found in this tenant: ${instanceId}`)
+    }
+    if (!instanceId && !spaceId) throw new Error('either spaceId or instanceId is required')
+    if (!(unitsPerDay > 0)) throw new Error('unitsPerDay must be greater than zero')
+    /* 구간은 **부르는 쪽이 말해야 한다** — 기본값을 두면 화면마다 다른 구간을 보면서 같은 값으로 읽는다. */
+    const from = Date.parse(fromTime)
+    const to = Date.parse(toTime)
+    if (Number.isNaN(from) || Number.isNaN(to)) throw new Error(`window is not a valid ISO time: ${fromTime} ~ ${toTime}`)
+    if (to <= from) throw new Error(`window is inverted: ${fromTime} ~ ${toTime}`)
+
+    /* 기준 주 규율은 `twinCapacity` 와 같다(같은 계산을 쓰므로 같은 주를 골라야 한다). */
+    const base = sampleWeekStart ? Date.parse(sampleWeekStart) : from
+    if (Number.isNaN(base)) throw new Error(`sampleWeekStart is not a valid ISO time: ${sampleWeekStart}`)
+    const d = new Date(base)
+    const monday = Date.UTC(d.getUTCFullYear(), d.getUTCMonth(), d.getUTCDate() - ((d.getUTCDay() + 6) % 7))
+
+    return TwinEngine.operationsCapability(
+      context.state.domain.id,
+      { instanceId, spaceId },
+      unitsPerDay,
+      monday,
+      { fromTime, toTime }
+    )
+  }
+
   @Query(returns => ScalarObject, {
     description:
-      "Structural revisions a twin has been through, newest last: when each took effect, how many journal events happened under it, and what changed from the previous one (counts by location type and equipment kind). The board itself is not returned — a revision holds the whole plant, but what a person wants is the difference."
+      "Structural revisions a twin has been through, newest last: when each took effect, how many journal events happened under it, and what changed from the previous one (counts by location type and equipment kind). The model itself is not returned — a revision holds the whole plant, but what a person wants is the difference."
   })
   async twinStructures(@Arg('instanceId') instanceId: string, @Ctx() context: ResolverContext): Promise<any> {
     /* 이력 질문이므로 **등록부**에 소유를 묻는다 — 꺼진 트윈의 이력도 읽을 수 있어야 한다. */

package/server/service/twin-lifecycle/twin-lifecycle-mutation.ts

@@ -4,7 +4,7 @@ import { ScalarObject } from '@things-factory/shell'
 
 import { TwinEngine } from '../../engine/index.js'
 
-import type { BoardDef } from '@operato/twin-kernel'
+import type { TwinModelDef } from '@operato/twin-kernel'
 
 /* 도메인 어휘 카탈로그(시스템별 노드 타입) — 커널이 SSOT. 앱/UI 는 이걸 소싱하고 재선언하지 않는다(방언 금지).
  * 조합은 domain-catalog.ts 가 소유 — 리졸버와 서버측 소비자(board-ai 도구 등)가 같은 형태를 본다. */
@@ -14,39 +14,40 @@ import { domainCatalog } from './domain-catalog.js'
  * 트윈 인스턴스 생명주기 채널 — 프로비저닝(상향, ADR-0015).
  * State/Command/Scenario 는 이미 running 인 인스턴스를 다루지만, 이 채널은 인스턴스 자체를 만들고/설정하고/없앤다.
  * 생명주기: provision(save, 미기동) → start → stop → delete. 모두 domain 스코프(context.state.domain.id).
- * board(BoardDef+layout)=구조, scenario=자극 은 분리 — 여기선 구조만 세운다. 자극은 controlTwinScenario 로.
+ * model(TwinModelDef+layout)=구조, scenario=자극 은 분리 — 여기선 구조만 세운다. 자극은 controlTwinScenario 로.
  */
 @Resolver()
 export class TwinLifecycleMutation {
-  /** 프로비저닝(저장, 미기동) — 구조를 레지스트리에 등록만. 재프로비전 시 구조 변경이면 저널 purge(엔진). */
-  @Directive('@privilege(category: "twin", privilege: "mutation", domainOwnerGranted: true, superUserGranted: true)')
-  @Mutation(returns => Boolean, {
-    description: 'Provision (save) a twin instance structure (kind: wms|yms|mes) from a BoardDef without starting it.'
-  })
-  async saveTwinInstance(
-    @Arg('instanceId') instanceId: string,
-    @Arg('kind') kind: string,
-    @Arg('board', type => ScalarObject) board: any,
-    @Ctx() context: ResolverContext
-  ): Promise<boolean> {
-    await TwinEngine.provision(context.state.domain.id, instanceId, kind, board as BoardDef)
-    return true
-  }
+  /*
+   * `saveTwinInstance` 는 **없앴다**(2026-08-08, ADR-0028).
+   *
+   * 트윈의 구조를 임의의 model 로 덮어쓰는 문이었고, 유일한 소비자는 손저작 편집기였다.
+   * 구조는 원본에서 온다 — 템플릿(`createFromTemplate`)이나 커넥터(`ingestMaster`)가 그 길이다.
+   * 문을 열어 두면 화면만 지워도 다음 소비자가 다시 생긴다.
+   *
+   * 시뮬 트윈을 세우는 것은 여전히 가능하다. 다만 그 입구는 **원본을 만드는 쪽**이지
+   * 트윈을 고치는 쪽이 아니다(ADR-0029 — 시뮬레이터는 원본의 한 종류).
+   */
 
-  /** 기동 — board 를 주면 provision+start, 없으면 레지스트리에 저장된 구조로 start. */
+  /** 기동 — model 를 주면 provision+start, 없으면 레지스트리에 저장된 구조로 start. */
   @Directive('@privilege(category: "twin", privilege: "mutation", domainOwnerGranted: true, superUserGranted: true)')
   @Mutation(returns => Boolean, {
-    description: 'Start a twin runtime instance and begin the worker tick. If board is given it provisions first; otherwise it starts from the saved registry board.'
+    description: 'Start a twin runtime instance and begin the worker tick. If model is given it provisions first; otherwise it starts from the saved registry model.'
   })
   async startTwinInstance(
     @Arg('instanceId') instanceId: string,
     @Ctx() context: ResolverContext,
     @Arg('kind', { nullable: true }) kind?: string,
-    @Arg('board', type => ScalarObject, { nullable: true }) board?: any
+    @Arg('model', type => ScalarObject, { nullable: true }) model?: any
   ): Promise<boolean> {
     const domainId = context.state.domain.id
     // 시각 기준은 **공간**이 갖는다(테넌트 아님) — 교대의 HH:MM 을 어느 기준으로 읽나.
-    if (board) TwinEngine.start(instanceId, domainId, kind ?? 'wms', await TwinEngine.withSpaceTimeBase(board as BoardDef, domainId))
+    if (model) {
+      /* model 를 함께 주는 것은 프로비저닝이다 — 그러면 종류도 말해야 한다.
+         예전에는 `kind ?? 'wms'` 로 메웠는데, 종류를 빠뜨린 야드/생산 트윈이 **창고로 조용히 기동**했다. */
+      if (!kind) throw new Error('kind is required when model is given — it decides which domain kernel runs this twin')
+      TwinEngine.start(instanceId, domainId, kind, await TwinEngine.withSpaceTimeBase(model as TwinModelDef, domainId))
+    }
     else await TwinEngine.startFromRegistry(domainId, instanceId)
     return true
   }
@@ -85,8 +86,8 @@ export class TwinLifecycleMutation {
     return TwinEngine.list(context.state.domain.id)
   }
 
-  /** 단건 상세 — 프로비저닝 에디터용 board(구조+layout) 포함. */
-  @Query(returns => ScalarObject, { nullable: true, description: 'Get one provisioned twin instance with its BoardDef (structure + layout) for editing.' })
+  /** 단건 상세 — 프로비저닝 에디터용 model(구조+layout) 포함. */
+  @Query(returns => ScalarObject, { nullable: true, description: 'Get one provisioned twin instance with its TwinModelDef (structure + layout) for editing.' })
   async twinInstanceDetail(@Arg('instanceId') instanceId: string, @Ctx() context: ResolverContext): Promise<any | null> {
     return TwinEngine.detail(context.state.domain.id, instanceId)
   }

package/server/service/twin-metrics/twin-metrics-query.ts

@@ -1,14 +1,20 @@
-import { Arg, Ctx, Query, Resolver } from 'type-graphql'
+import { Arg, Ctx, Directive, Query, Resolver } from 'type-graphql'
 
-import { ScalarObject } from '@things-factory/shell'
+import { In } from 'typeorm'
+
+import { Domain, getRepository, ScalarObject } from '@things-factory/shell'
 
 import { TwinEngine } from '../../engine/index.js'
+import { newCpuSampler, sampleCpu } from '../../engine/load-meter.js'
 
 /*
  * 트윈 처리량 계측(모니터, ④-1) — 라이브 동기 인터페이스 부하를 읽는 일급 지표.
  * 유입률(ingestRate)·방송률(broadcastRate)·저널률(journalRate)·백로그(backlog)·누적. 폴링으로 라이브 관측.
  * (부하가 화면에 안 보인다던 문제의 정공법 — "얼마나 들어오고 얼마나 방송/기록되나"를 수치로.)
  */
+/* CPU 는 누적값이라 **표본 사이의 차이**로만 점유율이 나온다. 그래서 호출 사이에 상태가 남아야 한다. */
+const CPU_SAMPLER = newCpuSampler()
+
 @Resolver()
 export class TwinMetricsQuery {
   @Query(returns => ScalarObject, { nullable: true, description: 'Live throughput metrics of one twin instance (ingest/broadcast/journal rate, backlog). Null if not a live instance or not in the current domain.' })
@@ -21,4 +27,55 @@ export class TwinMetricsQuery {
   async twinMetricsAll(@Ctx() context: ResolverContext): Promise<any[]> {
     return TwinEngine.allMetrics(context.state.domain.id) // 도메인 스코프
   }
+
+  /*
+   * ── 이벤트 루프 부하 — **운영 계기판이다. 테넌트 기능이 아니다.** ─────────────
+   *
+   * `twinMetrics` 는 "얼마나 들어오고 나가나"(초당 이벤트)를 답한다. 여기서 묻는 것은 "그 일을 하느라
+   * 이벤트 루프를 얼마나 붙잡고 있나" 다. 시뮬 틱은 트윈마다 setInterval 로 **메인 루프에서 동기로**
+   * 돌기 때문에, 한 트윈이 느려지면 HTTP·구독이 함께 느려진다. 실제로 그 상태를 겪었는데 볼 계기판이
+   * 없어서 "포트는 열렸는데 응답이 없다" 로만 보였다.
+   *
+   * ── 왜 도메인으로 자르지 않나 ───────────────────────────────────────────────
+   * 처음에는 호출자의 도메인만 냈다. 테넌트 격리로는 맞아 보이지만 **이벤트 루프는 프로세스 하나가
+   * 공유한다.** 실측으로 드러났다: 한 도메인 트윈 22개가 CPU 를 110% 쓰는 동안, 다른 도메인 화면은
+   * `실행 중 0 · 루프 점유 —` 였다. "내 도메인은 한가한데 왜 느리지" 를 설명할 수 없었다.
+   *
+   * 그렇다고 테넌트에게 남의 부하를 조금 보여 주는 것도 답이 아니다 — 쓸 수 없는 정보이고 봐서도 안 된다.
+   * 층이 잘못이었다: 이것은 **프로세스를 운영하는 사람의 계기판**이다. 그래서 도메인으로 자르지 않고
+   * (전 테넌트 합산) **슈퍼유저에게만** 연다.
+   */
+  @Directive('@privilege(superUserGranted: true)')
+  @Query(returns => ScalarObject, {
+    description:
+      'Event-loop load of every twin in this process, for system operators (superuser only). Deliberately NOT scoped to the caller\'s domain: the event loop is shared by the whole process, so a tenant-scoped view reports an idle domain while the machine is saturated by someone else. Reports how many instances are running (by mode), how many forecast forks have been created, and per instance how long each kind of work takes (kernel tick, state snapshot, broadcast payload, publish, journal write, live ingest, Monte-Carlo forecast, fork trajectory). Each instance reports both `recent` (the last closed sampling window — what it is doing now) and `total` (cumulative since boot), with `busyRatio` telling how much of the window that twin held the loop. `fleetBusyRatio` above 1 means the twins together cannot finish inside one tick interval, which is when HTTP and subscriptions start to stall. Work that has never been measured is reported as null rather than zero, because zero would read as "instant".'
+  })
+  async twinLoad(@Ctx() context: ResolverContext): Promise<any> {
+    const fleet = TwinEngine.fleet() // 프로세스 전체 — 도메인으로 자르지 않는다(위 주석)
+
+    /* 도메인 id 는 UUID 라 사람이 못 읽는다. 읽을 수 있는 이름을 채운다 — **모르면 id 를 그대로 둔다**
+       (지어내지 않는다). 라이브 인스턴스에는 이미 붙어 있고, 시뮬은 여기서 한 번 조회한다. */
+    const ids = [...new Set((fleet.byDomain ?? []).map((d: any) => d.domainId).filter((v: any) => v && v !== '(unknown)'))]
+    if (ids.length) {
+      const found = await getRepository(Domain).find({ where: { id: In(ids as string[]) } })
+      const nameOf = new Map(found.map(d => [d.id, d.subdomain || d.name]))
+      for (const d of fleet.byDomain) if (nameOf.get(d.domainId)) d.label = nameOf.get(d.domainId) as string
+      for (const r of fleet.slowest ?? []) if (r.domainId && nameOf.get(r.domainId)) r.domainLabel = nameOf.get(r.domainId)
+      for (const r of fleet.details ?? []) if (r.domainId && nameOf.get(r.domainId)) r.domainLabel = nameOf.get(r.domainId)
+    }
+
+    /*
+     * 프로세스가 실제로 쓴 CPU — **계기판의 다른 숫자와 뜻이 다르다.**
+     *
+     * 위의 값들은 트윈의 계측된 작업만 잰 것이라, 그 밖의 일(GraphQL·TypeORM·GC·webpack·HTTP)은
+     * 분모에도 분자에도 없다. "루프 점유 <1%" 인데 CPU 는 110% 였던 상태를 실제로 겪었다. 두 숫자를
+     * 나란히 두어야 **트윈이 범인인지** 가릴 수 있다.
+     *
+     * 표본 간 차이라 첫 호출은 `null` 이다 — 0 이 아니다.
+     */
+    const usage = process.cpuUsage()
+    const cpu = sampleCpu(CPU_SAMPLER, usage.user + usage.system, Date.now())
+
+    return { ...fleet, processCpuRatio: cpu?.ratio ?? null, processCpuSpanMs: cpu?.spanMs ?? null }
+  }
 }

package/server/service/twin-model/epcis-coverage.ts

@@ -0,0 +1,195 @@
+/*
+ * GS1 EPCIS 2.0 적합성 기준 — **물류·제조 트윈이 표준의 어디를 채우고 있나.**
+ *
+ * ── 왜 따로 있나 ────────────────────────────────────────────────────────────
+ * 적합성 패널이 ISA-95 하나만 말하고 있었다. 그런데 창고·야드·공장 트윈에서 「무슨 일이 있었나」와
+ * 「이 번호가 무엇을 가리키나」를 정하는 것은 EPCIS 다. ISA-95 표만 보이면 그 트윈이 기대는 기준의
+ * 절반이 화면에 없다.
+ *
+ * ── 수준은 근거를 보고 적었다 ───────────────────────────────────────────────
+ * 「있다/없다」를 기억으로 적지 않는다. 각 줄의 판단 근거:
+ *  · 타입 선언 — 커널 `epcis.ts`(이벤트·필드의 모양)
+ *  · 실제 사용 — 커널 도메인(`mes-kernel`·`face2-adapter`·`observed-reducer`)과 호스트 인제스트
+ *  · 화면 노출 — 저널·계보·엔티티 360
+ * 모양만 있고 아무도 채우지 않는 필드는 **구조만 있음**으로 적는다(그게 사실이다).
+ *
+ * ISA-95 표와 같은 규율이다(`isa95-coverage.ts` 머리말): 사람이 판단해 적고, 틀리면 여기를 고친다.
+ */
+import type { Isa95Concept, CoverageLevel } from './isa95-coverage.js'
+
+/* Part: EPCIS 2.0 의 사건 종류 — 무엇이 일어났는가. */
+const EVENTS: Isa95Concept[] = [
+  {
+    std: 'ObjectEvent',
+    part: 'events',
+    label: 'twin.epcis.ObjectEvent',
+    axis: 'items',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.epcis.note.ObjectEvent'
+  },
+  {
+    std: 'AggregationEvent',
+    part: 'events',
+    label: 'twin.epcis.AggregationEvent',
+    axis: null,
+    shownOn: ['items'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'partial',
+    note: 'twin.epcis.note.AggregationEvent'
+  },
+  {
+    std: 'TransactionEvent',
+    part: 'events',
+    label: 'twin.epcis.TransactionEvent',
+    axis: 'orders',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'partial',
+    note: 'twin.epcis.note.TransactionEvent'
+  },
+  {
+    std: 'TransformationEvent',
+    part: 'events',
+    label: 'twin.epcis.TransformationEvent',
+    axis: null,
+    shownOn: ['items', 'operations'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.epcis.note.TransformationEvent'
+  },
+  /* EPCIS 2.0 이 더한 사건 — 우리는 타입조차 두지 않았다. 없는 것은 없다고 적는다. */
+  {
+    std: 'AssociationEvent',
+    part: 'events',
+    label: 'twin.epcis.AssociationEvent',
+    axis: null,
+    structure: 'none',
+    behavior: 'none',
+    surface: 'none',
+    note: 'twin.epcis.note.AssociationEvent'
+  }
+]
+
+/* Part: 사건이 답하는 다섯 가지 — 무엇을·어디서·언제·왜, 그리고 어떤 거래로. */
+const FIELDS: Isa95Concept[] = [
+  {
+    std: 'epcList / quantityList',
+    part: 'fields',
+    label: 'twin.epcis.identity',
+    axis: 'items',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.epcis.note.identity'
+  },
+  {
+    std: 'bizStep / disposition (CBV)',
+    part: 'fields',
+    label: 'twin.epcis.cbv',
+    axis: null,
+    shownOn: ['items', 'tasks'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.epcis.note.cbv'
+  },
+  {
+    std: 'readPoint / bizLocation',
+    part: 'fields',
+    label: 'twin.epcis.where',
+    axis: 'locations',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.epcis.note.where'
+  },
+  {
+    std: 'bizTransactionList',
+    part: 'fields',
+    label: 'twin.epcis.bizTransaction',
+    axis: 'orders',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'partial',
+    note: 'twin.epcis.note.bizTransaction'
+  },
+  {
+    std: 'ilmd',
+    part: 'fields',
+    label: 'twin.epcis.ilmd',
+    axis: null,
+    shownOn: ['items'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'partial',
+    note: 'twin.epcis.note.ilmd'
+  },
+  {
+    std: 'errorDeclaration',
+    part: 'fields',
+    label: 'twin.epcis.errorDeclaration',
+    axis: null,
+    shownOn: ['items'],
+    structure: 'full',
+    behavior: 'partial',
+    surface: 'none',
+    note: 'twin.epcis.note.errorDeclaration'
+  },
+  /* 모양만 있고 아무도 채우지 않는 것들 — 구조만 있음. */
+  {
+    std: 'sourceList / destinationList',
+    part: 'fields',
+    label: 'twin.epcis.sourceDestination',
+    axis: null,
+    structure: 'partial',
+    behavior: 'none',
+    surface: 'none',
+    note: 'twin.epcis.note.sourceDestination'
+  },
+  {
+    std: 'persistentDisposition',
+    part: 'fields',
+    label: 'twin.epcis.persistentDisposition',
+    axis: null,
+    structure: 'partial',
+    behavior: 'none',
+    surface: 'none',
+    note: 'twin.epcis.note.persistentDisposition'
+  },
+  {
+    std: 'sensorElementList',
+    part: 'fields',
+    label: 'twin.epcis.sensorElement',
+    axis: null,
+    structure: 'partial',
+    behavior: 'none',
+    surface: 'none',
+    note: 'twin.epcis.note.sensorElement'
+  }
+]
+
+export const EPCIS_CONCEPTS: Isa95Concept[] = [...EVENTS, ...FIELDS]
+
+export function epcisCoverage(axes: string[]): {
+  model: string
+  concepts: (Isa95Concept & { axisMissing?: boolean })[]
+  totals: { concepts: number; structure: number; behavior: number; surface: number }
+} {
+  const known = new Set(axes)
+  const concepts = EPCIS_CONCEPTS.map(c => {
+    const axisMissing = !!c.axis && !known.has(c.axis)
+    const shownOn = c.shownOn?.filter(a => known.has(a))
+    const fixed = shownOn && shownOn.length !== c.shownOn?.length ? { ...c, shownOn } : c
+    return axisMissing ? { ...fixed, structure: 'none' as CoverageLevel, axisMissing } : fixed
+  })
+  const count = (k: 'structure' | 'behavior' | 'surface') => concepts.filter(c => c[k] === 'full').length
+  return {
+    model: 'GS1 EPCIS 2.0',
+    concepts,
+    totals: { concepts: concepts.length, structure: count('structure'), behavior: count('behavior'), surface: count('surface') }
+  }
+}

package/server/service/twin-model/iec61850-coverage.ts

@@ -0,0 +1,117 @@
+/*
+ * IEC 61850 적합성 기준 — **에너지 트윈이 표준의 어디를 채우고 있나.**
+ *
+ * ── 왜 따로 있나 ────────────────────────────────────────────────────────────
+ * 인스펙션의 적합성 패널은 트윈 종류와 무관하게 ISA-95 하나만 말하고 있었다. 에너지 트윈에서 그것은
+ * 거짓은 아니지만(설비·계층·속성은 에너지에서도 ISA-95 자원이다) **부족하다** — 계량기·차단기·태양광·
+ * 축전지의 어휘를 주는 것은 IEC 61850 이고, 무엇이 비었는지도 그 목록으로만 셀 수 있다.
+ *
+ * ── 주장 수준을 못 박는다 ───────────────────────────────────────────────────
+ * 여기서 재는 것은 **어휘와 모델**이다. 프로토콜(MMS·GOOSE·샘플드값)을 구현했다는 뜻이 아니며,
+ * 그 주장은 적합성 시험이 뒷받침해야 한다. 표 이름을 「IEC 61850 (vocabulary)」로 쓰는 이유다.
+ *
+ * ── 값은 관측이 아니라 선언이다 ─────────────────────────────────────────────
+ * ISA-95 표와 같은 규율이다(`isa95-coverage.ts` 머리말): 사람이 판단해 적고, 틀리면 여기를 고친다.
+ * 자동으로 알 수 있는 것 하나만 자동으로 한다 — 축 이름이 커널 축 목록에 없으면 구조가 없는 것이다.
+ */
+import type { Isa95Concept, CoverageLevel } from './isa95-coverage.js'
+
+/*
+ * Part 7-4 — 논리 노드 클래스. 이 프로파일이 쓰는 것만 적는다(표준 전체를 옮기지 않는다):
+ * 계량·계측·개폐·발전·저장.
+ */
+const LOGICAL_NODES: Isa95Concept[] = [ // vocabulary-guard: allow — IEC 61850 의 「논리 노드(logical node)」는 표준 용어다(우리가 은퇴시킨 node 어휘가 아니다)
+  /*
+   * 계량(적산) — 커넥터가 누적 전력량을 실어 오고 상태가 지점별로 들고 있다. 화면은 계량 컴포넌트가
+   * 지점의 값을 보인다.
+   */
+  {
+    std: 'MMTR',
+    part: '7-4',
+    label: 'twin.iec61850.MMTR',
+    axis: 'equipment',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.iec61850.note.MMTR'
+  },
+  /*
+   * 계측(유효전력·역률) — 표본이 수요 구간으로 접히고, 구간·피크·계약 대비가 그 위에 선다.
+   * 이 프로파일에서 가장 두껍게 채운 자리다.
+   */
+  {
+    std: 'MMXU',
+    part: '7-4',
+    label: 'twin.iec61850.MMXU',
+    axis: 'demandWindows',
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.iec61850.note.MMXU'
+  },
+  /*
+   * ── 셋이 함께 올라갔다 (2026-08-15) ──────────────────────────────────────
+   * 개폐·발전·저장은 오래 「구조만 있음」이었다. 능력이 상태 필드를 선언해 두었는데 **값을 받는 문이
+   * 없었기 때문**이다. 이제 셋 다 실제로 돈다: 설비 상태가 계약에 서고(`EquipmentState`), 커널이
+   * `energy.equipment` 로 받아 그 설비에 적고, 씬 컴포넌트가 그린다.
+   *
+   * 세 층을 함께 올리는 이유: 값이 없는데 화면만 만들면 영원히 「—」인 카드가 되고, 화면이 없는데
+   * 기능만 올리면 아무도 그 값을 보지 못한다. 「값이 먼저, 컴포넌트는 그 다음」의 결과다.
+   */
+  {
+    std: 'XCBR',
+    part: '7-4',
+    label: 'twin.iec61850.XCBR',
+    axis: null,
+    shownOn: ['equipment'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.iec61850.note.XCBR'
+  },
+  {
+    std: 'DPVA',
+    part: '7-4',
+    label: 'twin.iec61850.DPVA',
+    axis: null,
+    shownOn: ['equipment'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.iec61850.note.DPVA'
+  },
+  {
+    std: 'ZBAT',
+    part: '7-4',
+    label: 'twin.iec61850.ZBAT',
+    axis: null,
+    shownOn: ['equipment'],
+    structure: 'full',
+    behavior: 'full',
+    surface: 'full',
+    note: 'twin.iec61850.note.ZBAT'
+  }
+]
+
+export const IEC61850_CONCEPTS: Isa95Concept[] = [...LOGICAL_NODES] // vocabulary-guard: allow — 표준 용어(위 주석)
+
+export function iec61850Coverage(axes: string[]): {
+  model: string
+  concepts: (Isa95Concept & { axisMissing?: boolean })[]
+  totals: { concepts: number; structure: number; behavior: number; surface: number }
+} {
+  const known = new Set(axes)
+  const concepts = IEC61850_CONCEPTS.map(c => {
+    const axisMissing = !!c.axis && !known.has(c.axis)
+    const shownOn = c.shownOn?.filter(a => known.has(a))
+    const fixed = shownOn && shownOn.length !== c.shownOn?.length ? { ...c, shownOn } : c
+    return axisMissing ? { ...fixed, structure: 'none' as CoverageLevel, axisMissing } : fixed
+  })
+  const count = (k: 'structure' | 'behavior' | 'surface') => concepts.filter(c => c[k] === 'full').length
+  return {
+    /* 이름에 (vocabulary) 를 달아 둔다 — 프로토콜 적합성으로 읽히지 않게. */
+    model: 'IEC 61850 (vocabulary)',
+    concepts,
+    totals: { concepts: concepts.length, structure: count('structure'), behavior: count('behavior'), surface: count('surface') }
+  }
+}