export declare class TwinReferenceResolver {
    /** 등록된 레퍼런스 소스 목록(요약 + 이미 인제스트됐는지). */
    referenceSources(context: ResolverContext): Promise<any[]>;
    /** 소스를 인제스트 → 공간 + 인스턴스 생성(provision). start 면 기동까지. */
    importFromReference(source: string, restartPolicy: string, context: ResolverContext, start?: boolean): Promise<any>;
    /**
     * **원본에서 다시 읽는다** — 이 트윈의 구조를 지금의 원본 모습으로 갱신한다.
     *
     * ── 왜 진입점이 하나여야 하나 ──────────────────────────────────────────────
     * 지금까지 다시 읽기는 **만드는 경로에 얹혀 있었다**(`importFromReference`·`createFromTemplate`).
     * 그래서 이미 있는 트윈을 갱신하려면 만들 때 무엇을 골랐는지 사람이 기억해 같은 화면을 다시
     * 거쳐야 했고, 템플릿으로 세운 트윈은 노브를 어디에도 안 남겨서 **아예 갱신할 방법이 없었다.**
     * 원천이 무엇이든 트윈 자신이 기억하게 하고(`TwinInstance.origin`), 여기 한 곳에서 그것을 따른다.
     *
     * ── 무엇이 일어나나 ────────────────────────────────────────────────────────
     * 원본에서 마스터를 다시 얻어 인제스트에 그대로 태운다. 그다음은 인제스트가 아는 일이다 —
     * 구조가 달라졌으면 새 리비전이 남고, 구조 행이 다시 그려지고, **실행 중인 미러는 멈추지 않고
     * 전환한다.** 실행 중인 시뮬레이션은 거절된다(조건이 바뀐 실험은 다른 실험이다).
     *
     * ── 못 할 때는 못 한다고 한다 ──────────────────────────────────────────────
     * `origin` 이 없는 트윈(이 자리가 생기기 전에 만들어진 것)은 다시 읽을 수 없다. 짐작으로
     * 템플릿을 고르거나 첫 레퍼런스를 집지 않는다 — 엉뚱한 원본으로 현장을 덮는 것이 훨씬 나쁘다.
     */
    /**
     * **그 번호들이 무엇이었나** — 구멍을 만났을 때 원본에 묻는다.
     *
     * `fillTwinScope` 가 「418 다음이 420」이라고 멈추면, 그 419 가 무엇이었는지 알아야 다음을
     * 정할 수 있다. 그 길이 없어서 사람이 원본 DB 를 손으로 뒤졌다.
     *
     * **판정하지 않는다.** 원본이 아는 것을 그대로 낸다 — `lost` 는 「번호는 나갔는데 행이 없다」이지
     * 「포기해도 된다」가 아니다. 그 판단은 되돌릴 수 없어서(커서가 지나가면 끝이다) 사람의 몫이다.
     */
    twinSeqReport(instanceId: string, scope: string, from: number, to: number, context: ResolverContext): Promise<any>;
    /**
     * **빠진 구간을 다시 받는다** — 훅은 반드시 놓칩니다: 우리가 내려가 있을 때, 그쪽이 못 보냈을 때.
     *
     * ── 왜 문이 필요한가 ──────────────────────────────────────────────────────
     * 번호가 비면 `takeInSequence` 가 알아챕니다. 그런데 **알아챈 뒤 그 사이를 채우는 길이 없었습니다.**
     * `fillSince` 는 2026-08-31 부터 있었고 부르는 곳이 0곳이었습니다.
     *
     * 실제로 plant 아웃박스의 1~20 을 잃고 되찾을 방법이 없는 상태를 만났습니다.
     *
     * ── `from` 은 잃은 구간을 되찾을 때만 ──────────────────────────────────────
     * 주지 않으면 커서부터 이어 받습니다. 주면 **그 번호부터 다시 묻습니다** — 이미 들어간 것은 유입
     * 경계가 되풀이로 거르므로 두 번 앉지 않습니다.
     *
     * 저장된 커서를 되돌리지 않습니다. `fillSince` 는 번호 검사를 지난 만큼만 적으므로, 되찾은 뒤
     * 커서가 원래 자리보다 앞서지 않습니다.
     */
    fillTwinScope(instanceId: string, scope: string, context: ResolverContext, from?: number, maxPages?: number): Promise<any>;
    resyncTwin(instanceId: string, context: ResolverContext): Promise<any>;
    /** 기억해 둔 원천에서 마스터를 다시 얻는다 — 어댑터든 템플릿이든 이 한 곳에서 갈린다. */
    private masterFromOrigin;
    /** 등록된 트윈 템플릿(파라미터화 아키타입) 목록 — 노브 스키마 포함(클라이언트 폼용). */
    twinTemplates(_context: ResolverContext): Promise<any[]>;
    /** 템플릿 + 노브 → 합성 마스터 → 인제스트(+기동+시나리오). 레퍼런스 import 와 같은 경로, 원천만 합성. */
    createFromTemplate(templateId: string, params: any, restartPolicy: string, context: ResolverContext, start?: boolean, spaceId?: string): Promise<any>;
    twinReferences(context: ResolverContext): Promise<any[]>;
    referenceAdapterTypes(): string[];
    /**
     * 인티그레이션 그룹핑 (reference-management §2.3·D11) — 산출물을 커넥터 타입 ▸ Connection ▸ 인스턴스 2단으로.
     * 트윈-네이티브 온톨로지(integration 무의존): TwinReference 가 그룹핑 노드(source=connectionName),
     * scopeSpec.connectorType 로 상위 분류. producedCount 는 라이브 인스턴스로 대조(지워진 트윈 제외).
     */
    twinConnections(context: ResolverContext): Promise<any[]>;
    /** 한 Connection 그룹 노드 상세 — 그 아래 생성된 트윈 인스턴스(라이브 대조·상태·기동여부). */
    twinConnection(source: string, context: ResolverContext): Promise<any | null>;
    /** 단건 상세(뷰/편집) — connectionConfig 포함, 어댑터 스키마의 secret 필드는 마스킹(있으면 '••••••'). */
    twinReference(source: string, context: ResolverContext): Promise<any | null>;
    referenceAdapters(): any[];
    saveTwinReference(source: string, patch: any, context: ResolverContext): Promise<any>;
    /** 연결 해제 — removeTwins=true 면 이 레퍼런스가 만든 트윈(provenance)도 함께 제거(라이프사이클 연쇄). 기본은 트윈 보존(분리). */
    deleteTwinReference(source: string, context: ResolverContext, removeTwins?: boolean): Promise<boolean>;
    testReferenceConnection(source: string, context: ResolverContext): Promise<any>;
    /**
     * 어댑터 기반 인제스트 — discoverSites → 사이트별 fetchMaster → ingestMaster (fan-out, §2.2·§4.2).
     * P1 은 대개 N=1(virtual/단일). start 면 각 인스턴스 기동. 라이브 피드·mode 는 face2-inbound-live 소유.
     */
    /** 레퍼런스가 노출하는 사이트/공장 발견 — 트윈 생성 시 "어느 공장" 선택용(§2.2). */
    discoverReferenceSites(source: string, context: ResolverContext): Promise<any>;
    /**
     * 트윈 생성 — 레퍼런스에서 사이트 발견 → (siteIds 있으면 그 공장만) → fetchMaster → provision. 사이트별 resilient.
     * 여러 공장을 관할하는 소스는 siteIds 로 "어느 공장"을 골라 생성(1:N, §2.1·§2.2).
     *
     * ── 현장 선택이 이 경로에도 있다 (2026-08-13) ────────────────────────────
     * 한 현실을 여러 렌즈가 비춘다(WMS·MES·YMS). 그런데 **그 선택이 템플릿 경로에만** 있어서
     * (`createFromTemplate(spaceId)`), 실 시스템에서 가져온 트윈은 어댑터가 파생한 공간 id 가 우연히
     * 일치할 때만 한 현장에 모였다 — 사람이 "이 MES 와 같은 현장에 넣어라" 를 말할 방법이 없었다.
     * 데이터로는 가능한 일이 저작으로는 불가능한, `ingest-space` 가 이미 지적한 그 비대칭이다.
     *
     * 판정은 그 순수 모듈이 갖는다: 없는 공간은 거절(`resolveIngestSpace`), 사이트 여럿을 한 공간에
     * 넣는 것도 거절(`refuseImportSpace`) — 서로 다른 현장이 알리지 않고 합쳐지는 것을 막는다.
     */
    importTwinReference(source: string, context: ResolverContext, siteIds?: string[], start?: boolean, live?: boolean, spaceId?: string, restartPolicy?: string): Promise<any>;
}