@things-factory/headless-twin 10.1.278 → 10.1.279

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

@@ -1,615 +0,0 @@
-import { twinWarn } from '../../engine/log.js'
-import { Between, LessThanOrEqual, MoreThanOrEqual } from 'typeorm'
-import { Arg, Args, Ctx, Float, Int, Query, Resolver, UseMiddleware } from 'type-graphql'
-
-import { buildNextCursor, cursorSortings, getQueryBuilderFromListParams, getRepository, ListParam, ScalarObject, SpeakRefusals } from '@things-factory/shell'
-
-import { TwinEvent } from '../twin-event/twin-event.js'
-import { JOURNAL_COUNT_CAP } from '../twin-event/journal-count.js'
-import { TwinEventList } from '../twin-event/twin-event-type.js'
-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.
- * twinEvents : append-only 이벤트 저널 조회(Ledger/History/Entity360) — instanceId·revision 범위·eventType 필터.
- * twinReplay : 내구 저널을 replay 해 상태 재구성(재부팅 복구·시간여행) — untilRevision 으로 임의 과거.
- * (실시간 스트림은 twinState subscription, 명령은 twin-control mutation. 이건 '질의' 표면.)
- */
-/*
- * 건수 상한은 **저널 세기의 문**에서 온다(`journal-count.ts`) — 값과 규율이 두 곳에 흩어지면 한쪽만
- * 고쳐진다. 근거(2026-08-22 실측): 상한 1만이면 0.04초, 상한 없이 세면 5.32초(저널 358만 행).
- */
-const COUNT_CAP = JOURNAL_COUNT_CAP
-
-/**
- * 시각 필터 값을 날짜로 — 배열(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)
-}
-
-/**
- * 자유 검색어가 펼쳐지는 축 — **목록과 건수가 같은 것을 본다**(2026-09-19).
- *
- * 전부 인덱스 가능한 승격 컬럼이다(payload JSON 안이 아니라). 프레임워크 질의 빌더는 이 목록에 없는
- * 컬럼의 LIKE 를 경고 후 무시한다 — 인덱스 없는 전체 스캔을 막기 위해서다.
- *
- * ── 왜 상수인가 ────────────────────────────────────────────────────────────
- * 목록과 건수가 **다른 빌더**로 만들어진다(빠른 갈래의 건수 probe). 두 자리에 배열을 따로 적으면
- * 한쪽만 늘어나는 날 목록은 걸러지고 건수는 안 걸러진다 — 화면에 「한 건」과 「전체 수」가 나란히 선다.
- *
- * 지금은 그 일이 **일어날 수 없다**: 빠른 갈래는 검색어가 있으면 아예 안 탄다
- * (`event-type-split-shape.ts` — 시험 「자유 검색어」가 그 축을 붙든다). 그래도 같은 상수를 쓴다 —
- * 그 규칙이 언젠가 느슨해질 때 이 자리가 조용히 갈리지 않게.
- */
-export const JOURNAL_SEARCHABLES = ['epc', 'orderId', 'locationId', 'moverId', 'bizStep', 'eventType', 'correlationId'] as const
-
-@Resolver()
-@UseMiddleware(SpeakRefusals)
-export class TwinJournalQuery {
-  @Query(returns => [TwinEvent], {
-    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,
-    @Arg('fromRevision', type => Int, { nullable: true }) fromRevision: number,
-    @Arg('toRevision', type => Int, { nullable: true }) toRevision: number,
-    @Arg('eventType', { nullable: true }) eventType: string,
-    @Arg('limit', type => Int, { nullable: true }) limit: number,
-    @Ctx() context: ResolverContext,
-    @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
-    /*
-     * ── 구간으로 물을 수 있게 한다 (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)
-
-    /*
-     * 최신순(DESC) 기본 — Ledger/recent 뷰. 범위 필터로 시간여행 구간 조회도 가능.
-     *
-     * ── 정렬 축을 **거르는 축과 맞춘다** (2026-08-22 실측) ─────────────────────
-     * `untilTime` 경로는 `eventTime <= T` 로 거르면서 `revision` 으로 정렬했다. 그러면 sqlite 는 조건에
-     * 맞는 행을 **전부 찾아 전부 정렬한 뒤** 상한을 적용한다 — 상한이 정렬 뒤에 걸리므로 200건을 얻는
-     * 데도 전량 정렬을 치른다. 실측(인스턴스 하나가 375만 행):
-     *
-     *   ORDER BY revision DESC              → 33.4초
-     *   ORDER BY eventTime DESC, revision DESC → 0.007초   (4,700배)
-     *
-     * 계획이 그것을 그대로 말한다: 앞은 `USE TEMP B-TREE FOR ORDER BY`(전체 정렬), 뒤는
-     * `... FOR LAST TERM OF ORDER BY` — 시각은 인덱스(`ix_twin_event_1`)에서 순서대로 나오고
-     * **동시각만** 임시 정렬한다.
-     *
-     * **`revision` 경로는 그대로 둔다.** 그때는 거르는 축이 `revision` 이고 정렬도 `revision` 이라 이미
-     * 맞아 있다(`ix_twin_event_0`). 축이 어긋난 경로만 고친다 — 맞는 자리를 건드리면 그쪽이 어긋난다.
-     *
-     * 순서의 뜻이 **완전히 같지는 않다**(측정해서 고친 문장): `revision` 순서와 `eventTime` 순서가
-     * 어긋나는 자리가 실재한다(426만 행 중 7건 — 미러는 원본의 시각을 싣고 도착 순서로 리비전을 받는다).
-     * 이 목록은 사람이 이력을 훑는 화면이고 **시각순으로 보는 것이 그 화면의 뜻**이므로, 그 어긋남은
-     * 결함이 아니라 오히려 맞는 순서다. 동시각의 순서를 위해 `revision` 을 둘째 축으로 남긴다.
-     */
-    /*
-     * ── 아무 필터도 없을 때도 시각순으로 낸다 (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 }`).
-   *
-   * ── 왜 `twinEvents` 와 따로 두는가 ─────────────────────────────────────────
-   * `twinEvents` 는 배열만 돌려준다. 화면은 자기가 받은 게 전부인지 잘린 건지 알 수 없었고, 그래서
-   * 리스트가 **알리지 않고 잘린 채 "이게 전부" 처럼** 보였다(원장 limit 120 이 대표적). 총건수를 함께
-   * 주면 "48 / 12,904" 라고 말할 수 있고, 사용자는 좁혀야 한다는 사실을 안다.
-   * 기존 호출자를 깨지 않으려고 `twinEvents` 는 그대로 두고 목록 계약을 새로 연다.
-   *
-   * ── 검색이 진짜인 이유 ─────────────────────────────────────────────────────
-   * `searchables` 는 전부 **인덱스 가능한 승격 컬럼**이다(payload JSON 안이 아니라). 프레임워크
-   * 질의 빌더는 `searchables` 에 없는 컬럼의 LIKE 를 경고 후 무시한다 — 인덱스 없는 전체 스캔을
-   * 막기 위해서다. 그 규율에 맞추려고 검색 축을 컬럼으로 승격했다(`twin-event-keys.ts`).
-   *
-   * 정렬 기본값은 revision DESC(최신순) — 저널의 자연 순서이자 ix_twin_event_0 가 그대로 타는 축.
-   */
-
-  @Query(returns => TwinEventList, {
-    description:
-      'List twin journal events with the standard list contract (filters, pagination, sortings) plus the total match count. ' +
-      'Scope is either one twin (instanceId) or a whole site (spaceId, which folds in every running operational twin co-located there, the same targets twinKpi uses) — one of the two is required. ' +
-      'Searchable fields are the columns promoted out of the payload: epc (item), orderId, locationId, moverId (equipment), bizStep, eventType. ' +
-      'Returns total so a caller can show an honest "shown of total" count instead of silently truncating a long journal. ' +
-      'Defaults to newest first (revision descending) and to a page of 100; limit is capped at 500 per page.'
-  })
-  async twinEventList(
-    @Args(type => ListParam) params: ListParam,
-    @Ctx() context: ResolverContext,
-    @Arg('instanceId', { nullable: true, description: 'Read one twin instance journal.' }) instanceId?: string,
-    @Arg('spaceId', { nullable: true, description: 'Read every running operational twin co-located in this space, merged on the shared time axis.' }) spaceId?: string
-  ): Promise<TwinEventList> {
-    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}`)
-    }
-
-    /* 대상 해소는 KPI 와 같은 창구를 쓴다 — 같은 공간을 보면서 화면마다 대상이 달라지면 안 된다. */
-    const instanceIds = await resolveTwinTargets(domain.id, instanceId, spaceId)
-    if (instanceIds.length === 0) return { items: [], total: 0 }
-
-    /* 페이지 상한 — 화면이 실수로(또는 악의로) 저널 전체를 한 번에 달라고 해도 서버가 버틴다. */
-    const limit = Math.min(params.pagination?.limit ?? 100, 500)
-    const effective: ListParam = {
-      ...params,
-      /*
-       * ── 이어 읽기 지점을 **잃지 않는다** (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 }],
-      /*
-       * 시각 필터는 **날짜로 바꿔서** 질의 빌더에 넘긴다.
-       *
-       * 화면은 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))
-    }
-
-    /*
-     * ── 대상 하나의 이력은 **파생 테이블**이 답한다 (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: [...JOURNAL_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,
-      domain,
-      /* 전부 인덱스 가능한 승격 컬럼 — 자유 검색어는 서버가 이 축들로 펼친다. */
-      searchables: [...JOURNAL_SEARCHABLES],
-      /* 정렬은 인덱스가 받쳐 주는 축으로만 — 큰 저널에서 임의 컬럼 정렬은 전체 정렬 스캔이다. */
-      sortables: ['eventTime', 'revision', 'eventType', 'bizStep'],
-      defaultLimit: 100,
-      maxLimit: 500,
-      /*
-       * ── 동시각을 가리는 축을 **두 경로가 같게** 쓴다 (2026-08-28 실측) ─────────
-       *
-       * 커서는 「이 행 다음부터」이므로 시각이 같은 행들 사이에서 무엇이 앞인지 정해야 한다. 기본값은
-       * 기본키(`id`)인데, 파생 테이블 경로는 `revision` 으로 가린다(그 테이블에 `id` 가 없다).
-       *
-       * 두 경로가 한 목록을 나눠 답하면 그 축이 달라지고, 시각이 같은 행이 많은 자리에서 **본 행이
-       * 또 나온다.** 실측: 재고 사건 2,665건이 같은 시각을 가진 트윈에서 30건씩 네 번 이어 읽어
-       * 120건 중 15건이 되풀었다.
-       *
-       * 그래서 트윈 하나를 볼 때는 `revision` 으로 가린다 — 그 트윈 안에서 유일하고 빈 값이 없다.
-       * 여러 트윈을 합쳐 보는 목록에서는 리비전이 트윈마다 따로 세는 번호라 유일하지 않으므로
-       * 기본키를 쓴다.
-       */
-      cursorTiebreak: tiebreak
-    })
-    /* 대상 범위는 호출자가 필터로 빼먹을 수 있는 값이 아니다 — 계약상 필수라 여기서 강제한다. */
-    qb.andWhere(`${qb.alias}.instanceId IN (:...instanceIds)`, { instanceIds })
-
-    /*
-     * ── 건수는 **상한까지만** 센다 (2026-08-22 실측) ──────────────────────────
-     * 예전에는 `getManyAndCount()` 였다. 그 두 번째 질의가 조건에 맞는 행을 **전부** 세는데, 실측한
-     * 개발 저널에서 트윈 하나가 358만 행이라 **한 번에 5.32초**였다. 이력 화면을 열 때마다 그것을
-     * 물었고, 그 5초 동안 이벤트 루프가 다른 요청을 처리하지 못했다.
-     *
-     * 상한을 두면 같은 답이 **0.04초**다(130배). 상한을 넘으면 정확한 수를 모르는 것이 사실이므로
-     * 목록 규약의 「서버 상한에 부딪힘(total 모름)」 갈래로 낸다 — 화면은 「처음 N 건만」이라고 말하고
-     * 좁히기를 권한다. **알리지 않고 자르지 않는다**: 상한을 넘었다는 사실을 `capped` 로 함께 낸다.
-     *
-     * 왜 하위 질의로 세지 않나: 5개 드라이버에서 같이 도는 형태여야 한다(이 저장소의 절대 규칙).
-     * 그래서 **키 컬럼만 상한까지 읽어 세는** 방식을 쓴다 — 색인만 읽으므로 행 본문을 만들지 않는다.
-     */
-    const items = await qb.getMany()
-    const probe = qb
-      .clone()
-      .orderBy() /* 세는 데 순서는 필요 없다 — 정렬을 남기면 임의 축에서 전체 정렬이 된다. */
-      .skip(0)
-      .take(COUNT_CAP + 1)
-      .select(`${qb.alias}.id`)
-    const counted = await probe.getRawMany()
-    const capped = counted.length > COUNT_CAP
-    /* 상한을 넘었으면 **전체 수를 모른다** — 상한값을 전체로 적으면 화면이 거짓을 말한다. */
-    const total = capped ? undefined : counted.length
-
-    /* 다음 커서는 **이번 페이지의 마지막 행**에서 만든다. 페이지가 상한보다 짧으면 뒤가 없다. */
-    const axes = cursorSortings(effective.sortings, tiebreak)
-    const nextCursor = items.length === limit ? buildNextCursor(items[items.length - 1], axes) : undefined
-
-    /*
-     * ── **앞부분이 지워졌는지 함께 낸다** (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 — 시간창 처리량·소요시간·자원 점유. 저널을 **계산해서** 만든다(새 계측을 주입하지 않는다).
-   *
-   * `twinMetrics`(초당 이벤트 수 = 인프라 부하)와 **다른 것**이다: 이건 "지난 한 시간에 몇 건 처리했고
-   * 한 건에 얼마나 걸렸나" 다. 이름이 비슷해 헷갈리기 쉬우므로 설명에 명시한다.
-   *
-   * 완료된 작업의 **시작 이벤트가 창 앞에 있을 수 있어** 조회 구간을 창보다 앞으로 넓힌다(lookback).
-   * 그래도 못 찾은 것은 결과의 `unpaired` 로 드러난다 — 평균에서 오류 없이 빠지면 지표가 거짓이 된다.
-   */
-  @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 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,
-    /* 공간이 사용자의 단위다 — 한 트윈만 보려면 instanceId 를 준다(둘 중 하나 필수). */
-    @Arg('spaceId', { nullable: true }) spaceId?: string,
-    @Arg('instanceId', { nullable: true }) instanceId?: string,
-    /** 창 시작·끝(ISO). 미지정이면 최근 1시간. */
-    @Arg('fromTime', { nullable: true }) fromTime?: string,
-    @Arg('toTime', { nullable: true }) toTime?: string,
-    /** 창 길이(분). fromTime 이 있으면 무시. 기본 60. */
-    @Arg('windowMinutes', type => Int, { nullable: true }) windowMinutes?: number,
-    /** 추세를 위해 창을 N 등분(1~48). 미지정이면 쪼개지 않는다. */
-    @Arg('buckets', type => Int, { nullable: true }) buckets?: number,
-    /** 시작 이벤트를 찾기 위해 창보다 앞으로 더 읽는 시간(분). 기본 60. */
-    @Arg('lookbackMinutes', type => Int, { nullable: true }) lookbackMinutes?: number,
-    /** 관점 축 — 같은 창을 자원별·작업종류별·도착지점별·오더별·구역별로 쪼갠다. */
-    @Arg('groupBy', { nullable: true }) groupBy?: string,
-    /** 축의 상한(기본 20, 최대 100). 넘치면 잘라내고 잘린 수를 알린다. */
-    @Arg('groupLimit', type => Int, { nullable: true }) groupLimit?: number,
-    /** 비교 기준 — 같은 길이의 앞 구간(previous)이나 하루 전 같은 시간(yesterday). */
-    @Arg('compareTo', { nullable: true }) compareTo?: string,
-    /** 여러 구간 동시 비교 — 최근 N 구간의 같은 시간대 분포(1~14). */
-    @Arg('baselinePeriods', type => Int, { nullable: true }) baselinePeriods?: number,
-    /** 분포의 간격 — day(같은 시간대) | week(같은 요일·시간대). 기본 day. */
-    @Arg('baselineStride', { nullable: true }) baselineStride?: string
-  ): Promise<any> {
-    /* 테넌트 격리 — 트윈 지정이면 소속을 확인한다. 공간 지정이면 대상 해소가 도메인 목록에서
-     * 이뤄지므로(computeTwinKpi) 남의 트윈이 섞이지 않는다. 들어온 것이 없는 빈 결과가 아니라 명시 실패. */
-    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')
-    /* 창 해소·조회·폴드는 `computeTwinKpi` 가 소유한다 — 같은 규칙을 AI 도구와 공유해야 한다
-     * (두 곳에 적으면 화면과 AI 가 다른 숫자를 말한다). */
-    return computeTwinKpi({
-      domainId: context.state.domain.id,
-      instanceId,
-      spaceId,
-      fromTime,
-      toTime,
-      windowMinutes,
-      buckets,
-      lookbackMinutes,
-      groupBy: groupBy as any,
-      groupLimit,
-      compareTo: compareTo as any,
-      ...(baselinePeriods && baselinePeriods > 0
-        ? { baseline: { periods: baselinePeriods, stride: (baselineStride as any) === 'week' ? 'week' : 'day' } }
-        : {})
-    })
-  }
-
-  @Query(returns => ScalarObject, {
-    nullable: true,
-    description: 'Reconstruct twin state from the durable journal (DB → replay). untilTime (ISO) for time-travel on the shared clock (preferred); untilRevision for the lens-internal counter; omit both for latest.'
-  })
-  async twinReplay(
-    @Arg('instanceId') instanceId: string,
-    @Arg('untilRevision', type => Int, { nullable: true }) untilRevision: number,
-    @Arg('untilTime', { nullable: true }) untilTime: string,
-    @Ctx() context: ResolverContext,
-    /*
-     * 필요한 축만 — 지도는 `locations`·`attentions` 만 쓰는데 상태를 통째로 받고 있었다(실 저널로
-     * 재 보니 트윈 하나가 최대 710KB, 같은 공간에 셋이면 약 2MB). 화면 전용 질의를 만들지 않고
-     * 호출부가 축을 말한다(무방언 — 어휘가 화면 이름이 아니라 상태의 축이다).
-     * 말하지 않으면 자르지 않는다(기존 호출부 무영향).
-     */
-    @Arg('axes', type => [String], { nullable: true }) axes?: string[],
-    /*
-     * 신호는 몇 건만 필요한가 — 레일은 20건을 그리고 나머지는 "N건 더" 라고만 말한다. 그런데 신호가
-     * 많은 트윈은 그 전량이 108KB 다(`hatio-yard` 397건). 상위 N 만 보내고 **전체 개수와 자리별
-     * 최고 심각도는 전량을 근거로** 함께 보낸다 — 레일은 잘라도 되지만 지도 색은 잘라선 안 된다.
-     * 말하지 않으면 자르지 않는다.
-     */
-    @Arg('attentionLimit', type => Int, { nullable: true }) attentionLimit?: number
-  ): 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)
-    /* 잘랐다는 사실을 값으로 남긴다 — 개수만 줄어들면 화면은 "괜찮아졌다" 로 읽는다. */
-    return { ...picked.state, attentions: d.attentions, attentionTotal: d.attentionTotal, severityByLocation: d.severityByLocation }
-  }
-
-  @Query(returns => ScalarObject, {
-    nullable: true,
-    description:
-      'Steady-state capacity of a twin against a declared demand: per-operation supply vs required across equipment, personnel, physical assets and locations, plus the binding constraint and the daily ceiling. Answers "can this plant meet the target?" without running a simulation. Null when the twin is not running.'
-  })
-  async twinCapacity(
-    @Arg('instanceId', { nullable: true }) instanceId: string,
-    @Arg('spaceId', { nullable: true }) spaceId: string,
-    /** 하루 몇 대를 낼 것인가 — 화면이 보고 있는 목표에서 나온다(선언된 수요). */
-    @Arg('unitsPerDay', type => Float) unitsPerDay: number,
-    /**
-     * 가용 시간을 잴 기준 주의 시작(ISO, 월요일). 공휴일이 없는 평상주여야 한다 —
-     * 공휴일은 연간 가용량을 따로 깎지, 이 공장의 평상시 상한을 정하지 않는다.
-     */
-    @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 base = sampleWeekStart ? Date.parse(sampleWeekStart) : Date.now()
-    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.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 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> {
-    /* 이력 질문이므로 **등록부**에 소유를 묻는다 — 꺼진 트윈의 이력도 읽을 수 있어야 한다. */
-    if (!(await TwinEngine.ownsRegistered(context.state.domain.id, instanceId))) {
-      throw new Error(`twin instance not found in this tenant: ${instanceId}`)
-    }
-    return TwinEngine.structureHistory(context.state.domain.id, instanceId)
-  }
-
-  @Query(returns => ScalarObject, {
-    description: 'Event time range (min/max ISO) across all co-located twins of a space — the history scrubber time axis.'
-  })
-  async twinTimeRange(
-    @Arg('spaceId') spaceId: string,
-    @Ctx() context: ResolverContext
-  ): Promise<{ minTime: string | null; maxTime: string | null }> {
-    return TwinEngine.timeRange(context.state.domain.id, spaceId)
-  }
-}