@things-factory/headless-twin 10.0.14 → 10.0.17

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

@@ -11,6 +11,10 @@ import { TwinEngine } from '../../engine/index.js'
 import { pickAxes } from '../../engine/state-axes.js'
 import { digestAttentions } from '../../engine/attention-digest.js'
 import { computeTwinKpi, resolveTwinTargets } from '../../engine/kpi-query.js'
+import { journalOrder } from './journal-order.js'
+import { readModelPage } from '../twin-subject/twin-subject-fast-path.js'
+import { eventTypeSplitPage } from './event-type-split.js'
+import { splitShape } from './event-type-split-shape.js'
 
 /*
  * 저널 읽기 채널 — 상향 query.
@@ -41,7 +45,9 @@ function toDateValue(v: any): any {
 @Resolver()
 export class TwinJournalQuery {
   @Query(returns => [TwinEvent], {
-    description: 'Read the append-only twin event journal (Ledger / History / audit), filtered and ordered by revision.'
+    description:
+      'Read the append-only twin event journal (Ledger / History / audit). Newest first by event time; ' +
+      'ordered by revision only when a revision range is given.'
   })
   async twinEvents(
     @Arg('instanceId') instanceId: string,
@@ -50,12 +56,33 @@ export class TwinJournalQuery {
     @Arg('eventType', { nullable: true }) eventType: string,
     @Arg('limit', type => Int, { nullable: true }) limit: number,
     @Ctx() context: ResolverContext,
-    @Arg('untilTime', { nullable: true }) untilTime?: string
+    @Arg('untilTime', { nullable: true }) untilTime?: string,
+    @Arg('fromTime', { nullable: true }) fromTime?: string
   ): Promise<TwinEvent[]> {
     const where: any = { domain: { id: context.state.domain.id }, instanceId }
     if (eventType) where.eventType = eventType
-    /* 시각 커서(untilTime, ISO) 우선 — eventTime ≤ T(공유 clock). 컬럼이 날짜라 **날짜로 넘긴다.** */
-    if (untilTime != null) where.eventTime = LessThanOrEqual(new Date(untilTime))
+    /*
+     * ── 구간으로 물을 수 있게 한다 (2026-08-25 실측) ────────────────────────────
+     *
+     * `untilTime` 만 있으면 **끝만 정해진 조회**다. 그러면 위쪽 경계에서 뒤로 걸어오며 종류를 하나씩
+     * 확인해야 하고, 찾는 종류가 며칠 전에 멈춘 트윈에서는 그 사이 행을 전부 열어 본다. 실측:
+     *
+     *   공정 타임라인이 부르는 방식(종류만·200건)            22.0초
+     *   같은 조회에 `untilTime` 만 더한 것                     9.7초
+     *
+     * 이유는 계획이 말한다. 종류별 시각순 인덱스가 없어서 `(domain, instanceId, eventTime)` 로 걷고
+     * 행마다 테이블을 열어 종류를 본다. 승화푸드에서 작업 사실은 8월 22일에 멈춰 있고 그 뒤로 리비전이
+     * 110만 늘었으므로, 200건에 닿기까지 그만큼을 읽고 버린다.
+     *
+     * **구간을 주면 그 범위만 걷는다**(`event_time>? AND event_time<?`). 화면은 자기가 그리는 구간을
+     * 알고 있으므로 그것을 그대로 물으면 된다 — 「전체」가 실제로는 상한에 걸린 6.7시간이었던 문제도
+     * 같은 자리에서 없어진다.
+     *
+     * 컬럼이 날짜라 **날짜로 넘긴다**(문자열로 비교하면 sqlite 에서 오류 없이 빈 결과가 나온다).
+     */
+    if (untilTime != null && fromTime != null) where.eventTime = Between(new Date(fromTime), new Date(untilTime))
+    else if (untilTime != null) where.eventTime = LessThanOrEqual(new Date(untilTime))
+    else if (fromTime != null) where.eventTime = MoreThanOrEqual(new Date(fromTime))
     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)
@@ -75,7 +102,7 @@ export class TwinJournalQuery {
      * `... FOR LAST TERM OF ORDER BY` — 시각은 인덱스(`ix_twin_event_1`)에서 순서대로 나오고
      * **동시각만** 임시 정렬한다.
      *
-     * **리비전 경로는 그대로 둔다.** 그때는 거르는 축이 `revision` 이고 정렬도 `revision` 이라 이미
+     * **`revision` 경로는 그대로 둔다.** 그때는 거르는 축이 `revision` 이고 정렬도 `revision` 이라 이미
      * 맞아 있다(`ix_twin_event_0`). 축이 어긋난 경로만 고친다 — 맞는 자리를 건드리면 그쪽이 어긋난다.
      *
      * 순서의 뜻이 **완전히 같지는 않다**(측정해서 고친 문장): `revision` 순서와 `eventTime` 순서가
@@ -83,16 +110,77 @@ export class TwinJournalQuery {
      * 이 목록은 사람이 이력을 훑는 화면이고 **시각순으로 보는 것이 그 화면의 뜻**이므로, 그 어긋남은
      * 결함이 아니라 오히려 맞는 순서다. 동시각의 순서를 위해 `revision` 을 둘째 축으로 남긴다.
      */
-    const order: any = untilTime != null ? { eventTime: 'DESC', revision: 'DESC' } : { revision: 'DESC' }
-    return getRepository(TwinEvent).find({ where, order, take: limit ?? 200 })
+    /*
+     * ── 아무 필터도 없을 때도 시각순으로 낸다 (2026-08-25 실측) ────────────────
+     * 이 갈래가 `revision DESC` 였다. 공정 타임라인은 필터 없이 상한만 걸고 부르므로
+     * (`loadTwinEvents(id, { eventType: 'task.status', limit })`) 그 갈래로 떨어졌다.
+     *
+     * `revision` 은 **적힌 순서**다. 연결된 시스템을 되읽는 트윈에서는 그 순서가 일어난 순서와 다르다 —
+     * 커넥터가 원본의 갱신 순서를 걷기 때문에, 원본에서 나중에 손댄 행이 4월 사실을 담고 있으면 그
+     * 행이 큰 revision 을 받는다. 승화푸드 실측:
+     *
+     *   작업 축에 있는 가장 늦은 사실      2026-08-23 03:20
+     *   revision 이 가장 큰 작업 사실      2026-04-15 10:49   ← 상한이 잡던 값
+     *
+     * 상한 안에 8월 두 달치가 들어오지 않았고, 화면은 4월 사실을 최근 것으로 그렸다.
+     *
+     * 아래 목록 계약(`twinEventList`)은 이미 시각순을 기본으로 골라 두었다(§`sortings`). 이 함수만
+     * 남아 있었다. 성능도 이유가 되지 않는다 — 시각 정렬이 인덱스를 순서대로 타는 것은 아래 실측이
+     * 말한다.
+     *
+     * `revision` 범위로 거를 때는 `revision DESC` 를 그대로 쓴다. 거르는 축과 정렬 축을 맞추는 규칙이고,
+     * 그때는 부르는 쪽이 리비전으로 말하고 있으므로 리비전 순서가 그 물음의 답이다.
+     */
+    const order: any = journalOrder({ untilTime, fromTime, fromRevision, toRevision })
+
+    /*
+     * ── `find` 이 아니라 질의 빌더로 묻는다 (2026-08-25 실측) ───────────────────
+     *
+     * `find({ where: { domain: { id } }, order, take })` 는 관계를 가진 엔티티에서 **두 단계 질의**가
+     * 된다. 실제로 나간 SQL 이 이렇다:
+     *
+     *   SELECT DISTINCT "distinctAlias"."TwinEvent_id", …
+     *   FROM (SELECT … 모든 컬럼 … FROM twin_events WHERE …) "distinctAlias"
+     *   ORDER BY … LIMIT ?
+     *
+     * **안쪽에 상한이 없다.** 조건에 맞는 행을 전부 만들어 놓고 밖에서 자른다. 승화푸드의 작업 사실은
+     * 438,913건이고 `payload` 가 함께 실리므로, 200건을 얻는 데 그 전부를 읽었다.
+     *
+     * 실측: 같은 조회를 손으로 쓰면 0.024초, 이 함수를 통하면 12초였다. 인덱스를 새로 얹은 뒤에도
+     * 그대로였다 — 인덱스는 안쪽 질의를 도와줄 뿐이고, 문제는 안쪽이 전부를 만든다는 것이었다.
+     *
+     * 관계를 **컬럼으로** 물으면 감싸지 않는다. 이 파일의 다른 자리(`timeRange` · 최종 리비전)가 이미
+     * 그 방식이다. `getMany` 는 조인이 없으면 `DISTINCT` 를 붙이지 않는다.
+     */
+    const qb = getRepository(TwinEvent)
+      .createQueryBuilder('e')
+      .where('e.domain = :domainId', { domainId: context.state.domain.id })
+      .andWhere('e.instanceId = :instanceId', { instanceId })
+    if (eventType) qb.andWhere('e.eventType = :eventType', { eventType })
+    if (where.eventTime !== undefined) {
+      /* 조건은 위에서 이미 정했다 — 같은 판단을 두 벌로 적지 않는다. */
+      if (untilTime != null && fromTime != null) {
+        qb.andWhere('e.eventTime BETWEEN :fromTime AND :untilTime', { fromTime: new Date(fromTime), untilTime: new Date(untilTime) })
+      } else if (untilTime != null) {
+        qb.andWhere('e.eventTime <= :untilTime', { untilTime: new Date(untilTime) })
+      } else {
+        qb.andWhere('e.eventTime >= :fromTime', { fromTime: new Date(fromTime as string) })
+      }
+    } else if (where.revision !== undefined) {
+      if (fromRevision != null && toRevision != null) qb.andWhere('e.revision BETWEEN :from AND :to', { from: fromRevision, to: toRevision })
+      else if (fromRevision != null) qb.andWhere('e.revision >= :from', { from: fromRevision })
+      else qb.andWhere('e.revision <= :to', { to: toRevision })
+    }
+    for (const [column, direction] of Object.entries(order)) qb.addOrderBy(`e.${column}`, direction as 'DESC')
+    return qb.limit(limit ?? 200).getMany()
   }
 
   /**
-   * 저널 목록 — things-factory 표준 목록 계약(`ListParam` → `{ items, total }`).
+   * 지난 기록 목록 — things-factory 표준 목록 계약(`ListParam` → `{ items, total }`).
    *
    * ── 왜 `twinEvents` 와 따로 두는가 ─────────────────────────────────────────
    * `twinEvents` 는 배열만 돌려준다. 화면은 자기가 받은 게 전부인지 잘린 건지 알 수 없었고, 그래서
-   * 리스트가 **조용히 잘린 채 "이게 전부" 처럼** 보였다(원장 limit 120 이 대표적). 총건수를 함께
+   * 리스트가 **알리지 않고 잘린 채 "이게 전부" 처럼** 보였다(원장 limit 120 이 대표적). 총건수를 함께
    * 주면 "48 / 12,904" 라고 말할 수 있고, 사용자는 좁혀야 한다는 사실을 안다.
    * 기존 호출자를 깨지 않으려고 `twinEvents` 는 그대로 두고 목록 계약을 새로 연다.
    *
@@ -120,7 +208,7 @@ export class TwinJournalQuery {
     const { domain } = context.state
     if (!instanceId && !spaceId) throw new Error('either instanceId or spaceId is required')
     /* 테넌트 격리 — twinKpi 와 같은 규약. 남의 트윈은 빈 결과가 아니라 명시 실패로 알린다
-     * (조용한 빈 목록은 "권한 없음" 과 "데이터 없음" 을 구분할 수 없게 만든다). */
+     * (들어온 것이 없는 빈 목록은 "권한 없음" 과 "데이터 없음" 을 구분할 수 없게 만든다). */
     if (instanceId && !(await TwinEngine.ownsRegistered(domain.id, instanceId))) {
       throw new Error(`twin instance not found in this tenant: ${instanceId}`)
     }
@@ -133,7 +221,16 @@ export class TwinJournalQuery {
     const limit = Math.min(params.pagination?.limit ?? 100, 500)
     const effective: ListParam = {
       ...params,
-      pagination: { page: params.pagination?.page ?? 1, limit },
+      /*
+       * ── 이어 읽기 지점을 **잃지 않는다** (2026-08-28 실측) ─────────────────────
+       *
+       * 여기서 페이지 값을 다시 만들면서 `after` 를 빼고 있었다. 그래서 응답은 다음 지점(`nextCursor`)을
+       * 내주는데 다음 요청의 그 값은 아무 데도 쓰이지 않았고, 「더 보기」가 **1페이지를 다시 냈다.**
+       * 실측: 같은 품목의 30건을 세 번 이어 읽었더니 90건 중 60건이 되풀었다(같은 id).
+       *
+       * 오류가 나지 않는 결함이라 화면에서는 「이력이 30건뿐」이나 「같은 사건이 계속 나온다」로 보인다.
+       */
+      pagination: { page: params.pagination?.page ?? 1, limit, after: params.pagination?.after },
       /* 기본 정렬은 시각 내림차순 — 여러 트윈을 합칠 때 공통 축은 revision(트윈별 카운터)이 아니라
        * **시각**이다. revision 으로 섞으면 서로 다른 트윈의 무관한 카운터가 뒤엉킨다. */
       sortings: params.sortings?.length ? params.sortings : [{ name: 'eventTime', desc: true }],
@@ -148,6 +245,70 @@ export class TwinJournalQuery {
       filters: (params.filters ?? []).map(f => (f.name === 'eventTime' ? { ...f, value: toDateValue(f.value) } : f))
     }
 
+    /*
+     * ── 대상 하나의 이력은 **파생 테이블**이 답한다 (2026-08-28 실측) ───────────
+     *
+     * 360 화면의 이력이 이 문으로 온다. 물음은 「이 품목(오더·자리·설비)의 사건을 최신순으로 30건」
+     * 인데, 저널에는 그 모양의 목차가 없다: 축으로 걸러도 시각으로 정렬하는 순간 목차를 못 쓰고,
+     * 품목과 로트가 한 문자열에 붙어 있어 품목으로는 아예 찾지 못한다. 실측 **63.998초**였다.
+     *
+     * 그 물음의 모양대로 만든 테이블이 이미 있다(`twin_subject_events`). 같은 질의가 **0.078초**다.
+     * 화면을 고치지 않고 여기서 답을 가져오는 곳만 바꾼다 — 계약도 커서도 그대로다.
+     *
+     * 맞지 않는 물음(여러 트윈·자유 검색·종류 필터·다른 정렬)이거나 파생 테이블이 그 구간을 말할 수
+     * 없으면 `null` 이 오고, 그때는 아래 저널 경로로 간다. 느리지만 온전하다.
+     */
+    if (instanceIds.length === 1) {
+      const fast = await readModelPage(domain.id, instanceIds[0], effective, limit)
+      if (fast) return fast
+    }
+
+    /*
+     * ── **여러 종류를 시각순으로 물으면 나눠 묻는다** (2026-08-28 실측) ──────────
+     *
+     * 에너지 원장이 「이 여덟 종류를 시각 내림차순으로」를 묻는다. 그 모양에서 sqlite 는 종류 색인을
+     * 버리고 시각 색인으로 337만 행을 걸으며 행마다 종류를 확인한다 — **37.181초, 결과 0건**.
+     * 종류를 정확일치로 하나씩 물으면 색인이 시각 순서까지 주므로 **각 0.003초**다.
+     *
+     * 새 색인도 새 테이블도 필요 없다. 있는 색인(`ix_twin_event_7`)을 쓰게 하는 것이 전부다.
+     * 건수 세기는 이미 빠르다(정렬을 지우므로 같은 색인을 탄다) — 목록만 이 갈래를 탄다.
+     */
+    const tiebreak: 'revision' | 'id' = instanceIds.length === 1 ? 'revision' : 'id'
+    const split = splitShape(effective, effective.sortings ?? [])
+    if (split) {
+      const page = await eventTypeSplitPage(domain.id, instanceIds, split, limit, tiebreak, effective.pagination?.after)
+      if (page) {
+        /*
+         * 건수는 일반 경로와 같은 방식으로 센다 — 상한까지 키만 읽는다. 이 조건은 정렬이 없어 종류
+         * 색인을 그대로 타므로 값이 싸다(실측 0.003초).
+         */
+        const probe = getQueryBuilderFromListParams({
+          repository: getRepository(TwinEvent),
+          params: { ...effective, pagination: { page: 1, limit: COUNT_CAP + 1 } },
+          domain,
+          searchables: [],
+          sortables: ['eventTime', 'revision', 'eventType', 'bizStep'],
+          defaultLimit: COUNT_CAP + 1,
+          maxLimit: COUNT_CAP + 1
+        })
+        probe.andWhere(`${probe.alias}.instanceId IN (:...instanceIds)`, { instanceIds })
+        const counted = await probe
+          .orderBy()
+          .select(`${probe.alias}.id`)
+          .getRawMany()
+          .catch(() => null)
+        const capped = !counted || counted.length > COUNT_CAP
+        return {
+          items: page.items,
+          total: capped ? undefined : counted!.length,
+          capped,
+          countCap: COUNT_CAP,
+          nextCursor: page.nextCursor,
+          oldestRevision: undefined
+        }
+      }
+    }
+
     const qb = getQueryBuilderFromListParams({
       repository: getRepository(TwinEvent),
       params: effective,
@@ -157,7 +318,22 @@ export class TwinJournalQuery {
       /* 정렬은 인덱스가 받쳐 주는 축으로만 — 큰 저널에서 임의 컬럼 정렬은 전체 정렬 스캔이다. */
       sortables: ['eventTime', 'revision', 'eventType', 'bizStep'],
       defaultLimit: 100,
-      maxLimit: 500
+      maxLimit: 500,
+      /*
+       * ── 동시각을 가리는 축을 **두 경로가 같게** 쓴다 (2026-08-28 실측) ─────────
+       *
+       * 커서는 「이 행 다음부터」이므로 시각이 같은 행들 사이에서 무엇이 앞인지 정해야 한다. 기본값은
+       * 기본키(`id`)인데, 파생 테이블 경로는 `revision` 으로 가린다(그 테이블에 `id` 가 없다).
+       *
+       * 두 경로가 한 목록을 나눠 답하면 그 축이 달라지고, 시각이 같은 행이 많은 자리에서 **본 행이
+       * 또 나온다.** 실측: 재고 사건 2,665건이 같은 시각을 가진 트윈에서 30건씩 네 번 이어 읽어
+       * 120건 중 15건이 되풀었다.
+       *
+       * 그래서 트윈 하나를 볼 때는 `revision` 으로 가린다 — 그 트윈 안에서 유일하고 빈 값이 없다.
+       * 여러 트윈을 합쳐 보는 목록에서는 리비전이 트윈마다 따로 세는 번호라 유일하지 않으므로
+       * 기본키를 쓴다.
+       */
+      cursorTiebreak: tiebreak
     })
     /* 대상 범위는 호출자가 필터로 빼먹을 수 있는 값이 아니다 — 계약상 필수라 여기서 강제한다. */
     qb.andWhere(`${qb.alias}.instanceId IN (:...instanceIds)`, { instanceIds })
@@ -170,7 +346,7 @@ export class TwinJournalQuery {
      *
      * 상한을 두면 같은 답이 **0.04초**다(130배). 상한을 넘으면 정확한 수를 모르는 것이 사실이므로
      * 목록 규약의 「서버 상한에 부딪힘(total 모름)」 갈래로 낸다 — 화면은 「처음 N 건만」이라고 말하고
-     * 좁히기를 권한다. **조용히 자르지 않는다**: 상한을 넘었다는 사실을 `capped` 로 함께 낸다.
+     * 좁히기를 권한다. **알리지 않고 자르지 않는다**: 상한을 넘었다는 사실을 `capped` 로 함께 낸다.
      *
      * 왜 하위 질의로 세지 않나: 5개 드라이버에서 같이 도는 형태여야 한다(이 저장소의 절대 규칙).
      * 그래서 **키 컬럼만 상한까지 읽어 세는** 방식을 쓴다 — 색인만 읽으므로 행 본문을 만들지 않는다.
@@ -188,20 +364,48 @@ export class TwinJournalQuery {
     const total = capped ? undefined : counted.length
 
     /* 다음 커서는 **이번 페이지의 마지막 행**에서 만든다. 페이지가 상한보다 짧으면 뒤가 없다. */
-    const axes = cursorSortings(effective.sortings, 'id')
+    const axes = cursorSortings(effective.sortings, tiebreak)
     const nextCursor = items.length === limit ? buildNextCursor(items[items.length - 1], axes) : undefined
 
-    return { items, total, capped, countCap: COUNT_CAP, nextCursor }
+    /*
+     * ── **앞부분이 지워졌는지 함께 낸다** (2026-08-27) ─────────────────────────
+     *
+     * 보관 기간 정리가 오래된 사건을 지운다(기본 7일). 그러면 이 목록을 아무리 내려가도 어느 지점에서
+     * 기록이 끝나는데, 화면이 그것을 말하지 않으면 사람은 「이 트윈은 그때 시작했다」로 읽는다.
+     * 없었던 것과 지워진 것은 다른 사실이다.
+     *
+     * 저장하지 않고 그때그때 구한다 — 저장한 값은 실제 데이터와 어긋날 수 있고, 어긋나면 어느 쪽이
+     * 사실인지 알 수 없다. 색인 `(domain, instanceId, revision)` 의 첫 행 하나라서 값이 싸다.
+     *
+     * 트윈 하나를 물었을 때만 낸다. 여러 트윈을 합쳐 보는 목록에서는 리비전이 트윈마다 따로 세는
+     * 번호라 하나의 답이 없다.
+     */
+    let oldestRevision: number | undefined
+    if (instanceIds.length === 1) {
+      const first = await getRepository(TwinEvent)
+        .createQueryBuilder('e')
+        .select('e.revision', 'revision')
+        .where('e.domain = :domainId', { domainId: domain.id })
+        .andWhere('e.instanceId = :instanceId', { instanceId: instanceIds[0] })
+        .orderBy('e.revision', 'ASC')
+        .limit(1)
+        .getRawOne<{ revision: unknown }>()
+        .catch(() => null)
+      const at = Number(first?.revision)
+      if (Number.isFinite(at) && at > 0) oldestRevision = at
+    }
+
+    return { items, total, capped, countCap: COUNT_CAP, nextCursor, oldestRevision }
   }
 
   /**
-   * 업무 KPI — 시간창 처리량·소요시간·자원 점유. 저널을 **접어서** 만든다(새 계측을 주입하지 않는다).
+   * 업무 KPI — 시간창 처리량·소요시간·자원 점유. 저널을 **계산해서** 만든다(새 계측을 주입하지 않는다).
    *
    * `twinMetrics`(초당 이벤트 수 = 인프라 부하)와 **다른 것**이다: 이건 "지난 한 시간에 몇 건 처리했고
    * 한 건에 얼마나 걸렸나" 다. 이름이 비슷해 헷갈리기 쉬우므로 설명에 명시한다.
    *
    * 완료된 작업의 **시작 이벤트가 창 앞에 있을 수 있어** 조회 구간을 창보다 앞으로 넓힌다(lookback).
-   * 그래도 못 찾은 것은 결과의 `unpaired` 로 드러난다 — 평균에서 조용히 빠지면 지표가 거짓이 된다.
+   * 그래도 못 찾은 것은 결과의 `unpaired` 로 드러난다 — 평균에서 오류 없이 빠지면 지표가 거짓이 된다.
    */
   @Query(returns => ScalarObject, {
     description:
@@ -233,7 +437,7 @@ export class TwinJournalQuery {
     @Arg('baselineStride', { nullable: true }) baselineStride?: string
   ): Promise<any> {
     /* 테넌트 격리 — 트윈 지정이면 소속을 확인한다. 공간 지정이면 대상 해소가 도메인 목록에서
-     * 이뤄지므로(computeTwinKpi) 남의 트윈이 섞이지 않는다. 조용한 빈 결과가 아니라 명시 실패. */
+     * 이뤄지므로(computeTwinKpi) 남의 트윈이 섞이지 않는다. 들어온 것이 없는 빈 결과가 아니라 명시 실패. */
     if (instanceId && !(await TwinEngine.ownsRegistered(context.state.domain.id, instanceId))) {
       throw new Error(`twin instance not found in this tenant: ${instanceId}`)
     }
@@ -284,7 +488,7 @@ export class TwinJournalQuery {
   ): Promise<any> {
     const state = await TwinEngine.recover(context.state.domain.id, instanceId, untilRevision ?? undefined, untilTime ?? undefined)
     const picked = pickAxes(state, axes)
-    /* 오타를 조용히 넘기지 않는다 — 화면이 빈 채로 뜨는 이유를 아무도 모르게 되는 것이 가장 나쁘다. */
+    /* 오타를 알리지 않고 넘기지 않는다 — 화면이 빈 채로 뜨는 이유를 아무도 모르게 되는 것이 가장 나쁘다. */
     if (picked.unknown.length) twinWarn(`[twin] twinReplay: unknown axes ignored for "${instanceId}": ${picked.unknown.join(', ')}`)
     if (!attentionLimit || !picked.state?.attentions) return picked.state
     const d = digestAttentions(picked.state.attentions, attentionLimit)
@@ -317,7 +521,7 @@ export class TwinJournalQuery {
 
     /*
      * 기준 주를 안 주면 **이번 주 월요일**을 쓴다. 그 주에 공휴일이 끼면 상한이 조금 낮게 나오는데,
-     * 그것은 조용한 오류가 아니라 **이번 주의 실제 가용 시간**이라 답으로서 정직하다. 평상시 상한을
+     * 그것은 들어온 것이 없는 오류가 아니라 **이번 주의 실제 가용 시간**이라 답으로서 정직하다. 평상시 상한을
      * 보려는 호출자는 평상주를 지정한다.
      */
     const base = sampleWeekStart ? Date.parse(sampleWeekStart) : Date.now()

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

@@ -48,7 +48,7 @@ export class TwinLifecycleMutation {
     // 시각 기준은 **공간**이 갖는다(테넌트 아님) — 교대의 HH:MM 을 어느 기준으로 읽나.
     if (model) {
       /* model 를 함께 주는 것은 프로비저닝이다 — 그러면 종류도 말해야 한다.
-         예전에는 `kind ?? 'wms'` 로 메웠는데, 종류를 빠뜨린 야드/생산 트윈이 **창고로 조용히 기동**했다. */
+         예전에는 `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))
     }
@@ -74,7 +74,7 @@ export class TwinLifecycleMutation {
    *
    * ── 지금 도는 것에는 손대지 않는다 ─────────────────────────────────────────
    * 이 값은 **다음 기동**의 규칙이다. 돌고 있는 런타임의 구동 방식을 바꾸려면 정지·기동이 필요하고,
-   * 그 판단은 사람의 것이다(도는 트윈을 조용히 갈아 끼우면 그 사이의 사실이 어디로 갔는지 알 수 없다).
+   * 그 판단은 사람의 것이다(도는 트윈을 알리지 않고 갈아 끼우면 그 사이의 사실이 어디로 갔는지 알 수 없다).
    * 그래서 결과에 「지금 도는 것과 다르다」는 사실을 함께 낸다.
    */
   @Directive('@privilege(category: "twin", privilege: "mutation", domainOwnerGranted: true, superUserGranted: true)')
@@ -88,7 +88,7 @@ export class TwinLifecycleMutation {
     @Ctx() context: ResolverContext
   ): Promise<any> {
     const domainId = context.state.domain.id
-    /* 값은 **엄격히** 읽는다 — 모르는 말을 기본값으로 메우면 그 트윈의 이력이 남을지가 조용히 결정된다. */
+    /* 값은 **엄격히** 읽는다 — 모르는 말을 기본값으로 메우면 그 트윈의 이력이 남을지가 알리지 않고 결정된다. */
     const policy = readRestartPolicy(restartPolicy, `twin "${instanceId}"`)
     const repo = getRepository(TwinInstance)
     const row = await repo.findOne({ where: { domain: { id: domainId }, instanceId } })
@@ -103,6 +103,60 @@ export class TwinLifecycleMutation {
     return { instanceId, restartPolicy: policy, previous: before, changed: true, appliesAtNextStart: running }
   }
 
+  /**
+   * 트윈의 **이름을 다시 붙인다** (2026-08-26).
+   *
+   * ── 왜 이 문이 필요한가 ────────────────────────────────────────────────────
+   * 이름은 트윈을 처음 세울 때 한 번 정해지고(`provision`), 다시 읽기는 그것을 건드리지 않는다. 그
+   * 자체는 안전하다 — 사람이 붙인 이름을 연결이 덮어쓰면 안 된다. 그런데 그래서 **첫날의 이름에
+   * 갇힌다.**
+   *
+   * 실제로 그런 일이 났다: 태양광 발전소를 붙일 때 커넥터가 아는 이름이 연결된 시스템의 코드
+   * (`ES202307202202`)뿐이었다. 뒤에 사람이 부르는 이름(`호현에너지`)이 어디 있는지 알아내 커넥터를
+   * 고쳤는데, 트윈 이름은 그대로였다. **연결된 시스템을 따라가는 트윈에서는 이름이 나중에 좋아진다** —
+   * 커넥터가 나아질 때마다 이 일이 난다.
+   *
+   * 그때 남은 유일한 길이 트윈을 지우고 다시 세우는 것이었다. 그러면 지난 기록이 사라진다 — **이름
+   * 하나 때문에 사실을 버리는 선택**이 된다. 그래서 이름만 바꾸는 문을 낸다.
+   *
+   * ── 연결이 따라오게 하지 않는다 ────────────────────────────────────────────
+   * 다시 읽기가 이름을 따라가게 하면 사람이 붙인 이름을 덮어쓴다. 「사람이 손대지 않았으면 따라간다」가
+   * 옳아 보이지만, 그러려면 「손댔다」는 표시를 새로 만들어야 하고 그것은 이름 하나 때문에 지기에 무거운
+   * 빚이다. 사람이 바꾸는 길만 낸다.
+   *
+   * ── 빈 이름은 받지 않는다 ──────────────────────────────────────────────────
+   * 이름을 지우는 것과 바꾸는 것은 다른 일이다. 빈 값을 받으면 그 트윈은 목록에서 식별자만 남는데,
+   * 그것을 「이름을 바꿨다」로 보고하면 거짓이다. 지우고 싶으면 그 뜻의 문이 따로 있어야 한다.
+   */
+  @Directive('@privilege(category: "twin", privilege: "mutation", domainOwnerGranted: true, superUserGranted: true)')
+  @Mutation(returns => ScalarObject, {
+    description:
+      'Rename a twin instance. The name is set when the twin is first provisioned and a re-read never touches it, ' +
+      'so a twin stays with the name its connector knew on day one — often a code from the connected system. ' +
+      'This changes the name only; nothing about the twin data, its journal or its runtime is affected. ' +
+      'An empty name is refused: clearing a name and changing it are different acts.'
+  })
+  async renameTwinInstance(
+    @Arg('instanceId') instanceId: string,
+    @Arg('name') name: string,
+    @Ctx() context: ResolverContext
+  ): Promise<any> {
+    const domainId = context.state.domain.id
+    const next = String(name ?? '').trim()
+    if (!next) throw new Error(`a twin name cannot be empty — "${instanceId}" was left as it was`)
+
+    const repo = getRepository(TwinInstance)
+    const row = await repo.findOne({ where: { domain: { id: domainId }, instanceId } })
+    if (!row) throw new Error(`unknown twin "${instanceId}" in this domain — nothing was changed`)
+
+    const before = row.name ?? ''
+    if (before === next) return { instanceId, name: next, changed: false }
+
+    await repo.update({ id: row.id }, { name: next, updater: context.state.user })
+    /* 도는 런타임은 이름을 쓰지 않는다(식별자로 돈다) — 그래서 정지·기동이 필요하지 않다. */
+    return { instanceId, name: next, previous: before || null, changed: true }
+  }
+
   /** 삭제 — 정지 + 레지스트리 삭제 + 저널 purge(domain 스코프). */
   @Directive('@privilege(category: "twin", privilege: "mutation", domainOwnerGranted: true, superUserGranted: true)')
   @Mutation(returns => Boolean, { description: 'Delete a twin instance: stop it, remove the registry entry and purge its event journal.' })

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

@@ -49,7 +49,7 @@ export class TwinMetricsQuery {
    * `twinMetrics` 는 **통과한** 이벤트의 초당 수를 답한다. 여기서 답하는 것은 **제시된 것 중 얼마가
    * 통과했나**이고, 통과하지 못한 것의 이유와 실제 모양까지 낸다.
    *
-   * 왜 따로 있나: 거부된 레코드는 **저널에 없다**(거부의 뜻이 그것이다). 저널을 접어 나오는 것은 통과한
+   * 왜 따로 있나: 거부된 레코드는 **저널에 없다**(거부의 뜻이 그것이다). 저널을 계산해 나오는 것은 통과한
    * 쪽뿐이라, 거부의 추이는 세는 자리를 따로 두어야 나온다.
    *
    * 왜 도메인으로 자르나: 이것은 **테넌트의 데이터**다. 거부 표본에는 그 고객의 레코드 원문이 들어
@@ -66,6 +66,19 @@ export class TwinMetricsQuery {
    * 빈 배열로 두면 「거부된 것이 없다」로 읽힌다.
    */
   @Query(returns => ScalarObject, {
+    /*
+     * ── `null` 이 정답인 자리다 (2026-08-29 실측) ───────────────────────────────
+     * 이 조회는 세 경우에 `null` 을 낸다: 다른 도메인의 트윈 · 등록되지 않은 트윈 · 아직 돌지 않는
+     * 트윈. 설명문에도 그렇게 적혀 있었는데 **스키마가 그것을 금지하고 있었다.**
+     *
+     * 그래서 화면이 아직 돌지 않는 트윈을 열면 조회 전체가 이 오류로 죽었다.
+     *
+     *   Cannot return null for non-nullable field Query.twinIngestHealth.
+     *
+     * 「없다」를 낼 수 있어야 화면이 「아직 잰 것이 없다」를 말한다. 빈 객체로 바꾸면 그것이
+     * 「재 봤는데 아무것도 없다」로 읽힌다 — 두 사실이 다르다.
+     */
+    nullable: true,
     description:
       'Answers one question: is this twin keeping in step with the floor? Returns a verdict — syncing | mapping-blocked | no-traffic | not-connected | not-applicable | unknown — together with the threshold it was judged by, so a screen can say why. `recent` is the last **closed** 10-minute window (null while the first window is still filling: a partially filled window under-counts, so it is not called "recent"), and `trend` carries up to 36 closed windows (6 hours) oldest-first with offered / accepted / rejected per window. Accepted and rejected are reported together because counting only rejections makes "nothing is arriving" and "everything is fine" both look like zero. `reasons` groups rejections by the reason the kernel gave, most frequent first, each with the last time that reason occurred — a reason whose time has stopped is one you already fixed. `samples` holds one rejected record per reason (the raw record, truncated with recordTruncated when long) because a reason alone does not tell you what the source actually sent. Counts that could not be shown are reported rather than dropped: sampleDropped, trendDropped, and reasonsCapped when distinct reasons hit their limit and the rest were folded into "(other reasons)". A twin that has never received anything reports null figures rather than zeros, since never-measured and measured-as-zero are different facts. This ledger lives in memory: it covers roughly the last 6 hours and resets when the process restarts. The verdict, trend and reasons are returned to anyone in the owning domain, but the raw records in `samples` are business data of that tenant, so they require the same privilege as changing the twin (twin/mutation, with domain owner and superuser granted); when the caller lacks it, `samples` comes back empty and `samplesWithheld` says how many were held back — an empty list alone would read as "nothing was rejected". `modelGap` answers a different question from the verdict: the verdict is about the feed (is anything arriving, does it pass), while modelGap is about the model (did we declare what the source knows). The ingest gate deliberately does not reject a record that references an id the master never declared — a source may legitimately report a new place before the structure sync catches up, and rejecting it would lose that measurement. The kernel absorbs it and marks it `origin: "observed"` instead, and modelGap counts those per axis (locations / equipment / persons) with a capped id list plus how many more were left out. It also carries the kernel\'s `unhandled` tally — event kinds the twin could not apply at all — and, for energy twins, how many state reports arrived from equipment the model does not know. `notCovered` names axes this cannot answer yet: meters carry no origin mark in the kernel, so a mistyped meterId silently becomes a new meter whose kW is accumulated into the site demand. Null while the twin is not running: there is nothing to compare against, and never-compared is not the same as none. Null if the instance is not in the current domain.'
   })

package/server/service/twin-model/axis-journal-evidence.ts

@@ -50,7 +50,7 @@ export async function axisSeenInJournal(
   /*
    * 접두사로 찾는 축(물품) — 한 건만 있으면 된다. `Like` 를 쓰는 대신 **낱말 목록**을 쓰지 않는 이유는
    * EPCIS 사건 이름이 커널에서 자라기 때문이다(객체·집약·변환·거래…). 이름을 여기 베끼면 커널이
-   * 하나 늘릴 때 이 자리가 조용히 낡는다.
+   * 하나 늘릴 때 이 자리가 알리지 않고 낡는다.
    */
   const { Like } = await import('typeorm')
   return anyJournalRow(repo, { ...where, eventType: Like(`${spec.prefix}%`) })

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

@@ -76,6 +76,31 @@ const EVENTS: Isa95Concept[] = [
 
 /* 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',
@@ -143,11 +168,15 @@ const FIELDS: Isa95Concept[] = [
     note: 'twin.epcis.note.ilmd'
   },
   {
+    /*
+     * `shownOn` 은 「어디에 속하나」다 — 정정 선언은 물품의 사실이다. 화면에 그려지는지는 `surface` 가
+     * 따로 답한다(지금은 `none` 이고 `note` 가 그 사실을 말한다). 둘은 다른 물음이다(§`shownOn`).
+     */
+    shownOn: ['items'],
     std: 'errorDeclaration',
     part: 'fields',
     label: 'twin.epcis.errorDeclaration',
     axis: null,
-    shownOn: ['items'],
     structure: 'full',
     behavior: 'partial',
     surface: 'none',
@@ -155,6 +184,8 @@ const FIELDS: Isa95Concept[] = [
   },
   /* 모양만 있고 아무도 채우지 않는 것들 — 구조만 있음. */
   {
+    /* 어디에 속하나 — 소유·보관의 이전은 그 물품의 사실이다. 화면에 그려지는지는 `surface` 가 따로 답한다(§`shownOn`). */
+    shownOn: ['items'],
     std: 'sourceList / destinationList',
     part: 'fields',
     label: 'twin.epcis.sourceDestination',
@@ -165,6 +196,8 @@ const FIELDS: Isa95Concept[] = [
     note: 'twin.epcis.note.sourceDestination'
   },
   {
+    /* 어디에 속하나 — 지속 처분은 그 물품에 붙는다. 화면에 그려지는지는 `surface` 가 따로 답한다(§`shownOn`). */
+    shownOn: ['items'],
     std: 'persistentDisposition',
     part: 'fields',
     label: 'twin.epcis.persistentDisposition',
@@ -188,6 +221,8 @@ const FIELDS: Isa95Concept[] = [
    * 그 구별을 표가 말하지 않으면 「센서를 못 받는 트윈」으로 읽힌다.
    */
   {
+    /* 어디에 속하나 — 표준에서 센서 관측은 **개체에 붙는다** — 우리가 그것을 자리로 옮긴 것이 다른 이야기다. 화면에 그려지는지는 `surface` 가 따로 답한다(§`shownOn`). */
+    shownOn: ['items'],
     std: 'sensorElementList',
     part: 'fields',
     label: 'twin.epcis.sensorElement',

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

@@ -36,7 +36,7 @@ const LOGICAL_NODES: Isa95Concept[] = [ // vocabulary-guard: allow — IEC 61850
     note: 'twin.iec61850.note.MMTR'
   },
   /*
-   * 계측(유효전력·역률) — 표본이 수요 구간으로 접히고, 구간·피크·계약 대비가 그 위에 선다.
+   * 계측(유효전력·역률) — 표본이 수요 구간에 합쳐지고, 구간·피크·계약 대비가 그 위에 선다.
    * 이 프로파일에서 가장 두껍게 채운 자리다.
    */
   {