@mochabug/adapt-plugin-toolkit/dist/genproto/mochabugapis/adapt/plugins/v1/compound_services_pb.d.ts

The API toolkit to facilitate mochabug adapt plugin development

import type { GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
import type { Message } from "@bufbuild/protobuf";
/**
 * Describes the file mochabugapis/adapt/plugins/v1/compound_services.proto.
 */
export declare const file_mochabugapis_adapt_plugins_v1_compound_services: GenFile;
/**
 * A grouped service definition that references multiple other flat service definitions.
 *
 * ## Architecture: Groups Reference Flat Definitions
 *
 * GroupedDefinition is itself a flat service definition at the Manifest.service_definitions level.
 * It references OTHER flat service definitions by name as a string array.
 *
 * ## Purpose
 *
 * Groups allow plugin authors to bundle related services together. For example:
 * - Production and sandbox environments for the same API
 * - Multiple related API keys
 * - Primary and backup authentication methods
 *
 * ## Example
 *
 * ```protobuf
 * // In Manifest.service_definitions
 * [
 *   { name: "stripe_prod", label: "Stripe Production", oauth2: {...} },
 *   { name: "stripe_sandbox", label: "Stripe Sandbox", oauth2: {...}, optional: true },
 *   {
 *     name: "stripe_envs",
 *     label: "Stripe Environments",
 *     group: {
 *       services: ["stripe_prod", "stripe_sandbox"]
 *     }
 *   }
 * ]
 *
 * // Referenced in system services list
 * system_services: ["stripe_envs"]
 *
 * // Plugin code accesses members with dot notation:
 * "stripe_envs.stripe_prod", "stripe_envs.stripe_sandbox"
 * ```
 *
 * @generated from message mochabugapis.adapt.plugins.v1.GroupedDefinition
 */
export type GroupedDefinition = Message<"mochabugapis.adapt.plugins.v1.GroupedDefinition"> & {
    /**
     * References to other flat service definitions that comprise this group
     *
     * @generated from field: repeated string services = 1;
     */
    services: string[];
};
/**
 * A grouped service definition that references multiple other flat service definitions.
 *
 * ## Architecture: Groups Reference Flat Definitions
 *
 * GroupedDefinition is itself a flat service definition at the Manifest.service_definitions level.
 * It references OTHER flat service definitions by name as a string array.
 *
 * ## Purpose
 *
 * Groups allow plugin authors to bundle related services together. For example:
 * - Production and sandbox environments for the same API
 * - Multiple related API keys
 * - Primary and backup authentication methods
 *
 * ## Example
 *
 * ```protobuf
 * // In Manifest.service_definitions
 * [
 *   { name: "stripe_prod", label: "Stripe Production", oauth2: {...} },
 *   { name: "stripe_sandbox", label: "Stripe Sandbox", oauth2: {...}, optional: true },
 *   {
 *     name: "stripe_envs",
 *     label: "Stripe Environments",
 *     group: {
 *       services: ["stripe_prod", "stripe_sandbox"]
 *     }
 *   }
 * ]
 *
 * // Referenced in system services list
 * system_services: ["stripe_envs"]
 *
 * // Plugin code accesses members with dot notation:
 * "stripe_envs.stripe_prod", "stripe_envs.stripe_sandbox"
 * ```
 *
 * @generated from message mochabugapis.adapt.plugins.v1.GroupedDefinition
 */
export type GroupedDefinitionJson = {
    /**
     * References to other flat service definitions that comprise this group
     *
     * @generated from field: repeated string services = 1;
     */
    services?: string[];
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.GroupedDefinition.
 * Use `create(GroupedDefinitionSchema)` to create a new message.
 */
export declare const GroupedDefinitionSchema: GenMessage<GroupedDefinition, {
    jsonType: GroupedDefinitionJson;
}>;
/**
 * A one-of service definition that allows users to choose from multiple flat service definitions.
 *
 * ## Architecture: One-Of References Flat Definitions
 *
 * OneOfDefinition is itself a flat service definition at the Manifest.service_definitions level.
 * It references OTHER flat service definitions by name.
 *
 * ## Purpose
 *
 * One-of definitions allow plugins to support multiple alternative implementations:
 * - Different payment providers (Stripe, PayPal, Square)
 * - Different authentication methods (OAuth2, API Key, mTLS)
 * - Different deployment environments
 *
 * Users choose ONE option during plugin installation/configuration.
 *
 * ## Example
 *
 * ```protobuf
 * // In Manifest.service_definitions
 * [
 *   { name: "stripe_oauth", label: "Stripe OAuth", oauth2: {...} },
 *   { name: "paypal_oauth", label: "PayPal OAuth", oauth2: {...} },
 *   { name: "square_oauth", label: "Square OAuth", oauth2: {...} },
 *   {
 *     name: "payment_provider",
 *     label: "Payment Provider",
 *     oneof: {
 *       options: {
 *         "stripe_oauth": "Stripe",
 *         "paypal_oauth": "PayPal",
 *         "square_oauth": "Square"
 *       },
 *       default: "stripe_oauth"
 *     }
 *   }
 * ]
 *
 * // Referenced in system services list
 * system_services: ["payment_provider"]
 *
 * // Plugin code accesses using the service name:
 * "payment_provider" (regardless of which provider user chose)
 * ```
 *
 * @generated from message mochabugapis.adapt.plugins.v1.OneOfDefinition
 */
export type OneOfDefinition = Message<"mochabugapis.adapt.plugins.v1.OneOfDefinition"> & {
    /**
     * Map of service definition options users can choose from.
     *
     * Key: Service definition name (from Manifest.service_definitions)
     * Value: Human-friendly label shown to users during selection
     *
     * The map key must reference an existing ServiceDefinition.name.
     * The map value is displayed to users when choosing between options.
     *
     * ## Examples
     *
     * Basic options:
     *   options: {
     *     "stripe_oauth": "Stripe",
     *     "paypal_oauth": "PayPal"
     *   }
     *
     * Descriptive labels:
     *   options: {
     *     "stripe_oauth": "Stripe (recommended for production)",
     *     "paypal_oauth": "PayPal (simpler setup)"
     *   }
     *
     * @generated from field: map<string, string> options = 1;
     */
    options: {
        [key: string]: string;
    };
    /**
     * Optional default selection.
     *
     * If specified, this service definition will be pre-selected in the UI during installation.
     * Users can still choose a different option.
     *
     * The default value MUST match one of the keys in the options map.
     *
     * Use this to:
     * - Suggest the most common choice
     * - Indicate the recommended option
     * - Set a safe default for new users
     *
     * ## Default Behavior: System Settings vs User Settings
     *
     * **System Settings** (Manifest.system_services):
     * - Default selection is automatically applied when the plugin is installed
     * - The service is marked as "configured" if the default option has all required values
     * - Plugin creators define and approve these defaults
     *
     * **User Settings** (Vertex.user_services):
     * - Default selection is a UI hint only and NOT automatically applied
     * - The service is NOT marked as "configured" until the user explicitly submits settings
     * - Users must review and approve the selection, even with a default present
     * - This ensures users actively consent to which option is selected
     *
     * ## Rationale
     *
     * System settings use automatic defaults because the plugin creator (who defines
     * the defaults) is also the one approving them during plugin development.
     *
     * User settings require explicit submission because end users need to review and
     * consciously approve which option is selected and configured.
     *
     * @generated from field: optional string default = 2;
     */
    default?: string;
};
/**
 * A one-of service definition that allows users to choose from multiple flat service definitions.
 *
 * ## Architecture: One-Of References Flat Definitions
 *
 * OneOfDefinition is itself a flat service definition at the Manifest.service_definitions level.
 * It references OTHER flat service definitions by name.
 *
 * ## Purpose
 *
 * One-of definitions allow plugins to support multiple alternative implementations:
 * - Different payment providers (Stripe, PayPal, Square)
 * - Different authentication methods (OAuth2, API Key, mTLS)
 * - Different deployment environments
 *
 * Users choose ONE option during plugin installation/configuration.
 *
 * ## Example
 *
 * ```protobuf
 * // In Manifest.service_definitions
 * [
 *   { name: "stripe_oauth", label: "Stripe OAuth", oauth2: {...} },
 *   { name: "paypal_oauth", label: "PayPal OAuth", oauth2: {...} },
 *   { name: "square_oauth", label: "Square OAuth", oauth2: {...} },
 *   {
 *     name: "payment_provider",
 *     label: "Payment Provider",
 *     oneof: {
 *       options: {
 *         "stripe_oauth": "Stripe",
 *         "paypal_oauth": "PayPal",
 *         "square_oauth": "Square"
 *       },
 *       default: "stripe_oauth"
 *     }
 *   }
 * ]
 *
 * // Referenced in system services list
 * system_services: ["payment_provider"]
 *
 * // Plugin code accesses using the service name:
 * "payment_provider" (regardless of which provider user chose)
 * ```
 *
 * @generated from message mochabugapis.adapt.plugins.v1.OneOfDefinition
 */
export type OneOfDefinitionJson = {
    /**
     * Map of service definition options users can choose from.
     *
     * Key: Service definition name (from Manifest.service_definitions)
     * Value: Human-friendly label shown to users during selection
     *
     * The map key must reference an existing ServiceDefinition.name.
     * The map value is displayed to users when choosing between options.
     *
     * ## Examples
     *
     * Basic options:
     *   options: {
     *     "stripe_oauth": "Stripe",
     *     "paypal_oauth": "PayPal"
     *   }
     *
     * Descriptive labels:
     *   options: {
     *     "stripe_oauth": "Stripe (recommended for production)",
     *     "paypal_oauth": "PayPal (simpler setup)"
     *   }
     *
     * @generated from field: map<string, string> options = 1;
     */
    options?: {
        [key: string]: string;
    };
    /**
     * Optional default selection.
     *
     * If specified, this service definition will be pre-selected in the UI during installation.
     * Users can still choose a different option.
     *
     * The default value MUST match one of the keys in the options map.
     *
     * Use this to:
     * - Suggest the most common choice
     * - Indicate the recommended option
     * - Set a safe default for new users
     *
     * ## Default Behavior: System Settings vs User Settings
     *
     * **System Settings** (Manifest.system_services):
     * - Default selection is automatically applied when the plugin is installed
     * - The service is marked as "configured" if the default option has all required values
     * - Plugin creators define and approve these defaults
     *
     * **User Settings** (Vertex.user_services):
     * - Default selection is a UI hint only and NOT automatically applied
     * - The service is NOT marked as "configured" until the user explicitly submits settings
     * - Users must review and approve the selection, even with a default present
     * - This ensures users actively consent to which option is selected
     *
     * ## Rationale
     *
     * System settings use automatic defaults because the plugin creator (who defines
     * the defaults) is also the one approving them during plugin development.
     *
     * User settings require explicit submission because end users need to review and
     * consciously approve which option is selected and configured.
     *
     * @generated from field: optional string default = 2;
     */
    default?: string;
};
/**
 * Describes the message mochabugapis.adapt.plugins.v1.OneOfDefinition.
 * Use `create(OneOfDefinitionSchema)` to create a new message.
 */
export declare const OneOfDefinitionSchema: GenMessage<OneOfDefinition, {
    jsonType: OneOfDefinitionJson;
}>;
//# sourceMappingURL=compound_services_pb.d.ts.map