import type { GatewayMethodDescriptor } from './method-catalog-shared.js';
/**
 * Calendar operator methods, event read/write and iCalendar import/export
 * through the standard operator method protocol.
 *
 * These are SERVED. `registerCalendarGatewayMethods`
 * (control-plane/routes/calendar.ts) attaches an in-process handler to each id
 * over a `CalendarGatewayService`, the daemon composition supplies the
 * Google-backed implementation
 * (platform/google/gateway-calendar-service.ts), and
 * `GATEWAY_REST_ROUTES` maps each advertised http path to the same handler, so
 * the REST path and the methodId-invoke endpoint resolve identically.
 *
 * They did not used to be. For a long time none of these five http paths was
 * served by anything: there was no /api/calendar surface at any prefix, no
 * calendar-routes.ts, and no handler. They carried `invokable: false` so the
 * published contract and the live method-dispatch path both said "cataloged,
 * not callable" rather than letting a caller discover the 404 the hard way.
 * The reason was never the routing, it was that the only implementation
 * lived inside one product, so the daemon had nothing to call, and scheduled
 * work, triggers and channel-driven work could not touch a calendar at all.
 * Hoisting the connector into the SDK is what made serving them possible.
 *
 * The route-reconcile regression gate (method-catalog-route-reconcile.ts,
 * exercised in test/capability-route-reconcile.test.ts) keeps the two halves
 * honest in both directions: a descriptor that advertises an http path no
 * route serves reddens it, and so does one that quietly reappears unmarked.
 */
export declare const builtinGatewayCalendarMethodDescriptors: readonly GatewayMethodDescriptor[];
//# sourceMappingURL=method-catalog-calendar.d.ts.map