@things-factory/headless-twin 10.1.278 → 10.1.280

package/test/broadcast-cost-baseline.test.ts

@@ -1,201 +0,0 @@
-/*
- * **브로드캐스팅 한 번의 비용** — 200ms 마다 무엇을 만드는지 값으로 남긴다 (2026-08-21).
- *
- * ── 왜 재는가 ───────────────────────────────────────────────────────────────
- * `publishEntityData` 는 브로드캐스팅 주기마다 ① 상태를 통째로 투영하고(`getSnapshot`) ② 엔티티마다 payload 를
- * 만들고(`buildEntityDeltas`) ③ 그 payload 를 문자열로 만들어 이전 것과 비교한다. ③ 의 비교가 없던
- * 시절에는 바뀌지 않은 것까지 전송했고, 그 낭비는 2026-08-14 에 없앴다 — 그런데 없앤 것은 **전송**이고
- * ①②③ 의 **계산은 그대로** 남았다. 물품이 수천 개인 트윈에서는 하나만 움직여도 수천 개를 만들어
- * 문자열로 바꾼 뒤 「같다」를 확인하고 버린다.
- *
- * 고치기 전에 세 축의 몫을 값으로 남긴다. 짐작으로 고치면 무엇이 나아졌는지 말할 수 없다.
- *
- * ── 고친 뒤 (2026-08-21) ────────────────────────────────────────────────────
- * 이제 브로드캐스팅은 **건드린 물품만** 만든다(`buildEntityDeltas` 의 `scope.items`). 그래서 이 시험은 두
- * 창을 나란히 잰다: 범위를 모를 때(전부) 와 물품 하나를 건드렸을 때(좁힘).
- *
- * ── 게이트는 시간이 아니다 ──────────────────────────────────────────────────
- * 기계마다·스위트 병렬 실행마다 시간은 달라진다(같은 코드에서 3.2배와 14.8배가 나온 적이 있다). 그래서
- * 단정은 **시간과 무관한 사실**로 한다: 좁힌 창이 만든 물품 payload 가 말한 것 하나뿐인가. 시간은
- * 기준선으로 출력만 하고, 여러 번 재 그중 **가장 짧은 값**을 적는다(GC·JIT 잡음을 덜 타는 값).
- */
-import { test } from 'node:test'
-import assert from 'node:assert/strict'
-
-import { MesKernel } from '@operato/twin-kernel'
-import { type CanonicalEnvelope, type ProductionSpec, type ScenarioDef, type TwinModelDef } from '@operato/ops-contract'
-
-import { buildEntityDeltas } from '../shared/entity-delta.ts'
-
-const COMMISSIONING = 'urn:epcglobal:cbv:bizstep:commissioning'
-/* GS1 이 예제로 지정한 `952` 대역 — 실 배정 대역을 픽스처에 두지 않는다(CBV 2.0). */
-const PREFIX = '9521321'
-const RAW_GTIN = `urn:epc:idpat:sgtin:${PREFIX}.0001.*`
-
-const DEFINITION: any = {
-  materials: [
-    { key: 'raw', label: '원자재', locationType: 'raw-store' },
-    { key: 'product', label: '완제품', locationType: 'fg-store' }
-  ],
-  locationTypes: [
-    { key: 'raw-store', label: '자재 보관' },
-    { key: 'cut-st', label: '절단' },
-    { key: 'fg-store', label: '완제품 보관' }
-  ],
-  resourceTypes: [{ key: 'cutter', label: '절단기' }],
-  operations: [{ key: 'cut', label: '절단', intent: 'process', locationType: 'cut-st', resourceType: 'cutter', bizStep: COMMISSIONING }],
-  routes: [{ key: 'line', label: '라인', steps: ['cut'] }],
-  recipes: [{ key: 'prod', label: '완제품', inputs: [{ material: 'raw', qty: 1 }], outputs: [{ material: 'product', qty: 1 }], route: 'line' }]
-}
-const SPEC: ProductionSpec = {
-  definition: DEFINITION,
-  binding: { raw: '0001', product: '0002' },
-  identity: { documentTypes: { workorder: '403' }, namespaces: [`urn:epc:idpat:sgtin:${PREFIX}.`] },
-  companyPrefix: PREFIX
-}
-
-function board(): TwinModelDef {
-  return {
-    locations: [
-      { id: 'raw-store', type: 'raw-store', capacity: 1_000_000 },
-      { id: 'cut-st', type: 'cut-st', capacity: 1_000_000 },
-      { id: 'fg-store', type: 'fg-store', capacity: 1_000_000 }
-    ],
-    equipment: Array.from({ length: 8 }, (_, i) => ({ id: `cutter-${i}`, kind: 'cutter', homeLocation: 'cut-st' }))
-  } as TwinModelDef
-}
-
-function scenario(ordersPerHour: number): ScenarioDef {
-  return {
-    seed: 9,
-    generators: [
-      {
-        kind: 'inbound-arrival',
-        stimulus: 'arrival',
-        rate: { distribution: 'constant', meanPerHour: ordersPerHour * 4 },
-        content: { skuMix: [{ gtin: RAW_GTIN, weight: 1 }], qtyPerLine: { min: 1, max: 1 } }
-      },
-      {
-        kind: 'workorder',
-        stimulus: 'order',
-        rate: { distribution: 'constant', meanPerHour: ordersPerHour },
-        content: { skuMix: [{ gtin: 'wo', weight: 1 }], qtyPerLine: { min: 1, max: 1 } }
-      }
-    ]
-  } as ScenarioDef
-}
-
-interface Row {
-  items: number
-  entities: number
-  payloads: number
-  /** 물품 하나만 건드렸다고 말했을 때 만드는 payload 수 — 좁히기가 듣는지. */
-  scopedPayloads: number
-  snapshotMs: number
-  /** 매핑 + 시그니처(다섯 번 중 가장 짧은 값). */
-  buildMs: number
-  broadcastMs: number
-  /** 좁힌 창의 매핑 + 시그니처 시간 — 투영은 그대로 남는다(커널 몫). */
-  scopedMs: number
-  /** 만든 payload 목록 — 단정이 「무엇을 만들었나」를 직접 본다(수만으로는 축을 구별하지 못한다). */
-  fullDeltas: any[]
-  scopedDeltas: any[]
-}
-
-/** 한 규모에서 **브로드캐스팅 한 번**의 세 축을 잰다. 상태는 미리 쌓아 두고, 재는 것은 브로드캐스팅뿐이다. */
-function measure(ticks: number, ordersPerHour: number): Row {
-  const k: any = new MesKernel('bench', undefined, SPEC)
-  k.onEvent((_e: CanonicalEnvelope) => {})
-  k.loadTwinModel(board())
-  k.scenario.load(scenario(ordersPerHour))
-  k.scenario.start()
-  for (let i = 0; i < ticks; i++) k.tick(1000)
-
-  /* ① 상태 투영 — 자리·물품·자원·작업·오더를 새 객체로 만든다. */
-  const t0 = performance.now()
-  const st = k.getSnapshot()
-  const t1 = performance.now()
-  /*
-   * ②③ payload 만들기 + 시그니처 — **다섯 번 재 가장 짧은 값을 쓴다.** 한 번만 재면 그 순간의 GC 가
-   * 값에 들어가, 좁힌 창이 전부 만든 창보다 오래 걸린 것처럼 보이는 일이 실제로 있었다.
-   */
-  const pass = (scope?: { items: ReadonlySet<string> }) => {
-    let best = Infinity
-    let built: any[] = []
-    let chars = 0
-    for (let i = 0; i < 5; i++) {
-      const a = performance.now()
-      built = buildEntityDeltas(st, 'bench', scope)
-      chars = 0
-      for (const d of built) chars += JSON.stringify(d.data).length
-      best = Math.min(best, performance.now() - a)
-    }
-    return { built, chars, ms: Math.round(best * 10) / 10 }
-  }
-
-  const fullPass = pass()
-  const deltas = fullPass.built
-  const chars = fullPass.chars
-
-  const entities =
-    st.locations.length + st.items.length + st.equipment.length + (st.assets?.length ?? 0) + (st.persons?.length ?? 0) + st.tasks.length + st.orders.length
-
-  /* ④ 좁힌 창 — 물품 하나만 건드렸다고 말한 경우. 같은 상태로 재야 비교가 성립한다. */
-  const one = new Set<string>([st.items[0]?.epc].filter(Boolean) as string[])
-  const scopedPass = pass({ items: one })
-  const scoped = scopedPass.built
-
-  assert.ok(chars > 0 && scopedPass.chars > 0, '문자열을 만들지 않았다면 측정이 성립하지 않는다')
-  const ms = (a: number, b: number) => Math.round((b - a) * 10) / 10
-  return {
-    items: st.items.length,
-    entities,
-    payloads: deltas.length,
-    scopedPayloads: scoped.length,
-    snapshotMs: ms(t0, t1),
-    buildMs: fullPass.ms,
-    broadcastMs: Math.round((ms(t0, t1) + fullPass.ms) * 10) / 10,
-    scopedMs: scopedPass.ms,
-    fullDeltas: deltas,
-    scopedDeltas: scoped
-  }
-}
-
-test('브로드캐스팅 한 번의 비용 — 좁힌 창은 건드린 물품만 만든다', () => {
-  /* 예열은 가장 큰 규모로 한 번 버린다 — 작은 규모부터 재면 뒤 측정이 앞의 JIT 이득을 본다. */
-  measure(600, 3600)
-
-  const rows = [measure(600, 60), measure(600, 480), measure(600, 3600)]
-
-  console.log('[브로드캐스팅 한 번의 비용 · MES 선언본]')
-  for (const r of rows) {
-    console.log(
-      `  물품 ${String(r.items).padStart(5)} · 엔티티 ${String(r.entities).padStart(5)} — payload ${String(r.payloads).padStart(5)}개 · ` +
-        `투영 ${String(r.snapshotMs).padStart(6)}ms · 만들기 ${String(r.buildMs).padStart(6)}ms · 합 ${r.broadcastMs}ms` +
-        `  ▸ 좁힌 창: payload ${String(r.scopedPayloads).padStart(4)}개 · ${r.scopedMs}ms`
-    )
-  }
-
-  /* 측정이 성립했는지 — 규모가 실제로 커져야 비교에 뜻이 있다. */
-  assert.ok(rows[0].items > 0, '물품이 쌓여야 한다')
-  assert.ok(rows[rows.length - 1].items > rows[0].items * 3, '규모가 실제로 커져야 한다')
-
-  /*
-   * ── 고친 뒤의 단정 (2026-08-21) ──────────────────────────────────────────
-   * 전부 만드는 창은 여전히 엔티티 수에 비례한다 — 그 창은 그물이고 주기마다 한 번뿐이다(§그물).
-   *
-   * **좁힌 창이 만드는 물품 payload 는 말한 것 하나뿐이다.** 이것이 시간과 무관한 단정이다. 기울기로
-   * 재지 않는 이유는 이 픽스처가 물품과 함께 오더·작업도 늘리기 때문이다 — 그 축은 좁히지 않으므로
-   * (자리 점유·집약과 같은 이유) 기울기에는 남의 몫이 섞인다.
-   *
-   * 실 현장의 비율은 물품 쪽이 훨씬 무겁다(hatio-us: 물품 2,805 · 오더 192 · 작업 221). 이 픽스처는
-   * 오더를 과하게 실은 쪽이므로, 여기서 보이는 절감은 **실 현장보다 작다.**
-   */
-  const last = rows[rows.length - 1]
-  const itemPayloads = (ds: any[]) => ds.filter(d => d?.data?.entity === 'item').length
-  assert.equal(itemPayloads(last.fullDeltas), last.items, '전부 만드는 창은 물품 전부를 만든다')
-  assert.equal(itemPayloads(last.scopedDeltas), 1, '좁힌 창은 건드린 물품 하나만 만들어야 한다')
-  /* 집약은 좁히지 않는다 — 목록 전체가 한 payload 라서 한 물품이 바뀌면 통째로 새로 만든다. */
-  const aggregates = (ds: any[]) => ds.filter(d => String(d.tag).startsWith('__')).length
-  assert.equal(aggregates(last.scopedDeltas), aggregates(last.fullDeltas), '집약 뷰는 좁힌 창에서도 그대로 나간다')
-})

package/test/broadcast-period.test.ts

@@ -1,58 +0,0 @@
-/*
- * 브로드캐스팅 주기는 **재 본 비용에 맞춘다** (2026-08-21).
- *
- * 한 번의 브로드캐스팅은 상태 크기에 비례한다(실측: 물품 2,400 개 트윈 하나가 4.5ms). 트윈이 스무 개면
- * 200ms 주기에서 90ms 가 브로드캐스팅이고, 그 시간에는 HTTP 도 구독도 서지 못한다. 그래서 브로드캐스팅이 주기의
- * 일정 몫을 넘게 쓰면 주기를 늘리고, 여유가 생기면 되돌린다.
- *
- * 지키는 것:
- *  ① 무거우면 늘린다 — 상한까지만.
- *  ② 가벼워지면 되돌린다 — 원래 주기 아래로는 내려가지 않는다.
- *  ③ 경계에서 늘리고 줄이기를 반복하지 않는다(문턱이 둘이다).
- *  ④ **늘렸다는 사실을 센다** — 알리지 않고 늦추면 사람은 화면이 낡은 이유를 알 수 없다.
- */
-import { test, beforeEach } from 'node:test'
-import assert from 'node:assert/strict'
-import { createRequire } from 'node:module'
-
-const req = createRequire(import.meta.url)
-const { TwinEngine } = req('../dist-server/engine/twin-engine.js')
-
-/** 주기 조정만 부른다 — 실제 브로드캐스팅(pubsub·DB)은 이 판정과 무관하다. */
-const adjust = (flushMs: number) => (TwinEngine as any).adjustBroadcastPeriod(flushMs)
-
-beforeEach(() => {
-  TwinEngine.broadcastPeriodMs = TwinEngine.BROADCAST_COALESCE_MS
-  TwinEngine.broadcastBackoffs = 0
-})
-
-test('브로드캐스팅이 주기의 몫을 넘게 쓰면 주기를 늘린다 — 상한까지만', () => {
-  const base = TwinEngine.BROADCAST_COALESCE_MS
-  adjust(base) // 주기를 통째로 쓴 셈
-  assert.equal(TwinEngine.broadcastPeriodMs, base * 2)
-
-  for (let i = 0; i < 10; i++) adjust(TwinEngine.broadcastPeriodMs)
-  assert.equal(TwinEngine.broadcastPeriodMs, TwinEngine.BROADCAST_MAX_COALESCE_MS, '상한 위로는 올라가지 않는다')
-})
-
-test('늘렸다는 사실을 센다 — 알리지 않고 늦추지 않는다', () => {
-  adjust(TwinEngine.BROADCAST_COALESCE_MS)
-  assert.equal(TwinEngine.broadcastBackoffs, 1)
-})
-
-test('가벼워지면 되돌린다 — 원래 주기 아래로는 내려가지 않는다', () => {
-  adjust(TwinEngine.BROADCAST_COALESCE_MS) // 200 → 400
-  assert.ok(TwinEngine.broadcastPeriodMs > TwinEngine.BROADCAST_COALESCE_MS)
-
-  for (let i = 0; i < 10; i++) adjust(0.5)
-  assert.equal(TwinEngine.broadcastPeriodMs, TwinEngine.BROADCAST_COALESCE_MS)
-})
-
-test('경계에서 늘리고 줄이기를 반복하지 않는다 — 문턱이 둘이다', () => {
-  const base = TwinEngine.BROADCAST_COALESCE_MS
-  /* 늘리는 문턱(몫)과 되돌리는 문턱(몫의 절반) 사이의 값 — 어느 쪽도 아니어야 한다. */
-  const between = base * TwinEngine.BROADCAST_LOAD_RATIO * 0.75
-  for (let i = 0; i < 5; i++) adjust(between)
-  assert.equal(TwinEngine.broadcastPeriodMs, base, '문턱 사이의 값은 주기를 바꾸지 않는다')
-  assert.equal(TwinEngine.broadcastBackoffs, 0)
-})

package/test/broadcast-queue-overflow.test.ts

@@ -1,244 +0,0 @@
-/*
- * ★ 브로드캐스팅이 서버를 죽였다 — 그 기전을 실제 라이브러리로 재고, 우리 코드가 그것을 넘기지 않는지 본다.
- *
- * ── 무엇이 났나 (2026-08-27 10:24 · 실측) ───────────────────────────────────
- * `RepeaterOverflowError: No more than 1024 pending calls to push are allowed on a single repeater.`
- * 가 브로드캐스팅 타이머 안에서 나서 프로세스가 내려갔다. 같은 예외로 2026-08-14 에도 죽었다.
- *
- * ── 기전 ────────────────────────────────────────────────────────────────────
- * 구독의 대기열에는 버퍼가 없다. `pubsub.subscribe` 가 `new Repeater(fn)` 을 버퍼 인자 없이 만든다.
- * 그래서 발행하는 순간에 「다음 값을 달라」는 요청이 이미 걸려 있어야 바로 전달되고, 아니면 대기열에
- * 쌓인다. 상한은 1024 이고 넘으면 예외가 난다.
- *
- * 값을 꺼내는 쪽은 비동기다. 그래서 **동기 반복문이 도는 중에는 한 건도 꺼내지 못한다.** 반복문으로
- * N 건을 발행하면 첫 건만 전달되고 나머지 N−1 건이 전부 쌓인다. 브라우저가 아무리 빨라도 넘는다 —
- * 속도 문제가 아니라 꺼낼 틈을 주지 않는 것이 원인이다.
- *
- * ── 왜 try/catch 로 못 막나 ─────────────────────────────────────────────────
- * 2026-08-14 에 `publishGuarded` 가 `pubsub.publish` 를 try/catch 로 감쌌고, 커밋 제목이 「방송이
- * 호스트를 죽이지 못하게」였다. 그것이 무력하다. 예외는 `EventTarget` 이 부른 리스너 안에서 나고,
- * 런타임은 리스너 예외를 호출자에게 주지 않고 uncaughtException 으로 보낸다. 이 테스트가 그것을
- * 값으로 못 박는다 — 그때 검증하지 않아서 3주 동안 막힌 줄 알고 있었다.
- *
- * ── 왜 오늘 났나 ────────────────────────────────────────────────────────────
- * 오늘 아침 chef 커넥터가 묻는 간격을 5초에서 30초로 올렸다(상대 서버 부담을 줄이려고). 요청 횟수는
- * 줄지만 한 번에 오는 양이 6배가 된다. 초당 130건이 들어오는 원본에서 한 묶음이 3,900건이 되고, 그
- * 묶음이 한 창에 몰려 반복문 하나가 1024 를 넘겼다.
- */
-import { test } from 'node:test'
-import assert from 'node:assert/strict'
-import { readFileSync } from 'node:fs'
-import { join } from 'node:path'
-import { spawnSync } from 'node:child_process'
-
-const ENGINE = join(import.meta.dirname, '..', 'server', 'engine', 'twin-engine.ts')
-const src = readFileSync(ENGINE, 'utf8')
-
-/** 저장소 뿌리 — 자식이 `graphql-yoga` 를 찾을 수 있어야 한다. */
-const REPO = join(import.meta.dirname, '..', '..', '..')
-
-/**
- * 발행을 **자식 프로세스**에서 한다 — 「프로세스가 죽는다」를 종료 코드로 확인하려면 그래야 한다.
- *
- * 같은 프로세스에서 재면 예외가 테스트 러너에 잡혀 이 테스트의 실패로 보고된다. 그것도 사실이지만
- * 확인하려는 것은 「감싸도 못 막고 프로세스가 내려간다」이므로 자식의 종료 코드로 판정한다.
- */
-function runChild(
-  count: number,
-  opts: { consume: boolean; chunk?: number; subscribers?: number; watchAll?: boolean }
-) {
-  const subscribers = opts.subscribers ?? 1
-  const code = `
-    import { createPubSub, pipe, filter } from 'graphql-yoga'
-    const pubsub = createPubSub()
-    const watchAll = ${!!opts.watchAll}
-    let pulled = 0, ordered = true, lastSeen = -1
-    if (${opts.consume}) {
-      for (let s = 0; s < ${subscribers}; s++) {
-        const stream = pipe(pubsub.subscribe('data'), filter(p => watchAll || p.tag === 'watched'))
-        ;(async () => {
-          for await (const p of stream) {
-            /* 순서 확인은 첫 구독만 한다 — 여럿이 세면 서로의 값이 섞인다. */
-            if (s === 0) {
-              pulled++
-              if (watchAll) {
-                if (p.i !== lastSeen + 1) ordered = false
-                lastSeen = p.i
-              }
-            }
-          }
-        })().catch(() => {})
-      }
-      /* 소비자들이 첫 요청을 걸 틈을 준다 — 이것이 없으면 리스너조차 등록되지 않는다(지연 구독). */
-      await new Promise(r => setImmediate(r))
-    }
-    let thrownToCaller = 0, sinceYield = 0
-    for (let i = 0; i < ${count}; i++) {
-      try { pubsub.publish('data', { tag: (watchAll || i === 0) ? 'watched' : 'other-' + i, i }) }
-      catch { thrownToCaller++ }
-      const chunk = ${opts.chunk ?? 0}
-      if (chunk && ++sinceYield >= chunk) { sinceYield = 0; await new Promise(r => setImmediate(r)) }
-    }
-    /* 남은 것을 다 꺼낼 틈을 준다 — 여기서 짧게 끊으면 「빠졌다」로 오판한다. */
-    for (let k = 0; k < 50; k++) await new Promise(r => setImmediate(r))
-    await new Promise(r => setTimeout(r, 100))
-    console.log(JSON.stringify({ thrownToCaller, pulled, ordered }))
-  `
-  const r = spawnSync(process.execPath, ['--input-type=module', '-e', code], {
-    cwd: REPO,
-    encoding: 'utf8'
-  })
-  const line = (r.stdout ?? '').trim().split('\n').filter(Boolean).pop()
-  return {
-    status: r.status,
-    overflowed: /No more than 1024 pending calls to push/.test(r.stderr ?? ''),
-    result: line ? (JSON.parse(line) as { thrownToCaller: number; pulled: number; ordered: boolean }) : null
-  }
-}
-
-test('★ 구독자가 있고 한 차례에 1024건을 넘게 발행하면 프로세스가 죽는다 — 브라우저 속도와 무관하다', () => {
-  const r = runChild(2000, { consume: true })
-  assert.ok(r.overflowed, '대기열이 넘쳐 예외가 나야 한다(이것이 서버를 죽인 그 예외다)')
-  assert.notEqual(r.status, 0, '그 예외로 프로세스가 내려간다')
-})
-
-test('★ 그 예외는 publish() 를 감싼 try/catch 로 잡히지 않는다 — 08-14 의 가드가 무력한 이유', () => {
-  const r = runChild(2000, { consume: true })
-  assert.equal(r.result, null, '완주하지 못한다 — 결과를 낼 자리에 닿지 못한다')
-  assert.ok(r.overflowed, '예외는 감싼 곳이 아니라 uncaughtException 으로 간다')
-})
-
-test('★ 상한마다 루프를 비워 주면 넘지 않는다 — 이것이 고친 방법이다', () => {
-  const r = runChild(5000, { consume: true, chunk: 200 })
-  assert.equal(r.status, 0, '청크마다 양보하면 프로세스가 살아 있다')
-  assert.equal(r.overflowed, false, '대기열이 넘지 않는다')
-  assert.ok((r.result?.pulled ?? 0) > 0, '소비자가 실제로 꺼내 간다')
-})
-
-test('★ 동기 반복문 중에는 소비자가 꺼내지 못한다 — 속도가 아니라 틈이 없는 것이 원인이다', () => {
-  /* 1024 아래로 두어 죽지 않게 하고, 그 사이에 몇 건이 꺼내졌는지 본다. */
-  const r = runChild(1000, { consume: true })
-  assert.equal(r.status, 0)
-  assert.ok((r.result?.pulled ?? -1) <= 2, `꺼낸 것이 ${r.result?.pulled}건뿐이다 — 1000건을 발행하는 동안`)
-})
-
-test('구독자가 없으면 아무것도 쌓이지 않는다 — 리스너가 없다', () => {
-  const r = runChild(2000, { consume: false })
-  assert.equal(r.status, 0, '들을 사람이 없으면 대기열도 없다')
-  assert.equal(r.overflowed, false)
-})
-
-
-
-
-
-
-test('★ 엔진의 발행 반복문이 상한마다 루프를 비워 준다', () => {
-  const at = src.indexOf('static async publishEntityData')
-  assert.ok(at > 0, 'publishEntityData 가 async 여야 한다 — 양보할 수 없으면 상한을 지킬 수 없다')
-  const body = src.slice(at, at + 6000)
-  assert.match(body, /PUBLISH_CHUNK/, '한 차례의 상한에 이름이 있어야 한다')
-  assert.match(
-    body,
-    /sinceYield \+= 0|\+\+sinceYield >= this\.PUBLISH_CHUNK[\s\S]{0,120}?setImmediate/,
-    '상한에 닿으면 루프를 비워 줘야 한다'
-  )
-  /* 상한은 1024 보다 넉넉히 작아야 한다 — 한 청크를 다 꺼내지 못해도 여유가 남게. */
-  const cap = Number(/static PUBLISH_CHUNK = ([0-9_]+)/.exec(src)?.[1]?.replace(/_/g, ''))
-  assert.ok(cap > 0 && cap <= 512, `상한이 ${cap} 이다 — 1024 의 절반 아래여야 한다`)
-})
-
-test('★ 발행을 중간에 그만두지 않는다 — 그만두면 그 태그가 낡은 값으로 남는다', () => {
-  const at = src.indexOf('static async publishEntityData')
-  const body = src.slice(at, at + 6000)
-  /* 상한에 닿았을 때 `break`·`return` 으로 빠지면 남은 태그는 이 창에서 발행되지 않는다. */
-  assert.doesNotMatch(body, />= this\.PUBLISH_CHUNK[\s\S]{0,80}?(break|return)/, '상한에서 빠져나가지 않는다')
-})
-
-test('★ 한 창이 겹쳐 돌지 않는다 — 같은 태그가 두 순서로 나가지 않게', () => {
-  const at = src.indexOf('static flushLiveBroadcasts')
-  assert.ok(at > 0, 'flushLiveBroadcasts 가 있어야 한다')
-  const body = src.slice(at, at + 1200)
-  assert.match(body, /if \(this\.flushInFlight\)/, '앞 창이 돌고 있으면 들어가지 않는다')
-  assert.match(body, /flushOverruns\+\+/, '겹친 횟수를 센다 — 알리지 않고 넘기지 않는다')
-  /* 발행을 기다려야 청크 사이의 양보가 뜻을 갖는다. */
-  assert.match(src, /await this\.publishEntityData\(inst\)/, '창이 발행을 기다린다')
-})
-
-test('★ 발행 건수를 남긴다 — 다음에 이 판단을 추측으로 하지 않게', () => {
-  const at = src.indexOf('static async publishEntityData')
-  const body = src.slice(at, at + 6000)
-  assert.match(body, /publishedTotal/, '누적 발행 건수를 든다')
-  assert.match(body, /건 발행/, '상한을 넘긴 창은 건수를 로그에 남긴다')
-})
-
-/*
- * ── 여기서부터: 상한 근처와 그 너머를 더 넓게 잰다 ────────────────────────────
- *
- * 위 테스트가 「1024 를 넘으면 죽고, 200마다 양보하면 산다」를 못 박았다. 그런데 실제 창은 18,426건이고
- * 구독은 하나가 아니다(`board-provider` 가 컴포넌트마다 하나씩 연다). 그 조건에서도 서는지 잰다.
- */
-
-test('★ 실제 규모에서 선다 — 한 창 18,426건 · 청크 200', () => {
-  /* 2026-08-27 11:11 실측값 그대로. 이 수가 상한의 18배라서 청크 없이는 반드시 죽는다. */
-  const r = runChild(18426, { consume: true, chunk: 200 })
-  assert.equal(r.status, 0, '실측 규모에서 프로세스가 살아 있어야 한다')
-  assert.equal(r.overflowed, false)
-})
-
-test('★ 구독이 여러 개여도 선다 — 화면은 컴포넌트마다 구독을 하나씩 연다', () => {
-  /*
-   * 지금 구조에서는 발행 하나가 **구독마다** 큐를 지나간다. 그래서 구독 수가 늘면 밀리는 총량도
-   * 그만큼 늘고, 양보 한 번에 소비자 여럿이 나눠 꺼내야 한다. 그 조건에서도 상한을 넘지 않아야 한다.
-   */
-  const r = runChild(5000, { consume: true, chunk: 200, subscribers: 20 })
-  assert.equal(r.status, 0, '구독 20개에서도 살아 있어야 한다')
-  assert.equal(r.overflowed, false)
-})
-
-test('★ 한 실행 차례의 경계는 1,025건이다 — 재서 확인한 값이다', () => {
-  /*
-   * ── 측정값 (2026-08-27) ─────────────────────────────────────────────────────
-   *   청크 1,024 · 1,025   산다
-   *   청크 1,026           죽는다
-   *   구독 수(1·5·20)      경계를 바꾸지 않는다 — 구독마다 자기 대기열이 따로다
-   *
-   * 1,025 까지 사는 이유: 청크가 시작될 때 소비자의 요청이 하나 걸려 있어 첫 건은 바로 전달되고,
-   * 그 뒤 1,024건이 쌓인 상태에서 검사를 통과한다. 1,026번째에 상한에 닿는다.
-   *
-   * 처음에 「청크가 상한과 같으면 위험하다」고 단정했는데 틀렸다. 재서 고쳤다.
-   */
-  assert.equal(runChild(5000, { consume: true, chunk: 1025 }).status, 0, '1,025 는 산다')
-  const over = runChild(5000, { consume: true, chunk: 1026 })
-  assert.ok(over.overflowed, '1,026 은 넘친다')
-  assert.notEqual(over.status, 0, '그리고 프로세스가 내려간다')
-})
-
-test('★ 그래도 여유를 둔다 — 같은 실행 차례에 다른 발행처가 함께 넣는다', () => {
-  /*
-   * 경계가 1,025 라도 그것에 붙여 쓰지 않는다. 이 채널에 발행하는 곳이 우리만이 아니다 —
-   * `integration-base` 의 상태 등록 변경과 `shell` 의 진행률 보고가 같은 채널을 쓴다. 그것들이
-   * 같은 실행 차례에 끼어들면 우리 몫에 더해진다.
-   *
-   * 엔진의 값이 200 이다(경계의 1/5). 이 테스트는 그 값이 여유 있는 쪽에 있는지만 본다.
-   */
-  const cap = Number(/static PUBLISH_CHUNK = ([0-9_]+)/.exec(src)?.[1]?.replace(/_/g, ''))
-  assert.ok(cap > 0 && cap <= 512, `상한이 ${cap} 이다 — 경계(1,025)의 절반 아래여야 한다`)
-})
-
-test('청크가 넉넉히 작으면 구독이 늘어도 여유가 남는다 — 엔진의 200이 그 자리에 있다', () => {
-  const r = runChild(5000, { consume: true, chunk: 200, subscribers: 50 })
-  assert.equal(r.status, 0)
-  assert.equal(r.overflowed, false)
-})
-
-test('★ 발행한 것이 하나도 빠지지 않는다 — 청크로 나눈 것이 값을 잃지 않았음을 확인한다', () => {
-  /*
-   * 청크는 시점만 나눈다. 건수·내용·순서가 그대로여야 한다. 그것을 확인하지 않으면 「죽지 않는다」만
-   * 알고 「제대로 전달된다」는 모르는 상태가 된다.
-   */
-  const r = runChild(3000, { consume: true, chunk: 200, watchAll: true })
-  assert.equal(r.status, 0)
-  assert.equal(r.result?.pulled, 3000, '발행한 3,000건이 그대로 도착해야 한다')
-  assert.equal(r.result?.ordered, true, '순서도 그대로여야 한다')
-})