@things-factory/headless-twin 10.1.278 → 10.1.279

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

@@ -1,251 +0,0 @@
-/*
- * GS1 EPCIS 2.0 적합성 기준 — **물류·제조 트윈이 표준의 어디를 채우고 있나.**
- *
- * ── 왜 따로 있나 ────────────────────────────────────────────────────────────
- * 적합성 패널이 ISA-95 하나만 말하고 있었다. 그런데 창고·야드·공장 트윈에서 「무슨 일이 있었나」와
- * 「이 번호가 무엇을 가리키나」를 정하는 것은 EPCIS 다. ISA-95 표만 보이면 그 트윈이 기대는 기준의
- * 절반이 화면에 없다.
- *
- * ── 수준은 근거를 보고 적었다 ───────────────────────────────────────────────
- * 「있다/없다」를 기억으로 적지 않는다. 각 줄의 판단 근거:
- *  · 타입 선언 — 커널 `epcis.ts`(이벤트·필드의 모양)
- *  · 실제 사용 — 커널 도메인(`mes-kernel`·`face2-adapter`·`observed-reducer`)과 호스트 인제스트
- *  · 화면 노출 — 저널·계보·엔티티 360
- * 모양만 있고 아무도 채우지 않는 필드는 **구조만 있음**으로 적는다(그게 사실이다).
- *
- * ISA-95 표와 같은 규율이다(`isa95-coverage.ts` 머리말): 사람이 판단해 적고, 틀리면 여기를 고친다.
- */
-import { reconcileAxes, type Isa95Concept, type 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[] = [
-  {
-    /*
-     * **무엇을 한 것인가** — 표준 `action`: `ADD`(생겼다) · `OBSERVE`(보았다) · `DELETE`(없어졌다).
-     *
-     * 이 줄이 표에 없었다. 표준 필드이고 우리가 계약·유입·검증에서 다 쓰는데도 세지 않았습니다.
-     *
-     * ── 2026-08-25 그 뜻이 커졌다 ─────────────────────────────────────────────
-     * `DELETE` 를 낱개 번호가 있는 물품에만 적용하고 있었다. 그래서 **낱개 번호가 없는 현장에서는
-     * 재고를 지울 방법이 하나도 없었다** — 승화푸드는 모든 재고가 수량으로 오는 현장이고, 한 번 본
-     * 재고가 영원히 남았다(실제 1,704건인데 트윈이 10,038건).
-     *
-     * 이제 수량으로 온 재고도 없어질 수 있다. 자리를 함께 말하면 그 자리의 것만, 말하지 않으면
-     * 그 로트를 모든 자리에서 지운다 — 짐작이 아니라 진술의 범위를 읽는다.
-     *
-     * 화면은 아직 없다. 「이것이 없어졌다」를 사람에게 보이는 자리를 만들지 않았다.
-     */
-    std: 'action',
-    part: 'fields',
-    label: 'twin.epcis.action',
-    axis: null,
-    shownOn: ['items'],
-    structure: 'full',
-    behavior: 'full',
-    surface: 'none'
-  },
-  {
-    std: 'epcList / quantityList',
-    part: 'fields',
-    label: 'twin.epcis.identity',
-    axis: 'items',
-    structure: 'full',
-    behavior: 'full',
-    surface: 'full',
-    note: 'twin.epcis.note.identity'
-  },
-  /*
-   * ── 2026-08-24 주장 근거가 달라졌다 ────────────────────────────────────────
-   * 이 줄은 오래 `full` 이었지만 근거가 **우리 선언**이었다. 이제 **정본 원문 대조**다:
-   * CBV Standard Release 2.0(Ratified Jun 2022) §7.2.3 의 처분 38개를 전수 확인했다.
-   *
-   * 그 대조가 실제로 셋을 바꿨다.
-   *   · `expired` — 있는 낱말인데 우리가 쓰지 않고 있었다(기한 경과를 처분으로 말할 수 있게 됐다)
-   *   · `conformant` / `non_conformant` — 검사 판정을 처분으로 남기는 낱말. 함께 `inspecting` bizStep
-   *   · `non_sellable_expired` 는 표준이 **폐기**하고 `expired` 로 대체한 것을 확인
-   *
-   * ★ 그리고 **검증 방법에 함정이 있다**: `ref.gs1.org/cbv/…` 로 URN 을 조회하면 **지어낸 값에도
-   * 똑같은 응답**이 온다. 그것으로 확인했다고 여기면 없는 낱말을 발행한다(한 번 그렇게 했다).
-   * 확인은 정본 문서로만 한다.
-   */
-  {
-    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'
-  },
-  {
-    /*
-     * `shownOn` 은 「어디에 속하나」다 — 정정 선언은 물품의 사실이다. 화면에 그려지는지는 `surface` 가
-     * 따로 답한다(지금은 `none` 이고 `note` 가 그 사실을 말한다). 둘은 다른 물음이다(§`shownOn`).
-     */
-    shownOn: ['items'],
-    std: 'errorDeclaration',
-    part: 'fields',
-    label: 'twin.epcis.errorDeclaration',
-    axis: null,
-    structure: 'full',
-    behavior: 'partial',
-    surface: 'none',
-    note: 'twin.epcis.note.errorDeclaration'
-  },
-  /* 모양만 있고 아무도 채우지 않는 것들 — 구조만 있음. */
-  {
-    /* 어디에 속하나 — 소유·보관의 이전은 그 물품의 사실이다. 화면에 그려지는지는 `surface` 가 따로 답한다(§`shownOn`). */
-    shownOn: ['items'],
-    std: 'sourceList / destinationList',
-    part: 'fields',
-    label: 'twin.epcis.sourceDestination',
-    axis: null,
-    structure: 'partial',
-    behavior: 'none',
-    surface: 'none',
-    note: 'twin.epcis.note.sourceDestination'
-  },
-  {
-    /* 어디에 속하나 — 지속 처분은 그 물품에 붙는다. 화면에 그려지는지는 `surface` 가 따로 답한다(§`shownOn`). */
-    shownOn: ['items'],
-    std: 'persistentDisposition',
-    part: 'fields',
-    label: 'twin.epcis.persistentDisposition',
-    axis: null,
-    structure: 'partial',
-    behavior: 'none',
-    surface: 'none',
-    note: 'twin.epcis.note.persistentDisposition'
-  },
-  /*
-   * ── 2026-08-24 계측이 어디로 들어오는지 확정됐다 ──────────────────────────
-   * 「계측은 EPCIS 센서 필드로 오지 않는다」는 사실이 이제 **자리를 갖는다**: 자리의 상시 관측은
-   * ISA-95 `OperationsEvent` 로 들어오고(커널 `location.measured` 채널), 에너지는 그 위의 누적기가
-   * 받는다. ISA-95 표의 `OperationsEvent` 줄이 그 판정을 든다.
-   *
-   * 왜 EPCIS 가 아닌가: `SensorElement` 는 **개체에 붙는** 관측이고, 냉장실의 온도는 그 안의 물건
-   * 수백 개와 관계되며 그 수백 개는 시간에 따라 바뀐다. 개체마다 붙이면 같은 사실이 수백 벌이 되고,
-   * 물건이 떠나면 그 방의 온도 이력이 함께 사라진다. 주인은 **자리**다.
-   *
-   * 그래서 이 줄은 `behavior: 'none'` 으로 남는다 — 결손이 아니라 **다른 층으로 들어온다는 사실**이다.
-   * 그 구별을 표가 말하지 않으면 「센서를 못 받는 트윈」으로 읽힌다.
-   */
-  {
-    /* 어디에 속하나 — 표준에서 센서 관측은 **개체에 붙는다** — 우리가 그것을 자리로 옮긴 것이 다른 이야기다. 화면에 그려지는지는 `surface` 가 따로 답한다(§`shownOn`). */
-    shownOn: ['items'],
-    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 concepts = EPCIS_CONCEPTS.map(c => reconcileAxes(c, new Set(axes)))
-  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/external-resolver.ts

@@ -1,173 +0,0 @@
-/*
- * **board 밖을 가리키는 관계를 푸는 자리** — 선언은 있고 코드가 0곳이던 이음새.
- *
- * ── 무엇이 있었나 (2026-09-05 실측) ────────────────────────────────────────
- * 계약이 `target: { kind: 'external', entity: … }` 를 선언하고 주석에 「해소는 호스트가 한다」고
- * 적어 두었다. 그런데 **`headless-twin/server` 어디에도 `kind === 'external'` 을 다루는 코드가
- * 없었다**(0곳).
- *
- * `space.area` 가 도는 것처럼 보인 이유는 이음새가 있어서가 아니라 **호스트에서 그것이 평범한 FK
- * 라서**다. TypeORM 메타데이터가 우연히 답해 준 것이지 선언이 길을 낸 것이 아니다.
- *
- * ── 왜 지금 채우나 ─────────────────────────────────────────────────────────
- * 아침에는 「아무도 안 막혔으니 급하지 않다」로 적었다. **그 판단이 규모를 작게 잡은 것이었다.**
- *
- * 360(한 대상에 걸린 것을 한자리에)의 소비처는 무한히 늘어난다. 그러면 각 제품의 자기 저장소가
- * 관계의 원천이 된다 — MES 의 실적·상태 구간·정비 계획이 그렇고, 다음 제품도 그럴 것이다.
- *
- * 그때 **선언은 「밖을 가리킨다」고 말하는데 푸는 길이 없으면 제품마다 자기 길을 낸다.** 그것이
- * 정확히 「무한히 갈린다」다. 이 파일이 그 갈림을 막는다.
- *
- * ── 커널은 어느 표인지 모른다 ──────────────────────────────────────────────
- * 계약은 「이 축이 밖을 가리킨다」까지만 안다. **「어느 표의 어느 칸」은 제품이 안다.** 그래서 제품이
- * 부팅에서 해소기를 꽂는다 — 장부 기록기(`installIngestWindowWriter`)와 같은 규율이다.
- *
- * 커널이 표 이름을 알게 되면 한 제품의 저장 구조에 매이고, 다음 제품이 다른 표를 쓰면 커널을 또
- * 고쳐야 한다.
- *
- * ── 없는 것을 숨기지 않는다 ────────────────────────────────────────────────
- * 해소기가 없으면 **그 사실을 낸다**(`unresolved`). 링크를 지우면 화면은 「그런 관계가 없다」로
- * 읽고, 실제로는 「아무도 답할 수 없다」다. 그 둘은 사람이 할 일이 다르다.
- */
-
-/** 밖에 사는 대상 하나 — 화면이 이름을 보이고 갈 곳을 정할 수 있게. */
-export interface ExternalRef {
-  id: string
-  /** 사람이 읽는 이름. 없으면 화면이 id 를 보인다(지어내지 않는다). */
-  name?: string
-  /**
-   * 그 제품에서 이것을 열 수 있는 자리 — 없으면 화면이 링크를 만들지 않는다.
-   *
-   * 막다른 링크를 만들지 않는 것이 이 칸의 요점이다. 눌러서 아무 일도 안 일어나면 사람은 그것을
-   * 결함으로 읽는다.
-   */
-  href?: string
-  /** 그 id 가 실제로 있나 — **없으면 없다고 말한다.** 답에서 빼지 않는다. */
-  missing?: boolean
-}
-
-/**
- * 밖에서 이 대상을 가리키는 것들 — 들어오는 관계 한 묶음.
- *
- * `tense` 를 **제품이 선언한다**(계약의 `RelationTense`). 실적·상태 구간은 지난 일이고 정비 계획·
- * 지시는 앞의 일이다 — 「걸린 것이 열」이 두 뜻이 되는 자리이므로 묶음이 스스로 말해야 한다.
- */
-export interface ExternalIncoming {
-  /** 관계의 이름(i18n 키) — 계약의 `via` 와 같은 규칙. 제품은 자기 접두를 쓴다. */
-  via: string
-  /** 어디서 오나 — 사람이 읽는 축 이름이 아니라 그 제품의 축 키다. */
-  from: string
-  /** 언제의 일인가. 안 주면 「선언이 말하지 않았다」다 — `standing` 으로 바꾸지 않는다. */
-  tense?: 'past' | 'future' | 'standing'
-  ids: string[]
-  /** 전체 수 — `ids` 가 잘렸어도 몇인지 말한다. */
-  total: number
-}
-
-/**
- * 한 external 대상을 푸는 제품 쪽 구현.
- *
- * 둘 다 선택이다. 이름만 대 줄 수 있는 제품과 들어오는 관계만 낼 수 있는 제품이 다 있다 — 하나만
- * 꽂아도 그만큼은 답해진다.
- */
-/** What the relation being resolved belongs to. Required — a resolver that answers without it answers for the wrong twin. */
-export interface ExternalResolveContext {
-  instanceId: string
-}
-
-export interface ExternalResolver {
-  /** 계약의 `target.entity` 와 **같은 낱말**. 다르면 아무 관계에도 안 붙는다. */
-  entity: string
-  /**
-   * 이 id 들이 무엇인가 — **어느 트윈의 관계인지와 함께** 묻는다.
-   *
-   * 인스턴스를 넘기는 이유(2026-09-18): 밖의 id 는 도메인에서 유일하지 않다. 구역 id(`areaId`)는
-   * 공간 안에서만 유일하므로, 도메인만으로 찾으면 다른 공간의 같은 id 가 답이 되어 **남의 공간 이름**이
-   * 이 자리의 부모로 보인다. 부르는 쪽은 인스턴스를 알고 있다.
-   */
-  resolve?(domainId: string, ids: readonly string[], context: ExternalResolveContext): Promise<ExternalRef[]>
-  /** 이 대상을 가리키는 것들. */
-  incoming?(domainId: string, instanceId: string, axis: string, itemId: string): Promise<ExternalIncoming[]>
-}
-
-const resolvers = new Map<string, ExternalResolver>()
-
-/**
- * 해소기를 꽂는다 — **부팅에서 한 번.**
- *
- * 같은 `entity` 를 두 번 꽂으면 뒤엣것이 이긴다. 그것이 개발 중 재적재의 정상 동작이고, 운영에서
- * 일어나면 두 제품이 같은 대상을 자기 것이라 말하는 것이므로 **경고를 남긴다** — 조용히 덮으면
- * 어느 쪽이 답하고 있는지 아무도 모른다.
- */
-export function registerExternalResolver(r: ExternalResolver, warn?: (msg: string) => void): void {
-  const entity = String(r?.entity ?? '').trim()
-  if (!entity) {
-    warn?.('[external-resolver] entity 없는 해소기는 꽂지 않는다 — 아무 관계에도 안 붙는다')
-    return
-  }
-  if (resolvers.has(entity)) {
-    warn?.(`[external-resolver] '${entity}' 해소기를 덮어쓴다 — 두 제품이 같은 대상을 답하려 하면 그중 하나만 답한다`)
-  }
-  resolvers.set(entity, { ...r, entity })
-}
-
-/** 지금 꽂혀 있는 것들 — 「무엇을 풀 수 있나」를 밖에서 잴 수 있게. */
-export function externalResolverEntities(): string[] {
-  return [...resolvers.keys()].sort()
-}
-
-/** 시험이 재기동을 넣을 수 있게. */
-export function clearExternalResolvers(): void {
-  resolvers.clear()
-}
-
-/**
- * 그 id 들을 푼다 — **못 풀면 못 푼다고 말한다.**
- *
- * 해소기가 터져도 360 전체를 죽이지 않는다. 한 관계가 답을 못 하는 것과 화면이 안 뜨는 것은 다른
- * 사고이고, 뒤엣것이 훨씬 나쁘다.
- */
-export async function resolveExternal(
-  entity: string,
-  domainId: string,
-  ids: readonly string[],
-  context: ExternalResolveContext,
-  warn?: (msg: string) => void
-): Promise<{ refs?: ExternalRef[]; unresolved?: 'no-resolver' | 'failed' }> {
-  const r = resolvers.get(entity)
-  if (!r?.resolve) return { unresolved: 'no-resolver' }
-  try {
-    return { refs: await r.resolve(domainId, ids, context) }
-  } catch (e: any) {
-    warn?.(`[external-resolver] '${entity}' 해소가 실패했다 — ${String(e?.message ?? e)}`)
-    return { unresolved: 'failed' }
-  }
-}
-
-/**
- * 밖에서 이 대상을 가리키는 것들을 모은다.
- *
- * 꽂힌 것이 없으면 **빈 배열이지 오류가 아니다** — 밖에서 가리키는 것이 없는 대상이 정상이다.
- * 다만 「해소기가 없어서 모른다」와 「없다」는 다르므로, 그 구별은 `externalResolverEntities()` 로
- * 밖에서 잰다.
- */
-export async function externalIncoming(
-  domainId: string,
-  instanceId: string,
-  axis: string,
-  itemId: string,
-  warn?: (msg: string) => void
-): Promise<ExternalIncoming[]> {
-  const out: ExternalIncoming[] = []
-  for (const r of resolvers.values()) {
-    if (!r.incoming) continue
-    try {
-      const got = await r.incoming(domainId, instanceId, axis, itemId)
-      /* 빈 묶음은 싣지 않는다 — 여기서는 「그 제품이 이 축을 안 본다」는 뜻이고 할 말이 없다. */
-      for (const g of got ?? []) if (g && g.total > 0) out.push(g)
-    } catch (e: any) {
-      warn?.(`[external-resolver] '${r.entity}' 의 들어오는 관계 조회가 실패했다 — ${String(e?.message ?? e)}`)
-    }
-  }
-  return out
-}

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

@@ -1,111 +0,0 @@
-/*
- * IEC 61850 적합성 기준 — **에너지 트윈이 표준의 어디를 채우고 있나.**
- *
- * ── 왜 따로 있나 ────────────────────────────────────────────────────────────
- * 인스펙션의 적합성 패널은 트윈 종류와 무관하게 ISA-95 하나만 말하고 있었다. 에너지 트윈에서 그것은
- * 거짓은 아니지만(설비·계층·속성은 에너지에서도 ISA-95 자원이다) **부족하다** — 계량기·차단기·태양광·
- * 축전지의 어휘를 주는 것은 IEC 61850 이고, 무엇이 비었는지도 그 목록으로만 셀 수 있다.
- *
- * ── 주장 수준을 못 박는다 ───────────────────────────────────────────────────
- * 여기서 재는 것은 **어휘와 모델**이다. 프로토콜(MMS·GOOSE·샘플드값)을 구현했다는 뜻이 아니며,
- * 그 주장은 적합성 시험이 뒷받침해야 한다. 표 이름을 「IEC 61850 (vocabulary)」로 쓰는 이유다.
- *
- * ── 값은 관측이 아니라 선언이다 ─────────────────────────────────────────────
- * ISA-95 표와 같은 규율이다(`isa95-coverage.ts` 머리말): 사람이 판단해 적고, 틀리면 여기를 고친다.
- * 자동으로 알 수 있는 것 하나만 자동으로 한다 — 축 이름이 커널 축 목록에 없으면 구조가 없는 것이다.
- */
-import { reconcileAxes, type Isa95Concept, type 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 concepts = IEC61850_CONCEPTS.map(c => reconcileAxes(c, new Set(axes)))
-  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') }
-  }
-}

package/server/service/twin-model/index.ts

@@ -1,25 +0,0 @@
-/*
- * 트윈 구조 모델 — `TwinInstance.model`(JSON 덩어리) 에서 풀어낸 **표준 엔티티**(ADR-0032).
- *
- * 여기 있는 것은 전부 **원본에서 온 캐시**다. 정본은 원본 시스템이고(ADR-0028), 이 행들은
- * 인제스트가 만들며 언제든 전부 지우고 다시 만들 수 있어야 한다.
- *
- * 오늘은 **실제로 채워지는 세 축**만 있다 — 자리·설비·공정. 사람·자산·등급·속성·생산 정의는
- * 지금 0건이라 만들지 않는다("설계와 착수는 다르다", ADR-0032-H). 모델은 그때 옳게 세운다.
- */
-export { TwinLocation } from './twin-location.js'
-export { TwinEquipment } from './twin-equipment.js'
-export { TwinOperation } from './twin-operation.js'
-
-import { TwinLocation } from './twin-location.js'
-import { TwinEquipment } from './twin-equipment.js'
-import { TwinOperation } from './twin-operation.js'
-
-import { TwinModelQuery } from './twin-model-query.js'
-import { TwinModelItemQuery } from './twin-model-item-query.js'
-import { TwinModelTreeQuery } from './twin-model-tree-query.js'
-import { TwinModelMutation } from './twin-model-mutation.js'
-import { TwinLineageQuery } from './twin-lineage-query.js'
-
-export const entities = [TwinLocation, TwinEquipment, TwinOperation]
-export const resolvers = [TwinModelQuery, TwinModelItemQuery, TwinModelTreeQuery, TwinModelMutation, TwinLineageQuery]