/*!
 * Copyright (c) 2026 Interop Alliance. All rights reserved.
 */
/**
 * The did:webvh side of `@interop/vh-resource-log`'s controller port: the
 * wallet-core EXTENDED controller view -- the library's generic port plus the
 * per-version credential-inventory accessor the ceremony-tail license reads,
 * plus the library's `admitAppend` admission hook made mandatory -- and the
 * adapter that builds it from an
 * already-verified account log (the `verifyAccountLog` output), answering
 * version lookups from that verified history rather than from any wire
 * fetch. Handing the verifier a view instead of a resolver is what
 * enforces the profile's rule that controller-document material never comes
 * from the channel the log came from; supplying the hook is the obligation
 * the library's port states for any controller document that can list
 * ladder-shaped verification methods -- a bare view does not lack ladder
 * keys, it lacks the ability to recognize them.
 *
 * The hook this adapter supplies runs the ceremony-tail license, which is the
 * USER KEY ROSTER class's rule rather than every log's. One account document
 * governs several logs, so the rule belongs to the log rather than to the
 * document, and it is chosen by the class dispatch beside this file
 * (`logClass.ts`, `controllerForLogClass`), which the log-governed store
 * applies to this view before every read and every append. The adapter keeps
 * producing the licensed view, so a caller that states no class gets the
 * roster rule.
 *
 * The document reading itself is not restated here: the relation resolver,
 * the ladder-VM recognition, and the credential class all come from
 * `document.ts` beside this file, so this view and every other reader of an
 * account document answer identically over the same bytes.
 */
import type { DIDLog } from '@interop/did-method-webvh';
import { type ResourceLogController } from '@interop/vh-resource-log';
import { type LadderRungKeys } from './ladderRungs.js';
/**
 * The credential-inventory view at one controller-log version, consumed by the
 * ceremony-tail license on ladder-signed appends (clause B of the ladder
 * VM's authority clauses). Both members come from the shared
 * account-document readers beside this file (`ladderVmMethods` and
 * `credentialKeyAgreementMethods` in `document.ts`), so the license reads the
 * document exactly as the client listing and the roster's recipient resolver
 * do. `ladderKeys` holds the ladder VMs' signing-key multibases, which is how
 * a verifier tells a ladder-signed proof from an enrolled client's.
 * `inventoryKeys` is S(V), the credential-inventory key set: the
 * credential-class `keyAgreement` methods keyed by their key material,
 * verbatim `Multikey` keys and `MultikeyCommitment` commitments alike, union
 * the ladder VMs. A document entry is inventory-changing iff S(V) differs
 * from S(V-1) in either direction; ordinary client enrollment and revocation
 * are excluded structurally, because a client's `keyAgreement` twin carries
 * the `did:key` controller marker rather than the account DID.
 *
 * Three members serve the license's third shape, which admits a ladder-signed
 * append at a version whose ENROLLED-CLIENT set changed and whose entry a rung
 * of the appending ladder signed. `enrolledClientKeys` is that set, the
 * version's `capabilityInvocation` key multibases -- the census the client
 * listing keys on, and the structural complement of `inventoryKeys`.
 * `entrySignerKeys` names the update keys that signed the version's own entry,
 * which is what tells a ladder-signed enrollment or removal from a
 * client-signed one. `ladderRungKeys` maps each attributed ladder VM to its
 * rung keys as the log itself names them, so the signer test is answered with
 * no ladder seed in hand; a ladder the log does not attribute is absent from
 * the map and its appends refuse (`ladderRungs.ts` states the walk's bounds).
 */
export interface ControllerInventory {
    ladderKeys: Set<string>;
    inventoryKeys: Set<string>;
    enrolledClientKeys: Set<string>;
    entrySignerKeys: Set<string>;
    ladderRungKeys: LadderRungKeys;
}
/**
 * The wallet-core extended controller view: the library's generic port plus
 * the credential-inventory accessor at a given version, which is what
 * evaluating the ceremony-tail license and recognizing a ladder-signed
 * append require (both invisible through the `assertionMethod` accessor
 * alone), plus the library's optional `admitAppend` admission hook made
 * mandatory -- an account did:webvh document can list ladder VMs, so a view
 * over one must answer the admission question (the port's stated
 * obligation), whichever log class's rule that answer comes from. The
 * pre-append license check in the log-governed descriptor store calls
 * `inventoryAt` directly, which is why the accessor stays on the type
 * beside the hook: a verify-time refusal alone would poison the served log
 * for every reader.
 */
export interface WebvhResourceLogController extends ResourceLogController {
    /**
     * Resolves the credential-inventory view at a controller-log version
     * (`undefined`: the current document): the ladder VM key multibases and
     * the inventory set S(V) the ceremony-tail license compares across
     * versions.
     *
     * @param [versionId] {string}
     * @returns {Promise<ControllerInventory>}
     */
    inventoryAt(versionId?: string): Promise<ControllerInventory>;
    admitAppend: NonNullable<ResourceLogController['admitAppend']>;
}
/**
 * Builds the controller view over an already-verified did:webvh account log
 * (the `verifyAccountLog` output -- callers never hand this a log they have
 * not verified against the account pointer). Because every verified entry
 * carries its resolved document in `state`, the per-version `assertionMethod`
 * sets are read straight off those entries in one linear pass over the log
 * rather than replaying resolution once per version. A lookup at a version
 * the log does not carry refuses instead of guessing, and `undefined`
 * answers from the last entry (the current document).
 *
 * The returned view carries the `admitAppend` hook under the user key
 * roster class's rule (`controllerForLogClass` narrows it for another log
 * class): it resolves the inventory at the proof's controller versionId,
 * and where the signing key is a ladder VM there it runs the ceremony-tail
 * license
 * (`assertLadderAppendLicensed`) --
 * so ordinary client-signed appends admit untouched, and a ladder-signed
 * append outside the license refuses with `ResourceLogLicenseError`,
 * propagated with its class intact by the library's verifier.
 *
 * @param options {object}
 * @param options.did {string}   the account's did:webvh, as verified
 * @param options.log {DIDLog}   the verified account log
 * @returns {WebvhResourceLogController}
 */
export declare function webvhResourceLogController({ did, log }: {
    did: string;
    log: DIDLog;
}): WebvhResourceLogController;
//# sourceMappingURL=controller.d.ts.map