syntax = "proto3";

package test_pb;

option go_package = "Beacon/pkg/pb"; // 替换 your_module_path

message DynamicTestRunInput {
  string run_id = 1;
  string composite_case_id = 2; // 引用数据库中的复合案例ID
  map<string, string> global_parameters = 3; // 运行时传入的全局参数，例如 environment_url

  // 这里的 steps 会在 Go 服务端启动 Workflow 时，根据数据库查询结果动态构建
  // 也可以不在 Proto 中定义，直接在 Workflow 中根据 DB 数据拉取并使用
  // 但如果希望 Workflow 的输入本身包含整个流程定义，可以定义一个嵌套结构
  repeated DynamicStep steps = 4; // 也可以通过 DB ID 在 Workflow 中获取
}

message DynamicStep {
  string step_id = 1; // 对应数据库中的 step_id
  string activity_name = 2; // 对应 Activity 函数名
  map<string, string> parameters_json = 3; // 将 JSONB 转换为 string 或 bytes 传递
  // 对于条件和跳转，Workflow 内部逻辑会根据这些信息进行判断
  // 例如，可以传递一个表示整个流程图的 DAG 结构，或让 Workflow 每次都查询 DB
}

// 定义一个复合测试用例中的单个步骤
message CompositeCaseStepDefinition {
  string step_id = 1;               // 对应数据库中的 step_id
  int32 step_order = 2;             // 步骤执行顺序
  string step_type = 3;             // e.g., "API_TEST", "UI_TEST"
  string activity_name = 4;         // 对应的 Temporal Activity 函数名

  // 将参数作为 JSON 字符串传递，在 Workflow 中反序列化
  // 也可以根据 Activity 的具体类型定义一个 oneof 结构，但 JSON 字符串更灵活
  string parameters_json = 5;       // JSON 格式的 Activity 参数

  // 条件跳转 (如果成功/失败，跳转到哪个 step_order)
  optional int32 success_next_step_order = 6; // 可选，如果成功则跳转到此步骤的顺序号
  optional int32 failure_next_step_order = 7; // 可选，如果失败则跳转到此步骤的顺序号

  // 执行条件（例如：{"prev_step_id": "xyz", "status": "success"}）
  // Workflow 内部需要解析和评估此 JSON
  string run_condition_json = 8;
}