@mochabug/adapt-sdk 0.1.1

package/dist/genproto/mochabugapis/adapt/graph/signal_descriptor_pb.d.ts

@@ -0,0 +1,161 @@
+import type { GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
+import type { SignalFormat, SignalFormatJson } from "./signal_format_pb";
+import type { Message } from "@bufbuild/protobuf";
+/**
+ * Describes the file mochabugapis/adapt/graph/signal_descriptor.proto.
+ */
+export declare const file_mochabugapis_adapt_graph_signal_descriptor: GenFile;
+/**
+ * SignalDescriptor defines the complete specification of a signal, including its identity
+ * and data format, without containing the actual signal data.
+ *
+ * A signal descriptor represents what a signal IS - its name, documentation, and the
+ * single, specific format it produces. This is distinct from SignalBinding, which
+ * represents what formats a binding point ACCEPTS.
+ *
+ * @generated from message mochabugapis.adapt.graph.SignalDescriptor
+ */
+export type SignalDescriptor = Message<"mochabugapis.adapt.graph.SignalDescriptor"> & {
+    /**
+     * Identifier for the signal, following ECMAScript identifier naming conventions.
+     * Must be a valid JavaScript/TypeScript identifier to ensure compatibility with
+     * code generation and scripting environments.
+     *
+     * Pattern: Must start with letter, $, or _, followed by letters, digits, $, or _
+     * Length: 1-50 characters
+     *
+     * Examples: "temperature", "user_id", "$internal", "_privateSignal"
+     *
+     * @generated from field: string name = 1;
+     */
+    name: string;
+    /**
+     * Human-readable label for the signal, suitable for display in user interfaces.
+     * Should be brief and descriptive.
+     *
+     * Length: Up to 250 characters
+     *
+     * Examples: "Room Temperature", "User ID", "Processing Status"
+     *
+     * @generated from field: optional string label = 2;
+     */
+    label?: string;
+    /**
+     * Detailed description of the signal's purpose, behavior, and usage.
+     * Should provide context for developers and users.
+     *
+     * Length: Up to 1000 characters
+     *
+     * May include:
+     * - What the signal represents
+     * - When it's emitted
+     * - Expected value ranges or formats
+     * - Usage examples or constraints
+     *
+     * @generated from field: optional string description = 3;
+     */
+    description?: string;
+    /**
+     * Indicates whether this signal must be provided.
+     *
+     * When false or unset: Signal is required and must be present
+     * When true: Signal is optional and may be omitted
+     *
+     * Optional signals provide flexibility in graph construction, allowing
+     * vertices to function with or without certain inputs.
+     *
+     * @generated from field: optional bool optional = 4;
+     */
+    optional?: boolean;
+    /**
+     * List of formats that this signal produces. The signal will produce any signal whose
+     * format matches at least one entry in this list.
+     *
+     * Validation: At least one format must be specified. Maximum 50 formats to prevent
+     * overly complicated signals and ensure reasonable validation performance.
+     *
+     * @generated from field: repeated mochabugapis.adapt.graph.SignalFormat formats = 5;
+     */
+    formats: SignalFormat[];
+};
+/**
+ * SignalDescriptor defines the complete specification of a signal, including its identity
+ * and data format, without containing the actual signal data.
+ *
+ * A signal descriptor represents what a signal IS - its name, documentation, and the
+ * single, specific format it produces. This is distinct from SignalBinding, which
+ * represents what formats a binding point ACCEPTS.
+ *
+ * @generated from message mochabugapis.adapt.graph.SignalDescriptor
+ */
+export type SignalDescriptorJson = {
+    /**
+     * Identifier for the signal, following ECMAScript identifier naming conventions.
+     * Must be a valid JavaScript/TypeScript identifier to ensure compatibility with
+     * code generation and scripting environments.
+     *
+     * Pattern: Must start with letter, $, or _, followed by letters, digits, $, or _
+     * Length: 1-50 characters
+     *
+     * Examples: "temperature", "user_id", "$internal", "_privateSignal"
+     *
+     * @generated from field: string name = 1;
+     */
+    name?: string;
+    /**
+     * Human-readable label for the signal, suitable for display in user interfaces.
+     * Should be brief and descriptive.
+     *
+     * Length: Up to 250 characters
+     *
+     * Examples: "Room Temperature", "User ID", "Processing Status"
+     *
+     * @generated from field: optional string label = 2;
+     */
+    label?: string;
+    /**
+     * Detailed description of the signal's purpose, behavior, and usage.
+     * Should provide context for developers and users.
+     *
+     * Length: Up to 1000 characters
+     *
+     * May include:
+     * - What the signal represents
+     * - When it's emitted
+     * - Expected value ranges or formats
+     * - Usage examples or constraints
+     *
+     * @generated from field: optional string description = 3;
+     */
+    description?: string;
+    /**
+     * Indicates whether this signal must be provided.
+     *
+     * When false or unset: Signal is required and must be present
+     * When true: Signal is optional and may be omitted
+     *
+     * Optional signals provide flexibility in graph construction, allowing
+     * vertices to function with or without certain inputs.
+     *
+     * @generated from field: optional bool optional = 4;
+     */
+    optional?: boolean;
+    /**
+     * List of formats that this signal produces. The signal will produce any signal whose
+     * format matches at least one entry in this list.
+     *
+     * Validation: At least one format must be specified. Maximum 50 formats to prevent
+     * overly complicated signals and ensure reasonable validation performance.
+     *
+     * @generated from field: repeated mochabugapis.adapt.graph.SignalFormat formats = 5;
+     */
+    formats?: SignalFormatJson[];
+};
+/**
+ * Describes the message mochabugapis.adapt.graph.SignalDescriptor.
+ * Use `create(SignalDescriptorSchema)` to create a new message.
+ */
+export declare const SignalDescriptorSchema: GenMessage<SignalDescriptor, {
+    jsonType: SignalDescriptorJson;
+}>;
+//# sourceMappingURL=signal_descriptor_pb.d.ts.map

package/dist/genproto/mochabugapis/adapt/graph/signal_descriptor_pb.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"signal_descriptor_pb.d.ts","sourceRoot":"","sources":["../../../../../src/genproto/mochabugapis/adapt/graph/signal_descriptor_pb.ts"],"names":[],"mappings":"AAmBA,OAAO,KAAK,EAAE,OAAO,EAAE,UAAU,EAAE,MAAM,8BAA8B,CAAC;AAGxE,OAAO,KAAK,EAAE,YAAY,EAAE,gBAAgB,EAAE,MAAM,oBAAoB,CAAC;AAEzE,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,oBAAoB,CAAC;AAElD;;GAEG;AACH,eAAO,MAAM,+CAA+C,EAAE,OACqf,CAAC;AAEpjB;;;;;;;;;GASG;AACH,MAAM,MAAM,gBAAgB,GAAG,OAAO,CAAC,2CAA2C,CAAC,GAAG;IACpF;;;;;;;;;;;OAWG;IACH,IAAI,EAAE,MAAM,CAAC;IAEb;;;;;;;;;OASG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IAEf;;;;;;;;;;;;;OAaG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IAErB;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,EAAE,OAAO,CAAC;IAEnB;;;;;;;;OAQG;IACH,OAAO,EAAE,YAAY,EAAE,CAAC;CACzB,CAAC;AAEF;;;;;;;;;GASG;AACH,MAAM,MAAM,oBAAoB,GAAG;IACjC;;;;;;;;;;;OAWG;IACH,IAAI,CAAC,EAAE,MAAM,CAAC;IAEd;;;;;;;;;OASG;IACH,KAAK,CAAC,EAAE,MAAM,CAAC;IAEf;;;;;;;;;;;;;OAaG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IAErB;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,EAAE,OAAO,CAAC;IAEnB;;;;;;;;OAQG;IACH,OAAO,CAAC,EAAE,gBAAgB,EAAE,CAAC;CAC9B,CAAC;AAEF;;;GAGG;AACH,eAAO,MAAM,sBAAsB,EAAE,UAAU,CAAC,gBAAgB,EAAE;IAAC,QAAQ,EAAE,oBAAoB,CAAA;CAAC,CACjC,CAAC"}

package/dist/genproto/mochabugapis/adapt/graph/signal_format_pb.d.ts

@@ -0,0 +1,305 @@
+import type { GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
+import type { JTDSchema, JTDSchemaJson } from "./jtd_schema_pb";
+import type { Message } from "@bufbuild/protobuf";
+/**
+ * Describes the file mochabugapis/adapt/graph/signal_format.proto.
+ */
+export declare const file_mochabugapis_adapt_graph_signal_format: GenFile;
+/**
+ * SignalFormat defines how signal data is structured and should be interpreted.
+ * All signals are binary at the transport level; this message determines the interpretation.
+ *
+ * This message is designed to be reusable across both signal descriptors (which produce
+ * one specific format or format family) and signal bindings (which may accept multiple formats).
+ *
+ * Format matching semantics:
+ * - JTD schemas use structural subsumption (handled by existing JTD subsume algorithm)
+ * - MIME types use pattern matching with optional wildcards
+ * - JTD and MIME formats are incompatible - a JTD signal cannot bind to a MIME-accepting
+ *   binding and vice versa, even if semantically similar (e.g., application/json vs JTD)
+ *
+ * @generated from message mochabugapis.adapt.graph.SignalFormat
+ */
+export type SignalFormat = Message<"mochabugapis.adapt.graph.SignalFormat"> & {
+    /**
+     * The format specification is mutually exclusive - a signal format is either:
+     * - jtd_schema: Structured JSON with schema validation (enables automatic validation,
+     *   type inference, and platform-level tooling support)
+     * - mime_type: Generic binary format identification for non-JSON data
+     *
+     * Design note: While JSON data is technically "application/json" as a MIME type,
+     * using jtd_schema instead provides platform-level schema validation, automatic
+     * type checking, and better developer tooling support.
+     *
+     * @generated from oneof mochabugapis.adapt.graph.SignalFormat.format
+     */
+    format: {
+        /**
+         * Schema definition for JSON-structured signals.
+         * Must follow the JSON Type Definition (JTD) specification: https://www.rfc-editor.org/rfc/rfc8927
+         *
+         * The empty schema {} validates any JSON value.
+         *
+         * Common JTD primitive types:
+         * - "string": JSON string values
+         * - "float32", "float64": JSON numbers with specific precision
+         * - "int8", "int16", "int32": JSON numbers representing integers
+         * - "boolean": JSON boolean values (true/false)
+         * - "timestamp": ISO 8601 datetime strings (RFC 3339 format)
+         *
+         * JTD also supports complex types:
+         * - elements: { elements: { type: "string" } } for arrays
+         * - properties: { properties: { id: { type: "int32" } } } for objects
+         * - discriminator: For tagged unions
+         * - enum: For enumerated string values
+         * - nullable: Wraps any type to allow null
+         *
+         * Compatibility checking:
+         * JTD schemas are checked for structural compatibility using subsumption rules.
+         * A producer schema is compatible with a consumer schema if every valid value
+         * under the producer schema is also valid under the consumer schema.
+         *
+         * Example usage for text display binding (accepts primitive types):
+         *   accepts = [
+         *     { jtd_schema: { type: "string" } },
+         *     { jtd_schema: { type: "float64" } },
+         *     { jtd_schema: { type: "int32" } },
+         *     { jtd_schema: { type: "boolean" } },
+         *     { jtd_schema: { type: "timestamp" } }
+         *   ]
+         *
+         * @generated from field: mochabugapis.adapt.graph.JTDSchema jtd_schema = 1;
+         */
+        value: JTDSchema;
+        case: "jtdSchema";
+    } | {
+        /**
+         * MIME type for binary format signals.
+         * Must be a concrete MIME type or a type-family wildcard, conforming to RFC 6838
+         * media type specifications (without parameters).
+         *
+         * Format requirements:
+         * - Structure: type/subtype (e.g., "image/png", "image/*")
+         * - Type must be concrete (alphanumeric start + allowed characters)
+         * - Subtype can be concrete OR wildcard "*"
+         * - NO parameters allowed (no semicolons or charset specifications)
+         * - Case-insensitive but conventionally lowercase
+         * - Maximum length: 255 characters (127 for type + "/" + 127 for subtype)
+         *
+         * Wildcard rules:
+         * Wildcards are allowed in two forms:
+         * ✅ "*\/*"           - Universal wildcard (accepts/produces any format)
+         * ✅ "image/*"       - Type-family wildcard (accepts/produces any image format)
+         * ✅ "text/*"        - Type-family wildcard (accepts/produces any text format)
+         * ✅ "application/*" - Type-family wildcard (accepts/produces any application format)
+         * ✅ "image/png"     - Concrete type (no wildcard)
+         * ❌ "*\/png"         - Type wildcard with concrete subtype forbidden (semantically invalid)
+         * ❌ "*\/json"        - Type wildcard with concrete subtype forbidden (semantically invalid)
+         *
+         * Why no parameters?
+         * Parameters like charset, boundary, and encoding are transport-level concerns
+         * in this system. All data is transmitted as binary/JSON, and character encoding
+         * is handled at the serialization layer, not the graph validation layer.
+         *
+         * **Character Encoding Assumption**:
+         * All text-based formats (text/*, application/json, application/xml, etc.) are
+         * assumed to use UTF-8 encoding. This is a platform-wide convention that ensures
+         * consistent text handling across all signal processing. When specifying text MIME
+         * types, charset parameters are forbidden and UTF-8 is always assumed.
+         *
+         * Examples of forbidden formats:
+         * ❌ "text/plain; charset=utf-8"     (redundant - UTF-8 is assumed)
+         * ❌ "text/plain; charset=iso-8859-1" (non-UTF-8 encodings not supported)
+         * ❌ "application/json; format=compact"
+         * Instead use: "text/plain" or "application/json"
+         *
+         *
+         * Semantic meaning for producers vs consumers:
+         * - In SignalDescriptor (producer):
+         *   - "*\/*" means "this signal's format is completely dynamic"
+         *   - "image/*" means "this signal produces an image, format depends on runtime"
+         * - In SignalBinding (consumer):
+         *   - "*\/*" means "this binding accepts any format universally"
+         *   - "image/*" means "this binding accepts any image format"
+         *
+         * MIME type compatibility checking (subsumption rules):
+         * Subsumption hierarchy: Concrete ⊆ Type-family ⊆ Universal
+         * Example: image/png ⊆ image/* ⊆ *\/*
+         *
+         * A producer format is compatible with a consumer format if:
+         * - Both are concrete and equal: "image/png" ⊆ "image/png" ✅
+         * - Producer is concrete, consumer is type-family: "image/png" ⊆ "image/*" ✅
+         * - Producer is concrete, consumer is universal: "image/png" ⊆ "*\/*" ✅
+         * - Both are type-family of same type: "image/*" ⊆ "image/*" ✅
+         * - Producer is type-family, consumer is universal: "image/*" ⊆ "*\/*" ✅
+         * - Both are universal: "*\/*" ⊆ "*\/*" ✅
+         * - Producer is type-family, consumer is concrete: "image/*" ⊆ "image/png" ❌
+         * - Producer is universal, consumer is type-family: "*\/*" ⊆ "image/*" ❌
+         * - Producer is universal, consumer is concrete: "*\/*" ⊆ "image/png" ❌
+         * - Different types: "image/png" ⊆ "text/*" ❌
+         *
+         * Common concrete examples:
+         * - Images: "image/png", "image/jpeg", "image/webp", "image/gif", "image/svg+xml"
+         * - Documents: "application/pdf", "text/html", "text/markdown"
+         * - Binary: "application/octet-stream", "application/zip"
+         * - Text: "text/plain", "text/csv"
+         *
+         * Common wildcard examples:
+         * - "image/*": Any raster or vector image format
+         * - "text/*": Any text-based format
+         * - "application/*": Any application-specific binary format
+         * - "audio/*": Any audio format
+         * - "video/*": Any video format
+         *
+         * @generated from field: string mime_type = 2;
+         */
+        value: string;
+        case: "mimeType";
+    } | {
+        case: undefined;
+        value?: undefined;
+    };
+};
+/**
+ * SignalFormat defines how signal data is structured and should be interpreted.
+ * All signals are binary at the transport level; this message determines the interpretation.
+ *
+ * This message is designed to be reusable across both signal descriptors (which produce
+ * one specific format or format family) and signal bindings (which may accept multiple formats).
+ *
+ * Format matching semantics:
+ * - JTD schemas use structural subsumption (handled by existing JTD subsume algorithm)
+ * - MIME types use pattern matching with optional wildcards
+ * - JTD and MIME formats are incompatible - a JTD signal cannot bind to a MIME-accepting
+ *   binding and vice versa, even if semantically similar (e.g., application/json vs JTD)
+ *
+ * @generated from message mochabugapis.adapt.graph.SignalFormat
+ */
+export type SignalFormatJson = {
+    /**
+     * Schema definition for JSON-structured signals.
+     * Must follow the JSON Type Definition (JTD) specification: https://www.rfc-editor.org/rfc/rfc8927
+     *
+     * The empty schema {} validates any JSON value.
+     *
+     * Common JTD primitive types:
+     * - "string": JSON string values
+     * - "float32", "float64": JSON numbers with specific precision
+     * - "int8", "int16", "int32": JSON numbers representing integers
+     * - "boolean": JSON boolean values (true/false)
+     * - "timestamp": ISO 8601 datetime strings (RFC 3339 format)
+     *
+     * JTD also supports complex types:
+     * - elements: { elements: { type: "string" } } for arrays
+     * - properties: { properties: { id: { type: "int32" } } } for objects
+     * - discriminator: For tagged unions
+     * - enum: For enumerated string values
+     * - nullable: Wraps any type to allow null
+     *
+     * Compatibility checking:
+     * JTD schemas are checked for structural compatibility using subsumption rules.
+     * A producer schema is compatible with a consumer schema if every valid value
+     * under the producer schema is also valid under the consumer schema.
+     *
+     * Example usage for text display binding (accepts primitive types):
+     *   accepts = [
+     *     { jtd_schema: { type: "string" } },
+     *     { jtd_schema: { type: "float64" } },
+     *     { jtd_schema: { type: "int32" } },
+     *     { jtd_schema: { type: "boolean" } },
+     *     { jtd_schema: { type: "timestamp" } }
+     *   ]
+     *
+     * @generated from field: mochabugapis.adapt.graph.JTDSchema jtd_schema = 1;
+     */
+    jtdSchema?: JTDSchemaJson;
+    /**
+     * MIME type for binary format signals.
+     * Must be a concrete MIME type or a type-family wildcard, conforming to RFC 6838
+     * media type specifications (without parameters).
+     *
+     * Format requirements:
+     * - Structure: type/subtype (e.g., "image/png", "image/*")
+     * - Type must be concrete (alphanumeric start + allowed characters)
+     * - Subtype can be concrete OR wildcard "*"
+     * - NO parameters allowed (no semicolons or charset specifications)
+     * - Case-insensitive but conventionally lowercase
+     * - Maximum length: 255 characters (127 for type + "/" + 127 for subtype)
+     *
+     * Wildcard rules:
+     * Wildcards are allowed in two forms:
+     * ✅ "*\/*"           - Universal wildcard (accepts/produces any format)
+     * ✅ "image/*"       - Type-family wildcard (accepts/produces any image format)
+     * ✅ "text/*"        - Type-family wildcard (accepts/produces any text format)
+     * ✅ "application/*" - Type-family wildcard (accepts/produces any application format)
+     * ✅ "image/png"     - Concrete type (no wildcard)
+     * ❌ "*\/png"         - Type wildcard with concrete subtype forbidden (semantically invalid)
+     * ❌ "*\/json"        - Type wildcard with concrete subtype forbidden (semantically invalid)
+     *
+     * Why no parameters?
+     * Parameters like charset, boundary, and encoding are transport-level concerns
+     * in this system. All data is transmitted as binary/JSON, and character encoding
+     * is handled at the serialization layer, not the graph validation layer.
+     *
+     * **Character Encoding Assumption**:
+     * All text-based formats (text/*, application/json, application/xml, etc.) are
+     * assumed to use UTF-8 encoding. This is a platform-wide convention that ensures
+     * consistent text handling across all signal processing. When specifying text MIME
+     * types, charset parameters are forbidden and UTF-8 is always assumed.
+     *
+     * Examples of forbidden formats:
+     * ❌ "text/plain; charset=utf-8"     (redundant - UTF-8 is assumed)
+     * ❌ "text/plain; charset=iso-8859-1" (non-UTF-8 encodings not supported)
+     * ❌ "application/json; format=compact"
+     * Instead use: "text/plain" or "application/json"
+     *
+     *
+     * Semantic meaning for producers vs consumers:
+     * - In SignalDescriptor (producer):
+     *   - "*\/*" means "this signal's format is completely dynamic"
+     *   - "image/*" means "this signal produces an image, format depends on runtime"
+     * - In SignalBinding (consumer):
+     *   - "*\/*" means "this binding accepts any format universally"
+     *   - "image/*" means "this binding accepts any image format"
+     *
+     * MIME type compatibility checking (subsumption rules):
+     * Subsumption hierarchy: Concrete ⊆ Type-family ⊆ Universal
+     * Example: image/png ⊆ image/* ⊆ *\/*
+     *
+     * A producer format is compatible with a consumer format if:
+     * - Both are concrete and equal: "image/png" ⊆ "image/png" ✅
+     * - Producer is concrete, consumer is type-family: "image/png" ⊆ "image/*" ✅
+     * - Producer is concrete, consumer is universal: "image/png" ⊆ "*\/*" ✅
+     * - Both are type-family of same type: "image/*" ⊆ "image/*" ✅
+     * - Producer is type-family, consumer is universal: "image/*" ⊆ "*\/*" ✅
+     * - Both are universal: "*\/*" ⊆ "*\/*" ✅
+     * - Producer is type-family, consumer is concrete: "image/*" ⊆ "image/png" ❌
+     * - Producer is universal, consumer is type-family: "*\/*" ⊆ "image/*" ❌
+     * - Producer is universal, consumer is concrete: "*\/*" ⊆ "image/png" ❌
+     * - Different types: "image/png" ⊆ "text/*" ❌
+     *
+     * Common concrete examples:
+     * - Images: "image/png", "image/jpeg", "image/webp", "image/gif", "image/svg+xml"
+     * - Documents: "application/pdf", "text/html", "text/markdown"
+     * - Binary: "application/octet-stream", "application/zip"
+     * - Text: "text/plain", "text/csv"
+     *
+     * Common wildcard examples:
+     * - "image/*": Any raster or vector image format
+     * - "text/*": Any text-based format
+     * - "application/*": Any application-specific binary format
+     * - "audio/*": Any audio format
+     * - "video/*": Any video format
+     *
+     * @generated from field: string mime_type = 2;
+     */
+    mimeType?: string;
+};
+/**
+ * Describes the message mochabugapis.adapt.graph.SignalFormat.
+ * Use `create(SignalFormatSchema)` to create a new message.
+ */
+export declare const SignalFormatSchema: GenMessage<SignalFormat, {
+    jsonType: SignalFormatJson;
+}>;
+//# sourceMappingURL=signal_format_pb.d.ts.map

package/dist/genproto/mochabugapis/adapt/graph/signal_format_pb.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"signal_format_pb.d.ts","sourceRoot":"","sources":["../../../../../src/genproto/mochabugapis/adapt/graph/signal_format_pb.ts"],"names":[],"mappings":"AAmBA,OAAO,KAAK,EAAE,OAAO,EAAE,UAAU,EAAE,MAAM,8BAA8B,CAAC;AAGxE,OAAO,KAAK,EAAE,SAAS,EAAE,aAAa,EAAE,MAAM,iBAAiB,CAAC;AAEhE,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,oBAAoB,CAAC;AAElD;;GAEG;AACH,eAAO,MAAM,2CAA2C,EAAE,OACo/B,CAAC;AAE/iC;;;;;;;;;;;;;;GAcG;AACH,MAAM,MAAM,YAAY,GAAG,OAAO,CAAC,uCAAuC,CAAC,GAAG;IAC5E;;;;;;;;;;;OAWG;IACH,MAAM,EAAE;QACN;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WAmCG;QACH,KAAK,EAAE,SAAS,CAAC;QACjB,IAAI,EAAE,WAAW,CAAC;KACnB,GAAG;QACF;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;WA+EG;QACH,KAAK,EAAE,MAAM,CAAC;QACd,IAAI,EAAE,UAAU,CAAC;KAClB,GAAG;QAAE,IAAI,EAAE,SAAS,CAAC;QAAC,KAAK,CAAC,EAAE,SAAS,CAAA;KAAE,CAAC;CAC5C,CAAC;AAEF;;;;;;;;;;;;;;GAcG;AACH,MAAM,MAAM,gBAAgB,GAAG;IAC7B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OAmCG;IACH,SAAS,CAAC,EAAE,aAAa,CAAC;IAE1B;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;OA+EG;IACH,QAAQ,CAAC,EAAE,MAAM,CAAC;CACnB,CAAC;AAEF;;;GAGG;AACH,eAAO,MAAM,kBAAkB,EAAE,UAAU,CAAC,YAAY,EAAE;IAAC,QAAQ,EAAE,gBAAgB,CAAA;CAAC,CACzB,CAAC"}

package/dist/genproto/mochabugapis/adapt/graph/transceiver_pb.d.ts

@@ -0,0 +1,77 @@
+import type { GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
+import type { SignalDescriptor, SignalDescriptorJson } from "./signal_descriptor_pb";
+import type { Message } from "@bufbuild/protobuf";
+/**
+ * Describes the file mochabugapis/adapt/graph/transceiver.proto.
+ */
+export declare const file_mochabugapis_adapt_graph_transceiver: GenFile;
+/**
+ * Transceiver is a dual-purpose entity capable of both emitting and receiving signals.
+ *
+ * @generated from message mochabugapis.adapt.graph.Transceiver
+ */
+export type Transceiver = Message<"mochabugapis.adapt.graph.Transceiver"> & {
+    /**
+     * Identifier for the transceiver, following the ECMA naming pattern, limited to 50 characters.
+     *
+     * @generated from field: string name = 1;
+     */
+    name: string;
+    /**
+     * Optional descriptive text for the transceiver's purpose, up to 250 characters.
+     *
+     * @generated from field: optional string description = 2;
+     */
+    description?: string;
+    /**
+     * List of signals the transceiver handles. Can contain up to 512 unique signals.
+     *
+     * @generated from field: repeated mochabugapis.adapt.graph.SignalDescriptor signals = 3;
+     */
+    signals: SignalDescriptor[];
+    /**
+     * Wheter or not the transceiver is a streaming transceiver.
+     *
+     * @generated from field: optional bool streaming = 4;
+     */
+    streaming?: boolean;
+};
+/**
+ * Transceiver is a dual-purpose entity capable of both emitting and receiving signals.
+ *
+ * @generated from message mochabugapis.adapt.graph.Transceiver
+ */
+export type TransceiverJson = {
+    /**
+     * Identifier for the transceiver, following the ECMA naming pattern, limited to 50 characters.
+     *
+     * @generated from field: string name = 1;
+     */
+    name?: string;
+    /**
+     * Optional descriptive text for the transceiver's purpose, up to 250 characters.
+     *
+     * @generated from field: optional string description = 2;
+     */
+    description?: string;
+    /**
+     * List of signals the transceiver handles. Can contain up to 512 unique signals.
+     *
+     * @generated from field: repeated mochabugapis.adapt.graph.SignalDescriptor signals = 3;
+     */
+    signals?: SignalDescriptorJson[];
+    /**
+     * Wheter or not the transceiver is a streaming transceiver.
+     *
+     * @generated from field: optional bool streaming = 4;
+     */
+    streaming?: boolean;
+};
+/**
+ * Describes the message mochabugapis.adapt.graph.Transceiver.
+ * Use `create(TransceiverSchema)` to create a new message.
+ */
+export declare const TransceiverSchema: GenMessage<Transceiver, {
+    jsonType: TransceiverJson;
+}>;
+//# sourceMappingURL=transceiver_pb.d.ts.map

package/dist/genproto/mochabugapis/adapt/graph/transceiver_pb.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"transceiver_pb.d.ts","sourceRoot":"","sources":["../../../../../src/genproto/mochabugapis/adapt/graph/transceiver_pb.ts"],"names":[],"mappings":"AAmBA,OAAO,KAAK,EAAE,OAAO,EAAE,UAAU,EAAE,MAAM,8BAA8B,CAAC;AAGxE,OAAO,KAAK,EAAE,gBAAgB,EAAE,oBAAoB,EAAE,MAAM,wBAAwB,CAAC;AAErF,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,oBAAoB,CAAC;AAElD;;GAEG;AACH,eAAO,MAAM,yCAAyC,EAAE,OAC4kB,CAAC;AAEroB;;;;GAIG;AACH,MAAM,MAAM,WAAW,GAAG,OAAO,CAAC,sCAAsC,CAAC,GAAG;IAC1E;;;;OAIG;IACH,IAAI,EAAE,MAAM,CAAC;IAEb;;;;OAIG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IAErB;;;;OAIG;IACH,OAAO,EAAE,gBAAgB,EAAE,CAAC;IAE5B;;;;OAIG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;CACrB,CAAC;AAEF;;;;GAIG;AACH,MAAM,MAAM,eAAe,GAAG;IAC5B;;;;OAIG;IACH,IAAI,CAAC,EAAE,MAAM,CAAC;IAEd;;;;OAIG;IACH,WAAW,CAAC,EAAE,MAAM,CAAC;IAErB;;;;OAIG;IACH,OAAO,CAAC,EAAE,oBAAoB,EAAE,CAAC;IAEjC;;;;OAIG;IACH,SAAS,CAAC,EAAE,OAAO,CAAC;CACrB,CAAC;AAEF;;;GAGG;AACH,eAAO,MAAM,iBAAiB,EAAE,UAAU,CAAC,WAAW,EAAE;IAAC,QAAQ,EAAE,eAAe,CAAA;CAAC,CACxB,CAAC"}

package/dist/genproto/mochabugapis/adapt/graph/transmitter_pb.d.ts

@@ -0,0 +1,120 @@
+import type { GenEnum, GenFile, GenMessage } from "@bufbuild/protobuf/codegenv2";
+import type { SignalDescriptor, SignalDescriptorJson } from "./signal_descriptor_pb";
+import type { Message } from "@bufbuild/protobuf";
+/**
+ * Describes the file mochabugapis/adapt/graph/transmitter.proto.
+ */
+export declare const file_mochabugapis_adapt_graph_transmitter: GenFile;
+/**
+ * Transmitter represents an output point for a vertex, emitting multiple signals.
+ *
+ * @generated from message mochabugapis.adapt.graph.Transmitter
+ */
+export type Transmitter = Message<"mochabugapis.adapt.graph.Transmitter"> & {
+    /**
+     * Identifier for the transmitter, following the ECMA naming pattern, limited to 50 characters.
+     *
+     * @generated from field: string name = 1;
+     */
+    name: string;
+    /**
+     * Optional descriptive text for the transmitter's purpose, up to 250 characters.
+     *
+     * @generated from field: optional string description = 2;
+     */
+    description?: string;
+    /**
+     * List of signals the transmitter can emit. Can contain up to 512 unique signals.
+     *
+     * @generated from field: repeated mochabugapis.adapt.graph.SignalDescriptor signals = 3;
+     */
+    signals: SignalDescriptor[];
+    /**
+     * An optional mode for the transmitter, indicating its operational context.
+     * If not set, it defaults to the standard mode
+     *
+     * @generated from field: optional mochabugapis.adapt.graph.Transmitter.Mode mode = 4;
+     */
+    mode?: Transmitter_Mode;
+};
+/**
+ * Transmitter represents an output point for a vertex, emitting multiple signals.
+ *
+ * @generated from message mochabugapis.adapt.graph.Transmitter
+ */
+export type TransmitterJson = {
+    /**
+     * Identifier for the transmitter, following the ECMA naming pattern, limited to 50 characters.
+     *
+     * @generated from field: string name = 1;
+     */
+    name?: string;
+    /**
+     * Optional descriptive text for the transmitter's purpose, up to 250 characters.
+     *
+     * @generated from field: optional string description = 2;
+     */
+    description?: string;
+    /**
+     * List of signals the transmitter can emit. Can contain up to 512 unique signals.
+     *
+     * @generated from field: repeated mochabugapis.adapt.graph.SignalDescriptor signals = 3;
+     */
+    signals?: SignalDescriptorJson[];
+    /**
+     * An optional mode for the transmitter, indicating its operational context.
+     * If not set, it defaults to the standard mode
+     *
+     * @generated from field: optional mochabugapis.adapt.graph.Transmitter.Mode mode = 4;
+     */
+    mode?: Transmitter_ModeJson;
+};
+/**
+ * Describes the message mochabugapis.adapt.graph.Transmitter.
+ * Use `create(TransmitterSchema)` to create a new message.
+ */
+export declare const TransmitterSchema: GenMessage<Transmitter, {
+    jsonType: TransmitterJson;
+}>;
+/**
+ * The type of the transmitter.
+ *
+ * @generated from enum mochabugapis.adapt.graph.Transmitter.Mode
+ */
+export declare enum Transmitter_Mode {
+    /**
+     * Default value indicating the mode is not explicitly set.
+     *
+     * @generated from enum value: MODE_UNSPECIFIED = 0;
+     */
+    UNSPECIFIED = 0,
+    /**
+     * Transmitter is transmitting with the standard mode. I.e. a single transmission
+     *
+     * @generated from enum value: MODE_STANDARD = 1;
+     */
+    STANDARD = 1,
+    /**
+     * Transmitter is transmitter with stream. I.e. multiple transmissions
+     *
+     * @generated from enum value: MODE_STREAM = 2;
+     */
+    STREAM = 2,
+    /**
+     * Transmitter is transmitting a failure. I.e. a single transmission with a failure flag
+     *
+     * @generated from enum value: MODE_FAILURE = 3;
+     */
+    FAILURE = 3
+}
+/**
+ * The type of the transmitter.
+ *
+ * @generated from enum mochabugapis.adapt.graph.Transmitter.Mode
+ */
+export type Transmitter_ModeJson = "MODE_UNSPECIFIED" | "MODE_STANDARD" | "MODE_STREAM" | "MODE_FAILURE";
+/**
+ * Describes the enum mochabugapis.adapt.graph.Transmitter.Mode.
+ */
+export declare const Transmitter_ModeSchema: GenEnum<Transmitter_Mode, Transmitter_ModeJson>;
+//# sourceMappingURL=transmitter_pb.d.ts.map